On Oct 30, 2020, at 11:55 AM, John Levine <[email protected]> wrote: > > In article <[email protected]> you write: >> Please see >> >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-01__;!!PtGJab4!vl19XNUhsMgJI-uBPf9MS755H4n4TwXtgXF2sb1KJaWgGj29kdvUieBrp6OXnpaCZE4BL36jAw$ >> >> 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.
And now I'm having trouble following your logic. Which oracle are you talking about? The draft only talks about "check on port 853 for DoT service". > 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. The latter is not part of the explicit use case for this document. If others have that use case and want to write it up, that's great. However, they haven't, so we can't evaluate it. > 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.) That's for the other use case, yes. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
