On 27 Oct 2016, at 6:45, Sara Dickinson wrote:
On 23 Oct 2016, at 00:26, Paul Hoffman <paul.hoff...@vpnc.org> 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
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
