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

From: [email-masked]
Date: Tue, 05 May 2015 09:55:38 -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-00.txt
	Pages           : 15
	Date            : 2015-05-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-00

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: Simon Josefsson <[email-masked]>
Date: Tue, 12 May 2015 20:40:12 +0200

Hi.

This document define essentially two mechanisms: port-based DNS-over-TLS
AND upgrade-based DNS-over-TLS.  I may have missed earlier discussions
about this design choice.  However I want to understand why you
want/need this complexity, to make sure there really was a good
motivation behind that choice.

For SMTP, IMAP, POP etc the reason for having both port-based and
upgrade-based is legacy and historic reasons: back in the days the
STARTTLS approach wasn't invented, so following HTTP(S) footsteps, new
ports were allocated for "secure" protocol variants.  Modern protocols
does not have this issue; compare XMPP.

Having two parallel mechanisms for a latency-sensitive protocol leads to
the necessity of doing a "happy eyeballs" approach in implementation to
decrease latency.  There is quite some complexity in getting that right.
Compare RFC 6555 for that approach on a IPv4+IPv6 level.  DNS is
relatively latency sensitive, unlike IMAP/SMTP/XMPP.

What I'm basically wondering, and advocating, is if perhaps one method
would be sufficient.  This would reduce complexity on the protocol and
implementation level.

The preference in IETF has been for the inband STARTTLS approach, so I
suppose that would be the choice of least resistance.  The only reason
against that in your document is a vague "maybe interact poorly with
middle boxes that inspect DNS traffic" -- and I would like to challenge
that this is sufficient motivation to introduce the complexity of having
both port-based and upgrade-based DNS-over-TLS.  Certainly middle boxes
that inspect traffic may interact poorly with port-based DNS-over-TLS as
well.

I would go further and say that middle boxes that interfer with DNS
traffic should be considered part of the problem, not part of the
solution.

Thanks,
/Simon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 May 2015 15:17:42 -0400

> would be sufficient.  This would reduce complexity on the protocol and

I agree that a single mechanism would be cleaner, but perhaps the two
mechanisms serve different purposes?

It seems to me that the STARTTLS variant is useful for opportunistic
dns-privacy, while the distinct-port-based TLS-wrapped variant is useful
for pre-configured non-opportunistic dns-privacy.

People might want to argue about whether opportunistic dns-privacy is
relevant or useful, but if we concede that it does defend against some
relevant attackers, then it might be useful?

I don't imagine a "happy eyeballs" approach happening -- if someone
isn't sure which will be available, they will just use the STARTTLS
approach.  If someone *is* sure, they will use DNS-over-TLS-over-TCP.

Perhaps this distinction could be handled differently, though (e.g. with
some external signalling, such as a DHCP option) so that everything
could be collapsed to the DNS-over-TLS-over-TCP case (since it appears
to be 1RTT faster).

> The preference in IETF has been for the inband STARTTLS approach

I think recent discussions have indicated that there isn't any consensus
for either approach these days.  see, for example, the 'is one or two
ports "more secure"' discussion in saag (hopefully i haven't greivously
misinterpreted it):

  http://thread.gmane.org/gmane.ietf.saag/4916

  --dkg

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 May 2015 14:22:38 -0700

> motivation behind that choice.

Great.

> does not have this issue; compare XMPP.

That's not accurate for SMTP: during discussion of RFC 2487, there was no alternate port for SMTP-over-TLS. It's also not accurate for IMAP and POP: both of those got STARTTLS-like extensions "because that's how SMTP works".

> decrease latency.

That's only true of the specifications don't say what to do first. However, draft-ietf-dprive-start-tls-for-dns *does* say what to do first, so there is no happy-eyeballs issue.

> There is quite some complexity in getting that right.

draft-ietf-dprive-start-tls-for-dns is not about all of DNS: it is about the stub-to-resolver link. The latency you discuss is a one-time issue, because you rarely change your resolver unless your network link changes.

> would be sufficient.  This would reduce complexity on the protocol and

It would indeed reduce complexity, but at the risk of having more unencrypted DNS traffic.

> The preference in IETF has been for the inband STARTTLS approach,

...except for the most popular use case, HTTP... :-)

> so I

