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

[Daniel Migault <[e-mail]>]

Hi Vladimir and Florian,

Thanks for the comment regarding the use of 5011, to update the
trust anchors. There are two situations where TAs need to be updated:
* 1) configuration so the server instances are started with
the up-to-date TA.
* 2) a running resolver instance that has been started with the old TA and
that needs a new TA to be considered.

1) configuration:

TA trust store is an essential element of the configuration, and the
document recommends having a special process to ensure every new resolver
instance starts with the  up-to-date TAs. TAs are so essential in the
elaboration of trust that special care must be considered.  This means that
you need a robust mechanism to update the TAs trust store.
Many DRO will not implement that process and instead rely on software
updates to delegate the TA trust store update to the software vendor.
If the DRO is willing to have a *special/specific* additional TA that is
not updated delegated to the software vendor, the DRO will have to put in
place such a mechanism. This is a critical operation and the DRO must have
strong reasons to do so and must balance the additional operational risks
versus the additional benefits.
Given the essential aspect of the TA trust store, we recommend updates to
be handled by an automated process (as opposed to manually being performed)
BUT we also recommend the process to be manually supervised, that is with a
manual confirmation.
This mechanism is likely to require a specific relation between the DRO and
the TA issuer with potentially the mechanism, being out-of band. To that
point 5011 is probably not the best choice as mentioned by 5011 itself in
section 8.3.

2) running servers

For running resolvers, there is a need to ensure that the resolver is using
the up-to-date TA. For this we recommend to follow 5011 that indicates how
to automatically put significant trust into the newly published DNSKEY. On
the other hand, if resolvers are retarted every days we may not need to
have 5011 and monitor the roll over. I think that is the purpose of your
comment.

My impression is that there were some confusions in the text where 5011 was
used. When it is limited to the running resolver, I would
recommend enabling 5011 when the TA signer implements 5011 in case the
software is not updated in a timely manner - or at least let the DRO decide
whether it is willing to enable this option as a sort of insurance - even
if it is relying on the software update as a general mechanism. I think it
might be a bit different from what you proposed initially, which is to
leave that to DRO with DNSSEC strong expertise and recommend to
only stay with software updates. If there are any strong feelings on just
relying on software updates and leaving 5011 to DNSSEC experts, I am also
fine to push toward such a direction.

I updated the text as follows:
* clarifying TA updates for configuration versus running instances
* clarifying 5011 dot not apply for updating configuration - at least as a
primary mechanism
* emphasize that the non default model is only recommended for DRO with
DNSSEC expertise
* adding that TA update for running resolver may be performed also by
software update under the condition the DRO is likely to ensure a very
recent release is run.
* add a recommendation that when 5011 is used, the signer needs to
implement 5011 timings.

The changes can be seen there:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/dbb75b72a1806520ac77cf04424b0f6de0df29b5

Yours,
Daniel

On Sun, Nov 27, 2022 at 7:26 AM Florian Obser <[e-mail]>
wrote:

> On 2022-11-25 12:26 -05, Daniel Migault <[e-mail]> wrote:
> > On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát <
> [e-mail]>
> > wrote:
> >> 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.
>
> Another issue with 5011 is that it needs cooperation from the entity
> signing the zone during a KSK rollover. 7583 spells this out in section
> 2.2. I think Vladimír is hinting at this already, I'd say it should be
> spelled out. Especially since this is aimed at non-DNSSEC-Experts as you
> were saying earlier in the thread.
>
> If a DRO unilaterally decides to put in a TA for example.com as
> suggested in section 7.1.1 and using 5011 this will not end well if they
> don't tell the people operating the signer. They will probably not
> follow the correct timing during a KSK roll.
>


-- 
Daniel Migault
Ericsson