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

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

Hello Ben,

On Tue, 2020-05-26 at 21:27 -0400, Ben Schwartz wrote:
> 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.

I agree, it's the weakest link in the proposition.

>  DoT authoritatives would need to keep both the old and new certificates on hand during the transition

keys, not certificates

> , and DoT recursives would need some way to signal in the ClientHello which one they are expecting.

I don't follow - if the DS set has both the old and new keys, the DoT recursive will accept either. I ki

>   This is pretty far from how TLS normally works.

Hmm, is TLSA 3 1 x far from how TLS normally works? I feel like I'm missing something.

> 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.

I considered putting names in DS records; I also considered chain-extension; but I failed to consider them together! With NS names 'verified' by DS, that looks like something that would also be secure. I agree with the problems Petr spotted - I'm aware of roughly zero implementations of dnssec-chain in clients or servers.

> That seems preferable to me.

For me, with 10 domains on two name servers, not having the complexity of chain-extension is preferable. For others, with a million domains, obviously our draft does not scale. I've been assuming we'd end up with two or three separate signals, each fit for purpose for a certain scale. Your proposal seems like a viable candidate to be one of those to me.


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