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

[Brian Dickson <[e-mail]>]

On Tue, Nov 17, 2020 at 3:30 PM Tony Finch <[e-mail]> wrote:

> Peter van Dijk <[e-mail]> wrote:
> > On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote:
>
> > > 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.
>
> Even so I think delegations should be signed.
>

So, the parental NS records are not authoritative, and thus not supposed to
be signed.

Has anyone ever experimented with how a signed delegation NS would be
handled by resolvers? (This might vary by resolver software and possibly
version.)

The signer field would differ between the delegation RRSIG and the apex
RRSIG (on what would otherwise be very similar RRSETs).
I.e. if you had zone.example.net NS ns1.something.example.com (and
friends), the apex RRSIG would have signer name zone.example.net, and the
non-apex delegation RRSIG would have a different (shorter) signer name.

Actually doing this as a protocol spec change would probably require that
the delegation RRSIGs would need to be cached differently (in the same way
the NS records are cached differently), and used accordingly.

The standardization of DNSSEC was before my time, so I don't know to what
degree this was discussed back then.
As much as making changes to those RFCs would be difficult and potentially
controversial, this might be the path of least implementation difficulty.
The big thing would be the signing overhead on large authoritative
(delegation-mostly) zones.

And I'm not sure whether the DPRIVE use case is enough of a "new
requirement" to justify changing the spec. But I think that is open to
consideration at least.

Fodder for discussion rather than a serious proposal, at least at this
point.

Brian