idnits 2.17.1 draft-ietf-dcrup-dkim-usage-01.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 : ---------------------------------------------------------------------------- No issues found here. 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 (June 5, 2017) is 2517 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 74 == Missing Reference: 'FIPS-180-3-2008' is mentioned on line 114, but not defined ** Downref: Normative reference to an Informational RFC: RFC 8017 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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) June 5, 2017 5 Intended status: Standards Track 6 Expires: December 7, 2017 8 Cryptographic Algorithm and Key Usage Update to DKIM 9 draft-ietf-dcrup-dkim-usage-01 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. This document updates RFC 6376. 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 December 7, 2017. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. DKIM Signing and Verification Algorithms . . . . . . . . . . 3 56 3.1. The rsa-sha1 Signing Algorithm . . . . . . . . . . . . . 3 57 3.2. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3 58 3.3. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.4. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4 60 4. The DKIM-Signature Header Field . . . . . . . . . . . . . . . 4 61 5. Key Management and Representation . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. DKIM Hash Algorithms . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 Discussion Venue: Discussion about this draft is directed to the 74 dcrup@ietf.org [1] mailing list. 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. 80 The defining documents specify a single signing algorithm, RSA 81 [RFC8017], and recommends key sizes of 1024 to 2048 bits (but require 82 verification of 512 bit keys). As discussed in US-CERT VU#268267 83 [VULNOTE], the operational community has recognized that shorter keys 84 compromise the effectiveness of DKIM. While 1024 bit signatures are 85 common, stronger signatures are not. Widely used DNS configuration 86 software places a practical limit on key sizes, because the software 87 only handles a single 256 octet string in a TXT record, and RSA keys 88 longer than 1024 bits don't fit in 256 octets. 90 2. Conventions Used in This Document 92 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 93 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. 97 3. DKIM Signing and Verification Algorithms 99 This section replaces [RFC6376] Section 3.3 in its entirety. 101 DKIM supports multiple digital signature algorithms. Two algorithms 102 were defined by [RFC6376]: rsa-sha1 and rsa-sha256. Signers MUST 103 implement and sign using rsa-sha256. Verifiers MUST implement rsa- 104 sha256. The rsa-sha1 signing algorithm is obsolete and MUST NOT be 105 used. 107 3.1. The rsa-sha1 Signing Algorithm 109 This algorithm is obsolete and MUST NOT be used. 111 3.2. The rsa-sha256 Signing Algorithm 113 The rsa-sha256 Signing Algorithm computes a message hash as described 114 in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the 115 hash-alg. That hash is then signed by the Signer using the RSA 116 algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg 117 and the Signer's private key. The hash MUST NOT be truncated or 118 converted into any form other than the native binary form before 119 being signed. The signing algorithm SHOULD use a public exponent of 120 65537. 122 3.3. Key Sizes 124 Selecting appropriate key sizes is a trade-off between cost, 125 performance, and risk. Since short RSA keys more easily succumb to 126 off-line attacks, Signers MUST use RSA keys of at least 1024 bits for 127 all keys. Verifiers MUST be able to validate signatures with keys 128 ranging from 1024 bits to 4096 bits, and they MAY be able to validate 129 signatures with larger keys. Verifier policies can use the length of 130 the signing key as one metric for determining whether a signature is 131 acceptable. 133 Factors that should influence the key size choice include the 134 following: 136 o The practical constraint that large (e.g., 4096-bit) keys might 137 not fit within a 512-byte DNS UDP response packet 139 o The security constraint that keys smaller than 2048 bits may be 140 subject to off-line attacks 142 o Larger keys impose higher CPU costs to verify and sign email 144 o Keys can be replaced on a regular basis; thus, their lifetime can 145 be relatively short 147 o The security goals of DKIM,[RFC6376], are modest compared to 148 typical goals of other systems that employ digital signatures 150 See [RFC3766] for further discussion on selecting key sizes. 152 3.4. Other Algorithms 154 Other algorithms will be defined in the future. Verifiers MUST 155 ignore any signatures using algorithms that they do not implement. 157 4. The DKIM-Signature Header Field 159 This section updates the a= tag in [RFC6376] Section 3.5. 161 The text description of the tag is now: 163 a= The algorithm used to generate the signature (plain-text; 164 REQUIRED). Verifiers MUST support "rsa-sha256"; Signers MUST 165 sign using "rsa-sha256". See [RFC6376] Section 3.3 (as updated 166 by this document) for a description of the algorithms. 168 The following ABNF element is updated: 170 ABNF: 172 sig-a-tag-h = "sha256" / x-sig-a-tag-h 174 5. Key Management and Representation 176 This section updates the h= tag in [RFC6376] Section 3.6.1. 178 The following ABNF element is updated: 180 ABNF: 182 key-h-tag-alg = "sha256" / x-key-h-tag-alg 184 6. Security Considerations 185 This document does not change the Security Considerations of 186 [RFC6376]. It reduces the risk of signature compromise due to weak 187 cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are 188 resolved. 190 7. IANA Considerations 192 IANA is requested to update registries as follows. 194 7.1. DKIM Hash Algorithms 196 The following value is changed in the DKIM Hash Algorithms 198 +------+-----------------+----------+ 199 | TYPE | REFERENCE | STATUS | 200 +------+-----------------+----------+ 201 | sha1 | (this document) | obsolete | 202 +------+-----------------+----------+ 204 Table 1: DKIM Hash Algorithms Changed Value 206 8. References 208 8.1. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 212 RFC2119, March 1997, 213 . 215 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 216 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 217 RFC 3766, DOI 10.17487/RFC3766, April 2004, 218 . 220 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 221 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 222 RFC 6376, DOI 10.17487/RFC6376, September 2011, 223 . 225 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 226 "PKCS #1: RSA Cryptography Specifications Version 2.2", 227 RFC 8017, DOI 10.17487/RFC8017, November 2016, 228 . 230 8.2. Informative References 232 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 233 Considerations for the SHA-0 and SHA-1 Message-Digest 234 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 235 . 237 [VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys 238 Identified Mail (DKIM) Verifiers may inappropriately 239 convey message trust", October 2012. 241 Appendix A. Acknowledgements 243 The author wishes to acknowledge the following for their review and 244 constructive criticism of this proposal: TBD (surely there will be 245 someone). 247 Thanks to John Levine for draft-ietf-dcrup-dkim-crypto-00, which was 248 the source for much of the introductory material in this draft. 250 Author's Address 252 Scott Kitterman 253 Kitterman Technical Services 254 3611 Scheel Dr 255 Ellicott City, MD 21042 257 Phone: +1 301 325-5475 258 Email: scott@kitterman.com