On 27-Apr-2015 11:03 am, Christian Huitema <[email protected]> wrote: > >>> The question then is whether we can profile DTLS without in effect >>> requiring a new implementation library. >> This doesn't solve the actual problem, as compared with DNS/UDP. > > For all practical purposes, DNS/DTLS/UDP is close to DNS/TLS/TCP than > DNS/UDP. This is particularly true when using anycast. > > DNS/UDP is pretty much stateless. If we assume that an anycast address is > served by a pool of servers, any server in the pool can answer the request. > The responses will be identical, and the client will not see any difference. > > Both DNS/DTLS/UDP and DNS/TLS/TCP are different. The servers can only answer > a query if they have previously completed a TLS handshake with the client. If > anycast routes a query to a different server in the pool, that different > server will have to repeat the TLS handshake before answering.
That problem is fixed if we have "Transport Layer Security (TLS) Session Resumption without Server-Side State" (RFC5077) and the emerging TLS 1.3 early data extension. > DTLS/UDP may have a slightly lower overhead than TLS/TCP, in the sense that > it will not require the TCP "ACK." But that comes at the price of less > efficient error handling, and also less efficient transmission if the DNS > messages happen to be larger than the MTU. Large responses exceeding MTU are already a problem with DNS over UDP. I agree that if we want to fix that problem, abandoning DNS over UDP entirely is a viable approach. However, based on the comments at the microphone that I heard in Dallas, I did not get the feeling there was consensus to abandon UDP. But I am not a chair, and I can't call consensus on that point. > If a NAT is involved, UDP will also require keep-alive traffic to "pin" the > port mappings, something that is not needed nearly as much with TCP. Keepalive isn't necessary (even with UDP) as long as the packet is self-contained, as it would be with RFC5077 and with TLS early data. -d > Bottom line, DNS/DTLS/UDP does not have much of an advantage over > DNS/TLS/TCP. It looks more like gratuitous complexity. > > -- Christian Huitema > > > > _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
