On Mon, Sep 10, 2018 at 10:48 AM Tony Finch <[email protected]> wrote: > 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. > > I'd also like to point out another option -- I threw up a little when first suggesting it, but it may be worth considering again (and please feel free to point me at the list if it already was). An opportunistic solution is vulnerable to intentional (or accidental) blocking, causing a fallback to unencrypted -- blocking of port 853, stupid middleboxes, etc. You also cannot try just do both 53 and 853 in parallel, because, well, that would just be stupid.
When resolving www.example.com, the com servers have already provided you with: dig +nocomment ns example.com example.com. 86383 IN NS a.iana-servers.net. example.com. 86383 IN NS b.iana-servers.net. a.iana-servers.net. 172783 IN A 199.43.135.53 b.iana-servers.net. 172783 IN A 199.43.133.53 a.iana-servers.net. 172783 IN AAAA 2001:500:8f::53 b.iana-servers.net. 172783 IN AAAA 2001:500:8d::53 The NS records here are signed and dnssec verifiable (the glue isn't, but that is a separate fight). If the NS records / labels were _ta.a.iana-servers.net and _ ta.b.iana-servers.net, that could be used as a positive signal that the resolver (or if the underscore freaks people out, dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability to connect is a security issue. so: example.com. 86383 IN NS _ta.a.iana-servers.net. example.com. 86383 IN NS _ta.b.iana-servers.net. _ta.a.iana-servers.net. 172783 IN A 199.43.135.530 _ta.b.iana-servers.net. 172783 IN A 199.43.133.53 This works in a backward compatible manner - non-dprive servers don't care what the nameservers are "called", dprive servers can use the nameserver label as a signal. Yes, you could make the argument that this is a icky (and I won't disagree), or that eventually we would end up with this being abused into _ta._foo._bar._I_like_cheese._ your_father_smells_of_elderberries.ns23.example.com -- but, I still think it is worth considering... W > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
