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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
