Subject: Re: [dns-privacy] review of draft-ietf-dprive-dns-over-tls

From: "John Levine" <[email-masked]>
Date: 2 Oct 2015 04:21:33 -0000

I think it's in pretty good shape but of course I have a few questions.

In 3.3, it says to match queries and responses "using the ID field and
port number".  I get the ID field, but the port number?  In a TCP
session?  This language appears to be copied from 5966bis, where it
seems to have been copied by mistake from something that was talking
about UDP.  It's not in RFC 5966.

In the opportunistic privacy profiles in 4.1, why wouldn't you want to
use opportunistic TLS when talking to an authoritative server the same
as you would talking to a cache?  The example suggests it only applies
to caches.

In the security considerations, item 3 appears to be left over from
the STARTTLS version.  If the handshake happens at the beginning, how
could there be protocol interactions prior to the handshake?

R's,
John

---

From: 神明達哉 <[email-masked]>
Date: Fri, 2 Oct 2015 11:23:56 -0700

At Wed, 23 Sep 2015 10:32:05 -0400,
Warren Kumari <[email-masked]> wrote:

> Please review our documents:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/

I've reviewed the 00 version of draft-ietf-dprive-dns-over-tls.  I
didn't see any substantial issues, so it seems to me almost ready to
ship.  (But I don't think I can claim to be a TCP or TLS or security
expert, so my review is more or less superficial anyway).

For the record I agreed with what Stephane Bortzmeyer complained about
in his review.

I have a couple of more minor comments and one editorial nit:

- Section 3.3

   For reasons of efficiency, DNS clients and servers SHOULD
   transmit the two-octet length field, and the message described by
   that length field, in a single TCP segment ([I-D.ietf-dnsop-5966bis],
   Section 8).

  I pointed out that 'in a single TCP segment' is not realistic for my
  review on 5966bis, and in my understanding this sentence has been
  revised.  This draft will also have to make corresponding updates.

- Section 4.2

   Methods for pre-deployment of the designated DNS provider are outside
   the scope of this document.  In corporate settings, such information
   may be provided at system installation, for instance within the
   authenticated DHCP exchange [RFC3118].

  In my understanding no one ever seriously used RFC3118 (or
  RFC3315)-style DHCP authentication.  In fact, the dhc wg is now even
  going to deprecate the original RFC3315-based authentication in a
  bis document.  So, even with 'for instance', referring to this
  particular authentication mechanism seems to be too unrealistic.  If
  there's a better and more practical example (which I don't know), I
  suggest replacing the example with that one; otherwise, I'd rather
  suggest removing the "for instance...[RFC3118]'.

- Section 9: a minor nit: s/be//?

   2.  Middleboxes [RFC3234] are be present in some networks and have

--
JINMEI, Tatuya

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 5 Oct 2015 11:57:43 +0200

On Fri, Oct 02, 2015 at 04:21:33AM -0000,
 John Levine <[email-masked]> wrote 
 a message of 24 lines which said:

> In 3.3, it says to match queries and responses "using the ID field
> and port number".  I get the ID field, but the port number?  In a
> TCP session?

This point was raised in
<http://mailarchive.ietf.org/arch/msg/dns-privacy/FGofF8JBv-WM86iasrqf1mCyE2w>
and handled in
<http://mailarchive.ietf.org/arch/msg/dns-privacy/msPmsO-bSNE6zTAteVNn-nD5OTc>

---

From: "John R Levine" <[email-masked]>
Date: 5 Oct 2015 10:09:53 -0400

> <http://mailarchive.ietf.org/arch/msg/dns-privacy/msPmsO-bSNE6zTAteVNn-nD5OTc>

Hm, must be this one but you're right, it's fixed, never mind.

https://mailarchive.ietf.org/arch/msg/dns-privacy/TVlUMfG2CqMN4qPPLKaGaEfoOO0

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2015 22:00:26 +0000

> On Sep 30, 2015, at 5:05 PM, Watson Ladd <[email-masked]> wrote:
> 
> On Wed, Sep 23, 2015 at 10:32 AM, Warren Kumari <[email-masked]> wrote:
>> Hi all,
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/
>> 
>> We would like to see a significant amount of review and discussion before
>> our meeting in Yokohama - if not it is hard to justify the meeting time.
>> 
>> I put in the request for early port allocation few days back...
> 
> Is "pining" really the right term for recording which resolvers
> support DNS? When I've seen pinning used it has been in the context of
> certificates, with pining involving remembering which certificate was
> used.

Watson,

I think that is a fair point and I've made the following change:

