idnits 2.17.1 draft-ietf-tls-negotiated-ff-dhe-10.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 abstract seems to contain references ([RFC5246], [RFC4492], [RFC2246], [RFC4346]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4346, but the abstract doesn't seem to directly say this. It does mention RFC4346 though, so this could be OK. -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to directly say this. It does mention RFC5246 though, so this could be OK. -- The draft header indicates that this document updates RFC2246, but the abstract doesn't seem to directly say this. It does mention RFC2246 though, so this could be OK. -- The draft header indicates that this document updates RFC4492, but the abstract doesn't seem to directly say this. It does mention RFC4492 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2246, updated by this document, for RFC5378 checks: 1996-12-03) -- 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 (June 1, 2015) is 3245 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 758 ** Downref: Normative reference to an Experimental draft: draft-bmoeller-tls-falsestart (ref. 'FALSE-START') ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Gillmor 3 Internet-Draft ACLU 4 Updates: 4492, 5246, 4346, 2246 (if June 1, 2015 5 approved) 6 Intended status: Standards Track 7 Expires: December 3, 2015 9 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS 10 draft-ietf-tls-negotiated-ff-dhe-10 12 Abstract 14 Traditional finite-field-based Diffie-Hellman (DH) key exchange 15 during the TLS handshake suffers from a number of security, 16 interoperability, and efficiency shortcomings. These shortcomings 17 arise from lack of clarity about which DH group parameters TLS 18 servers should offer and clients should accept. This document offers 19 a solution to these shortcomings for compatible peers by using a 20 section of the TLS "EC Named Curve Registry" to establish common 21 finite-field DH parameters with known structure and a mechanism for 22 peers to negotiate support for these groups. 24 This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 25 [RFC5246], as well as the TLS ECC extensions [RFC4492]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 3, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Named Group Overview . . . . . . . . . . . . . . . . . . . . 4 65 3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Client Local Policy on Custom Groups . . . . . . . . . . 6 67 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Checking the Peer's Public Key . . . . . . . . . . . . . 8 70 5.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 8 71 5.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 8 72 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 73 6.1. Preference Ordering . . . . . . . . . . . . . . . . . . . 9 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 9.1. Negotiation resistance to active attacks . . . . . . . . 10 78 9.2. Group strength considerations . . . . . . . . . . . . . . 11 79 9.3. Finite-Field DHE only . . . . . . . . . . . . . . . . . . 12 80 9.4. Deprecating weak groups . . . . . . . . . . . . . . . . . 12 81 9.5. Choice of groups . . . . . . . . . . . . . . . . . . . . 12 82 9.6. Timing attacks . . . . . . . . . . . . . . . . . . . . . 13 83 9.7. Replay attacks from non-negotiated FFDHE . . . . . . . . 13 84 9.8. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 13 85 9.9. False Start . . . . . . . . . . . . . . . . . . . . . . . 14 86 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 87 10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 14 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 11.2. Informative References . . . . . . . . . . . . . . . . . 15 91 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 17 93 A.1. ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . . 17 94 A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 18 95 A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 20 96 A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 21 97 A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 23 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 100 1. Introduction 102 Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key 103 exchange mode which provides Forward Secrecy for the connection. The 104 client offers a ciphersuite in the ClientHello that includes DHE, and 105 the server offers the client group parameters generator g and modulus 106 p. If the client does not consider the group strong enough (e.g., if 107 p is too small, or if p is not prime, or there are small subgroups 108 that cannot be easily avoided), or if it is unable to process the 109 group for other reasons, the client has no recourse but to terminate 110 the connection. 112 Conversely, when a TLS server receives a suggestion for a DHE 113 ciphersuite from a client, it has no way of knowing what kinds of DH 114 groups the client is capable of handling, or what the client's 115 security requirements are for this key exchange session. For 116 example, some widely-distributed TLS clients are not capable of DH 117 groups where p > 1024 bits. Other TLS clients may by policy wish to 118 use DHE only if the server can offer a stronger group (and are 119 willing to use a non-PFS key-exchange mechanism otherwise). The 120 server has no way of knowing which type of client is connecting, but 121 must select DH parameters with insufficient knowledge. 123 Additionally, the DH parameters selected by the server may have a 124 known structure which renders them secure against a small subgroup 125 attack, but a client receiving an arbitrary p and g has no efficient 126 way to verify that the structure of a new group is reasonable for 127 use. 129 This modification to TLS solves these problems by using a section of 130 the "EC Named Curves" registry to select common DH groups with known 131 structure and defining the use of the "elliptic_curves(10)" extension 132 (described here as "Supported Groups" extension) for clients 133 advertising support for DHE with these groups. This document also 134 provides guidance for compatible peers to take advantage of the 135 additional security, availability, and efficiency offered. 137 The use of this mechanism by one compatible peer when interacting 138 with a non-compatible peer should have no detrimental effects. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. The term 145 "PRIVATE USE" is to be interpreted as described in [RFC5226]. 147 1.2. Vocabulary 149 The terms "DHE" or "FFDHE" are used in this document to refer to the 150 finite-field-based Diffie-Hellman ephemeral key exchange mechanism in 151 TLS. TLS also supports elliptic-curve-based Diffie-Hellman (ECDHE) 152 ephemeral key exchanges [RFC4492], but this document does not 153 document their use. A registry previously used only by ECHDE-capable 154 implementations is expanded in this document to cover FFDHE groups as 155 well. "FFDHE ciphersuites" is used in this document to refer 156 exclusively to ciphersuites with FFDHE key exchange mechanisms, but 157 note that these suites are typically labeled with a TLS_DHE_ prefix. 159 2. Named Group Overview 161 We use previously-unallocated codepoints within the extension 162 currently known as "elliptic_curves" (section 5.1.1. of [RFC4492]) to 163 indicate known finite field groups. The extension's semantics are 164 expanded from "Supported Elliptic Curves" to "Supported Groups". The 165 semantics of the extension's data type (enum NamedCurve) is also 166 expanded from "named curve" to "named group". 168 Additionally, we explicitly relax the requirement about when the 169 Supported Groups extension can be sent. This extension MAY be sent 170 by the client when either FFDHE or ECDHE ciphersuites are listed. 172 Codepoints in the NamedCurve registry with a high byte of 0x01 (that 173 is, between 256 and 511 inclusive) are set aside for FFDHE groups, 174 though only a small number of them are initially defined and we do 175 not expect many other FFDHE groups to be added to this range. No 176 codepoints outside of this range will be allocated to FFDHE groups. 177 The new code points for the NamedCurve registry are: 179 enum { 180 // other already defined elliptic curves (see RFC 4492) 181 ffdhe2048(256), ffdhe3072(257), ffdhe4096(258), 182 ffdhe6144(259), ffdhe8192(260), 183 // 184 } NamedCurve; 186 These additions to the Named Curve registry are described in detail 187 in Appendix A. They are all safe primes derived from the base of the 188 natural logarithm ("e"), with the high and low 64 bits set to 1 for 189 efficient Montgomery or Barrett reduction. 191 The use of the base of the natural logarithm here is as a "nothing- 192 up-my-sleeve" number. The goal is to guarantee that the bits in the 193 middle of the modulus are effectively random, while avoiding any 194 suspicion that the primes have secretly been selected to be weak 195 according to some secret criteria. [RFC3526] used pi for this value. 196 See Section 9.5 for reasons that this draft does not reuse pi. 198 3. Client Behavior 200 A TLS client that is capable of using strong finite field Diffie- 201 Hellman groups can advertise its capabilities and its preferences for 202 stronger key exchange by using this mechanism. 204 The compatible client that wants to be able to negotiate strong FFDHE 205 sends a "Supported Groups" extension (identified by type 206 elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a 207 list of known FFDHE groups in the extension data, ordered from most 208 preferred to least preferred. If the client also supports and wants 209 to offer ECDHE key exchange, it MUST use a single "Supported Groups" 210 extension to include all supported groups (both ECDHE and FFDHE 211 groups). The ordering SHOULD be based on client preference, but see 212 Section 6.1 for more nuance. 214 A client that offers a "Supported Groups" extension containing an 215 FFDHE group SHOULD also include at least one FFDHE ciphersuite in the 216 Client Hello. 218 A client that offers a group MUST be able and willing to perform a DH 219 key exchange using that group. 221 A client that offers one or more FFDHE groups in the "Supported 222 Groups" extension and an FFDHE ciphersuite, and receives an FFDHE 223 ciphersuite from the server SHOULD take the following steps upon 224 receiving the ServerKeyExchange: 226 For non-anonymous ciphersuites where the offered Certificate is 227 valid and appropriate for the peer, validate the signature over 228 the ServerDHParams. If not valid, terminate the connection. 230 If the signature over ServerDHParams is valid, compare the 231 selected dh_p and dh_g with the FFDHE groups offered by the 232 client. If none of the offered groups match, the server is not 233 compatible with this draft. The client MAY decide to continue the 234 connection if the selected group is acceptable under local policy, 235 or it MAY decide to terminate the connection with a fatal 236 insufficient_security(71) alert. 238 If the client continues (either because the server offered a 239 matching group, or because local policy permits the offered custom 240 group), the client MUST verify that dh_Ys is in the range 1 < 241 dh_Ys < dh_p - 1. If dh_Ys is not in this range, the client MUST 242 terminate the connection with a fatal handshake_failure(40) alert. 244 If dh_Ys is in range, then the client SHOULD continue with the 245 connection as usual. 247 3.1. Client Local Policy on Custom Groups 249 Compatible clients that are willing to accept FFDHE ciphersuites from 250 non-compatible servers may have local policy about what custom FFDHE 251 groups they are willing to accept. This local policy presents a risk 252 to clients, who may accept weakly-protected communications from 253 misconfigured servers. 255 This draft cannot enumerate all possible safe local policy (the 256 safest may be to simply reject all custom groups), but compatible 257 clients that accept some custom groups from the server MUST do at 258 least cursory checks on group size, and may take other properties 259 into consideration as well. 261 A compatible client that accepts FFDHE ciphersuites using custom 262 groups from non-compatible servers MUST reject any group with |dh_p| 263 < 768 bits, and SHOULD reject any group with |dh_p| < 1024 bits. 265 A compatible client that rejects a non-compatible server's custom 266 group may decide to retry the connection while omitting all FFDHE 267 ciphersuites from the ClientHello. A client SHOULD only use this 268 approach if it successfully verified the server's expected signature 269 over the ServerDHParams, to avoid being forced by an active attacker 270 into a non-preferred ciphersuite. 272 4. Server Behavior 274 If a compatible TLS server receives a Supported Groups extension from 275 a client that includes any FFDHE group (i.e. any codepoint between 276 256 and 511 inclusive, even if unknown to the server), and if none of 277 the client-proposed FFDHE groups are known and acceptable to the 278 server, then the server MUST NOT select an FFDHE ciphersuite. In 279 this case, the server SHOULD select an acceptable non-FFDHE 280 ciphersuite from the client's offered list. If the extension is 281 present with FFDHE groups, none of the client's offered groups are 282 acceptable by the server, and none of the client's proposed non-FFDHE 283 ciphersuites are acceptable to the server, the server MUST end the 284 connection with a fatal TLS alert of type insufficient_security(71). 286 If at least one FFDHE ciphersuite is present in the client 287 ciphersuite list, and the Supported Groups extension is either absent 288 from the ClientHello entirely or contains no FFDHE groups (i.e. no 289 codepoints between 256 and 511 inclusive), then the server knows that 290 the client is not compatible with this document. In this scenario, a 291 server MAY select a non-FFDHE ciphersuite, or MAY select an FFDHE 292 ciphersuite and offer an FFDHE group of its choice to the client as 293 part of a traditional ServerKeyExchange. 295 A compatible TLS server that receives the Supported Groups extension 296 with FFDHE codepoints in it, and which selects an FFDHE ciphersuite 297 MUST select one of the client's offered groups. The server indicates 298 the choice of group to the client by sending the group's parameters 299 as usual in the ServerKeyExchange as described in section 7.4.3 of 300 [RFC5246]. 302 A TLS server MUST NOT select a named FFDHE group that was not offered 303 by a compatible client. 305 A TLS server MUST NOT select an FFDHE ciphersuite if the client did 306 not offer one, even if the client offered an FFDHE group in the 307 Supported Groups extension. 309 If a non-anonymous FFDHE ciphersuite is selected, and the TLS client 310 has used this extension to offer an FFDHE group of comparable or 311 greater strength than the server's public key, the server SHOULD 312 select an FFDHE group at least as strong as the server's public key. 313 For example, if the server has a 3072-bit RSA key, and the client 314 offers only ffdhe2048 and ffdhe4096, the server SHOULD select 315 ffdhe4096. 317 When an FFDHE ciphersuite is selected, and the client sends a 318 ClientKeyExchange, the server MUST verify that 1 < dh_Yc < dh_p - 1. 319 If dh_Yc is out of range, the server MUST terminate the connection 320 with fatal handshake_failure(40) alert. 322 5. Optimizations 324 In a key exchange with a successfully negotiated known FFDHE group, 325 both peers know that the group in question uses a safe prime as a 326 modulus, and that the group in use is of size p-1 or (p-1)/2. This 327 allows at least three optimizations that can be used to improve 328 performance. 330 5.1. Checking the Peer's Public Key 332 Peers MUST validate each other's public key Y (dh_Ys offered by the 333 server or dh_Yc offered by the client) by ensuring that 1 < Y < p-1. 334 This simple check ensures that the remote peer is properly behaved 335 and isn't forcing the local system into the 2-element subgroup. 337 To reach the same assurance with an unknown group, the client would 338 need to verify the primality of the modulus, learn the factors of 339 p-1, and test both the generator g and Y against each factor to avoid 340 small subgroup attacks. 342 5.2. Short Exponents 344 Traditional Finite Field Diffie-Hellman has each peer choose their 345 secret exponent from the range [2,p-2]. Using exponentiation by 346 squaring, this means each peer must do roughly 2*log_2(p) 347 multiplications, twice (once for the generator and once for the 348 peer's public key). 350 Peers concerned with performance may also prefer to choose their 351 secret exponent from a smaller range, doing fewer multiplications, 352 while retaining the same level of overall security. Each named group 353 indicates its approximate security level, and provides a lower-bound 354 on the range of secret exponents that should preserve it. For 355 example, rather than doing 2*2*3072 multiplications for a ffdhe3072 356 handshake, each peer can choose to do 2*2*275 multiplications by 357 choosing their secret exponent from the range [2^274,2^275] (that is, 358 a m-bit integer where m is at least 275) and still keep the same 359 approximate security level. 361 A similar short-exponent approach is suggested in SSH's Diffie- 362 Hellman key exchange (See section 6.2 of [RFC4419]). 364 5.3. Table Acceleration 366 Peers wishing to further accelerate FFDHE key exchange can also pre- 367 compute a table of powers of the generator of a known group. This is 368 a memory vs. time tradeoff, and it only accelerates the first 369 exponentiation of the ephemeral DH exchange (the fixed-base 370 exponentiation). The variable-base exponentiation (using the peer's 371 public exponent as a base) still needs to be calculated as normal. 373 6. Operational Considerations 374 6.1. Preference Ordering 376 The ordering of named groups in the Supported Groups extension may 377 contain some ECDHE groups and some FFDHE groups. These SHOULD be 378 ranked in the order preferred by the client. 380 However, the ClientHello also contains list of desired ciphersuites, 381 also ranked in preference order. This presents the possibility of 382 conflicted preferences. For example, if the ClientHello contains a 383 CipherSuite with two choices in order 384 and the Supported Groups 386 Extension contains two choices in order then 387 there is a clear contradiction. Clients SHOULD NOT present such a 388 contradiction since it does not represent a sensible ordering. A 389 server that encounters such an contradiction when selecting between 390 an ECDHE or FFDHE key exchange mechanism while trying to respect 391 client preferences SHOULD give priority to the Supported Groups 392 extension (in the example case, it should select 393 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp256r1), but MAY resolve 394 the contradiction any way it sees fit. 396 More subtly, clients MAY interleave preferences between ECDHE and 397 FFDHE groups, for example if stronger groups are preferred regardless 398 of cost, but weaker groups are acceptable, the Supported Groups 399 extension could consist of: 400 . In this example, with the 401 same CipherSuite offered as the previous example, a server configured 402 to respect client preferences and with support for all listed groups 403 SHOULD select TLS_DHE_RSA_WITH_AES_128_CBC_SHA with ffdhe8192. A 404 server configured to respect client preferences and with support for 405 only secp384p1 and ffdhe3072 SHOULD select 406 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp384p1. 408 7. Acknowledgements 410 Thanks to Fedor Brunner, Dave Fergemann, Niels Ferguson, Sandy 411 Harris, Tero Kivinen, Watson Ladd, Nikos Mavrogiannopolous, Niels 412 Moeller, Bodo Moeller, Kenny Paterson, Eric Rescorla, Tom Ritter, 413 Rene Struik, Martin Thomson, Sean Turner, and other members of the 414 TLS Working Group for their comments and suggestions on this draft. 415 Any mistakes here are not theirs. 417 8. IANA Considerations 419 IANA maintains the registry currently known as EC Named Curves 420 (originally defined in [RFC4492] and updated by [RFC7027]) at [1]. 422 This document expands the semantics of this registry slightly, to 423 include groups based on finite fields in addition to groups based on 424 elliptic curves. IANA should add a range designation to that 425 registry, indicating that values from 256-511 (inclusive) are set 426 aside for "Finite Field Diffie-Hellman groups", and that all other 427 entries in the registry are "Elliptic curve groups". 429 This document allocates five well-defined codepoints in the registry 430 for specific Finite Field Diffie-Hellman groups defined in 431 Appendix A. 433 In addition, the four highest codepoints in this range (508-511, 434 inclusive) are designated for PRIVATE USE by peers who have 435 privately-developed Finite Field Diffie-Hellman groups that they wish 436 to signal internally. 438 The updated registry section should be as follows: 440 +---------------------+-------------+---------+-----------------+ 441 | Value | Description | DTLS-OK | Reference | 442 +---------------------+-------------+---------+-----------------+ 443 | 256 | ffdhe2048 | Y | [this document] | 444 | 257 | ffdhe3072 | Y | [this document] | 445 | 258 | ffdhe4096 | Y | [this document] | 446 | 259 | ffdhe6144 | Y | [this document] | 447 | 260 | ffdhe8192 | Y | [this document] | 448 | 508-511 (inclusive) | PRIVATE USE | - | - | 449 +---------------------+-------------+---------+-----------------+ 451 9. Security Considerations 453 9.1. Negotiation resistance to active attacks 455 Because the contents of the Supported Groups extension are hashed in 456 the finished message, an active MITM that tries to filter or omit 457 groups will cause the handshake to fail, but possibly not before 458 getting the peer to do something they would not otherwise have done. 460 An attacker who impersonates the server can try to do any of the 461 following: 463 Pretend that a non-compatible server is actually capable of this 464 extension, and select a group from the client's list, causing the 465 client to select a group it is willing to negotiate. It is 466 unclear how this would be an effective attack. 468 Pretend that a compatible server is actually non-compatible by 469 negotiating a non-FFDHE ciphersuite. This is no different than 470 MITM ciphersuite filtering. 472 Pretend that a compatible server is actually non-compatible by 473 negotiating a DHE ciphersuite, with a custom (perhaps weak) group 474 selected by the attacker. This is no worse than the current 475 scenario, and would require the attacker to be able to sign the 476 ServerDHParams, which should not be possible without access to the 477 server's secret key. 479 An attacker who impersonates the client can try to do the following: 481 Pretend that a compatible client is not compatible (e.g., by not 482 offering the Supported Groups extension, or by replacing the 483 Supported Groups extension with one that includes no FFDHE 484 groups). This could cause the server to negotiate a weaker DHE 485 group during the handshake, or to select a non-FFDHE ciphersuite, 486 but it would fail to complete during the final check of the 487 Finished message. 489 Pretend that a non-compatible client is compatible (e.g., by 490 adding the Supported Groups extension, or by adding FFDHE groups 491 to the extension). This could cause the server to select a 492 particular named group in the ServerKeyExchange, or to avoid 493 selecting an FFDHE ciphersuite. The peers would fail to compute 494 the final check of the Finished message. 496 Change the list of groups offered by the client (e.g., by removing 497 the stronger of the set of groups offered). This could cause the 498 server to negotiate a weaker group than desired, but again should 499 be caught by the check in the Finished message. 501 9.2. Group strength considerations 503 TLS implementations using FFDHE key exchange should consider the 504 strength of the group they negotiate. The strength of the selected 505 group is one of the factors that define the connection's resiliance 506 against attacks on the session's confidentiality and integrity, since 507 the session keys are derived from the DHE handshake. 509 While attacks on integrity must generally happen while the session is 510 in progress, attacks against session confidentiality can happen 511 significantly later, if the entire TLS session is stored for offline 512 analysis. Therefore, FFDHE groups should be selected by clients and 513 servers based on confidentiality guarantees they need. Sessions 514 which need extremely long-term confidentiality should prefer stronger 515 groups. 517 [ENISA] provides rough estimates of group resistance to attack, and 518 recommends that forward-looking implementations ("future systems") 519 should use FFDHE group sizes of at least 3072 bits. ffdhe3072 is 520 intended for use in these implementations. 522 Other sources (e.g., [NIST]) estimate the security levels of the DLOG 523 problem to be slightly more difficult than [ENISA]. This document's 524 suggested minimum exponent sizes in Appendix A for implementations 525 that use the short exponents optimization (Section 5.2) are 526 deliberately conservative to account for the range of these 527 estimates. 529 9.3. Finite-Field DHE only 531 Note that this document specifically targets only finite field-based 532 Diffie-Hellman ephemeral key exchange mechanisms. It does not cover 533 the non-ephemeral DH key exchange mechanisms, nor does it address 534 elliptic curve DHE (ECDHE) key exchange, which is defined in 535 [RFC4492]. 537 Measured by computational cost to the TLS peers, ECDHE appears today 538 to offer much a stronger key exchange mechanism than FFDHE. 540 9.4. Deprecating weak groups 542 Advances in hardware or in finite field cryptanalysis may cause some 543 of the negotiated groups to not provide the desired security margins, 544 as indicated by the estimated work factor of an adversary to discover 545 the premaster secret (and may therefore compromise the 546 confidentiality and integrity of the TLS session). 548 Revisions of this document should mark known-weak groups as 549 explicitly deprecated for use in TLS, and should update the estimated 550 work factor needed to break the group, if the cryptanalysis has 551 changed. Implementations that require strong confidentiality and 552 integrity guarantees should avoid using deprecated groups and should 553 be updated when the estimated security margins are updated. 555 9.5. Choice of groups 557 Other lists of named finite field Diffie-Hellman groups 558 [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for 559 several reasons: 561 Using the same groups in multiple protocols increases the value 562 for an attacker with the resources to crack any single group. 564 The IKE groups include weak groups like MODP768 which are 565 unacceptable for secure TLS traffic. 567 Mixing group parameters across multiple implementations leaves 568 open the possibility of some sort of cross-protocol attack. This 569 shouldn't be relevant for ephemeral scenarios, and even with non- 570 ephemeral keying, services shouldn't share keys; however, using 571 different groups avoids these failure modes entirely. 573 9.6. Timing attacks 575 Any implementation of finite field Diffie-Hellman key exchange should 576 use constant-time modular-exponentiation implementations. This is 577 particularly true for those implementations that ever re-use DHE 578 secret keys (so-called "semi-static" ephemeral keying) or share DHE 579 secret keys across a multiple machines (e.g., in a load-balancer 580 situation). 582 9.7. Replay attacks from non-negotiated FFDHE 584 [SECURE-RESUMPTION], [CROSS-PROTOCOL], and [SSL3-ANALYSIS] all show a 585 malicious peer using a bad FFDHE group to maneuver a client into 586 selecting a pre-master secret of the peer's choice, which can be 587 replayed to another server using a non-FFDHE key exchange, and can 588 then be bootstrapped to replay client authentication. 590 To prevent this attack (barring the fixes proposed in 591 [SESSION-HASH]), a client would need not only to implement this 592 draft, but also to reject non-negotiated FFDHE ciphersuites whose 593 group structure it cannot afford to verify. Such a client would need 594 to abort the initial handshake and reconnect to the server in 595 question without listing any FFDHE ciphersuites on the subsequent 596 connection. 598 This tradeoff may be too costly for most TLS clients today, but may 599 be a reasonable choice for clients performing client certificate 600 authentication, or who have other reason to be concerned about 601 server-controlled pre-master secrets. 603 9.8. Forward Secrecy 605 One of the main reasons to prefer FFDHE ciphersuites is Forward 606 Secrecy, the ability to resist decryption even if when the endpoint's 607 long-term secret key (usually RSA) is revealed in the future. 609 This property depends on both sides of the connection discarding 610 their ephemeral keys promptly. Implementations should wipe their 611 FFDHE secret key material from memory as soon as it is no longer 612 needed, and should never store it in persistent storage. 614 Forward secrecy also depends on the strength of the Diffie-Hellman 615 group; using a very strong symmetric cipher like AES256 with a 616 forward-secret ciphersuite, but generating the keys with a much 617 weaker group like dhe2048 simply moves the adversary's cost from 618 attacking the symmetric cipher to attacking the dh_Ys or dh_Yc 619 ephemeral keyshares. 621 If the goal is to provide forward secrecy, attention should be paid 622 to all parts of the ciphersuite selection process, both key exchange 623 and symmetric cipher choice. 625 9.9. False Start 627 Clients capable of TLS False Start [FALSE-START] may receive a 628 proposed FFDHE group from a server that is attacker-controlled. In 629 particular, the attacker can modify the ClientHello to strip the 630 proposed FFDHE groups, which may cause the server to offer a weaker 631 FFDHE group than it should, and this will not be detected until 632 receipt of the server's Finished message. This could cause a client 633 using the False Start protocol modification to send data encrypted 634 under a weak key agreement. 636 Clients should have their own classification of FFDHE groups that are 637 "cryptographically strong" in the same sense described in the 638 description of symmetric ciphers in [FALSE-START], and SHOULD offer 639 at least one of these in the initial handshake if they contemplate 640 using the False Start protocol modification with an FFDHE 641 ciphersuite. 643 Compatible clients performing a full handshake MUST NOT use the False 644 Start protocol modification if the server selects an FFDHE 645 ciphersuite but sends a group that is not cryptographically strong 646 from the client's perspective. 648 10. Privacy Considerations 650 10.1. Client fingerprinting 652 This extension provides a few additional bits of information to 653 distinguish between classes of TLS clients (see e.g. 654 [PANOPTICLICK]). To minimize this sort of fingerprinting, clients 655 SHOULD support all named groups at or above their minimum security 656 threshhold. New named groups SHOULD NOT be added to the registry 657 without consideration of the cost of browser fingerprinting. 659 11. References 661 11.1. Normative References 663 [FALSE-START] 664 Langley, A., Modadugu, N., and B. Moeller, "Transport 665 Layer Security (TLS) False Start", Work in Progress, 666 draft-bmoeller-tls-falsestart-01, November 2014. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 672 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 673 for Transport Layer Security (TLS)", RFC 4492, May 2006. 675 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 676 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 677 May 2008. 679 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 680 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 682 11.2. Informative References 684 [CROSS-PROTOCOL] 685 Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and 686 B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", 687 October 2012, 688 . 691 [ECRYPTII] 692 European Network of Excellence in Cryptology II, "ECRYPT 693 II Yearly Report on Algorithms and Keysizes (2011-2012)", 694 September 2012, 695 . 697 [ENISA] European Union Agency for Network and Information Security 698 Agency, "Algorithms, Key Sizes and Parameters Report, 699 version 1.0", October 2013, 700 . 704 [NIST] National Institute of Standards and Technology, "NIST 705 Special Publication 800-57. Recommendation for key 706 management - Part 1: General (Revision 3)", 2012, 707 . 710 [PANOPTICLICK] 711 Electronic Frontier Foundation, "Panopticlick: How Unique 712 - and Trackable - Is Your Browser?", 2010, 713 . 715 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 716 RFC 2246, January 1999. 718 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 719 Diffie-Hellman groups for Internet Key Exchange (IKE)", 720 RFC 3526, May 2003. 722 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 723 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 725 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 726 Group Exchange for the Secure Shell (SSH) Transport Layer 727 Protocol", RFC 4419, March 2006. 729 [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography 730 (ECC) Brainpool Curves for Transport Layer Security 731 (TLS)", RFC 7027, October 2013. 733 [SECURE-RESUMPTION] 734 Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, 735 "Triple Handshakes Considered Harmful: Breaking and Fixing 736 Authentication over TLS", March 2014, . 739 [SESSION-HASH] 740 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 741 A., and M. Ray, "Triple Handshakes Considered Harmful: 742 Breaking and Fixing Authentication over TLS", March 2014, 743 . 746 [SSL3-ANALYSIS] 747 Schneier, B. and D. Wagner, "Analysis of the SSL 3.0 748 protocol", 1996, . 750 [STRONGSWAN-IKE] 751 Brunner, T. and A. Steffen, "Diffie Hellman Groups in 752 IKEv2 Cipher Suites", October 2013, 753 . 756 11.3. URIs 758 [1] https://www.iana.org/assignments/tls-parameters/tls- 759 parameters.xhtml#tls-parameters-8 761 Appendix A. Named Group Registry 763 Each description below indicates the group itself, its derivation, 764 its expected strength (estimated roughly from guidelines in 765 [ECRYPTII]), and whether it is recommended for use in TLS key 766 exchange at the given security level. It is not recommended to add 767 further finite field groups to the NamedCurves registry; any attempt 768 to do so should consider Section 10.1. 770 The primes in these finite field groups are all safe primes, that is, 771 a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is 772 the base of the natural logarithm, and square brackets denote the 773 floor operation, the groups which initially populate this registry 774 are derived for a given bitlength b by finding the lowest positive 775 integer X that creates a safe prime p where: 777 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1 779 New additions of FFDHE groups to this registry may use this same 780 derivation (e.g., with different bitlengths) or may choose their 781 parameters in a different way, but must be clear about how the 782 parameters were derived. 784 New additions of FFDHE groups MUST use a safe prime as the modulus to 785 enable the inexpensive peer verification described in Section 5.1. 787 A.1. ffdhe2048 789 The 2048-bit group has registry value 256, and is calculated from the 790 following formula: 792 The modulus is: p = 2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64 793 - 1 795 The hexadecimal representation of p is: 797 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 798 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 799 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 800 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 801 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 802 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 803 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 804 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 805 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 806 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 807 886B4238 61285C97 FFFFFFFF FFFFFFFF 809 The generator is: g = 2 811 The group size is: q = (p-1)/2 813 The hexadecimal representation of q is: 815 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 816 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 817 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 818 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 819 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 820 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 821 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 822 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 823 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 824 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 825 4435A11C 30942E4B FFFFFFFF FFFFFFFF 827 The estimated symmetric-equivalent strength of this group is 103 828 bits. 830 Peers using ffdhe2048 that want to optimize their key exchange with a 831 short exponent (Section 5.2) should choose a secret key of at least 832 225 bits. 834 A.2. ffdhe3072 836 The 3072-bit prime has registry value 257, and is calculated from the 837 following formula: 839 The modulus is: p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 840 -1 842 The hexadecimal representation of p is: 844 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 845 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 846 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 847 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 848 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 849 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 850 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 851 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 852 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 853 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 854 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 855 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 856 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 857 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 858 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 859 3C1B20EE 3FD59D7C 25E41D2B 66C62E37 FFFFFFFF FFFFFFFF 861 The generator is: g = 2 863 The group size is: q = (p-1)/2 865 The hexadecimal representation of q is: 867 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 868 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 869 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 870 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 871 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 872 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 873 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 874 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 875 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 876 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 877 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 878 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 879 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 880 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 881 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 882 9E0D9077 1FEACEBE 12F20E95 B363171B FFFFFFFF FFFFFFFF 884 The estimated symmetric-equivalent strength of this group is 125 885 bits. 887 Peers using ffdhe3072 that want to optimize their key exchange with a 888 short exponent (Section 5.2) should choose a secret key of at least 889 275 bits. 891 A.3. ffdhe4096 893 The 4096-bit group has registry value 258, and is calculated from the 894 following formula: 896 The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 897 - 1 899 The hexadecimal representation of p is: 901 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 902 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 903 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 904 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 905 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 906 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 907 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 908 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 909 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 910 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 911 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 912 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 913 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 914 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 915 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 916 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 917 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 918 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 919 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 920 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 921 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E655F6A 922 FFFFFFFF FFFFFFFF 924 The generator is: g = 2 926 The group size is: q = (p-1)/2 928 The hexadecimal representation of q is: 930 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 931 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 932 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 933 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 934 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 935 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 936 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 937 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 938 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 939 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 940 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 941 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 942 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 943 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 944 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 945 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 946 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 947 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 948 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 949 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 950 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F32AFB5 951 7FFFFFFF FFFFFFFF 953 The estimated symmetric-equivalent strength of this group is 150 954 bits. 956 Peers using ffdhe4096 that want to optimize their key exchange with a 957 short exponent (Section 5.2) should choose a secret key of at least 958 325 bits. 960 A.4. ffdhe6144 962 The 6144-bit group has registry value 259, and is calculated from the 963 following formula: 965 The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 966 2^64 - 1 968 The hexadecimal representation of p is: 970 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 971 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 972 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 973 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 974 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 975 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 976 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 977 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 978 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 979 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 980 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 981 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 982 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 983 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 984 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 985 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 986 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 987 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 988 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 989 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 990 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 991 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 992 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 993 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 994 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 995 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 996 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 997 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 998 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 999 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 1000 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 1001 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF 1003 The generator is: g = 2 1005 The group size is: q = (p-1)/2 1007 The hexadecimal representation of q is: 1009 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 1010 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 1011 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 1012 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 1013 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 1014 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 1015 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 1016 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 1017 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 1018 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 1019 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 1020 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 1021 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 1022 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 1023 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 1024 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 1025 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 1026 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 1027 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 1028 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 1029 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 1030 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1031 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 1032 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B 1033 D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 1034 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 1035 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 1036 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 1037 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 1038 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 1039 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 1040 D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF 1042 The estimated symmetric-equivalent strength of this group is 175 1043 bits. 1045 Peers using ffdhe6144 that want to optimize their key exchange with a 1046 short exponent (Section 5.2) should choose a secret key of at least 1047 375 bits. 1049 A.5. ffdhe8192 1051 The 8192-bit group has registry value 260, and is calculated from the 1052 following formula: 1054 The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 1055 2^64 - 1 1056 The hexadecimal representation of p is: 1058 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 1059 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 1060 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 1061 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 1062 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 1063 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 1064 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 1065 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 1066 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 1067 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 1068 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 1069 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C 1070 AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 1071 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D 1072 ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 1073 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 1074 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 1075 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 1076 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 1077 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 1078 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 1079 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 1080 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A 1081 CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 1082 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 1083 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 1084 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 1085 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C 1086 D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A 1087 E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 1088 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 1089 A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838 1090 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 1091 0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665 1092 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 1093 2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022 1094 BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C 1095 51AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9 1096 D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 1097 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30 1098 FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 1099 97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C 1100 D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF 1102 The generator is: g = 2 1103 The group size is: q = (p-1)/2 1105 The hexadecimal representation of q is: 1107 7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 1108 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C 1109 BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 1110 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A 1111 CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 1112 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD 1113 DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 1114 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 1115 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 1116 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 1117 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 1118 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 1119 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 1120 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 1121 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 1122 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D 1123 BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 1124 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 1125 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 1126 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 1127 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 1128 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1129 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 1130 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B 1131 D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 1132 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 1133 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 1134 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 1135 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 1136 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 1137 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 1138 D20EAB86 BC9C6D6A 5207194E 67FA3555 1B568026 7B00641C 1139 0F212D18 ECA8D732 7ED91FE7 64A84EA1 B43FF5B4 F6E8E62F 1140 05C661DE FB258877 C35B18A1 51D5C414 AAAD97BA 3E499332 1141 E596078E 600DEB81 149C441C E95782F2 2A282563 C5BAC141 1142 1423605D 1AE1AFAE 2C8B0660 237EC128 AA0FE346 4E435811 1143 5DB84CC3 B523073A 28D45498 84B81FF7 0E10BF36 1C137296 1144 28D5348F 07211E7E 4CF4F18B 286090BD B1240B66 D6CD4AFC 1145 EADC00CA 446CE050 50FF183A D2BBF118 C1FC0EA5 1F97D22B 1146 8F7E4670 5D4527F4 5B42AEFF 39585337 6F697DD5 FDF2C518 1147 7D7D5F0E 2EB8D43F 17BA0F7C 60FF437F 535DFEF2 9833BF86 1148 CBE88EA4 FBD4221E 84117283 54FA30A7 008F154A 41C7FC46 1149 6B4645DB E2E32126 7FFFFFFF FFFFFFFF 1151 The estimated symmetric-equivalent strength of this group is 192 1152 bits. 1154 Peers using ffdhe8192 that want to optimize their key exchange with a 1155 short exponent (Section 5.2) should choose a secret key of at least 1156 400 bits. 1158 Author's Address 1160 Daniel Kahn Gillmor 1161 ACLU 1162 125 Broad Street, 18th Floor 1163 New York, NY 10004 1164 USA 1166 Email: dkg@fifthhorseman.net