Subject: [dns-privacy] DOTPIN, TLSA, and DiS

From: Peter van Dijk <[email-masked]>
Date: Thu, 19 Nov 2020 14:05:59 +0100

Please bear with me while I take you on a rollercoaster :-)

We introduce our three actors:

DOTPIN: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ - pin TLS key material in a DS record. Scales badly if one NSset hosts 100k domains, basically preventing you from ever rolling keys. Written in the assumption that software changes at registries are hard, so it only asks them to allow one more DNSKEY Algorithm number. Has great latency properties.

TLSA: frequently touted as an ADoT signal/pin mechanism that would not have all the problems DOTPIN has. Makes sense, but requires some inventive thinking because delegation NSsets are not signed.

DiS: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-delegation-information-signer/ - a parent side signature over delegation data (NS records and glue), published as another DS record. Written in the assumption that we can actually change registry software (in this case, specifically, the DNSSEC signer).

We give our actors roles in a The Shining/MacGyver fanfic crossover:

DiS assumes registry processes can be changed a little. If we trust that they can change more than just a little, the following combination of factors can be proposed:
1. auth operators publish TLSA records for their NSes
2. the registry, while generating zone files, queries for those TLSA records
3. from the found TLSA records, the registry generates DOTPIN DSes
4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, and perhaps the DiS

This offers us:
1. TLSA-based keyrolls from a single 'source of truth' (the auth operator), at low delay (however often the registry re-lookups the TLSA and pushes a zonefile update)
2. a secure shortcut straight through the problematic unsigned nature of delegation NSsets
3. zero additional latency delivery of signal/pinning information to resolvers

However:
1. the complex moving parts are now in the registry, instead of in 10-20 pieces of (mostly open source) DNS software
2. as a whole, it's not pretty
3. an operator hosting 100k domains can make the TLD zone file grow by 100k records by publishing one additional (TLSA) record for one of their NSes

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 20 Nov 2020 20:47:23 +0100

> 4. the DOTPIN DSes are published alongside the domain owner's NSes, DSes, and perhaps the DiS

Intriguing but isn't it unnecessarily complicated? If we assume that
DiS-like is possible, I'd rather replace the DOTPIN-related parts by
some simple flag that tells if the zone's policy is to avoid cleartext.

I.e., in comparison with today, the parent side would additionally sign:
(a) the NS set - e.g. via DiS; that's because signing certs directly has
those scalability issues
(b) and this "policy flag" in some way (say, yet another DS alg like
DiS, but there are other ways).
The reasons are that I believe we want a possibility of downgrade
resistance.

More details: the rest of the trust chain could be TLSA or something
similar on those NSs, looked up separately by a supporting resolver,
assuming these can again be DNSSEC-validated (for now let me avoid
trying to define the case when they can't).  Maybe this "policy flag"
could be more than binary, too, e.g. allowing to indicate that the NSs
may support DoT but it's OK if the supporting resolver isn't strict -
and a third case might mean that resolvers shouldn't even attempt a
secure transport (as optimization).  Of course, it's still not as nice
as I'd like it (but maybe no perfect solution exists anyway), e.g.:
- the TLSA lookup would add latency (at least I expect its TTL high
enough to amortize for larger NSs), and
- there are edge cases like privacy being hard for zones containing
those TLSA records (circular dependencies; I expect we can sacrifice
privacy of those TLSAs at least), and
- it again assumes abusing DS - that's avoidable in theory but it may be
too difficult to make the parent-side sign and return the necessary
information in other ways (soon-ish).

In retrospect I see that what I wrote is very similar to Manu's "Do9"
except for replacing WebPKI by TLSA, with all their pros and cons:
https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01

--Vladimir

---

From: Brian Dickson <[email-masked]>
Date: Fri, 20 Nov 2020 12:14:55 -0800

> https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01
I think we (the three of us and maybe Tony Finch, if not the whole DNS
community) may be converging on a design that will, I believe, work.

I just checked on something that was nagging at me:
Is there a way to secure the NS set without requiring the delegated zone to
be signed?
I believe the answer is "yes", at least assuming implementers follow RFC
4035 correctly.

In section 5.2, the Nth paragraph reads:
    " If the validator does not support any of the algorithms listed in an

   authenticated DS RRset, then the resolver has no supported
   authentication path leading from the parent to the child.  The
   resolver should treat this case as it would the case of an
   authenticated NSEC RRset proving that no DS RRset exists, as
   described above."

So, using a new algorithm for whatever we do, should be 100% backward
compatible.

The assumption is any resolver supporting the new algorithm does so
correctly, and

that any resolver that does not support the new algorithm does the
right thing (treat like unsigned).

This means the design can be as simple as "put stuff in an apex DNSKEY
record with a new algorithm)",

plus put the corresponding DS (hash of DNSKEY elements that DS uses)
in the parent zone, is sufficient.

Note that for TLDs, the mechanism for this would be EPP sending of DS
(or DNSKEY), and/or using

the CDS/CDNSKEY mechanisms.

There is likely use cases for separate new algorithms for protected
delegation items NS, A, and AAAA,

all of which would be non-authoritative (and thus not signed by the
parent, but if encoded this way in

a DNSKEY, hashed as a DS, and signed indirectly by the parent, achieve
equivalency on protection).

Time to test some stuff and do some POC coding, and collaborate on a
draft with some folks.

Yay!

Brian

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 20 Nov 2020 22:00:36 +0100

> So, using a new algorithm for whatever we do, should be 100% backward

