Subject: [dns-privacy] DNS over TLS for zone transfers?

From: Shane Kerr <[email-masked]>
Date: Tue, 17 Jan 2017 18:22:29 +0800

Hello,

I'm sorry if it has already been discussed, but has there been any work
done on using TLS for AXFR/IXFR?

It seems like it should be relatively straightforward, compared to the
stub-to-resolver and resolver-to-authority links. While it does not
seem as big of a problem either, obviously somebody cares about hiding
the contents of zones or everybody wouldn't block zone transfers,
right? 

There are still some issues to consider, such as what the interaction of
TSIG and TLS certificates means, as well as what method a master can
use to signal TLS support (this seems desirable to me, although not
necessary).

Does this seem like something worth working on? Or is it a distraction
from the resolver-to-authority work?

Note also that it might be worthwhile building a new zone transfer
protocol that can perform better in areas where AXFR and IXFR don't
work well today (unnecessary data in IXFR of signed zones, inefficiency
for synchronizing lots of zones, automatic fallback to full zone
transfer on IXFR failure, and so on). That's not really something for
DPRIVE, of course, but adding TLS to the protocol could be rolled into
such an activity.

Cheers,

--
Shane

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 17 Jan 2017 16:17:27 +0530

> DPRIVE, of course, but adding TLS to the protocol could be rolled into

On a side note, because any encryption will require a change to the DNS
protocol (i.e., putting things into a crypto box which isn't backwards
compatible) IMO it would be worthwhile to consider revisiting the DNS
message format.

For parsing queries at nearly link speed, the DNS message format isn't
best suited:

* DNS owner name fields are variable length which makes the message
  difficult to filter (e.g., it requires a DNS specific packet filter to
  match on the question type field because the name field is variable
  length and has no length prefix either, so one has to parse almost the
  entire name to find out how long it is).

* when parsing a query, the implementation wants to know whether to
  accept/serve the query at all, e.g., by examining things in the OPT RR
  (cookie, etc.) and TSIG RR, which come in the additional section and
  requires skipping variable length fields (owner names) on the way
  which isn't fast.

* DNS name compression isn't the greatest idea. Compression code needs
  to be extremely fast (and it can't be skipped according to RFC 1123),
  and this is best left to general purpose compression libraries than
  having to implement this protocol-specific method (which has its
  issues btw.. limited to RFC 1035 names with some quirks, limited to
  16k offset from 0 => poor AXFR, etc.). It's not easy for DNS
  implementors to get high compression to performance ratio even with
  the lacklustre name compression scheme.

* There's redundancy in fields when considering RRsets.

Sara Dickinson said something in her talk in Seoul that their DNS
traffic recording system achieved a low per-message space utilization.

Things to achieve would be to allow implementations to:

- get at things they need to parse quickly
- avoid redundancy in messages
- remove compression or use general purpose compression
- prefix names with whole-name lengths so they can be quickly skipped if necessary

		Mukund

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2017 00:31:57 +1100

> the contents of zones or everybody wouldn't block zone transfers,

People do lots of things which for the most part do nothing useful
like the mistaken belief that preventing people seeing the zone
content provides some sort of real security.  This rose out of the
rsh days where if you could poision caches with false PTR/A record
pairs of known machine names you could break into machines using
rsh.  From this came the misguided advise to block zone transfers
whereas increasing zone transfers would actually prevent the poisoning
actually happening.

Replacing rsh with ssh removed this vulnerability but people still
continued to believe the myth.  Machine names get learnt all the
time.  If you security depends on machines names being unknown you
have no security.

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 17 Jan 2017 07:54:45 -0800

> compatible) IMO it would be worthwhile to consider revisiting the DNS

Shane was talking about wrapping the DNS traffic in TLS. This does not 
"require a change to the DNS protocol", as we have already seen in this 
WG.

--Paul Hoffman

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 17 Jan 2017 15:04:39 -0500

Hi, Shane:

> done on using TLS for AXFR/IXFR?

There was a mini-thread back in June 2016, but I think that was it:

https://mailarchive.ietf.org/arch/msg/dns-privacy/eNHQx5KT3MzqjFObqgDRswCpxi4

> the contents of zones or everybody wouldn't block zone transfers,

I think this was explicitly mentioned at least in passing in "DNS
Privacy Considerations" (RFC 7626), in §2.1 "The Alleged Public Nature
of DNS Data".

DPRIVE has done some work to foil traffic analysis attacks with the
EDNS0 padding option, so it makes sense to me to also encrypt zone
contents during distribution, because zone contents are the exact data
you would need to execute a traffic analysis attack.

DNSEXT defined NSEC3 on the explicit rationale of preventing zone
enumeration. Implementing TLS for zone transfers would address the
collection of zone content by pervasive monitoring.

