Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy

[Sara Dickinson <[e-mail]>]

> On 27 Oct 2016, at 19:28, Paul Hoffman <[e-mail]> 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.