Internet DRAFT - draft-ray-tls-encrypted-handshake
draft-ray-tls-encrypted-handshake
Internet Engineering Task Force M. Ray
Internet-Draft PhoneFactor, Inc.
Intended status: Informational May 04, 2012
Expires: November 03, 2012
Transport Layer Security (TLS) Encrypted Handshake Extension
draft-ray-tls-encrypted-handshake-00
Abstract
This specification defines a Transport Layer Security (TLS) extension
which allows endpoints to negotiate the use of encryption with
forward secrecy at the beginning of the handshake. Two levels of
functionality are defined. Implementations are free to support one
or both levels, with the first level incurring no additional
computational or round-trip overhead. The TLS cryptographic
calculations are unchanged.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 03, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
Ray Expires November 03, 2012 [Page 1]
Internet-Draft Encrypted Handshake May 2012
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
4. ServerHello2a handshake message . . . . . . . . . . . . . . . 7
5. ServerHello2b handshake message . . . . . . . . . . . . . . . 8
6. ClientHello2 handshake message . . . . . . . . . . . . . . . . 9
7. Session resumption . . . . . . . . . . . . . . . . . . . . . . 9
8. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Although TLS [RFC 5246] provides a variety of cryptographic options
for securing application data it exposes an unnecessarily large
amount of plaintext during its initial handshake. The server's
identity, session resumption data, and session ticket data are all
sent in the clear. When client cert authentication is used, the
client's identity and the server's list of trusted root CAs is also
exposed. Typically the leaked information is sufficient to allow a
passive observer to fingerprint the TLS client and server
applications in use, and even to learn something about the connection
history of the user. This is arguably not a characteristic of an
ideal data security protocol.
Currently, the only defined way to fully encrypt a TLS handshake is
to first perform an unencrypted TLS handshake as an anonymous client
and server and then immediately renegotiate the connection all over
again in the new encrypted channel. The overhead this imposes is
significant, effectively doubling the number of (relatively
expensive) public key operations and requiring several additional
round trips. Furthermore, implementations often completely forbid
both the initial anon-anon TLS connection as well as client-initiated
renegotiation. Consequently, renegotiation is of limited use to
endpoints desiring greater protection for their handshake data.
The amount of interesting information sent in the clear will continue
to increase as new protocol features and applications are enabled by
new TLS extensions. But some interesting new applications may be
limited by the lack of encryption during the initial handshake.
Ray Expires November 03, 2012 [Page 2]
Internet-Draft Encrypted Handshake May 2012
In the unmodified TLS handshake, encryption of the record layer
begins seemingly as late in the process as possible. The reasons for
this design decision are unclear but it seems likely to be an
artifact of the historical under-use of ephemeral Diffie-Hellman
(DHE) cipher suites at the time (SSLv2 did not support them at all).
At the time, the need for the additional computation required by
traditional Diffie-Hellman key exchange was considered expensive and
for the RC4 cipher (very popular for its efficiency) DHE cipher
suites have never even been defined. Before the Server Name
Indication (SNI) extension [RFC 6066], it was not possible to serve
multiple HTTPS sites from a single IP address, so the specific site
to which the user was connecting was effectively already known.
There were no TLS extensions to carry interesting plaintext, so there
was little interesting plaintext to protect (client certs being a
notable exception).
Today we have a greater amount of interesting information present in
the handshake, faster hardware, and the far more efficient Elliptic
Curve DH algorithms. Some very high-traffic sites are configured to
select (EC)DHE cipher suites whenever the option is presented by the
client.[XXX cite] There are new extensions being proposed that would
benefit from encryption in the handshake.[XXX cite NP(N)] So this
appears to be an appropriate time to introduce early encryption via
ephemeral key exchange into the handshake.
1.1. Requirements Language
XXX reference presentation language in 5246 here?
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Functional Overview
The Encrypted Handshake (EH) extension allows endpoints to perform a
key exchange and begin record layer encryption as early in the
handshake as possible. Two levels of protection provide flexibility
for the client and server (and the implementation) to manage
practical considerations and level of effort.
While in general it is not possible to protect pre-authentication
data from an active man-in-the-middle type attacker, this extension
hides the bulk of the handshake data from a passive observer and can
detect active attacks as a failed handshake.
Level one provides encryption with forward secrecy for all data in
the Server Hello message (including Server Hello extensions) and all
data following. This level incurs no additional computational or
round-trip overhead over the traditional handshake and is intended to
require minimal changes to the implementation of existing libraries,
but it has the limitation that data sent by the client in the Client
Hello continues to be sent in the clear.
Ray Expires November 03, 2012 [Page 3]
Internet-Draft Encrypted Handshake May 2012
The second level of implementation encrypts all the same handshake
data as the first and additionally encrypts the most interesting
parts of the Client Hello (e.g. the extensions), but it requires an
additional round trip to the server.
Note that in the following diagrams, an asterisk (*) is used to
indicate a optional or situation-dependent messages, while square
brackets are placed around the [ChangeCipherSpec] message to reflect
its distinct record type.
For reference, the traditional TLS full handshake without Encrypted
Handshake looks like this:
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Unencrypted TLS full handshake.
When the use of EH level one has been negotiated, the ServerHello
message is split to allow the ChangeCipherSpec record to be sent as
soon as possible:
Client Server
ClientHello (with EH ext) -------->
ServerHello2a
[ChangeCipherSpec]
ServerHello2b
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
[ChangeCipherSpec]
Certificate*
ClientKeyExchange
CertificateVerify*
Finished -------->
<-------- Finished
Application Data <-------> Application Data
Ray Expires November 03, 2012 [Page 4]
Internet-Draft Encrypted Handshake May 2012
Figure 2. TLS full handshake using EH level one.
When the use of EH level two has been negotiated, the ServerHello
message is split and the ChangeCipherSpec record is sent early (as in
level one). The protocol then performs an additional round-trip in
order to allow the complete ClientHello2 to be transmitted within the
encrypted channel:
Client Server
ClientHello (with EH ext) -------->
ServerHello2a
<-------- [ChangeCipherSpec]
[ChangeCipherSpec]
ClientHello2 -------->
ServerHello2b
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
Finished -------->
<-------- Finished
Application Data <-------> Application Data
Figure 3. TLS full handshake using EH level two.
3. Extension Definition
This document defines a new TLS extension, "encrypted_handshake"
(having extension type [TBD]), which both negotiates the level of EH
implementation used for this handshake as well as transmits the
(EC)DH parameters necessary for early key exchange. This extension
is sent in both the client-to-server and server-to-client directions,
however server acceptance of the use of EH is also indicated by the
presence of a ServerHello2a message in response. The "extension
data" field of this extension contains one of two different
structures, or is empty, depending on the type of the message
carrying it.
Levels of support are indicated by the following enumeration.
However, levels higher than are defined here are reserved for future
use and receivers should treat them accordingly.
enum {
zero(0), one(1), two(2), inquire(255)
} EncryptedHandshakeLevel;
When the extension is carried on the Client Hello message it contains
Ray Expires November 03, 2012 [Page 5]
Internet-Draft Encrypted Handshake May 2012
an EncryptedHandshakeInfoCH structure:
struct {
EncryptedHandshakeLevel client_requested;
EncryptedHandshakeLevel client_required;
ClientDHParamSet client_dh_params_sets<0..2^16-1>;
Extension conditional_extensions<0..2^16-1>;
} EncryptedHandshakeInfoCH;
client_requested
The highest EH level being requested by the client.
client_required
The lowest EH level acceptable by the client.
client_dh_params_sets
Contains a set of (EC)DH(E) parameters for all
KeyExchangeAlgorithms used by any of the cipher_suites specified
in the ClientHello. The element type is defined below.
conditional_extensions
ClientHello-type extensions which are sent in the clear, but to be
processed by the server only if the server interprets the EH
extension and agrees to EH level one or higher. The definition of
'Extension' is from [TLS].
When the extension is carried on the Server Hello message it contains
an EncryptedHandshakeInfoSH structure:
struct {
EncryptedHandshakeLevel server_max_supported;
} EncryptedHandshakeInfoSH;
server_max_supported
The max EH level provided by the server, for informational
purposes.
The EH extension MAY be included on the ServerHello2a or
ServerHello2b message, or it may be omitted. If present, it MUST be
empty.
The ClientDHParamSet structure represents a set of (EC)DH parameters
and specifies with which cipher suites they may be used:
Ray Expires November 03, 2012 [Page 6]
Internet-Draft Encrypted Handshake May 2012
struct {
CipherSuite cipher_suites<2..2^16-2>;
uint16 params_size;
select (KeyExchangeAlgorithm) {
case dh_anon: // [TLS]
case dhe_dss:
case dhe_rsa:
DHParams params;
case ec_diffie_hellman: // [RFC 4492]
ClientECDiffieHellmanPublic params;
};
} ClientDHParamSet;
cipher_suites
The set of cipher suite(s) to which this ClientDHParamSet applies.
params_size
Number of bytes to follow in the params field.
params
The set of Diffie-Hellman parameters to be used for the specified
cipher suites.
4. ServerHello2a handshake message
This message forms the (unencrypted) first part of the modified
Server Hello handshake message when the use of EH level one or level
two has been accepted. Its purpose is to transmit to the client the
minimum information necessary to complete the key exchange subsequent
to a Client Hello which proposed the use of EH.
struct {
ProtocolVersion server_version;
Random random;
CipherSuite cipher_suite;
EncryptedHandshakeLevel server_accepted;
CompressionMethod compression_method;
uint16 params_size;
select (KeyExchangeAlgorithm) {
case dh_anon:
case dhe_dss:
case dhe_rsa:
ServerDHParams params; // [TLS]
case ec_diffie_hellman:
ServerECDHParams params; // [RFC 4492]
};
Extension extensions<0..2^16-1>;
} ServerHello2a;
server_version, random, compression_method
Defined identically to the corresponding field in the Server Hello
message of the TLS version in use.
Ray Expires November 03, 2012 [Page 7]
Internet-Draft Encrypted Handshake May 2012
cipher_suite
Defined identically to the corresponding field in the Server Hello
message of the TLS version in use. On a ServerHello2a message,
the selected cipher suite MUST be some type of DH cipher suite.
server_accepted
The Encrypted Handshake level accepted by the server for this
handshake. On a ServerHello2a message, this field must indicate
level one or level two.
extensions
ServerHello-type extensions included on the ServerHello2a
handshake message. Most extensions SHOULD sent under encryption
on a subsequent message, but if any are needed to establish the
cipher state they MUST be included here.
params_size
Number of bytes in the immediately following params field, not
including the params_size field itself.
params
Defined identically to the corresponding field in the Server Key
Exchange message. However, note that in this structure the
parameters are not signed.
5. ServerHello2b handshake message
This message forms the (encrypted) second part of the modified
ServerHello handshake message. Its purpose is to transmit to the
client the information present in an ordinary ServerHello that was
not transmitted in the ServerHello1a.
It is sent by the server subsequent to receiving from the client
either:
1. a ServerHello1a accepting EH level one behavior and
ChangeCipherSpec, or
2. a ServerHello1a accepting EH level two behavior ChangeCipherSpec,
and after the client's ClientHello2.
struct {
EncryptedHandshakeLevel server_max_supported;
SessionID session_id;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello2b;
server_max_supported
Ray Expires November 03, 2012 [Page 8]
Internet-Draft Encrypted Handshake May 2012
The max EH level provided by the server, for informational
purposes.
session_id, extensions
Defined identically to the corresponding field in the Server Hello
message of the TLS version in use. Ordinarily the EH extension is
omitted, must be empty if present.
6. ClientHello2 handshake message
This message is used to transmit information under encryption that
would have otherwise been sent in the clear in the ClientHello.
Certain fields such as protocol_version, client_random, and
cipher_suite are always necessary in order to proceed with any type
of handshake. However, in anticipation of successful negotiation of
EH level two, a client MAY elect to leave the session_id field empty
and extensions absent in the ClientHello in order to supply them
later under encryption in ClientHello2.
struct {
SessionID session_id;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello2;
session_id, extensions
Defined identically to the corresponding field in the Client Hello
message of the TLS version in use. Ordinarily the EH extension is
omitted, must be empty if present.
7. Session resumption
TLS provides a means to efficiently resume a previously established
session without having to perform any asymmetric crypto or cert
validation operations (often referred to as an "abbreviated
handshake"). Session resumption generally involves the presence of
the same Client/ServerHello extensions as a full handshake, so it has
equal need of encryption. EH levels one and two are both compatible
Ray Expires November 03, 2012 [Page 9]
Internet-Draft Encrypted Handshake May 2012
with session resumption.
Traditional TLS session resumption without EH looks like this:
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 4. Unencrypted TLS abbreviated handshake.
When the use of EH level one has been negotiated a handshake with
session resumption looks like this:
Client Server
ClientHello (with EH ext) -------->
ServerHello2a
[ChangeCipherSpec]
ServerHello2b
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 5. TLS abbreviated handshake with EH level one.
With EH level two, the client MAY leave the session_id field empty
when it is transmitted in the clear on the ClientHello, and still
perform resumption based on the session_id field on ClientHello2.
However, if client withholds the session_id value and the server then
declines EH level two session resumption will not be possible. But
because session resumption depends on the client having had recent
prior interaction with the server anyway, this unpredictability is
thought unlikely to become an issue in practice.
Client Server
ClientHello (with EH ext) -------->
ServerHello2a
<-------- [ChangeCipherSpec]
[ChangeCipherSpec]
ClientHello2 -------->
ServerHello2b
<-------- Finished
Finished -------->
Application Data <-------> Application Data
Figure 6. TLS abbreviated handshake with EH level two.
Ray Expires November 03, 2012 [Page 10]
Internet-Draft Encrypted Handshake May 2012
XXX TODO possible optimization: the client could indicate that it
wants to allow resumption without involving the key exchange. This
would seem to leave any ServerHello extensions completely in the
clear. But many extensions seem to be ignored or are required to
hold identical values on resumption, if they could be shown to be
redundant perhaps they could simply be eliminated.
8. Client Behavior
The client initiates the connection and begins the handshake using
the following sequence, after which the connection generally follows
the TLS specification.
1. The client constructs and sends the Client Hello message and EH
extension:
* A client that simply wishes to query a server for its level of
support SHOULD send a Client Hello containing an EH extension
with a client_required value of 'inquire'. The client SHOULD
set client_requested to the highest level that it supports
(which may be zero). Other than this specfic case, a client
SHOULD NOT set the client_required value higher than the
client_requested value.
* A client wishing not to use EH SHOULD send an EH extension on
the Client Hello with the client_requested and client_required
fields set to zero. This is semantically equivalent to
sending no EH extension at all, except that the Server Hello
may contain an EH extension in reply.
* A client wishing to use level one EH support only SHOULD send
an EH extension on the Client Hello with the client_requested
field set to one. The client SHOULD set the client_required
field to zero or one as appropriate.
* A client which desires level two EH support but will accept
level one as a fallback SHOULD send an EH extension on the
Client Hello with the client_requested field set to two and
the client_required field set to one. Since the protocol may
fall back to level one, the client SHOULD continue send all
necessary session_id and extensions on the initial Client
Hello.
* A client which requires level two EH support SHOULD set the
client_requested and client_required fields to two. Such a
client SHOULD NOT set any session_id or extension data on the
Ray Expires November 03, 2012 [Page 11]
Internet-Draft Encrypted Handshake May 2012
ClientHello, or send extensions other than EH and those
necessary for the key exchange and the integrity of the
connection. Renegotiation Info [RFC 5746] is an example of
such an extension.
2. If a client, requesting level one or higher, anticipates that
sensitive data could be returned via some ServerHello extension
in reply, and would prefer that extension not be evaluated at all
rather than have that reply transmitted in the clear, the client
MUST put the requesting ClientHello extension inside the
conditional_extensions section of the EH extension instead of
putting it in the usual ClientHello extension section.
3. The server's response to the ClientHello informs the client of
the EH level that will be in effect for the remainder of the
handshake:
* If the server's response is a standard Server Hello message,
the server is providing EH level zero. If any EH extension is
present, it MUST be ignored.
* If the server's response is a ServerHello2a message, this the
handshake is proceeding at EH level one or higher. The client
MUST proceed with the handshake at the level indicated by the
server_accepted field. (Level zero here represents an
unrecoverable protocol error.)
4. Now, depending on the negotiated level:
* If the client required an EH level higher than what was
accepted by the server, the client SHOULD continue with the
connection at least to the point of validating the server's
Finished message (in order to authenticate this information).
As the client continues the handshake it MUST avoid disclosing
any potentially interesting info (such as a client
certificate). After the server's Finished message has been
received and validated the client MUST close the connection
gracefully without transmitting any application data. The
remainder of this section does not apply.
* If EH level zero was negotiated (and no higher value was
required by the client) the client continues the TLS
connection as usual and the remainder of this section does not
apply.
* If EH level one or two was negotiated, the client handles the
TLS-defined fields and extensions on the ServerHello2a in the
usual way. Additionally, the client MUST examine the server-
selected cipher suite and confirm that it was (a) a cipher
suite the client proposed and (b) a cipher suite for which the
client had provided a ClientDHParamSet in the ClientHello EH
extension.
Ray Expires November 03, 2012 [Page 12]
Internet-Draft Encrypted Handshake May 2012
5. By combining data from the Client Hello and the ServerHello2a,
the client now has everything necessary to generate the
key_block.
* If EH level one is in use the client SHOULD NOT send his own
Change Cipher Spec record at this time, even though he could.
This somewhat artificial rule is to simply to promote
consistency among implementations. However, the client MUST
send his CCS and switch to the new cipher state before sending
any other handshake records.
* If EH level two is in use, the client MUST send a Change
Cipher Spec record, switch to the new cipher state, and
generate and send a ClientHello2 handshake message. The
session_id field SHOULD be populated with the appropriate
value if it was withheld from the original ClientHello,
otherwise it MUST be empty. Likewise, any ClientHello
extensions not sent in the original ClientHello (either in the
ClientHello extension area or in the EH extension
conditional_extensions area) SHOULD be included. The normal
rule of at most one of any specific type of extension MUST be
followed, but it now applies to the union of all three
possible ClientHello-type extension areas.
6. The client receives a ChangeCipherSpec record from the server and
and the new cipher state becomes active on the server-to-client
channel.
7. The client receives a ServerHello2b handshake message. The
client MUST interpret the session_id and extensions the usual
way, as defined for a normal ServerHello. The client MAY look at
the server_max_supported value for informational purposes, but
there is no guarantee that this value will remain valid for any
length of time. If any EH extension is present, it MUST be
ignored.
8. The remainder of the handshake proceeds as usual, with just these
annotations:
* We've already received the Change Cipher Spec from the server,
so we don't expect to receive another.
* In level one, the client will need to send a Change Cipher
Spec before his next handshake message, typically a
Certificate or Client Key Exchange message. In level two the
client will have already sent it.
Ray Expires November 03, 2012 [Page 13]
Internet-Draft Encrypted Handshake May 2012
* When the (EC)DH parameters are received again (at the expected
point in a non-EH handshake, e.g. the Server Key Exchange
message), they MUST be compared with the server params used in
the early key exchange. If the data covered by the server's
signature is not byte-for-byte the same as that used to
establish the current effective cipher state, the client MUST
treat this condition as it would an invalid signature on the
signed data itself. Even if the handshake was anonymous-
anonymous, these parameters MUST be compared.
9. Server Behavior
From the server's perspective, the handshake proceeds as follows:
1. The server receives a Client Hello message from the client and
looks for an EH extension:
* If no EH extension is present, the negotiated EH level is zero
server continues the TLS connection as usual. The remainder
of this section does not apply.
* If an EH extension is present, the server uses the smaller of
the client_requested value and the server's own maximum
supported implementation level as the EH level for the
handshake. The server MAY consider the client_required level
in this process. For example, a server might claim to only
support level zero or one, but could actually use level two if
the client "required" it, i.e., threatened to waste the
handshake.
2. If the negotiated EH level is zero and an EH extension was
present on the Client Hello, the server SHOULD include an EH
extension on the Server Hello in reply. The server SHOULD set
the server_max_supported field honestly. The server MUST NOT
process any extensions in the conditional_extensions. The TLS
handshake continues as usual and the remainder of this section
does not apply.
3. If the received client_required value is higher than the
client_requested value, or it is higher than that supported by
the server, the server SHOULD continue the handshake at the
smaller of the client_requested and max_server_supported values.
In such a case, the server's goal should be to transmit its
Finished message while disclosing a minimum of information. For
example, the Server Hello MUST NOT transmit a nonempty session_id
(except to indicate session resumption) and it MUST NOT include
extensions other than EH and those necessary for the integrity of
the connection. Renegotiation Info is an example of such an
extension. The server MUST NOT request client authentication.
Immediately after transmitting the Server Finished message the
server MUST close the connection gracefully without transferring
any application data.
Ray Expires November 03, 2012 [Page 14]
Internet-Draft Encrypted Handshake May 2012
4. At this point, the EH level is known to be at least one. The
server selects a cipher suite from those that (a) the server
supports, (b) are listed in the Client Hello cipher_suites, (c)
permit this type of key exchange, and (c) the client has provided
a valid set of (EC)DH parameters in the EH extension. If no
cipher suites of this type can be selected, the handshake fails.
5. The server generates its (EC)DH parameters and transmits a
ServerHello2a. Most of the fields correspond directly to those
of ServerHello, the others carry the server's (EC)DH params. The
server MUST NOT include extensions other than EH and those
necessary for the integrity of the connection. Renegotiation
Info is an example of such an extension.
6. The server transmits its Change Cipher Spec record and switches
to the new cipher state in the transmit direction.
7. If the negotiated EH level is two, the server receives a Change
Cipher Spec record from the client, switches to the new cipher
state in the receive direction and receives and processes a
ClientHello2 message from the client.
8. Any not-yet-processed extensions from the ClientHello and
ClientHello2, including those in the conditional_extensions
field, should be processed at this time.
9. The server constructs and transmits a ServerHello2b message. The
server SHOULD set the server_max_supported field honestly. The
server SHOULD include any ServerHello-type extensions in reply
that were not already sent on the ServerHello2a.
10. The remainder of the handshake proceeds as usual, with just
these annotations:
* In level two, we've already received the Change Cipher Spec
from the client so we don't expect to receive another.
* When the (EC)DH parameters are received again (at the
expected point in a non-EH handshake, e.g. the Client Key
Exchange message), they MUST be compared with the client
params used in the early key exchange. If the data covered
here is not byte-for-byte the same as that used to establish
the current effective cipher state, the server MUST treat
this condition as it would an invalid signature on a
Certificate Verify or an invalid verify_data in the client's
Finished message. Even if the handshake did not involve
client authentication, these parameters MUST be compared.
10. Other Considerations
Ray Expires November 03, 2012 [Page 15]
Internet-Draft Encrypted Handshake May 2012
Implementers of TLS libraries that allow configuration of cipher
suites (e.g. a permitted cipher suites list ordered by preference)
are encouraged provide a means to configure this list separately for
EH-requesting clients. This is to prevent a situation where server
support of this extension is restricted by a simple server preference
for non-DHE cipher suites.
There are reportedly some defective servers [XXX cite?] that fail in
an ungraceful manner if sent a Client Hello message larger than a
certain size which is smaller than the defined maximum. Clients
wishing to minimize the risk of interoperability with such servers
may consider limiting the number of parameter sets they include in
the Client Hello, or sending only the smaller ECDH types. It is
possible that these noncompliant servers are older and less well-
maintained implementations and tend not to support newer features
such as ECDH.
11. IANA Considerations
XXX allocation of encrypted_handshake Hello extension
XXX allocation of ServerHello2a handshake message id
XXX allocation of ServerHello2b handshake message id
XXX allocation of ClientHello2 handshake message id
12. Security Considerations
Insofar as TLS is inherently a data security protocol, this entire
document is about security. However, a few points of concern are
probably worth mentioning.
o It cannot be repeated often enough that the early encryption
negotiated by the EH extension *only* provides protection from
passive eavesdropper. It *can not* resist a man-in-the-middle
type active attacker who wishes to steal a sample of the plaintext
the client and server intended to exchange (doing so will break
the handshake however). Like TLS without EH, full protection from
an active attacker only begins after the Finished messages are
received and validated by each side.
o It could happen that the handshake encryption so obvious in a
packet capture will give users a false sense of security. The
difference between unauthenticated encryption and an authenticated
(and properly bound) encrypted channel is a subtle distinction
even to protocol professionals. We must be vigilant to inform
users of this extension of these limits and to not rely on it for
protections beyond what it can deliver.
Ray Expires November 03, 2012 [Page 16]
Internet-Draft Encrypted Handshake May 2012
o This extension is not expected to introduce any significant new
computational Denial of Service (DoS) vulnerabilities. TLS
without this extension allows an attacker to obligate the server
to three or more useless asymmetric crypto operations (ephemeral
key exchange, server DH parameter signing, client cert signature
verification, and possibly client cert signature chain validation)
with no significant computation required on the part of the
attacker. This extension adds no new crypto operations to an
existing DHE handshake. In fact, an attacker who negotiates its
use finds himself now obligated to perform an asymmetric crypto
operation in order to proceed further.
However, EH level two introduces an additional round trip from
server to client and back. Under conditions of severe packet loss
(e.g., during a DDoS event) these additional handshake packets may
translate into a reduced success rate for clients. Facing a worst
case scenario, a server operator may feel desperate to reduce load
by disabling any excess features. Forward secrecy and client
privacy being relatively abstract benefits, in the face of a very
concrete service outage features such as Diffie-Hellman and EH
level two will be tempting targets.
o Although this extension does not modify the TLS cryptographic
calculations, it does change the order of certain messages. The
author does not (currently :-) believe that this introduces any
new weaknesses (and it may even mitigate some) but this is
certainly in need of careful expert review. XXX
13. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S. and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
Author's Address
Ray Expires November 03, 2012 [Page 17]
Internet-Draft Encrypted Handshake May 2012
Marsh Ray
PhoneFactor, Inc.
7301 W 129th Street
Overland Park, KS 66213
USA
Email: marsh@extendedsubset.com
Ray Expires November 03, 2012 [Page 18]
