Hacker News Reader

Comment by kuschku | Hacker News Reader

Much easier — allow people to put a public key into the WHOIS database.

How does either solve this if the bad actor is able to inject routes at will? Just redirect whois.iana.org to their servers. Then they can prevent you from accurately determining who the registrar is in the first place.

Whois database results can be signed and are signed for some TLDs.

Where is that information on whether or not you should expect a TLD to be signed stored? Is it on the client side? If a client receives an unsigned whois response, what does it do?

This isn't something I was aware of, and I'm not having much luck in finding out the implementation details.

> Where is that information on whether or not you should expect a TLD to be signed stored? Is it on the client side? If a client receives an unsigned whois response, what does it do?

I can imagine a zillion different approaches... most obvious (not necessarily the best) one being to ask an IANA server over a normal TLS connection whether it should expect a TLD's records to be signed. And you can obviously cache that response for a while.

Remember the point here is to validate domain ownership, which everybody already understands to be a big deal. If you can't get any trustable response from anybody, then I would expect it is your duty to refrain from issuing a certificate for that domain.

My question is about the existing implementation of signed WHOIS records, which kuschku seems to be stating exist for some TLD already.

There are some drafts, and some NICs that have custom WHOIS solutions over custom authenticated protocols that don’t integrate with the normal WHOIS functionality.

But the larger issue is that there is no global integrated WHOIS system – e.g. to view a WHOIS record for a .de currently you need to solve a captcha and provide a valid reason (and can’t do it automated).

Or, you know, use DNSSEC.

Crypto maximalists don't like additive security mechanisms that reduce the risk and potential scope of attacks, but may not address every possible attack vector. Often the effect of crypto maximalism is reduced security. In the real world it takes multiple mitigating technologies to address a problem, and perfection is not always achievable. See RFC7435.

Except WHOIS is (likely) going away next month (at least in RIPE) due to GDPR.

It is not going away, it never was, never will.

DENIC has been compliant with the GDPR for months already, and its WHOIS database is still running – you just can’t expose all fields of the WHOIS to any unauthenticated viewer.

I don't think it makes sense to force every domain owner on the planet who wants HTTPS to understand how to generate, store, use, and maintain (more) public/private keys, especially in a secure manner. Having to deal with SSL certificates is enough of a pain already, and for this one you'd have to use another program to sign requests, so there's an added layer of pain. In fact, I don't think it makes sense to add to the burden of domain owners so much at all, even if they could all do this.

Not to mention that, more practically there's no need (and potentially possible harm) to tie the ownership records to a particular cipher. Really, it's the registrar's job to deal with domain ownership; ideally it shouldn't involve you at all. And as a near-corollary, they could probably deal with long-term key security better than the average domain owner.

I think it does make sense. If they can't do it themselves then let them hire someone who'll do this for them.

> I think it does make sense. If they can't do it themselves then let them hire someone who'll do this for them.

Really? In your mental model is (or should be) every domain owner overflowing with money?

In my mental model the requirements of the modern web are way above what was in the 1990s.

A single static landing page would be expected to have at least traffic tracking, at least for the sake of load-balancing.

Even if the page is that - just a static page, the chance it's hosted by the content owner themselves is becoming smaller every day.

So frankly - yes. I believe today is the right time to start adding/replacing layers in the stack. After all - we've gone a long way in terms of software deployment tools so it's way more interchangeable.

Ok, then we need to stop using DNS. Your record server being compromised shouldn't be able to imply ownership.

Or we should require DNSSEC for DV certificates.

You're right that something should be used, but DNSSEC is a weak solution from a security point of view.

I... agree? In fact that's quite literally what I was saying?

Reply on news.ycombinator.com