From: dns-privacy [mailto:[email protected]] On Behalf Of Watson Ladd Sent: Friday, April 24, 2015 6:28 AM To: Phillip Hallam-Baker Cc: Ted Hardie; [email protected]; Dan Wing (dwing) Subject: Re: [dns-privacy] DPRIVE over UDP or TCP
On Apr 23, 2015 1:52 PM, "Phillip Hallam-Baker" <[email protected]<mailto:[email protected]>> wrote: > > On Thu, Apr 23, 2015 at 4:21 PM, [๐] Dan Wing > <[email protected]<mailto:[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. [TR]The size of the ticket for session resumption in [D]TLS is small as explained in https://tools.ietf.org/html/rfc4507#section-1; The two main benefits as discussed are 3. ability to load balance requests across servers 4. embedded servers with little memory #3 makes it work across servers with anycast. 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. [TR] The cryptographic context need not to synced. The servers could share the keying material to decrypt and authenticate the ticket sent by the client. However with TCP, its state need to be synced. -Tiru 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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
