5 ms·
Much easier — allow people to put a public key into the WHOIS database.
by kuschku 9y ago
Much easier — allow people to put a public key into the WHOIS database.
- cthalupa 9y agoHow 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.
- kuschku 9y agoWhois database results can be signed and are signed for some TLDs.
- cthalupa 9y agoWhere 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.
- mehrdadn 9y ago> 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.
- cthalupa 9y agoMy question is about the existing implementation of signed WHOIS records, which kuschku seems to be stating exist for some TLD already.
- kuschku 9y agoThere 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).
- mehrdadn 9y agoI 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.
- hueving 9y agoOk, then we need to stop using DNS. Your record server being compromised shouldn't be able to imply ownership.
- heavenlyblue 9y agoI think it does make sense. If they can't do it themselves then let them hire someone who'll do this for them.
- LogicX 9y agoExcept WHOIS is (likely) going away next month (at least in RIPE) due to GDPR.
- kuschku 9y agoIt 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.
- cryptonector 9y agoOr, you know, use DNSSEC.
- ietf-dane 9y agoCrypto 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.