Subject: [Dcrup] Genart last call review of draft-ietf-dcrup-dkim-crypto-12

From: Pete Resnick <[email-masked]>
Date: Mon, 11 Jun 2018 09:22:23 -0700

Reviewer: Pete Resnick
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dcrup-dkim-crypto-12
Reviewer: Pete Resnick
Review Date: 2018-06-11
IETF LC End Date: 2018-06-12
IESG Telechat date: 2018-06-21

Summary: Nice simple document; Ready to go with nits.

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

Nit: You should update the 2119 template to the 8174 template.

Comment: If this kind of update is only going to happen every 6 or 7 years, I
guess it's fine, but all that this document really does is: - Trivially update
the ABNF - Add the algorithm to the registry - Update the normative
instructions to indicate that this new algorithm be used. That really could
have all be done with a registry update if the registry had a field for
normative instructions for use of the algorithm. I suppose it's no longer a big
deal to add one more document to the eight-odd-thousand RFCs, but still...

pr

---

From: "John R. Levine" <[email-masked]>
Date: 15 Jun 2018 20:19:44 -0400

I think the -13 addresses the last call comments.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Jun 2018 16:23:09 -0400

John:

How hard would it be to expand section 6 to include an example of two selectors being used, one with RSA and one with ed25519?  If it is pretty easy, I think it would help the reader.

Russ

> On Jun 15, 2018, at 8:19 PM, John R. Levine <[email-masked]> wrote:
> 
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Jun 2018 16:37:30 -0400

I think we have that in the current revision in Appendix A.3.  Do we need to 
specifically refer to that in Section 6?

Scott K

On Monday, June 18, 2018 04:23:09 PM Russ Housley wrote:
> John:
> 
> How hard would it be to expand section 6 to include an example of two
> selectors being used, one with RSA and one with ed25519?  If it is pretty
> easy, I think it would help the reader.
> 
> Russ
> 
> > John Levine, [email-masked], Primary Perpetrator of "The Internet for
> > Dummies", Please consider the environment before reading this e-mail.
> > https://jl.ly
> >

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Jun 2018 17:38:55 -0400

Frankly, I missed it.  The intro text to A.3 provides no hint that the example is showing two signatures using different algorithms.

The text is repeated below so that other readers do not need to look it up.

Russ

= = = = = = = =

A.3.  Signed Message

   The text in each line of the message starts at the first position
   except for the continuation lines on the DKIM-Signature headers which
   start with a single space.  A blank line follows the "Joe." line.

   DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
    d=football.example.com; i=@football.example.com;
    q=dns/txt; s=brisbane; t=1528637909; h=from : to :
    subject : date : message-id : from : subject : date;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=/gCrinpcQOoIfuHNQIbq4pgh9kyIK3AQUdt9OdqQehSwhEIug4D11Bus
    Fa3bT3FY5OsU7ZbnKELq+eXdp1Q1Dw==
   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=football.example.com; i=@football.example.com;
    q=dns/txt; s=test; t=1528637909; h=from : to : subject :
    date : message-id : from : subject : date;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=F45dVWDfMbQDGHJFlXUNB2HKfbCeLRyhDXgFpEL8GwpsRe0IeIixNTe3
    DhCVlUrSjV4BwcVcOF6+FF3Zo9Rpo1tFOeS9mPYQTnGdaSGsgeefOsk2Jz
    dA+L10TeYt9BgDfQNZtKdN1WO//KgIqXP7OdEFE4LjFYNcUxZQ4FADY+8=
   From: Joe SixPack <[email-masked]>
   To: Suzie Q <[email-masked]>
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: <[email-masked]>

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

> On Jun 18, 2018, at 4:37 PM, Scott Kitterman <[email-masked]> wrote:
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Jun 2018 17:45:48 -0400

OK.  Maybe added to the end of the paragraph in section 6:

Current:

6.  Transition Considerations

   For backward compatibility, signers can add multiple signatures that
   use old and new signing algorithms.  Since there can only be a single
   key record in the DNS for each selector, the signatures have to use
   different selectors, although they can use the same d= and i=
   identifiers.

Proposed:

6.  Transition Considerations

   For backward compatibility, signers can add multiple signatures that
   use old and new signing algorithms.  Since there can only be a single
   key record in the DNS for each selector, the signatures have to use
   different selectors, although they can use the same d= and i=
   identifiers.  Appendix A.3 shows an example message signed with both
   ed25519-sha256 and rsa-sha256 with the same d= and i=, but unique
   selectors (s=brisbane and s=test respectively).

Scott K

On Monday, June 18, 2018 05:38:55 PM Russ Housley wrote:
> Frankly, I missed it.  The intro text to A.3 provides no hint that the
> example is showing two signatures using different algorithms.
> 
> > I think we have that in the current revision in Appendix A.3.  Do we need
> > to specifically refer to that in Section 6?
> > 
> > Scott K
> >

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 Jun 2018 17:47:59 -0400

That would resolve my issue completely.

Russ

> On Jun 18, 2018, at 5:45 PM, Scott Kitterman <[email-masked]> wrote:
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 18 Jun 2018 18:01:34 -0400

OK.

John??  Versions are cheap, after all.

Scott K

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 20 Jun 2018 15:00:32 -0400

Pete, thanks for your review. I think the whole point of chartering DCRUP was to produce documents such as this.

John, thanks for updating to reference RFC 8174, although I agree with Adam that the boilerplate should match 8174.

Thanks,
Alissa

> On Jun 11, 2018, at 12:22 PM, Pete Resnick <[email-masked]> wrote:
> 
> Reviewer: Pete Resnick
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "John R. Levine" <[email-masked]>
Date: 20 Jun 2018 15:38:24 -0400

> John, thanks for updating to reference RFC 8174, although I agree with Adam that the boilerplate should match 8174.

It's fixed in the copy I have here, waiting to see what other nits to 
fix show up in LC before posting the final.

By the way, there are comments in the XML pointing out the stuff to 
remove, which have been there all along.

R's,
John

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 21 Jun 2018 10:25:17 -0400

> On Jun 20, 2018, at 3:38 PM, John R. Levine <[email-masked]> wrote:
> 
> It's fixed in the copy I have here, waiting to see what other nits to fix show up in LC before posting the final.
> 
> By the way, there are comments in the XML pointing out the stuff to remove, which have been there all along.

Ok. I don’t read the XML when doing my IESG reviews.

Alissa

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jun 2018 15:30:08 +0100

Hi John,

> fix show up in LC before posting the final.

Please post a new revision. The document is approved pending a new revision (or an email from you saying that none is needed).

Thank you,
Alexey

---

From: "John R. Levine" <[email-masked]>
Date: 21 Jun 2018 11:43:52 -0400

> Please post a new revision. The document is approved pending a new revision (or an email from you saying that none is needed).

I posted -14 which I think addresses the comments.

Changed security section to point to 8032 for ed25519 rather than RSA.

Added a sentence noting the two independent signatures.

Fixed the MUSTard boiletplate.

Whew!

Regards,