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

[Ben Schwartz <[e-mail]>]

I like the idea of signalling DoT support in the DS record, but I worry a
bit about putting the SPKI fingerprint in the DS as well.  Having to update
the parent zone whenever the TLSA key needs to be rotated seems cumbersome
and fragile, especially if the nameserver is operated by a third party.
DoT authoritatives would need to keep both the old and new certificates on
hand during the transition, and DoT recursives would need some way to
signal in the ClientHello which one they are expecting.  This is pretty far
from how TLS normally works.

I wonder if you considered using draft-ietf-tls-dnssec-chain-extension
instead? That would provide the same security and performance, using less
volatile information in the parent.  Specifically, I think that the DS
record would have to convey one bit ("DoT enabled") plus the name of the
nameserver (which should probably match the NS record).  That seems
preferable to me.

On Tue, May 26, 2020 at 5:13 PM Peter van Dijk <[e-mail]>
wrote:

> On Sun, 2020-05-24 at 17:36 -0400, Paul Wouters wrote:
> > I thought using keytag 0, which cannot happen normally, would allow
> > you to leave algorithm and other values more real.
>
> This comment made me curious. Why would that be true? So I generated
> 524726 keys equally split between algorithms 8, 13, and 15.
>
> The result: 2 algo 13 keys with tag 0, 7 algo 15 keys with tag 0. I've
> pasted them at
> https://gist.github.com/Habbie/feb0bf288ea1137bee5a2c3d8913ba7f (happy
> to provide the related private keys if anybody cares).
>
> None for RSA, though, which I bet was predicted in the work behind
>
> https://indico.dns-oarc.net/event/22/contributions/315/attachments/316/555/Quest_for_the_missing_keytags.pdf
> and
> https://ripe78.ripe.net/presentations/5-20190520-RIPE-78-DNS-wg-Keytags.pdf
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>