Such boxes "may" do anything, but we have seen no evidence that boxes that watch unassigned ports act differently if TLS is negotiated on those ports.

> traffic should be considered part of the problem, not part of the

Fully agree, and the draft says nothing about them being part of the solution.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 May 2015 10:28:49 +0100

> That's not accurate for SMTP: during discussion of RFC 2487, there was
> no alternate port for SMTP-over-TLS. It's also not accurate for IMAP and
> POP: both of those got STARTTLS-like extensions "because that's how SMTP
> works".

My understanding is that the smtps port was allocated, then in a fit of
panic the IETF decided that allocating N*M ports (N protocols, M security
layers) would be a disaster and cause horrible security layer negotiation
problems, so smtps was un-allocated and STARTTLS was invented. (IANA
doesn't record when imaps and pops ports were allocated but I think it was
before smtps.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Variable 4, becoming southeasterly 5 or 6. Moderate or
rough. Showers. Good.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2015 12:36:17 +0200

> for pre-configured non-opportunistic dns-privacy.

I think that makes sense -- pre-configured configurations will have some
trust anchor considerations as well, and might as well use a dedicated
port.  However these two issues are probably orthogonal.  The current
document defines upgrade-base and port-based approach for the same
opportunistic use-case.  I'd still like to understand exactly what the
benefit in having two mechanisms that cover the same use-case is.

> relevant attackers, then it might be useful?

Yes.

> approach.  If someone *is* sure, they will use DNS-over-TLS-over-TCP.

The document says that the starttls approach may interact poorly with
middle boxes.  So it appears as if an implementation cannot be certain
that either one will work, but would have to try both.  I believe that
leads to a lot of unwanted complexity.

>   http://thread.gmane.org/gmane.ietf.saag/4916

Yeah... I phrased that as "traditional preference" first, but I agree
this is somewhat shaky.  I think it is best to evaluate the use-case for
DNS and not apply any rigid traditional arguments.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 May 2015 12:52:43 +0200

Paul Hoffman <[email-masked]> writes:

> That's only true of the specifications don't say what to do
> first. However, draft-ietf-dprive-start-tls-for-dns *does* say what to
> do first, so there is no happy-eyeballs issue.

Are you referring to the following text?

   DNS clients first try port-based DNS-over-TLS.  If that connection
   fails, they try upgrade-based DNS-over-TLS.

That approach is what dual-stack IPv4+IPv6 applications did before
people realized defining "fails" is non-trivial and came up with the
happy eyeballs approach to let the quickest path win, and not bother
waiting for the "fail" to be determined.

> draft-ietf-dprive-start-tls-for-dns is not about all of DNS: it is
> about the stub-to-resolver link. The latency you discuss is a one-time
> issue, because you rarely change your resolver unless your network
> link changes.

Good point.  If indeed latency is not an issue, what's wrong with only
defining upgrade-based DNS-over-TLS?

> It would indeed reduce complexity, but at the risk of having more

True, but the document needs to find a balance.  With the same line of
argumentation, you could suggest that the document should include a
third mechanism DNS-over-HTTPS because it is common for middle-boxes to
interfer with both DNS traffic and special-port TLS traffic, and HTTPS
often works.  I don't believe that is a good path to follow.  It leads
to an explosion of mechanisms.  Therefor I disagree that the risk of
having unencrypted DNS traffic trumf the complexities in having multiple
mechanisms.

> Such boxes "may" do anything, but we have seen no evidence that boxes
> that watch unassigned ports act differently if TLS is negotiated on
> those ports.

On the contrary: I would say that tampering with non-common ports is
frequent.  There are many public/hotel wifi networks that only allow
port 53, 80, 143 and 443 for example.  If you try to do IMAP-over-TLS or
SSH you notice this, they would be completely blocked.

> Fully agree, and the draft says nothing about them being part of the solution.

The document says "Protocol changes proposed here must consider
potential interactions with middle boxes." and then goes on to introduce
the two concepts of upgrade-based and port-based DNS-over-TLS.  To me
this looks as if behaviour of middle boxes were allowed to significantly
influence the design of the protocol.  What I'm questioning is whether
this has lead to too high complexity that can harm rate of adoption.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2015 07:14:26 -0700

> doesn't record when imaps and pops ports were allocated but I think it was

This does not match my memory of what happened, but I totally admit that I was prejudiced by the excitement of creating STARTTLS. Regardless, the situation for SMTP is very different than for DPRIVE, where we are expecting the client to be connecting to just one server for a long period of time, namely until their network settings change.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2015 07:29:49 -0700

Yes.

> waiting for the "fail" to be determined.

And if we later change to that type of wishy-washy operations, you will be correct at that time. We are not there yet, and I will fight strongly against getting there.

If we need more definition of "fails", I'm happy to work on that. Determining success and failure here is completely different than for dual-address applications.

> defining upgrade-based DNS-over-TLS?

Because we know for a fact that some firewalls inspect traffic on TCP port 53, and that they block traffic that they don't understand. They will not understand STARTTLS.

A better question is what's wrong with only defining new-port-based DNS-over-TLS. My personal expectation is that there are far more firewalls that do stupid things with trying to understand port 53 traffic than those that block all unknown ports, but we do know that *some* firewalls are configured to block all unknown ports. That is, if the WG wanted to only pick one, I would bet we would end up with more successful encryption with "new port" than with "STARTTLS".

However, I still disagree that "try A, and try B if failure" is reasonable here, certainly more reasonable in the IPv4or6 case.

> True, but the document needs to find a balance.

We did. :-) That is, your preferred balance point seems to be different than the one we picked, and thus there is now a WG discussion of balance points.

