Subject: [dns-privacy] Early port allocation request for dns-over-TLS

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Aug 2015 09:03:19 -0400

Hi all,

The chairs believe that there is sufficient interest in the working
group for early allocation of a port for dns over TLS, following RFC
7120.

Looking at the eligibility criteria in RFC 7120 Section 2:
2a) we expect this port to be a system port and therefore the IANA
policy for it is IETF Review.
2b) we believe the document has adequately described the protocol.
2c) we believe the document has reached a good level of stability.
2d) The Working Group chairs and Area Directors (ADs) judge that there is
sufficient interest in the community for early (pre-RFC) implementation
and deployment, or that failure to make an early allocation might lead to
contention for the code point in the field.

If you violently disagree with this plan, please let us know no later
than Friday the 14th.

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: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 8 Aug 2015 12:32:55 +0200

On Fri, Aug 07, 2015 at 09:03:19AM -0400,
 Warren Kumari <[email-masked]> wrote 

> group for early allocation of a port for dns over TLS, following RFC

Also, one can read RFC 7605, just published, which discusses the port
allocation criteria and mechanisms.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 10 Aug 2015 19:13:34 -0400

> group for early allocation of a port for dns over TLS, following RFC

... and a quick clarification - we will be asking for both TCP and UDP.

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: Colm MacCárthaigh <[email-masked]>
Date: Mon, 10 Aug 2015 16:35:44 -0700

Quick question: What document is "the document"?

On Fri, Aug 7, 2015 at 6:03 AM, Warren Kumari <[email-masked]> wrote:

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

-- 
Colm

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 10 Aug 2015 17:32:57 -0700

> Quick question: What document is "the document"?

Two: draft-ietf-dprive-dnsodtls and draft-ietf-dprive-start-tls-for-dns.

--Paul Hoffman

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 11 Aug 2015 10:41:41 -0700

Thanks for the references. I haven't been keeping up with this WG, so
apologies for coming to them both anew.

I don't have any violent feedback, but I'd be disappointed to see a system
port allocated for these proposals right now. System ports are scarce and
precious and it would be better to be responsible and to have some
real-world deployments and traction before allocating one.

I have a now-defunct non-system UDP and TCP port (4166) assigned to me,
which people are welcome to re-use for experimentation. (I've never figured
out how to return that port, maybe this is an out).

Some of my reasoning:

   * The documents describe using a dedicated port and re-using port 53. If
re-using port 53 turns out to be more popular, the dedicated port seems
like a waste.
   * I wonder if the goals of DNS privacy are actually enhanced by
encouraging as much "overloading" of port 53 as possible. By having
different traffic types share that port, it may discourage or penalize,
fingerprinting more generally.
   * I've implemented TLS and DNS a few times each, and without meaning to
be inflammatory; they don't seem like a good match for each other to me.
I'm pretty skeptical about adoption.
   * That aside, both documents are poorly specified. Why the note about
disabling compression,  but no consideration of regular size-based
side-channel leaks? why is one kind of compression ok, but not the other?
how should TLS authentication be handled? is it intended to use PKI? or PSK
or some alternative? if it's PKI, how are the circular dependencies on DNS
resolved? what happens when a query crosses the boundary between two or
more TLS sessions and auth contexts? for the SPKI scheme, what happens when
you need to change the signature format or algorithm? for the DTLS cases -
how do you reason about replay attacks and DNS server behavior; for
example, if I as a MITM replay a DTLS DNS query can I observe the rotation
of a multi-RR RRSET to derive what the q-tuple was? I probably can, right?
Which seems like a privacy leak. The docs say that a single DTLS session
can be used for multiple queries, do we rely purely on queryid + q-tuple to
disambiguate them or do we also look at the DTLS record numbers? are there
MITM attacks where the extremely small query-id space can be abused to
derive the plaintext? e.g. if I replay responses from elsewhere in the
stream, with 2^16 responses then I can produce arbitrary matches - could
that leak data or allow me to poison caches? should there therefore be a
limit on the number of responses per PRF stream? can an attacker do
interesting things if they can engineer a DNS response to be split across
DTLS records at interesting boundaries?

-- 
Colm

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 10:51:46 -0700

On 8/11/2015 10:41 AM, Colm MacCárthaigh wrote:
...
> which people are welcome to re-use for experimentation. (I've never
> figured out how to return that port, maybe this is an out).  

See RFC 6335, Section 8.2.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 11:00:10 -0700

> group for early allocation of a port for dns over TLS, following RFC

Hi, Warren,

It might be useful to summarize on this list the rationale for this
allocation and the plan for its use.

