Subject: [dns-privacy] Signaling with TLSA records

From: Robert Evans <[email-masked]>
Date: Thu, 9 Dec 2021 19:17:53 -0500

Hi dprive folks,

TL;DR can we make incremental progress using TLSA as a signal?

TLSA records have been discussed here before as a signal that a name server
offers ADoT:

        ns1.example.    A     ...
        ns1.example.    AAAA  ...
        _853._tcp.ns1.example.    TLSA    ....

Resolvers can probe for these records today as a signal for
fully-authenticated ADoT support and fallback to opportunistic TLS via
unilateral probing or unencrypted transport when not found. (This turns out
to be exactly the same approach RFC 7672 specifies for SMTP DANE, including
TLSA as a TLS-is-supported signal.)

Of course as discussed before name server name signals are imperfect:
1. NS records in referrals are unsigned (but NS revalidation[1] is possible
for signed children)
2. In-bailiwick queries cannot be secured (but there's no loss of privacy
when the initial referral is unencrypted, which is going to be typical
given sentiment against ADoT)

Without parent-side signals, no better scheme is possible for signals at
the name-server name. And there is no ideal solution for pure parent-side
signaling, and no consensus either.

So, given all that, TLSA seems to be an imperfect but workable
incremental step towards a fully secure solution. Future parent-side
signals can solve both of the issues above in a way that is 100% compatible
with non-parent TLSA signals.

Is anyone else interested in supporting this approach? I'm considering
writing up an I-D for this and welcome early feedback about whether or not
this might be worth adopting, at least for consideration on an
experimental basis for early adopters.

-Bob

p.s. Why not SVCB? In short it's unnecessary indirection and complexity.
TLSA is minimal and sufficient for now. And nothing prevents SVCB from
using (the same?) TLSA records in the future for TLS certificate
associations.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation

---

From: Paul Wouters <[email-masked]>
Date: Thu, 9 Dec 2021 20:10:56 -0500

> TL;DR can we make incremental progress using TLSA as a signal?

Yes.

> Is anyone else interested in supporting this approach? I'm considering writing up an I-D for this and welcome early feedback about whether or not this might be worth adopting, at least for consideration on an experimental basis for early adopters.

Yes.

> p.s. Why not SVCB? In short it's unnecessary indirection and complexity. TLSA is minimal and sufficient for now. And nothing prevents SVCB from using (the same?) TLSA records in the future for TLS certificate associations.

On the fence on this one. We want to prevent needing to query for multiple records to determine nameserver support. So doing TLSA now and SVCB later would be less ideal, unless nameservers would throw both in the additional section.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 11 Dec 2021 00:13:48 +0200

> TLSA as a TLS-is-supported signal.)

I think you're suggesting that the recursive should hard-fail if a TLSA
record is found but it does not successfully authenticate the
authoritative.

TLSA itself doesn't include the following properties that i think we
want from a signal:

 - indication of which encrypted transports (DoT or DoQ) are supported
 - whether to hard-fail or not
 - how to report errors

If i was an authoritative nameserver operator, i'd be concerned that
deploying such a TLSA record would cause my nameserver to become
unreachable.

The way i'd imagine deploying strict TLS safely on an authoritative is:

 - indicate that i want reports about failures of encrypted transport

 - signal that some encrypted transport is available (without requiring hardfail)

 - wait a few months (at least long enough for some credential rollover
   to happen, to ensure that this happens smoothly)

 - review any received reports in that window

 - if problems, fix problems and start over

 - if no problems, consider turning on hard-fail

I worry that TLSA alone isn't expressive enough to support that rollout,
and that jumping straight to a hard-fail mechanism will scare people
from deploying.  Maybe those fears are misplaced, though.

     --dkg

---

From: Robert Evans <[email-masked]>
Date: Fri, 10 Dec 2021 21:01:24 -0500

> record is found but it does not successfully authenticate the

TLSA signals that the authoritative operator serves TLS and promises to
always offer certificates matching the certificate association(s) in the
TLSA record set.

Resolvers that use the TLSA signal are asked to strictly validate the
certificates so authorities can know to expect and enjoy strict validation
in return.

Beyond that I think we should leave it to the resolvers to set TLS
preference (but exploring the space is important to know the protocol works
in various cases). Strict resolvers can exhaust TLS-enabled name servers.
Lax ones can fallback to Do53. Practical resolvers serving a sizable
population of users will probably bias towards not failing. But the basic
signal is sufficient to enable strict behavior too.

> from deploying.  Maybe those fears are misplaced, though.

This is fair and I agree operators need to be able to gain confidence.

That said, I think the simple signals can work when attached to individual
name server names because operators can do incremental deployment for
important zones. In addition to careful testing with unimportant zones.

The main focus here should be predictable behavior and meaningful rollback.
TLSA signals can be published with small TTLs and resolvers must honor
those. Then operators can rollback predictably when there are failures.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Dec 2021 21:32:08 -0500

> record is found but it does not successfully authenticate the

I am not Robert, but:

Eventually, maybe not at first ?

> - indication of which encrypted transports (DoT or DoQ) are supported

It does this by having a different prefix location but I agree it’s not ideal as I said in my previous message.

> - whether to hard-fail or not

See above. Although one could add it as EKU to the cert but then dns needs the full cert instead of the hash.

Or we could extend the Usage field of the TLSA record to contain this information.

> - how to report errors

Gossip like ? Send old certs from the TLS to the new server to report them, similar to CT gossip proposals. That is in a TLS extension.

> from deploying.  Maybe those fears are misplaced, though.

I think we can encode that in the Usage field.

Paul

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 15 Dec 2021 17:32:59 +0100

>   - whether to hard-fail or not

I don't think it's much worth to bother with authentication if on-path 
active attackers could easily cause automatic downgrade anyway.

One problem with discovery in non-downgradable schemes without parent 
signals is when a resolver encounters a larger NS set.  To make sure 
that none of the servers supports encryption, you'd need to do quite a 
large amount of queries (and also revalidate the NS).  And you can't 
even continue deeper before finishing all of them.  That's quite a 
problem; we've had DoS CVE across multiple vendors just for discovering 
huge amount of NS addresses in such malicious cases for each single 
client query.

Without the "more difficult" parent signals, this could be done by 
requiring to indicate encryption support in the NS name (_dot label or 
whatever).  We need to validate the NS set anyway, and costs to 
implementing resolvers would decrease, especially DoS attempts like 
above, though the number of round-trips per referral would still be 
significantly higher than for resolvers without ADoT.

--Vladimir | knot-resolver.cz

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 15 Dec 2021 08:41:20 -0800

On Wed, Dec 15, 2021 at 8:33 AM Vladimír Čunát <[email-masked]>
wrote:

> even continue deeper before finishing all of them.

This is an interesting observation, but I don't think it's fatal.  We can
simply agree that resolvers have no obligation to prefer encrypted
nameservers.  That means mixed NS-sets will result in fractional DoT
rollout, which seems fine.

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 15 Dec 2021 17:51:21 +0100

On 15/12/2021 17.41, Ben Schwartz wrote:
> We can simply agree that resolvers have no obligation to prefer 
> encrypted nameservers.  That means mixed NS-sets will result in 
> fractional DoT rollout, which seems fine.

That would be a question for operators.  I imagine some deployments 
might want to serve encrypted DNS on a different set of IP addresses 
than normal DNS.