In the most general terms, when upgrading a protocol from cleartext to TLS, there are a couple of questions the client has to answer:
1. Does this server support TLS? 2. How can I authenticate it? And there are a couple of approaches to answering them: A. opportunistic B. explicit Opportunistic protocols are easier to set up, but they only answer question 1 (leaving 2 implicit); whereas explicit protocols are about publising an answer to question 2, which implies answer 1 is yes. Opportunistic TLS ----------------- The only mechanism we have is to probe port 853 and fall back to 53 if TLS isn't available. This is fraught with problems since in many cases firewalls will drop packets to port 853 rather than promptly returning ICMP errors. It will be useful for resolvers to keep a cache of which auth servers support TLS (with TLS session resumption data for those that do). Suggestion: TA flag, "TLS available" ------------------------------------ It might be worth adding an EDNS flag to advertise the availability of TLS (only meaningful in responses, like the RA flag). This might mitigate the worst auto-probing latency problems. This is kind of by analogy to SMTP servers advertising STARTTLS in their EHLO response. Authentication mess ------------------- If an auth server supporting TLS has a name in its certificate matching the target name of the NS record that was used to find it, then the implicit answer to question 2 is "just use PKIX certificate validation". However, it's relatively common for NS records to use unofficial target names. For example, DJB's comments on gluelessness and his recommendation for delegations to be in-bailiwick with glue: https://cr.yp.to/djbdns/notes.html This means that opportunistic DoT for a popular authoritative server is likely to run into certificate validation problems, so opportunistic TLS can only be safe against passive snooping not active interception. Suggestion: DANE for DoT ------------------------ This is similar to the SMTP situation, so how far can we get by applying a similar solution? That is, use DANE TLSA records to advertise that: * this nameserver supports TLS, and * resolvers can authenticate it strictly. For example, newton.ac.uk. NS auth0.dns.cam.ac.uk. ... auth0.dns.cam.ac.uk. A 131.111.8.37 auth0.dns.cam.ac.uk. A 2a05:b400:d:a0::1 _853._tcp.auth0.dns.cam.ac.uk. TLSA 1 1 1 ( ... ) (This is basically the same as a SPKI pinset but with a different encoding.) A nice thing about this is that the resolver can find out the auth server's DoT details at the same time as it finds out its addresses, so there's no need for slow protocol negotiation. Caveats of unusual size ----------------------- Unfortunately, when we consider in-bailwick delegations, we soon realise that we have strayed into a fire swamp. Ideally (to minimize latency) when following a referral to a zone with DoT auth servers, we would get everything we need in one response, including TLSA records as a new kind of glue record. I believe there aren't any big obstacles from the DNS protocol point of view (including AXFR and UPDATE etc.) to adding new kinds of glue record. However, to make TLSA glue useful, it also needs to be supported by registry databases, by EPP, and by registrar user interfaces. That'll take considerably more than a million times longer than getting out of the lightning sand. Glueless DANE ------------- If DANE glue isn't available, but TA flags are, then perhaps a reasonable delegation following process is to make a probe `_853._tcp` TLSA query in order to get the server's explicit DoT configuration, or failing that a TA bit suggesting opportunistic DoT. This costs an extra round trip in the resolution process. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ the quest for freedom and justice can never end _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