> With the same line of
> often works.

Correct, it could. And we chose against that balance point.

> I don't believe that is a good path to follow.

Good, we're in agreement there.

> It leads

And we do. None of us can prove anything, of course, but we can discuss our opinions.

> port 53, 80, 143 and 443 for example.

That's not "tampering", that's "blocking", and I agree that happens sometimes, but much more rarely now than five years ago, at least from the anecdotal evidence (that is, insufficient research) that I hear from firewall vendors.

> If you try to do IMAP-over-TLS or

I POP-over-TLS and SSH whenever I travel, and I am rarely blocked, whereas ten years ago it was common. Firewall vendors I have spoken to say that they stopped recommending 53/80/443 setups long ago. They still exist, of course, and always will; that's why we didn't go with STARTTLS-only.

> influence the design of the protocol.

They did influence the design, heavily. They are absolutely not "part of the solution".

> What I'm questioning is whether

It is a reasonable question, one that the WG needs to deal with.

--Paul Hoffman

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 May 2015 10:32:17 -0600

Firewall issue:

We can't live in fear that only a handful of ports are forever usable
because of busted firewalls or busted firewall administrators.

I think the decision should be based on what's best for DNS.

I hope that older DNS servers do no crash when getting a new type of packet
information on port 53.
I would think that making sure we do not bust existing things should take
priority.

-
Doug Royer
[email-masked]
(714)989-6135

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 May 2015 14:20:09 -0400

> I would think that making sure we do not bust existing things should take

We should be abolishing port numbers in favor of SRV type discovery.

However, DNS is the exception to the rule. It is a discovery protocol
so it is the one area where fixed IP address and port is arguably
acceptable still.

It depends on your view of the client->resolver versus
resolver->authoritative protocols and how binding is achieved for
client->resolver. I think it is time to let go of fixed IP address and
known port completely

---

From: John Heidemann <[email-masked]>
Date: Wed, 13 May 2015 13:40:42 -0700

>benefit in having two mechanisms that cover the same use-case is.

I would not align choice of startup mechanism with the use case.

Choice of mechanism depends on interference or non-interference from
the client's first-hop network.

Use case (opportunistic vs. pre-configured) depends on the client's
policy.

Clients that change networks (wifi laptops or phones) will want to be
flexible in choice of mechanism, but hopefully consistent in their
policy on privacy.

When you said: "The current document defines upgrade-base and port-based
approach for the same opportunistic use-case.",
I would have said  "...for all use cases" instead.
What in the document suggests mechanism is specific to use case?

   -John Heidemann

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 May 2015 09:13:43 +1000

> this has lead to too high complexity that can harm rate of adoption.