In particular:

	- why port 53 is not sufficient using STARTTLS

	- why a system port, rather than a user port, is appropriate

	- whether TLS-protected DNS would ever be expected on port 53

Speaking as an individual (though I also chair the IANA port expert
review team, which reviews applications not through the standards
process), my view is that:

	a) it would have been preferable to use the existing
	assigned port for DNS (e.g., using STARTTLS), as I note
	in RFC7605

	b) the existing ubiquity of DNS ALGs will make (a) difficult
	(this does not apply to new protocols but would here)

	c) if the secure variant has a separate port, then it would
	be confusing to run the same service on multiple ports

	d) if this service is assigned a new port, it should be
	a system port; although system ports do not often afford
	the protections once assumed, it seems reasonable to stay
	with the same type of port as the original service

As a result, I concur with the assignment of a port for "dns-s" (FWIW,
that's what I would suggest, as it is the convention for most new secure
variants) as a system port.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Aug 2015 11:06:27 -0700

FYI:

Joe Abley reminded me off-list that the service name for DNS is
"domain", so my suggestion for the name for this new assignment would
then be "domain-s".

Note: there have been several types of suffixes to indicate security:
-ssl, -tls, -sec, and more recently -s. Because there are many types of
security and to allow more characters for the remainder of the service
name, the -s suffix is currently preferred by the IANA Ports Review team.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 13 Aug 2015 14:13:13 -0400 (EDT)

> "domain", so my suggestion for the name for this new assignment would

Why? Just let the "domain" reference die please, don't build on it.

dnstls or so seems fine to me :P

Paul

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Aug 2015 11:25:04 -0700

> Why? Just let the "domain" reference die please, don't build on it.

There are a few reasons to build on "domain":

	- the current name is "domain", so if you want to
	associate this with the same service but add security,
	it's much more obvious to call it "domain-s"

	- the use of multiple service names for the same port
	is recommended against (RFC 6335), so it's no longer
	possible to assign both "domain-s" and "dns-s"

I.e., if you move to "dns-s" you're creating a distinct name for a
service that really isn't new -- it's just a secure alternate of an
existing service.

As to "dnstls", it might be convenient to speak out loud but it breaks
with current service name recommendations in several ways (new base
name, using the -tls suffix rather than -s), and I don't see a good
reason for this service to blaze a new trail compared to other service
assignments.

Besides, IMO, "domain-s" ought to suffice for any secure version,
including future ones that might use a different security mechanism than
TLS.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Aug 2015 09:42:23 -0400

>         - why port 53 is not sufficient using STARTTLS

- The WG decided that using a new port instead of a STARTTLS or
octet-matching would better suite our operational goals.
We had significant discussions on this, and we have concerns about
things like middle boxes reacting to non-DNS on 53.

>         - why a system port, rather than a user port, is appropriate

- A system port is appropriate because DNS is, and always has been, a
system service.

>         - whether TLS-protected DNS would ever be expected on port 53

- TLS- or DTLS-protected DNS is not expected to ever appear on port 53.

> variants) as a system port.

Thank you. We had similar discussions in the WG, but it is very
helpful to have someone who evaluates these sorts of requests come to
the same conclusion.
W

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 17 Aug 2015 16:03:33 +0000

> On Aug 17, 2015, at 6:42 AM, Warren Kumari <[email-masked]> wrote:
> 

Additionally:

- A separate port avoids the 1xRTT incurred by STARTTLS negotiation.

- DNS-over-DTLS can't use STARTTLS (at least not as currently described), although
it does claim that it can run on port 53.  That relies on an unaware server
mis-interpreting a DTLS ClientHello message as a DNS message with Opcode=15.  That,
in turn, takes Opcode 15 off the table for future allocation, etc.

DW

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Aug 2015 11:16:36 +1000

In message <[email-masked]>, "Wessels, Duane
> in turn, takes Opcode 15 off the table for future allocation, etc.

More correctly DTLS traffic is DNS reply traffic (QR=1) which is
why there is no response from DNS servers.  The traffic is processed
as a broken unexpected reply.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Aug 2015 11:03:19 -0700

FWIW, it would be useful if these issues were documented in the draft,
e.g., in the IANA considerations section.

Joe

---

From: "Mankin, Allison" <[email-masked]>
Date: Tue, 18 Aug 2015 18:12:28 +0000

Hi, Joe,

We authors of the TLS draft are in the process of a revision includes just
this.  I¹m told that the DTLS draft will be revised in the near term to
include port-based establishment as well.

Allison

On 8/18/15, 2:03 PM, "dns-privacy on behalf of Joe Touch"
<[email-masked] on behalf of [email-masked]> wrote:

>>> - DNS-over-DTLS can't use STARTTLS (at least not as currently
>>>described),
>>> although