Skip to main content

A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
RFC 8463

Yes

(Alexey Melnikov)
(Terry Manderson)

No Objection

Alvaro Retana
(Deborah Brungard)
(Eric Rescorla)
(Ignas Bagdonas)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)

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

Alvaro Retana No Objection

Warren Kumari No Objection

Comment (2018-06-18 for -13)
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.

(Adam Roach; former steering group member) Yes

Yes (2018-06-18 for -13)
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.

(Alexey Melnikov; former steering group member) Yes

Yes (for -10)

                            

(Ben Campbell; former steering group member) Yes

Yes (2018-06-19 for -13)
Adam beat me to the RFC 8174 boilerplate comment.

(Spencer Dawkins; former steering group member) Yes

Yes (2018-06-20 for -13)
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; former steering group member) Yes

Yes (for -13)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2018-06-20 for -13)
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; former steering group member) (was Discuss) No Objection

No Objection (2018-06-16 for -13)
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.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -13)

                            

(Eric Rescorla; former steering group member) No Objection

No Objection (for -13)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -13)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -13)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -13)

                            

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -13)