Subject: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

From: Warren Kumari <[email-masked]>
Date: Thu, 22 Oct 2015 10:23:02 +0100

Dear DPRIVE WG,

The authors of draft-ietf-dprive-dns-over-tls-01 have indicated that
they believe that the document is ready, and have asked for Working
Group Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls-01/

Please review this draft to see if you think it is ready for
publication and send comments to the DPRIVE list, clearly stating your
view.

We have chosen to run this WGLC during the IETF meeting, and have it
end after the meeting. This will allow us use meeting time to discuss
contentious WGLC issues (if any).
This will be a 3 week WGLC, and ends Thu 12-Nov-2015.

To satisfy RFC 6702 ("Promoting Compliance with Intellectual Property
Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dprive-dns-over-tls-01?  If so, has this IPR been disclosed
in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and
5378 for more details.)

Thanks,
Warren Kumari
(as DPRIVE WG co-chair)

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Bob Harold <[email-masked]>
Date: Thu, 22 Oct 2015 13:59:01 -0400

> in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and

The URL is not working for me, and I cannot find a working URL.  Is it just
me?

-- 
Bob Harold

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 22 Oct 2015 19:03:30 +0100

Bob

https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/

is a working URL

thanks for pointing that out

tim

On 10/22/15 6:59 PM, Bob Harold wrote:
>
> On Thu, Oct 22, 2015 at 5:23 AM, Warren Kumari <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear DPRIVE WG,
>
> The URL is not working for me, and I cannot find a working URL.  Is it
> just me?
>
> --
> Bob Harold
>
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 22 Oct 2015 18:05:36 +0000

> On Oct 22, 2015, at 6:59 PM, Bob Harold <[email-masked]> wrote:
> 
> The URL is not working for me, and I cannot find a working URL.  Is it just me?

Try this:

---

From: Bob Harold <[email-masked]>
Date: Thu, 22 Oct 2015 14:11:45 -0400

On Thu, Oct 22, 2015 at 2:05 PM, Wessels, Duane <[email-masked]>
wrote:

> Thanks Tim and Duane, looks good to me.

-- 
Bob Harold

---

From: Warren Kumari <[email-masked]>
Date: Thu, 22 Oct 2015 20:37:59 +0100

Gaaaaah.

I have a script to generate these emails, and fixing it to remove the
-<version> from the URL is one of those niggling bugs that I keep meaning
to fix....
... and then forgetting...

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Oct 2015 14:35:29 +0200

> they believe that the document is ready, and have asked for Working

Hi.  I believe the document is in relatively good shape.  I have one
high level concern, and one concern with the document itself that is
related to the higher-level concern:

1) I believe it would be a mistake to publish this without synchronizing
the TLS-related aspects of DNS-over-TLS and DNS-over-DTLS.  The
documents solve roughly the same problem, with rougly the same
technology.  One important difference is how they approach
authentication of the peer in TLS.  Given the similarities of the
protocols and solutions, this seems like a recipe for implementation
frustration.  An implementer would prefer to implement DNS-over-TLS/DTLS
as similar as possible.  Having different X.509 (etc) certificate
verification code paths depending on whether TLS or DTLS is used appears
bad to me.

2) On TLS verification, this document should reference RFC 6125 and
describe how naming information should be compared with the locally
known data with what is being presented by the server.  See
draft-ietf-dprive-dnsodtls for one way (not necessarily the best one or
the most readable or complete way) of doing this.

If merging DNS-over-TLS and DNS-over-DTLS is not an option, another
possibility is that TLS-related aspects are deferred from both documents
to another third new document that describe how to perform TLS
credential verification for DNS-over-(D)TLS in a generalized way.  Then
there would be harmony in the TLS-related aspects, and the respective
document can focus on the DNS-related aspects.  If document editor
cycles is limiting factor, I would volunteer to help write this.

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 23 Oct 2015 16:10:07 +0300

On Fri, Oct 23, 2015 at 02:35:29PM +0200, Simon Josefsson wrote:
> technology. 
> credential verification for DNS-over-(D)TLS in a generalized way.

