< draft-ietf-tls-negotiated-ff-dhe-01.txt   draft-ietf-tls-negotiated-ff-dhe-02.txt >
Internet Engineering Task Force D. Gillmor Internet Engineering Task Force D. Gillmor
Internet-Draft ACLU Internet-Draft ACLU
Intended status: Informational August 27, 2014 Intended status: Informational October 11, 2014
Expires: February 28, 2015 Expires: April 14, 2015
Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
draft-ietf-tls-negotiated-ff-dhe-01 draft-ietf-tls-negotiated-ff-dhe-02
Abstract Abstract
Traditional finite-field-based Diffie-Hellman (DH) key exchange Traditional finite-field-based Diffie-Hellman (DH) key exchange
during the TLS handshake suffers from a number of security, during the TLS handshake suffers from a number of security,
interoperability, and efficiency shortcomings. These shortcomings interoperability, and efficiency shortcomings. These shortcomings
arise from lack of clarity about which DH group parameters TLS arise from lack of clarity about which DH group parameters TLS
servers should offer and clients should accept. This document offers servers should offer and clients should accept. This document offers
a solution to these shortcomings for compatible peers by establishing a solution to these shortcomings for compatible peers by using a
a registry of DH parameters with known structure and a mechanism for section of the TLS "EC Named Curve Registry" to establish common DH
peers to indicate support for these groups. parameters with known structure and a mechanism for peers to
negotiate support for these groups.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 28, 2015. This Internet-Draft will expire on April 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 4
2. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 2. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 3. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ServerDHParams changes . . . . . . . . . . . . . . . . . 5 3.1. ServerDHParams changes . . . . . . . . . . . . . . . . . 6
4. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Checking the Peer's Public Key . . . . . . . . . . . . . 6 4.1. Checking the Peer's Public Key . . . . . . . . . . . . . 6
4.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 6 4.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 7
4.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 6 4.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 7
5. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 7 5. Operational Considerations . . . . . . . . . . . . . . . . . 7
5.1. Server Indication of support . . . . . . . . . . . . . . 7 5.1. Preference Ordering . . . . . . . . . . . . . . . . . . . 7
5.2. Normalizing Weak Groups . . . . . . . . . . . . . . . . . 7 6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Arbitrary Groups . . . . . . . . . . . . . . . . . . . . 7 6.1. Server Indication of support . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Normalizing Weak Groups . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.3. Arbitrary Groups . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Negotiation resistance to active attacks . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.2. DHE only . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.3. Deprecating weak groups . . . . . . . . . . . . . . . . . 9 9.1. Negotiation resistance to active attacks . . . . . . . . 10
8.4. Choice of groups . . . . . . . . . . . . . . . . . . . . 10 9.2. DHE only . . . . . . . . . . . . . . . . . . . . . . . . 11
8.5. Timing attacks . . . . . . . . . . . . . . . . . . . . . 10 9.3. Deprecating weak groups . . . . . . . . . . . . . . . . . 11
8.6. Replay attacks from non-negotiated FF DHE . . . . . . . . 10 9.4. Choice of groups . . . . . . . . . . . . . . . . . . . . 11
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 9.5. Timing attacks . . . . . . . . . . . . . . . . . . . . . 12
9.1. Client fingerprinting . . . . . . . . . . . . . . . . . . 11 9.6. Replay attacks from non-negotiated FF DHE . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
A.1. ffdhe2432 . . . . . . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 14 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 14
A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. ffdhe2432 . . . . . . . . . . . . . . . . . . . . . . . . 15
A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 19
A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key
exchange mode which provides Perfect Forward Secrecy for the exchange mode which provides Perfect Forward Secrecy for the
connection. The client offers a ciphersuite in the ClientHello that connection. The client offers a ciphersuite in the ClientHello that
includes DHE, and the server offers the client group parameters g and includes DHE, and the server offers the client group parameters g and
p. If the client does not consider the group strong enough (e.g. if p. If the client does not consider the group strong enough (e.g. if
p is too small, or if p is not prime, or there are small subgroups), p is too small, or if p is not prime, or there are small subgroups),
or if it is unable to process it for other reasons, it has no or if it is unable to process it for other reasons, it has no
skipping to change at page 3, line 25 skipping to change at page 3, line 32
server can offer a stronger group (and are willing to use a non-PFS server can offer a stronger group (and are willing to use a non-PFS
key-exchange mechanism otherwise). The server has no way of knowing key-exchange mechanism otherwise). The server has no way of knowing
which type of client is connecting, but must select DH parameters which type of client is connecting, but must select DH parameters
with insufficient knowledge. with insufficient knowledge.
Additionally, the DH parameters chosen by the server may have a known Additionally, the DH parameters chosen by the server may have a known
structure which renders them secure against a small subgroup attack, structure which renders them secure against a small subgroup attack,
but a client receiving an arbitrary p has no efficient way to verify but a client receiving an arbitrary p has no efficient way to verify
that the structure of a new group is reasonable for use. that the structure of a new group is reasonable for use.
This extension solves these problems with a registry of groups of This modification to TLS solves these problems by using a section of
known reasonable structure, an extension for clients to advertise the "EC Named Curves" registry to select common DH groups with known
support for them and servers to select them, and guidance for structure; defining the use of the "elliptic_curves(10)" extension
compliant peers to take advantage of the additional security, for clients advertising support for DHE with these groups; and
availability, and efficiency offered. defining how a server indicates acceptance of a proposed common
group. This document also provides guidance for compliant peers to
take advantage of the additional security, availability, and
efficiency offered.
The use of this extension by one compliant peer when interacting with The use of this mechanism by one compliant peer when interacting with
a non-compliant peer should have no detrimental effects. a non-compliant peer should have no detrimental effects.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Vocabulary 1.2. Vocabulary
The term "DHE" is used in this document to refer to the finite-field- The terms "DHE" or "FFDHE" are used in this document to refer to the
based Diffie-Hellman ephemeral key exchange mechanism in TLS. TLS finite-field-based Diffie-Hellman ephemeral key exchange mechanism in
also supports elliptic-curve-based Diffie-Hellman (ECDHE) ephemeral TLS. TLS also supports elliptic-curve-based Diffie-Hellman (ECDHE)
key exchanges, but this document does not discuss their use. ephemeral key exchanges [RFC4492], but this document does not
Mentions of DHE here refer strictly to finite-field-based DHE, and document their use. A registry previously used only by ECHDE-capable
not to ECDHE. implementations is expanded in this document to cover FFDHE groups as
well. "FFDHE ciphersuites" is used in this document to refer
exclusively to ciphersuites with FFDHE key exchange mechanisms, but
note that these suites are typically labeled with a TLS_DHE_ prefix.
2. Client Behavior 2. Client Behavior
A TLS client that is capable of using strong finite field Diffie- A TLS client that is capable of using strong finite field Diffie-
Hellman groups can advertise its capabilities and its preferences for Hellman groups can advertise its capabilities and its preferences for
stronger key exchange by using this mechanism. stronger key exchange by using this mechanism.
The client SHOULD send an extension of type We use previously-unallocated codepoints within the extension
"negotiated_ff_dhe_groups" in the ClientHello, indicating a list of currently known as "elliptic_curves" (section 5.1.1. of [RFC4492]) to
known finite field Diffie-Hellman groups, ordered from most preferred indicate known finite field groups. The extension's semantics is
to least preferred. expanded from "known elliptic curve groups" to "known groups". The
semantics of the extension's data type (enum NamedCurve) is also
expanded from "named curve" to "named group".
The "extension_data" field of this extension SHALL contain The compatible client that wants to be able to negotiate strong FFDHE
"FiniteFieldDHEGroups" where: SHOULD send an extension of type "elliptic_curves" ([RFC4492]) in the
ClientHello, and include a list of known FFDHE groups in the
extension data, ordered from most preferred to least preferred. If
the client also supports and wants to offer ECDHE key exchange, it
MUST use a single elliptic_curves extension to include all supported
groups (both ECDHE and FFDHE groups). The ordering SHOULD be based
on client preference, but see Section 5.1 for more nuance.
enum { Here are the new code points for the NamedCurve registry:
ffdhe2432(0), ffdhe3072(1), ffdhe4096(2),
ffdhe6144(3), ffdhe8192(4), (255)
} FiniteFieldDHEGroup;
struct { enum {
FiniteFieldDHEGroup finite_field_dhe_group_list<1..2^8-1>; // other already defined elliptic curves (see RFC 4492)
} FiniteFieldDHEGroups; ffdhe2432(256), ffdhe3072(257), ffdhe4096(258),
ffdhe6144(259), ffdhe8192(260),
//
} NamedCurve;
A client that offers this extension SHOULD include at least one DHE- A client that offers any of these values in the NamedCurves extension
key-exchange ciphersuite in the Client Hello. SHOULD ALSO include at least one FFDHE ciphersuite in the Client
Hello.
The known groups defined by the FiniteFieldDHEGroup registry are These additions to the Named Curve registry are described in detail
listed in Appendix A. These are all safe primes derived from the in Appendix A. They are all safe primes derived from the base of the
base of the natural logarithm ("e"), with the high and low 64 bits natural logarithm ("e"), with the high and low 64 bits set to 1 for
set to 1 for efficient Montgomery or Barrett reduction. efficient Montgomery or Barrett reduction.
The use of the base of the natural logarithm here is as a "nothing- The use of the base of the natural logarithm here is as a "nothing-
up-my-sleeve" number. The goal is to guarantee that the bits in the up-my-sleeve" number. The goal is to guarantee that the bits in the
middle of the modulus are effectively random, while avoiding any middle of the modulus are effectively random, while avoiding any
suspicion that the primes have secretly been selected to be weak suspicion that the primes have secretly been selected to be weak
according to some secret criteria. [RFC3526] used pi for this value. according to some secret criteria. [RFC3526] used pi for this value.
See Section 8.4 for reasons that this draft does not reuse pi. See Section 9.4 for reasons that this draft does not reuse pi.
A client who offers a group MUST be able and willing to perform a DH A client who offers a group MUST be able and willing to perform a DH
key exchange using that group. key exchange using that group.
3. Server Behavior 3. Server Behavior
A TLS server MUST NOT send the NegotiatedDHParams extension to a If a compatible TLS server receives a NamedCurves extension from a
client that does not offer it first. client that includes any FFDHE groups, the server SHOULD NOT select
an FFDHE ciphersuite if it is unwilling to use one of the FFDHE
A compatible TLS server that receives this extension from a client groups named by the client. In this case, the server SHOULD select
SHOULD NOT select a DHE ciphersuite if it is unwilling to use one of an acceptable non-FFDHE ciphersuite from the client's offered list.
the DH groups named by the client. In this case, it SHOULD select an If the extension is present, none of the client's offered groups are
acceptable non-DHE ciphersuite from the client's offered list. If acceptable by the server, and none of the client's proposed non-FFDHE
the extension is present, none of the client's offered groups are
acceptable by the server, and none of the client's proposed non-DHE
ciphersuites are acceptable to the server, the server SHOULD end the ciphersuites are acceptable to the server, the server SHOULD end the
connection with a fatal TLS alert of type insufficient_security. connection with a fatal TLS alert of type insufficient_security.
A compatible TLS server that receives this extension from a client A compatible TLS server that receives the NamedCurve extension with
and selects a DHE-key-exchange ciphersuite selects one of the offered FFDHE codepoints in it, and which selects an FFDHE ciphersuite MUST
groups and indicates it to the client in the ServerHello by sending a select one of the offered groups and indicates the choice of groups
"negotiated_ff_dhe_groups" extension. The "extension_data" field of to the client by sending a specially-formatted ServerDHParams as
this extension on the server side should be a single one-byte value described below.
FiniteFieldDHEGroup.
A TLS server MUST NOT send the specially-formatted ServerDHParams
message to a client that did not offer an FFDHE group in the
NamedCurves extension first.
A TLS server MUST NOT select a named group that was not offered by A TLS server MUST NOT select a named group that was not offered by
the client. the client.
If a non-anonymous DHE ciphersuite is chosen, and the TLS client has A TLS server MUST NOT select an FFDHE ciphersuite if the client did
used this extension to offer a DHE group of comparable or greater not offer one, even if the client offered an FFDHE group in the
strength than the server's public key, the server SHOULD select a DHE NamedCurves extension.
group at least as strong as the server's public key. For example, if
the server has a 3072-bit RSA key, and the client offers only If a non-anonymous FFDHE ciphersuite is chosen, and the TLS client
ffdhe2432 and ffdhe4096, the server SHOULD select ffdhe4096. has used this extension to offer an FFDHE group of comparable or
greater strength than the server's public key, the server SHOULD
select an FFDHE group at least as strong as the server's public key.
For example, if the server has a 3072-bit RSA key, and the client
offers only ffdhe2432 and ffdhe4096, the server SHOULD select
ffdhe4096.
3.1. ServerDHParams changes 3.1. ServerDHParams changes
When the server sends the "negotiated_ff_dhe_groups" extension in the When the compatible server selects an FFDHE ciphersuite for a client
ServerHello, the ServerDHParams member of the subsequent who offered FFDHE groups via Named Curves, the ServerDHParams member
ServerKeyExchange message should indicate a one-byte zero value (0) of the subsequent ServerKeyExchange message should indicate a one-
in place of dh_g and the identifier of the named group in place of byte zero value (0) in place of dh_g to indicate support for a pre-
dh_p, represented as a one-byte value. dh_Ys must be transmitted as known FFDHE group. It places the value of the named group
normal. (represented as a two-byte value) in place of dh_p. dh_Ys must be
transmitted as normal.
This re-purposing of dh_p and dh_g is unambiguous: there are no This re-purposing of dh_p and dh_g is unambiguous: there are no
groups with a generator of 0, and no implementation should accept a groups with a generator of 0, and no implementation should accept a
modulus of size < 9 bits. This change serves two purposes: modulus of size < 17 bits. Aside from making the ServerDHParams an
unambiguous indicator of support for named FFDHE groups, this change
serves two purposes:
The size of the handshake is reduced (significantly, in the case The size of the handshake is reduced (significantly, in the case
of a large prime modulus). of a large prime modulus).
The signed struct should not be re-playable in a subsequent key The signed struct should not be re-playable in a subsequent key
exchange that does not indicate named DH groups. exchange that does not indicate named FFDHE groups.
4. Optimizations 4. Optimizations
In a successfully negotiated finite field DH group key exchange, both In a key exchange with a successfully negotiated known FFDHE group,
peers know that the group in question uses a safe prime as a modulus, both peers know that the group in question uses a safe prime as a
and that the group in use is of size p-1 or (p-1)/2. This allows at modulus, and that the group in use is of size p-1 or (p-1)/2. This
least three optimizations that can be used to improve performance. allows at least three optimizations that can be used to improve
performance.
4.1. Checking the Peer's Public Key 4.1. Checking the Peer's Public Key
Peers should validate the each other's public key Y (dh_Ys offered by Peers should validate each other's public key Y (dh_Ys offered by the
the server or DH_Yc offered by the client) by ensuring that 1 < Y < server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1.
p-1. This simple check ensures that the remote peer is properly This simple check ensures that the remote peer is properly behaved
behaved and isn't forcing the local system into a small subgroup. and isn't forcing the local system into a small subgroup.
To reach the same assurance with an unknown group, the client would To reach the same assurance with an unknown group, the client would
need to verify the primality of the modulus, learn the factors of need to verify the primality of the modulus, learn the factors of
p-1, and test both the generator g and Y against each factor to avoid p-1, and test both the generator g and Y against each factor to avoid
small subgroup attacks. small subgroup attacks.
4.2. Short Exponents 4.2. Short Exponents
Traditional Finite Field Diffie-Hellman has each peer choose their Traditional Finite Field Diffie-Hellman has each peer choose their
secret exponent from the range [2,p-2]. Using exponentiation by secret exponent from the range [2,p-2]. Using exponentiation by
skipping to change at page 6, line 42 skipping to change at page 7, line 28
example, rather than doing 2*2*2432 multiplications for a ffdhe2432 example, rather than doing 2*2*2432 multiplications for a ffdhe2432
handshake, each peer can choose to do 2*2*224 multiplications by handshake, each peer can choose to do 2*2*224 multiplications by
choosing their secret exponent in the range [2,2^224] and still keep choosing their secret exponent in the range [2,2^224] and still keep
the approximate 112-bit security level. the approximate 112-bit security level.
A similar short-exponent approach is suggested in SSH's Diffie- A similar short-exponent approach is suggested in SSH's Diffie-
Hellman key exchange (See section 6.2 of [RFC4419]). Hellman key exchange (See section 6.2 of [RFC4419]).
4.3. Table Acceleration 4.3. Table Acceleration
Peers wishing to further accelerate DHE key exchange can also pre- Peers wishing to further accelerate FFDHE key exchange can also pre-
compute a table of powers of the generator of a known group. This is compute a table of powers of the generator of a known group. This is
a memory vs. time tradeoff, and it only accelerates the first a memory vs. time tradeoff, and it only accelerates the first
exponentiation of the ephemeral DH exchange (the exponentiation using exponentiation of the ephemeral DH exchange (the exponentiation using
the peer's public exponent as a base still needs to be done as the peer's public exponent as a base still needs to be done as
normal). normal).
5. Open Questions 5. Operational Considerations
5.1. Preference Ordering
The ordering of named groups in the NamedCurves extension may contain
some ECDHE groups and some FFDHE groups. These SHOULD be ranked in
preference order.
However, the ClientHello also contains list of desired ciphersuites,
also ranked in preference order. This presents the possibility of
conflicted preferences. For example, if the ClientHello contains a
CipherSuite with two choices in order
<TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA> and the NamedCurves Extension
contains two choices in order <secp256r1,ffdhe3072> then there is a
clear contradiction. Clients MUST NOT present such a contradiction.
A server that encounters such an contradiction when selecting between
an ECDHE or FFDHE key exchange mechanism while trying to respect
client preferences SHOULD give priority to the NamedCurves extension
(in the example case, it should select
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp256r1.
More subtly, it is possible for a client to present an ambiguity that
is not a clear contradiction. For example, the ClientHello could be
the same as the above example, but NamedCurves could be:
<ffdhe8192,secp384p1,ffdhe3072,secp256r1>. Clients MAY present such
a mixed set of groups. In this case, a server configured to respect
client preferences and with support for all listed groups SHOULD
select TLS_DHE_RSA_WITH_AES_128_CBC_SHA with ffdhe8192. A server
configured to respect client preferences and with support for only
secp384p1 and ffdhe3072 SHOULD select
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp384p1.
6. Open Questions
[This section should be removed, and questions resolved, before any [This section should be removed, and questions resolved, before any
formalization of this draft] formalization of this draft]
5.1. Server Indication of support 6.1. Server Indication of support
Some servers will support this extension, but for whatever reason Some servers will support this mechanism, but for whatever reason
decide to not negotiate a ciphersuite with DHE key exchange at all. decide to not negotiate a ciphersuite with DHE key exchange at all.
Some possible reasons include: Some possible reasons include:
The client indicated that a server-supported non-DHE ciphersuite The client indicated that a server-supported non-FFDHE ciphersuite
was preferred over all DHE ciphersuites, and the server honors was preferred over all FFDHE ciphersuites, and the server honors
that preference. that preference.
The server prefers a client-supported non-DHE ciphersuite over all The server prefers a client-supported non-FFDHE ciphersuite over
DHE ciphersuites, and selects it unilaterally. all FFDHE ciphersuites, and selects it unilaterally.
The server would have chosen a DHE ciphersuite, but none of the The server would have chosen a FFDHE ciphersuite, but none of the
client's offered groups are acceptable to the server, client's offered groups are acceptable to the server,
Clients will not know that such a server supports the extension. Clients will not know that such a server supports this mechanism.
Should we offer a way for a server to indicate its support for this Should we offer a way for a server to indicate its support for this
extension to a compatible client in this case? mechanism to a compatible client in this case?
Should the server have a way to advertise that it supports this Should the server have a way to advertise that it supports this
extension even if the client does not offer it? mechanism even if the client does not offer an FFDHE group in
NamedCurves, or does not offer any NamedCurve at all?
5.2. Normalizing Weak Groups [dkg] I think the answer here is that we do not care about signalling
this support to the client in general.
6.2. Normalizing Weak Groups
Is there any reason to include a weak group in the list of groups? Is there any reason to include a weak group in the list of groups?
Most DHE-capable peers can already handle 1024-bit DHE, and therefore Most DHE-capable peers can already handle 1024-bit DHE, and therefore
1024-bit DHE does not need to be negotiated. Properly-chosen 1024-bit DHE does not need to be negotiated. Properly-chosen
2432-bit DH groups should be roughly equivalent to 112-bit security. 2432-bit DH groups should be roughly equivalent to 112-bit security.
And future implementations should use sizes of at least 3072 bits And future implementations should use sizes of at least 3072 bits
according to [ENISA]. according to [ENISA].
5.3. Arbitrary Groups 6.3. Arbitrary Groups
This spec currently doesn't indicate any support for groups other This spec currently doesn't indicate any support for groups other
than the named groups. Other DHE specifications have moved away from than the named groups. Other FFDHE specifications have moved away
staticly-named groups with the explicitly-stated rationale of from staticly-named groups with the explicitly-stated rationale of
reducing the incentive for precomputation-driven attacks on any reducing the incentive for precomputation-driven attacks on any
specific group (e.g. section 1 of [RFC4419]). However, arbitrary specific group (e.g. section 1 of [RFC4419]). However, arbitrary
large groups are expensive to transmit over the network and it is large groups are expensive to transmit over the network and it is
computationally infeasible for the client to verify their structure computationally infeasible for the client to verify their structure
during a key exchange. If we instead allow the server to propose during a key exchange. If we instead allow the server to propose
arbitrary groups, we could make it a MUST that the generated groups arbitrary groups, we could make it a MUST that the generated groups
use safe prime moduli, while still allowing clients to signal support use safe prime moduli, while still allowing clients to signal support
(and desire) for large groups. This leaves the client in the (and desire) for large groups. This leaves the client in the
position of relying on the server to choose a strong modulus, though. position of relying on the server to choose a strong modulus, though.
Note that in several known attacks against TLS and SSL Note that in several known attacks against TLS and SSL
[SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious
server uses a deliberately broken finite field DHE group to server uses a deliberately broken FFDHE group to impersonate the
impersonate the client to a different server. client to a different server.
6. Acknowledgements 7. Acknowledgements
Thanks to Fedor Brunner, Dave Fergemann, Sandy Harris, Watson Ladd, Thanks to Fedor Brunner, Dave Fergemann, Sandy Harris, Watson Ladd,
Nikos Mavrogiannopolous, Niels Moeller, Kenny Paterson, and Tom Nikos Mavrogiannopolous, Niels Moeller, Kenny Paterson, Eric
Ritter for their comments and suggestions on this draft. Any Rescorla, Tom Ritter, Martin Thomson, and Sean Turner for their
mistakes here are not theirs. comments and suggestions on this draft. Any mistakes here are not
theirs.
7. IANA Considerations 8. IANA Considerations
This document defines a new TLS extension, "negotiated_dh_group", IANA maintains the registry currently known as EC Named Curves
assigned a value of XXX from the TLS ExtensionType registry defined (originally defined in [RFC4492] and updated by [RFC7027]) at [1].
in section 12 of [RFC5246]. This value is used as the extension
number for the extensions in both the client hello message and the
server hello message.
Appendix A defines a TLS Finite Field DHE Named Group Registry. Each This document expands the semantics of this registry slightly, to
entry in this registry indicates the group itself, its derivation, include groups based on finite fields in addition to groups based on
its expected strength (estimated roughly from guidelines in elliptic curves.
[ECRYPTII]), and whether it is recommended for use in TLS key
exchange at the given security level. This registry may be updated
by the addition of new finite field groups, and by reassessments of
the security level or utility to TLS of any already present group.
Updates are made by IETF Review [RFC5226], and should consider
Section 9.1.
8. Security Considerations This document allocates five codepoints in the registry, as follows:
8.1. Negotiation resistance to active attacks +-------+-------------+---------+-----------------+
| Value | Description | DTLS-OK | Reference |
+-------+-------------+---------+-----------------+
| 256 | ffdhe2432 | Y | [this document] |
| 257 | ffdhe3072 | Y | [this document] |
| 258 | ffdhe4096 | Y | [this document] |
| 259 | ffdhe6144 | Y | [this document] |
| 260 | ffdhe8192 | Y | [this document] |
+-------+-------------+---------+-----------------+
9. Security Considerations
9.1. Negotiation resistance to active attacks
Because the contents of this extension is hashed in the finished Because the contents of this extension is hashed in the finished
message, an active MITM that tries to filter or omit groups will message, an active MITM that tries to filter or omit groups will
cause the handshake to fail, but possibly not before getting the peer cause the handshake to fail, but possibly not before getting the peer
to do something they would not otherwise have done. to do something they would not otherwise have done.
An attacker who impersonates the server can try to do any of the An attacker who impersonates the server can try to do any of the
following: following:
Pretend that a non-compatible server is actually capable of this Pretend that a non-compatible server is actually capable of this
skipping to change at page 9, line 37 skipping to change at page 11, line 10
Pretend that a non-compatible client is compatible. This could Pretend that a non-compatible client is compatible. This could
cause the server to send what appears to be an extremely odd cause the server to send what appears to be an extremely odd
ServerDHParams (see Section 3.1), and the check in the Finished ServerDHParams (see Section 3.1), and the check in the Finished
message would fail. It is not clear how this could be an attack. message would fail. It is not clear how this could be an attack.
Change the list of groups offered by the client (e.g. by removing Change the list of groups offered by the client (e.g. by removing
the stronger of the set of groups offered). This could cause the the stronger of the set of groups offered). This could cause the
server to negotiate a weaker group than desired, but again should server to negotiate a weaker group than desired, but again should
be caught by the check in the Finished message. be caught by the check in the Finished message.
8.2. DHE only 9.2. DHE only
Note that this extension specifically targets only finite field-based Note that this extension specifically targets only finite field-based
Diffie-Hellman ephemeral key exchange mechanisms. It does not cover Diffie-Hellman ephemeral key exchange mechanisms. It does not cover
the non-ephemeral DH key exchange mechanisms, nor does it cover the non-ephemeral DH key exchange mechanisms, nor does it cover
elliptic curve-based DHE key exchange, which has its own list of elliptic curve-based DHE key exchange, which has its own list of
named groups. named groups.
8.3. Deprecating weak groups 9.3. Deprecating weak groups
Advances in hardware or in finite field cryptanalysis may cause some Advances in hardware or in finite field cryptanalysis may cause some
of the negotiated groups to not provide the desired security margins, of the negotiated groups to not provide the desired security margins,
as indicated by the estimated work factor of an adversary to discover as indicated by the estimated work factor of an adversary to discover
the premaster secret (and therefore compromise the confidentiality the premaster secret (and therefore compromise the confidentiality
and integrity of the TLS session). and integrity of the TLS session).
Revisions of this extension or updates should mark known-weak groups Revisions of this extension or updates should mark known-weak groups
as explicitly deprecated for use in TLS, and should update the as explicitly deprecated for use in TLS, and should update the
estimated work factor needed to break the group, if the cryptanalysis estimated work factor needed to break the group, if the cryptanalysis
has changed. Implementations that require strong confidentiality and has changed. Implementations that require strong confidentiality and
integrity guarantees should avoid using deprecated groups and should integrity guarantees should avoid using deprecated groups and should
be updated when the estimated security margins are updated. be updated when the estimated security margins are updated.
8.4. Choice of groups 9.4. Choice of groups
Other lists of named finite field Diffie-Hellman groups Other lists of named finite field Diffie-Hellman groups
[STRONGSWAN-IKE] exist. This draft chooses to not reuse them for [STRONGSWAN-IKE] exist. This draft chooses to not reuse them for
several reasons: several reasons:
Using the same groups in multiple protocols increases the value Using the same groups in multiple protocols increases the value
for an attacker with the resources to crack any single group. for an attacker with the resources to crack any single group.
The IKE groups include weak groups like MODP768 which are The IKE groups include weak groups like MODP768 which are
unacceptable for secure TLS traffic. unacceptable for secure TLS traffic.
skipping to change at page 10, line 34 skipping to change at page 12, line 9
Mixing group parameters across multiple implementations leaves Mixing group parameters across multiple implementations leaves
open the possibility of some sort of cross-protocol attack. This open the possibility of some sort of cross-protocol attack. This
shouldn't be relevant for ephemeral scenarios, and even with non- shouldn't be relevant for ephemeral scenarios, and even with non-
ephemeral keying, services shouldn't share keys; however, using ephemeral keying, services shouldn't share keys; however, using
different groups avoids these failure modes entirely. different groups avoids these failure modes entirely.
Other lists of named FF DHE groups are not collected in a single Other lists of named FF DHE groups are not collected in a single
IANA registry, or are mixed with non-FF DHE groups, which makes IANA registry, or are mixed with non-FF DHE groups, which makes
them inconvenient for re-use in a TLS DHE key exchange context. them inconvenient for re-use in a TLS DHE key exchange context.
8.5. Timing attacks 9.5. Timing attacks
Any implementation of finite field Diffie-Hellman key exchange should Any implementation of finite field Diffie-Hellman key exchange should
use constant-time modular-exponentiation implementations. This is use constant-time modular-exponentiation implementations. This is
particularly true for those implementations that ever re-use DHE particularly true for those implementations that ever re-use DHE
secret keys (so-called "semi-static" ephemeral keying) or share DHE secret keys (so-called "semi-static" ephemeral keying) or share DHE
secret keys across a multiple machines (e.g. in a load-balancer secret keys across a multiple machines (e.g. in a load-balancer
situation). situation).
8.6. Replay attacks from non-negotiated FF DHE 9.6. Replay attacks from non-negotiated FF DHE
[SECURE-RESUMPTION] shows a malicious peer using a bad FF DHE group [SECURE-RESUMPTION] shows a malicious peer using a bad FF DHE group
to maneuver a client into selecting a pre-master secret of the peer's to maneuver a client into selecting a pre-master secret of the peer's
choice, which can be replayed to another server using a non-DHE key choice, which can be replayed to another server using a non-DHE key
exchange, and can then be bootstrapped to replay client exchange, and can then be bootstrapped to replay client
authentication. authentication.
To prevent this attack (barring the fixes proposed in To prevent this attack (barring the fixes proposed in
[SESSION-HASH]), a client would need not only to implement this [SESSION-HASH]), a client would need not only to implement this
draft, but also to reject non-negotiated FF DHE ciphersuites whose draft, but also to reject non-negotiated FF DHE ciphersuites whose
group structure it cannot afford to verify. Such a client would need group structure it cannot afford to verify. Such a client would need
to abort the initial handshake and reconnect to the server in to abort the initial handshake and reconnect to the server in
question without listing any FF DHE ciphersuites on the subsequent question without listing any FF DHE ciphersuites on the subsequent
connection. connection.
This tradeoff may be too costly for most TLS clients today, but may This tradeoff may be too costly for most TLS clients today, but may
be a reasonable choice for clients performing client certificate be a reasonable choice for clients performing client certificate
authentication, or who have other reason to be concerned about authentication, or who have other reason to be concerned about
server-controlled pre-master secrets. server-controlled pre-master secrets.
9. Privacy Considerations 10. Privacy Considerations
9.1. Client fingerprinting 10.1. Client fingerprinting
This extension provides a few additional bits of information to This extension provides a few additional bits of information to
distinguish between classes of TLS clients (see e.g. distinguish between classes of TLS clients (see e.g.
[PANOPTICLICK]). To minimize this sort of fingerprinting, clients [PANOPTICLICK]). To minimize this sort of fingerprinting, clients
SHOULD support all named groups at or above their minimum security SHOULD support all named groups at or above their minimum security
threshhold. New named groups SHOULD NOT be added to the registry threshhold. New named groups SHOULD NOT be added to the registry
without consideration of the cost of browser fingerprinting. without consideration of the cost of browser fingerprinting.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
11.2. Informative References
[CROSS-PROTOCOL] [CROSS-PROTOCOL]
Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and
B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", B. Preneel, "A Cross-Protocol Attack on the TLS Protocol",
October 2012, October 2012,
<http://www.cosic.esat.kuleuven.be/publications/ <http://www.cosic.esat.kuleuven.be/publications/
article-2216.pdf>. article-2216.pdf>.
[ECRYPTII] [ECRYPTII]
European Network of Excellence in Cryptology II, "ECRYPT European Network of Excellence in Cryptology II, "ECRYPT
skipping to change at page 12, line 25 skipping to change at page 14, line 5
<https://panopticlick.eff.org/>. <https://panopticlick.eff.org/>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
Group Exchange for the Secure Shell (SSH) Transport Layer Group Exchange for the Secure Shell (SSH) Transport Layer
Protocol", RFC 4419, March 2006. Protocol", RFC 4419, March 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography
IANA Considerations Section in RFCs", BCP 26, RFC 5226, (ECC) Brainpool Curves for Transport Layer Security
May 2008. (TLS)", RFC 7027, October 2013.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SECURE-RESUMPTION] [SECURE-RESUMPTION]
Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, Delignat-Lavaud, A., Bhargavan, K., and A. Pironti,
"Triple Handshakes Considered Harmful: Breaking and Fixing "Triple Handshakes Considered Harmful: Breaking and Fixing
Authentication over TLS", March 2014, <https://secure- Authentication over TLS", March 2014, <https://secure-
resumption.com/>. resumption.com/>.
[SESSION-HASH] [SESSION-HASH]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Triple Handshakes Considered Harmful: A., and M. Ray, "Triple Handshakes Considered Harmful:
skipping to change at page 13, line 11 skipping to change at page 14, line 32
[SSL3-ANALYSIS] [SSL3-ANALYSIS]
Schneier, B. and D. Wagner, "Analysis of the SSL 3.0 Schneier, B. and D. Wagner, "Analysis of the SSL 3.0
protocol", 1996, <https://www.schneier.com/paper-ssl.pdf>. protocol", 1996, <https://www.schneier.com/paper-ssl.pdf>.
[STRONGSWAN-IKE] [STRONGSWAN-IKE]
Brunner, T. and A. Steffen, "Diffie Hellman Groups in Brunner, T. and A. Steffen, "Diffie Hellman Groups in
IKEv2 Cipher Suites", October 2013, IKEv2 Cipher Suites", October 2013,
<https://wiki.strongswan.org/projects/strongswan/wiki/ <https://wiki.strongswan.org/projects/strongswan/wiki/
IKEv2CipherSuites#Diffie-Hellman-Groups>. IKEv2CipherSuites#Diffie-Hellman-Groups>.
11.3. URIs
[1] https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml#tls-parameters-8
Appendix A. Named Group Registry Appendix A. Named Group Registry
Each description below indicates the group itself, its derivation,
its expected strength (estimated roughly from guidelines in
[ECRYPTII]), and whether it is recommended for use in TLS key
exchange at the given security level. It is not recommended to add
furtherw finite field groups to the NamedCurves registry; any attempt
to do so should consider Section 10.1.
The primes in these finite field groups are all safe primes, that is, The primes in these finite field groups are all safe primes, that is,
a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is a prime p is a safe prime when q = (p-1)/2 is also prime. Where e is
the base of the natural logarithm, and square brackets denote the the base of the natural logarithm, and square brackets denote the
floor operation, the groups which initially populate this registry floor operation, the groups which initially populate this registry
are derived for a given bitlength b by finding the lowest positive are derived for a given bitlength b by finding the lowest positive
integer X that creates a safe prime p where: integer X that creates a safe prime p where:
p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1 p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1
New additions to this registry may use this same derivation (e.g. New additions to this registry may use this same derivation (e.g.
with different bitlengths) or may choose their parameters in a with different bitlengths) or may choose their parameters in a
different way, but must be clear about how the parameters were different way, but must be clear about how the parameters were
derived. derived.
A.1. ffdhe2432 A.1. ffdhe2432
The 2432-bit group has registry value 0, and is calcluated from the The 2432-bit group has registry value 256, and is calcluated from the
following formula: following formula:
The modulus is: p = 2^2432 - 2^2368 + {[2^2302 * e] + 2111044} * 2^64 The modulus is: p = 2^2432 - 2^2368 + {[2^2302 * e] + 2111044} * 2^64
- 1 - 1
The hexadecimal representation of p is: The hexadecimal representation of p is:
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
skipping to change at page 14, line 31 skipping to change at page 16, line 28
The estimated symmetric-equivalent strength of this group is 112 The estimated symmetric-equivalent strength of this group is 112
bits. bits.
Peers using ffdhe2432 that want to optimize their key exchange with a Peers using ffdhe2432 that want to optimize their key exchange with a
short exponent (Section 4.2) should choose a secret key of at least short exponent (Section 4.2) should choose a secret key of at least
224 bits. 224 bits.
A.2. ffdhe3072 A.2. ffdhe3072
The 3072-bit prime has registry value 1, and is calcluated from the The 3072-bit prime has registry value 257, and is calcluated from the
following formula: following formula:
p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1 p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 -1
The hexadecimal representation of p is: The hexadecimal representation of p is:
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
skipping to change at page 16, line 7 skipping to change at page 17, line 34
The estimated symmetric-equivalent strength of this group is 125 The estimated symmetric-equivalent strength of this group is 125
bits. bits.
Peers using ffdhe3072 that want to optimize their key exchange with a Peers using ffdhe3072 that want to optimize their key exchange with a
short exponent (Section 4.2) should choose a secret key of at least short exponent (Section 4.2) should choose a secret key of at least
250 bits. 250 bits.
A.3. ffdhe4096 A.3. ffdhe4096
The 4096-bit group has registry value 2, and is calcluated from the The 4096-bit group has registry value 258, and is calcluated from the
following formula: following formula:
The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 The modulus is: p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64
- 1 - 1
The hexadecimal representation of p is: The hexadecimal representation of p is:
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
skipping to change at page 17, line 37 skipping to change at page 19, line 37
The estimated symmetric-equivalent strength of this group is 150 The estimated symmetric-equivalent strength of this group is 150
bits. bits.
Peers using ffdhe4096 that want to optimize their key exchange with a Peers using ffdhe4096 that want to optimize their key exchange with a
short exponent (Section 4.2) should choose a secret key of at least short exponent (Section 4.2) should choose a secret key of at least
300 bits. 300 bits.
A.4. ffdhe6144 A.4. ffdhe6144
The 6144-bit group has registry value 3, and is calcluated from the The 6144-bit group has registry value 259, and is calcluated from the
following formula: following formula:
The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * The modulus is: p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} *
2^64 - 1 2^64 - 1
The hexadecimal representation of p is: The hexadecimal representation of p is:
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
skipping to change at page 19, line 47 skipping to change at page 21, line 47
The estimated symmetric-equivalent strength of this group is 175 The estimated symmetric-equivalent strength of this group is 175
bits. bits.
Peers using ffdhe6144 that want to optimize their key exchange with a Peers using ffdhe6144 that want to optimize their key exchange with a
short exponent (Section 4.2) should choose a secret key of at least short exponent (Section 4.2) should choose a secret key of at least
350 bits. 350 bits.
A.5. ffdhe8192 A.5. ffdhe8192
The 8192-bit group has registry value 4, and is calcluated from the The 8192-bit group has registry value 260, and is calcluated from the
following formula: following formula:
The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * The modulus is: p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} *
2^64 - 1 2^64 - 1
The hexadecimal representation of p is: The hexadecimal representation of p is:
FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1
D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9
7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
 End of changes. 65 change blocks. 
168 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/