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

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

On 27 Oct 2016, at 6:45, Sara Dickinson wrote:

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

I apologize for not giving feedback at the time; I was waiting for other 
people to chime in and then forgot.

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


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

--Paul Hoffman