idnits 2.17.1 draft-josefsson-tls-curve25519-03.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '...rves ClientHello extension SHOULD also...' RFC 2119 keyword, line 127: '... Servers MUST NOT select an ECDHE_EC...' RFC 2119 keyword, line 132: '... Private keys MUST be selected as specified in [Curve25519]. That is,...' -- The draft header indicates that this document updates RFC4492, 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 RFC4492, updated by this document, for RFC5378 checks: 1998-03-18) -- 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 (January 11, 2014) is 3757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-04) exists of draft-ladd-safecurves-02 Summary: 4 errors (**), 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. Josefsson 3 Internet-Draft SJD AB 4 Updates: 4492 (if approved) M. Pegourie-Gonnard 5 Intended status: Informational Independant / PolarSSL 6 Expires: July 15, 2014 January 11, 2014 8 Additional Elliptic Curves for Transport Layer Security (TLS) Elliptic 9 Curve Diffie-Hellman Key Agreement 10 draft-josefsson-tls-curve25519-03 12 Abstract 14 This document specifies the use of additional elliptic curves 15 (Curve25519, E382, M383, Curve3617, M511, E521) for key exchange in 16 the Transport Layer Security (TLS) protocol. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 15, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 In [Curve25519], a new elliptic curve function for use in 53 cryptographic applications was specified. Curve25519 is a Diffie- 54 Hellman function designed with performance and security in mind. In 55 [I-D.ladd-safecurves] additional curves are describe with similar 56 properties, but of different strengths. The complete list of curves 57 is Curve25519, E382, M383, Curve3617, M511, and E521. In this 58 document we refer to this list of curves informally as "additional 59 curves". 61 [RFC4492] defines the usage of elliptic curves for authentication and 62 key agreement in TLS 1.0 and TLS 1.1, and these mechanisms are also 63 applicable to TLS 1.2 [RFC5246]. The use of ECC curves for key 64 exchange requires the definition and assignment of additional 65 NamedCurve IDs. This document specify that value for the additional 66 curves, as well as the minor changes in key selection and 67 representation that are required to accomodate for the curves 68 slightly different nature. 70 This document only describes usage of additional curves for ephemeral 71 key exchange (ECDHE), not for use with long-term keys embedded in 72 PKIX certificates (ECDH_ECDSA and ECDH_ECDSA). This is because 73 Curve25519 is not directly suitable for authentication with ECDSA, 74 and thus not applicable for signing of e.g. PKIX certificates. See 75 draft-josefsson-eddsa-ed25519 for a parallel effort. 77 2. Data Structures and Computations 79 [RFC4492] and related standards [SEC1] define an elliptic curve over 80 GF(p) as the set of solutions of the equation y^2 = x^3 + a x + b 81 (commonly referred to as a short Weierstrass equation) with both x 82 and y in GF(p), plus the point at infinity. For each curve, a point 83 G is fixed, generating a subgroup of large (prime) order N. 85 The Diffie-Hellman key exchange is then defined as follows: each 86 party generates a random number 1 <= d < N (the private key), 87 computes Q = d G (the public key). The parties exchange their public 88 keys and compute the shared secret as Z = d Q_peer. 90 [RFC4492] defines formats for representing public keys during the 91 exchange, and extensions for negotiating the format used by each 92 party and the underlying curve used by both parties. 94 While retaining the same overall structure for the Diffie-Hellman key 95 exchange, the additional curves makes some changes to the way the 96 curve equation is presented, private keys are selected and public 97 keys exchanged, in order to ease secure and efficient 98 implementations. 100 The following subsections describe the differences between using 101 additional curves and the curves defined by RFC 4492 for key exchange 102 in TLS. 104 2.1. Group negotiation and new NamedCurve type 106 Curve negotiation is the same for the additional curves as for other 107 curves, but is restricted to using the named_curve type in the 108 ServerKeyEchange message: the explicit_prime type is only suited to 109 curves in short Weierstrass form. This document adds a new 110 NamedCurve value for the additional curves as follows. 112 enum { 113 Curve25519(TBD1), 114 E382(TBD2), 115 M383(TBD3), 116 Curve3617(TBD4), 117 M511(TBD5), 118 E521(TBD6) 119 } NamedCurve; 121 The curves are suitable for use with DTLS [RFC6347]. 123 Since these curves are not designed to be used in signatures, clients 124 who offer ECDHE_ECDSA ciphersuites and advertise support for any of 125 these curves in the elliptic_curves ClientHello extension SHOULD also 126 advertise support for at least one other curve, suitable for ECDSA. 127 Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common 128 curve is one of these curves. 130 2.2. Curve25519 Private key generation 132 Private keys MUST be selected as specified in [Curve25519]. That is, 133 private keys are 255-bits numbers with the following properties: the 134 most significant bit (bit 254) is set, and the three least 135 significants bits are cleared; the remaining bits (3 to 253 included) 136 are chosen uniformly at random. 138 2.3. Curve25519 Public key representation 140 For ECDHE, public keys need to be transmitted in the 141 ServerKeyExchange and ClientKeyExchange messages, both of which 142 encode it as follows. 144 struct { 145 opaque point <1..2^8-1>; 146 } ECPoint; 148 For short Weierstrass curves, the contents of ECPoint.point are 149 defined by X9.62. For Curve25519, the ECpoint structure is the same, 150 but the contents of ECPoint.point are encoded and interpreted as 151 follows: each peer's public key is a number between 0 and 2^255 - 20 152 included, and ECPoint.point contains the 32 bytes string representing 153 this number in big endian convention. (The receiving party can 154 accept any 32 bytes string, interpreted as a 256 bits number, as 155 public key: by design, no validation is needed.) 157 Note that ECPoint.point differs from the definition of public keys in 158 [Curve25519] in two ways: (1) the byte-ordering is big-endian, wich 159 is more uniform with how big integers are represented in TLS, and (2) 160 there is an additional length byte (so ECpoint.point is actually 33 161 bytes), again for uniformity (and extensibility). 163 Since only one point format can be used with Curve25519, which is 164 distinct from the formats used by short Weierstrass curves, the 165 contents of the "Supported Point Formats" extension is irrelevant for 166 this curve. Peers do not need to advertise support for the above 167 point format in any way (nor check that the orther party supports it) 168 when planning to use Curve25519 for key agreement: support for 169 Curve25519 implies support for the above point format, which is tied 170 to it. 172 2.4. Curve25519 Shared secret computation 174 As in the standard Elliptic Curve Diffie-Hellman protocol [SEC1], 175 each party computes the shared secret by multiplying the peer's 176 public value (seen as a point on the curve) by its own private value, 177 except that in the case of Curve25519, only the x coordinate is 178 computed. This is merely an internal detail since [RFC4492] 179 specifies that only the x coordinate is used as the premaster secret 180 anyway. 182 Again, in line with [RFC4492] and as a departure from the convention 183 chosen in [Curve25519], the x coordinate is converted to a bytes 184 string using big endian order. As in [RFC4492], leading zeros are 185 preserved, so the premaster secret is always a 32 bytes string with 186 Curve25519. 188 3. Acknowledgement 190 This document was inspired by the content and structure of [RFC7027]. 192 4. IANA Considerations 194 IANA is requested to assign numbers for the additional curves listed 195 in Section 2.1 to the Transport Layer Security (TLS) Parameters 196 registry EC Named Curve [IANA-TLS] as follows. 198 +-------+-------------+---------+-----------+ 199 | Value | Description | DTLS-OK | Reference | 200 +-------+-------------+---------+-----------+ 201 | TBD1 | Curve25519 | Y | This doc | 202 | | | | | 203 | TBD2 | E382 | Y | This doc | 204 | | | | | 205 | TBD3 | M383 | Y | This doc | 206 | | | | | 207 | TBD4 | Curve3617 | Y | This doc | 208 | | | | | 209 | TBD5 | M511 | Y | This doc | 210 | | | | | 211 | TBD6 | E521 | Y | This doc | 212 +-------+-------------+---------+-----------+ 214 Table 1 216 5. Security Considerations 218 The security considerations of [RFC5246] and most of the security 219 considerations of [RFC4492] apply accordingly. 221 Curve25519 was specifically designed so that secure, fast 222 implementations are easier to produce. In particular, no validation 223 of public keys is required, and point multiplication (using only the 224 x coordinate) can be efficiently [EFD] computed with a Montgomery 225 ladder using a constant number of operations (since the actual bit 226 length of the private key is fixed), which avoids a number of side- 227 channel attacks. However, in the fight against side-channel leaks, 228 implementors should also pay attention to the following points: 230 1. In the Montgomery ladder, avoid branches depending on secret data 231 (the individual bits of the secret key); 233 2. In the same place, avoid memory access patterns dependant on 234 secret data; 236 3. Either avoid data-dependant branches and memory access patterns 237 in the underlying field arithmetic (that is, the bignum 238 arithmetic, including the mod 2^255-19 operation) or randomize 239 projective (that is, x/z) coordinates by multiplying both x and z 240 with the same 256-bit value, chosen at random. 242 Some of the curves defined in [RFC4492], namely all whose name ends 243 with r1 or r2, have been advertised as pseudo-randomly chosen, but 244 the lack of verifiability of the seeds has raised concerns that the 245 those curves might be weaker than expected aginst some attackers. 246 The Koblitz curves (those whose name end with k1) of [RFC4492] do not 247 suffer from this problem, but are char2 curves and there seems to be 248 a consensus that curves over prime fields are a safer bet against 249 future progress in discrete log computation. The Brainpool curves 250 [RFC7027] are prime curves generated in a fully verifiable pseudo- 251 random way to avoid manipulation concerns, but do not perform as well 252 due to the use of pseudo-random primes. Curve22519 is also chosen in 253 a fully verifiable way, but offers better performances (better than 254 the curves form [RFC4492]) while facilitating secure implementations 255 as mentioned above. 257 See also [SafeCurves] and [I-D.ladd-safecurves] for more security 258 discussions. 260 6. References 262 6.1. Normative References 264 [Curve25519] 265 Bernstein, J., "Curve25519: new Diffie-Hellman speed 266 records", 267 WWW http://cr.yp.to/ecdh/curve25519-20060209.pdf, 268 February 2006. 270 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 271 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 272 for Transport Layer Security (TLS)", RFC 4492, May 2006. 274 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 275 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 277 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 278 Security Version 1.2", RFC 6347, January 2012. 280 6.2. Informative References 282 [IANA-TLS] 283 Internet Assigned Numbers Authority, "Transport Layer 284 Security (TLS) Parameters", . 287 [SafeCurves] 288 Bernstein, D. and T. Lange, "SafeCurves: choosing safe 289 curves for elliptic-curve cryptography.", January 2014, 290 . 292 [I-D.ladd-safecurves] 293 Ladd, W., "Additional Elliptic Curves for IETF protocols", 294 draft-ladd-safecurves-02 (work in progress), January 2014. 296 [EFD] Bernstein, D. and T. Lange, "Explicit-Formulas Database: 297 XZ coordinates for Montgomery curves", January 2014, . 300 [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography 301 (ECC) Brainpool Curves for Transport Layer Security 302 (TLS)", RFC 7027, October 2013. 304 [SEC1] Certicom Research, "Standards for Efficient Cryptography 305 (SEC) 1", September 2000. 307 Appendix A. Test vectors 309 This section provides some test vectors for example Diffie-Hellman 310 key exchanges using Curve25519. The following notations are used: 312 d_A the secret key of party A 314 x_A the public key of party A 316 d_B the secret key of party B 318 x_B the public key of party B 320 x_S the shared secret that results from completion of the Diffie- 321 Hellman computation, i.e., the hex representation of the pre- 322 master secret. 324 The field elements x_A, x_B, and x_S are represented as hexadecimal 325 values using the FieldElement-to-OctetString conversion method 326 specified in [SEC1]. 328 d_A = 5AC99F33632E5A768DE7E81BF854C27C46E3FBF2ABBACD29EC4AFF51 329 7369C660 330 d_B = 47DC3D214174820E1154B49BC6CDB2ABD45EE95817055D255AA35831 331 B70D3260 332 x_A = 057E23EA9F1CBE8A27168F6E696A791DE61DD3AF7ACD4EEACC6E7BA5 333 14FDA863 334 x_B = 6EB89DA91989AE37C7EAC7618D9E5C4951DBA1D73C285AE1CD26A855 335 020EEF04 336 x_S = 61450CD98E36016B58776A897A9F0AEF738B99F09468B8D6B8511184 337 D53494AB 339 Authors' Addresses 341 Simon Josefsson 342 SJD AB 344 Email: simon@josefsson.org 346 Manuel Pegourie-Gonnard 347 Independant / PolarSSL 349 Email: mpg@elzevir.fr