Agreed. Furthermore, I think that the (D)TLS profiling aspects should
be merged too (TLS and DTLS are virtually[1] the same here).

[1] IIRC, pretty much the only difference is RC4: Doesn't work at all
in DTLS, forbidden in TLS.

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 23 Oct 2015 14:31:15 +0000

>cycles is limiting factor, I would volunteer to help write this.

Fully agree on all counts. If the WG wants to move both -TLS and -DTLS to
the IETF, it makes no sense at all to have them have different crypto
properties. I don't care if the answer is "harmonize each before
finishing" or "harmonize them by reference to a third document".

--Paul Hoffman

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 23 Oct 2015 13:59:35 -0700

> finishing" or "harmonize them by reference to a third document".

+1.

-d

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 25 Oct 2015 16:23:07 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of Paul
> Hoffman
> Sent: Friday, October 23, 2015 8:01 PM
> To: Simon Josefsson
> Cc: [email-masked]
> Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01
> 
> >1) I believe it would be a mistake to publish this without
> >synchronizing the TLS-related aspects of DNS-over-TLS and
> >DNS-over-DTLS.  The documents solve roughly the same problem, with
> >rougly the same technology.  One important difference is how they
> >approach authentication of the peer in TLS.  Given the similarities of
> >the protocols and solutions, this seems like a recipe for
> >implementation frustration.  An implementer would prefer to implement
> >DNS-over-TLS/DTLS as similar as possible.  Having different X.509 (etc)
> >certificate verification code paths depending on whether TLS or DTLS is
> >used appears bad to me.
> >
> >possibility is that TLS-related aspects are deferred from both
> >documents to another third new document that describe how to perform
> >TLS credential verification for DNS-over-(D)TLS in a generalized way.
> >Then there would be harmony in the TLS-related aspects, and the
> >respective document can focus on the DNS-related aspects.  If document
> >editor cycles is limiting factor, I would volunteer to help write this.
> 
> Fully agree on all counts. If the WG wants to move both -TLS and -DTLS to the
> IETF, it makes no sense at all to have them have different crypto properties. I
> don't care if the answer is "harmonize each before finishing" or "harmonize
> them by reference to a third document".

https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00 discusses both TLS and DTLS profile for providing DNS privacy.

-Tiru

---

From: Muhammad Yousaf <[email-masked]>
Date: Mon, 26 Oct 2015 14:28:08 +0000 (UTC)

Hi all, I am new to this list, infact read the document for the first time. So, don't know whether my comments will make any sense or not. My first feeling is that this document is proposing too much security overhead in the name of privacy protection. TCP Handshake -> TLS Handshake -> DNS Request/Reply -> TLS Close -> TCP Close.Although draft discussed the overhead, however, only discussion can't resolve the issue. Draft also discussed the long term persistant connections and associated security issues with this approach. Again discussion only is not the solution.Draft also discussed the queued requests and its issue. Again no satisfactory solution. Also, it is not clear that why we need to encrypt the traffic between recursive server and the authoritative server. What is the privacy issue there?If community is not in a hurry, then in my humble opinion, standard body should look for more efficient and well thought off solution may be out of TLS. I can volunteer for any such activity.   Best Regards,Dr. Muhammad Yousaf,Assistant Professor, Faculty of Computing, Riphah International University (RIU), Islamabadhttps://sites.google.com/site/muhyousaf/

-Tiru

---

From: 神明達哉 <[email-masked]>
Date: Mon, 26 Oct 2015 10:26:07 -0700

At Fri, 23 Oct 2015 14:31:15 +0000,
Paul Hoffman <[email-masked]> wrote:

> >the TLS-related aspects of DNS-over-TLS and DNS-over-DTLS.
[...]
> >known data with what is being presented by the server.
[...]
> finishing" or "harmonize them by reference to a third document".

I have some preliminary question about the 'If'.  I don't remember
exactly how the DNS/DTLS draft became a wg document, but IIRC when we
adopted DNS/TLS from several candidates the decision was to focus on
this particular solution while allowing flexibility of discussions
other ideas at a lower priority, so we can at least publish one
concrete solution document as soon as possible.  I have no problem of
discussing DNS/DTLS itself, but if my understanding about the wg focus
is correct, I don't think it a good idea to delay publishing DNS/TLS
because of it implication with DNS/DTLS.  In that sense merging these
two drafts doesn't seem to be a good idea to me.  Extracting and
deferring some parts of DNS/TLS may be acceptable if the resulting
DNS/TLS draft is still a self-contained document to be published.

