idnits 2.17.1 draft-dupont-dnsext-ec-tkey-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2539, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2930, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2931, 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 (Using the creation date from RFC2539, updated by this document, for RFC5378 checks: 1997-06-02) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2013) is 4057 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) ** Downref: Normative reference to an Informational RFC: RFC 5114 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group F. Dupont 3 Internet-Draft Internet Systems Consortium 4 Updates: 2930,2539,2931 February 18, 2013 5 (if approved) 6 Intended status: Standards Track 7 Expires: August 22, 2013 9 Modern cryptography TKEY 10 draft-dupont-dnsext-ec-tkey-00 12 Abstract 14 This document updates the TKEY resource record specifications for the 15 use of Elliptic Curve Diffie-Hellman, and related IANA registries. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 22, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The TKEY resource record [RFC2930] was designed to enable the 52 establishment of a shared secret between DNS client and server, using 53 GSS-API or a Diffie-Hellman exchange. 55 The purpose of this document is to modernize the cryptography used by 56 the Diffie-Hellman variant of TKEY, i.e., to move to ECDH (Elliptic 57 Curve Diffie-Hellman). As a side effect, registries for the DH KEY 58 [RFC2539] and SIG(0) [RFC2931] resource records are updated. 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC2119 [RFC2119]. 64 2. ECDH groups 66 This document specifies a new "well-known group" with a 1536 bit 67 prime for the DH KEY resource record [RFC2539], taken from the 68 expired revision [I-D.ietf-dnsext-rfc2539bis-dhk], in the Appendix A. 69 (this group is supported by some implementations, the idea is to make 70 it official) 72 The NIST P-256 and P-384 curve groups are added as groups 13 and 14. 73 These groups are already used in several IETF RFCs, including 74 [RFC5114], or for DNSSEC [RFC6605]. A public key is the uncompressed 75 form of a curve point, so on twice 256 or 384 bits. The shared 76 secret is the first coordinate of the Diffie-Hellman common value, so 77 on 256 or 384 bits. 79 3. ECDH TKEY 81 The ECDH TKEY reuses the DH TKEY (RFC2930 [RFC2930] section 4.1) 82 specification with some changes. 84 The Diffie-Hellman exchange uses the Elliptic Curve P-256 group, the 85 hash function is SHA-256. 87 The "key data" lengths MUST be at least 128 bits / 16 octets, and 88 SHOULD be at most 256 bits / 32 octets. 90 The "keying material" is derived using the formula (taken from IKEv2 91 [RFC4306]): 93 keymat = HMAC-SHA-256(query data | server data, ECDH value) 95 4. IANA Considerations 97 The "DNS KEY Record Diffie-Hellman Well-Known Prime/Generator Pairs" 98 registry is modified by the addition of entries for 3, 13 and 14, 99 with "A 1536 bit prime", "EC P-256" and "EC P-384" for descriptions, 100 and this document for the reference. 102 The "DNS Security Algorithm Numbers" registry is modified by adding 103 TKEY in the "transaction security mechanisms" and by making 104 ECDSAP256SHA256 and ECDSAP384SHA384 eligible for transaction 105 security. 107 The "SIG (0) Algorithm Numbers" registry is either updated / aligned 108 with the preceding one, or simply suppressed as its content was 109 merged into the preceding one. 111 5. Security Considerations 113 The Elliptic Curve cryptography is considered as being as safe as the 114 modular prime field one but with faster operations and far smaller 115 payloads, so should be a vector for better security. 117 In the same way, more support and use of TKEY should be encouraged. 118 This is why it had to be re-based on modern cryptography tools. 120 To share a private key for two different usages is recognized as a 121 bad practice, so when an ECDH TKEY is authenticated by 122 ECDSAP256SHA256, the private key SHOULD NOT be shared. 124 6. Acknowledgments 126 Donald E. Eastlake 3rd is the author of the expired DH KEY revision 127 [I-D.ietf-dnsext-rfc2539bis-dhk] where the well-known group 3 was 128 taken. 130 7. References 132 7.1. Normative References 134 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 135 Requirement Levels", BCP 14, RFC 2119, March 1997. 137 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the 138 Domain Name System (DNS)", RFC 2539, March 1999. 140 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY 141 RR)", RFC 2930, September 2000. 143 [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( 144 SIG(0)s)", RFC 2931, September 2000. 146 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 147 Groups for Use with IETF Standards", RFC 5114, 148 January 2008. 150 7.2. Informative References 152 [I-D.ietf-dnsext-rfc2539bis-dhk] 153 Eastlake, D., "Storage of Diffie-Hellman Keying 154 Information in the DNS", 155 draft-ietf-dnsext-rfc2539bis-dhk-08 (work in progress), 156 October 2006. 158 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 159 RFC 4306, December 2005. 161 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 162 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 163 April 2012. 165 Appendix A. Well-Known Group 3: A 1536 bit prime 167 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. 169 Its decimal value is: 171 241031242692103258855207602219756607485695054850245994265411 172 694195810883168261222889009385826134161467322714147790401219 173 650364895705058263194273070680500922306273474534107340669624 174 601458936165977404102716924945320037872943417032584377865919 175 814376319377685986952408894019557734611984354530154704374720 176 774996976375008430892633929555996888245787241299381012913029 177 459299994792636526405928464720973038494721168143446471443848 178 8520940127459844288859336526896320919633919 180 Prime modulus Length (32 bit words): 48, Data (hex): 182 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 183 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 184 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 185 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 186 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 187 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 188 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 189 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 191 Generator: Length (32 bit words): 1, Data (hex): 2 193 Author's Address 195 Francis Dupont 196 Internet Systems Consortium 198 Email: fdupont@isc.org