Subject: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 19:52:23 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-multi-provider-dnssec-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-multi-provider-dnssec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for responding to the SECDIR review by Daniel Migault (and thanks for
doing the review Daniel!)  The proposed clarifications would be helpful.

** Per Section 6.1, “Provider A would generate a new ZSK and communicate their
intent to perform a rollover …”, how is that communication done? Just as the
Security Considerations already talks about API security, is there an analogous
thing to say here in Section 12?

** Section 12.  As key generation is invoked as a step in a number of these
procedures, provide a pointer good practices for this step would be helpful,
say Section 3.4.4 of RFC6781.

** Editorial Nits:
-- A few places.  Typo. s/Authentiated/ Authenticated/g

-- Section 5.1.  Typo. s/prefered/preferred/

-- Section 5.2. Typo. s/Aggresive/Aggressive/

---

From: Shumon Huque <[email-masked]>
Date: Thu, 9 Apr 2020 10:37:58 -0400

On Wed, Apr 8, 2020 at 10:52 PM Roman Danyliw via Datatracker <
[email-masked]> wrote:

Thank you for your review Roman.

> COMMENT:

Yes, I have several clarifications from that review in the pipeline for the
next
update of the draft.

** Per Section 6.1, “Provider A would generate a new ZSK and communicate
> their

That's a good question. We are assuming the zone owner and provider would
either
use a secure out-of-band channel to signal this intent, or the provider API
would have
a relevant function that the zone owner could invoke for this. I'll spell
this out explicitly.

> say Section 3.4.4 of RFC6781.

We reference 6781 in the earlier section on key rollovers. But sure, I
think it would
be a good idea to re-mention it in Security Considerations for more general
practices
covering security relevant topics.

> -- Section 5.2. Typo. s/Aggresive/Aggressive/

Ok.

Shumon Huque