On Fri, Oct 28, 2016 at 6:21 AM, Sara Dickinson <[email protected]> wrote:
> > > On 27 Oct 2016, at 19:28, Paul Hoffman <[email protected]> wrote: > > > > I will admit that I thought there was just one bottom level of OS in our > discussion, cleartext. If there are two (cleartext; no communication), the > document needs more discussion in multiple places because it would be > surprising to any implementer who didn't follow the long discussion during > the end stages of RFC 7435. > > As the draft stands it is clear about what Strict is and allows for all > flavours of OS, essentially leaving it as an implementation choice. If, > because of the nature of DNS, the feeling is it makes more sense that > Opportunistic _always_ falls back to clear text in order to get service > then I can see the value in that. It is just a question of spelling this > out clearly in the draft. > > > Which users do we think would not want to negotiate weak TLS (such as > DES-MD2) but would be willing to go to cleartext? For other than crypto > experts (who are likely to only want Strict), how would weak TLS be worse > than cleartext? > > There was some discussion in Buenos Aires (I think) about an intermediate > ‘Relaxed’ mode where a client is willing to use a (weakly) encrypted > connection but not willing to fallback to clear text so as to have some > protection against passive monitoring. But IIRC the consensus was ‘keep it > simple, Strict or Opportunistic’. > > For me the other ‘intermediate’ case I was really thinking of in the > hard-fail case for Opportunistic is when the client does have > authentication information configured (as opposed to having none) but the > authentication fails. Should there be scope for the client to decide in > that case that something is wrong enough it doesn't want to continue? As > you say, maybe this is complicating the picture too much. > > Sara. > > 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. -- Bob Harold
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
