Subject: [dns-privacy] I-D Action: draft-ietf-dprive-start-tls-for-dns-01.txt

From: [email-masked]
Date: Sun, 05 Jul 2015 23:46:29 -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 Working Group of the IETF.

        Title           : TLS for DNS: Initiation and Performance Considerations
        Authors         : Zi Hu
                          Liang Zhu
                          John Heidemann
                          Allison Mankin
                          Duane Wessels
                          Paul Hoffman
	Filename        : draft-ietf-dprive-start-tls-for-dns-01.txt
	Pages           : 18
	Date            : 2015-07-05

Abstract:
   This document offers an approach to initiating TLS for DNS: use of a
   dedicated DNS-over-TLS port, and fallback to a mechanism for
   upgrading a DNS-over-TCP connection over the standard port (TCP/53)
   to a DNS-over-TLS connection.  Encryption provided by TLS eliminates
   opportunities for eavesdropping on DNS queries in the network, such
   as discussed in RFC 7258.  In addition it specifies two usage
   profiles for DNS-over-TLS.  Finally, it provides advice on
   performance considerations to minimize overheads from using TCP and
   TLS with DNS, pertaining to both approaches.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-start-tls-for-dns/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-start-tls-for-dns-01

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: "Wessels, Duane" <[email-masked]>
Date: Tue, 14 Jul 2015 04:58:03 +0000

> On Jul 5, 2015, at 11:46 PM, [email-masked] wrote:
> 
> 

Working group,

This updated internet draft was submitted last week.  Here are the substantive changes since
the -00 version:

- incorporated a number of suggestions and comments from Daniel Kahn Gillmor.
- removed a discussion question on utility of the TO in a UDP message.  There was no input from the working group on this point.
- when a client receives TO=0 in response to TO=1 query, they client MAY (was SHOULD) use the established
connection for unencrypted queries.
- clarify that when TLS handshake fails, both sides must close the connection.
- rewrote the "established connection" section
- this document no longer makes specific recommendations on idle timeouts.  It defers to other documents.
- added reference to TLS fast session resumption and mention of TLS false start work-in-progress.
- added an "implementation status" section

Also note that we added a discussion question on the need for both the upgrade-based (i.e. TO bit) approach
and the dedicated port approach.  If the working group feels that one approach is sufficient, this document
may be simplified.

We believe that this update addresses the working group's concerns and hope that the document can progress
to last call soon.

Duane W, on behalf of the draft authors

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Jul 2015 12:43:48 +0300

On Tue, Jul 14, 2015 at 04:58:03AM +0000, Wessels, Duane wrote:
> 
> We believe that this update addresses the working group's concerns
> and hope that the document can progress to last call soon.

I didn't see any discussion about requirements on TLS if any.

Given that this is a new service, running on a "fresh" port
(so no problems like HTTP/2 faced), one can set the bar
relatively high.

One problem with TLS is that there is no way to perform
TLS record padding without resorting to obsolete stuff with
known security issues (enough to trigger user-visible
warnings in Chrome) and not supported in TLS 1.3 (or yet
to be defined extensions). 

So if query/response padding is to be done (and I think it
does), it needs to be somehow done on DNS level.

Also, regarding pre-deployed profile, what names are the
certificate validated against (assuming it is not RPK
[RFC7250])? The name is stored in the same config as
the resolver IP and the pinned key?

-Ilari

---

From: Shumon Huque <[email-masked]>
Date: Wed, 15 Jul 2015 11:36:04 -0400

> (so no problems like HTTP/2 faced), one can set the bar

Yes, I agree. I think this draft should probably reference the TLS BCP doc
(RFC7525) and recommend the use of no less than TLS 1.2 with AEAD
ciphersuites. There are no backwards compatibility considerations here to
consider anything weaker.

Or the document could write out the specific TLS requirements itself, or
have them listed in another document ("A TLS profile for DNS"?).

I've mentioned all these things to Allison Mankin previously, and I believe
she was favoring the approach of pointing to RFC7525.

> to be defined extensions).

Can you elaborate on the security issues, and also on what specific
warnings Chrome puts up? - I probably haven't kept up with this topic, but
I was under the impression that the padding oracle attacks don't work
against TLS 1.2 with AEAD ciphersuites.

> the resolver IP and the pinned key?

This is good question. For pre-configured stub to resolver profiles, raw
public keys might actually make sense to avoid getting into chicken and egg
issues involving the server's DNS name.

Shumon Huque

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Jul 2015 19:01:36 +0300

> against TLS 1.2 with AEAD ciphersuites.

Background: There are three cipher modes in TLS 1.2.
- Stream: Only has bad ciphers. Don't use.
- Block: CBC ciphers. Supports padding, but vulernable to many attacks.
- AEAD: GCM and Poly1305 modes. Does not support padding. Regarded
        as modern ciphers.

The various security issues include POODLE TLS against some endpoints,
LUCKY13 (various endpoints try to mitigate, but maybe not fully),
length-recovery attacks via truncated_hmac and probably some other
subtle attacks.

The Chrome warning "uses obsolete cryptography" is given for using
RSA key exchange (not to be confused with DHE or ECDHE signed with
RSA key) or any cipher that isn't of AEAD type. I think the warning
is in panel popped up by clicking on the lock icon.

TLS 1.3 will remove stream and block type ciphers (as well as
RSA key exchange).

-Ilari

---

From: Shumon Huque <[email-masked]>
Date: Wed, 15 Jul 2015 12:53:46 -0400

> length-recovery attacks via truncated_hmac and probably some other

Thanks for the elaboration. So if we follow the recommendations in the TLS
BCP (to summarize, TLS 1.2 only with AEAD ciphersuites), we are safe from a
bunch of these: POODLE, LUCKY13 (both padding oracle attacks), right? Is
there a pointer to the length recovery attack (and do we really care about
that for DNS privacy)?

> is in panel popped up by clicking on the lock icon.

Ok, so the TLS BCP addresses this too.

> TLS 1.3 will remove stream and block type ciphers (as well as

That's great. There is one other feature in TLS 1.3 that will be beneficial
for DNS over TLS implementations for performance/latency reasons: the
planned 0-RTT mode for resumed sessions with previously seen resolvers
(most clients will take to the same resolvers), which will frequently cut
out 1RTT.

Shumon Huque

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 15 Jul 2015 20:06:31 +0300

> there a pointer to the length recovery attack (and do we really care about

Yeah. As for pointer for length recovery, it is in one of the references
of TLS BCP. The impact is seemingly to allow attacker to tell the amount
of padding inserted at TLS level.

> (most clients will take to the same resolvers), which will frequently cut

Actually 0RTT is allowed even if performing full handshake (if the server
has valid key on file, this also allows for skipping certificate auth).

-Ilari