< draft-ietf-tls-negotiated-ff-dhe-08.txt   draft-ietf-tls-negotiated-ff-dhe-09.txt >
Internet Engineering Task Force D. Gillmor Internet Engineering Task Force D. Gillmor
Internet-Draft ACLU Internet-Draft ACLU
Updates: 4492, 5246, 4346, 2246 (if March 28, 2015 Updates: 4492, 5246, 4346, 2246 (if May 12, 2015
approved) approved)
Intended status: Informational Intended status: Informational
Expires: September 29, 2015 Expires: November 13, 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-08 draft-ietf-tls-negotiated-ff-dhe-09
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 using a a solution to these shortcomings for compatible peers by using a
section of the TLS "EC Named Curve Registry" to establish common section of the TLS "EC Named Curve Registry" to establish common
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 29, 2015. This Internet-Draft will expire on November 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 4
2. Named Group Overview . . . . . . . . . . . . . . . . . . . . 4 2. Named Group Overview . . . . . . . . . . . . . . . . . . . . 4
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Client Local Policy on Custom Groups . . . . . . . . . . 6
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
5. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Checking the Peer's Public Key . . . . . . . . . . . . . 7 5.1. Checking the Peer's Public Key . . . . . . . . . . . . . 7
5.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 7 5.2. Short Exponents . . . . . . . . . . . . . . . . . . . . . 8
5.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 8 5.3. Table Acceleration . . . . . . . . . . . . . . . . . . . 8
6. Operational Considerations . . . . . . . . . . . . . . . . . 8 6. Operational Considerations . . . . . . . . . . . . . . . . . 8
6.1. Preference Ordering . . . . . . . . . . . . . . . . . . . 8 6.1. Preference Ordering . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. Negotiation resistance to active attacks . . . . . . . . 10 9.1. Negotiation resistance to active attacks . . . . . . . . 10
9.2. Group strength considerations . . . . . . . . . . . . . . 11 9.2. Group strength considerations . . . . . . . . . . . . . . 11
9.3. Finite-Field DHE only . . . . . . . . . . . . . . . . . . 11 9.3. Finite-Field DHE only . . . . . . . . . . . . . . . . . . 12
9.4. Deprecating weak groups . . . . . . . . . . . . . . . . . 11 9.4. Deprecating weak groups . . . . . . . . . . . . . . . . . 12
9.5. Choice of groups . . . . . . . . . . . . . . . . . . . . 12 9.5. Choice of groups . . . . . . . . . . . . . . . . . . . . 12
9.6. Timing attacks . . . . . . . . . . . . . . . . . . . . . 12 9.6. Timing attacks . . . . . . . . . . . . . . . . . . . . . 13
9.7. Replay attacks from non-negotiated FFDHE . . . . . . . . 12 9.7. Replay attacks from non-negotiated FFDHE . . . . . . . . 13
9.8. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 13 9.8. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 13
9.9. False Start . . . . . . . . . . . . . . . . . . . . . . . 13 9.9. False Start . . . . . . . . . . . . . . . . . . . . . . . 14
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 14 10.1. Client fingerprinting . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 16 Appendix A. Named Group Registry . . . . . . . . . . . . . . . . 16
A.1. ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . . 16 A.1. ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 17 A.2. ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 20 A.4. ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . . 21
A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.5. ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
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 Forward Secrecy for the connection. The exchange mode which provides Forward Secrecy for the connection. The
client offers a ciphersuite in the ClientHello that includes DHE, and client offers a ciphersuite in the ClientHello that includes DHE, and
the server offers the client group parameters generator g and modulus the server offers the client group parameters generator g and modulus
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 the group for other reasons, the client that cannot be easily avoided), or if it is unable to process the
has no recourse but to terminate the connection. group for other reasons, the client has no recourse but to terminate
the connection.
Conversely, when a TLS server receives a suggestion for a DHE Conversely, when a TLS server receives a suggestion for a DHE
ciphersuite from a client, it has no way of knowing what kinds of DH ciphersuite from a client, it has no way of knowing what kinds of DH
groups the client is capable of handling, or what the client's groups the client is capable of handling, or what the client's
security requirements are for this key exchange session. For security requirements are for this key exchange session. For
example, some widely-distributed TLS clients are not capable of DH example, some widely-distributed TLS clients are not capable of DH
groups where p > 1024 bits. Other TLS clients may by policy wish to groups where p > 1024 bits. Other TLS clients may by policy wish to
use DHE only if the server can offer a stronger group (and are use DHE only if the server can offer a stronger group (and are
willing to use a non-PFS key-exchange mechanism otherwise). The willing to use a non-PFS key-exchange mechanism otherwise). The
server has no way of knowing which type of client is connecting, but server has no way of knowing which type of client is connecting, but
must select DH parameters with insufficient knowledge. must select DH parameters with insufficient knowledge.
Additionally, the DH parameters chosen by the server may have a known Additionally, the DH parameters selected by the server may have a
structure which renders them secure against a small subgroup attack, known structure which renders them secure against a small subgroup
but a client receiving an arbitrary p and g has no efficient way to attack, but a client receiving an arbitrary p and g has no efficient
verify that the structure of a new group is reasonable for use. way to verify that the structure of a new group is reasonable for
use.
This modification to TLS solves these problems by using a section of This modification to TLS solves these problems by using a section of
the "EC Named Curves" registry to select common DH groups with known the "EC Named Curves" registry to select common DH groups with known
structure; defining the use of the "elliptic_curves(10)" extension structure and defining the use of the "elliptic_curves(10)" extension
(described here as "Supported Groups" extension) for clients (described here as "Supported Groups" extension) for clients
advertising support for DHE with these groups. This document also advertising support for DHE with these groups. This document also
provides guidance for compliant peers to take advantage of the provides guidance for compatible peers to take advantage of the
additional security, availability, and efficiency offered. additional security, availability, and efficiency offered.
The use of this mechanism by one compliant peer when interacting with The use of this mechanism by one compatible peer when interacting
a non-compliant peer should have no detrimental effects. with a non-compatible 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]. The term document are to be interpreted as described in [RFC2119]. The term
"PRIVATE USE" is to be interpreted as described in [RFC5226]. "PRIVATE USE" is to be interpreted as described in [RFC5226].
1.2. Vocabulary 1.2. Vocabulary
skipping to change at page 4, line 26 skipping to change at page 4, line 26
2. Named Group Overview 2. Named Group Overview
We use previously-unallocated codepoints within the extension We use previously-unallocated codepoints within the extension
currently known as "elliptic_curves" (section 5.1.1. of [RFC4492]) to currently known as "elliptic_curves" (section 5.1.1. of [RFC4492]) to
indicate known finite field groups. The extension's semantics are indicate known finite field groups. The extension's semantics are
expanded from "Supported Elliptic Curves" to "Supported Groups". The expanded from "Supported Elliptic Curves" to "Supported Groups". The
semantics of the extension's data type (enum NamedCurve) is also semantics of the extension's data type (enum NamedCurve) is also
expanded from "named curve" to "named group". expanded from "named curve" to "named group".
Additionally, we explicitly relax the requirement about when the
Supported Groups extension can be sent. This extension MAY be sent
by the client when either FFDHE or ECDHE ciphersuites are listed.
Codepoints in the NamedCurve registry with a high byte of 0x01 (that Codepoints in the NamedCurve registry with a high byte of 0x01 (that
is, between 256 and 511 inclusive) are set aside for FFDHE groups, is, between 256 and 511 inclusive) are set aside for FFDHE groups,
though only a small number of them are initially defined and we do though only a small number of them are initially defined and we do
not expect many other FFDHE groups to be added to this range. No not expect many other FFDHE groups to be added to this range. No
codepoints outside of this range will be allocated to FFDHE groups. codepoints outside of this range will be allocated to FFDHE groups.
The new code points for the NamedCurve registry are: The new code points for the NamedCurve registry are:
enum { enum {
// other already defined elliptic curves (see RFC 4492) // other already defined elliptic curves (see RFC 4492)
ffdhe2048(256), ffdhe3072(257), ffdhe4096(258), ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
skipping to change at page 5, line 12 skipping to change at page 5, line 14
according to some secret criteria. [RFC3526] used pi for this value. according to some secret criteria. [RFC3526] used pi for this value.
See Section 9.5 for reasons that this draft does not reuse pi. See Section 9.5 for reasons that this draft does not reuse pi.
3. Client Behavior 3. 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 compatible client that wants to be able to negotiate strong FFDHE The compatible client that wants to be able to negotiate strong FFDHE
SHOULD send a "Supported Groups" extension (identified by type sends a "Supported Groups" extension (identified by type
elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a
list of known FFDHE groups in the extension data, ordered from most list of known FFDHE groups in the extension data, ordered from most
preferred to least preferred. If the client also supports and wants preferred to least preferred. If the client also supports and wants
to offer ECDHE key exchange, it MUST use a single "Supported Groups" to offer ECDHE key exchange, it MUST use a single "Supported Groups"
extension to include all supported groups (both ECDHE and FFDHE extension to include all supported groups (both ECDHE and FFDHE
groups). The ordering SHOULD be based on client preference, but see groups). The ordering SHOULD be based on client preference, but see
Section 6.1 for more nuance. Section 6.1 for more nuance.
A client that offers any of these values in the elliptic_curves A client that offers a "Supported Groups" extension containing an
extension SHOULD ALSO include at least one FFDHE ciphersuite in the FFDHE group SHOULD also include at least one FFDHE ciphersuite in the
Client Hello. Client Hello.
A client who offers a group MUST be able and willing to perform a DH A client that offers a group MUST be able and willing to perform a DH
key exchange using that group. key exchange using that group.
A client that offers one or more FFDHE groups in the "Supported A client that offers one or more FFDHE groups in the "Supported
Groups" extension and an FFDHE ciphersuite, and receives an FFDHE Groups" extension and an FFDHE ciphersuite, and receives an FFDHE
ciphersuite from the server SHOULD take the following steps upon ciphersuite from the server SHOULD take the following steps upon
receiving the ServerKeyExchange: receiving the ServerKeyExchange:
For non-anonymous ciphersuites where the offered Certificate is For non-anonymous ciphersuites where the offered Certificate is
valid and appropriate for the peer, validate the signature over valid and appropriate for the peer, validate the signature over
the ServerDHParams. If not valid, terminate the connection. the ServerDHParams. If not valid, terminate the connection.
If the signature over ServerDHParams is valid, compare the If the signature over ServerDHParams is valid, compare the
selected dh_p and dh_g with the FFDHE groups offered by the selected dh_p and dh_g with the FFDHE groups offered by the
client. If none of the offered groups match, the server is not client. If none of the offered groups match, the server is not
compatible with this draft. The client MAY decide to continue the compatible with this draft. The client MAY decide to continue the
connection if the selected group is acceptable under local policy, connection if the selected group is acceptable under local policy,
or it MAY decide to terminate the connection with a fatal or it MAY decide to terminate the connection with a fatal
insufficient_security(71) alert. insufficient_security(71) alert.
If the selected group matches an offered FFDHE group exactly, the If the client continues (either because the server offered a
the client MUST verify that dh_Ys is in the range 1 < dh_Ys < dh_p matching group, or because local policy permits the offered custom
- 1. If dh_Ys is not in this range, the client MUST terminate the group), the client MUST verify that dh_Ys is in the range 1 <
connection with a fatal handshake_failure(40) alert. dh_Ys < dh_p - 1. If dh_Ys is not in this range, the client MUST
terminate the connection with a fatal handshake_failure(40) alert.
If the selected group matches an offered FFDHE group exactly, and If dh_Ys is in range, then the client SHOULD continue with the
dh_Ys is in range, then the client SHOULD continue with the
connection as usual. connection as usual.
3.1. Client Local Policy on Custom Groups
Compatible clients that are willing to accept FFDHE ciphersuites from
non-compatible servers may have local policy about what custom FFDHE
groups they are willing to accept. This local policy presents a risk
to clients, who may accept weakly-protected communications from
misconfigured servers.
This draft cannot enumerate all possible safe local policy (the
safest may be to simply reject all custom groups), but compatible
clients that accept some custom groups from the server MUST do at
least cursory checks on group size, and may take other properties
into consideration as well.
A compatible client that accepts FFDHE ciphersuites using custom
groups from non-compatible servers MUST reject any group with |dh_p|
< 768 bits, and SHOULD reject any group with |dh_p| < 1024 bits.
A compatible client that rejects a non-compatible server's custom
group may decide to retry the connection while omitting all FFDHE
ciphersuites from the ClientHello. A client SHOULD only use this
approach if it successfully verified the server's expected signature
over the ServerDHParams, to avoid being forced by an active attacker
into a non-preferred ciphersuite.
4. Server Behavior 4. Server Behavior
If a compatible TLS server receives a Supported Groups extension from If a compatible TLS server receives a Supported Groups extension from
a client that includes any FFDHE group (i.e. any codepoint between a client that includes any FFDHE group (i.e. any codepoint between
256 and 511 inclusive, even if unknown to the server), and if none of 256 and 511 inclusive, even if unknown to the server), and if none of
the client-proposed FFDHE groups are known and acceptable to the the client-proposed FFDHE groups are known and acceptable to the
server, then the server SHOULD NOT select an FFDHE ciphersuite. In server, then the server MUST NOT select an FFDHE ciphersuite. In
this case, the server SHOULD select an acceptable non-FFDHE this case, the server SHOULD select an acceptable non-FFDHE
ciphersuite from the client's offered list. If the extension is ciphersuite from the client's offered list. If the extension is
present with FFDHE groups, none of the client's offered groups are present with FFDHE groups, none of the client's offered groups are
acceptable by the server, and none of the client's proposed non-FFDHE acceptable by the server, and none of the client's proposed non-FFDHE
ciphersuites are acceptable to the server, the server SHOULD end the ciphersuites are acceptable to the server, the server MUST end the
connection with a fatal TLS alert of type insufficient_security(71). connection with a fatal TLS alert of type insufficient_security(71).
If at least one FFDHE ciphersuite is present in the client If at least one FFDHE ciphersuite is present in the client
ciphersuite list, and the Supported Groups extension is present in ciphersuite list, and the Supported Groups extension is either absent
the ClientHello, but the extension does not include any FFDHE groups from the ClientHello entirely or contains no FFDHE groups (i.e. no
(i.e. no codepoints between 256 and 511 inclusive), then the server codepoints between 256 and 511 inclusive), then the server knows that
knows that the client is not compatible with this document. In this the client is not compatible with this document. In this scenario, a
scenario, a server MAY choose to select a non-FFDHE ciphersuite, or server MAY select a non-FFDHE ciphersuite, or MAY select an FFDHE
MAY choose an FFDHE ciphersuite and offer an FFDHE group of its ciphersuite and offer an FFDHE group of its choice to the client as
choice to the client as part of a traditional ServerKeyExchange. part of a traditional ServerKeyExchange.
A compatible TLS server that receives the Supported Groups extension A compatible TLS server that receives the Supported Groups extension
with FFDHE codepoints in it, and which selects an FFDHE ciphersuite with FFDHE codepoints in it, and which selects an FFDHE ciphersuite
MUST select one of the client's offered groups. The server indicates MUST select one of the client's offered groups. The server indicates
the choice of group to the client by sending the group's parameters the choice of group to the client by sending the group's parameters
as usual in the ServerKeyExchange as described in section 7.4.3 of as usual in the ServerKeyExchange as described in section 7.4.3 of
[RFC5246]. [RFC5246].
A TLS server MUST NOT select a named FFDHE group that was not offered A TLS server MUST NOT select a named FFDHE group that was not offered
by a compatible client. by a compatible client.
A TLS server MUST NOT select an FFDHE ciphersuite if the client did A TLS server MUST NOT select an FFDHE ciphersuite if the client did
not offer one, even if the client offered an FFDHE group in the not offer one, even if the client offered an FFDHE group in the
Supported Groups extension. Supported Groups extension.
If a non-anonymous FFDHE ciphersuite is chosen, and the TLS client If a non-anonymous FFDHE ciphersuite is selected, and the TLS client
has used this extension to offer an FFDHE group of comparable or has used this extension to offer an FFDHE group of comparable or
greater strength than the server's public key, the server SHOULD 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. 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 For example, if the server has a 3072-bit RSA key, and the client
offers only ffdhe2048 and ffdhe4096, the server SHOULD select offers only ffdhe2048 and ffdhe4096, the server SHOULD select
ffdhe4096. ffdhe4096.
When a compatible server selects an FFDHE group from among a client's When an FFDHE ciphersuite is selected, and the client sends a
Supported Groups, and the client sends a ClientKeyExchange, the ClientKeyExchange, the server MUST verify that 1 < dh_Yc < dh_p - 1.
server MUST verify that 1 < dh_Yc < dh_p - 1. If it is out of range, If dh_Yc is out of range, the server MUST terminate the connection
the server MUST terminate the connection with fatal with fatal handshake_failure(40) alert.
handshake_failure(40) alert.
5. Optimizations 5. Optimizations
In a key exchange with a successfully negotiated known FFDHE group, In a key exchange with a successfully negotiated known FFDHE group,
both peers know that the group in question uses a safe prime as a both peers know that the group in question uses a safe prime as a
modulus, and that the group in use is of size p-1 or (p-1)/2. This modulus, and that the group in use is of size p-1 or (p-1)/2. This
allows at least three optimizations that can be used to improve allows at least three optimizations that can be used to improve
performance. performance.
5.1. Checking the Peer's Public Key 5.1. Checking the Peer's Public Key
Peers MUST validate each other's public key Y (dh_Ys offered by the Peers MUST validate each other's public key Y (dh_Ys offered by the
server or dh_Yc offered by the client) by ensuring that 1 < Y < p-1. server or dh_Yc offered by the client) by ensuring that 1 < Y < p-1.
This simple check ensures that the remote peer is properly behaved This simple check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup. and isn't forcing the local system into the 2-element 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.
5.2. Short Exponents 5.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 9, line 21 skipping to change at page 9, line 42
TLS Working Group for their comments and suggestions on this draft. TLS Working Group for their comments and suggestions on this draft.
Any mistakes here are not theirs. Any mistakes here are not theirs.
8. IANA Considerations 8. IANA Considerations
IANA maintains the registry currently known as EC Named Curves IANA maintains the registry currently known as EC Named Curves
(originally defined in [RFC4492] and updated by [RFC7027]) at [1]. (originally defined in [RFC4492] and updated by [RFC7027]) at [1].
This document expands the semantics of this registry slightly, to This document expands the semantics of this registry slightly, to
include groups based on finite fields in addition to groups based on include groups based on finite fields in addition to groups based on
elliptic curves. It should add a range designation to that registry, elliptic curves. IANA should add a range designation to that
indicating that values from 256-511 (inclusive) are set aside for registry, indicating that values from 256-511 (inclusive) are set
"Finite Field Diffie-Hellman groups", and that all other entries in aside for "Finite Field Diffie-Hellman groups", and that all other
the registry are "Elliptic curve groups". entries in the registry are "Elliptic curve groups".
This document allocates five well-defined codepoints in the registry This document allocates five well-defined codepoints in the registry
for specific Finite Field Diffie-Hellman groups defined in for specific Finite Field Diffie-Hellman groups defined in
Appendix A. Appendix A.
In addition, the four highest codepoints in this range (508-511, In addition, the four highest codepoints in this range (508-511,
inclusive) are designated for PRIVATE USE by peers who have custom inclusive) are designated for PRIVATE USE by peers who have
Finite Field Diffie-Hellman groups that they wish to signal privately-developed Finite Field Diffie-Hellman groups that they wish
internally. to signal internally.
The updated registry section should be as follows: The updated registry section should be as follows:
+---------------------+-------------+---------+-----------------+ +---------------------+-------------+---------+-----------------+
| Value | Description | DTLS-OK | Reference | | Value | Description | DTLS-OK | Reference |
+---------------------+-------------+---------+-----------------+ +---------------------+-------------+---------+-----------------+
| 256 | ffdhe2048 | Y | [this document] | | 256 | ffdhe2048 | Y | [this document] |
| 257 | ffdhe3072 | Y | [this document] | | 257 | ffdhe3072 | Y | [this document] |
| 258 | ffdhe4096 | Y | [this document] | | 258 | ffdhe4096 | Y | [this document] |
| 259 | ffdhe6144 | Y | [this document] | | 259 | ffdhe6144 | Y | [this document] |
skipping to change at page 10, line 4 skipping to change at page 10, line 24
+---------------------+-------------+---------+-----------------+ +---------------------+-------------+---------+-----------------+
| 256 | ffdhe2048 | Y | [this document] | | 256 | ffdhe2048 | Y | [this document] |
| 257 | ffdhe3072 | Y | [this document] | | 257 | ffdhe3072 | Y | [this document] |
| 258 | ffdhe4096 | Y | [this document] | | 258 | ffdhe4096 | Y | [this document] |
| 259 | ffdhe6144 | Y | [this document] | | 259 | ffdhe6144 | Y | [this document] |
| 260 | ffdhe8192 | Y | [this document] | | 260 | ffdhe8192 | Y | [this document] |
| 508-511 (inclusive) | PRIVATE USE | - | - | | 508-511 (inclusive) | PRIVATE USE | - | - |
+---------------------+-------------+---------+-----------------+ +---------------------+-------------+---------+-----------------+
9. Security Considerations 9. Security Considerations
9.1. Negotiation resistance to active attacks 9.1. Negotiation resistance to active attacks
Because the contents of the Supported Groups extension is hashed in Because the contents of the Supported Groups extension are hashed in
the finished message, an active MITM that tries to filter or omit the finished message, an active MITM that tries to filter or omit
groups will cause the handshake to fail, but possibly not before groups will cause the handshake to fail, but possibly not before
getting the peer to do something they would not otherwise have done. getting the peer 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
extension, and select a group from the client's list, causing the extension, and select a group from the client's list, causing the
client to select a group it is willing to negotiate. It is client to select a group it is willing to negotiate. It is
unclear how this would be an effective attack. unclear how this would be an effective attack.
Pretend that a compatible server is actually non-compatible by Pretend that a compatible server is actually non-compatible by
negotiating a non-FFDHE ciphersuite. This is no different than negotiating a non-FFDHE ciphersuite. This is no different than
MITM ciphersuite filtering. MITM ciphersuite filtering.
Pretend that a compatible server is actually non-compatible by Pretend that a compatible server is actually non-compatible by
negotiating a DHE ciphersuite, with a custom (perhaps weak) group negotiating a DHE ciphersuite, with a custom (perhaps weak) group
chosen by the attacker. This is no worse than the current selected by the attacker. This is no worse than the current
scenario, and would require the attacker to be able to sign the scenario, and would require the attacker to be able to sign the
ServerDHParams, which should not be possible without access to the ServerDHParams, which should not be possible without access to the
server's secret key. server's secret key.
An attacker who impersonates the client can try to do the following: An attacker who impersonates the client can try to do the following:
Pretend that a compatible client is not compatible (e.g. by not Pretend that a compatible client is not compatible (e.g., by not
offering the Supported Groups extension, or by replacing the offering the Supported Groups extension, or by replacing the
Supported Groups extension with one that includes no FFDHE Supported Groups extension with one that includes no FFDHE
groups). This could cause the server to negotiate a weaker DHE groups). This could cause the server to negotiate a weaker DHE
group during the handshake, or to select a non-FFDHE ciphersuite, group during the handshake, or to select a non-FFDHE ciphersuite,
but it would fail to complete during the final check of the but it would fail to complete during the final check of the
Finished message. Finished message.
Pretend that a non-compatible client is compatible (e.g. by . Pretend that a non-compatible client is compatible (e.g., by
This could cause the server to select a particular named group in adding the Supported Groups extension, or by adding FFDHE groups
the ServerKeyExchange, or to avoid selecting an FFDHE ciphersuite. to the extension). This could cause the server to select a
The peers would fail to compute the final check of the Finished particular named group in the ServerKeyExchange, or to avoid
message. selecting an FFDHE ciphersuite. The peers would fail to compute
the final check of the Finished message.
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.
9.2. Group strength considerations 9.2. Group strength considerations
TLS implementations using FFDHE key exchange should consider the TLS implementations using FFDHE key exchange should consider the
strength of the group they negotiate. The strength of the selected strength of the group they negotiate. The strength of the selected
group is one of the factors which defines the connection's resiliance group is one of the factors that define the connection's resiliance
against attacks on the session's confidentiality and integrity, since against attacks on the session's confidentiality and integrity, since
the session keys are derived from the DHE handshake. the session keys are derived from the DHE handshake.
While attacks on integrity must generally happen while the session is While attacks on integrity must generally happen while the session is
in progress, attacks against session confidentiality can happen in progress, attacks against session confidentiality can happen
significantly later, if the entire TLS session is stored for offline significantly later, if the entire TLS session is stored for offline
analysis. Therefore, FFDHE groups should be selected by clients and analysis. Therefore, FFDHE groups should be selected by clients and
servers based on confidentiality guarantees they need. Sessions servers based on confidentiality guarantees they need. Sessions
which need extremely long-term confidentiality should prefer stronger which need extremely long-term confidentiality should prefer stronger
groups. groups.
[ENISA] provides rough estimates of group resistance to attack, and [ENISA] provides rough estimates of group resistance to attack, and
recommends that forward-looking implementations ("future systems") recommends that forward-looking implementations ("future systems")
should use FFDHE group sizes of at least 3072 bits. ffdhe3072 is should use FFDHE group sizes of at least 3072 bits. ffdhe3072 is
intended for use in these implementations. intended for use in these implementations.
Other sources (e.g. [NIST]) estimate the security levels of the DLOG Other sources (e.g., [NIST]) estimate the security levels of the DLOG
problem to be slightly more difficult than [ENISA]. This document's problem to be slightly more difficult than [ENISA]. This document's
suggested minimum exponent sizes in Appendix A for implementations suggested minimum exponent sizes in Appendix A for implementations
that use the short exponents optimization (Section 5.2) are that use the short exponents optimization (Section 5.2) are
deliberately conservative to account for the range of these deliberately conservative to account for the range of these
estimates. estimates.
9.3. Finite-Field DHE only 9.3. Finite-Field DHE only
Note that this document specifically targets only finite field-based Note that this document 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 address the non-ephemeral DH key exchange mechanisms, nor does it address
elliptic curve DHE (ECDHE) key exchange, which is defined in elliptic curve DHE (ECDHE) key exchange, which is defined in
[RFC4492]. [RFC4492].
Measured by computational cost to the TLS peers, ECDHE appears today Measured by computational cost to the TLS peers, ECDHE appears today
to offer much a stronger key exchange than FFDHE. to offer much a stronger key exchange mechanism than FFDHE.
9.4. Deprecating weak groups 9.4. 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 may therefore compromise the the premaster secret (and may therefore compromise the
confidentiality and integrity of the TLS session). confidentiality and integrity of the TLS session).
Revisions of this document should mark known-weak groups as Revisions of this document should mark known-weak groups as
skipping to change at page 12, line 36 skipping to change at page 13, line 11
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.
9.6. Timing attacks 9.6. 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).
9.7. Replay attacks from non-negotiated FFDHE 9.7. Replay attacks from non-negotiated FFDHE
[SECURE-RESUMPTION], [CROSS-PROTOCOL], and [SSL3-ANALYSIS] all show a [SECURE-RESUMPTION], [CROSS-PROTOCOL], and [SSL3-ANALYSIS] all show a
malicious peer using a bad FFDHE group to maneuver a client into malicious peer using a bad FFDHE group to maneuver a client into
selecting a pre-master secret of the peer's choice, which can be selecting a pre-master secret of the peer's choice, which can be
replayed to another server using a non-FFDHE key exchange, and can replayed to another server using a non-FFDHE key exchange, and can
then be bootstrapped to replay client authentication. then be bootstrapped to replay client authentication.
skipping to change at page 13, line 41 skipping to change at page 14, line 16
to all parts of the ciphersuite selection process, both key exchange to all parts of the ciphersuite selection process, both key exchange
and symmetric cipher choice. and symmetric cipher choice.
9.9. False Start 9.9. False Start
Clients capable of TLS False Start [FALSE-START] may receive a Clients capable of TLS False Start [FALSE-START] may receive a
proposed FFDHE group from a server that is attacker-controlled. In proposed FFDHE group from a server that is attacker-controlled. In
particular, the attacker can modify the ClientHello to strip the particular, the attacker can modify the ClientHello to strip the
proposed FFDHE groups, which may cause the server to offer a weaker proposed FFDHE groups, which may cause the server to offer a weaker
FFDHE group than it should, and this will not be detected until FFDHE group than it should, and this will not be detected until
receipt of the server's Finished message. This could cause the a receipt of the server's Finished message. This could cause a client
client using the False Start protocol modification to send data using the False Start protocol modification to send data encrypted
encrypted under a weak key agreement. under a weak key agreement.
Clients should have their own classification of FFDHE groups that are Clients should have their own classification of FFDHE groups that are
"cryptographically strong" in the same sense described in the "cryptographically strong" in the same sense described in the
description of symmetric ciphers in [FALSE-START], and SHOULD offer description of symmetric ciphers in [FALSE-START], and SHOULD offer
at least one of these in the initial handshake if they contemplate at least one of these in the initial handshake if they contemplate
using the False Start protocol modification with an FFDHE using the False Start protocol modification with an FFDHE
ciphersuite. ciphersuite.
Compatible clients performing a full handshake MUST NOT use the False Compatible clients performing a full handshake MUST NOT use the False
Start protocol modification if the server selects an FFDHE Start protocol modification if the server selects an FFDHE
skipping to change at page 16, line 39 skipping to change at page 17, line 15
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 of FFDHE groups to this registry may use this same New additions of FFDHE groups to this registry may use this same
derivation (e.g. with different bitlengths) or may choose their derivation (e.g., with different bitlengths) or may choose their
parameters in a different way, but must be clear about how the parameters in a different way, but must be clear about how the
parameters were derived. parameters were derived.
New additions of FFDHE groups MUST use a safe prime as the modulus to New additions of FFDHE groups MUST use a safe prime as the modulus to
enable the inexpensive peer verification described in Section 5.1. enable the inexpensive peer verification described in Section 5.1.
A.1. ffdhe2048 A.1. ffdhe2048
The 2048-bit group has registry value 256, and is calcluated from the The 2048-bit group has registry value 256, and is calculated from the
following formula: following formula:
The modulus is: p = 2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64 The modulus is: p = 2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 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
2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935
984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735
30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB
B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19
0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61
skipping to change at page 17, line 45 skipping to change at page 18, line 26
The estimated symmetric-equivalent strength of this group is 103 The estimated symmetric-equivalent strength of this group is 103
bits. bits.
Peers using ffdhe2048 that want to optimize their key exchange with a Peers using ffdhe2048 that want to optimize their key exchange with a
short exponent (Section 5.2) should choose a secret key of at least short exponent (Section 5.2) should choose a secret key of at least
225 bits. 225 bits.
A.2. ffdhe3072 A.2. ffdhe3072
The 3072-bit prime has registry value 257, and is calcluated from the The 3072-bit prime has registry value 257, and is calculated from the
following formula: following formula:
The modulus is: p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 The modulus is: p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 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 19, line 7 skipping to change at page 19, 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 5.2) should choose a secret key of at least short exponent (Section 5.2) should choose a secret key of at least
275 bits. 275 bits.
A.3. ffdhe4096 A.3. ffdhe4096
The 4096-bit group has registry value 258, and is calcluated from the The 4096-bit group has registry value 258, and is calculated 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 20, line 37 skipping to change at page 21, 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 5.2) should choose a secret key of at least short exponent (Section 5.2) should choose a secret key of at least
325 bits. 325 bits.
A.4. ffdhe6144 A.4. ffdhe6144
The 6144-bit group has registry value 259, and is calcluated from the The 6144-bit group has registry value 259, and is calculated 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 22, line 47 skipping to change at page 23, 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 5.2) should choose a secret key of at least short exponent (Section 5.2) should choose a secret key of at least
375 bits. 375 bits.
A.5. ffdhe8192 A.5. ffdhe8192
The 8192-bit group has registry value 260, and is calcluated from the The 8192-bit group has registry value 260, and is calculated 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. 51 change blocks. 
84 lines changed or deleted 118 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/