On May 12, 2015, at 11:40 AM, Simon Josefsson <[email protected]> wrote:
> This document define essentially two mechanisms: port-based DNS-over-TLS > AND upgrade-based DNS-over-TLS. I may have missed earlier discussions > about this design choice. However I want to understand why you > want/need this complexity, to make sure there really was a good > motivation behind that choice. Great. > For SMTP, IMAP, POP etc the reason for having both port-based and > upgrade-based is legacy and historic reasons: back in the days the > STARTTLS approach wasn't invented, so following HTTP(S) footsteps, new > ports were allocated for "secure" protocol variants. Modern protocols > does not have this issue; compare XMPP. That's not accurate for SMTP: during discussion of RFC 2487, there was no alternate port for SMTP-over-TLS. It's also not accurate for IMAP and POP: both of those got STARTTLS-like extensions "because that's how SMTP works". > 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. > 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. > 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. > The preference in IETF has been for the inband STARTTLS approach, ...except for the most popular use case, HTTP... :-) > 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. > 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. --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
