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

[Daniel Migault <[e-mail]>]

On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát <[e-mail]>
wrote:

> 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}}.
>
>
> So let me know how we came to this lines and I suspect we do share some
similar concerns. A recurrent question and reticence we receive from MNO
and ISPs regarding DNSSEC is that they are really scared about having
the cache with  incoherent RRsets in their cache that causes the validation
to fail and in many cases they imagine a mechanism to prevent and address
such incoherent data in the cache.
One of the intentions of this draft is to prevent such mechanisms to be
implemented - mostly as it is likely to generate errors that DNSSEC experts
would not be able to catch or understand - as generated by the home
made solutions.  As a result we wanted  to minimize the change to
the DNSSEC mechanic and only rely on very simple and standard  mechanisms.
4033 provided one way to limit some incoherencies, and we also thought of a
similar mechanism that was   like the one described in
I-D.ietf-dnsop-ns-revalidation which as we saw it ensures something like a
mechanism that refreshes the chain of trust.
What we expect is that the validator proposes this option and as such the
DRO selects that option in the validator if present.

>
> 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
>
>
> sure. So the idea is not to provide some recommendations to the
authoritative part, but what I wanted to stress is that having a
communication between resolvers and authoritative server is beneficial for
a better understanding of the DNS system involving multiple parties. Now,
given that EDNSO has some drawbacks an dthat the current mechanisms is not
deployed. I agree we can remove this recommendation.

>
> 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 got your point and agree it might be counter productive to encourage a
mechanism that is not reliable. I propose to remove the text below:


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.
>
>
> 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)
>
>
> Oh! sure for the TA. My understanding of the text is that it recommends
5011 for running instances, but that new instances are configured with
up-to-date TA that in most cases are updated by software update. So yes I
agree and will check this appears clearly.

> --Vladimir
>


-- 
Daniel Migault
Ericsson