@@ -787,8 +787,8 @@
             Clients and
             servers MUST adhere to the TLS implementation recommendations
             and security considerations of <xref target="RFC7525"/>.
-            DNS clients keeping track of servers known to support TLS (i.e.,
-            "pinning") enables clients to detect downgrade attacks.
+            DNS clients keeping track of servers known to support TLS
+            enables clients to detect downgrade attacks.
             For servers with no connection history and no apparent
             support for TLS, clients depending on their Privacy
             Profile and privacy requirements may choose to (a) try another server when

> We don't seem to have a good deal to say about authenticating DNS resolvers.

Yes, and we are acknowledging such as out of scope for this document.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2015 22:09:08 +0000

> On Oct 2, 2015, at 11:23 AM, 神明達哉 <[email-masked]> wrote:
> 

Thanks, this has been updated:

@@ -380,7 +380,10 @@
           <xref target="RFC1035"/>.
           For reasons of efficiency, DNS clients and servers SHOULD
           transmit the two-octet length field, and the message
-          described by that length field, in a single TCP segment
+          described by that length field, to the TCP layer at the
+          same time (e.g., in a single "write" system call) to make
+          it more likely that all the data will be transmitted in
+          a single TCP segment
           (<xref target="I-D.ietf-dnsop-5966bis"/>, Section 8).

>  suggest removing the "for instance...[RFC3118]'.

Fine with me and not hearing any other comments, I've removed it as you
suggested:

@@ -543,8 +545,7 @@
         <t>
           Methods for pre-deployment of the designated DNS provider are
           outside the scope of this document.  In corporate settings,
-          such information may be provided at system installation, for instance within
-          the authenticated DHCP exchange <xref target="RFC3118"/>. 
+          such information may be provided at system installation.

>   2.  Middleboxes [RFC3234] are be present in some networks and have

Thanks!

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2015 22:31:14 +0000

John,

> On Oct 1, 2015, at 9:21 PM, John Levine <[email-masked]> wrote:
> 

Already fixed, as you already know...

> as you would talking to a cache?  The example suggests it only applies

Because the working group is focused on stub-to-recursive that is what
the document authors focused on as well.  

> could there be protocol interactions prior to the handshake?

Here's the text:

3.  Any protocol interactions prior to the TLS handshake are
       performed in the clear and can be modified by a person-in-the-
       middle attacker.  For this reason, clients MAY discard cached
       information about server capabilities advertised prior to the
       start of the TLS handshake.

The authors debated about leaving this in or taking it out.

The argument for leaving it is that a client might not use TLS
immediately, for whatever reason.  If it performs normal queries
before using TLS then the client might want to discard anything it
learned about servers.  That might include RTT estimates, EDNS support, etc.

If there is consensus that its better to remove that paragraph, we would
be happy to do so.

DW

---

From: "John R Levine" <[email-masked]>
Date: 9 Oct 2015 18:44:33 -0400

> learned about servers.  That might include RTT estimates, EDNS support, etc.

If the TLS stuff is on a separate port that only does TLS, what could 
possibly happen before the TLS handshake?

Regards,

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 9 Oct 2015 22:54:10 +0000

> On Oct 9, 2015, at 3:44 PM, John R Levine <[email-masked]> wrote:
> 
>> Here's the text:
>> 
> If the TLS stuff is on a separate port that only does TLS, what could possibly happen before the TLS handshake?

I'm suggesting that a query/response on port 53 might happen prior to TLS.

DW

---

From: "John R Levine" <[email-masked]>
Date: 9 Oct 2015 19:33:14 -0400

> I'm suggesting that a query/response on port 53 might happen prior to TLS.

Oh, OK.  It'd help if the text mentioned that.

Regards,

---

From: "Wessels, Duane" <[email-masked]>
Date: Sat, 10 Oct 2015 05:07:58 +0000

> On Oct 9, 2015, at 4:33 PM, John R Levine <[email-masked]> wrote:
> 

John, how does this look to you?

-            Any protocol interactions prior to the TLS handshake are
-            performed in the clear and can be modified by a person-in-the-middle
-            attacker.  For this reason, clients MAY discard cached
+            Any DNS protocol interactions prior to the TLS handshake that are
+            performed in the clear can be modified by a person-in-the-middle
+            attacker.  For example, unencrypted queries and responses
+            might take place over port 53 between a client and server
+            prior to TLS.  For this reason, clients MAY discard cached
             information about server capabilities advertised prior to
             the start of the TLS handshake.

DW

---

From: "John R Levine" <[email-masked]>
Date: 10 Oct 2015 01:43:22 -0400

That's fine.  Thanks.

Regards,