Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dtls-and-tls-profiles-03.txt

From: [email-masked]
Date: Fri, 08 Jul 2016 09:35:44 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange of the IETF.

        Title           : Authentication and (D)TLS Profile for DNS-over-(D)TLS
        Authors         : Sara Dickinson
                          Daniel Kahn Gillmor
                          Tirumaleswar Reddy
	Filename        : draft-ietf-dprive-dtls-and-tls-profiles-03.txt
	Pages           : 21
	Date            : 2016-07-08

Abstract:
   This document describes how a DNS client can use a domain name to
   authenticate a DNS server that uses Transport Layer Security (TLS)
   and Datagram TLS (DTLS).  Additionally, it defines (D)TLS profiles
   for DNS clients and servers implementing DNS-over-TLS and DNS-over-
   DTLS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dtls-and-tls-profiles-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 8 Jul 2016 17:37:55 +0100

Hi All, 

This is a minor update which adds some additional text to section 9.2 on the use of DANE. 

Regards

Sara. 

> On 8 Jul 2016, at 17:35, [email-masked] wrote:
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 20 Jul 2016 10:25:01 +0200

All,

I know everyone wants to work on the Next Thing, but we'd like to get 
some reviews of this draft.  The chairs are hoping to have this in WGLC 
before the next meeting.

thanks
tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 21 Jul 2016 17:06:42 +0200

On Fri, Jul 08, 2016 at 05:37:55PM +0100,
 Sara Dickinson <[email-masked]> wrote 

> This is a minor update which adds some additional text to section

Summary: IMHO, ready for WGLC

A few questions:

Technical :

4.2 : in the Figure 2, I have a doubt about the last line
(opportunistic profile, clear text). It shows that it offers no
protection against a passive or active attacker (OK), but has a D
(detection possible). How do you detect a sniffer? (This table
appeared in -02. The previous table, in -01, did not mention this
possibility of detection.) I vaguely remember discussions about that
in Buenos Aires but I cannot be sure: it may indicate there is a need
for more explanations, for instance in section 5.

9.2.1 "The DNS queries for such DANE records MAY use opportunistic
encryption or be in the clear[I would add a comma here] to avoid trust
recursion" Why mentioning "in the clear"? When is it useful? If you
cannot authenticate, opportunistic encryption is still better (or, at
the minimum, not worse) than in the clear.

[It cannot be because the resolver does not support TLS-over-DNS
because, in that case, retrieving certificates with DANE would be
pointless.]

Editorial :

9.2 "DANE [RFC6698] provides mechanisms to root certificate and raw
public key trust with DNSSEC" My english is too limited, I did not
know this use of "to root". Is it common?

---

From: Sara Dickinson <[email-masked]>
Date: Fri, 22 Jul 2016 15:35:10 +0200

> On 21 Jul 2016, at 17:06, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Hi Stephane,

> Summary: IMHO, ready for WGLC

Thanks for the review. 

> for more explanations, for instance in section 5.

I meant to add text for this (because, yes, it has come up before) and forgot - thanks for reminding me.

One example of ‘detecting’ an attack is where a name server that has previously provided DNS-over-TLS suddenly stops (e.g TLS handshakes fail). The Opportunistic client can choose to switch to TCP to continue to get DNS service but it should assume it has detected an attack (even if the reality is just a bad config change). 

> the minimum, not worse) than in the clear.

Well, latency might be one reason because the client might have to wait a timeout to determine if the server supports TLS…. (but see below)

> because, in that case, retrieving certificates with DANE would be

However (on first use) the client may not know the services the nameserver offers, it must ‘discover' them. 

How about "SHOULD use opportunistic encryption but MAY use clear text (for example, if latency is a concern).”? 

> know this use of "to root". Is it common?

It makes sense to me but I can see the potential confusion - will re-word. 

Sara.