--
JINMEI, Tatuya

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 26 Oct 2015 19:05:56 +0100

> DNS/TLS draft is still a self-contained document to be published.

Both DNS/TLS and DNS/DTLS were adopted by the WG, check the mailing list
archives.  In that light, I believe it make sense for them to be aligned
with each other.

/Simon

---

From: 神明達哉 <[email-masked]>
Date: Mon, 26 Oct 2015 11:24:24 -0700

At Mon, 26 Oct 2015 19:05:56 +0100,
Simon Josefsson <[email-masked]> wrote:

> archives.

I know DNS/TLS was adopted by the WG (was I unclear about that in my
previous message?).  My question was about the significance of the
adoption of DNS/DTLS, especially about whether DNS/DTLS should affect
the progress of DNS/TLS or whether we rather want the latter to be
published sooner as long as it's complete other than issues related to
DTLS interaction.

--
JINMEI, Tatuya

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 26 Oct 2015 17:27:06 -0700

On 26-Oct-2015 07:28 am, Muhammad Yousaf <[email-masked]> wrote: 
> Hi all, 
> I am new to this list, infact read the document for the first time. So, don't know whether my comments will make any sense or not. 
> My first feeling is that this document is proposing too much security overhead in the name of privacy protection. 
> TCP Handshake

TCP FastOpen (RFC7413), which would contain the TCP ClientHello

> -> TLS Handshake

Which would use TLS session resumption w/o server-side state (RFC5077), and TLS FalseStart (draft-ietf-tls-falsestart).

> -> DNS Request/Reply -> TLS Close -> TCP Close.

The TLS session and TCP connection don't need to be closed right away.  If left open, subsequent queries have nearly the same overhead as today's un-encrypted queries, and as long as the network is stable (NAT, firewall, path), DNSoTLS and DNSoDTLS are very similar in their operation.

> Although draft discussed the overhead, however, only discussion can't resolve the issue. 
> Draft also discussed the long term persistant connections and associated security issues with this approach. Again discussion only is not the solution.
> Draft also discussed the queued requests and its issue. Again no satisfactory solution. 
> Also, it is not clear that why we need to encrypt the traffic between recursive server and the authoritative server. What is the privacy issue there?

The risk is a victim querying a unique (or nearly unique) resource record), such as ejkfjuiuerekfjekfjekfjekjfejqkjkejqkj.example.com <http://ejkfjuiuerekfjekfjekfjekjfejqkjkejqkj.example.com/> (which might be completely unique to that particular user) or such as "kitten-pictures.blogspot.com <http://i-love-kittens.blogspot.com/>" (where kitten pictures are deemed subversive or are illegal).  Imagine that unique query combined with draft-ietf-dnsop-edns-client-subnet.

-d

> If community is not in a hurry, then in my humble opinion, standard body should look for more efficient and well thought off solution may be out of TLS. 
> I can volunteer for any such activity.  
>  
> Best Regards,
> Dr. Muhammad Yousaf,
> Assistant Professor, Faculty of Computing, 
> Riphah International University (RIU), Islamabad
> https://sites.google.com/site/muhyousaf/ <https://sites.google.com/site/muhyousaf/>
> 
> 
> 
> > From: dns-privacy [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Paul
> > Hoffman
> > Cc: [email-masked] <mailto:[email-masked]>
> > On 10/23/15, 1:35 PM, "Simon Josefsson" <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00  <https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00>discusses both TLS and DTLS profile for providing DNS privacy.
> 
> -Tiru
> 
> > 
> > --Paul Hoffman
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dns-privacy <https://www.ietf.org/mailman/listinfo/dns-privacy>
> 
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 27 Oct 2015 09:23:53 +0100

On Mon, Oct 26, 2015 at 02:28:08PM +0000,
 Muhammad Yousaf <[email-masked]> wrote 
 a message of 224 lines which said:

> I am new to this list,

Therefore I suggest that you read the other documents of the working
group first because some of them will answer to some of your
questions.

> TCP Handshake -> TLS Handshake -> DNS Request/Reply -> TLS Close ->
> TCP Close.

See Dan Wing's response (I agree with him and think it is well
described in the current draft). Also, draft-ietf-dnsop-5966bis, while
not from this working group, is a very recommended reading for
DNS-over-TLS-over-TCP.

