Re: [dns-privacy] TLSA for secure resolver-auth transport (was: Possible use case: Opportunistic encryption for recursive to authoritative)

[Paul Wouters <[e-mail]>]

On Wed, 12 Aug 2020, Peter van Dijk wrote:

>> On Mon, 10 Aug 2020, Peter van Dijk wrote:
>>
>>> On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote:
>>>> In the case of encrypted DNS to authoritative servers, those servers
>>>> obviously can have an cryptographic ID based on FQDN.
>>>
>>> This is not obvious. It would be great if it was; but it isn't.
>>
>> Sorry, I did not realise it was not obvious to everyone, so let me
>> clarify:
>>
>> _853._dot.ns0.nohats.ca. IN TLSA <blob>
>> _443._doh.ns0.nohats.ca. IN TLSA <blob>
>
> Yes, that part seems obvious (if we assume the records live with the
> child, which I guess is obvious from your 'national MITM' argument in
> other threads). Many other aspects are not obvious. Some examples
> follow.

It seems regardless of where in the DNS these cryptographic ID's are
placed, that we agree on using the DNS, and thus DNSSEC ?

The "obvious" part only referred to "use DNS records to authenticate
DNS authoritative servers".

The rest of this email is about one of the specific solution proposals.

> Delegation NS records are not signed, so do we stick -those- (or a hash
> of the NSset perhaps?) into DS?

I don't think so. The DS is signed, and following that path, it hardly
matters where the NS records point to. Do you fear that you will receive
bad NS records from the parent, who will than MITM you by relaying
DNSSEC payloads from the real authoritative server, and thus losing privacy
that way? While that is true, there is not much the child can do to
prevent this, other than 1) monitoring and 2) use CNS records so you can
verify the parental glue based on the DS published key. So that at least
ensures it again only comes down to DS record forging the parent would
have to do (see also delegation_only draft)

> Can we find those TLSA records without leaking the names of the name
> servers we are looking for, or do we decide that name server names are
> not a privacy leak?

Hiding nameserver names is pointless, as you will just open up an
encrypted TLS connection to those IP addresses anyway. Any attacker can
do a reverse lookup of that IP. There are commercial entities selling
current and historic NS/WHOIS information. So yes, I don't think you
can gain any privacy by protecting the nameserver names.

> Do we move delegation-revalidation from 'possibly later' to 'always do
> that first', so that we get signed NS records before we look for TLSA?

That could be a local policy? Just like the hardening options in unbound
are now a local policy.

> Do we expect resolvers to issue a couple of TLSA queries per NS before
> getting to the actual end user's question?

Yes. The price per nameserver is pretty small. Especially seeing some
nameservers already verify parental glue at the child zone with DNSSEC.
It could possibly even come in as Additional Data that way to save
an RTT.

> 'Put TLSA records in your zone' is not a protocol. I'm sure we can
> define a protocol that revolves around TLSA, but your description is
> not yet it. That is what I mean by 'this is not obvious'.

We were talking about different things then. Hopefully this email
cleared that up.

>> This uses the unique FQDN of each nameserver's name. You can have
>> multiple TLSA records if you use different keys on some of your
>> nameservers (eg some outsourced to an ANYcloud provider)
>
> Assuming you use vanity names in the outsourcing (i.e. ns5.nohats.ca is
> actually a CloudFlare name server). If you don't use vanity names, the
> scaling mentioned just below comes for free because the outsourced
> operator would own the TLSA records (i.e. nohats.ca IN NS
> paul.cloudflare.com).

I don't understand the "vanity name" ? nameervers have unique names,
whether vanity or not, with the exception of any cast servers. We would
hope anycast servers would share the same or a small subset of keys that
can be handles with one or a few TLSA records at the same nameserver
name.

>> Note that this scales with the nameserver. For example by publishing the
>> above, the libreswan.org domain would also have dot/doh published as it
>> is using the same nameservers.
>
> This, to me, is the main selling point of tying key publication to NS
> names instead of zone names.

Yes, and to circle back to Paul Hoffman's point. I think this is an
essential property. The nameserver operators own the key and they
should be able to change their keys without DS updates by another
party - especially when those nameservers are hosting thousands of
domains.

What is then left is the question "is there any information worth
putting into the DS record with respect to encrypted connections
to nameservers for the domain" ?  I think we could have a bit of
information that says "I expect my nameservers have DoT or DoH",
which would allow resolvers to skip attempting this if the bit is
not found. Although a recursive might still decide to try and lookup
TLSA records anyway to support registrars/registries that cannot or
will not allow these DS records.

So as for the solution space, I now think no bits are needed
within the DS record, but it could very well be that someone
still has a good use for it that we want to support.

Paul