OK, thanks. The changes are certainly improvements, in my eyes. Below
I'll further clarify what I meant.
4033 indicates it does not make much sense to keep a RRSIG whose
validity period has expired ( TTL > Validity period).
Yes, I should stress that I do agree with trimming TTL of whole RRset by
expiration of RRSIG that's used to validate it, and there are good
reasons for that. I even had implemented that some time ago for Knot
Resolver.
As I wrote (perhaps unclearly), I was puzzled mainly by the
recommendation that followed. I'm failing to really understand what it
meant exactly, and by what mechanism it's meant to ensure coherence (in
some cases?). And perhaps, how a validator operator could enforce such
conditions without forking their validator. The line:
RRsets TTL SHOULD NOT exceed the DS, KSK or ZSK initial TTL value,
that TTL SHOULD trigger delegation revalidation as described in
{{!I-D.ietf-dnsop-ns-revalidation}}.
I agree we need to ensure good practice with 8624.
I do agree this might not be very very useful today, but the reason we
recommended this is also to ease communication between the resolvers
and authorities. My impression is that it is hard to change the
signature scheme on the authoritative side as we do not know what
resolver will support it.
Recommendations for authoritatives are a bit tangential here. I believe
that RFCs (8624 or others) currently don't give a good idea about
internet-wide support of resolvers for the algorithms, but you can find
good measurements if you pay attention around IETF, OARC, etc. Alg. 13
is widely used for some time, even on TLDs, but 15 seems unfortunately
still rather "risky" (or recently was):
https://www.potaroo.net/ispcol/2021-06/eddi.html
The question seems whether we should use such recommendations to
improve communication between authoritative and resolvers or favor a
more centralized approach where all software is more sticking to one
document 8624. That latter approach seems to me to have too long
cycles and I wished that we could benefit from new crypto ed25519
earlier than when all resolvers are updated.
Well yes, I'm in favor of keeping the supported-algorithm set
centralized internet-wide, instead of trying to start deploying a
decentralized mechanism.
Validators don't need to talk to *authoritative* servers. I believe
it's quite common to have more than one layer of resolvers/caches, in
which case an EDNS0 signal is just a bad mechanism, even if we somehow
managed to deploy it widely. (which wouldn't be easy, kinda similarly
to widely deploying EdDSA validation)
I mainly wanted to dissuade from early algorithm deprecation on
validator side. Validator operators might not understand that instead
of validating a zone with a (supposedly) weak algorithm, they won't
validate it at all. So the only improvement is the AD=1 bit which gets
stricter by that, but most use cases don't even look at that bit and
only rely on the protection by SERVFAILs.
I am surprised you would not recommend RFC 5011
5011 needs persistent state, a thing that resolvers/validators often
don't need at all otherwise (cache is safe to delete). 5011 doesn't
always work, so you need to combine with some fallback mechanism(s)
anyway - for new installations and for stale ones (missed rotation).
Root rollover has happened only once in history, non-root TAs aren't
that common, and 5011 algorithm isn't very simple, so the code can
easily get some bugs without anyone noticing until it's too late.
Lots of down-sides, so I rather put the TAs into SW updates, for the
root TA case at least. I'd recommend trying to avoid non-root TAs, but
if I had to choose, I'd put them into configuration. Again a thing that
I have to provision *anyway*, so I get the occasional TA updates
basically for free, without needing to worry about those 5011
disadvantages. (occasional = 5011 defaults to requiring 30 days of overlap)
--Vladimir
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
