On 11/1/19 3:13 PM, Eric Rescorla wrote: > > Generally speaking, I believe it's fine to add assumptions about > DNSSEC > validation, if that makes the ADoT protocol "better" in some way. > (and > I expect it will) It seems that DNSSEC will be much easier than this > new stuff. > > > Easier for who? The advantage of transport security in this setting is > that the authoritative can just deploy it for all their users without > any interaction with the user.
I don't follow you - where's the user interaction? To deploy DNSSEC, I click a checkbox in my registrar's UI. That's all. Actually, here in ..cz you usually even need to make effort not to get DNSSEC. Or do you refer to the recursive resolver as "user"? Not even stubs (like Firefox) should communicate with authoritatives, so these still won't need to start caring about validating themselves, if that's the direction you mean. > By the way, I'm personally not yet 100% convinced by TLS and might > e.g. > add QUIC into consideration > > > Well, DoQ seems like an interesting direction, but I'm not sure what > you mean by > "not 100% convinced by TLS". Not convinced by the relatively long (first-time) handshakes; I see no other problem, and the overwhelming TLS deployment is a huge advantage (libs, bugs, tools). TLS just wasn't designed for sessions that only need to transport 1kB. Other options: I can't remember if DTLS can do a faster handshake (probably not), but over longer term QUIC will surely have larger deployment. DoH would cover both TLS and QUIC, but the http layer seems pointless here, and I can't see demand in this WG anyway. A specialized protocol might be even a better fit in terms of handshake and other properties (say DNSCrypt, DNSCurve or even a new one), but I *suspect* these paths wouldn't be worth it - another transport protocol just for DNS privacy. --Vladimir
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
