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
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
