Subject: [dns-privacy] Please review documents...

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

Hi all,

Please review our documents:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/
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...

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: Warren Kumari <[email-masked]>
Date: Wed, 30 Sep 2015 14:24:49 -0400

Having heard nothing back, I'm going to have to assume that both of
these documents are absolutely completely 100% perfect, and could not
be made any better, clearer or more complete...

I find this, um, surprising...

I'd love to be able to publish these two documents, declare success
and shut this WG down... but I'm assuming that the WG simply hasn't
finished reviewing these, so, pretty please, review and provide
feedback...

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: Ted Hardie <[email-masked]>
Date: Wed, 30 Sep 2015 11:53:20 -0700

Howdy,

A quick question about  draft-ietf-dprive-dns-over-tls-0:

Some previous drafts used ALPN (RFC 7301) tokens to negotiate the use of
DNS as an application layer protocol user of TLS.  This draft seems to
assume that because it is using a well-known port, it does not need to
specify an ALPN  token to indicate that the protocol being negotiated is
DNS.

It strike me as utterly harmless to include such a token and possibly
beneficial (since you might eventually use different tokens for EDNS level,
for example). Is there a strong objection to using both that I'm missing?

regards,

Ted

On Wed, Sep 30, 2015 at 11:24 AM, Warren Kumari <[email-masked]> wrote:

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Sep 2015 11:57:11 -0700

> for example). Is there a strong objection to using both that I'm 

Your proposal would restrict initial deployment to clients and servers 
whose TLS stack has ALPN. Instead of doing this, we could gate the next 
version on ALPN instead, causing more early deployment.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Wed, 30 Sep 2015 12:14:14 -0700

On Wed, Sep 30, 2015 at 11:57 AM, Paul Hoffman <[email-masked]>
wrote:

> ​Are you anticipating DNS running over versions of TLS lower than 1.2, or
are you anticipating that the 1.2 TLS libraries this will be old?
According to Wikipedia, ALPN is supported in:

   - GnuTLS <https://en.wikipedia.org/wiki/GnuTLS> since version 3.2.0
   released in May 2013.[3]
   <https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation#cite_note-GnuTLS-3.2.0-3>
   - MatrixSSL <https://en.wikipedia.org/wiki/MatrixSSL> since version
   3.7.1 released in December 2014.[4]
   <https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation#cite_note-MatrixSSL-3.7.1-4>
   - Network Security Services
   <https://en.wikipedia.org/wiki/Network_Security_Services> since version
   3.15.5 released in April 2014.[5]
   <https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation#cite_note-NSS-3.15.5-5>
   - OpenSSL <https://en.wikipedia.org/wiki/OpenSSL> since version 1.0.2
   released in January 2015.[6]
   <https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation#cite_note-OpenSSL-1.0.2-6>
   - LibreSSL <https://en.wikipedia.org/wiki/LibreSSL> since version 2.1.3
   released in January 2015.[7]
   <https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation#cite_note-libressl-2.1.3-7>
   - mbed TLS <https://en.wikipedia.org/wiki/Mbed_TLS> (previously
   PolarSSL) since version 1.3.6 released in April 2014.[8]
   <https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation#cite_note-PolarSSL-1.3.6-8>
   - SChannel <https://en.wikipedia.org/wiki/SChannel> since 8.1 / 2012 R2.
   - s2n <https://en.wikipedia.org/wiki/S2n> since its original public
   release in June 2015.

Some of these are comparatively new, but by the time this is deployed they
mostly won't be.

I'm not sure gating the next version on ALPN actually helps much, honestly,
as you're either going to have to then burn yet another port, or run the
risk of sending ALPN to the same port at some future time.  Am I missing
another way around this?

(Note that I am not advocating reconsidering the question of using a new
well-defined port, just mulling whether the TLS extension mechanics for
application-layer identification should be in the protocol from the start)

regards,

Ted

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Sep 2015 22:23:55 +0300

> finished reviewing these, so, pretty please, review and provide

Some random comments from quick reading (might be quite off-base):

Both:

1) I think that (D)TLS profiling, authentication and privacy profiling
should be harmonized between the documents. It seems that the problem
is (almost) identical, yet the solutions described look different.

After all, TLS and DTLS are very similar crypto capability-wise (I
think the only difference is that RC4 does not work in DTLS).

