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

["Paul Hoffman" <[e-mail]>]

On 28 Oct 2016, at 3:21, Sara Dickinson wrote:

>
>> 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.

Right. However, the draft currently says in a few places that you choose 
opportunistic if you want to be sure you get DNS service. So you either 
have to remove those, or remove the possibility that OS will not go to 
cleartext.

>> 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’.

I don't remember the conversation, but I really don't remember anyone 
advocating for "more complicated". Strict, 
Opportunistic-only-to-good-crypto, and Opportunistic-to-cleartext is 
more complicated than Strict and Opportunistic-to-cleartext. Users don't 
know how to set "good crypto".

> 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.

That's Strict, yes?

> 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.

We can make this as complicated as we want. My goal is to prevent people 
from turning it off when the Internet doesn't work and they find out 
it's because DNS-over-TLS was turned on.

--Paul Hoffman