idnits 2.17.1 draft-ietf-dcrup-dkim-usage-06.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 (November 3, 2017) is 2365 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 199 ** 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) November 3, 2017 5 Intended status: Standards Track 6 Expires: May 7, 2018 8 Cryptographic Algorithm and Key Usage Update to DKIM 9 draft-ietf-dcrup-dkim-usage-06 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 May 7, 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. DKIM Signing and Verification Algorithms . . . . . . . . 3 58 4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 7.2. Informative References . . . . . . . . . . . . . . . . . 4 64 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Discussion Venue 70 RFC EDITOR: Please remove this section before publication. 72 Discussion about this draft is directed to the dcrup@ietf.org [1] 73 mailing list. 75 2. Introduction 77 DKIM [RFC6376] signs e-mail messages, by creating hashes of the 78 message headers and content and signing the header hash with a 79 digital signature. Message recipients fetch the signature 80 verification key from the DNS where it is stored in a TXT record. 82 The defining documents specify a single signing algorithm, RSA 83 [RFC8017], and recommends key sizes of 1024 to 2048 bits (but require 84 verification of 512 bit keys). As discussed in US-CERT VU#268267 85 [VULNOTE], the operational community has recognized that shorter keys 86 compromise the effectiveness of DKIM. While 1024 bit signatures are 87 common, stronger signatures are not. Widely used DNS configuration 88 software places a practical limit on key sizes, because the software 89 only handles a single 256 octet string in a TXT record, and RSA keys 90 significantly longer than 1024 bits don't fit in 256 octets. 92 Due to the recognized weakness of the sha1 hash algorithm, see 93 [RFC6194], and the wide availability of the sha256 hash algorithm (it 94 has been a required part of DKIM [RFC6376] since it was originally 95 standardized in 2007), the sha1 hash algorithm MUST NOT be used. 97 This is being done now to allow the operational community time to 98 fully shift to sha256 in advance of any sha1 related crisis. 100 3. Conventions Used in This Document 102 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 103 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 4. DKIM Signing and Verification Algorithms 109 Section 4.1 updates [RFC6376] Section 3.3. 111 Section 4.2 updates [RFC6376] Section 3.3.3. 113 The algorithm described in[RFC6376] Section 3.3.1 is now historic and 114 no longer used by DKIM. 116 [RFC6376] Sections 3.3.2 and 3.3.4 are not affected. 118 4.1. DKIM Signing and Verification Algorithms 120 DKIM supports multiple digital signature algorithms. Two algorithms 121 are defined by this specification at this time: rsa-sha1 and rsa- 122 sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able 123 to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or 124 verifying. 126 DKIM signatures identified as having been signed with historic 127 algorithms (currently rsa-sha1) have permanently failed evaluation as 128 discussed in [RFC6376] Section 3.9. 130 4.2. Key Sizes 132 Selecting appropriate key sizes is a trade-off between cost, 133 performance, and risk. Since short RSA keys more easily succumb to 134 off-line attacks, Signers MUST use RSA keys of at least 1024 bits for 135 all keys. Signers SHOULD use RSA keys of at least 2048 bits. 136 Verifiers MUST be able to validate signatures with keys ranging from 137 1024 bits to 4096 bits, and they MAY be able to validate signatures 138 with larger keys. Verifier policies can use the length of the 139 signing key as one metric for determining whether a signature is 140 acceptable. Verifiers MUST NOT consider signatures using RSA keys of 141 less than 1024 bits as valid signatures. 143 DKIM signatures with insufficient key sizes (currently rsa-sha256 144 with less than 1024 bits) have permanently failed evaluation as 145 discussed in [RFC6376] Section 3.9. 147 5. Security Considerations 149 This document does not change the Security Considerations of 150 [RFC6376]. It reduces the risk of signature compromise due to weak 151 cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are 152 resolved due to rsa-sha1 no longer being used by DKIM. 154 6. IANA Considerations 156 IANA is requested to update the "sha1" registration in the "DKIM Hash 157 Algorithms" as follows: 159 +------+-----------+----------+ 160 | TYPE | REFERENCE | STATUS | 161 +------+-----------+----------+ 162 | sha1 | [RFC6376] | historic | 163 +------+-----------+----------+ 165 Table 1: DKIM Hash Algorithms Changed Value 167 7. References 169 7.1. Normative References 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 173 RFC2119, March 1997, 174 . 176 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 177 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 178 RFC 6376, DOI 10.17487/RFC6376, September 2011, 179 . 181 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 182 "PKCS #1: RSA Cryptography Specifications Version 2.2", 183 RFC 8017, DOI 10.17487/RFC8017, November 2016, 184 . 186 7.2. Informative References 188 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 189 Considerations for the SHA-0 and SHA-1 Message-Digest 190 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 191 . 193 [VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys 194 Identified Mail (DKIM) Verifiers may inappropriately 195 convey message trust", October 2012. 197 7.3. URIs 199 [1] mailto:dcrup@ietf.org 201 Appendix A. Acknowledgements 203 The author wishes to acknowledge the following for their review and 204 comment on this proposal: Kurt Andersen, Murray S. Kucherawy, Martin 205 Thomson, John Levine, Russ Housley, and Jim Fenton. 207 Thanks to John Levine for his DCRUP work that was the source for much 208 of the introductory material in this draft. 210 Author's Address 212 Scott Kitterman 213 Kitterman Technical Services 214 3611 Scheel Dr 215 Ellicott City, MD 21042 217 Phone: +1 301 325-5475 218 Email: scott@kitterman.com