idnits 2.17.1 draft-ietf-dcrup-dkim-usage-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6376, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2017) is 2371 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 186 ** Downref: Normative reference to an Informational RFC: RFC 8017 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kitterman 3 Internet-Draft Kitterman Technical Services 4 Updates: 6376 (if approved) October 27, 2017 5 Intended status: Standards Track 6 Expires: April 30, 2018 8 Cryptographic Algorithm and Key Usage Update to DKIM 9 draft-ietf-dcrup-dkim-usage-05 11 Abstract 13 The cryptographic algorithm and key size requirements included when 14 DKIM was designed in the last decade are functionally obsolete and in 15 need of immediate revision. This document updates DKIM requirements 16 to those minimaly suitable for operation with currently specified 17 algorithms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 56 4. DKIM Signing and Verification Algorithms . . . . . . . . . . 3 57 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 7.2. Informative References . . . . . . . . . . . . . . . . . 4 63 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Discussion Venue 69 RFC EDITOR: Please remove this section before publication. 71 Discussion about this draft is directed to the dcrup@ietf.org [1] 72 mailing list. 74 2. Introduction 76 DKIM [RFC6376] signs e-mail messages, by creating hashes of the 77 message headers and content and signing the header hash with a 78 digital signature. Message recipients fetch the signature 79 verification key from the DNS where it is stored in a TXT record. 81 The defining documents specify a single signing algorithm, RSA 82 [RFC8017], and recommends key sizes of 1024 to 2048 bits (but require 83 verification of 512 bit keys). As discussed in US-CERT VU#268267 84 [VULNOTE], the operational community has recognized that shorter keys 85 compromise the effectiveness of DKIM. While 1024 bit signatures are 86 common, stronger signatures are not. Widely used DNS configuration 87 software places a practical limit on key sizes, because the software 88 only handles a single 256 octet string in a TXT record, and RSA keys 89 significantly longer than 1024 bits don't fit in 256 octets. 91 Due to the recognized weakness of the sha1 hash algorithm, see 92 [RFC6194], and the wide availability of the sha256 hash algorithm (it 93 has been a required part of DKIM [RFC6376] since it was originally 94 standardized in 2007), the sha1 hash algorithm MUST NOT be used. 96 This is being done now to allow the operational community time to 97 fully shift to sha256 in advance of any sha1 related crisis. 99 3. Conventions Used in This Document 101 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 102 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 4. DKIM Signing and Verification Algorithms 108 This section updates [RFC6376] Section 3.3. 110 DKIM supports multiple digital signature algorithms. Two algorithms 111 are defined by this specification at this time: rsa-sha1 and rsa- 112 sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able 113 to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or 114 verifying. 116 DKIM signatures signed with historic algorithms (currently rsa-sha1) 117 or with insufficient key sizes (currently rsa-sha256 with less than 118 1024 bits) have permanently failed evaluation as discussed in 119 [RFC6376] Section 3.9. 121 4.1. Key Sizes 123 Selecting appropriate key sizes is a trade-off between cost, 124 performance, and risk. Since short RSA keys more easily succumb to 125 off-line attacks, Signers MUST use RSA keys of at least 1024 bits for 126 all keys. Signers SHOULD use RSA keys of at least 2048 bits. 127 Verifiers MUST be able to validate signatures with keys ranging from 128 1024 bits to 4096 bits, and they MAY be able to validate signatures 129 with larger keys. Verifier policies can use the length of the 130 signing key as one metric for determining whether a signature is 131 acceptable. Verifiers MUST NOT consider signatures using RSA keys of 132 less than 1024 bits as valid signatures. 134 5. Security Considerations 136 This document does not change the Security Considerations of 137 [RFC6376]. It reduces the risk of signature compromise due to weak 138 cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are 139 resolved due to rsa-sha1 no longer being used by DKIM. 141 6. IANA Considerations 143 IANA is requested to update the "sha1" registration in the "DKIM Hash 144 Algorithms" as follows: 146 +------+-----------+----------+ 147 | TYPE | REFERENCE | STATUS | 148 +------+-----------+----------+ 149 | sha1 | [RFC6376] | historic | 150 +------+-----------+----------+ 152 Table 1: DKIM Hash Algorithms Changed Value 154 7. References 156 7.1. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 160 RFC2119, March 1997, 161 . 163 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 164 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 165 RFC 6376, DOI 10.17487/RFC6376, September 2011, 166 . 168 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 169 "PKCS #1: RSA Cryptography Specifications Version 2.2", 170 RFC 8017, DOI 10.17487/RFC8017, November 2016, 171 . 173 7.2. Informative References 175 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 176 Considerations for the SHA-0 and SHA-1 Message-Digest 177 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 178 . 180 [VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys 181 Identified Mail (DKIM) Verifiers may inappropriately 182 convey message trust", October 2012. 184 7.3. URIs 186 [1] mailto:dcrup@ietf.org 188 Appendix A. Acknowledgements 190 The author wishes to acknowledge the following for their review and 191 comment on this proposal: Kurt Andersen, Murray S. Kucherawy, Martin 192 Thomson, John Levine, Russ Housley, and Jim Fenton. 194 Thanks to John Levine his DCRUP work that was the source for much of 195 the introductory material in this draft. 197 Author's Address 199 Scott Kitterman 200 Kitterman Technical Services 201 3611 Scheel Dr 202 Ellicott City, MD 21042 204 Phone: +1 301 325-5475 205 Email: scott@kitterman.com