Subject: [dns-privacy] Call for Adoption: draft-dgr-dprive-dtls-and-tls-profiles

From: Tim Wicinski <[email-masked]>
Date: Tue, 12 Jan 2016 16:56:39 -0500

The chairs realized earlier today that we encouraged this draft to be 
created, but once it was, we forgot to start a formal Call for Adoption. 
  With the feedback already, this document looks ready for adoption and 
being worked on.

This starts a Call for Adoption for draft-dgr-dprive-dtls-and-tls-profiles

The draft is available here: 
https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-profiles/

Please review this draft to see if you think it is suitable for adoption 
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends 26 January 2016

Thanks,
tim wicinski
DPRIVE co-chair

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Jan 2016 17:29:50 +0100

On Tue, Jan 12, 2016 at 04:56:39PM -0500,
 Tim Wicinski <[email-masked]> wrote 
 a message of 25 lines which said:

> Please review this draft to see if you think it is suitable for adoption by
> DPRIVE, and comments to the list, clearly stating your view.

I've read the draft, I think the general idea (having profiles
separated from the two protocols, TLD and DTLS) is sound, IMHO, the
draft is still too difficult to read (the terminology would need some
strictening) but it can be solved. I volunteer for review, also.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 14 Jan 2016 11:07:14 -0800

At Tue, 12 Jan 2016 16:56:39 -0500,

> by DPRIVE, and comments to the list, clearly stating your view.

I support the adoption.

Some initial comments on the 00 version follow:

- Section 4.2

      +-----------------------+------------------+-----------------+
      |     Usage Profile     | Passive Attacker | Active Attacker |
      +-----------------------+------------------+-----------------+
      |       No Privacy      |        N         |        N        |
      | Opportunistic Privacy |        P         |      N (D)      |
      |     Strict Privacy    |        P         |        P        |
      +-----------------------+------------------+-----------------+

How can we detect an active attack in Opportunistic Privacy?  For
example, if an active attacker pretends to be the recursive server
that just doesn't support privacy, can't we distinguish it from a
genuine server that actually doesn't support it?  Perhaps it's
described in the following part of Section 5:

   [...]  This is useful for
   detecting (but not preventing) active attack, and for debugging or
   diagnostic purposes if there are means to report the result of the
   authentication attempt.

but it's still not very clear to me.

Editorial matters:

- Section 4.2: s/section Section/Section/

      is discussed in section Section 5

- Section 6: '[dnssec-trigger]' isn't included in the references sections.

   [...]  Techniques such as those used by DNSSEC-trigger [dnssec-
   trigger] MAY be used during network configuration, with the intent to

- Section 8.3: s/purse/pursue/ ? (If it's really 'purse' I don't
  understand what it means...)

   [QUESTION: The authors would like to solicit feedback on the use of
   DHCP to determine whether to purse a new DHCP option in a later
   version of this draft, or defer it.]

--
JINMEI, Tatuya

---

From: Shumon Huque <[email-masked]>
Date: Thu, 14 Jan 2016 22:00:51 -0500

On Tue, Jan 12, 2016 at 4:56 PM, Tim Wicinski <[email-masked]> wrote:

> With the feedback already, this document looks ready for adoption and being
> worked on.
>
I support adoption of this draft. I've reviewed many details of the current
draft with the authors directly in private communication. And offer to
continue reviewing, and/or
contributing text.

-- 
Shumon Huque

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 18 Jan 2016 11:28:56 +0000

> On 14 Jan 2016, at 19:07, 神明達哉 <[email-masked]> wrote:
> I support the adoption.

Thanks for the review.

> Some initial comments on the 00 version follow:

Yes you are correct this section touches on the issue. The scenario where detection is possible is if a client is configured with either a domain name or SPKI pinset for a given server then the expectation is that the server _is_ a DNS privacy enabling server. So if the authentication fails in Strict Privacy the connection is aborted. However in Opportunistic Privacy the client can choose to connect anyway, but it is aware that the server does not authenticate and so it should consider an active attack in progress (worst case - of course it could be a config error…).

We plan to update the discussion of Opportunistic Privacy in the next version - thanks for this comment.  

>   trigger] MAY be used during network configuration, with the intent to

Thanks - will fix. 

>   version of this draft, or defer it.]

Ah! Yes this should be pursue! 

Sara.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 18 Jan 2016 11:36:50 -0800

At Mon, 18 Jan 2016 11:28:56 +0000,

> Yes you are correct this section touches on the issue. The scenario where detection is possible is if a client is configured with either a domain name or SPKI pinset for a given server then the exp…

Maybe it's just a matter of wording, but this doesn't really sound
like "Detection" to me, in that the client can't (100%) know if it's
an attack or not (that's the same for Strict Privacy, but we can
surely say it provides "Protection" in that case due to its hard-fail
nature).  But...

> We plan to update the discussion of Opportunistic Privacy in the next version - thanks for this comment.

...since this may be a wording issue, I'll see how the revised version
reads.

--
JINMEI, Tatuya

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 21 Jan 2016 21:11:55 -0800

On 12-Jan-2016 01:56 pm, Tim Wicinski <[email-masked]> wrote:
> 
> The chairs realized earlier today that we encouraged this draft to be created, but once it was, we forgot to start a formal Call for Adoption.  With the feedback already, this document looks ready for adoption and being worked on.
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-dgr-dprive-dtls-and-tls-profiles/
> 
> Please review this draft to see if you think it is suitable for adoption by DPRIVE, and comments to the list, clearly stating your view.

It should be adopted as a WG document.

> Please also indicate if you are willing to contribute text, review, etc.

I am willing to review.

-d

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

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 23 Jan 2016 23:13:47 -0800

On Thursday, January 21, 2016 9:12 PM, Dan Wing wrote
> > ...

I believe that too. I also believe that the document will benefit from
reviews and comments.

> > Please also indicate if you are willing to contribute text, review, etc.

Me too.

When I read the current draft, I found too issues that will hopefully be
fixed in the next revisions.

The first issue is the deployment model. I believe that a very common model
will be the connection by client hosts to a trusted recursive resolver. One
has to "read between the lines" of the current draft to find how the
considerations apply to this model. I wish we could have a more explicit
discussion of that scenario.

The other issue is the interaction with "firewall policies" in common use in
enterprise networks. These policies include making internal sites available
to hosts behind the firewall, but not outside it. They also commonly include
barring access to a variety of "not safe for work" domains. Encrypted
connections to a DNS server could traverse these firewalls, and bypass these
policy controls. The issue is documented in CERT Alert (TA15-240A),
"Controlling Outbound DNS Access,"
https://www.us-cert.gov/ncas/alerts/TA15-240A. We should address it.

-- Christian Huitema

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 26 Jan 2016 05:50:32 +0000

>by DPRIVE, and comments to the list, clearly stating your view.

I support adoption of the draft.

-Prashanth

---

From: Warren Kumari <[email-masked]>
Date: Wed, 27 Jan 2016 04:32:02 +0000

Dear authors,

We see consensus to adopt this document.

Please resubmit as draft-ietf-dprive-dtls-and-tls-profies.

Also, thanks to the WG for review and feedback.
W