Subject: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers

From: Tony Finch <[email-masked]>
Date: Mon, 10 Sep 2018 15:48:03 +0100

In the most general terms, when upgrading a protocol from cleartext to
TLS, there are a couple of questions the client has to answer:

1. Does this server support TLS?
2. How can I authenticate it?

And there are a couple of approaches to answering them:

A. opportunistic
B. explicit

Opportunistic protocols are easier to set up, but they only answer
question 1 (leaving 2 implicit); whereas explicit protocols are about
publising an answer to question 2, which implies answer 1 is yes.

Opportunistic TLS
-----------------

The only mechanism we have is to probe port 853 and fall back to 53 if
TLS isn't available.

This is fraught with problems since in many cases firewalls will drop
packets to port 853 rather than promptly returning ICMP errors.

It will be useful for resolvers to keep a cache of which auth servers
support TLS (with TLS session resumption data for those that do).

Suggestion: TA flag, "TLS available"
------------------------------------

It might be worth adding an EDNS flag to advertise the availability of
TLS (only meaningful in responses, like the RA flag). This might
mitigate the worst auto-probing latency problems. This is kind of by
analogy to SMTP servers advertising STARTTLS in their EHLO response.

Authentication mess
-------------------

If an auth server supporting TLS has a name in its certificate
matching the target name of the NS record that was used to find it,
then the implicit answer to question 2 is "just use PKIX certificate
validation".

However, it's relatively common for NS records to use unofficial
target names. For example, DJB's comments on gluelessness and his
recommendation for delegations to be in-bailiwick with glue:

https://cr.yp.to/djbdns/notes.html

This means that opportunistic DoT for a popular authoritative server
is likely to run into certificate validation problems, so
opportunistic TLS can only be safe against passive snooping not active
interception.

Suggestion: DANE for DoT
------------------------

This is similar to the SMTP situation, so how far can we get by
applying a similar solution? That is, use DANE TLSA records to
advertise that:

* this nameserver supports TLS, and
* resolvers can authenticate it strictly.

For example,

    newton.ac.uk.  NS  auth0.dns.cam.ac.uk.
	...

    auth0.dns.cam.ac.uk.  A  131.111.8.37
    auth0.dns.cam.ac.uk.  A  2a05:b400:d:a0::1

    _853._tcp.auth0.dns.cam.ac.uk.  TLSA  1 1 1 ( ... )

(This is basically the same as a SPKI pinset but with a different encoding.)

A nice thing about this is that the resolver can find out the auth
server's DoT details at the same time as it finds out its addresses,
so there's no need for slow protocol negotiation.

Caveats of unusual size
-----------------------

Unfortunately, when we consider in-bailwick delegations, we soon
realise that we have strayed into a fire swamp.

Ideally (to minimize latency) when following a referral to a zone with
DoT auth servers, we would get everything we need in one response,
including TLSA records as a new kind of glue record.

I believe there aren't any big obstacles from the DNS protocol point
of view (including AXFR and UPDATE etc.) to adding new kinds of glue
record.

However, to make TLSA glue useful, it also needs to be supported by
registry databases, by EPP, and by registrar user interfaces. That'll
take considerably more than a million times longer than getting out of
the lightning sand.

Glueless DANE
-------------

If DANE glue isn't available, but TA flags are, then perhaps a
reasonable delegation following process is to make a probe `_853._tcp`
TLSA query in order to get the server's explicit DoT configuration, or
failing that a TA bit suggesting opportunistic DoT. This costs an
extra round trip in the resolution process.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
the quest for freedom and justice can never end

---

From: Shane Kerr <[email-masked]>
Date: Wed, 12 Sep 2018 08:38:42 +0200

Tony,

On 2018-09-10 16:48, Tony Finch wrote:
> packets to port 853 rather than promptly returning ICMP errors. >

This seems reasonable, at the cost of sending *some* unencrypted traffic.

Note that we can also use the RTT of this query to set a reasonable 
timeout for our port 853 traffic. A DNS server administrator may have 
configured port 853 support, but the network administrator may block 
this port for portions of the network or may later block this port. So 
we still need probing and a timeout - but it can be quite low in most cases.

> Suggestion: DANE for DoT

I like it.

> Caveats of unusual size

I don't follow why the registries need to be involved with DANE for 
DNS-over-TLS any more than they do with HTTP-over-TLS or SMTP-over-TLS. 
Can you maybe try to explain more?

--
Shane

---