> use to signal TLS support (this seems desirable to me, although not

The easiest thing to do is probably to make it all a matter of explicit
configuration in server configuration files, for which system
administrators have a well-known solution (configuration management).

Zone transfers already require explicit configuration of several
parameters, anyway, and adding TLS will require a bunch more (e.g.,
permitted TLS versions, permitted cipher suites, certificate validation,
etc).

> from the resolver-to-authority work?

I think if resolver-to-authority confidentiality is implemented, the
next logical plaintext leak to plug would be zone transfers, and if the
full charter were implemented ("…or provide end-to-end confidentiality
of DNS transactions"), then the lack of zone transfer confidentiality
would be a glaring omission.

> DPRIVE, of course, but adding TLS to the protocol could be rolled into

But if an enhanced zone transfer (EXFR?) type were implemented, it seems
like it would be nice to be able to run it over plaintext port 53, so I
don't see why it should be tied to the transport.

(BTW, one thing I wonder about is, for operators who *don't* use
AXFR/IXFR on port 53 to distribute their zones, does the transport they
use support confidentiality equivalent to TLS/SSH?)

-- 
Robert Edmonds

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 18 Jan 2017 06:53:44 +0530

On Tue, Jan 17, 2017 at 07:54:45AM -0800, Paul Hoffman wrote:
> "require a change to the DNS protocol", as we have already seen in this WG.

It does. It won't work on port 53 with an existing client.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 18 Jan 2017 07:04:46 +0530

> It does. It won't work on port 53 with an existing client.

BTW, the email I sent wasn't exactly a follow-up to Shane's DNS over TLS
for AXFR email. My mail was about the resolver -> auth communications.

Maybe it was not clear from the original mail: when a different
mechanism (port and related protocol change) is being introduced for
encrypted traffic which current implementations cannot use without
changes to them, it would be good to consider revisiting the DNS message
format. The reasons for this have been given, and some of these are
things we have recently had performance or filtering issues with with in
the implementation I work on. After a point, no amount of tweaking the
implementation is going to help an inferior format.

		Mukund

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Tue, 17 Jan 2017 18:25:45 -0800

> On Jan 17, 2017, at 02:22, Shane Kerr <[email-masked]> wrote:
> 
> Does this seem like something worth working on?

I'd use it if it was available. Internally one can use any of many methods to add encryption (IPSec, stunnel, etc), but working with external parties it'd be very nice to have a standard method.

There are many facets to security. Keeping zone data private does cover some.

I don't see why this would be tied to a new zone transfer mechanism or message format

Ask

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 17 Jan 2017 21:49:09 -0500

Mukund Sivaraman wrote:
> format.

>From the DPRIVE charter:

    The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms
    to provide confidentiality to DNS transactions, to address concerns
    surrounding pervasive monitoring (RFC 7258).

    …

    DPRIVE is chartered to work on mechanisms that add confidentiality to
    the DNS. While it may be tempting to solve other DNS issues while
    adding confidentiality, DPRIVE is not the working group to do this.

DNS transactions are carried over DNS messages, and RFC 1035 §4
"MESSAGES" divides the message protocol into a "Format" (§4.1) and a
"Transport" (§4.2).

DPRIVE has introduced a new "Transport" backwards incompatible with
existing clients (DNS-over-TLS), but it hasn't introduced any backwards
incompatible changes to the message "Format". There have been backwards
compatible changes, though (EDNS0 padding), using the existing DNS
message format extension mechanism, in support of transaction
confidentiality.

If I understand correctly, you'd need to show that making backwards
*in*compatible changes to the DNS message format are necessary to
providing DNS transaction confidentiality. (Or re-charter.)

> The reasons for this have been given, and some of these are

What does poor message decoding performance from a particular
implementation have to do with DNS transaction confidentiality?

(There are DNS implementations that advertise high query rates with
filtering, so I'm skeptical that backwards incompatible changes to the
message format would deliver substantial speedups.)

-- 
Robert Edmonds

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 18 Jan 2017 08:47:35 +0530

I'll not continue with the charter topic, because you're right that it's
offtopic on a privacy list. However the point was made because it was an
opportunity as a protocol change would be introduced when introducing
encryption.

> message format would deliver substantial speedups.)

No software implementations that I know of advertise link speed rates,
even considering a single 10gbe link. The fastest I've come across is
about 2.4 million QPS from a well-known commercial product. There's a
higher overhead to parsing DNS messages and constructing DNS messages[1]
than need be, especially when the service is hit with attack traffic.

The points I'd listed are from real situations we've encountered.

[1] Unlike for protocols such as HTTP that can serve pre-compressed
resources, DNS name compression is performed on-the-fly during message
rendering. It is a burden on implementations because efficient
implementation of matching would require implementing it in assembly,
something that a general purpose compression library can easily provide
if it were not DNS specific. I don't think any high-level language
implementation (C and above) can efficiently render something like a
COM. delegation (which contains 29 RRs) without a hit on
performance. Profile it and you'll see. If you argue that "DNS
implementations .. advertise high query rates", they could be doing
better.

		Mukund

---

From: John Heidemann <[email-masked]>
Date: Tue, 17 Jan 2017 20:00:09 -0800

>from the resolver-to-authority work?

That seems like a good idea.

Wouldn't a straightforward signalling method be the same as rfc7858: use
port 853?  Is there some reason that wouldn't work?

>DPRIVE, of course, but adding TLS to the protocol could be rolled into

A more modern prototocol may may not be a good idea, but if just using
port 853 works, then the two should be decoupled.

   -John Heidemann