Yes, it should be.  A few different proposals have been relying on that
already, for DS or DNSKEY.  It is possible that some validators still
have bugs around this, but hopefully they would be manageable.

For signers there's a possible caveat that a zone must be fully signed
by *all* the present DNSKEY algorithms, but my point of view is that
redefining that it relatively easy on deployment (as only zones wanting
the feature get affected).  See last paragraph of
https://tools.ietf.org/html/rfc4035#section-2.2

> community) may be converging on a design that will, I believe, work.

So far I can't clearly see that direction of convergence, but I'll be
looking forward to such design proposals.

--Vladimir

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 23 Nov 2020 12:49:25 +0100

On Fri, 2020-11-20 at 20:47 +0100, Vladimír Čunát wrote:
> Intriguing but isn't it unnecessarily complicated?

Yes, it is complicated. It is an exercise in ticking -all- the boxes
(incremental deployment, low latency, scalable management) - by moving
all the pain into the registry operation.

> If we assume that

Yes, I believe (and have said before) that this is how a TLSA-based
deployment would make sense.

> https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01

WebPKI has excellent latency properties compared to TLSA. In more words: a parent-side signal that does not pin keys, but does authenticate names, would allow WebPKI based DoT with zero extra queries compared to current non-DoT operations.
 
Kind regards,

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 23 Nov 2020 12:56:19 +0100

On Fri, 2020-11-20 at 12:14 -0800, Brian Dickson wrote:
> 
> I think we (the three of us and maybe Tony Finch, if not the whole DNS community) may be converging on a design that will, I believe, work.

This is not the first time that design has been proposed. It is the
first time it was not met with only criticism, however!

> Is there a way to secure the NS set without requiring the delegated zone to be signed?
> I believe the answer is "yes", at least assuming implementers follow RFC 4035 correctly.
> So, using a new algorithm for whatever we do, should be 100% backward compatible.
> The assumption is any resolver supporting the new algorithm does so correctly, and
> that any resolver that does not support the new algorithm does the right thing (treat like unsigned).

In early 2019, Knot Resolver and 8.8.8.8 had trouble with this. They've
both been fixed a long time ago now. < 
https://mailarchive.ietf.org/arch/msg/dns-privacy/HiqLSzeWRgwseOh6JiNBkScSq_o/

> This means the design can be as simple as "put stuff in an apex DNSKEY record with a new algorithm)",
> plus put the corresponding DS (hash of DNSKEY elements that DS uses) in the parent zone, is sufficient.
> Note that for TLDs, the mechanism for this would be EPP sending of DS (or DNSKEY), and/or using

Yes - I don't think the data functionally needs to even appear in the
child's apex DNSKEY, it just needs a delivery mechanism into the
parent.

(In DiS, the delivery mechanism is "the parent's zone signer software";
that would just leave open the question of delivering the policy flag
that Vladimir mentioned).

Kind regards,

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 Nov 2020 16:20:29 +0200

On Mon, Nov 23, 2020 at 12:49:25PM +0100, Peter van Dijk wrote:
> > In retrospect I see that what I wrote is very similar to Manu's
> > "Do9" except for replacing WebPKI by TLSA, with all their pros
> > and cons:
> WebPKI has excellent latency properties compared to TLSA. In more
> words: a parent-side signal that does not pin keys, but does
> authenticate names, would allow WebPKI based DoT with zero extra
> queries compared to current non-DoT operations.

The WebPKI folks would really hate that, due to the serious
ossificiation concerns it would pose to WebPKI. And by history of DNS,
those concerns are very much warranted (DNSSEC root key rollover was
the most obvious example). There have been number of incidents where
non-web use of WebPKI has caused significant headaches for WebPKI
folks.

On the other side, there are very real concerns about security of
WebPKI. Some of the approved validation methods are downright scary.
Then security of WebPKI fundamentially based on DNS (despite it managing
to collect more single points of failure), so using it in DNS would
cause cyclic dependency with non-obvious implications. Then WebPKI can
not do service authentication (it is not needed for the Web).

Then what should the contents of the trust store be? While in
theory, TLS is capable of negotiation here, in practice that does not
work (because clients have too many trusted CAs, and servers have no
room to manover in). So one would likely get interop issues.

Then this would cause issues if there are ever two incompatible
transports, e.g., DNS over TLS and TLS over QUIC. The server operators
would prefer not to have involve zone owners in what transports they
offer. If one has secure capability advertisment from server operators,
one could just put the authentication data into that (but there would
be some concerns about many queries to various servers, even if the
advertisment is just one rrset).

If there is DNSSEC, stapling the chain would offer the same latency
properties. Of course, that turns out to hit some layer-9 issues to
specify (there was draft about that that got kicked out of TLS WG for
being too toxic), alongside with above-noted issues with incompatible
transports.

-Ilari

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Nov 2020 17:16:13 +0000

> WebPKI. Some of the approved validation methods are downright scary.

Exactly. We now have 25 years of experience to say "we only allow these validation mechanism, not those".

> cause cyclic dependency with non-obvious implications.

That is not inherently true. Newer authentication mechanisms are much more robust than the old "look it up in the DNS, do a nonce check, done". Again, the rules can be set by us, and if only a small number of CAs can (or want to) meet those rules, that's fine.

The fact that we already have DNSSEC greatly helps the situation over what the WebPKI people have. We can leverage that.

And, of course, there will be people who refuse to use any kind of PKI other than DNSSEC for DNS-related uses. That's fine. DNSPKI would be a second, optional mechanism. It would never replace DNSSEC.

--Paul Hoffman