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/
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy