Skip to main content

Last Call Review of draft-ietf-dcrup-dkim-usage-04
review-ietf-dcrup-dkim-usage-04-secdir-lc-nystrom-2017-09-20-00

Request Review of draft-ietf-dcrup-dkim-usage
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-09-13
Requested 2017-08-30
Authors Scott Kitterman
Draft last updated 2017-09-20
Completed reviews Genart Last Call review of -04 by Jari Arkko (diff)
Secdir Last Call review of -04 by Magnus Nystrom (diff)
Opsdir Last Call review of -04 by Sheng Jiang (diff)
Assignment Reviewer Magnus Nystrom
State Completed
Review review-ietf-dcrup-dkim-usage-04-secdir-lc-nystrom-2017-09-20
Reviewed revision 04 (document currently at 06)
Result Has Issues
Completed 2017-09-20
review-ietf-dcrup-dkim-usage-04-secdir-lc-nystrom-2017-09-20-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This document intends to update the DKIM specification with a new mandatory
hash algorithm (SHA-256) and new RSA key size requirements.

While I definitely agree with the stated direction, I do wonder about the
RSA 1024 bit key size recommendation. Conventionally, this corresponds to
about 80-bit security and to reach the equivalent of 128-bit security
(which is what SHA-256 gives), a 3072-bit RSA key size should be
recommended. In this day and age, mandating only 1024 bits seems a little
weak. I recognize there may be limitations in the DNS records storing these
keys, but it should be possible to store at  least 2048-bit keys (256 bits)
(corresponding roughly to 112-bit security) or at least close to it and
thus why not require 2048 bit RSA keys as a minimum? 1024 bit keys are, as
is also commonly known, considered "legacy" by NIST SP 800-57 part 1 and
shouldn't be used for new signatures at this point.

>
-- Magnus