Hi Vladimir, Thanks for the feedback and see inline my comments.
You can also find teh changes made on the PR below: https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/8238c76899bc5a40b1c5234b623ea44fd3f31c77 Yours, Daniel On Wed, Nov 16, 2022 at 3:51 PM Vladimír Čunát <vladimir.cunat=2Bietf= 40nic...@dmarc.ietf.org> wrote: > 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. > > > The section is mostly intended to provide recommendations in order to ensure the data being cached are consistent. 4033 indicates it does not make much sense to keep a RRSIG whose validity period has expired ( TTL > Validity period). When the validity period of the key has expired, we wanted to highlighted that new signatures may have been generated using a new key and this is why we indicated a key roll over - as the mechanism to change the key. I agree with you that we do not fix broken key roll over. I considered adding some text but I came to the conclusion that this would be providing maybe too much description of a zone owner that cumulates mistakes. I prefer to remove the sentence: This would at least reduce inconsistencies during regular KSK roll over. The intention was not to have such a mechanism as a mechanism to address/ correct emergency key roll over. I agree with you this is out of scope. This section does not aim at going further than providing sufficient confidence that the cached data are coherent. One motivation we had also to put this section is to prevent DRO to implement their own mechanism to ensure coherence. * 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. > > > Correct, we had subtree in mind and the full cache. While we could potentially remove only the RRsets that are being validated by a given DNSKEY, I was not aware of any implementation doing it. Again, we want the management capabilities to be quite simple as to not prevent introducing side effects that are even harder to understand. We changed the text to: A DRO MUST be able to flush the cached data subtree associated to a DNSKEY > > 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. > > > 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. Similarly, it is also hard to remove deprecated schemes on the resolvers as we do not know if an authoritative zone is not still supporting it. 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. I currently update the section as follows: As mentioned in {{!RFC8247}} and {{!RFC8221}} cryptography used one day is expected over the time to be replaced by new and more robust cryptographic mechanisms. In the case of DNSSEC signature protocols are likely to be updated over time. In order to anticipate the sunset of one of the signature scheme, a DNSSEC validator may be willing to estimate the impact of deprecating one signature scheme. Currently, interoperability and security are enforced via cryptographic recommendations {{!RFC8624}} that are followed by both resolvers and authoritative servers. The implementation of such guidance is ensured by the software vendors and the compliance of their releases. To safely deprecate one signature scheme, the DNSSEC validator operator is expected to follow the recommendation below: STARTUP: * DRO MUST ensure recent software releases that comply with the most recent cryptographic guidances are being used RUNTIME: * A DRO SHOULD regularly request and monitor the signature scheme supported by an authoritative server. * A DRO SHOULD report a "Unsupported DNSKEY Algorithm" as defined in {{!RFC8914}} when a deprecated algorithm is used for validation. One inconvenient such strategy does not let one DRO to take advantage of more recent cryptographic. While currently not being widely used, a DRO MAY share information with authoritative server in the hope that future deployment of authoritative servers will be able to leverage it. {{!RFC6975}} provides the ability for a DNSSEC validator to announce an authoritative server the supported signature schemes. However, a DNSSEC validator is not able to determine other than by requesting and monitoring DNSKEY RRsets as well as RRSIG. These RRsets are received by enabling DNSSEC validation by default which is obviously the case for DNSSEC validator. 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. > > > I am surprised you would not recommend RFC 5011 but also agree that this could be implemented with a series of software releases. I have the impression that in general MNO tend to prefer a stand alone mechanism as they are constantly deploying releases, but I am happy to hear more on that. --Vladimir | knot-resolver.cz > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop