Subject: [dns-privacy] Review of draft-ietf-dprive-dtls-and-tls-profiles-03

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 23 Jul 2016 08:51:43 -0700

This document seems ready for WG Last Call. The comments I have hear can 
be dealt with before or during WG Last Call.

--Paul Hoffman

=====

The following text from section 4.2 still seems wrong:
    Since Strict Privacy provides the strongest privacy guarantees it is
    preferable to Opportunistic Privacy.
Strict Privacy is only preferable to users who would rather have an 
unusable Internet connection: an Internet connection where every DNS 
lookup in every application fails. Currently, that size of that set of 
users is incredibly small, although it might grow over time. The 
sentence above could lead developers to implement Strict Privacy without 
also implementing Opportunistic Privacy to the detriment of the vast 
majority of current Internet users.

Proposed replacement:
    Strict Privacy provides the strongest privacy guarantees and 
therefore should always be implemented along with Opportunistic Privacy. 
The negative implications of the two types of privacy are so radically 
different (a possibly-unusable Internet service for Strict Privacy; 
complete control of DNS responses for Opportunistic Privacy) that 
neither option can be considered a good default for all users.

=====

I have a significant concern about the discussion of 
draft-ietf-dprive-dnsodtls, which is listed as an informational 
reference. That document seems to be stalled again, which is 
unfortunate. If, during IETF review, someone insists that the DTLS 
document is in fact a normative reference (which would make sense if 
that document were finished), draft-ietf-dprive-dtls-and-tls-profiles 
will be blocked from publication.

Proposal: remove any mention of draft-ietf-dprive-dnsodtls from 
draft-ietf-dprive-dtls-and-tls-profiles. When (if?) 
draft-ietf-dprive-dnsodtls goes through WG Last Call, it can have a 
paragraph that says that the RFC that 
draft-ietf-dprive-dtls-and-tls-profiles has become applies to it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 24 Jul 2016 20:43:42 +0200

On Sat, Jul 23, 2016 at 08:51:43AM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 46 lines which said:

> Proposed replacement: [...] The negative implications of the two
> types of privacy are so radically different (a possibly-unusable
> Internet service for Strict Privacy; complete control of DNS
> responses for Opportunistic Privacy) that neither option can be
> considered a good default for all users.

The current default is worse than opportunistic privacy, it is no
privacy at all. So, I would say that opportunistic privacy is a
reasonable default for a new installation of DNS-over-TLS. (It's also
the only one realistic since strict privacy would probably require
some sort of configuration, that cannot be pre-determined.)

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 24 Jul 2016 12:24:50 -0700

> some sort of configuration, that cannot be pre-determined.)

Very good point, and my quote above should not have been focused on just 
the two types. New proposed wording to be added to the one above:

However, a system SHOULD offer at least a default option of 
opportunistic privacy instead of no option for privacy at all.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 24 Jul 2016 21:56:46 +0200

On Sun, Jul 24, 2016 at 12:24:50PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 25 lines which said:

> New proposed wording to be added to the one above:
> 
> However, a system SHOULD offer at least a default option of opportunistic
> privacy instead of no option for privacy at all.

OK for me (your test + this addition).

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 25 Jul 2016 04:07:32 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of Paul
> Hoffman
> Sent: Saturday, July 23, 2016 9:22 PM
> To: [email-masked]
> Subject: [dns-privacy] Review of draft-ietf-dprive-dtls-and-tls-profiles-03
> 
> Strict Privacy is only preferable to users who would rather have an unusable
> Internet connection: an Internet connection where every DNS lookup in every
> application fails. Currently, that size of that set of users is incredibly small,
> although it might grow over time. The sentence above could lead developers
> to implement Strict Privacy without also implementing Opportunistic Privacy
> to the detriment of the vast majority of current Internet users.
> 
> Proposed replacement:
>     Strict Privacy provides the strongest privacy guarantees and therefore
> should always be implemented along with Opportunistic Privacy.
> The negative implications of the two types of privacy are so radically different
> (a possibly-unusable Internet service for Strict Privacy; complete control of
> DNS responses for Opportunistic Privacy) that neither option can be
> I have a significant concern about the discussion of draft-ietf-dprive-dnsodtls,
> which is listed as an informational reference. That document seems to be
> stalled again, which is unfortunate. 

