Hi. 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.
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. Having two parallel mechanisms for a latency-sensitive protocol leads to the necessity of doing a "happy eyeballs" approach in implementation to decrease latency. 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. 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. The preference in IETF has been for the inband STARTTLS approach, 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. 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. Thanks, /Simon
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
