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

["Livingood, Jason" <[e-mail]>]

Since it is in WGLC – are you able to close out the issues in Github? (https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues)

Jason

From: DNSOP <[e-mail]> on behalf of Tim Wicinski <[e-mail]>
Date: Tuesday, January 24, 2023 at 21:55
To: Daniel Migault <[e-mail]>
Cc: Florian Obser <[e-mail]>, dnsop <[e-mail]>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-validator-requirements

All

Daniel and I noticed some weird formatting issues with his -02 draft, so he's pushed out -03 which is just fixing some broken formatting.

Tim


On Tue, Jan 24, 2023 at 2:28 PM Tim Wicinski <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Daniel.   We've been  waiting for your updated draft.

tim


On Tue, Jan 24, 2023 at 10:14 AM Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

If you think I have addressed all comments I received, if you believe that is not the case or if there are other comments, please let me know. Otherwise I expect to publish a new version by the end of the week.

Yours,
Daniel

On Fri, Jan 13, 2023 at 5:21 PM Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I am just wondering if you have any further comments or thoughts or we declare your concerns being addressed. If you think we are fine, just let me know.

Yours,
Daniel

On Tue, Jan 3, 2023 at 7:14 PM Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:
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<https://urldefense.com/v3/__https:/github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/dbb75b72a1806520ac77cf04424b0f6de0df29b5__;!!CQl3mcHX2A!Aul7dCvIBaE6NYYl6uvsDbBfBTdsGNtNex5K8fXN24ksqkUnk3rlcNhKWt8IDbAufFeL8S48i7sAUoxtc8CpdkepUA$>

Yours,
Daniel

On Sun, Nov 27, 2022 at 7:26 AM Florian Obser <[e-mail]<mailto:[e-mail]>> wrote:
On 2022-11-25 12:26 -05, Daniel Migault <[e-mail]<mailto:[e-mail]>> wrote:
> On Wed, Nov 23, 2022 at 10:29 AM Vladimír Čunát <[e-mail]<mailto:[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<https://urldefense.com/v3/__http:/example.com__;!!CQl3mcHX2A!Aul7dCvIBaE6NYYl6uvsDbBfBTdsGNtNex5K8fXN24ksqkUnk3rlcNhKWt8IDbAufFeL8S48i7sAUoxtc8Blxvw2SQ$> 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


--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
_______________________________________________
DNSOP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dnsop__;!!CQl3mcHX2A!Aul7dCvIBaE6NYYl6uvsDbBfBTdsGNtNex5K8fXN24ksqkUnk3rlcNhKWt8IDbAufFeL8S48i7sAUoxtc8C-8lZaGA$>