> Also, it is not clear that why we need to encrypt the traffic
> between recursive server and the authoritative server. What is the
> privacy issue there?

It is described in RFC 7626.

---

From: sara <[email-masked]>
Date: Tue, 27 Oct 2015 09:51:56 +0000

> On 26 Oct 2015, at 17:26, 神明達哉 <[email-masked]> wrote:
> 
>  IIRC when we

I strongly agree with this position. I believe the working group should produce 3 documents here:

1) This draft - the technical discussion of DNS-over-TLS: I believe this document is mature enough to move forward as a standalone document (possibly with some minor re-working of section 5, to further clarify the scope with respect to authentication and add other references?). As detailed in the implementation section it also has several implementations. 

2) The technical discussion of DNS-over-DTLS: I believe that document is still under active review and development.

3) I agree there should be a separate document to describe further details of 'Authentication of DNS-over-(D)TLS connections’, and I am willing to work on that. 

I think this separation is the most pragmatic and flexible way to allowing the working group to deliver DNS Privacy in a timely fashion, without introducing unnecessary dependancies between the solutions. 

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Oct 2015 11:24:17 +0000

> From: dns-privacy [mailto:[email-masked]] On Behalf Of sara
> Sent: Tuesday, October 27, 2015 3:22 PM
> To: 神明達哉
> Cc: Simon Josefsson; Paul Hoffman; [email-masked]
> 1) This draft - the technical discussion of DNS-over-TLS: I believe this
> document is mature enough to move forward as a standalone document
> (possibly with some minor re-working of section 5, to further clarify the
> scope with respect to authentication and add other references?). As detailed
> in the implementation section it also has several implementations.
> 
> 3) I agree there should be a separate document to describe further details of
> 'Authentication of DNS-over-(D)TLS connections’, and I am willing to work on
> that.

Authenticating the DNS privacy server is discussed in https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-02#section-3.2 and is applicable for both TLS and DTLS.

-Tiru

> 
> I think this separation is the most pragmatic and flexible way to allowing the
> working group to deliver DNS Privacy in a timely fashion, without introducing
> unnecessary dependancies between the solutions.
> 
> Sara.

---

From: sara <[email-masked]>
Date: Tue, 27 Oct 2015 11:59:40 +0000

> On 27 Oct 2015, at 11:24, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

It does and I don’t think there is anything there which is incompatible with what is said about authenticating the server in section 5 of 
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls-01/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls-01/>

However section 2 of https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-02 clearly states “The scope of this document, however, is only UDP. “

I’m saying I think creating a separate document that specifically covers authentication for both TLS and DTLS makes most sense to me and will be clearer for consumers of the documents.

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Oct 2015 12:31:42 +0000

Inline [TR]

From: sara [mailto:[email-masked]]
Sent: Tuesday, October 27, 2015 5:30 PM
To: Tirumaleswar Reddy (tireddy)
Cc: 神明達哉; Simon Josefsson; Paul Hoffman; [email-masked]
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

On 27 Oct 2015, at 11:24, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

[TR] We can move this Section to https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00 and that will take care both (D)TLS profile for DNS privacy and authenticating the server.

-Tiru

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 27 Oct 2015 14:04:00 +0000

> On 27 Oct 2015, at 12:31, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
> [TR] We can move this Section to https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00 <https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00> and that will take care both (D)TLS profile for DNS privacy and authenticating the server.

I guess this is a decision for the working group since the DTLS draft is adopted, but the above document isn’t.

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Oct 2015 15:12:47 +0000

From: Sara Dickinson [mailto:[email-masked]]
Sent: Tuesday, October 27, 2015 7:34 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

