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

From: IETF Secretariat <[email-masked]>
Date: Mon, 04 May 2020 12:11:04 -0700

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/

---

From: Bob Harold <[email-masked]>
Date: Mon, 4 May 2020 16:28:29 -0400

Looks useful, I will review.

-- 
Bob Harold

On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <
[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 5 May 2020 10:32:22 -0400

Hi,

As a co-author, I am supporting the draft. I believe the document is
useful to encourage enabling DNSSEC validation on resolvers.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Tue, 5 May 2020 15:52:02 +0000

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
[https://avatars1.githubusercontent.com/u/6602698?s=400&v=4]<https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35>
bob's comment · mglt/draft-mglt-dnsop-dnssec-validator-requirements@f8ab674<https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35>
Contribute to mglt/draft-mglt-dnsop-dnssec-validator-requirements development by creating an account on GitHub.
github.com

________________________________
From: Bob Harold <[email-masked]>
Sent: Monday, May 4, 2020 4:29 PM
To: Daniel Migault <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>>

--
Bob Harold

On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Daniel Migault <[email-masked]>
Date: Tue, 5 May 2020 12:02:18 -0400

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.

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=
[email-masked]> wrote:

> Avoiding the configuration file to be updated prevents old configuration
> file to survive to writing error on read-only file systems.
>
>
> [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
>
> <https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35>
> bob's comment · mglt/draft-mglt-dnsop-dnssec-validator-requirements@f8ab674
> <https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35>
> Contribute to mglt/draft-mglt-dnsop-dnssec-validator-requirements
> development by creating an account on GitHub.
> github.com
>
>
>
> ------------------------------
> *From:* Bob Harold <[email-masked]>
> *Sent:* Monday, May 4, 2020 4:29 PM
> *To:* Daniel Migault <[email-masked]>
> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed
> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption
> By WG Issued"
>
> Minor nits:
>
> Avoiding the configuration file to be updated prevents old configuration
> file to survive to writing error on read-only file systems.
> </mglt>
>
> "disable the signature check for that key the time" > "disable the
> signature check for that key until the time"
> <mglt>
> addressed
> </mglt>
>
> From: *Bob Harold* <[email-masked]>
> 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 <[email-masked]>
>
>

-- 
Daniel Migault
Ericsson

---

From: Bob Harold <[email-masked]>
Date: Tue, 5 May 2020 14:52:59 -0400

On Tue, May 5, 2020 at 12:02 PM Daniel Migault <[email-masked]> wrote:

> 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

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?)

-- 
Bob Harold

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 May 2020 12:15:56 -0400

On Tue, May 5, 2020 at 2:53 PM Bob Harold <[email-masked]> wrote:

>> Thanks for the comments. The new version of the file is available here
>> [1] and a diff is available at [2].
>>
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

-- 
Daniel Migault
Ericsson

---

From: Bob Harold <[email-masked]>
Date: Wed, 6 May 2020 12:47:48 -0400

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

>> 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.

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

>>>> [1] and diff can be seen at [2].
>>>>
>>>> Avoiding the configuration file to be updated prevents old
>>>> configuration file to survive to writing error on read-only file systems.
>>>>
>>>>
>>>> Avoiding the configuration file to be updated prevents old
>>>> configuration file to survive to writing error on read-only file systems.
>>>> </mglt>
>>>>