Update to draft-ietf-dprive-dnsodtls was published recently to address the comments from the WG.
Draft looks ready for WGLC.

-Tiru

> If, during IETF review, someone insists that
> the DTLS document is in fact a normative reference (which would make sense
> if that document were finished), draft-ietf-dprive-dtls-and-tls-profiles
> Proposal: remove any mention of draft-ietf-dprive-dnsodtls from draft-ietf-
> dprive-dtls-and-tls-profiles. When (if?) draft-ietf-dprive-dnsodtls goes through
> WG Last Call, it can have a paragraph that says that the RFC that draft-ietf-
> dprive-dtls-and-tls-profiles has become applies to it.
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 28 Jul 2016 13:14:35 +0100

> On 24 Jul 2016, at 20:24, Paul Hoffman <[email-masked]> wrote:
> 
> Very good point, and my quote above should not have been focused on just the two types. New proposed wording to be added to the one above:
> 
> However, a system SHOULD offer at least a default option of opportunistic privacy instead of no option for privacy at all.

Hi Paul/Stephane, 

Thanks for these very good points. 

After the discussion in the WG at IETF 95, we added the last paragraph in section 4.1 to explicitly avoid any detailed of when to use what profile because there was some consensus that this was too complex to give a simple answer to and the situation could change over time, and that instead this should be addresses in a separate (BCP) document. But clear text no longer being the default for a Privacy capable client seems correct here though. How about this wording, which I hope covers your points:

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

Sara.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 28 Jul 2016 14:33:48 +0200

