Subject: Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)

From: Ralf Weber <[email-masked]>
Date: Thu, 24 Apr 2014 15:52:20 +0200

Moin!

On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)" <[email-masked]> wrote:

>> -----Original Message-----
>> From: dns-privacy [mailto:[email-masked]] On Behalf Of Nicholas
>> Weaver
>> Sent: Thursday, April 24, 2014 1:58 AM
>> To: Paul Wouters
>> Cc: dnsop; Nicholas Weaver; [email-masked]
>> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
>> 
>> 
>>> On Apr 23, 2014, at 1:00 PM, Paul Wouters <[email-masked]> wrote:
>>> No, I fully disagree with this. Port 53 TCP has a much better chance
>>> at working these days than a random other newly assigned port.
> 
> On the contrary, Firewalls are configured today to permit UDP port 53 and block TCP port 53. Why should firewalls change their configuration ?
I know lots of firewalls that also allow TCP/53, but the real problem with all these middle boxes that make changing DNS hard is that they believe to understand the full protocol and only pass what they think is right. So everything new we come up will be dropped (Been there, done that). We have to be very careful with changes to the DNS protocol if we want them to be deployed  

So long
Ralf 

Sent from my iPhone

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Apr 2014 10:53:08 -0400

> I know lots of firewalls that also allow TCP/53, but the real problem with all these middle boxes that make changing DNS hard is that they believe to understand the full protocol and only pass what…

+1

If you want to use TLS with DNS then use port 443. One of the effects
of firewalls is that we now only have three ports for all protocols:

Port 80/UDP: Non SSL traffic
Port 443/TCP: SSL traffic
Port 53/UDP: DNS

Which is why the HTTP/2.0 crowd have adopted 'always TLS', not for
encryption, they want to bypass firewalls. And the reason some of us
are pushing back on that is that some of them propose weakening TLS to
make this practical.

Now this approach is of course reprehensible. People are deploying
firewalls for legitimate reasons. And there are some circumstances in
which your traffic not getting out is exactly what should happen.

There are also circumstances where censorship bypass is important and
legitimate.

If you want to run DNS over TCP then I suggest that you simply build a
mechanism to advise on the port to use into whatever upgrade mechanism
you attempt. Then you can use 443, 8443, whatever works.

But the result is rather Rube-Goldberg. My version of digg exploded
from a few hundred kb to 2Mb because it now has the whole of OpenSSL
embedded. (Although the same might well happen if I implemented
DNSSEC)

I don't like that approach. TLS is optimized for a particular purpose
and DNS is a very different problem. We end up using only a fraction
of the features. And as heartbleed shows, an unused feature can still
cause failure. In fact its always been the underused parts of TLS
where problems have emerged - client auth, renegotiation, heartbeat.

I would prefer to separate out the key negotiation from the DNS
protocol. The complex part is the key negotiation. Applying crypo to
messages is pretty easy (albeit not foolproof as heartbeat shows).

One of the features you will note in both CBOR and JSON-B is that we
both use byte length markers to specify the length of binary and text
fields but we don't use them to denote lists or structures.

There is a good reason for that, using byte counts to measure
structures is inherently ambiguous if the inner lengths are larger
than the outer.

Just finishing up a draft. Got to get over this cold first.

-- 
Website: http://hallambaker.com/

---

From: Joe Abley <[email-masked]>
Date: Thu, 24 Apr 2014 11:19:09 -0400

> Port 443/TCP: SSL traffic

I think it's important to frame the problem space. I suspect that the firewall challenges you cite most often apply to communications between stub resolvers and recursive resolvers, for hosts that are using an off-net resolver (directly, or via a proxy).

I also suspect that any ISP who has ever decided to install firewalls or other packet-mangling middleware in front of their resolver service (and is still in business) has by now collected many reasons not to do that, and that the network path between ISP resolver and authority servers is very likely to be clean. For ISP, read campus, enterprise, etc as appropriate.

I have no science to back up my suspicions, here. Given that others apparently have different suspicions, equally plausible, perhaps science is needed. However, I'll note that the conversations surrounding the problem statement in London all seemed to support separating these two uses of the protocol.

I don't think it's worth butchering the protocol if it turns out that we have an easy and clean solution that works for a significant part of the problem space (resolvers talking to authority servers), which is what t-dns/draft-hzhwm-start-tls-for-dns looks like to me.

This compartmentalisation of the problem space reminds me of RFC 4409, and makes me wonder whether there's a way to replace stub-resolver communications with something new without breaking everything. After all, in a very real sense we really only have two edge platforms to worry about (Android and iOS).

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Apr 2014 11:32:12 -0400

> I also suspect that any ISP who has ever decided to install firewalls or other packet-mangling middleware in front of their resolver service (and is still in business) has by now collected many rea…

My interest at the start was censorship prevention so my interest is
almost exclusively client-resolver. It does look like a totally
different protocol to resolver-authoritative though.

Since what we are concerned with here is (also) privacy, I agree that
the resolver-authoritative loop is also in play. But that is a vastly
lower priority than the client-resolver loop. If you don't solve that,
you don't have any solution.

The two problems are completely separate from a trust point of view.
For key management in the Resolver-Authoritative loop you almost
certainly want to use DNSSEC. But in the client-resolver loop you
might well want to use WebPKI because you would want accountability.

> I don't think it's worth butchering the protocol if it turns out that we have an easy and clean solution that works for a significant part of the problem space (resolvers talking to authority serve…

You know when people use loaded terms like 'butchering the protocol'
to mean 'do it a different way to me' I start to get a little cross.

For me the idea of putting TLS traffic over the same port as non TLS
traffic without careful attention to how the upgrade is achieved would
be 'butchering the protocol'. Changing the port number to one that is
known to work is a cleaner approach.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 24 Apr 2014 13:28:44 +0000

On the contrary, Firewalls are configured today to permit UDP port 53 and block TCP port 53. Why should firewalls change their configuration ?
DNSoD does not require any changes to the Firewall configuration. Browsers already support DTLS because of WebRTC (SRTP-DTLS for media streams, SCTP over DTLS over UDP for data channels).

Cheers,
-Tiru

> 
> Not true.  Port 53 is far more molested than "random":  INBOUND firewall rules
> prevent you from running new services without firewall rule modifications, but
> outbound blocking is far less common.  (Our test port for this is TCP 1947 with
> Netalyzr).
> 
> 
> --
> Nicholas Weaver                  it is a tale, told by an idiot,
> [email-masked]                full of sound and fury,
> 510-666-2903                                 .signifying nothing
> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: John Heidemann <[email-masked]>
Date: Thu, 24 Apr 2014 15:58:43 -0700

On Thu, 24 Apr 2014 11:32:12 -0400, Phillip Hallam-Baker wrote: 
>...
>...

Agreed that TLS upgrade must be done carefully.

Fortunately we have a number of protocools that have survived a TLS
retrofit:  IMAP, STMP, POP3, FTP, XMPP, LDAP, NNTP (according to 
http://en.wikipedia.org/wiki/STARTTLS).

Several of these protocols are used over WANs, although I would guess
DNS has far more frequent "help" from transparent middleboxes than they
do, so YMMV.  I think SMTP is a pretty compelling argument that the
World May Not End to do STARTTLS, though.

It is true that a new port "solves" the "oh noes, something changed and
I, the firewall/middlebox, hate you" problem.  However, it solves that
by by turning it into the "oh noes, why should I, the firewall, ever
open this new port for you".  (As as been pointed out.)  It seems like a
trade-off about which pain one wants to endure.

   -John