On Thu, Apr 24, 2014 at 11:19 AM, Joe Abley <jab...@hopcount.ca> wrote: > > On 24 Apr 2014, at 10:53, Phillip Hallam-Baker <hal...@gmail.com> wrote: > >> If you want to use TLS with DNS then use port 443. One of the effects >> of firewalls is that we now only have three ports for all protocols: >> >> Port 80/UDP: Non SSL traffic >> Port 443/TCP: SSL traffic >> Port 53/UDP: DNS > > I think it's important to frame the problem space. I suspect that the > firewall challenges you cite most often apply to communications between stub > resolvers and recursive resolvers, for hosts that are using an off-net > resolver (directly, or via a proxy). > > I also suspect that any ISP who has ever decided to install firewalls or > other packet-mangling middleware in front of their resolver service (and is > still in business) has by now collected many reasons not to do that, and that > the network path between ISP resolver and authority servers is very likely to > be clean. For ISP, read campus, enterprise, etc as appropriate.
My interest at the start was censorship prevention so my interest is almost exclusively client-resolver. It does look like a totally different protocol to resolver-authoritative though. Since what we are concerned with here is (also) privacy, I agree that the resolver-authoritative loop is also in play. But that is a vastly lower priority than the client-resolver loop. If you don't solve that, you don't have any solution. The two problems are completely separate from a trust point of view. For key management in the Resolver-Authoritative loop you almost certainly want to use DNSSEC. But in the client-resolver loop you might well want to use WebPKI because you would want accountability. > I have no science to back up my suspicions, here. Given that others > apparently have different suspicions, equally plausible, perhaps science is > needed. However, I'll note that the conversations surrounding the problem > statement in London all seemed to support separating these two uses of the > protocol. > > I don't think it's worth butchering the protocol if it turns out that we have > an easy and clean solution that works for a significant part of the problem > space (resolvers talking to authority servers), which is what > t-dns/draft-hzhwm-start-tls-for-dns looks like to me. You know when people use loaded terms like 'butchering the protocol' to mean 'do it a different way to me' I start to get a little cross. For me the idea of putting TLS traffic over the same port as non TLS traffic without careful attention to how the upgrade is achieved would be 'butchering the protocol'. Changing the port number to one that is known to work is a cleaner approach. -- Website: http://hallambaker.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
