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

[Sara Dickinson <[e-mail]>]

>> 
>> I didn’t get any further feedback on this so didn’t include the text in the next version (which I really should have). I’d like to think we could work on improving this text to paint the correct picture of the 2 classes of user and which profile is most suitable for them?
> 
> I apologize for not giving feedback at the time; I was waiting for other people to chime in and then forgot.

My bad, I should have included the text regardless. 

> 
> That text is really good. However, instead of at the end of Section 4, I would put it right after Table 1, replacing "Since Strict Privacy provides the strongest privacy guarantees it is preferable to Opportunistic Privacy”.

Yes indeed - I meant at the end of section 4.2 which is exactly there. 

> 
> 
>>> Also: why is "hard failure" the fourth bullet describing Opportunistic Privacy? That would only apply to Strict Privacy, correct?
>> 
>> Not necessarily. From RFC7435: “Opportunistic security protocols may hard-fail with peers for which a
>>   security capability fails to function as advertised. “
> 
> Yes, I saw that there, but it makes no sense in this document because we explicitly allow for both going to no TLS and not telling the user about whether TLS is in use. I think that bit in RFC 7435 only applies to systems where the user sees that TLS is in use. We really should take it out of this document; otherwise, we have to add in a lot more about users knowing about the use of TLS.

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.

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?

Sara.