Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

[Vladimír Čunát <[e-mail]>]

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