On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd <[email protected]> wrote:
> > 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 > Ah, then it doesn't work. I can't see why people are so insistent on clinging to a familiar label. Is it because it is easier to put blind faith in TLS than consider how it works?
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