From: Erik Kline <[email-masked]>
Date: Wed, 12 Sep 2018 15:45:12 +0900

> we still need probing and a timeout - but it can be quite low in most cases.

One thing a client might do with a positive TA bit and failed
connections to 853 is present that information to the user and ask for
confirmation they'd still like to use the network.  That might be
useful, or might lead to confusion, idk.  Seems worth trying, though.

> Can you maybe try to explain more?

Exposing my considerable ignorance here (as usual), but can a TLSA
record be added for the in-addr.arpa/ip6.arpa name of a given
nameserver IP?

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Sep 2018 12:02:56 +0100

> > we still need probing and a timeout - but it can be quite low in most cases.

Right, there will need to be some careful client-side engineering.

> useful, or might lead to confusion, idk.  Seems worth trying, though.

Yes, the TA bit will (inevitably) sometimes be wrong. My idea is that
during the rollout phase it is probably worth having a TA bit so resolvers
can avoid probing 853 when it is definitely futile. If TA=1 and 853
doesn't work then it'll probably be slower to resolve that server's
domains, which is about the right level of breakage. (TA is a hint not a
security feature.)

> > Can you maybe try to explain more?

The reason for wanting to include the NS targets' TLSA records in the glue
is so that the resolver can immediately connect over DoT with
authentication, without having to spend time chasing down TLSA records
from below the zone cut. It would be a performance optimization.

To some extent it also closes a privacy leak since it makes it easier for
the resolver to query the child zone's servers without exposing which
child zone it is asking about.

> record be added for the in-addr.arpa/ip6.arpa name of a given

Possibly... I think it was the DoH session at IETF 101 where a bunch of
people got up to say that it's futile to expect the reverse DNS to be
useful. It is perhaps less of a disaster area for mail server and maybe
DNS server IP addresses. But it's shaky territory.

The advantage in this context is that it might allow us to work around the
problem of authoritative servers with lots of different names in NS
targets. You could authenticate DoT to the server regardless of name by
putting the TLSA record in the reverse DNS.

Another disadvantage is that it might be a bit slow, because you can't
look up the reverse DNS TLSA until after you have got the address records
(rather than being able to look them up concurrently). On the gripping
hand, since we can't include TLSA records in glue, the choice is between
a followup query to get the TLSA records from the child zone, or from the
reverse DNS, so the performance difference boils down to how quickly the
resolver can iterate down the reverse DNS.

Perhaps it makes sense to search for TLSA in both forward and reverse?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: West, backing southwest later, 5 to 7, occasionally gale 8 at first.
Moderate or rough. Showers later. Good.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Sep 2018 14:57:25 +0300

> from below the zone cut. It would be a performance optimization.

Maybe I am missing something, but would you not need the DNSSEC records
proving the TLSA records are correct too? And if someone is using many
nameservers and questionable signature algorithms (*cough* RSA *cough*),
the size of the glue could grow rather large, blowing the MTU.

-Ilari

---

From: Willem Toorop <[email-masked]>
Date: Wed, 12 Sep 2018 14:25:51 +0200

> the size of the glue could grow rather large, blowing the MTU.

If you received the TLSA glue from an authenticated DoT authoritative in
a referral, perhaps you do not need the RRSIG?

And perhaps (to deal with the chicken-and-egg problem) it is also okay
to use the glue-TLSA records when you serve the zone locally à la
RFC7706 and you have verified that the zone is complete and correct with
draft-wessels-dns-zone-digest ?

-- Willem

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Sep 2018 16:08:58 +0100

Ilari Liusvaara <[email-masked]> wrote:
> proving the TLSA records are correct too?

Er, good point!

The idea of TLSA in glue is a bit of a fantasy, but I guess if we can
manage to get it working (with EPP and the registr*s and all that jazz)
we can get signed glue records too :-)

Size of glue won't be a problem because we will serve it over TLS :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
the market alone does not distribute wealth or income fairly

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Sep 2018 11:10:57 -0400 (EDT)

>>> from below the zone cut. It would be a performance optimization.

Then use RFC 7901 DNS chain queries (or the hopefully soon
tls-dnssec-chain TLS extension)

>> the size of the glue could grow rather large, blowing the MTU.

Why do we care about MTU for DoH or DoT?

> a referral, perhaps you do not need the RRSIG?

Data origin security != transport security.

What's with this NLnetlabs push to conflate the two? We are all happy
for DNS over HTTPS/TLS but stop suggesting it is replacing DNSSEC. Stop
attacking DANE.

