On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <[email protected]> wrote: > > On Thu, Apr 23, 2015 at 4:21 PM, [image: ๐]Dan Wing <[email protected]> wrote: > > > I am not an expert on DTLS but that was the concern that made me avoid using > > it. I want a completely stateless resolver, not just UDP. > > > > That means using either a very fast ECC scheme for authentication or some > > sort of kerberos ticket. > > > > > > I believe "Transport Layer Security (TLS) Session Resumption without > > Server-Side State", https://tools.ietf.org/html/rfc5077 solves that problem. > > It works with TLS and with DTLS. > > That is an option in DTLS. > > For a DTLS based scheme to be acceptable, client support has to be mandatory. > > If we do that, I have no problem with the additional overhead. > > > 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. DTLS resumption requires a round trip: the server keeps that state alive as a new DTLS connection, and then the client or server closes it after using it. So if you have 10,000 clients, even if only 100 of them issue queries a second, but over two minutes they all do, you will either force them all to pay the latency price of reopening the connection or store state for 10,000 DTLS sessions. Another problem is with anycast. Ordinarily failover is completely transparent to users: the packets go somewhere else, and get responded to. I don't see how this works with TLS, unless you do fancy stateful failover tricks. The easiest solution is to encrypt packets with a public key that the servers have, or force every packet to contain something equivalent to resumption data. But that requires not using TLS/DTLS. Sincerely, Watson Ladd > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
