On Tue, May 5, 2020 at 2:53 PM Bob Harold <rharo...@umich.edu> wrote:
> > On Tue, May 5, 2020 at 12:02 PM Daniel Migault <mglt.i...@gmail.com> > 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 > -- > 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= >> 40ericsson....@dmarc.ietf.org> 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 <rharo...@umich.edu> >>> *Sent:* Monday, May 4, 2020 4:29 PM >>> *To:* Daniel Migault <daniel.miga...@ericsson.com> >>> *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* <rharo...@umich.edu> >>> 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 <dnsop@ietf.org> >>> >>> >>> Looks useful, I will review. >>> >>> -- >>> Bob Harold >>> >>> >>> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat < >>> ietf-secretariat-re...@ietf.org> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
