A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
draft-ietf-dcrup-dkim-crypto-14

Note: This ballot was opened for revision 10 and is now closed.

(Ben Campbell) Yes

Comment (2018-06-19 for -13)
No email
send info
Adam beat me to the RFC 8174 boilerplate comment.

(Spencer Dawkins) Yes

Comment (2018-06-20 for -13)
No email
send info
Just one nit. In 

   DKIM [RFC6376] signs e-mail messages, by creating hashes of the
   message headers and body and signing the header hash with a digital
   signature.  

would it be more correct to say 

   DKIM [RFC6376] is used to sign e-mail messages, by creating hashes of the
   message headers and body and signing the header hash with a digital
   signature.  

?

(Terry Manderson) Yes

Alexey Melnikov Yes

Adam Roach Yes

Comment (2018-06-18 for -13)
No email
send info
Thanks to the authors and working group for the work put in on this document.
I have two editorial updates to suggest.

---------------------------------------------------------------------------

The draft header indicates that this document updates RFC 6376, but the
abstract doesn't seem to mention this, which it should.

---------------------------------------------------------------------------

§2:

>  The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>  "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
>  "OPTIONAL" in this document are to be interpreted as described in
>  [RFC8174].

This text is almost, but not quite, the boilerplate from RFC 8174. Please update
this paragraph to match the boilerplate.

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-06-20 for -13)
No email
send info
Seems like this can be removed from Sec. 1: 
"Discussion Venue:    Discussion about this draft is directed to the
      dcrup@ietf.org [1] mailing list."

Benjamin Kaduk (was Discuss) No Objection

Comment (2018-06-16 for -13)
No email
send info
Thanks for the quick update letting me resolve my DISCUSS!

Thanks for writing this document; it will be good to have ed25519 available for DKIM.

There were some remarks in the secdir review that I don't remember seeing a response
to yet (though I'm not sure about the "DKIM Hash Algorithms Registry" part) -- it would be
good to see a reply to them as well as the updates already made.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-06-18 for -13)
No email
send info
Section 7.  Security Considerations
"Ed25519 is a widely used cryptographic technique, so the security of DKIM signatures using new signing algorithms should be at least as good as those using old algorithms."

Could this be reworded? This might just be a pet peeve, but as it is written, it is, I believe, false[0].

This says that, because lots of people use something, it must be good / secure. That's like saying that because lots of people drink instant coffee it must be at least as good as real coffee.  Adding something like "and has received lots of review from the cryptographic community", or "doesn't seem to have any weaknesses", or something would help.
Oh, the Change Log "11 to 12" entry wins!
W

[0]: I bought a box of commas on sale this weekend.

Mirja Kühlewind No Objection

(Eric Rescorla) No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection