On Wed, 27 May 2020, Peter van Dijk wrote:
DoT authoritatives would need to keep both the old and new certificates
on hand during the transition
keys, not certificates
I would not rule out that people want to run this using a CA chain.
Limiting the signaling to EE-certs or pubkeys is not needed. Especially
if you use TLSA, it makes no sense to take away that flexibility that
some people want, so they can replace their TLS certs and only pin it
to one (their own?) CA.
, 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
Only signal the name and mandate TLSA via tls-dnssec-chain, and this is
not a problem. Regular TLSA processing applies.
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.
It's a very liited subset of how TLS works :)
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.
stubby
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.
Not having SBKI in CDS/CDNSKEY's would be much cleaner from a protocol
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