> draft-wessels-dns-zone-digest ?

transfering entire zones to get TLSA records moves the privacy from from
the enduser to the zone administrator. Have you seen the ever returning
TLS Transparency discussions related to redacting?

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 12 Sep 2018 16:22:47 +0100

> tls-dnssec-chain TLS extension)

RFC 7901 doesn't work when asking authoritative servers because they
don't have a copy of the chain.

tls-dnssec-chain will not help iterative resolvers because they will
already have obtained the chain in the process of locating the server
they want to authenticate.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides, Bailey, Fair Isle: West or southwest, becoming
cyclonic in Bailey, 5 to 7, increasing gale 8 at times. Rough or very rough,
occasionally moderate. Squally showers, thundery at times except in Rockall
and Malin. Good, occasionally poor except in Rockall and Malin.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 12 Sep 2018 21:11:33 -0400 (EDT)

> don't have a copy of the chain.

You can set the start of the chain to the zone, so as long as any
chaining would remain within the zone or delegations on the same
server it could work. But perhaps that's stretching things too far.

Paul

---

From: Willem Toorop <[email-masked]>
Date: Thu, 13 Sep 2018 12:41:11 +0200

> they want to authenticate.

Not necessarily for out-of-bailiwick (or deep in-bailiwick) NS records
with glue.

If the tls-dnssec-chain would be obligatory for authoritative DoT
servers, then any kind of signaling that DoT is available would be
sufficient.

---

From: Tony Finch <[email-masked]>
Date: Thu, 13 Sep 2018 11:50:53 +0100

> server it could work. But perhaps that's stretching things too far.

The scenario is that we are querying a parent zone's server, and we want
to get the authenticated TLSA records for the target servers in the
delegation NS records, so we can immediately talk securely to the child
zone's servers.

For chain queries to help, the parent zone auth servers would have to be
willing to serve DNSKEY and TLSA records for all their child zones.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
sovereignty rests with the people and authority
in a democracy derives from the people

---

From: Willem Toorop <[email-masked]>
Date: Thu, 13 Sep 2018 14:14:19 +0200

> for DNS over HTTPS/TLS but stop suggesting it is replacing DNSSEC. Stop

Paul! NLnet Labs is a strong proponent of DNSSEC and DANE.
I'm sorry if we made a different impression.

I'm not trying to get rid of DNSSEC.
I was only talking about the TLSA glue.

Having that said, I actually do think that an obligatory
tls-dnssec-chain extension support for authoritative DoT servers would
make sense. With that in place, signaling does not have to deal with
authentication, so any kind of signaling would suffice... At least if it
came over DoT already, otherwise it can be nullified by an on path attacker.

Then, regarding the kind of signal (TA bit or TLSA glue).  I like
in-zone signaling of DoT availability, because it allows for incremental
deployment of reliable DoT to authoritative servers (with RFC7706 style
locally verified zones).

An alternative for TLSA glue could be a label in the NS name indicating
DoT support perhaps? It's not pretty, but at least it would work right now.

> TLS Transparency discussions related to redacting?

Understood. But it might be okay for the already public root.

---

From: "A. Schulze" <[email-masked]>
Date: Thu, 13 Sep 2018 17:27:28 +0200

> DoT support perhaps? It's not pretty, but at least it would work right now.

Hello,

