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

[Daniel Migault <[e-mail]>]

ok, I just posted the 02 version.

Yours,
Daniel

On Tue, Jan 24, 2023 at 2:28 PM Tim Wicinski <[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]>
> 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]>
>> 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]>
>>> 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
>>>>
>>>> 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
>>>>
>>>
>>>
>>> --
>>> Daniel Migault
>>> Ericsson
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>

-- 
Daniel Migault
Ericsson