On Tuesday, October 6, 2015 10:32 AM, Sara Dickinson wrote: > > Hi Ted, > > Well my review was from a standpoint of assessing this draft as a solution to > the problem statement of providing DNS privacy. Using existing standards > (DTLS 1.2 and DNS) message truncation is a specific, common case where > standalone dnsodtls cannot provide privacy for DNS. So I think it is a > significant limitation from a protocol, implementation and deployment point > of view.
I am looking at that from an implementer's perspective. In the current DNS client implementation in Windows, there is a client per process, and a shared cache. When an application calls API like "getaddrinfo", the code will open a UDP socket over which DNS queries will be sent and responses will be received. When using UDP, this is more efficient than having a background service manage a single client for the system. Of course, in some cases the queries or the responses are too big for UDP, in which case the exchange moves to TCP. I can see using the same design with DTLS as the default, and TLS as an optional backup when the messages are too large. But for this to be attractive, we would need a set of optimizations: 1) We need a zero-RTT variant of DTLS, which pretty much creates a dependency on TLS/1.3. Zero-RTT also ensures good operation when the servers uses anycast IP addresses. 2) We want to minimize the server load generated by "many sockets" -- and as many TLS handshakes. That means we probably need to support the Resumption and PSK methods defined in TLS/1.3. 3) We would benefit from a light-weight way to "fall back to TCP/TLS," presumably using the resumption methods. There is some uncertainty about TLS/TCP over anycast IP address. It only works as long as the path to that IP address remains stable. In theory it works, but there are potential failures when a client is at about the same distance from two instantiations of the anycast address. In fact, these failures will also affect DTLS, since there will most probably be two separate contexts at the two different locations. It would be useful to have a method to find the unicast address of a server, so connections could be "pinned" to that address. > I’m not saying this issue can’t or won’t be solved. Just that if the solution > requires one of > - deploying DTLS only when TLS is also available Yes. We need the fall back. > - a non-standard DTLS implementation No appetite for that... > - extensions to either the DTLS or DNS protocol (which are not yet detailed > in > the draft) > then that requirement should be very clear in a standards track document. Maybe we should have a unified draft, along the lines of "DTLS and fallback to TLS." -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