If a middle box does not respond it is broken.  We need to stop
pandering to broken middle boxes.  Most of them will pass stuff
especially the dumb proxies.  If a middle box does not like the
query it can send back FORMERR / NOTIMP.

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

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 May 2015 13:25:17 +1000

> I would think that making sure we do not bust existing things should take

We, like I suspect every other DNS vendor, expect garbage to appear
on the port / socket having had 1/4 of a century of attempts to
break into machines over DNS behind us.  We really should stop
worrying about DNS servers falling over when something new hits
them.  They really don't need to be nannied.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 May 2015 07:35:52 -0400

Any DNSvNext protocol MUST work in 100% of network situations where DNS
works or else it has 0% of being adopted.

There is only one difficult technical issue and that is developing a
protocol that is acceptable to the people who decide whether it goes in the
machines. At this point that requirement isn't even acknowledged by this
group.

What people think should be the basis for decision is irrelevant. If you
want to make the Internet more secure you have no choice but to work
through the gatekeepers and those gatekeepers care about performance and
reliability above all.

Google is currently working on HTTP over UDP to shave a second of page load
times. This group is working is proposing to move the most latency critical
interaction from UDP to TLS.

The disconnect is quite astonishing.

---

From: Doug Royer <[email-masked]>
Date: Sun, 17 May 2015 13:14:56 -0600

On 05/14/2015 09:25 PM, Mark Andrews wrote:
> We, like I suspect every other DNS vendor, expect garbage to appear on 
> the port / socket having had 1/4 of a century of attempts to break 
> into machines over DNS behind us. We really should stop worrying about 
> DNS servers falling over when something new hits them. They really 
> don't need to be nannied.

On any other topic I would agree. Breaking DNS should be one of the 
things to worry about.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 17 May 2015 13:10:16 -0700

> On any other topic I would agree. Breaking DNS should be one of the

Maybe we should make the distinction between "stub resolver" and "iterative resolver" part of the architecture. This would be very much the same split as between an mail client and an e-mail server. Email evolved to use different port numbers for message transmission by SMTP and message submission via SMTP, not to mention wholly separate protocols for email retrieval.

Given that, I would vote for having a distinct port for "stub to iterative DNS," and of course make TLS mandatory on that port.

Anything else has to be motivated by NAT and firewall traversal, and the need to sometime fallback to some dirty compromise. In that case, I cannot see how STARTTLS on TCP port 53 is the answer. If a firewall blocks outgoing TLS on unknown ports, chances are that it will also mess with port 53. NAT the connection, drop the STARTTLS, and voila, MITM on 53. If we need a "dirty fallback," then it has to be port 443. The same dirty fallback that other applications use.

-- Christian Huitema

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2015 12:37:54 +0200

> works or else it has 0% of being adopted.

That's simply impossible.  A goal like that will just distract us.

> interaction from UDP to TLS.

Some people here pointed out that the initial goal is for stub
resolving, which is not latency critical.  I believe this point can be
made more clear in the documents and in the discussion.  One easily gets
the idea that this is about Internet-wide DNS.  Confusing these two
use-cases is bad.

Personally, for stub-resolving I don't see the need for having two
mechanisms (upgrade-TLS and port-TLS).  Just standardize one of them and
be done with it.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2015 12:45:49 +0200

"Christian Huitema" <[email-masked]> writes:

> Maybe we should make the distinction between "stub resolver" and
> "iterative resolver" part of the architecture. This would be very much
> the same split as between an mail client and an e-mail server. Email
> evolved to use different port numbers for message transmission by SMTP
> and message submission via SMTP, not to mention wholly separate
> protocols for email retrieval.
>
> Given that, I would vote for having a distinct port for "stub to
> iterative DNS," and of course make TLS mandatory on that port.

I agree.

Let's simplify the current DNS-over-TLS document to say it is for stub
resolving and to use one dedicated port with TLS from the start.

The comparison with how SMTP for submission and transmission on port 25
evolved into separate ports is a good one.  And back in those days, it
wasn't feasible to demand TLS for all e-mail submission on port 587, so
the STARTTLS-approach made sense, but for the work here, having direct
TLS a'la HTTPS-style on a separate port makes sense to me.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2015 12:54:25 +0200

Paul Hoffman <[email-masked]> writes:

