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

[Ballot comment]
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."

[Ballot comment]
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. 

?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
This is basically pro-forma and should be easy to resolve: as pointed out in the secdir review,
"this is widely used, therefore it must be secure" does  not hold any weight.  The security
considerations should be adjusted to provide some actual justification of the primitive's
security or not make such a claim.

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

In addition to the above DISCUSS point, there were some other good remarks in the secdir
review (though I'm not sure about the "DKIM Hash Algorithms Registry" part) -- it would be
good to see a reply to them as well.

Section 3's Note may want to clarify that it is the public keys that
are 256 bits long (the relevant part, since those are what go in the
DNS).

In Section 4.2:

Typo, "mignt" for "might".
And maybe there's a better way to format the example than with a
selector of just "s"?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dcrup-dkim-crypto-12. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the DKIM Key Type registry on the DomainKeys Identified Mail (DKIM) Parameters registry page located at:

https://www.iana.org/assignments/dkim-parameters/

a single, new Key Type is to be registered as follows:

Type: ed25519
Reference: [RFC8032]
Status: active

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-06-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-dcrup-dkim-crypto@ietf.org, alexey.melnikov@isode.com, dcrup@ietf.org, fenton@bluepopcorn.net, dcrup-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A new cryptographic signature method for DKIM) to Proposed Standard


The IESG has received a request from the DKIM Crypto Update WG (dcrup) to
consider the following document: - 'A new cryptographic signature method for
DKIM'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-06-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document adds a new signing algorithm to DKIM.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3025/

Document shepherd writeup for draft-ietf-dcrup-dkim-crypto-09

1. Summary

The Document Shepherd for this document is Jim Fenton. The responsible Area Director is Alexey Melnikov.

DKIM [RFC6376] signs e-mail messages, by creating hashes of the message headers and body and signing the header hash with a digital signature.  Message recipients fetch the signature verification key from the DNS.  The defining documents specify a single signing algorithm, RSA [RFC3447].

This document adds a new stronger signing algorithm, Edwards-Curve Digital Signature Algorithm using the Curve25519 curve (ed25519), which has much shorter keys than RSA for similar levels of security. This is important in overcoming the practical limitations in storing long keys in DNS.

Publication is being requested as a Proposed Standard ("Standards Track" in the draft).

2. Review and Consensus

This document represents the consensus of the dcrup working group. The need for longer DKIM signing keys has become more acute as compute power (and therefore the ability to factor short RSA keys) increases. Initially, two approaches were considered: (1) publication of key fingerprints (hashes), rather than RSA keys in DNS; (2) use of the ed25519 signing algorithm, which has shorter keys for equivalent cryptographic strength. Ultimately, approach (1) was discarded because (2) was sufficient to satisfy the goals of the specification. There was also significant dicussion on the format to be used for publishing ed25529 public keys in DNS; a "raw key" format was adopted (without ASN1/DER wrapping).

The specification has received extensive review from significant members of the email community and input (such as algorithm selection) from WG technical advisor Eric Rescorla.

Multiple interoperating implementations exist, including dkimpy-milter, exim, NoSpamProxy, and OpenDKIM.

3. Intellectual property

One IPR disclosure (#3025) was filed regarding this draft, but this is no longer applicable because the disclosure related to the use of RSA fingerprints, which has been removed in an earlier revision.

No other IPR claims are known.

4. Other Points

This document contains a normative reference to RFC 8032, an informational RFC that describes ed25519. This is consistent with current practice; RFC 8032 is already listed on the Downref Registry because of a similar reference in RFC 8037.

This document also contains a normative reference to RFC 3447, which has been obsoleted by RFC 8017.

All references are listed as normative; it is possible that there is at least one informative reference (most likely the reference to RFC 3447).

There is also a reference to a NIST FIPS standard. While not an IETF document, we consider it sufficiently stable to be normatively referenced in a standards-track document.

Section 9.2 (URIs) and the Discussion Venue reference in the introduction should be removed by the RFC editor at publication.

In the opinion of the shepherd, the document is ready for publication.