Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued"

[Bob Harold <[e-mail]>]

On Wed, May 6, 2020 at 12:16 PM Daniel Migault <[e-mail]> wrote:

>
>
> On Tue, May 5, 2020 at 2:53 PM Bob Harold <[e-mail]> wrote:
>
>>
>> On Tue, May 5, 2020 at 12:02 PM Daniel Migault <[e-mail]>
>> wrote:
>>
>>> Hi Bob,
>>>
>>> I apology the previous email has just been sent unexpectedly.
>>>
>>> Thanks for the comments. The new version of the file is available here
>>> [1] and a diff is available at [2].
>>>
>>> I propose the following text for clarification. Feel free to let me know
>>> if that addresses your concern.
>>>
>>> OLD:
>>> Not updating the configuration file prevents a failed synchronization to
>>> to the absence of write permission that are hardly in the control of the
>>> software."
>>>
>>> NEW
>>> Avoiding the configuration file to be updated prevents old configuration
>>> file to survive to writing error on read-only file systems.
>>>
>>
>> I understand that we do not want the system to fail due to missing write
>> permissions.  It seems like this could be handled two ways:
>> 1. Just keep in memory, and do not try to write a new configuration.
>> That works, until the old trust anchor is removed, then it fails if the
>> service is restarted.
>> 2. Attempt to write a new configuration, but keep going even if that
>> fails.  If the write succeeds, then this works even after the old trust
>> anchor is removed.
>>
>> I would prefer the second method.  I think that is what some software
>> already does.  (BIND?)
>>
>>
> Thank you for your feed backs, though this may be changed, in the current
> document we encourage to have an instantiation process that performs some
> validation and checks before the service is started. One of these checks is
> to ensure the configuration is up-to-date. With such process in place, we
> expect that every instance of the service is appropriately provisioned. A
> concrete (simple) deployment can always retrieve the service from a repo or
> perform a check for updates.
>
> With that set, 1 or 2 would work the same. The reason I would maybe prefer
> 1) over 2) is that 1 is known to carry the old configuration which will
> force the necessary check at startup. On the other hand 2) works fine
> unless KSK roll over happens and a write error happens. This means that
> most of the time this will work fine and this is what makes it dangerous in
> my opinion.
>
> But again, I am happy to update this with what the WG thinks it mostly
> appropriated. I have raised the following issue:
>
> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/1
>
>
>

Thanks for explaining.  I had forgotten about the checks before starting.
In my case I was hoping to only need the root trust anchor, and keep it
updated by just patching regularly.  Might be wishful thinking.

-- 
Bob Harold


>
>
>
>
>
>
>
>> --
>> Bob Harold
>>
>>
>>>
>>> Please inline other comments.
>>>
>>> Yours,
>>> Daniel
>>>
>>> [1]
>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd
>>> [2]
>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35
>>>
>>>
>>> On Tue, May 5, 2020 at 11:52 AM Daniel Migault <daniel.migault=
>>> [e-mail]> wrote:
>>>
>>>> Hi Bob,
>>>>
>>>> Thanks for the comments. The new version of the file is available here
>>>> [1] and diff can be seen at [2].
>>>>
>>>> I propose the following text. Does it clarify the concern ?
>>>> Avoiding the configuration file to be updated prevents old
>>>> configuration file to survive to writing error on read-only file systems.
>>>>
>>>>
>>>> "Not updating the configuration file prevents a failed
>>>>    synchronization to to the absence of write permission that are hardly
>>>>    in the control of the software."
>>>>
>>>> <mglt>
>>>> </mglt>
>>>>
>>>> [1]
>>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd
>>>> [2]
>>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35
>>>>
>>>> ------------------------------
>>>> *From:* Bob Harold <[e-mail]>
>>>> *Sent:* Monday, May 4, 2020 4:29 PM
>>>> *To:* Daniel Migault <[e-mail]>
>>>> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed
>>>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption
>>>> By WG Issued"
>>>>
>>>> Minor nits:
>>>>
>>>> 7.  Trust Anchor Related Recommendations
>>>>
>>>> Last sentence, last few words:
>>>> "in section Section 8" > "in Section 8"
>>>>
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>>
>>>> 7.2.1.  Automated Updates to DNSSEC Trust Anchors
>>>>
>>>> "TA updates is" > "TA updates are"
>>>>
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>>
>>>> "but due to human" > "due to human"
>>>>
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>>
>>>> 7.2.2.  Automated Trust Anchor Check
>>>>
>>>> "Not updating the configuration file prevents a failed
>>>>    synchronization to to the absence of write permission that are hardly
>>>>    in the control of the software."
>>>>
>>>> <mglt>
>>>> I propose the following text. Does it clarify the concern ?
>>>> Avoiding the configuration file to be updated prevents old
>>>> configuration file to survive to writing error on read-only file systems.
>>>> </mglt>
>>>>
>>>> Seems confusing, please rewrite.
>>>>
>>>> "The TA can be queries" > "The TA can be queried"
>>>>
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>>
>>>> "does not only concerns" > "does not only concern"
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>> "if the mismatch result" > "if the mismatch resulted"
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>>
>>>> 8.  Negative Trust Anchors Related Recommendations
>>>>
>>>> "disable the signature check for that key the time" > "disable the
>>>> signature check for that key until the time"
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>>
>>>> "This does not prevents" > "This does not prevent"
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>> "either an attack or a failure into" > "either an attack or a failure
>>>> in"
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>> 10.1.  Automated Reporting
>>>>
>>>> "will take the appropriated steps" > "will take the appropriate steps"
>>>> <mglt>
>>>> addressed
>>>> </mglt>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: *Bob Harold* <[e-mail]>
>>>> Date: Mon, May 4, 2020 at 4:28 PM
>>>> Subject: Re: [DNSOP] The DNSOP WG has placed
>>>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption
>>>> By WG Issued"
>>>> To: IETF DNSOP WG <[e-mail]>
>>>>
>>>>
>>>> Looks useful, I will review.
>>>>
>>>> --
>>>> Bob Harold
>>>>
>>>>
>>>> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <
>>>> [e-mail]> wrote:
>>>>
>>>>
>>>> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements
>>>> in
>>>> state Call For Adoption By WG Issued (entered by Tim Wicinski)
>>>>
>>>> The document is available at
>>>>
>>>> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
>>>>
>>>>
>>>
>>> --
>>> Daniel Migault
>>> Ericsson
>>>
>>
>
> --
> Daniel Migault
> Ericsson
>