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

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

Hello.

I don't know... my opinions often differ from recommendations of this 
draft, but ultimately it's subjective to some degree.  As feedback was 
requested on IETF 115, let me highlight more significant differences in 
this e-mail, though I dislike arguing about (mostly) opinions.



Nit: the following part doesn't make sense to me, as signature validity 
period is normally way over the TTL anyway (and it's really a bug if it 
got shorter):

> Section 8.1 of [RFC4033 
> <https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-validator-requirements-01.html#RFC4033>] 
> mention the ability by the resolver to set the upper bound of the TTL 
> to the remaining signature validity period. This would at least reduce 
> inconsistencies during regular KSK roll over.

Perhaps I'm really misunderstanding the other parts of the 
recommendation that follows afterwards.  (Also, operator RFC seems a 
weird place to define new algorithms for TTL handling.)  I thought the 
usual issues from bad rollovers aren't about records using bad (initial) 
TTL values but rather doing some steps too fast (or other mistakes).  
Though yes, reduction of TTLs will reduce duration of transient 
mistakes.  And my understanding is that the referred-to (unfinished) 
revalidation draft won't change anything during key rollovers (e.g. 
clear cached records), even though key rollovers seem to be the focus in 
this section.



> *  A DRO MUST be able to flush the cached data associated to a DNSKEY
 From practical implementation perspective, I'd rather recommend 
flushing a subtree than additionally tracking which sets got validated 
by which keys.  (Or maybe that's considered to also satisfy the 
bullet?)  It's a nit basically, but let me post it, as the rule is with 
MUST in here.  Note that the rogue DNSKEY could sign delegations or 
other DNSKEYs, thereby in both cases populating (parts of) that subtree 
with data signed by *other* DNSKEYs.



Section 11. (Cryptography Deprecation Recommendations) seems to imply 
that *validator operator* would manage the set of supported DNSSEC 
algorithms.  I don't think that would be good advice.

RFC 6975 and the associated bullet serve as a red herring here - it's 
standardized but I haven't heard of anyone using it in practice, as it's 
just more convenient on signer side to use one good algorithm than to 
somehow serve different things to different resolvers (and I'm not even 
starting on multiple layers of DNS servers/caches).  RFC 8624 is the 
(missing) reference there, but I believe it's more for the IETF to 
choose/update and for vendors to implement.  Validator operators should 
just update their SW to get future updates of that, though this can be 
expected not to change for years.  We recently saw that the set of 
supported algorithms often isn't easy to configure and we reiterated 
other down-sides, when Red Hat tried hard to avoid SHA-1.


Nit: I wouldn't recommend RFC 5011, as I think it's more trouble than 
worth in practice.  Similarly with some of (root) TA bootstrapping 
mechanisms, but this draft is vague about recommending those anyway.


--Vladimir | knot-resolver.cz