> And if we later change to that type of wishy-washy operations, you
> will be correct at that time. We are not there yet, and I will fight
> strongly against getting there.

Reducing complexity (i.e., one mechanism) will avoid that risk.

> If we need more definition of "fails", I'm happy to work on
> that. Determining success and failure here is completely different
> than for dual-address applications.

Where is the definition for "fail" in the document now?

If port-based TLS is slowed down to a 100th of normal speed, is that
failing and the client should retry over port 53?

> Because we know for a fact that some firewalls inspect traffic on TCP
> port 53, and that they block traffic that they don't understand. They
> will not understand STARTTLS.
>
> A better question is what's wrong with only defining new-port-based
> DNS-over-TLS. My personal expectation is that there are far more
> firewalls that do stupid things with trying to understand port 53
> traffic than those that block all unknown ports, but we do know that
> *some* firewalls are configured to block all unknown ports. That is,
> if the WG wanted to only pick one, I would bet we would end up with
> more successful encryption with "new port" than with "STARTTLS".

My experience is that various kind of middle boxes does so many silly
things that you are walking in the wrong direction by starting to care
at all about what they do and how often they do it.

I think "new port"-only would be better.

> They did influence the design, heavily. They are absolutely not "part

The distinction is subtle.  If middle boxes influenced the design
heavily I would argue that middle boxes are considered to be part of how
the end result will look like.

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 May 2015 09:58:09 -0400

> That's simply impossible.  A goal like that will just distract us.

It is completely possible as I have done that.

> the idea that this is about Internet-wide DNS.  Confusing these two

Stub resolving is totally latency critical. Go talk to some folk who work
on browsers.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 May 2015 16:09:13 +0200

> Stub resolving is totally latency critical. Go talk to some folk who work

I should have qualified it: "connection setup latency of stub-resolving
is not critical".  That is at least how I understand other posts on this
list.

Browsers already have a built-in stub-resolver as far as I am aware, and
appear to be likely to continue to have them.

The latency for one query will be the same with DNS-over-TLS -- 1RTT.

To be fair, my experience is mixed, depending on application, the setup
cost could be an issue -- consider for example a normal Unix application
that does getaddrinfo().  In normal settings, that will cause libc to
open a UDP or TCP connection depending on what's in /etc/resolv.conf.
If that would involve doing a TLS handshake and pulling in a TLS stack,
that has its own share of issues including latency.  However I believe
this model is old-fashioned.  It would be better for /etc/resolv.conf to
always point at 127.0.0.1 or ::1 and have a local daemon running for
name resolution, and that daemon have a long-lived connection to its
local stub resolver.  There is the occational bootstrap issue during
boot, but I don't believe that warrants a complicated in-process stub
resolver.  The DNS stub resolver code in most libc's is crap anyway.

/Simon

---

From: Christian Grothoff <[email-masked]>
Date: Mon, 18 May 2015 12:51:12 +0200

On 05/15/2015 01:35 PM, Phillip Hallam-Baker wrote:
> Any DNSvNext protocol MUST work in 100% of network situations where
> DNS works or else it has 0% of being adopted.

Dear Phillip,

Can I hold you to this statement with respect to this network situation
where DNS "works": http://code.kryo.se/iodine/

(This is my favorite example for a DNS application that cannot be
supported by the GNU Name System, I didn't consider it important, but
clearly you seem to set the bar higher...)

Also, how can we ever even know all network situations where "DNS works"?

Isn't your bar saying: "do not touch the system in any way ever"?

Christian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 May 2015 12:55:28 -0400

> where DNS "works": http://code.kryo.se/iodine/

I did support exactly that in the original design but I took it out.

> Isn't your bar saying: "do not touch the system in any way ever"?

No.

If you have a negotiation layer inbetween that allows the client and
service to negotiate additional transports, you can address even these
corner cases.

One reason I took them out is that a combination of UDP transport plus
WebService transport is sufficient to make PrivateDNS work in any network
situation where the Web works.

The other is that the only use case for that particular application is
bypassing controls using steganographic approaches and I don't want to talk
about anything of that nature in this forum because standardizing
steganography is a contradiction in terms.

If you are doing IPv4 over DNS tunneling then you would need to specify
this as your additional transport.