Paul Hoffman <[email protected]> writes: >> 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.
Reducing complexity (i.e., one mechanism) will avoid that risk. > 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. Where is the definition for "fail" in the document now? If port-based TLS is slowed down to a 100th of normal speed, is that failing and the client should retry over port 53? >>>> 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". My experience is that various kind of middle boxes does so many silly things that you are walking in the wrong direction by starting to care at all about what they do and how often they do it. I think "new port"-only would be better. >>>> 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". The distinction is subtle. If middle boxes influenced the design heavily I would argue that middle boxes are considered to be part of how the end result will look like. /Simon
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
