Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Paul Wouters <[e-mail]>]

On Wed, 27 May 2020, Ben Schwartz wrote:

> I agree that the TLS DNSSEC chain extension isn't substantially deployed today, but I don't think that should stop us from using it if
> it would help.  This use case is important enough to drive deployment.

If people really want to avoid doing an extra RTT, then I guess this
extension could be used. But you would still need to have some kind of
TLS server SAN with FQDN conveyed within the DS record. Having a single
bit in the DS signifying "yes there is DoT", isn't enough if the
additional glue NS records can point to any machine with a valid TLSA
chain.

> Using this extension would indeed require the authoritative server to provide TLSA records for its own name.  I don't think it actually
> has to "resolve its own name", because it can choose a name that is in-bailiwick.  Servers can choose an in-bailiwick authentication
> name even if existing NS records have an out-of-bailiwick name.  If an authoritative server has multiple names, it would presumably
> identify the right one from the TLS-SNI.

The nameserver name has to be known (from DS) before the resolver
connects to the DoT server. How the DoT server would identify itself,
via TLSA or via fake DNSKEY doesn't really matter as it can just provide
whatever we decide to use.

Personally, I think it would be cleanest if we use the DS to signal
the DoT nameserver only by FQDN. Then connect to it and get the TLS
chain containing the TLSA record and the CDS that matches the DS.

That way, we can avoid adding pseudo-DNSKEY records. I understand not
every registry supports DS/CDS, but I think if you want to deploy
this, you cannot be depending on humands anything, so CDS or CDNSKEY
support would be a requirement anyway. Let's just convince those
registries that support CDNSKEY but not CDS, that they need to fix
things. It would make everything a LOT cleaner and we got no bogus
DNSKEY records to ignore in our DNSSEC validation path.

Paul