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

From: Dan Wing <[email-masked]>
Date: Wed, 23 Apr 2014 06:47:07 -0700

For discussion.

   DNS queries and responses are visible to network elements on the path
   between the DNS client and its server.  These queries and responses
   can contain privacy-sensitive information which is valuable to
   protect.  An active attacker can send bogus responses causing
   misdirection of the subsequent connection.

   To counter passive listening and active attacks, this document
   proposes the use of Datagram Transport Layer Security (DTLS) for DNS,
   to protect against passive listeners and certain active attacks.  As
   DNS needs to remain fast, this proposal also discusses mechanisms to
   reduce DTLS round trips and reduce DTLS handshake size.  The proposed
   mechanism runs over the default DNS port and can also run over an
   alternate port.

http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls

-d

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Apr 2014 07:26:42 -0700

> http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls

This proposes to run a binary protocol (DTLS) over port 53. It says "A DNS client or server that does not implement this specification will not respond to the incoming DTLS packets because they don't parse as DNS packets (the DNS Opcode would be 15, which is undefined)."

Has anyone run any tests against currently deployed recursive resolvers and authoritative servers to see what they do when sent the initial DTLS packet?

--Paul Hoffman

---

From: Dan Wing <[email-masked]>
Date: Wed, 23 Apr 2014 08:42:26 -0700

> Has anyone run any tests against currently deployed recursive resolvers and authoritative servers to see what they do when sent the initial DTLS packet?

Paul,
  openssl s_client -dtls1 -connect 1.2.3.4:53 -debug
substituting 1.2.3.4 for the server you want to test, and in another window do tcpdump port 53.

-d

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 23 Apr 2014 08:05:44 -0700

TLS seems like a poor choice for any new cryptographic transport, it is a
very complicated protocol with a considerable amount of implementation
complexity, computational and network costs. DTLS seems poorer still, as it
is an adaptation of primitives never intended for datagram transmission.

But feedback on the draft:

   * It's unclear how your protocol would really mitigate an active
attacker sending bogus responses. Won't the attacker still be able to
disrupt the DTLS session? Allowing session multiplexing by query-id likely
amplifies this risk.

   * In DTLS, the ClientHello is in the plain - this presents opportunities
for downgrade attacks and inference making. Considering the proposal
advocates for hardcoding the certificate, why not just use a key from the
off?

   * Some nameservers definitely don't just "not respond" when they get
messages they don't understand :/

   * Is the entire protocol subject to the simplest downgrade attack of
all? Just cause the first server response to be dropped and regular DNS
will be used?

   * How long should session state persist?

   * The network costs of certificate transmission probably pale in
comparison to the computational costs of key negotiation. How should
trivial key-exchange ddos attacks be prevented?

   * TLS Heartbeat messages do not permit asymmetric MTU discovery.

On Wed, Apr 23, 2014 at 6:47 AM, Dan Wing <[email-masked]> wrote:

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

-- 
Colm

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Apr 2014 09:16:29 -0700

> substituting 1.2.3.4 for the server you want to test, and in another window do tcpdump port 53.

Sure. What were the results of your testing?

--Paul Hoffman

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 23 Apr 2014 09:36:35 -0700

> http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls

a:  With the need to do all the handshaking, you gain only a little from doing dTLS over UDP rather than TLS over TCP.  So why use UDP with all its headaches?  Just use TCP and conventional TLS rather than DTLS, especially when you are talking about mucking with the handshake.

b:  DO NOT USE PORT 53 for this:  There are far far too many networks (1%+) that reinterpret DNS requests or just outright block all DNS to non-approved servers, and more still which block non-DNS over DNS.

--
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: Paul Vixie <[email-masked]>
Date: Wed, 23 Apr 2014 11:41:12 -0700

for reasons well-spoken up-thread, if we're going to add a dns
transport, i'd like it to be RFC 6013 style TCP (in which session
context can be compressed and retained after FIN for full-window-size
restart, and which permits the query to be bundled into the SYN packet),
or at a minimum, SCTP.

DTLS does not solve any of the problems described at
<https://queue.acm.org/detail.cfm?id=2578510>.

vixie

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Apr 2014 16:00:09 -0400 (EDT)

> b:  DO NOT USE PORT 53 for this:  There are far far too many networks (1%+) that reinterpret DNS requests or just outright block all DNS to non-approved servers, and more still which block non-DNS…

Yes, I fully agree with this. It was a major objection for me to CurveDNS
as well

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.

I'll go get a comfort coffee now.....

Paul
ps. leaning towards "custom crypto that fits in DNS formats"

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 23 Apr 2014 13:27:37 -0700