Sara Dickinson writes:

 > 
 > --===============2811901052251580029==
 > Content-Type: multipart/alternative;
 >  boundary="Apple-Mail=_F234D728-73AE-4122-ABCB-5C9595DA36B9"
 > 
 > 
 > --Apple-Mail=_F234D728-73AE-4122-ABCB-5C9595DA36B9
 > Content-Transfer-Encoding: quoted-printable
 > Content-Type: text/plain;
 > 	charset=utf-8
 > 
 > >=20
 > >=20
 > >>=20
 > >>=20
 > >=20
 > > Very good point, and my quote above should not have been focused on =
 > just the two types. New proposed wording to be added to the one above:
 > >=20
 > > However, a system SHOULD offer at least a default option of =
 > Hi Paul/Stephane,=20
 > Thanks for these very good points.=20
 > 
 > After the discussion in the WG at IETF 95, we added the last paragraph =
 > in section 4.1 to explicitly avoid any detailed of when to use what =
 > profile because there was some consensus that this was too complex to =
 > give a simple answer to and the situation could change over time, and =
 > that instead this should be addresses in a separate (BCP) document. But =
 > clear text no longer being the default for a Privacy capable client =
 > seems correct here though. How about this wording, which I hope covers =
 > your points:
 > 
 > =E2=80=9CStrict 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).=20
 > 
 > The choice between the two profiles depends on a number of factors =
 > including which is more important to the particular client:
 > =E2=80=94  DNS service at the cost of no privacy guarantee =
 > (Opportunistic) or
 > =E2=80=94  guaranteed privacy at the potential cost of no DNS service =
 > (Strict).=20
 > 
 >    server capabilities therefore DNS clients will need to carefully =
 > select which
 >    profile to use based on their communication privacy needs.=20
 > 
 > 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). =E2=80=9C
 > 
 > Sara.=20=
 > 
 > --Apple-Mail=_F234D728-73AE-4122-ABCB-5C9595DA36B9
 > Content-Transfer-Encoding: quoted-printable
 > Content-Type: text/html;
 > 	charset=utf-8
 > 
 > <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
 > charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
 > -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
 > class=3D""><blockquote type=3D"cite" class=3D"">On 24 Jul 2016, at =
 > 20:24, Paul Hoffman &lt;<a href=3D"mailto:[email-masked]" =
 > class=3D"">[email-masked]</a>&gt; =
 > wrote:</blockquote><div><blockquote type=3D"cite" class=3D""><br =
 > class=3D""><div class=3D""><div class=3D"">On 24 Jul 2016, at 11:43, =
 > Stephane Bortzmeyer wrote:<br class=3D""><br class=3D""><blockquote =
 > type=3D"cite" class=3D"">On Sat, Jul 23, 2016 at 08:51:43AM -0700,<br =
 > class=3D""> Paul Hoffman &lt;<a href=3D"mailto:[email-masked]" =
 > class=3D"">[email-masked]</a>&gt; wrote<br class=3D""> a message =
 > of 46 lines which said:<br class=3D""><br class=3D""><blockquote =
 > type=3D"cite" class=3D"">Proposed replacement: [...] The negative =
 > implications of the two<br class=3D"">types of privacy are so radically =
 > different (a possibly-unusable<br class=3D"">Internet service for Strict =
 > Privacy; complete control of DNS<br class=3D"">responses for =
 > Opportunistic Privacy) that neither option can be<br class=3D"">considered=
 >  a good default for all users.<br class=3D""></blockquote><br =
 > class=3D"">The current default is worse than opportunistic privacy, it =
 > is no<br class=3D"">privacy at all. So, I would say that opportunistic =
 > privacy is a<br class=3D"">reasonable default for a new installation of =
 > DNS-over-TLS. (It's also<br class=3D"">the only one realistic since =
 > strict privacy would probably require<br class=3D"">some sort of =
 > configuration, that cannot be pre-determined.)<br =
 > class=3D""></blockquote><br class=3D"">Very good point, and my quote =
 > above should not have been focused on just the two types. New proposed =
 > wording to be added to the one above:<br class=3D""><br =
 > class=3D"">However, a system SHOULD offer at least a default option of =
 > opportunistic privacy instead of no option for privacy at all.<br =
 > class=3D""></div></div></blockquote></div><br class=3D""><div =
 > class=3D"">Hi Paul/Stephane,&nbsp;</div><div class=3D""><br =
 > class=3D""></div><div class=3D"">Thanks for these very good =
 > points.&nbsp;</div><div class=3D""><br class=3D""></div><div =
 > class=3D"">After the discussion in the WG at IETF 95, we added the last =
 > paragraph in section 4.1 to explicitly avoid any detailed of when to use =
 > what profile because there was some consensus that this was too complex =
 > to give a simple answer to and the situation could change over time, and =
 > that instead this should be addresses in a separate (BCP) document. But =
 > clear text no longer being the default for a Privacy capable client =
 > seems correct here though. How about this wording, which I hope covers =
 > your points:</div><div class=3D""><br class=3D""></div><div =
 > class=3D"">=E2=80=9CStrict Privacy provides the strongest privacy =
 > guarantees and therefore SHOULD always be implemented in DNS clients =
 > along with Opportunistic Privacy.</div><div class=3D""><br =
 > class=3D""></div><div class=3D""><pre class=3D"newpage" =
 > style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; =
 > font-variant-ligatures: normal; line-height: normal; orphans: 2; widows: =
 > 2;"><font face=3D"Helvetica" style=3D"font-size: 13.3333px;" class=3D"">A =
 > DNS client that implements DNS-over-(D)TLS SHOULD NOT default to the use =
 > of clear text (no privacy).&nbsp;</font></pre><pre class=3D"newpage" =
 > style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; =
 > font-variant-ligatures: normal; line-height: normal; orphans: 2; widows: =
 > 2;"><span style=3D"font-size: 13.3333px;" class=3D""><font =
 > face=3D"Helvetica" class=3D""><br class=3D""></font></span></pre><pre =
 > class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; =
 > font-variant-ligatures: normal; line-height: normal; orphans: 2; widows: =
 > 2;"><font face=3D"Helvetica" class=3D""><font size=3D"2" class=3D"">The =
 > choice between the two profiles depends on a number of </font>factors =
 > including <font size=3D"2" class=3D"">which is more important to the =
 > particular client:</font></font></pre><pre class=3D"newpage" =
 > style=3D"margin-top: 0px; margin-bottom: 0px; font-variant-ligatures: =
 > normal; line-height: normal; orphans: 2; widows: 2;"><font =
 > face=3D"Helvetica" class=3D""><font size=3D"2" class=3D"">=E2=80=94  DNS =
 > service at the cost of no privacy </font>guarantee<font size=3D"2" =
 > class=3D""> (Opportunistic) or</font></font></pre><pre class=3D"newpage" =
 > style=3D"margin-top: 0px; margin-bottom: 0px; font-variant-ligatures: =
 > normal; line-height: normal; orphans: 2; widows: 2;"><font =
 > face=3D"Helvetica" class=3D""><font size=3D"2" class=3D"">=E2=80=94  =
 > guaranteed privacy at the potential cost of no DNS service =
 > (Strict).&nbsp;</font></font></pre><pre class=3D"newpage" =
 > style=3D"margin-top: 0px; margin-bottom: 0px; font-variant-ligatures: =
 > normal; line-height: normal; orphans: 2; widows: 2;"><font =
 > face=3D"Helvetica" class=3D""><font size=3D"2" class=3D""><br =
 > class=3D""></font></font></pre><pre class=3D"newpage" style=3D"margin-top:=
 >  0px; margin-bottom: 0px; font-variant-ligatures: normal; line-height: =
 > normal; orphans: 2; widows: 2;"><font face=3D"Helvetica" class=3D""><font =
 > size=3D"2" class=3D"">Additionally the two profiles require varying =
 > levels of
 >    server capabilities therefore DNS clients will need to carefully =
 > select which
 >    profile to use based on their communication privacy =
 > needs.&nbsp;</font></font></pre><pre class=3D"newpage" =
 > style=3D"margin-top: 0px; margin-bottom: 0px; font-variant-ligatures: =
 > normal; line-height: normal; orphans: 2; widows: 2;"><font =
 > face=3D"Helvetica" class=3D""><br class=3D""></font></pre><pre =
 > class=3D"newpage" style=3D"margin-top: 0px; margin-bottom: 0px; =
 > font-variant-ligatures: normal; line-height: normal; orphans: 2; widows: =
 > 2;"><font face=3D"Helvetica" class=3D"">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). </font><span style=3D"font-family: Helvetica;" =
 > class=3D"">=E2=80=9C</span></pre><pre class=3D"newpage" =
 > style=3D"margin-top: 0px; margin-bottom: 0px; font-variant-ligatures: =
 > normal; line-height: normal; orphans: 2; widows: 2;"><span =
 > style=3D"font-size: 13.3333px;" class=3D""><font face=3D"Helvetica" =
 > class=3D""><br class=3D""></font></span></pre><pre class=3D"newpage" =
 > style=3D"margin-top: 0px; margin-bottom: 0px; font-variant-ligatures: =
 > normal; line-height: normal; orphans: 2; widows: 2;"><span =
 > style=3D"font-size: 13.3333px;" class=3D""><font face=3D"Helvetica" =
 > class=3D"">Sara. </font></span></pre></div></body></html>=
 > 
 > --Apple-Mail=_F234D728-73AE-4122-ABCB-5C9595DA36B9--
 > 
 > 
 > --===============2811901052251580029==
 > Content-Type: text/plain; charset="us-ascii"
 > MIME-Version: 1.0
 > Content-Transfer-Encoding: 7bit
 > Content-Disposition: inline
 > 
 > --===============2811901052251580029==--