DNS-over-TLS (-00):

1) Section 3.2:

Is the section about authentication just examples or is it missing
stuff like pinning RPK of the server?

Also, DNS servers are usually designated by IP, but certificates
work by domain name...

2) Section 3.3:

I presume each request or reply SHOULD also be inside just one
TLS record (but multiple queries/responses can be combined into
a single one)?

DNS-over-DTLS (-01):

1) Section 2:

Obsolete reference, should be upgraded to WG DNS-over-TLS draft?

2) Section 3.1:

Also some kinds of NAT could interact badly with DTLS on UDP port
53 (specifically, those applying special lifetime rules on that
port).

3) Section 3.2:

The SPKI fingerprint example could use explicit specification of
the hash function (seems to be SHA1 in the example).

4) Section 6:

That is from before decision to switch to dedicated port?

I would imagine multiplexing on port 53 would cause problems with:
- All sorts of DNS proxies (these are infamous for various creative
  "interpretations" of DNS).
- Some NATs that might apply special rules on UDP/53
- Some anti-reflection firewall rules (DTLS handshake looks like
  answer, which are only allowed in, not out).
- All sorts of strange middleboxes.

I think the dedicated port is both TCP and UDP, and this would get
the UDP one.

5) Section 7:

Plain public keys reference should be RFC 7250?

DTLS heartbeat is infamous. Additionally, it isn't very well-suited
for MTU determination.

6) Section 10:

How would replying with DTLS alert be implemented? IIRC (but this
might be wrong), with connection in SHOWTIME, alerts from server
to client are encrypted, but the server doesn't have the keys
to construct the message.

One possible way would be to mirror SRTP mux. DTLS packet first
octet is record type, which is always 20-63 for DTLS. SRTP mux
sends non DTLS packets using first octets outside that range.

Also, this smae mechanism probably goes for dealing with client
address change (sometimes that changes rather frequently).

7) Multiple sections:

Multiple places seem to refer to some sort of shim layer that
does not seem to be defined anywhere.

-Ilari

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 30 Sep 2015 23:22:14 +0200

On Wed, Sep 30, 2015 at 02:24:49PM -0400,
 Warren Kumari <[email-masked]> wrote 
 a message of 53 lines which said:

> Having heard nothing back,

I'm surprised: both Simon Josefsson
<http://mailarchive.ietf.org/arch/msg/dns-privacy/QcjYHoo3chjQuaQN-cU4pNWT2WQ>
and me
<http://mailarchive.ietf.org/arch/msg/dns-privacy/FGofF8JBv-WM86iasrqf1mCyE2w>
sent reviews and criticisms on draft-ietf-dprive-dns-over-tls-00

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 30 Sep 2015 22:14:05 +0000

Hello Ilari,

> On Sep 30, 2015, at 12:23 PM, Ilari Liusvaara <[email-masked]> wrote:
> 
> 
> DNS-over-TLS (-00):
> 
> 1) Section 3.2:
> 

I don't feel that section 3.2 is missing anything.  Pinning is mentioned
later in the Security Considerations section.

> Also, DNS servers are usually designated by IP, but certificates

The subject of a certificate can be a domain name or an IP address, and there
are other ways of establishing trust of a server certificate.

> TLS record (but multiple queries/responses can be combined into

I think you're saying that a DNS message shouldn't be split between
multiple TLS records.   Is that because of performance or security reasons?
And do applications generally have that level of control over TLS?

DW

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 30 Sep 2015 16:50:31 -0700

On Wednesday, September 23, 2015 7:32 AM, Warren Kumari wrote: 

> 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.

Not really a review, more a data point. Our team did a test implementation of "draft-ietf-dprive-dns-over-tls." We measured the response times, and found that where the median response time was slightly higher than UDP transactions, mostly due to the encryption overhead.

We were also able to perform an interop test with the Sinodum server, thanks to Sara Dickinson's help. It worked, in the sense that our client could successfully send queries and receive responses. We needed some help to get the encapsulation right. The draft defines the encapsulation format by a reference to DNS over TCP, which is probably fine but confused us. Once the actual encapsulation was explained, everything sailed smoothly.

-- Christian Huitema

---

From: Watson Ladd <[email-masked]>
Date: Wed, 30 Sep 2015 20:05:06 -0400

> 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.

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

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.