On May 13, 2015, at 3:52 AM, Simon Josefsson <[email protected]> wrote: > 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.
Yes. > 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. And if we later change to that type of wishy-washy operations, you will be correct at that time. We are not there yet, and I will fight strongly against getting there. If we need more definition of "fails", I'm happy to work on that. Determining success and failure here is completely different than for dual-address applications. >>> 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? Because we know for a fact that some firewalls inspect traffic on TCP port 53, and that they block traffic that they don't understand. They will not understand STARTTLS. A better question is what's wrong with only defining new-port-based DNS-over-TLS. My personal expectation is that there are far more firewalls that do stupid things with trying to understand port 53 traffic than those that block all unknown ports, but we do know that *some* firewalls are configured to block all unknown ports. That is, if the WG wanted to only pick one, I would bet we would end up with more successful encryption with "new port" than with "STARTTLS". However, I still disagree that "try A, and try B if failure" is reasonable here, certainly more reasonable in the IPv4or6 case. > >>> 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. We did. :-) That is, your preferred balance point seems to be different than the one we picked, and thus there is now a WG discussion of balance points. > 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. Correct, it could. And we chose against that balance point. > I don't believe that is a good path to follow. Good, we're in agreement there. > 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. And we do. None of us can prove anything, of course, but we can discuss our opinions. >>> 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. That's not "tampering", that's "blocking", and I agree that happens sometimes, but much more rarely now than five years ago, at least from the anecdotal evidence (that is, insufficient research) that I hear from firewall vendors. > If you try to do IMAP-over-TLS or > SSH you notice this, they would be completely blocked. I POP-over-TLS and SSH whenever I travel, and I am rarely blocked, whereas ten years ago it was common. Firewall vendors I have spoken to say that they stopped recommending 53/80/443 setups long ago. They still exist, of course, and always will; that's why we didn't go with STARTTLS-only. >>> 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. They did influence the design, heavily. They are absolutely not "part of the solution". > What I'm questioning is whether > this has lead to too high complexity that can harm rate of adoption. It is a reasonable question, one that the WG needs to deal with. --Paul Hoffman
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
