> On 23 Oct 2016, at 00:26, Paul Hoffman <[email protected]> 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. 


_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to