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

[Daniel Migault <[e-mail]>]

On Mon, Nov 28, 2022 at 6:29 AM Vladimír Čunát <[e-mail]>
wrote:

> On 25/11/2022 18.26, Daniel Migault wrote:
>
> 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.
>
> I get that in countries with low validation rates [1] it may be difficult
> to explain to resolver operators that it should be only the authoritative
> side who worries that they "do DNSSEC wrong".  Maybe I'm also personally
> biased against putting much work to work around mistakes done on the other
> side of the protocol.
>
> [1] https://stats.labs.apnic.net/dnssec
>
>
> I think we are rather in agreement here and we do not want the operations
to become more complex because of the other side's mistakes.   This is
essentially why we explicitly tell them to not apply their own specific
recipes and only rely on standard options that are likely to be present in
their resolvers.

> What we expect is that the validator proposes this option and as such the
> DRO selects that option in the validator if present.
>
> Well, OK.
>
>
>
> Well yes, I'm in favor of keeping the supported-algorithm set centralized
>> internet-wide, instead of trying to start deploying a decentralized
>> mechanism.
>> [...]
>>
>> I mainly wanted to dissuade from early algorithm deprecation on validator
>> side. [...]
>>
> 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:
> [...]
>
> OK.
>
> I don't see the part about extended errors as problematic (RFC 8914).  It
> really seems to be getting into (open-source) implementations and it can
> help with debugging in some cases, though deploying it is probably not very
> important either.
>
>
> So I think what you're suggesting is that  8914 will be implemented,
without even the choice being left to the operator. If that the case, would
you like the text instead of SHOULD say something like MAY if not supported
by default by the implementation ?

>
> 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.
>
> I don't think 5011 is worth doing at all.  Maybe in some exceptional use
> cases.  Well, I haven't heard much about deployment experience with
> non-root TAs, so perhaps I just don't know those well.
>
>
> I need to take the time to reconsider that. I am a bit overloaded but
expect to come back to this point more specifically. I got your point in
any case and the scenario we have  is a zone that does not want to rely on
the parent zones in case something goes wrong in these parent zones. The
other aspect is also that we did ot want to give the impression DNSSEC only
works with the root KSK as a TA. But as ai mentioned I will come back with
that.

-- 
Daniel Migault
Ericsson