Paul Hoffman <[email protected]> writes: >> Having two parallel mechanisms for a latency-sensitive protocol leads to >> the necessity of doing a "happy eyeballs" approach in implementation to >> decrease latency. > > That's only true of the specifications don't say what to do > first. However, draft-ietf-dprive-start-tls-for-dns *does* say what to > do first, so there is no happy-eyeballs issue.
Are you referring to the following text? DNS clients first try port-based DNS-over-TLS. If that connection fails, they try upgrade-based DNS-over-TLS. That approach is what dual-stack IPv4+IPv6 applications did before people realized defining "fails" is non-trivial and came up with the happy eyeballs approach to let the quickest path win, and not bother waiting for the "fail" to be determined. >> There is quite some complexity in getting that right. >> Compare RFC 6555 for that approach on a IPv4+IPv6 level. DNS is >> relatively latency sensitive, unlike IMAP/SMTP/XMPP. > > draft-ietf-dprive-start-tls-for-dns is not about all of DNS: it is > about the stub-to-resolver link. The latency you discuss is a one-time > issue, because you rarely change your resolver unless your network > link changes. Good point. If indeed latency is not an issue, what's wrong with only defining upgrade-based DNS-over-TLS? >> What I'm basically wondering, and advocating, is if perhaps one method >> would be sufficient. This would reduce complexity on the protocol and >> implementation level. > > It would indeed reduce complexity, but at the risk of having more > unencrypted DNS traffic. True, but the document needs to find a balance. With the same line of argumentation, you could suggest that the document should include a third mechanism DNS-over-HTTPS because it is common for middle-boxes to interfer with both DNS traffic and special-port TLS traffic, and HTTPS often works. I don't believe that is a good path to follow. It leads to an explosion of mechanisms. Therefor I disagree that the risk of having unencrypted DNS traffic trumf the complexities in having multiple mechanisms. >> so I >> suppose that would be the choice of least resistance. The only reason >> against that in your document is a vague "maybe interact poorly with >> middle boxes that inspect DNS traffic" -- and I would like to challenge >> that this is sufficient motivation to introduce the complexity of having >> both port-based and upgrade-based DNS-over-TLS. Certainly middle boxes >> that inspect traffic may interact poorly with port-based DNS-over-TLS as >> well. > > Such boxes "may" do anything, but we have seen no evidence that boxes > that watch unassigned ports act differently if TLS is negotiated on > those ports. On the contrary: I would say that tampering with non-common ports is frequent. There are many public/hotel wifi networks that only allow port 53, 80, 143 and 443 for example. If you try to do IMAP-over-TLS or SSH you notice this, they would be completely blocked. >> I would go further and say that middle boxes that interfer with DNS >> traffic should be considered part of the problem, not part of the >> solution. > > Fully agree, and the draft says nothing about them being part of the solution. The document says "Protocol changes proposed here must consider potential interactions with middle boxes." and then goes on to introduce the two concepts of upgrade-based and port-based DNS-over-TLS. To me this looks as if behaviour of middle boxes were allowed to significantly influence the design of the protocol. What I'm questioning is whether this has lead to too high complexity that can harm rate of adoption. /Simon
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