> working these days than a random other newly assigned port.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Apr 2014 18:32:35 -0400

I agree that DTLS does not solve any problems for DNS. The basic
problem is that DTLS is still based around the notion of a session
where the server stores per connection state. So you might as well use
TLS for this application.

But TLS is not the only option available. Or rather using TLS to
secure DNS is not the only option possible. If we use TLS to do a
kerberos like key exchange, we can generate a shared secret and a
ticket which can then be used to secure all future communications
without changing from UDP.

We can't run over port 53 (trust me, I tried). But we can nominate the
ports to use in the key exchange setup.

The resulting protocol works in about 93-98% of network situations
(depending on how you measure). So you still need a Web Service
backup. But it does work pretty well.

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Apr 2014 19:11:02 -0400

On 23 Apr 2014, at 18:32, Phillip Hallam-Baker <[email-masked]> wrote:

> We can't run over port 53 (trust me, I tried).

You have doubts about the approach described in draft-hzhwm-start-tls-for-dns-00? Those would be interesting to hear; I find that draft (and the accompanying t-dns technical report) to be quite compelling.

If you have doubts, are you mainly concerned about transactions between recursive and authority servers, or between stub resolvers and recursive servers?

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Apr 2014 19:30:43 -0400

> If you have doubts, are you mainly concerned about transactions between recursive and authority servers, or between stub resolvers and recursive servers?

I meant Port 53 UDP. There is just too much middlebox stuff that gets
in the way.

Port 53 TCP might be viable.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Apr 2014 21:46:59 -0400 (EDT)

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

Provided you use "traditional DNS" perhaps? Once you account for roaming
around different network, I think you will see port 53 us regularly 
transparently proxied to a local DNS server. When those see something
they don't understand because its not "traditional DNS", you'll lose.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Apr 2014 12:01:48 +1000

In message <[email-masked]>, Paul Wouters writes:
> > 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).
> 

Which doesn't handle RD=0 queries and often doesn't handle DNSSEC.

This still isn't a reason to not use port 53.  It is a reason to
write "Transparent DNS Proxies Considered Harmful".

It is a reason to have a DHCP{v6} option for "hotspot registration".

Mark
 
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Apr 2014 08:11:28 +0200

On Wed, Apr 23, 2014 at 09:16:29AM -0700,
 Paul Hoffman <[email-masked]> wrote 

> Sure. What were the results of your testing?

I quickly tested with .FR authoritative name servers and both NSD and
BIND seem to silently ignore the incoming request. No response is seen
coming back.

08:08:44.460710 IP (tos 0x0, ttl 64, id 8611, offset 0, flags [DF],
proto UDP (17), length 192)
    192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-|
    [0q] 0/0/0 (164)
08:08:45.459519 IP (tos 0x0, ttl 64, id 8612, offset 0, flags [DF],
proto UDP (17), length 192)
    192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-|
    [0q] 0/0/256 ar:
    ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain]
08:08:47.459513 IP (tos 0x0, ttl 64, id 8613, offset 0, flags [DF],
proto UDP (17), length 192)
    192.168.1.10.48864 > 194.0.9.1.53: [udp sum ok] 5886 zoneRef*-|
    [0q] 0/0/512 ar:
    ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A^A.[|domain]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Apr 2014 07:19:14 -0700

>    ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@…

Thanks, this is the kind of data I was looking for. The draft seems to assume that the server will give an error, not no response.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Apr 2014 14:44:41 +1000

If you want a response "QR" needs to be zero.  Note the "*" which
indicates the packet is a response (QR=1).

In message <[email-masked]>, Paul Hoffman writes:
> >    ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^
> TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_
> M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A
> ^A.[|domain]
> >    ^A^@^@M-^K^@^@^@^@^@^@^@M-^KM-~M-^?SXM-*l^P^^^TM-"n4^gs^OM-ylMM-S0M-9M-=M-^F_^D^V4^NM-us{^^:^@^@^@XM-@^
> TM-@^JM-@"M-@!^@9^@8^@M-^H^@M-^GM-@^OM-@^E^@5^@M-^DM-@^RM-@^HM-@^\M-@^[^@^V^@^SM-@^MM-@^C^@^JM-@^SM-@^IM-@^_
> M-@^^^@3^@2^@M-^Z^@M-^Y^@E^@DM-@^NM-@^D^@/^@M-^V^@A^@^U^@^R^@^I^@^T^@^Q^@^H^@^F^@M-^?^A^@^@^I^@#^@^@^@^O^@^A
> ^A.[|domain]
>