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

[Sara Dickinson <[e-mail]>]

> On 23 Oct 2016, at 00:26, Paul Hoffman <[e-mail]> wrote:
> 
> Greetings. The tone in Section 4 about strict privacy seems completely wrong to me. I recognize that there some users really want to be able to configure strict privacy for themselves, but the text in the section ignores the fact that if strict privacy cannot be achieved in a particular session, a user is likely to turn off DNS-over-TLS. The text here makes opportunistic privacy seem like a weak second cousin, not a legitimate choice for people who want to encrypt where possible. If a user sees "you can't use the Internet because of your setting for DNS over TLS", the result will be less overall privacy than if the document primarily emphasizes opportunistic privacy, and describes strict privacy only for those users who are willing to have no internet connectivity at some times.

Hi Paul, 

We started but didn’t conclude a similar, smaller scale discussion during your review of the -03 version. Based on that discussion I proposed the following text for the end of section 4:

"Strict Privacy provides the strongest privacy guarantees and therefore SHOULD
always be implemented in DNS clients along with Opportunistic Privacy.

A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to the use of
clear text (no privacy). 

The choice between the two profiles depends on a number of factors including
which is more important to the particular client:
*  DNS service at the cost of no privacy guarantee (Opportunistic) or
*  guaranteed privacy at the potential cost of no DNS service (Strict).

Additionally the two profiles require varying levels of configuration (or a
trusted relationship with a provider) and DNS server capabilities therefore DNS
clients will need to carefully select which profile to use based on their 
communication privacy needs. 

A DNS server that implements DNS-over-TLS SHOULD provide at least one credential
in order that those DNS clients that wish to do so are able to use Strict
Privacy (see Section 2).”


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? 

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

Sara.