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

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

On 27 Oct 2016, at 11:03, Bob Harold wrote:

> On Thu, Oct 27, 2016 at 12:43 PM, Sara Dickinson <[e-mail]> 
> wrote:
>> So I’m not sure here. The aim here was to try to keep this section
>> flexible in terms of the interpretation of OS but perhaps this needs
>> discussion.

It seems like it does need discussion.

>> RFC 7435 says "An OS protocol first determines the capabilities of 
>> the
>> peer with which it is attempting to communicate.  Peer capabilities 
>> may be
>> discovered by out-of-band or in-band means.  (Out-of-band mechanisms
>> include the use of DANE records….”
>> and then allows for the hard failure if the capability isn’t as 
>> described.
>> So this seems to leave the door open for clients to choose to 
>> hard-fail in
>> certain circumstances which seem relevant to this document (I don’t 
>> see any
>> caveats about this only happening if users know what is going on). It 
>> seems
>> overkill to completely override that here with something like
>> "Opportunistic clients MUST fallback to clear text…” unless there 
>> is
>> consensus that that is how it should work for DNS in all cases?
>>
> It seems that there are levels of Opportunistic Security (OS), either
> falling back to TLS to an un-authenticated server, or falling back to 
> clear
> text (no TLS).  We should make it clear that there are various levels, 
> and
> that there should be some way to choose what minimum level is allowed.

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.

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?

It feels like this is adding a layer of operational complexity for an 
audience who probably doesn't exist.

--Paul Hoffman