Re: [dns-privacy] [Ext] Revised opportunistic encryption draft

[Peter van Dijk <[e-mail]>]

On Tue, 2020-11-17 at 23:30 +0000, Tony Finch wrote:
> Peter van Dijk <[e-mail]> wrote:
> > The incremental cost for a resolver (doing a full resolution process
> > for the TLSA records of one or more NS names) is not small, and neither
> > are the latency costs. For 'popular' name servers, this cost can mostly
> > be amortised, leaving the penalty with any domain hosted on a NSset
> > that only has a few domains.
> 
> Yes. However I think the relative cost of TLSA lookups is much less when a
> resolver implements delegation revalidation because then it's fetching
> authoritative A and AAAA anyway, so it can fetch TLSA concurrently.
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/

As I understand the draft, the revalidation can happen in parallel to
the actual query the user is waiting for. Any setup/discovery of secure
transports would have to happen before that, so I'm not sure we can say
'on top of delegation revalidation, TLSA lookups are basically free'.

> > > Using TLSA records at _853._tcp.<NS_NAME> in a signed zone provides an
> > > unambiguous signal to use optionally TLSA, in a downgrade-resistant
> > > manner.
> > 
> > Not downgrade-resistant, until NS names in delegations become signed.
> 
> Or until the parent nameservers support authenticated encrypted
> transports.

The design choice that DNSSEC did not make, a long time ago.

> Even so I think delegations should be signed.

It would solve a *lot* of problems.

> A (the?) major issue with this whole ADoT effort is the bad trade-off
> between a delegation-centric design (where the DoT signal is in the parent
> zone) which has really formidable deployment obstacles, and really
> troublesome scalability issues; or a DNS-hosting-provider-centric design
> which has poor performance and downgrade weaknesses.

I know DOTPIN has been rejected/shelved/not-adopted for the
deployment/scalability reasons you mention, and also because the
problem space was not mapped out well enough yet, but I still wonder if
perhaps it makes sense to have two solutions to the DPRIVE charter -
one with short paths, few extra queries (like DOTPIN), and one that
works well with '500k domains delegated to one party' - with
delegations signed, or a non-pinning signal (that does not take part in
key rollovers) on the 500k domains, etc.

> If (big if) we think it's worth upgrading the DNS delegation model (and
> EPP, and all the registries and registrars, and all the IPAM databases and
> user interfaces, and documentation and textbooks), can we also tackle the
> scalability problem? By "scalability" I mean the need for a hosting
> provider to update NNNNN delegations when a server cert changes. And there
> are decades old problems keeping delegation NS and glue and DS records
> correct. (A large chunk of the "it's always DNS" meme comes from how hard
> it is to understand delegations and update them correctly.) This whole
> area is a massive pain in the arse sorely in need of universal automation.

+100. I've referred to this in other threads - if CloudFlare had gotten
anywhere with their attempts to solve the operator / registrant /
registrar / registry disconnect problem, all of this would be so much
easier.

> Any serious attempt at improving delegations needs to deal convincingly
> with the quesion of why support for CDS, CDNSKEY, and CSYNC is so
> appallingly bad.

Yes, or in the broader sense, my previous paragraph.

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