> On 28 Oct 2016, at 16:40, Paul Hoffman <[email protected]> wrote: > > On 28 Oct 2016, at 8:27, Bob Harold wrote: > >> In Section 5 on Opportunistic Privacy, I am not sure "MAY" is correct. If >> the user chooses Opportunistic, I would think the server MUST try to be >> secure, in whatever ways are possible, but MAY fall back to less secure, >> only if those fail.
I think it is this text that Bob is referring to: “Clients using Opportunistic Privacy SHOULD try for the best case but MAY fallback to intermediate cases and eventually the worst case scenario in order to obtain a response. It therefore provides no privacy guarantee to the user and varying protection depending on what kind of connection is actually used.” One reason I left this as a SHOULD not a MUST because forcing a client to try all available servers for a secure encrypted connection can introduce significant latency into the resolution process which is probably undesirable for Opportunistic. For example, the client has 5 recursive resolvers configured. Authentication fails on the first, but encryption is ok. MUST the client try everyone of the other server to try to get an authenticated & encrypted connection or can it just use the encrypted connection it already has set up, given that it is using Opportunistic Privacy anyway? Appendix A touches on this a little bit too in terms of probing for server capabilities. And yes, if we decide to go for keeping it simple then I think this should be “Clients using Opportunistic Privacy SHOULD try for the best case and SHOULD fallback to intermediate cases and eventually the worst case scenario in order to obtain a response. “ Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
