Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt
Paul Hoffman paul.hoff...@vpnc.org wrote: On May 12, 2015, at 11:40 AM, Simon Josefsson si...@josefsson.org wrote: 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. My understanding is that the smtps port was allocated, then in a fit of panic the IETF decided that allocating N*M ports (N protocols, M security layers) would be a disaster and cause horrible security layer negotiation problems, so smtps was un-allocated and STARTTLS was invented. (IANA doesn't record when imaps and pops ports were allocated but I think it was before smtps.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Iceland: Variable 4, becoming southeasterly 5 or 6. Moderate or rough. Showers. Good. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt
Daniel Kahn Gillmor d...@fifthhorseman.net writes: On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote: 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. I agree that a single mechanism would be cleaner, but perhaps the two mechanisms serve different purposes? It seems to me that the STARTTLS variant is useful for opportunistic dns-privacy, while the distinct-port-based TLS-wrapped variant is useful for pre-configured non-opportunistic dns-privacy. I think that makes sense -- pre-configured configurations will have some trust anchor considerations as well, and might as well use a dedicated port. However these two issues are probably orthogonal. The current document defines upgrade-base and port-based approach for the same opportunistic use-case. I'd still like to understand exactly what the benefit in having two mechanisms that cover the same use-case is. People might want to argue about whether opportunistic dns-privacy is relevant or useful, but if we concede that it does defend against some relevant attackers, then it might be useful? Yes. I don't imagine a happy eyeballs approach happening -- if someone isn't sure which will be available, they will just use the STARTTLS approach. If someone *is* sure, they will use DNS-over-TLS-over-TCP. The document says that the starttls approach may interact poorly with middle boxes. So it appears as if an implementation cannot be certain that either one will work, but would have to try both. I believe that leads to a lot of unwanted complexity. The preference in IETF has been for the inband STARTTLS approach I think recent discussions have indicated that there isn't any consensus for either approach these days. see, for example, the 'is one or two ports more secure' discussion in saag (hopefully i haven't greivously misinterpreted it): http://thread.gmane.org/gmane.ietf.saag/4916 Yeah... I phrased that as traditional preference first, but I agree this is somewhat shaky. I think it is best to evaluate the use-case for DNS and not apply any rigid traditional arguments. /Simon signature.asc Description: PGP signature ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt
Paul Hoffman paul.hoff...@vpnc.org 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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] How many mechanisms in draft-ietf-dprive-start-tls-for-dns?
On May 13, 2015, at 3:52 AM, Simon Josefsson si...@josefsson.org wrote: Paul Hoffman paul.hoff...@vpnc.org 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
Re: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-00.txt
On Wed, 13 May 2015 12:36:17 +0200, Simon Josefsson wrote: Daniel Kahn Gillmor d...@fifthhorseman.net writes: On Tue 2015-05-12 14:40:12 -0400, Simon Josefsson wrote: 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. I agree that a single mechanism would be cleaner, but perhaps the two mechanisms serve different purposes? It seems to me that the STARTTLS variant is useful for opportunistic dns-privacy, while the distinct-port-based TLS-wrapped variant is useful for pre-configured non-opportunistic dns-privacy. I think that makes sense -- pre-configured configurations will have some trust anchor considerations as well, and might as well use a dedicated port. However these two issues are probably orthogonal. The current document defines upgrade-base and port-based approach for the same opportunistic use-case. I'd still like to understand exactly what the benefit in having two mechanisms that cover the same use-case is. I would not align choice of startup mechanism with the use case. Choice of mechanism depends on interference or non-interference from the client's first-hop network. Use case (opportunistic vs. pre-configured) depends on the client's policy. Clients that change networks (wifi laptops or phones) will want to be flexible in choice of mechanism, but hopefully consistent in their policy on privacy. When you said: The current document defines upgrade-base and port-based approach for the same opportunistic use-case., I would have said ...for all use cases instead. What in the document suggests mechanism is specific to use case? -John Heidemann ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] How many mechanisms in draft-ietf-dprive-start-tls-for-dns?
On Wed, May 13, 2015 at 12:32 PM, Doug Royer douglasro...@gmail.com wrote: Firewall issue: We can't live in fear that only a handful of ports are forever usable because of busted firewalls or busted firewall administrators. I think the decision should be based on what's best for DNS. I hope that older DNS servers do no crash when getting a new type of packet information on port 53. I would think that making sure we do not bust existing things should take priority. We should be abolishing port numbers in favor of SRV type discovery. However, DNS is the exception to the rule. It is a discovery protocol so it is the one area where fixed IP address and port is arguably acceptable still. It depends on your view of the client-resolver versus resolver-authoritative protocols and how binding is achieved for client-resolver. I think it is time to let go of fixed IP address and known port completely ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
