idnits 2.17.1 draft-ietf-dcrup-dkim-crypto-09.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 (May 10, 2018) is 2150 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 220 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4-2015' ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 8032 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Updates: 6376 (if approved) May 10, 2018 5 Intended status: Standards Track 6 Expires: November 11, 2018 8 A new cryptographic signature method for DKIM 9 draft-ietf-dcrup-dkim-crypto-09 11 Abstract 13 This document adds a new signing algorithm to DKIM. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on November 11, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 51 3. Ed25519-SHA256 Signing Algorithm . . . . . . . . . . . . . . 3 52 4. Signature and key syntax . . . . . . . . . . . . . . . . . . 3 53 4.1. Signature syntax . . . . . . . . . . . . . . . . . . . . 3 54 4.2. Key syntax . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Key and algorithm choice and strength . . . . . . . . . . . . 4 56 6. Transition Considerations . . . . . . . . . . . . . . . . . . 4 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 8.1. DKIM Key Type registry . . . . . . . . . . . . . . . . . 4 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Example of a signed message . . . . . . . . . . . . 5 64 A.1. Secret key . . . . . . . . . . . . . . . . . . . . . . . 5 65 A.2. Public key DNS record . . . . . . . . . . . . . . . . . . 6 66 A.3. Signed Message . . . . . . . . . . . . . . . . . . . . . 6 67 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Discussion Venue: Discussion about this draft is directed to the 73 dcrup@ietf.org [1] mailing list. 75 DKIM [RFC6376] signs e-mail messages, by creating hashes of the 76 message headers and body and signing the header hash with a digital 77 signature. Message recipients fetch the signature verification key 78 from the DNS. The defining documents specify a single signing 79 algorithm, RSA [RFC3447]. 81 This document adds a new stronger signing algorithm, Edwards-Curve 82 Digital Signature Algorithm using the Curve25519 curve (ed25519), 83 which has much shorter keys than RSA for similar levels of security. 85 2. Conventions Used in This Document 87 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 88 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in 90 [RFC2119]. 92 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. The ABNF 93 tokens sig-a-tag-k and key-k-tag-type are imported from [RFC6376]. 95 3. Ed25519-SHA256 Signing Algorithm 97 The ed25519-sha256 signing algorithm computes a message hash as 98 defined in section 3 of [RFC6376] using SHA-256 [FIPS-180-4-2015] as 99 the hash-alg, and signs it with the PureEDdSA variant Ed25519, as 100 defined in in RFC 8032 section 5.1 [RFC8032]. Example keys and 101 signatures in Appendix XX below are based on the test vectors in RFC 102 8032 section 7.1 [RFC8032]. 104 The DNS record for the verification public key has a "k=ed25519" tag 105 to indicate that the key is an Ed25519 rather than RSA key. 107 This is an additional DKIM signature algorithm added to Section 3.3 108 of [RFC6376] as envisioned in Section 3.3.4 of [RFC6376]. 110 Note: since Ed25519 keys are 256 bits long, the base64 encoded key is 111 only 44 octets, so only DNS key record data will generally fit in a 112 single 255 byte TXT string, and will work with DNS provisioning 113 software that doesn't handle multi-string TXT records. 115 4. Signature and key syntax 117 The syntax of DKIM signatures and DKIM keys are updated as follows. 119 4.1. Signature syntax 121 The syntax of DKIM algorithm tags in section 3.5 of [RFC6376] is 122 updated by adding this rule to the existing rule for sig-a-tag-k: 124 ABNF: 126 sig-a-tag-k =/ "ed25519" 128 4.2. Key syntax 130 The syntax of DKIM key tags in section 3.6.1 of [RFC6376] is updated 131 by adding this rule to the existing rule for key-k-tag-type: 133 ABNF: 135 key-k-tag-type =/ "ed25519" 137 The p= value in the key record is the ed25519 public key encoded in 138 base64. Since the key is 256 bits long, the base64 text is 44 octets 139 long. For example, a key record using the public key in [RFC8032] 140 Section 7.1, Test 1, mignt be: 142 s._domainkey.example TXT ( 143 "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=" 144 ) 146 5. Key and algorithm choice and strength 148 Section 3.3 of [RFC6376] describes DKIM's hash and signature 149 algorithms. It is updated as follows: 151 Signers SHOULD implement and verifiers MUST implement the 152 ed25519-sha256 algorithm. 154 6. Transition Considerations 156 For backward compatibility, signers MAY add multiple signatures that 157 use old and new signing algorithms. Since there can only be a single 158 key record in the DNS for each selector, the signatures will have to 159 use different selectors, although they can use the same d= and i= 160 identifiers. 162 7. Security Considerations 164 Ed25519 is a widely used cryptographic technique, so the security of 165 DKIM signatures using new signing algorithms should be at least as 166 good as those using old algorithms. 168 8. IANA Considerations 170 IANA is requested to update registries as follows. 172 8.1. DKIM Key Type registry 174 The following value is added to the DKIM Key Type Registry 176 +---------+-----------+--------+ 177 | TYPE | REFERENCE | STATUS | 178 +---------+-----------+--------+ 179 | ed25519 | [RFC8032] | active | 180 +---------+-----------+--------+ 182 Table 1: DKIM Key Type Registry Added Values 184 9. References 185 9.1. Normative References 187 [FIPS-180-4-2015] 188 U.S. Department of Commerce, "Secure Hash Standard", FIPS 189 PUB 180-4, August 2015, 190 . 193 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 194 Requirement Levels", BCP 14, RFC 2119, 195 DOI 10.17487/RFC2119, March 1997, 196 . 198 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 199 Standards (PKCS) #1: RSA Cryptography Specifications 200 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 201 2003, . 203 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 204 Specifications: ABNF", STD 68, RFC 5234, 205 DOI 10.17487/RFC5234, January 2008, 206 . 208 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 209 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 210 RFC 6376, DOI 10.17487/RFC6376, September 2011, 211 . 213 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 214 Signature Algorithm (EdDSA)", RFC 8032, 215 DOI 10.17487/RFC8032, January 2017, 216 . 218 9.2. URIs 220 [1] mailto:dcrup@ietf.org 222 Appendix A. Example of a signed message 224 This is a small message with an ed25519-rsa DKIM signature. 226 A.1. Secret key 228 Ed25519 secret key in base64. 230 fL+5V9EquCZAovKik3pA6Lk9zwCzoEtjIuIqK9ZXHHA= 232 A.2. Public key DNS record 234 test._domainkey.example.com IN TXT 235 "k=ed25519; p=yi50DjK5O9pqbFpNHklsv9lqaS0ArSYu02qp1S0DW1Y=" 237 A.3. Signed Message 239 The text in each line of the message start at the first position 240 except for the five continuation lines on the DKIM-Signature which 241 start with a single space. 243 DKIM-Signature: v=1; a=ed25519; c=relaxed/simple; d=example.com; 244 i=@example.com; q=dns/txt; s=test; t=5; h=message-id : 245 date : from : to : subject : date : from : subject; 246 bh=wE7NXSkgnx9PGiavN4OZhJztvkqPDlemV3OGuEnLwNo=; 247 b=wt7P+9DoBwcln1RKE3LN7069ZEEiSyVE/NH1YXnqnJy4JcrSCZUbeIEh 248 vXssPHelX4yNSXG9eTGTwwk5NxYqBw== 249 Received: from localhost 250 Message-ID: 251 Date: Mon, 01 Jan 2011 01:02:03 +0400 252 From: Test User 253 To: somebody@example.com 254 Subject: Testing 256 This is a test message. 258 Appendix B. Change log 260 08 to 09 Specify sha-256 for the extremely literal minded. Take out 261 the prehash stuff. Add example. 263 07 to 08 Specify base64 key records. Style edits per Dave C. 265 06 to 07: Remove RSA fingerprints. Change Pure to hashed eddsa. 267 05 to 06: Editorial changes only. 269 04 to 05: Remove deprecation cruft and inconsistent key advice. Fix 270 p= and k= text. 272 03 to 04: Change eddsa to ed25519. Add Martin's key regeneration 273 issue. Remove hashed ed25519 keys. Fix typos and clarify text. 274 Move syntax updates to separate section. Take out SHA-1 stuff. 276 01 to 02: Clarify EdDSA algorithm is ed25519 with Pure version of 277 the signing. Make references to tags and fields consistent. 279 Author's Address 281 John Levine 282 Taughannock Networks 283 PO Box 727 284 Trumansburg, NY 14886 286 Phone: +883.5100.01196712 287 Email: standards@taugh.com