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

[Daniel Migault <[e-mail]>]

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=
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Daniel Migault
Ericsson