idnits 2.17.1 draft-ietf-dcrup-dkim-usage-00.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 (May 30, 2017) is 2522 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 70 == Missing Reference: 'FIPS-180-3-2008' is mentioned on line 108, 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) May 30, 2017 5 Intended status: Standards Track 6 Expires: December 1, 2017 8 Cryptographic Algorithm and Key Usage to DKIM 9 draft-ietf-dcrup-dkim-usage-00 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 1, 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. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 5.1. DKIM Hash Algorithms . . . . . . . . . . . . . . . . . . 4 63 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Discussion Venue: Discussion about this draft is directed to the 70 dcrup@ietf.org [1] mailing list. 72 DKIM [RFC6376] signs e-mail messages, by creating hashes of the 73 message headers and content and signing the header hash with a 74 digital signature. Message recipients fetch the signature 75 verification key from the DNS where it is stored in a TXT record. 76 The defining documents specify a single signing algorithm, RSA 77 [RFC8017], and recommends key sizes of 1024 to 2048 bits (but require 78 verification of 512 bit keys). While 1024 bit signatures are common, 79 stronger signatures are not. Widely used DNS configuration software 80 places a practical limit on key sizes, because the software only 81 handles a single 256 octet string in a TXT record, and RSA keys 82 longer than 1024 bits don't fit in 256 octets. 84 2. Conventions Used in This Document 86 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 87 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in 89 [RFC2119]. 91 3. DKIM Signing and Verification Algorithms 93 This section replaces [RFC6376] Section 3.3 in its entirety. 95 DKIM supports multiple digital signature algorithms. Two algorithms 96 were defined by [RFC6376]: rsa-sha1 and rsa-sha256. Signers MUST 97 implement and sign using rsa-sha256. Verifiers MUST implement rsa- 98 sha256. The rsa-sha1 signing algorithm is obsolete and MUST NOT be 99 used. 101 3.1. The rsa-sha1 Signing Algorithm 103 This algorithm is obsolete and MUST NOT be used. 105 3.2. The rsa-sha256 Signing Algorithm 107 The rsa-sha256 Signing Algorithm computes a message hash as described 108 in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the 109 hash-alg. That hash is then signed by the Signer using the RSA 110 algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg 111 and the Signer's private key. The hash MUST NOT be truncated or 112 converted into any form other than the native binary form before 113 being signed. The signing algorithm SHOULD use a public exponent of 114 65537. 116 3.3. Key Sizes 118 Selecting appropriate key sizes is a trade-off between cost, 119 performance, and risk. Since short RSA keys more easily succumb to 120 off-line attacks, Signers MUST use RSA keys of at least 1024 bits for 121 all keys. Verifiers MUST be able to validate signatures with keys 122 ranging from 1024 bits to 4096 bits, and they MAY be able to validate 123 signatures with larger keys. Verifier policies can use the length of 124 the signing key as one metric for determining whether a signature is 125 acceptable. 127 Factors that should influence the key size choice include the 128 following: 130 o The practical constraint that large (e.g., 4096-bit) keys might 131 not fit within a 512-byte DNS UDP response packet 133 o The security constraint that keys smaller than 2048 bits may be 134 subject to off-line attacks 136 o Larger keys impose higher CPU costs to verify and sign email 138 o Keys can be replaced on a regular basis; thus, their lifetime can 139 be relatively short 141 o The security goals of DKIM,[RFC6376], are modest compared to 142 typical goals of other systems that employ digital signatures 144 See [RFC3766] for further discussion on selecting key sizes. 146 3.4. Other Algorithms 148 Other algorithms will be defined in the future. Verifiers MUST 149 ignore any signatures using algorithms that they do not implement. 151 4. Security Considerations 153 This document does not change the Security Considerations of 154 [RFC6376]. It reduces the risk of signature compromise due to weak 155 cryptography. 157 5. IANA Considerations 159 IANA is requested to update registries as follows. 161 5.1. DKIM Hash Algorithms 163 The following value is changed in the DKIM Hash Algorithms 165 +------+-----------------+----------+ 166 | TYPE | REFERENCE | STATUS | 167 +------+-----------------+----------+ 168 | sha1 | (this document) | obsolete | 169 +------+-----------------+----------+ 171 Table 1: DKIM Hash Algorithms Changed Value 173 6. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 177 RFC2119, March 1997, 178 . 180 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 181 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 182 RFC 3766, DOI 10.17487/RFC3766, April 2004, 183 . 185 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 186 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 187 RFC 6376, DOI 10.17487/RFC6376, September 2011, 188 . 190 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 191 "PKCS #1: RSA Cryptography Specifications Version 2.2", 192 RFC 8017, DOI 10.17487/RFC8017, November 2016, 193 . 195 Appendix A. Acknowledgements 197 The author wishes to acknowledge the following for their review and 198 constructive criticism of this proposal: TBD (surely there will be 199 someone). 201 Thanks to John Levine for draft-ietf-dcrup-dkim-crypto-00, which was 202 the source for much of the introductory material in this draft. 204 Author's Address 206 Scott Kitterman 207 Kitterman Technical Services 208 3611 Scheel Dr 209 Ellicott City, MD 21042 211 Phone: +1 301 325-5475 212 Email: scott@kitterman.com