draft-ietf-tls-tls13-04.txt   draft-ietf-tls-tls13-05.txt 
Network Working Group T. Dierks Network Working Group E. Rescorla
Internet-Draft Independent Internet-Draft RTFM, Inc.
Obsoletes: 3268, 4346, 4366, 5246 (if E. Rescorla Obsoletes: 3268, 4346, 4366, 5246 (if March 09, 2015
approved) RTFM, Inc. approved)
Updates: 4492 (if approved) January 03, 2015 Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 7, 2015 Expires: September 10, 2015
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-04 draft-ietf-tls-tls13-05
Abstract Abstract
This document specifies Version 1.3 of the Transport Layer Security This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications security (TLS) protocol. The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping, communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. tampering, or message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 7, 2015. This Internet-Draft will expire on September 10, 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 34 skipping to change at page 2, line 34
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 7 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 7
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 10 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 10
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 10 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12 4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12
4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14
5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 14 5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 15
6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 15 6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16
6.1. Connection States . . . . . . . . . . . . . . . . . . . . 16 6.1. Connection States . . . . . . . . . . . . . . . . . . . . 16
6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19
6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 18 6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19
6.2.2. Record Payload Protection . . . . . . . . . . . . . . 19 6.2.2. Record Payload Protection . . . . . . . . . . . . . . 20
6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 21 6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 22
7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 22 7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23
7.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23 7.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 24
7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 24 7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25
7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25 7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25
7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 28 7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 29
7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 33 7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 33
7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 34 7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 34
7.3.2. Client Key Share Message . . . . . . . . . . . . . . 37 7.3.2. Client Key Share Message . . . . . . . . . . . . . . 37
7.3.3. Server Key Share Message . . . . . . . . . . . . . . 48 7.3.3. Server Key Share Message . . . . . . . . . . . . . . 48
7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 49 7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 49
7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 49 7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 49
7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 52 7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 52
7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 53 7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 53
7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 55 7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 55
7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 56 7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 56
skipping to change at page 3, line 27 skipping to change at page 3, line 27
9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 61 9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 61
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 61 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 61
11. Security Considerations . . . . . . . . . . . . . . . . . . . 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.1. Normative References . . . . . . . . . . . . . . . . . . 63 13.1. Normative References . . . . . . . . . . . . . . . . . . 63
13.2. Informative References . . . . . . . . . . . . . . . . . 65 13.2. Informative References . . . . . . . . . . . . . . . . . 65
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Appendix A. Protocol Data Structures and Constant Values . . . . 69 Appendix A. Protocol Data Structures and Constant Values . . . . 69
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Change Cipher Specs Message . . . . . . . . . . . . . . . 69 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69
A.3. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70
A.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70 A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71
A.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71 A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 74
A.4.2. Server Authentication and Key Exchange Messages . . . 73 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 74
A.4.3. Client Authentication and Key Exchange Messages . . . 73 A.3.4. Handshake Finalization Messages . . . . . . . . . . . 75
A.4.4. Handshake Finalization Message . . . . . . . . . . . 74 A.4. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 75
A.5. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 74 A.5. The Security Parameters . . . . . . . . . . . . . . . . . 77
A.6. The Security Parameters . . . . . . . . . . . . . . . . . 76 A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 77
A.7. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 76 Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 78
Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . 77 Appendix C. Cipher Suite Definitions . . . . . . . . . . . . . . 81
Appendix C. Cipher Suite Definitions . . . . . . . . . . . . . . 80 Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 81
Appendix D. Implementation Notes . . . . . . . . . . . . . . . . 80 D.1. Random Number Generation and Seeding . . . . . . . . . . 81
D.1. Random Number Generation and Seeding . . . . . . . . . . 80 D.2. Certificates and Authentication . . . . . . . . . . . . . 82
D.2. Certificates and Authentication . . . . . . . . . . . . . 81 D.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 82
D.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 81 D.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 82
D.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 81 Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 83
Appendix E. Backward Compatibility . . . . . . . . . . . . . . . 82 E.1. Compatibility with prior versions . . . . . . . . . . . . 83
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 . . . . . . . 82 E.2. Compatibility with SSL . . . . . . . . . . . . . . . . . 85
E.2. Compatibility with SSL 2.0 . . . . . . . . . . . . . . . 84 Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 85
E.3. Avoiding Man-in-the-Middle Version Rollback . . . . . . . 85 F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 85
Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 86
F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 86
F.1.1. Authentication and Key Exchange . . . . . . . . . . . 86 F.1.1. Authentication and Key Exchange . . . . . . . . . . . 86
F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 87 F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 87
F.1.3. Detecting Attacks Against the Handshake Protocol . . 88 F.1.3. Detecting Attacks Against the Handshake Protocol . . 87
F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 88 F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 87
F.2. Protecting Application Data . . . . . . . . . . . . . . . 88 F.2. Protecting Application Data . . . . . . . . . . . . . . . 88
F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 89 F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 88
F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 89 F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 89
Appendix G. Working Group Information . . . . . . . . . . . . . 89 Appendix G. Working Group Information . . . . . . . . . . . . . 89
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 90 Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 89
1. Introduction 1. Introduction
DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen DISCLAIMER: This is a WIP draft of TLS 1.3 and has not yet seen
significant security analysis. significant security analysis.
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this
draft is maintained in GitHub. Suggested changes should be submitted draft is maintained in GitHub. Suggested changes should be submitted
as pull requests at https://github.com/tlswg/tls13-spec. as pull requests at https://github.com/tlswg/tls13-spec.
Instructions are on that page as well. Editorial changes can be Instructions are on that page as well. Editorial changes can be
skipping to change at page 5, line 32 skipping to change at page 5, line 30
Higher-level protocols can layer on top of the TLS protocol Higher-level protocols can layer on top of the TLS protocol
transparently. The TLS standard, however, does not specify how transparently. The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS. of protocols that run on top of TLS.
1.1. Requirements Terminology 1.1. Requirements Terminology
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
1.2. Major Differences from TLS 1.2 1.2. Major Differences from TLS 1.2
draft-05
- Prohibit SSL negotiation for backwards compatibility.
- Fix which MS is used for exporters.
draft-04 draft-04
- Modify key computations to include session hash. - Modify key computations to include session hash.
- Remove ChangeCipherSpec - Remove ChangeCipherSpec
- Renumber the new handshake messages to be somewhat more consistent - Renumber the new handshake messages to be somewhat more consistent
with existing convention and to remove a duplicate registration. with existing convention and to remove a duplicate registration.
- Remove renegotiation. - Remove renegotiation.
- Update format of signatures with context. - Update format of signatures with context.
- Remove point format negotiation. - Remove point format negotiation.
draft-03
- Remove GMT time. - Remove GMT time.
- Merge in support for ECC from RFC 4492 but without explicit - Merge in support for ECC from RFC 4492 but without explicit
curves. curves.
- Remove the unnecessary length field from the AD input to AEAD - Remove the unnecessary length field from the AD input to AEAD
ciphers. ciphers.
- Rename {Client,Server}KeyExchange to {Client,Server}KeyShare - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare
skipping to change at page 15, line 47 skipping to change at page 16, line 21
6. The TLS Record Protocol 6. The TLS Record Protocol
The TLS Record Protocol is a layered protocol. At each layer, The TLS Record Protocol is a layered protocol. At each layer,
messages may include fields for length, description, and content. messages may include fields for length, description, and content.
The Record Protocol takes messages to be transmitted, fragments the The Record Protocol takes messages to be transmitted, fragments the
data into manageable blocks, protects the records, and transmits the data into manageable blocks, protects the records, and transmits the
result. Received data is decrypted and verified, reassembled, and result. Received data is decrypted and verified, reassembled, and
then delivered to higher-level clients. then delivered to higher-level clients.
Four protocols that use the record protocol are described in this Three protocols that use the record protocol are described in this
document: the handshake protocol, the alert protocol, the change document: the handshake protocol, the alert protocol, and the
cipher spec protocol, and the application data protocol. In order to application data protocol. In order to allow extension of the TLS
allow extension of the TLS protocol, additional record content types protocol, additional record content types can be supported by the
can be supported by the record protocol. New record content type record protocol. New record content type values are assigned by IANA
values are assigned by IANA in the TLS Content Type Registry as in the TLS Content Type Registry as described in Section 12.
described in Section 12.
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST send an implementation receives an unexpected record type, it MUST send an
unexpected_message alert. unexpected_message alert.
Any protocol designed for use over TLS must be carefully designed to Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it. As a practical matter, deal with all possible attacks against it. As a practical matter,
this means that the protocol designer must be aware of what security this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on properties TLS does and does not provide and cannot safely rely on
skipping to change at page 16, line 29 skipping to change at page 16, line 50
by encryption. If this information is itself sensitive, application by encryption. If this information is itself sensitive, application
designers may wish to take steps (padding, cover traffic) to minimize designers may wish to take steps (padding, cover traffic) to minimize
information leakage. information leakage.
6.1. Connection States 6.1. Connection States
A TLS connection state is the operating environment of the TLS Record A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a record protection algorithm and its Protocol. It specifies a record protection algorithm and its
parameters as well as the record protection keys and IVs for the parameters as well as the record protection keys and IVs for the
connection in both the read and the write directions. The security connection in both the read and the write directions. The security
parameters are be set by the TLS Handshake Protocol, which also parameters are set by the TLS Handshake Protocol, which also
determines when new cryptographic keys are installed and used for determines when new cryptographic keys are installed and used for
record protection. The initial current state always specifies that record protection. The initial current state always specifies that
records are not protected. records are not protected.
The security parameters for a TLS Connection read and write state are The security parameters for a TLS Connection read and write state are
set by providing the following values: set by providing the following values:
connection end connection end
Whether this entity is considered the "client" or the "server" in Whether this entity is considered the "client" or the "server" in
this connection. this connection.
skipping to change at page 19, line 10 skipping to change at page 19, line 33
message boundaries are not preserved in the record layer (i.e., message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be into a single TLSPlaintext record, or a single message MAY be
fragmented across several records). fragmented across several records).
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
ProtocolVersion version = { 3, 4 }; /* TLS v1.3*/
enum { enum {
reserved(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
skipping to change at page 22, line 4 skipping to change at page 22, line 30
As a special case, we define the NULL_NULL AEAD cipher which is As a special case, we define the NULL_NULL AEAD cipher which is
simply the identity operation and thus provides no security. This simply the identity operation and thus provides no security. This
cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL
cipher suite. cipher suite.
6.3. Key Calculation 6.3. Key Calculation
[[OPEN ISSUE: This needs to be revised. See [[OPEN ISSUE: This needs to be revised. See
https://github.com/tlswg/tls13-spec/issues/5]] The Record Protocol https://github.com/tlswg/tls13-spec/issues/5]] The Record Protocol
requires an algorithm to generate keys required by the current requires an algorithm to generate keys required by the current
connection state (see Appendix A.6) from the security parameters connection state (see Appendix A.5) from the security parameters
provided by the handshake protocol. provided by the handshake protocol.
The master secret is expanded into a sequence of secure bytes, which The master secret is expanded into a sequence of secure bytes, which
is then split to a client write encryption key and a server write is then split to a client write encryption key and a server write
encryption key. Each of these is generated from the byte sequence in encryption key. Each of these is generated from the byte sequence in
that order. Unused values are empty. Some ciphers may additionally that order. Unused values are empty. Some ciphers may additionally
require a client write IV and a server write IV. require a client write IV and a server write IV.
When keys are generated, the then current master secret (MS) is used When keys are generated, the current master secret (MS) is used as an
as an entropy source. For handshake records, this means the entropy source. For handshake records, this means the
hs_master_secret. For application data records, this means the hs_master_secret. For application data records, this means the
regular master_secret. regular master_secret.
To generate the key material, compute To generate the key material, compute
key_block = PRF(MS, key_block = PRF(MS,
"key expansion", "key expansion",
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random); SecurityParameters.client_random);
skipping to change at page 23, line 12 skipping to change at page 23, line 39
An arbitrary byte sequence chosen by the server to identify an An arbitrary byte sequence chosen by the server to identify an
active or resumable session state. active or resumable session state.
peer certificate peer certificate
X509v3 [RFC3280] certificate of the peer. This element of the X509v3 [RFC3280] certificate of the peer. This element of the
state may be null. state may be null.
cipher spec cipher spec
Specifies the authentication and key establishment algorithms, the Specifies the authentication and key establishment algorithms, the
pseudorandom function (PRF) used to generate keying material, and pseudorandom function (PRF) used to generate keying material, and
the record protection algorithm (See Appendix A.6 for formal the record protection algorithm (See Appendix A.5 for formal
definition.) definition.)
resumption premaster secret resumption premaster secret
48-byte secret shared between the client and server. 48-byte secret shared between the client and server.
is resumable is resumable
A flag indicating whether the session can be used to initiate new A flag indicating whether the session can be used to initiate new
connections. connections.
These items are then used to create security parameters for use by These items are then used to create security parameters for use by
skipping to change at page 25, line 5 skipping to change at page 25, line 18
ending in order to avoid a truncation attack. Either party may ending in order to avoid a truncation attack. Either party may
initiate the exchange of closing messages. initiate the exchange of closing messages.
close_notify close_notify
This message notifies the recipient that the sender will not send This message notifies the recipient that the sender will not send
any more messages on this connection. Note that as of TLS 1.1, any more messages on this connection. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice. with widespread implementation practice.
Either party may initiate a close by sending a close_notify alert. Either party MAY initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored. Any data received after a closure alert is ignored.
Unless some other fatal alert has been transmitted, each party is Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side required to send a close_notify alert before closing the write side
of the connection. The other party MUST respond with a close_notify of the connection. The other party MUST respond with a close_notify
alert of its own and close down the connection immediately, alert of its own and close down the connection immediately,
discarding any pending writes. It is not required for the initiator discarding any pending writes. It is not required for the initiator
of the close to wait for the responding close_notify alert before of the close to wait for the responding close_notify alert before
closing the read side of the connection. closing the read side of the connection.
skipping to change at page 34, line 42 skipping to change at page 34, line 42
omitted, however. omitted, however.
New handshake message types are assigned by IANA as described in New handshake message types are assigned by IANA as described in
Section 12. Section 12.
7.3.1. Hello Messages 7.3.1. Hello Messages
The hello phase messages are used to exchange security enhancement The hello phase messages are used to exchange security enhancement
capabilities between the client and server. When a new session capabilities between the client and server. When a new session
begins, the record layer's connection state AEAD algorithm is begins, the record layer's connection state AEAD algorithm is
initialized to NULL_NULL. The current connection state is used for initialized to NULL_NULL.
renegotiation messages.
7.3.1.1. Client Hello 7.3.1.1. Client Hello
When this message will be sent: When this message will be sent:
When a client first connects to a server, it is required to send When a client first connects to a server, it is required to send
the ClientHello as its first message. The client will also send a the ClientHello as its first message. The client will also send a
ClientHello when the server has responded to its ClientHello with ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare. In that case, the client MUST match the client's ClientKeyShare. In that case, the client MUST
skipping to change at page 37, line 13 skipping to change at page 37, line 10
session_id session_id
The ID of a session the client wishes to use for this connection. The ID of a session the client wishes to use for this connection.
This field is empty if no session_id is available, or if the This field is empty if no session_id is available, or if the
client wishes to generate new security parameters. client wishes to generate new security parameters.
cipher_suites cipher_suites
This is a list of the cryptographic options supported by the This is a list of the cryptographic options supported by the
client, with the client's first preference first. If the client, with the client's first preference first. If the
session_id field is not empty (implying a session resumption session_id field is not empty (implying a session resumption
request), this vector MUST include at least the cipher_suite from request), this vector MUST include at least the cipher_suite from
that session. Values are defined in Appendix A.5. that session. Values are defined in Appendix A.4.
compression_methods compression_methods
Versions of TLS before 1.3 supported compression and the list of Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field. For any TLS 1.3 compression methods was supplied in this field. For any TLS 1.3
ClientHello, this field MUST contain only the "null" compression ClientHello, this field MUST contain only the "null" compression
method with the code point of 0. If a TLS 1.3 ClientHello is method with the code point of 0. If a TLS 1.3 ClientHello is
received with any other value in this field, the server MUST received with any other value in this field, the server MUST
generate a fatal "illegal_parameter" alert. Note that TLS 1.3 generate a fatal "illegal_parameter" alert. Note that TLS 1.3
servers may receive TLS 1.2 or prior ClientHellos which contain servers may receive TLS 1.2 or prior ClientHellos which contain
other compression methods and MUST follow the procedures for the other compression methods and MUST follow the procedures for the
skipping to change at page 46, line 25 skipping to change at page 46, line 25
sect193r1 (4), sect193r2 (5), sect233k1 (6), sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9), sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12), sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15), sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18), secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21), secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24), secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), secp521r1 (25),
// Finite Field Groups. // Finite Field Groups.
ffdhe2432(256), ffdhe3072(257), ffdhe4096(258), ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
ffdhe6144(259), ffdhe8192(260), ffdhe8192(259),
// Reserved Code Points. // Reserved Code Points.
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
reserved(0xFF01), reserved(0xFF01),
reserved(0xFF02), reserved(0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1> NamedGroup named_group_list<1..2^16-1>
} NamedGroupList; } NamedGroupList;
sect163k1, etc: Indicates support of the corresponding named curve sect163k1, etc
The named curves defined here are those specified in SEC 2 [13]. Indicates support of the corresponding named curve The named
Note that many of these curves are also recommended in ANSI X9.62 curves defined here are those specified in SEC 2 [13]. Note that
[X962] and FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are many of these curves are also recommended in ANSI X9.62 [X962] and
reserved for private use. Values 0xFF01 and 0xFF02 were used in FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are reserved for
previous versions of TLS but MUST NOT be offered by TLS 1.3 private use. Values 0xFF01 and 0xFF02 were used in previous
implementations. [[OPEN ISSUE: Triage curve list.]] versions of TLS but MUST NOT be offered by TLS 1.3
implementations. [[OPEN ISSUE: Triage curve list.]]
ffdhe2432, etc: Indicates support of the corresponding finite field ffdhe2432, etc
group, defined in [I-D.ietf-tls-negotiated-ff-dhe] Indicates support of the corresponding finite field group, defined
in [I-D.ietf-tls-negotiated-ff-dhe]
Items in named_curve_list are ordered according to the client's Items in named_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192; As an example, a client that only supports secp192r1 (aka NIST P-192;
value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015)
and prefers to use secp192r1 would include a TLS extension consisting and prefers to use secp192r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the of the following octets. Note that the first two octets indicate the
extension type (Supported Group Extension): extension type (Supported Group Extension):
skipping to change at page 55, line 31 skipping to change at page 55, line 31
send and receive application data over the connection. This data send and receive application data over the connection. This data
will be protected under keys derived from the hs_master_secret will be protected under keys derived from the hs_master_secret
(see Section 8. (see Section 8.
Structure of this message: Structure of this message:
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
verify_data verify_data
PRF(hs_master_secret, finished_label, Hash(handshake_messages)) PRF(hs_master_secret, finished_label, Hash(handshake_messages))
[0..verify_data_length-1]; [0..verify_data_length-1];
finished_label finished_label
For Finished messages sent by the client, the string For Finished messages sent by the client, the string "client
"client finished". For Finished messages sent by the server, finished". For Finished messages sent by the server, the string
the string "server finished". "server finished".
Hash denotes a Hash of the handshake messages. For the PRF Hash denotes a Hash of the handshake messages. For the PRF
defined in Section 5, the Hash MUST be the Hash used as the basis defined in Section 5, the Hash MUST be the Hash used as the basis
for the PRF. Any cipher suite which defines a different PRF MUST for the PRF. Any cipher suite which defines a different PRF MUST
also define the Hash to use in the Finished computation. also define the Hash to use in the Finished computation.
In previous versions of TLS, the verify_data was always 12 octets In previous versions of TLS, the verify_data was always 12 octets
long. In the current version of TLS, it depends on the cipher long. In the current version of TLS, it depends on the cipher
suite. Any cipher suite which does not explicitly specify suite. Any cipher suite which does not explicitly specify
verify_data_length has a verify_data_length equal to 12. This verify_data_length has a verify_data_length equal to 12. This
skipping to change at page 59, line 45 skipping to change at page 59, line 45
hs_master_secret = PRF(pre_master_secret, "handshake master secret", hs_master_secret = PRF(pre_master_secret, "handshake master secret",
session_hash) session_hash)
[0..47]; [0..47];
During resumption, the premaster secret is initialized with the During resumption, the premaster secret is initialized with the
"resumption premaster secret", rather than using the values from the "resumption premaster secret", rather than using the values from the
ClientKeyShare/ServerKeyShare exchange. ClientKeyShare/ServerKeyShare exchange.
This master secret value is used to generate the record protection This master secret value is used to generate the record protection
keys used for the handshake, as described in Section 6.3. It is also keys used for the handshake, as described in Section 6.3.
used with TLS Exporters [RFC5705].
Once the hs_master_secret has been computed, the premaster secret Once the hs_master_secret has been computed, the premaster secret
SHOULD be deleted from memory. SHOULD be deleted from memory.
Once the last non-Finished message has been sent, the client and Once the last non-Finished message has been sent, the client and
server then compute the master secret which will be used for the server then compute the master secret which will be used for the
remainder of the session: remainder of the session. It is also used with TLS Exporters
[RFC5705].
master_secret = PRF(hs_master_secret, "extended master secret", master_secret = PRF(hs_master_secret, "extended master secret",
session_hash) session_hash)
[0..47]; [0..47];
If the server does not request client authentication, the master If the server does not request client authentication, the master
secret can be computed at the time that the server sends its secret can be computed at the time that the server sends its
Finished, thus allowing the server to send traffic on its first Finished, thus allowing the server to send traffic on its first
flight (see [TODO] for security considerations on this practice.) If flight (see [TODO] for security considerations on this practice.) If
the server requests client authentication, this secret can be the server requests client authentication, this secret can be
skipping to change at page 61, line 20 skipping to change at page 61, line 19
flight, as it covers the client's Certificate and CertificateVerify. flight, as it covers the client's Certificate and CertificateVerify.
8.1.2. Diffie-Hellman 8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the pre_master_secret, and is converted negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above. Leading bytes of Z that into the master_secret, as specified above. Leading bytes of Z that
contain all zero bits are stripped before it is used as the contain all zero bits are stripped before it is used as the
pre_master_secret. pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's certificate.
8.1.3. Elliptic Curve Diffie-Hellman 8.1.3. Elliptic Curve Diffie-Hellman
All ECDH calculations (including parameter and key generation as well All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6] as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation using the ECKAS-DH1 scheme with the identity map as key derivation
function (KDF), so that the premaster secret is the x-coordinate of function (KDF), so that the premaster secret is the x-coordinate of
the ECDH shared secret elliptic curve point represented as an octet the ECDH shared secret elliptic curve point represented as an octet
string. Note that this octet string (Z in IEEE 1363 terminology) as string. Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros Primitive, has constant length for any given field; leading zeros
skipping to change at page 61, line 44 skipping to change at page 61, line 40
(Note that this use of the identity KDF is a technicality. The (Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use the premaster secret for anything because TLS does not directly use the premaster secret for anything
other than for computing the master secret.) other than for computing the master secret.)
9. Mandatory Cipher Suites 9. Mandatory Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the cipher otherwise, a TLS-compliant application MUST implement the cipher
suite TODO:Needs to be selected [1]. (See Appendix A.5 for the suite TODO:Needs to be selected [1]. (See Appendix A.4 for the
definition). definition).
10. Application Data Protocol 10. Application Data Protocol
Application data messages are carried by the record layer and are Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state. The fragmented and encrypted based on the current connection state. The
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
11. Security Considerations 11. Security Considerations
skipping to change at page 65, line 7 skipping to change at page 65, line 7
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
13.2. Informative References 13.2. Informative References
[BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS", CRYPTO98
LNCS vol. 1462, pages: 1-12, 1998, Advances in Cryptology,
1998.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures", May 2004, Problems and Countermeasures", May 2004,
<http://www.openssl.org/~bodo/tls-cbc.txt>. <http://www.openssl.org/~bodo/tls-cbc.txt>.
[CCM] "NIST Special Publication 800-38C: The CCM Mode for [CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality", May 2004, Authentication and Confidentiality", May 2004,
<http://csrc.nist.gov/publications/nistpubs/800-38C/ <http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf>. SP800-38C.pdf>.
[DES] "Data Encryption Standard (DES)", NIST FIPS PUB 46-3, [DES] "Data Encryption Standard (DES)", NIST FIPS PUB 46-3,
skipping to change at page 65, line 48 skipping to change at page 65, line 43
implementation error", August 2006, <http://www.imc.org/ implementation error", August 2006, <http://www.imc.org/
ietf-openpgp/mail-archive/msg14307.html>. ietf-openpgp/mail-archive/msg14307.html>.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, November 2007. Special Publication 800-38D, November 2007.
[I-D.ietf-tls-negotiated-ff-dhe] [I-D.ietf-tls-negotiated-ff-dhe]
Gillmor, D., "Negotiated Finite Field Diffie-Hellman Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for TLS", draft-ietf-tls-negotiated- Ephemeral Parameters for TLS", draft-ietf-tls-negotiated-
ff-dhe-05 (work in progress), December 2014. ff-dhe-07 (work in progress), March 2015.
[I-D.ietf-tls-session-hash] [I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf- Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-03 (work in progress), November 2014. tls-session-hash-03 (work in progress), November 2014.
[I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-02 (work in progress), March
2015.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
Syntax Standard, version 1.5", November 1993. Syntax Standard, version 1.5", November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Syntax Standard, version 1.5", November 1993. Syntax Standard, version 1.5", November 1993.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
skipping to change at page 67, line 33 skipping to change at page 67, line 33
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081, November Layer Security (TLS) Authentication", RFC 5081, November
2007. 2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM v. 21, n. 2, pp. Cryptosystems", Communications of the ACM v. 21, n. 2, pp.
120-126., February 1978. 120-126., February 1978.
[SSL2] Netscape Communications Corp., "The SSL Protocol", [SSL2] Netscape Communications Corp., "The SSL Protocol",
February 1995. February 1995.
[SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0 [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL 3.0
Protocol", November 1996. Protocol", November 1996.
skipping to change at page 69, line 9 skipping to change at page 69, line 9
13.3. URIs 13.3. URIs
[1] https://github.com/tlswg/tls13-spec/issues/32 [1] https://github.com/tlswg/tls13-spec/issues/32
[2] mailto:tls@ietf.org [2] mailto:tls@ietf.org
Appendix A. Protocol Data Structures and Constant Values Appendix A. Protocol Data Structures and Constant Values
This section describes protocol types and constants. This section describes protocol types and constants.
[[TODO: Clean this up to match the in-text description.]]
A.1. Record Layer A.1. Record Layer
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
ProtocolVersion version = { 3, 4 }; /* TLS v1.3*/ ProtocolVersion version = { 3, 4 }; /* TLS v1.3*/
enum { enum {
change_cipher_spec(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), (255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion version; ProtocolVersion version;
uint16 length; uint16 length;
opaque nonce_explicit[SecurityParameters.record_iv_length]; opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct { aead-ciphered struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
} fragment; } fragment;
} TLSCiphertext; } TLSCiphertext;
A.2. Change Cipher Specs Message A.2. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel;
struct { enum {
enum { change_cipher_spec(1), (255) } type; close_notify(0),
} ChangeCipherSpec; unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure_RESERVED(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
(255)
} AlertDescription;
A.3. Alert Messages struct {
enum { warning(1), fatal(2), (255) } AlertLevel; AlertLevel level;
AlertDescription description;
} Alert;
enum { A.3. Handshake Protocol
close_notify(0), enum {
unexpected_message(10), reserved(0), client_hello(1), server_hello(2),
bad_record_mac(20), client_key_share(5), hello_retry_request(6),
decryption_failed_RESERVED(21), server_key_share(7), certificate(11), reserved(12),
record_overflow(22), certificate_request(13), certificate_verify(15),
decompression_failure_RESERVED(30), reserved(16), finished(20), (255)
handshake_failure(40), } HandshakeType;
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
(255)
} AlertDescription;
struct { struct {
AlertLevel level; HandshakeType msg_type; /* handshake type */
AlertDescription description; uint24 length; /* bytes in message */
} Alert; select (HandshakeType) {
case client_hello: ClientHello;
case client_key_share: ClientKeyShare;
case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest;
case server_key_share: ServerKeyShare;
case certificate: Certificate;
case certificate_request: CertificateRequest;
case certificate_verify: CertificateVerify;
case finished: Finished;
} body;
} Handshake;
A.4. Handshake Protocol A.3.1. Hello Messages
enum {
reserved(0), client_hello(1), server_hello(2),
client_key_share(5), hello_retry_request(6),
server_key_share(7), certificate(11), reserved(12),
certificate_request(13), certificate_verify(15),
reserved(16), finished(20), (255)
} HandshakeType;
struct { opaque SessionID<0..32>;
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest;
case certificate: Certificate;
case server_key_share: ServerKeyShare;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_share: ClientKeyShare;
case finished: Finished;
} body;
} Handshake;
A.4.1. Hello Messages uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct { } HelloRequest; enum { null(0), (255) } CompressionMethod;
struct { struct {
opaque random_bytes[32]; ProtocolVersion client_version;
} Random; Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
opaque SessionID<0..32>; struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
uint8 CipherSuite[2]; struct {
ProtocolVersion server_version;
CipherSuite cipher_suite;
NamedGroup selected_group;
Extension extensions<0..2^16-1>;
} HelloRetryRequest;
enum { null(0), (255) } CompressionMethod; struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct { enum {
ProtocolVersion client_version; signature_algorithms(13), early_data(TBD), (65535)
Random random; } ExtensionType;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {}; struct {
case true: TLSCipherText messages<5 .. 2^24-1>;
Extension extensions<0..2^16-1>; } EarlyDataExtension;
};
} ClientHello;
struct { struct {
ProtocolVersion server_version; Extension extensions<0..2^16-1>;
Random random; } EncryptedExtensions;
SessionID session_id;
CipherSuite cipher_suite;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
struct { A.3.1.1. Signature Algorithm Extension
ExtensionType extension_type; enum {
opaque extension_data<0..2^16-1>; none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
} Extension; sha512(6), (255)
} HashAlgorithm;
enum { enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
signature_algorithms(13), (65535) SignatureAlgorithm;
} ExtensionType;
enum{ struct {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), HashAlgorithm hash;
sha512(6), (255) SignatureAlgorithm signature;
} HashAlgorithm; } SignatureAndHashAlgorithm;
enum {
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
} SignatureAlgorithm;
struct { SignatureAndHashAlgorithm
HashAlgorithm hash; supported_signature_algorithms<2..2^16-2>;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm A.3.1.2. Named Group Extension
supported_signature_algorithms<2..2^16-2>;
A.4.2. Server Authentication and Key Exchange Messages enum {
// Elliptic Curve Groups.
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
opaque ASN1Cert<2^24-1>; // Finite Field Groups.
ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
ffdhe8192(259),
struct { // Reserved Code Points.
ASN1Cert certificate_list<0..2^24-1>; reserved (0xFE00..0xFEFF),
} Certificate; reserved(0xFF01),
reserved(0xFF02),
(0xFFFF)
} NamedGroup;
struct { struct {
NamedGroup group; NamedGroup named_group_list<1..2^16-1>
opaque key_exchange<1..2^16-1>; } NamedGroupList;
} ServerKeyShare;
enum { A.3.2. Key Exchange Messages
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer;
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientKeyShareOffer offers<0..2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>; } ClientKeyShare;
} CertificateRequest;
struct { } ServerHelloDone; opaque dh_Y<1..2^16-1>;
A.4.3. Client Authentication and Key Exchange Messages opaque point <1..2^8-1>;
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; NamedGroup group;
} ClientKeyShare; opaque key_exchange<1..2^16-1>;
} ServerKeyShare;
struct { A.3.3. Authentication Messages
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer;
struct { opaque ASN1Cert<1..2^24-1>;
digitally-signed struct {
opaque handshake_messages_hash[hash_length];
}
} CertificateVerify;
The context string for the signature is "TLS 1.3, client struct {
CertificateVerify". ASN1Cert certificate_list<0..2^24-1>;
} Certificate;
A.4.4. Handshake Finalization Message enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), (255)
} ClientCertificateType;
struct { opaque DistinguishedName<1..2^16-1>;
opaque verify_data[verify_data_length];
} Finished;
A.5. The Cipher Suite struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct {
digitally-signed struct {
opaque handshake_messages_hash[hash_length];
}
} CertificateVerify;
A.3.4. Handshake Finalization Messages
struct {
opaque verify_data[verify_data_length];
} Finished;
A.4. The Cipher Suite
The following values define the cipher suite codes used in the The following values define the cipher suite codes used in the
ClientHello and ServerHello messages. ClientHello and ServerHello messages.
A cipher suite defines a cipher specification supported in TLS A cipher suite defines a cipher specification supported in TLS
Version 1.2. Version 1.2.
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST TLS connection during the first handshake on that channel, but MUST
NOT be negotiated, as it provides no more protection than an NOT be negotiated, as it provides no more protection than an
skipping to change at page 74, line 35 skipping to change at page 75, line 35
The following cipher suite definitions, defined in {{RFC5288}, are The following cipher suite definitions, defined in {{RFC5288}, are
used for server-authenticated (and optionally client-authenticated) used for server-authenticated (and optionally client-authenticated)
Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the
Diffie-Hellman parameters are signed by a signature-capable Diffie-Hellman parameters are signed by a signature-capable
certificate, which has been signed by the CA. The signing algorithm certificate, which has been signed by the CA. The signing algorithm
used by the server is specified after the DHE component of the used by the server is specified after the DHE component of the
CipherSuite name. The server can request any signature-capable CipherSuite name. The server can request any signature-capable
certificate from the client for client authentication. certificate from the client for client authentication.
CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9C}
CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9D}
CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E} CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}
CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F} CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}
CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2} CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}
CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3} CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}
The following cipher suite definitions, defined in {{RFC5289}, are The following cipher suite definitions, defined in {{RFC5289}, are
used for server-authenticated (and optionally client-authenticated) used for server-authenticated (and optionally client-authenticated)
Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie- Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie-
Hellman, where the Diffie-Hellman parameters are signed by a Hellman, where the Diffie-Hellman parameters are signed by a
signature-capable certificate, which has been signed by the CA. The signature-capable certificate, which has been signed by the CA. The
skipping to change at page 76, line 5 skipping to change at page 77, line 5
o For cipher suites ending with _SHA384, the PRF is the TLS PRF with o For cipher suites ending with _SHA384, the PRF is the TLS PRF with
SHA-384 as the hash function. SHA-384 as the hash function.
New cipher suite values are been assigned by IANA as described in New cipher suite values are been assigned by IANA as described in
Section 12. Section 12.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL reserved to avoid collision with Fortezza-based cipher suites in SSL
3. 3.
A.6. The Security Parameters A.5. The Security Parameters
These security parameters are determined by the TLS Handshake These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS record layer in order Protocol and provided as parameters to the TLS record layer in order
to initialize a connection state. SecurityParameters includes: to initialize a connection state. SecurityParameters includes:
enum { null(0), (255) } CompressionMethod; enum { server, client } ConnectionEnd;
enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm; enum { tls_prf_sha256 } PRFAlgorithm;
enum { aes_gcm } RecordProtAlgorithm; enum { aes_gcm } RecordProtAlgorithm;
/* Other values may be added to the algorithms specified in /* The algorithms specified in PRFAlgorithm and
PRFAlgorithm and RecordProtAlgorithm */ RecordProtAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; PRFAlgorithm prf_algorithm;
RecordProtAlgorithm record_prot_algorithm; RecordProtAlgorithm record_prot_algorithm;
uint8 enc_key_length; uint8 enc_key_length;
uint8 block_length; uint8 block_length;
uint8 fixed_iv_length; uint8 fixed_iv_length;
uint8 record_iv_length; uint8 record_iv_length;
opaque master_secret[48]; opaque hs_master_secret[48];
opaque client_random[32]; opaque master_secret[48];
opaque server_random[32]; opaque client_random[32];
} SecurityParameters; opaque server_random[32];
} SecurityParameters;
A.7. Changes to RFC 4492 A.6. Changes to RFC 4492
RFC 4492 [RFC4492] adds Elliptic Curve cipher suites to TLS. This RFC 4492 [RFC4492] adds Elliptic Curve cipher suites to TLS. This
document changes some of the structures used in that document. This document changes some of the structures used in that document. This
section details the required changes for implementors of both RFC section details the required changes for implementors of both RFC
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
RFC 4492 do not need to read this section. RFC 4492 do not need to read this section.
This document adds a "signature_algorithm" field to the digitally- This document adds a "signature_algorithm" field to the digitally-
signed element in order to identify the signature and digest signed element in order to identify the signature and digest
algorithms used to create a signature. This change applies to algorithms used to create a signature. This change applies to
skipping to change at page 82, line 37 skipping to change at page 83, line 37
- Does your TLS client check that the Diffie-Hellman parameters sent - Does your TLS client check that the Diffie-Hellman parameters sent
by the server are acceptable (see Appendix F.1.1.2)? by the server are acceptable (see Appendix F.1.1.2)?
- Do you use a strong and, most importantly, properly seeded random - Do you use a strong and, most importantly, properly seeded random
number generator (see Appendix D.1) Diffie-Hellman private values, number generator (see Appendix D.1) Diffie-Hellman private values,
the DSA "k" parameter, and other security-critical values? the DSA "k" parameter, and other security-critical values?
Appendix E. Backward Compatibility Appendix E. Backward Compatibility
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 E.1. Compatibility with prior versions
[[TODO: Revise backward compatibility section for TLS 1.3. [[TODO: Revise backward compatibility section for TLS 1.3.
https://github.com/tlswg/tls13-spec/issues/54]] Since there are https://github.com/tlswg/tls13-spec/issues/54]] Since there are
various versions of TLS (1.0, 1.1, 1.2, and any future versions) and various versions of TLS (1.0, 1.1, 1.2, 1.3, and any future versions)
SSL (2.0 and 3.0), means are needed to negotiate the specific and SSL (2.0 and 3.0), means are needed to negotiate the specific
protocol version to use. The TLS protocol provides a built-in protocol version to use. The TLS protocol provides a built-in
mechanism for version negotiation so as not to bother other protocol mechanism for version negotiation so as not to bother other protocol
components with the complexities of version selection. components with the complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol remains compatible, and the client supports the highest protocol
version available in the server. version available in the server.
skipping to change at page 84, line 8 skipping to change at page 85, line 8
compliant with this specification MUST accept any value {03,XX} as compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello. the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client, would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will and the value of ClientHello.client_version. No single value will
guarantee interoperability with all old servers, but this is a guarantee interoperability with all old servers, but this is a
complex topic beyond the scope of this document. complex topic beyond the scope of this document.
E.2. Compatibility with SSL 2.0 E.2. Compatibility with SSL
TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message
MUST contain the same version number as would be used for ordinary
ClientHello, and MUST encode the supported TLS cipher suites in the
CIPHER-SPECS-DATA field as described below.
Warning: The ability to send version 2.0 CLIENT-HELLO messages will
be phased out with all due haste, since the newer ClientHello format
provides better mechanisms for moving to newer versions and
negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
However, even TLS servers that do not support SSL 2.0 MAY accept
version 2.0 CLIENT-HELLO messages. The message is presented below in
sufficient detail for TLS server implementors; the true definition is
still assumed to be [SSL2].
For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
way as a ClientHello with a "null" compression method and no
extensions. Note that this message MUST be sent directly on the
wire, not wrapped as a TLS record. For the purposes of calculating
Finished and CertificateVerify, the msg_length field is not
considered to be a part of the handshake message.
uint8 V2CipherSpec[3];
struct {
uint16 msg_length;
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello;
msg_length
The highest bit MUST be 1; the remaining bits contain the length
of the following data in bytes.
msg_type
This field, in conjunction with the version field, identifies a
version 2 ClientHello message. The value MUST be 1.
version
Equal to ClientHello.client_version.
cipher_spec_length
This field is the total length of the field cipher_specs. It
cannot be zero and MUST be a multiple of the V2CipherSpec length
(3).
session_id_length
This field MUST have a value of zero for a client that claims to
support TLS 1.2.
challenge_length
The length in bytes of the client's challenge to the server to
authenticate itself. Historically, permissible values are between
16 and 32 bytes inclusive. When using the SSLv2 backward-
compatible handshake the client SHOULD use a 32-byte challenge.
cipher_specs
This is a list of all CipherSpecs the client is willing and able
to use. In addition to the 2.0 cipher specs defined in [SSL2],
this includes the TLS cipher suites normally sent in
ClientHello.cipher_suites, with each cipher suite prefixed by a
zero byte. For example, the TLS cipher suite {0x00,0x0A} would be
sent as {0x00,0x00,0x0A}.
session_id
This field MUST be empty.
challenge
Corresponds to ClientHello.random. If the challenge length is
less than 32, the TLS server will pad the data with leading (note:
not trailing) zero bytes to make it 32 bytes long.
Note: Requests to resume a TLS session MUST use a TLS client hello. The security of SSL 2.0 [SSL2] is considered insufficient for the
reasons enumerated in [RFC6176], and MUST NOT be negotiated for any
reason.
E.3. Avoiding Man-in-the-Middle Version Rollback Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
order to negotiate older versions of TLS.
When TLS clients fall back to Version 2.0 compatibility mode, they Implementations MUST NOT send or accept any records with a version
MUST use special PKCS#1 block formatting. This is done so that TLS less than { 3, 0 }.
servers will reject Version 2.0 sessions with TLS-capable clients.
When a client negotiates SSL 2.0 but also supports TLS, it MUST set The security of SSL 3.0 [SSL3] is considered insufficient for the
the right-hand (least-significant) 8 random bytes of the PKCS padding reasons enumerated in [I-D.ietf-tls-sslv3-diediedie], and MUST NOT be
(not including the terminal null of the padding) for the RSA negotiated for any reason.
encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
to 0x03 (the other padding bytes are random).
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after Implementations MUST NOT send a ClientHello.version or
decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding ServerHello.version set to { 3, 0 } or less. Any endpoint receiving
bytes are 0x03. If they are not, the server SHOULD generate a random a Hello message with ClientHello.version or ServerHello.version set
value for SECRET-KEY-DATA, and continue the handshake (which will to { 3, 0 } MUST respond with a "protocol_version" alert message and
eventually fail since the keys will not match). Note that reporting close the connection.
the error situation to the client could make the server vulnerable to
attacks described in [BLEI].
Appendix F. Security Analysis Appendix F. Security Analysis
The TLS protocol is designed to establish a secure connection between The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel. otherwise tamper with messages sent over the communication channel.
skipping to change at page 90, line 45 skipping to change at page 90, line 19
canetti@watson.ibm.com canetti@watson.ibm.com
Pete Chown Pete Chown
Skygate Technology Ltd Skygate Technology Ltd
pc@skygate.co.uk pc@skygate.co.uk
Antoine Delignat-Lavaud (co-author of [I-D.ietf-tls-session-hash]) Antoine Delignat-Lavaud (co-author of [I-D.ietf-tls-session-hash])
INRIA INRIA
antoine.delignat-lavaud@inria.fr antoine.delignat-lavaud@inria.fr
Tim Dierks (co-editor of TLS 1.0, 1.1, and 1.2)
Independent
tim@dierks.org
Taher Elgamal Taher Elgamal
taher@securify.com taher@securify.com
Securify Securify
Pasi Eronen Pasi Eronen
pasi.eronen@nokia.com pasi.eronen@nokia.com
Nokia Nokia
Anil Gangolli Anil Gangolli
anil@busybuddha.org anil@busybuddha.org
Vipul Gupta (co-author of RFC4492) Vipul Gupta (co-author of RFC4492)
Sun Microsystems Laboratories Sun Microsystems Laboratories
vipul.gupta@sun.com vipul.gupta@sun.com
Kipp Hickman Kipp Hickman
Chris Hawk (co-author of RFC4492) Chris Hawk (co-author of RFC4492)
skipping to change at page 92, line 40 skipping to change at page 92, line 17
Martin Thomson Martin Thomson
Mozilla Mozilla
mt@mozilla.com mt@mozilla.com
Tom Weinstein Tom Weinstein
Tim Wright Tim Wright
Vodafone Vodafone
timothy.wright@vodafone.com timothy.wright@vodafone.com
Authors' Addresses Author's Address
Tim Dierks
Independent
EMail: tim@dierks.org
Eric Rescorla Eric Rescorla
RTFM, Inc. RTFM, Inc.
EMail: ekr@rtfm.com EMail: ekr@rtfm.com
 End of changes. 99 change blocks. 
406 lines changed or deleted 365 lines changed or added

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