In article <[email protected]> you write: >Please see > > https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-01 >This isn't a WG document yet, but if the WG wants it, I think it could work >well within the charter, and with the discussion of >draft-ietf-dprive-phase2-requirements.
I'm having some trouble following this draft since it looks like parts of the text got scrambled, e.g.: In the opportunistic encryption described here, there is no need for the recursive resolver to authenticate the authoritative server because any authentication failure does not cause the TLS session from being set up. I get the gist of it, caches consult an oracle to see whether to use DoT, and you have to find your own oracle. That seems uncontroversial, but I fear it is so uncontroversial that it won't be useful. As far as whether to validate the server's certificate, that seems to me to be a policy decision based on your threat model. If your threat is traffic being snooped in transit, you don't, if it's traffic being stolen by hostile servers, you do. We leave for later the question of to what extent authenticating the authoritative server might be a substitute for DNSSEC (keeping in mind we know where to find dnscurve if that's what you want.) R's, John _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