yes, a special authoritative server name was also the mechanism, DJB choose to publish
a curvedns server public key. (https://en.wikipedia.org/wiki/DNSCurve)

so why not name a authoritative server "dot{foo}.example"?
A resolver may expect by definition that this authoritative server
- is reachable on port 853/tcp
- present a certificate
- prove the certificate's content by a TLSA record served inline via tls-dnssec-chain as well as via 'normal' DNS
- serve zone data

-> capability signaling by name

That way it's not a requirement for a delegation zone to serve any additional data.

Andreas

---

From: Warren Kumari <[email-masked]>
Date: Fri, 14 Sep 2018 15:33:35 -0400

> publising an answer to question 2, which implies answer 1 is yes.
I'd also like to point out another option -- I threw up a little when first
suggesting it, but it may be worth considering again (and please feel free
to point me at the list if it already was).
An opportunistic solution is vulnerable to intentional (or accidental)
blocking, causing a fallback to unencrypted -- blocking of port 853, stupid
middleboxes, etc. You also cannot try just do both 53 and 853 in parallel,
because, well, that would just be stupid.

When resolving www.example.com, the com servers have already provided you
with:
dig +nocomment ns example.com

example.com.            86383   IN      NS      a.iana-servers.net.
example.com.            86383   IN      NS      b.iana-servers.net.
a.iana-servers.net.     172783  IN      A       199.43.135.53
b.iana-servers.net.     172783  IN      A       199.43.133.53
a.iana-servers.net.     172783  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172783  IN      AAAA    2001:500:8d::53

The NS records here are signed and dnssec verifiable (the glue isn't, but
that is a separate fight).

If the NS records / labels were _ta.a.iana-servers.net and _
ta.b.iana-servers.net, that could be used as a positive signal that the
resolver (or if the underscore freaks people out,
dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability to
connect is a security issue.

so:
example.com.            86383   IN      NS      _ta.a.iana-servers.net.
example.com.            86383   IN      NS      _ta.b.iana-servers.net.
_ta.a.iana-servers.net.     172783  IN      A       199.43.135.530
_ta.b.iana-servers.net.     172783  IN      A       199.43.133.53

This works in a backward compatible manner - non-dprive servers don't care
what the nameservers are "called", dprive servers can use the nameserver
label as a signal.
Yes, you could make the argument that this is a icky (and I won't
disagree), or that eventually we would end up with this being abused into
_ta._foo._bar._I_like_cheese._
your_father_smells_of_elderberries.ns23.example.com -- but, I still think
it is worth considering...

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: Robert Edmonds <[email-masked]>
Date: Fri, 14 Sep 2018 16:22:40 -0400

> because, well, that would just be stupid.

Why is trying 53 and 853 in parallel stupid? You can cache whether the
port 853 attempt succeeded or not for a long time, perhaps even in
non-volatile storage, and this will end up suppressing a huge amount of
future unsuccessful connection attempts. Even with a few million
authoritative nameserver IP addresses the amount of storage required is
pretty low.

> that is a separate fight).

No? The delegation NS records served by the com servers are not
authoritative and are not signed. The only signed material you get from
that transaction is the RRSIG covering the DS RRset, right? You would
still need to contact the example.com servers with a separate NS query
to DNSSEC-validate any signals encoded in NSDNAMEs.

-- 
Robert Edmonds

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Sep 2018 11:36:57 +0100

Warren Kumari <[email-masked]> wrote:
> dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability
> to connect is a security issue.

Several people seem to quite like this kind of idea, and I think it's a
good way to reduce latency (since we have to assume that better glue
isn't an option). e.g. Willem and Andreas in
https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02137.html

Regarding the specifics, NS targets are hostnames so they have to conform
to RFC 952 syntax (no underscores).

I think signalling in the hostname has to be a hint rather than an
assertion, since it's vulnerable to a downgrade attack because delegation
NS records are unsigned (as Robert pointed out).

Putting the hint in the NS name I think makes the TA bit redundant - it's
really too late to be helpful.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Fitzroy: Southwesterly 5 to 7. Slight or moderate becoming rough or
very rough. Mainly fair. Good, occasionally poor.

---

From: Martin Hoffmann <[email-masked]>
Date: Mon, 17 Sep 2018 16:10:42 +0200

> NS records are unsigned (as Robert pointed out).

Downgrade seems to be an issue with all proposals. To solve them,
there may need to be something signed by the parent as part of the
delegation data.

One option is to create a hash over the NS record set and place it in the
parent zone in the same way as the DS record. This could either be a new
record type or, devious but possibly deployable right now, (ab)use the DS
record for the purpose with a new algorithm type.

Kind regards,
Martin

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Sep 2018 15:47:03 +0100

Martin Hoffmann <[email-masked]> wrote:
>
> Downgrade seems to be an issue with all proposals.

The tradeoffs seem to revolve around how much you leak before you work out
whether you can use strict DoT, and how much added latency that costs.

If you are talking to a nameserver via its canonical name, then asking for
its TLSA record in the clear is not really leaking anything that isn't
leaked by observing IP addresses and port numbers. And signed TLSA records
prevent downgrade attacks.

The other side of this tradeoff is the whole argument around gluelessness
vs. in-bailiwick namesserver names. If you give your servers non-canonical
in-bailiwick names then cleartext TLSA queries will leak the zone name,
which is not so great. TA hints in the nameserver name can reduce the
leakage to passive surveillance but not downgrade attacks.

> record for the purpose with a new algorithm type.

That's a neat hack and also quite disgusting :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: South 5 or 6, occasionally 7 later. Slight or moderate.
Showers. Good.