On 27 Oct 2015, at 12:31, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

[TR] Yes, of course; will do that only after WG feedback and adoption of the draft.

-Tiru

Sara.

---

From: "Mankin, Allison" <[email-masked]>
Date: Tue, 27 Oct 2015 16:28:34 +0000

My two cents is that the authentication profile for TLS and DTLS should not be the same as a draft with flows. 

I reviewed the flows draft before it was submitted (and thank the authors for responding to initial comments).   Unsurprisingly, the flows draft is almost entirely made up of flows.  I estimate that many will have to change in response to DPRIVE WG review/discussion of the DTLS fragmentation scheme; also, some of them may need to change based on what is finalized for 1.3 in the TLS WG.  In keeping with other precedents at IETF, I’d see the flows draft as an informational document to help implementors/deployers.

The authentication profile for TLS/DTLS is something we can pull together now, with some work by the WG, and I’d expect it to be standards track.  I would not want to delay it for finishing the detailed engineering on the DTLS draft.

Bottom line:  I very much support Sara’s offer to start a stand-alone document for the authentication profile.  Speaking for the TLS authors, we’ll be happy to add language pointing ahead to an authentication profile external to our draft. 

Allison

.

> On Oct 27, 2015, at 11:12 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
>  
>  
> From: Sara Dickinson [mailto:[email-masked] <mailto:[email-masked]>] 
> On 27 Oct 2015, at 12:31, Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Oct 2015 17:32:01 +0000

Inline [TR]

From: Mankin, Allison [mailto:[email-masked]]
Sent: Tuesday, October 27, 2015 9:59 PM
To: Tirumaleswar Reddy (tireddy); Sara Dickinson
Cc: [email-masked]
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dns-over-tls-01

[TR] But this draft also discusses (D)TLS profile for DNS privacy and it cannot be made informational. However (D)TLS profile and authentication mechanism discussed in DTLS draft can be moved to a new draft and this draft can then just discuss flows with (D)TLS and can be made informational.

Bottom line:  I very much support Sara’s offer to start a stand-alone document for the authentication profile.

[TR] DNSoD already discusses authentication mechanism that can also be used for TLS. This new draft can pick text from DNSoD. This new draft should cover both authentication and (D)TLS profile. I can help with the text for this draft.

-Tiru

Speaking for the TLS authors, we’ll be happy to add language pointing ahead to an authentication profile external to our draft.

Allison

.

On Oct 27, 2015, at 11:12 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Cc: [email-masked]<mailto:[email-masked]>

-Tiru

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Oct 2015 15:06:37 +0100

On Thu, Oct 22, 2015 at 10:23:02AM +0100,
 Warren Kumari <[email-masked]> wrote 

> they believe that the document is ready, and have asked for Working

I'm one of the several persons who believe that we should delay WG
approval a bit to align DNS-over-TLS and DNS-over-DTLS, specially the
server authentication part (-01 does not even mention which field in
the cert to check).

For draft-ietf-dprive-dns-over-tls-01, I have the following remarks:

Abstract: "eliminates opportunties for eavesdropping". "Eliminates"
seem too strong. For instance, section 9, paragraph 4 explains you can
still get information by eavesdropping.

Section 3.3: the text in the last paragraph is now a bit different
from the one I-D.ietf-dnsop-5966bis. May be copy-and-paste the text
from 5966bis?

---

From: "Mankin, Allison" <[email-masked]>
Date: Thu, 29 Oct 2015 16:52:11 +0000

Hi Stephane,

What do you think of the idea of a separated out TLS and DTLS authentication draft that applies to both? There's a move afoot to submit one as soon as the draft window opens.

We will improve the authentication section in the TLS draft per your point below and/or thru pointing to the new draft.

There's something elusive about our attempts to get an exact match of language between 5966bis and the TLS draft - the authors overlap but we keep missing anyway. Thanks for observing* the current mismatch. We will align. 

Allison

[*] I hope the problem isn't Heisenberg uncertainty ;-)

Sent from my iPhone

> On Oct 29, 2015, at 12:04, Stephane Bortzmeyer <[email-masked]> wrote:
>