On 23-Apr-2015 06:37 pm, Phillip Hallam-Baker <[email protected]> wrote: > > > On Thu, Apr 23, 2015 at 8:57 PM, Watson Ladd <[email protected] > <mailto:[email protected]>> wrote: > > 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, <emoji_u1f513.png>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 > > > <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?
Hugs and kisses, Phillip. It is time to write down requirements. -d
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
