draft-ietf-tls-tls13-03.txt   draft-ietf-tls-tls13-04.txt 
Network Working Group T. Dierks Network Working Group T. Dierks
Internet-Draft Independent Internet-Draft Independent
Obsoletes: 3268, 4346, 4366, 5246 (if E. Rescorla Obsoletes: 3268, 4346, 4366, 5246 (if E. Rescorla
approved) RTFM, Inc. approved) RTFM, Inc.
Updates: 4492 (if approved) October 27, 2014 Updates: 4492 (if approved) January 03, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: April 30, 2015 Expires: July 7, 2015
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-03 draft-ietf-tls-tls13-04
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 April 30, 2015. This Internet-Draft will expire on July 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Terminology . . . . . . . . . . . . . . . . 5 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 5
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 5
1.3. Major Differences from TLS 1.1 . . . . . . . . . . . . . 6 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 8 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 7
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 8 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 7
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 8 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 10
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 11 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 10
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12
4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 13
4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14 4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 14
5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 15 5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 14
6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16 6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 15
6.1. Connection States . . . . . . . . . . . . . . . . . . . . 17 6.1. Connection States . . . . . . . . . . . . . . . . . . . . 16
6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19 6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 18
6.2.2. Record Payload Protection . . . . . . . . . . . . . . 20 6.2.2. Record Payload Protection . . . . . . . . . . . . . . 19
6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 22 6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 21
7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23 7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 22
7.1. Change Cipher Spec Protocol . . . . . . . . . . . . . . . 24 7.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23
7.2. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 24 7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 24
7.2.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25 7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25
7.2.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 26 7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 28
7.3. Handshake Protocol Overview . . . . . . . . . . . . . . . 30 7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 33
7.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 34 7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 34
7.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 35 7.3.2. Client Key Share Message . . . . . . . . . . . . . . 37
7.4.2. Client Key Share Message . . . . . . . . . . . . . . 39 7.3.3. Server Key Share Message . . . . . . . . . . . . . . 48
7.4.3. Server Key Share Message . . . . . . . . . . . . . . 52 7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 49
7.4.4. Encrypted Extensions . . . . . . . . . . . . . . . . 52 7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 49
7.4.5. Server Certificate . . . . . . . . . . . . . . . . . 53 7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 52
7.4.6. Certificate Request . . . . . . . . . . . . . . . . . 55 7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 53
7.4.7. Server Certificate Verify . . . . . . . . . . . . . . 57 7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 55
7.4.8. Server Finished . . . . . . . . . . . . . . . . . . . 58 7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 56
7.4.9. Client Certificate . . . . . . . . . . . . . . . . . 60 7.3.10. Client Certificate Verify . . . . . . . . . . . . . . 58
7.4.10. Client Certificate Verify . . . . . . . . . . . . . . 61 8. Cryptographic Computations . . . . . . . . . . . . . . . . . 58
8. Cryptographic Computations . . . . . . . . . . . . . . . . . 62 8.1. Computing the Master Secret . . . . . . . . . . . . . . . 59
8.1. Computing the Master Secret . . . . . . . . . . . . . . . 62 8.1.1. The Session Hash . . . . . . . . . . . . . . . . . . 60
8.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 63 8.1.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 61
8.1.2. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 63 8.1.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 61
9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 63 9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 61
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 63 10. Application Data Protocol . . . . . . . . . . . . . . . . . . 61
11. Security Considerations . . . . . . . . . . . . . . . . . . . 63 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.1. Normative References . . . . . . . . . . . . . . . . . . 65 13.1. Normative References . . . . . . . . . . . . . . . . . . 63
13.2. Informative References . . . . . . . . . . . . . . . . . 66 13.2. Informative References . . . . . . . . . . . . . . . . . 65
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 69 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Appendix A. Protocol Data Structures and Constant Values . . . . 70 Appendix A. Protocol Data Structures and Constant Values . . . . 69
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 70 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Change Cipher Specs Message . . . . . . . . . . . . . . . 70 A.2. Change Cipher Specs Message . . . . . . . . . . . . . . . 69
A.3. Alert Messages . . . . . . . . . . . . . . . . . . . . . 70 A.3. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69
A.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 71 A.4. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70
A.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 72 A.4.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71
A.4.2. Server Authentication and Key Exchange Messages . . . 74 A.4.2. Server Authentication and Key Exchange Messages . . . 73
A.4.3. Client Authentication and Key Exchange Messages . . . 74 A.4.3. Client Authentication and Key Exchange Messages . . . 73
A.4.4. Handshake Finalization Message . . . . . . . . . . . 75 A.4.4. Handshake Finalization Message . . . . . . . . . . . 74
A.5. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 75 A.5. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 74
A.6. The Security Parameters . . . . . . . . . . . . . . . . . 77 A.6. The Security Parameters . . . . . . . . . . . . . . . . . 76
A.7. 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 TLS 1.0/1.1 and SSL 3.0 . . . . . . . 83 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 . . . . . . . 82
E.2. Compatibility with SSL 2.0 . . . . . . . . . . . . . . . 85 E.2. Compatibility with SSL 2.0 . . . . . . . . . . . . . . . 84
E.3. Avoiding Man-in-the-Middle Version Rollback . . . . . . . 87 E.3. Avoiding Man-in-the-Middle Version Rollback . . . . . . . 85
Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 87 Appendix F. Security Analysis . . . . . . . . . . . . . . . . . 86
F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 87 F.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 86
F.1.1. Authentication and Key Exchange . . . . . . . . . . . 87 F.1.1. Authentication and Key Exchange . . . . . . . . . . . 86
F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 89 F.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 87
F.1.3. Detecting Attacks Against the Handshake Protocol . . 89 F.1.3. Detecting Attacks Against the Handshake Protocol . . 88
F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 89 F.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 88
F.2. Protecting Application Data . . . . . . . . . . . . . . . 90 F.2. Protecting Application Data . . . . . . . . . . . . . . . 88
F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 90 F.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 89
F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 90 F.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 89
Appendix G. Working Group Information . . . . . . . . . . . . . 91 Appendix G. Working Group Information . . . . . . . . . . . . . 89
Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 91 Appendix H. Contributors . . . . . . . . . . . . . . . . . . . . 90
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 38 skipping to change at page 5, line 37
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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-03 draft-04
- Modify key computations to include session hash.
- Remove ChangeCipherSpec
- Renumber the new handshake messages to be somewhat more consistent
with existing convention and to remove a duplicate registration.
- Remove renegotiation.
- Update format of signatures with context.
- Remove point format negotiation.
- 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
- Add an explicit HelloRetryRequest to reject the client's - Add an explicit HelloRetryRequest to reject the client's
draft-02
- Increment version number. - Increment version number.
- Reworked handshake to provide 1-RTT mode. - Reworked handshake to provide 1-RTT mode.
- Remove custom DHE groups. - Remove custom DHE groups.
- Removed support for compression. - Removed support for compression.
- Removed support for static RSA and DH key exchange. - Removed support for static RSA and DH key exchange.
- Removed support for non-AEAD ciphers - Removed support for non-AEAD ciphers
1.3. Major Differences from TLS 1.1
This document is a revision of the TLS 1.1 [RFC4346] protocol which
contains improved flexibility, particularly for negotiation of
cryptographic algorithms. The major changes are:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) has
been replaced with cipher-suite-specified PRFs. All cipher suites
in this document use P_SHA256.
- The MD5/SHA-1 combination in the digitally-signed element has been
replaced with a single hash. Signed elements now include a field
that explicitly specifies the hash algorithm used.
- Substantial cleanup to the client's and server's ability to
specify which hash and signature algorithms they will accept.
Note that this also relaxes some of the constraints on signature
and hash algorithms from previous versions of TLS.
- Addition of support for authenticated encryption with additional
data modes.
- TLS Extensions definition and AES Cipher Suites were merged in
from external [TLSEXT] and [RFC3268].
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Tightened up a number of requirements.
- Verify_data length now depends on the cipher suite (default is
still 12).
- Cleaned up description of Bleichenbacher/Klima attack defenses.
- Alerts MUST now be sent in many cases.
- After a certificate_request, if no certificates are available,
clients now MUST send an empty certificate list.
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
cipher suite.
- Added HMAC-SHA256 cipher suites.
- Removed IDEA and DES cipher suites. They are now deprecated and
will be documented in a separate document.
- Support for the SSLv2 backward-compatible hello is now a MAY, not
a SHOULD, with sending it a SHOULD NOT. Support will probably
become a SHOULD NOT in the future.
- Added limited "fall-through" to the presentation language to allow
multiple case arms to have the same encoding.
- Added an Implementation Pitfalls sections
- The usual clarifications and editorial work.
2. Goals 2. Goals
The goals of the TLS protocol, in order of priority, are as follows: The goals of the TLS protocol, in order of priority, are as follows:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange develop applications utilizing TLS that can successfully exchange
cryptographic parameters without knowledge of one another's code. cryptographic parameters without knowledge of one another's code.
skipping to change at page 13, line 23 skipping to change at page 12, line 23
state (see Section 6.1). state (see Section 6.1).
A digitally-signed element is encoded as a struct DigitallySigned: A digitally-signed element is encoded as a struct DigitallySigned:
struct { struct {
SignatureAndHashAlgorithm algorithm; SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>; opaque signature<0..2^16-1>;
} DigitallySigned; } DigitallySigned;
The algorithm field specifies the algorithm used (see The algorithm field specifies the algorithm used (see
Section 7.4.2.5.1 for the definition of this field). Note that the Section 7.3.2.5.1 for the definition of this field). Note that the
algorithm field was introduced in TLS 1.2, and is not in earlier algorithm field was introduced in TLS 1.2, and is not in earlier
versions. The signature is a digital signature using those versions. The signature is a digital signature using those
algorithms over the contents of the element. The contents themselves algorithms over the contents of the element. The contents themselves
do not appear on the wire but are simply calculated. The length of do not appear on the wire but are simply calculated. The length of
the signature is specified by the signing algorithm and key. the signature is specified by the signing algorithm and key.
In previous versions of TLS, the ServerKeyExchange format meant that
attackers can obtain a signature of a message with a chosen, 32-byte
prefix. Because TLS 1.3 servers are likely to also implement prior
versions, the contents of the element always start with 64 bytes of
octet 32 in order to clear that chosen-prefix.
Following that padding is a NUL-terminated context string in order to
disambiguate signatures for different purposes. The context string
will be specified whenever a digitally-signed element is used.
Finally, the specified contents of the digitally-signed structure
follow the NUL at the end of the context string. (See the example at
the end of this section.)
In RSA signing, the opaque vector contains the signature generated In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC3447]. using the RSASSA-PKCS1-v1_5 signature scheme defined in [RFC3447].
As discussed in [RFC3447], the DigestInfo MUST be DER-encoded [X680] As discussed in [RFC3447], the DigestInfo MUST be DER-encoded [X680]
[X690]. For hash algorithms without parameters (which includes SHA- [X690]. For hash algorithms without parameters (which includes SHA-
1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL, 1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL,
but implementations MUST accept both without parameters and with NULL but implementations MUST accept both without parameters and with NULL
parameters. Note that earlier versions of TLS used a different RSA parameters. Note that earlier versions of TLS used a different RSA
signature scheme that did not include a DigestInfo encoding. signature scheme that did not include a DigestInfo encoding.
In DSA, the 20 bytes of the SHA-1 hash are run directly through the In DSA, the 20 bytes of the SHA-1 hash are run directly through the
skipping to change at page 14, line 38 skipping to change at page 14, line 5
struct { struct {
uint8 field1; uint8 field1;
uint8 field2; uint8 field2;
digitally-signed opaque { digitally-signed opaque {
uint8 field3<0..255>; uint8 field3<0..255>;
uint8 field4; uint8 field4;
}; };
} UserType; } UserType;
The contents of the inner struct (field3 and field4) are used as Assume that the context string for the signature was specified as
input for the signature/hash algorithm. The length of the structure, "Example". The input for the signature/hash algorithm would be:
in bytes, would be equal to two bytes for field1 and field2, plus two
bytes for the signature and hash algorithm, plus two bytes for the 2020202020202020202020202020202020202020202020202020202020202020
length of the signature, plus the length of the output of the signing 2020202020202020202020202020202020202020202020202020202020202020
algorithm. The length of the signature is known because the 4578616d706c6500
algorithm and key used for the signing are known prior to encoding or
decoding this structure. followed by the encoding of the inner struct (field3 and field4).
The length of the structure, in bytes, would be equal to two bytes
for field1 and field2, plus two bytes for the signature and hash
algorithm, plus two bytes for the length of the signature, plus the
length of the output of the signing algorithm. The length of the
signature is known because the algorithm and key used for the signing
are known prior to encoding or decoding this structure.
4.8. Constants 4.8. Constants
Typed constants can be defined for purposes of specification by Typed constants can be defined for purposes of specification by
declaring a symbol of the desired type and assigning values to it. declaring a symbol of the desired type and assigning values to it.
Under-specified types (opaque, variable-length vectors, and Under-specified types (opaque, variable-length vectors, and
structures that contain opaque) cannot be assigned values. No fields structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided. of a multi-element structure or vector may be elided.
skipping to change at page 17, line 10 skipping to change at page 16, line 28
Note in particular that type and length of a record are not protected Note in particular that type and length of a record are not protected
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. Logically, connection in both the read and the write directions. The security
there are always four connection states outstanding: the current read parameters are be set by the TLS Handshake Protocol, which also
and write states, and the pending read and write states. All records determines when new cryptographic keys are installed and used for
are processed under the current read and write states. The security record protection. The initial current state always specifies that
parameters for the pending states can be set by the TLS Handshake
Protocol, and the ChangeCipherSpec can selectively make either of the
pending states current, in which case the appropriate current state
is disposed of and replaced with the pending state; the pending state
is then reinitialized to an empty state. It is illegal to make a
state that has not been initialized with security parameters a
current state. 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.
PRF algorithm PRF algorithm
skipping to change at page 17, line 44 skipping to change at page 17, line 7
record protection algorithm record protection algorithm
The algorithm to be used for record protection. This algorithm The algorithm to be used for record protection. This algorithm
must be of the AEAD type and thus provides integrity and must be of the AEAD type and thus provides integrity and
confidentiality as a single primitive. It is possible to have confidentiality as a single primitive. It is possible to have
AEAD algorithms which do not provide any confidentiality and AEAD algorithms which do not provide any confidentiality and
Section 6.2.2 defines a special NULL_NULL AEAD algorithm for use Section 6.2.2 defines a special NULL_NULL AEAD algorithm for use
in the initial handshake). This specification includes the key in the initial handshake). This specification includes the key
size of this algorithm and the lengths of explicit and implicit size of this algorithm and the lengths of explicit and implicit
initialization vectors (or nonces). initialization vectors (or nonces).
handshake master secret
A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting the handshake.
master secret master secret
A 48-byte secret shared between the two peers in the connection. A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting application data.
client random client random
A 32-byte value provided by the client. A 32-byte value provided by the client.
server random server random
A 32-byte value provided by the server. A 32-byte value provided by the server.
These parameters are defined in the presentation language as: These parameters are defined in the presentation language as:
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
skipping to change at page 18, line 24 skipping to change at page 17, line 40
RecordProtAlgorithm may be added to. */ 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 hs_master_secret[48];
opaque master_secret[48]; opaque master_secret[48];
opaque client_random[32]; opaque client_random[32];
opaque server_random[32]; opaque server_random[32];
} SecurityParameters; } SecurityParameters;
The record layer will use the security parameters to generate the The record layer will use the security parameters to generate the
following four items (some of which are not required by all ciphers, following four items (some of which are not required by all ciphers,
and are thus empty): and are thus empty):
client write key client write key
skipping to change at page 19, line 10 skipping to change at page 18, line 31
The current state of the encryption algorithm. This will consist The current state of the encryption algorithm. This will consist
of the scheduled key for that connection. of the scheduled key for that connection.
sequence number sequence number
Each connection state contains a sequence number, which is Each connection state contains a sequence number, which is
maintained separately for read and write states. The sequence maintained separately for read and write states. The sequence
number MUST be set to zero whenever a connection state is made the number MUST be set to zero whenever a connection state is made the
active state. Sequence numbers are of type uint64 and may not active state. Sequence numbers are of type uint64 and may not
exceed 2^64-1. Sequence numbers do not wrap. If a TLS exceed 2^64-1. Sequence numbers do not wrap. If a TLS
implementation would need to wrap a sequence number, it must implementation would need to wrap a sequence number, it must
renegotiate instead. A sequence number is incremented after each terminate the connection. A sequence number is incremented after
record: specifically, the first record transmitted under a each record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0. particular connection state MUST use sequence number 0.
6.2. Record Layer 6.2. Record Layer
The TLS record layer receives uninterpreted data from higher layers The TLS record layer receives uninterpreted data from higher layers
in non-empty blocks of arbitrary size. in non-empty blocks of arbitrary size.
6.2.1. Fragmentation 6.2.1. Fragmentation
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
skipping to change at page 19, line 34 skipping to change at page 19, line 11
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;
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;
skipping to change at page 20, line 19 skipping to change at page 19, line 44
length length
The length (in bytes) of the following TLSPlaintext.fragment. The The length (in bytes) of the following TLSPlaintext.fragment. The
length MUST NOT exceed 2^14. length MUST NOT exceed 2^14.
fragment fragment
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol independent block to be dealt with by the higher-level protocol
specified by the type field. specified by the type field.
Implementations MUST NOT send zero-length fragments of Handshake, Implementations MUST NOT send zero-length fragments of Handshake or
Alert, or ChangeCipherSpec content types. Zero-length fragments of Alert types. Zero-length fragments of Application data MAY be sent
Application data MAY be sent as they are potentially useful as a as they are potentially useful as a traffic analysis countermeasure.
traffic analysis countermeasure.
Note: Data of different TLS record layer content types MAY be
interleaved. Application data is generally of lower precedence for
transmission than other content types. However, records MUST be
delivered to the network in the same order as they are protected by
the record layer. Recipients MUST receive and process interleaved
application layer traffic during handshakes subsequent to the first
one on a connection.
6.2.2. Record Payload Protection 6.2.2. Record Payload Protection
The record protection functions translate a TLSPlaintext structure The record protection functions translate a TLSPlaintext structure
into a TLSCiphertext. The deprotection functions reverse the into a TLSCiphertext. The deprotection functions reverse the
process. In TLS 1.3 as opposed to previous versions of TLS, all process. In TLS 1.3 as opposed to previous versions of TLS, all
ciphers are modelled as "Authenticated Encryption with Additional ciphers are modelled as "Authenticated Encryption with Additional
Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption
and authentication operation which turns plaintext into authenticated and authentication operation which turns plaintext into authenticated
ciphertext and back again. ciphertext and back again.
skipping to change at page 22, line 50 skipping to change at page 22, line 13
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.6) 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 master secret is used as an entropy When keys are generated, the then current master secret (MS) is used
source. as an entropy source. For handshake records, this means the
hs_master_secret. For application data records, this means the
regular master_secret.
To generate the key material, compute To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret, key_block = PRF(MS,
"key expansion", "key expansion",
SecurityParameters.server_random + SecurityParameters.server_random +
SecurityParameters.client_random); SecurityParameters.client_random);
until enough output has been generated. Then, the key_block is where MS is the relevant master secret. The PRF is computed enough
partitioned as follows: times to generate the necessary amount of data for the key_block,
which is then partitioned as follows:
client_write_key[SecurityParameters.enc_key_length] client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length] server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length] client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length] server_write_IV[SecurityParameters.fixed_iv_length]
Currently, the client_write_IV and server_write_IV are only generated Currently, the client_write_IV and server_write_IV are only generated
for implicit nonce techniques as described in Section 3.2.1 of for implicit nonce techniques as described in Section 3.2.1 of
[RFC5116]. [RFC5116].
skipping to change at page 23, line 48 skipping to change at page 23, line 15
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.6 for formal
definition.) definition.)
master 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
the record layer when protecting application data. Many connections the record layer when protecting application data. Many connections
can be instantiated using the same session through the resumption can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol. feature of the TLS Handshake Protocol.
7.1. Change Cipher Spec Protocol 7.1. Alert Protocol
The change cipher spec protocol exists to signal transitions in
ciphering strategies. The protocol consists of a single message,
which is encrypted under the current (not the pending) connection
state. The message consists of a single byte of value 1.
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
The ChangeCipherSpec message is sent by both the client and the
server to notify the receiving party that subsequent records will be
protected under the newly negotiated CipherSpec and keys. Reception
of this message causes the receiver to instruct the record layer to
immediately copy the read pending state into the read current state.
Immediately after sending this message, the sender MUST instruct the
record layer to make the write pending state the write current state.
(See Section 6.1.) The ChangeCipherSpec message is sent during the
handshake after the security parameters have been agreed upon, but
before the first message protected with a new CipherSpec is sent.
Note: If a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the old
CipherSpec. However, once the ChangeCipherSpec has been sent, the
new CipherSpec MUST be used. The first side to send the
ChangeCipherSpec does not know that the other side has finished
computing the new keying material (e.g., if it has to perform a time-
consuming public key operation). Thus, a small window of time,
during which the recipient must buffer the data, MAY exist. In
practice, with modern machines this interval is likely to be fairly
short. [[TODO: This text seems confusing.]]
7.2. Alert Protocol
One of the content types supported by the TLS record layer is the One of the content types supported by the TLS record layer is the
alert type. Alert messages convey the severity of the message alert type. Alert messages convey the severity of the message
(warning or fatal) and a description of the alert. Alert messages (warning or fatal) and a description of the alert. Alert messages
with a level of fatal result in the immediate termination of the with a level of fatal result in the immediate termination of the
connection. In this case, other connections corresponding to the connection. In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated, session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new preventing the failed session from being used to establish new
connections. Like other messages, alert messages are encrypted as connections. Like other messages, alert messages are encrypted as
specified by the current connection state. specified by the current connection state.
skipping to change at page 25, line 45 skipping to change at page 24, line 41
no_renegotiation(100), no_renegotiation(100),
unsupported_extension(110), unsupported_extension(110),
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
7.2.1. Closure Alerts 7.1.1. Closure Alerts
The client and the server must share knowledge that the connection is The client and the server must share knowledge that the connection is
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
skipping to change at page 26, line 36 skipping to change at page 25, line 31
transfer any additional data, but will only close the underlying transfer any additional data, but will only close the underlying
transport connection, then the implementation MAY choose to close the transport connection, then the implementation MAY choose to close the
transport without waiting for the responding close_notify. No part transport without waiting for the responding close_notify. No part
of this standard should be taken to dictate the manner in which a of this standard should be taken to dictate the manner in which a
usage profile for TLS manages its data transport, including when usage profile for TLS manages its data transport, including when
connections are opened or closed. connections are opened or closed.
Note: It is assumed that closing a connection reliably delivers Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport. pending data before destroying the transport.
7.2.2. Error Alerts 7.1.2. Error Alerts
Error handling in the TLS Handshake protocol is very simple. When an Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection. Servers and clients MUST parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal failed connection. Thus, any connection terminated with a fatal
alert MUST NOT be resumed. alert MUST NOT be resumed.
Whenever an implementation encounters a condition which is defined as Whenever an implementation encounters a condition which is defined as
skipping to change at page 29, line 40 skipping to change at page 28, line 35
user_canceled user_canceled
This handshake is being canceled for some reason unrelated to a This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning. by a close_notify. This message is generally a warning.
no_renegotiation no_renegotiation
Sent by the client in response to a hello request or by the server Sent by the client in response to a hello request or by the server
in response to a client hello after initial handshaking. Either in response to a client hello after initial handshaking. Versions
of these would normally lead to renegotiation; when that is not of TLS prior to TLS 1.3 supported renegotiation of a previously
appropriate, the recipient should respond with this alert. At established connection; TLS 1.3 removes this feature. This
that point, the original requester can decide whether to proceed message is always fatal.
with the connection. One case where this would be appropriate is
where a server has spawned a process to satisfy a request; the
process might receive security parameters (key length,
authentication, etc.) at startup, and it might be difficult to
communicate changes to these parameters after that point. This
message is always a warning.
unsupported_extension unsupported_extension
sent by clients that receive an extended server hello containing sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client an extension that they did not put in the corresponding client
hello. This message is always fatal. hello. This message is always fatal.
New Alert values are assigned by IANA as described in Section 12. New Alert values are assigned by IANA as described in Section 12.
7.3. Handshake Protocol Overview 7.2. Handshake Protocol Overview
The cryptographic parameters of the session state are produced by the The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record TLS Handshake Protocol, which operates on top of the TLS record
layer. When a TLS client and server first start communicating, they layer. When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms, agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets. techniques to generate shared secrets.
The TLS Handshake Protocol involves the following steps: The TLS Handshake Protocol involves the following steps:
skipping to change at page 31, line 25 skipping to change at page 30, line 14
If the client has provided a ClientKeyShare with an appropriate set If the client has provided a ClientKeyShare with an appropriate set
of keying material, the server responds to the ClientHello with a of keying material, the server responds to the ClientHello with a
ServerHello message. The ServerHello contains the server's nonce ServerHello message. The ServerHello contains the server's nonce
(ServerHello.random), the server's choice of the Protocol Version, (ServerHello.random), the server's choice of the Protocol Version,
Session ID and Cipher Suite, and the server's response to the Session ID and Cipher Suite, and the server's response to the
extensions the client offered. extensions the client offered.
The server can then generate its own keying material share and send a The server can then generate its own keying material share and send a
ServerKeyShare message which contains its share of the parameters for ServerKeyShare message which contains its share of the parameters for
the key agreement. The server can now compute the shared secret. At the key agreement. The server can now compute the shared secret (the
this point, a ChangeCipherSpec message is sent by the server, and the premaster secret). At this point, the server starts encrypting all
server copies the pending Cipher Spec into the current Cipher Spec. remaining handshake traffic with the negotiated cipher suite using a
The remainder of the server's handshake messages will be encrypted key derived from the premaster secret (via the "handshake master
under that Cipher Spec. secret"). The remainder of the server's handshake messages will be
encrypted using that key.
Following these messages, the server will send an EncryptedExtensions Following these messages, the server will send an EncryptedExtensions
message which contains a response to any client's extensions which message which contains a response to any client's extensions which
are not necessary to establish the Cipher Suite. The server will are not necessary to establish the Cipher Suite. The server will
then send its certificate in a Certificate message if it is to be then send its certificate in a Certificate message if it is to be
authenticated. The server may optionally request a certificate from authenticated. The server may optionally request a certificate from
the client by sending a CertificateRequest message at this point. the client by sending a CertificateRequest message at this point.
Finally, if the server is authenticated, it will send a Finally, if the server is authenticated, it will send a
CertificateVerify message which provides a signature over the entire CertificateVerify message which provides a signature over the entire
handshake up to this point. This serves both to authenticate the handshake up to this point. This serves both to authenticate the
server and to establish the integrity of the negotiation. Finally, server and to establish the integrity of the negotiation. Finally,
the server sends a Finished message which includes an integrity check the server sends a Finished message which includes an integrity check
over the handshake keyed by the shared secret and demonstrates that over the handshake keyed by the shared secret and demonstrates that
the server and client have agreed upon the same keys. [[TODO: If the the server and client have agreed upon the same keys. [[TODO: If the
server is not requesting client authentication, it MAY start sending server is not requesting client authentication, it MAY start sending
application data following the Finished, though the server has no way application data following the Finished, though the server has no way
of knowing who will be receiving the data. Add this.]] of knowing who will be receiving the data. Add this.]]
Once the client receives the ServerKeyShare, it can also compute the Once the client receives the ServerKeyShare, it can also compute the
shared key. At this point ChangeCipherSpec message is sent by the premaster secret and decrypt the server's remaining handshake
client, and the client copies the pending Cipher Spec into the messages. The client generates its own sending keys based on the
current Cipher Spec. The remainder of the client's messages will be premaster secret and will encrypt the remainder of its handshake
encrypted under this Cipher Spec. If the server has sent a messages using those keys and the newly established cipher suite. If
CertificateRequest message, the client MUST send the Certificate the server has sent a CertificateRequest message, the client MUST
message, though it may contain zero certificates. If the client has send the Certificate message, though it may contain zero
sent a certificate, a digitally-signed CertificateVerify message is certificates. If the client has sent a certificate, a digitally-
sent to explicitly verify possession of the private key in the signed CertificateVerify message is sent to explicitly verify
certificate. Finally, the client sends the Finished message. At possession of the private key in the certificate. Finally, the
this point, the handshake is complete, and the client and server may client sends the Finished message.
exchange application layer data. (See flow chart below.)
At this point, the handshake is complete, and the client and server
may exchange application layer data, which is protected using a new
set of keys derived from both the premaster secret and the handshake
transcript (see [I-D.ietf-tls-session-hash] for the security
rationale for this.)
Application data MUST NOT be sent prior to the Finished message. Application data MUST NOT be sent prior to the Finished message.
[[TODO: can we make this clearer and more clearly match the text [[TODO: can we make this clearer and more clearly match the text
above about server-side False Start.]] Client Server above about server-side False Start.]] Client Server
ClientHello ClientHello
ClientKeyShare --------> ClientKeyShare -------->
ServerHello ServerHello
ServerKeyShare ServerKeyShare
[ChangeCipherSpec] {EncryptedExtensions*}
EncryptedExtensions* {Certificate*}
Certificate* {CertificateRequest*}
CertificateRequest* {CertificateVerify*}
CertificateVerify* <-------- {Finished}
<-------- Finished {Certificate*}
[ChangeCipherSpec] {CertificateVerify*}
Certificate* {Finished} -------->
CertificateVerify* [Application Data] <-------> [Application Data]
Finished -------->
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake Figure 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not * Indicates optional or situation-dependent messages that are not
always sent. always sent.
Note: To help avoid pipeline stalls, ChangeCipherSpec is an {} Indicates messages protected using keys derived from the handshake
independent TLS protocol content type, and is not actually a TLS master secret.
handshake message.
[] Indicates messages protected using keys derived from the master
secret.
If the client has not provided an appropriate ClientKeyShare (e.g. it If the client has not provided an appropriate ClientKeyShare (e.g. it
includes only DHE or ECDHE groups unacceptable or unsupported by the includes only DHE or ECDHE groups unacceptable or unsupported by the
server), the server corrects the mismatch with a HelloRetryRequest server), the server corrects the mismatch with a HelloRetryRequest
and the client will need to restart the handshake with an appropriate and the client will need to restart the handshake with an appropriate
ClientKeyShare, as shown in Figure 2: ClientKeyShare, as shown in Figure 2:
Client Server Client Server
ClientHello ClientHello
ClientKeyShare --------> ClientKeyShare -------->
<-------- HelloRetryRequest <-------- HelloRetryRequest
ClientHello ClientHello
ClientKeyShare --------> ClientKeyShare -------->
ServerHello ServerHello
ServerKeyShare ServerKeyShare
[ChangeCipherSpec] {EncryptedExtensions*}
EncryptedExtensions* {Certificate*}
Certificate* {CertificateRequest*}
CertificateRequest* {CertificateVerify*}
CertificateVerify* <-------- {Finished}
<-------- Finished {Certificate*}
[ChangeCipherSpec] {CertificateVerify*}
Certificate* {Finished} -------->
CertificateVerify* [Application Data] <-------> [Application Data]
Finished -------->
Application Data <-------> Application Data
Figure 2. Message flow for a full handshake with mismatched Figure 2. Message flow for a full handshake with mismatched
parameters parameters
[[OPEN ISSUE: Do we restart the handshake hash?]] [[OPEN ISSUE: We [[OPEN ISSUE: Should we restart the handshake hash?
https://github.com/tlswg/tls13-spec/issues/104.]] [[OPEN ISSUE: We
need to make sure that this flow doesn't introduce downgrade issues. need to make sure that this flow doesn't introduce downgrade issues.
Potential options include continuing the handshake hashes (as long as Potential options include continuing the handshake hashes (as long as
clients don't change their opinion of the server's capabilities with clients don't change their opinion of the server's capabilities with
aborted handshakes) and requiring the client to send the same aborted handshakes) and requiring the client to send the same
ClientHello (as is currently done) and then checking you get the same ClientHello (as is currently done) and then checking you get the same
negotiated parameters.]] negotiated parameters.]]
If no common cryptographic parameters can be negotiated, the server If no common cryptographic parameters can be negotiated, the server
will send a fatal alert. will send a fatal alert.
When the client and server decide to resume a previous session or When the client and server decide to resume a previous session or
duplicate an existing session (instead of negotiating new security duplicate an existing session (instead of negotiating new security
parameters), the message flow is as follows: parameters), the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to The client sends a ClientHello using the Session ID of the session to
be resumed. The server then checks its session cache for a match. be resumed. The server then checks its session cache for a match.
If a match is found, and the server is willing to re-establish the If a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both ServerHello with the same Session ID value. At this point, both
client and server MUST send ChangeCipherSpec messages and proceed client and server MUST proceed directly to sending Finished messages,
directly to Finished messages. Once the re-establishment is which are protected using handshake keys as described above, computed
complete, the client and server MAY begin to exchange application using resumption premaster secret created in the first handshake as
layer data. (See flow chart below.) If a Session ID match is not the premaster secret. Once the re-establishment is complete, the
found, the server generates a new session ID, and the TLS client and client and server MAY begin to exchange application layer data, which
server perform a full handshake. is protected using the application secrets (See flow chart below.)
If a Session ID match is not found, the server generates a new
session ID, and the TLS client and server perform a full handshake.
Client Server Client Server
ClientHello ClientHello
ClientKeyExhange --------> ClientKeyExhange -------->
ServerHello ServerHello
[ChangeCipherSpec] <-------- {Finished}
<-------- Finished {Finished} -------->
[ChangeCipherSpec] [Application Data] <-------> [Application Data]
Finished -------->
Application Data <-------> Application Data
Figure 3. Message flow for an abbreviated handshake Figure 3. Message flow for an abbreviated handshake
The contents and significance of each message will be presented in The contents and significance of each message will be presented in
detail in the following sections. detail in the following sections.
7.4. Handshake Protocol 7.3. Handshake Protocol
The TLS Handshake Protocol is one of the defined higher-level clients The TLS Handshake Protocol is one of the defined higher-level clients
of the TLS Record Protocol. This protocol is used to negotiate the of the TLS Record Protocol. This protocol is used to negotiate the
secure attributes of a session. Handshake messages are supplied to secure attributes of a session. Handshake messages are supplied to
the TLS record layer, where they are encapsulated within one or more the TLS record layer, where they are encapsulated within one or more
TLSPlaintext structures, which are processed and transmitted as TLSPlaintext structures, which are processed and transmitted as
specified by the current active session state. specified by the current active session state.
enum { enum {
hello_request(0), client_hello(1), server_hello(2), reserved(0), client_hello(1), server_hello(2),
certificate(11), reserved(12), server_key_share (17), client_key_share(5), hello_retry_request(6),
server_key_share(7), certificate(11), reserved(12),
certificate_request(13), certificate_verify(15), certificate_request(13), certificate_verify(15),
reserved(16), client_key_share(18), finished(20), (255) reserved(16), finished(20), (255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; /* handshake type */ HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */ uint24 length; /* bytes in message */
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case client_key_share: ClientKeyShare; case client_key_share: ClientKeyShare;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_requst: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case server_key_share: ServerKeyShare; case server_key_share: ServerKeyShare;
case certificate: Certificate; case certificate: Certificate;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case finished: Finished; case finished: Finished;
} body; } body;
} Handshake; } Handshake;
The handshake protocol messages are presented below in the order they The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order MUST be sent; sending handshake messages in an unexpected order
results in a fatal error. Unneeded handshake messages can be results in a fatal error. Unneeded handshake messages can be
omitted, however. The one message that is not bound by these omitted, however.
ordering rules is the HelloRequest message, which can be sent at any
time, but which SHOULD be ignored by the client if it arrives in the
middle of a handshake.
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.4.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. The current connection state is used for
renegotiation messages. renegotiation messages.
7.4.1.1. Hello Request 7.3.1.1. Client Hello
When this message will be sent:
The HelloRequest message MAY be sent by the server at any time.
Meaning of this message:
HelloRequest is a simple notification that the client should begin
the negotiation process anew. In response, the client should send
a ClientHello message when convenient. This message is not
intended to establish which side is the client or server but
merely to initiate a new negotiation. Servers SHOULD NOT send a
HelloRequest immediately upon the client's initial connection. It
is the client's job to send a ClientHello at that time.
This message will be ignored by the client if the client is
currently negotiating a session. This message MAY be ignored by
the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission
precedence over application data, it is expected that the
negotiation will begin before no more than a few records are
received from the client. If the server sends a HelloRequest but
does not receive a ClientHello in response, it may close the
connection with a fatal alert.
After sending a HelloRequest, servers SHOULD NOT repeat the
request until the subsequent handshake negotiation is complete.
Structure of this message:
struct { } HelloRequest;
This message MUST NOT be included in the message hashes that are
maintained throughout the handshake and used in the Finished messages
and the certificate verify message.
7.4.1.2. 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 can also send a the ClientHello as its first message. The client will also send a
ClientHello in response to a HelloRequest or on its own initiative ClientHello when the server has responded to its ClientHello with
in order to renegotiate the security parameters in an existing a ServerHello that selects cryptographic parameters that don't
connection. Finally, the client will send a ClientHello when the match the client's ClientKeyShare. In that case, the client MUST
server has responded to its ClientHello with a ServerHello that send the same ClientHello (without modification) along with the
selects cryptographic parameters that don't match the client's new ClientKeyShare. If a server receives a ClientHello at any
ClientKeyShare. In that case, the client MUST send the same other time, it MUST send a fatal no_renegotiation alert.
ClientHello (without modification) along with the new
ClientKeyShare.
Structure of this message: Structure of this message:
The ClientHello message includes a random structure, which is used The ClientHello message includes a random structure, which is used
later in the protocol. later in the protocol.
struct { struct {
opaque random_bytes[32]; opaque random_bytes[32];
} Random; } Random;
skipping to change at page 39, line 21 skipping to change at page 37, line 29
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
appropriate prior version of TLS. appropriate prior version of TLS.
extensions extensions
Clients MAY request extended functionality from servers by sending Clients MAY request extended functionality from servers by sending
data in the extensions field. The actual "Extension" format is data in the extensions field. The actual "Extension" format is
defined in Section 7.4.2.5. defined in Section 7.3.2.5.
In the event that a client requests additional functionality using In the event that a client requests additional functionality using
extensions, and this functionality is not supplied by the server, the extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake. A server MUST accept ClientHello client MAY abort the handshake. A server MUST accept ClientHello
messages both with and without the extensions field, and (as for all messages both with and without the extensions field, and (as for all
other messages) it MUST check that the amount of data in the message other messages) it MUST check that the amount of data in the message
precisely matches one of these formats; if not, then it MUST send a precisely matches one of these formats; if not, then it MUST send a
fatal "decode_error" alert. fatal "decode_error" alert.
After sending the ClientHello message, the client waits for a After sending the ClientHello message, the client waits for a
ServerHello message. Any handshake message returned by the server, ServerHello or HelloRetryRequest message.
except for a HelloRequest, is treated as a fatal error.
7.4.2. Client Key Share Message 7.3.2. Client Key Share Message
When this message will be sent: When this message will be sent:
This message is always sent by the client. It MUST immediately This message is always sent by the client. It MUST immediately
follow the ClientHello message. In backward compatibility mode follow the ClientHello message. In backward compatibility mode
(see Section XXX) it will be included in the EarlyData extension (see Section XXX) it will be included in the EarlyData extension
(Section 7.4.2.5.4) in the ClientHello. (Section 7.3.2.5.3) in the ClientHello.
Meaning of this message: Meaning of this message:
This message contains the client's cryptographic parameters for This message contains the client's cryptographic parameters for
zero or more key establishment methods. zero or more key establishment methods.
Structure of this message: Structure of this message:
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer; } ClientKeyShareOffer;
group The named group for the key share offer. This identifies the group The named group for the key share offer. This identifies the
specific key exchange method that the ClientKeyShareOffer specific key exchange method that the ClientKeyShareOffer
describes. Finite Field Diffie-Hellman parameters are described describes. Finite Field Diffie-Hellman parameters are described
in Section 7.4.2.1; Elliptic Curve Diffie-Hellman parameters are in Section 7.3.2.1; Elliptic Curve Diffie-Hellman parameters are
described in Section 7.4.2.2. described in Section 7.3.2.2.
key_exchange Key exchange information. The contents of this field key_exchange Key exchange information. The contents of this field
are determined by the value of NamedGroup entry and its are determined by the value of NamedGroup entry and its
corresponding definition. corresponding definition.
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare; } ClientKeyShare;
offers offers
skipping to change at page 40, line 39 skipping to change at page 38, line 44
instance a client might offer shares for several elliptic curves or instance a client might offer shares for several elliptic curves or
multiple integer DH groups. The shares for each ClientKeyShareOffer multiple integer DH groups. The shares for each ClientKeyShareOffer
MUST by generated independently. Clients MUST NOT offer multiple MUST by generated independently. Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters. It is explicitly ClientKeyShareOffers for the same parameters. It is explicitly
permitted to send an empty ClientKeyShare message, as this is used to permitted to send an empty ClientKeyShare message, as this is used to
elicit the server's parameters if the client has no useful elicit the server's parameters if the client has no useful
information. [TODO: Recommendation about what the client offers. information. [TODO: Recommendation about what the client offers.
Presumably which integer DH groups and which curves.] [TODO: Work Presumably which integer DH groups and which curves.] [TODO: Work
out how this interacts with PSK and SRP.] out how this interacts with PSK and SRP.]
7.4.2.1. Diffie-Hellman Parameters 7.3.2.1. Diffie-Hellman Parameters
Diffie-Hellman parameters for both clients and servers are encoded in Diffie-Hellman parameters for both clients and servers are encoded in
the opaque key_exchange field of the ClientKeyShareOffer or the opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value contains the Diffie- ServerKeyShare structures. The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer. integer.
opaque dh_Y<1..2^16-1>; opaque dh_Y<1..2^16-1>;
7.4.2.2. ECHDE Parameters 7.3.2.2. ECHDE Parameters
ECDHE parameters for both clients and servers are encoded in the ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value conveys the Elliptic ServerKeyShare structures. The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point, which can represent an elliptic curve point in string ECPoint.point.
uncompressed or compressed format.
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
point point
This is the byte string representation of an elliptic curve point This is the byte string representation of an elliptic curve point
following the conversion routine in Section 4.3.6 of ANSI X9.62 following the conversion routine in Section 4.3.6 of ANSI X9.62
{{X962}. {{X962}.
Although X9.62 supports multiple point formats, any given curve MUST
specify only a single point format. All curves currently specified
in this document MUST only be used with the uncompressed point
format.
Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS
1.3 removes this feature in favor of a single point format for each
curve.
[[OPEN ISSUE: We will need to adjust the compressed/uncompressed [[OPEN ISSUE: We will need to adjust the compressed/uncompressed
point issue if we have new curves that don't need point compression. point issue if we have new curves that don't need point compression.
This depends on the CFRG's recommendations. The expectation is that This depends on the CFRG's recommendations. The expectation is that
future curves will come with defined point formats and that existing future curves will come with defined point formats and that existing
curves conform to X9.62.]] curves conform to X9.62.]]
7.4.2.3. Server Hello 7.3.2.3. Server Hello
When this message will be sent: When this message will be sent:
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare message was acceptable. If the and the client's ClientKeyShare message was acceptable. If the
client proposed groups are not acceptable by the server, it will client proposed groups are not acceptable by the server, it will
respond with an insufficient_security fatal alert. respond with an insufficient_security fatal alert.
Structure of this message: Structure of this message:
skipping to change at page 42, line 16 skipping to change at page 40, line 29
there are bytes following the cipher_suite field at the end of the there are bytes following the cipher_suite field at the end of the
ServerHello. ServerHello.
server_version server_version
This field will contain the lower of that suggested by the client This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For in the client hello and the highest supported by the server. For
this version of the specification, the version is 3.4. (See this version of the specification, the version is 3.4. (See
Appendix E for details about backward compatibility.) Appendix E for details about backward compatibility.)
random random
This structure is generated by the server and MUST be This structure is generated by the server and MUST be generated
independently generated from the ClientHello.random. independently of the ClientHello.random.
session_id session_id
This is the identity of the session corresponding to this This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection found and the server is willing to establish the new connection
using the specified session state, the server will respond with using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed resumed session and dictates that the parties must proceed
directly to the Finished messages. Otherwise, this field will directly to the Finished messages. Otherwise, this field will
skipping to change at page 42, line 47 skipping to change at page 41, line 12
cipher_suite cipher_suite
The single cipher suite selected by the server from the list in The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions, this field is ClientHello.cipher_suites. For resumed sessions, this field is
the value from the state of the session being resumed. the value from the state of the session being resumed.
extensions extensions
A list of extensions. Note that only extensions offered by the A list of extensions. Note that only extensions offered by the
client can appear in the server's list. In TLS 1.3 as opposed to client can appear in the server's list. In TLS 1.3 as opposed to
previous versions of TLS, the server's extensions are split previous versions of TLS, the server's extensions are split
between the ServerHello and the EncryptedExtensions Section 7.4.4 between the ServerHello and the EncryptedExtensions Section 7.3.4
message. The ServerHello MUST only include extensions which are message. The ServerHello MUST only include extensions which are
required to establish the cryptographic context. required to establish the cryptographic context.
7.4.2.4. HelloRetryRequest 7.3.2.4. HelloRetryRequest
When this message will be sent: When this message will be sent:
The server will send this message in response to a ClientHello The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms message when it was able to find an acceptable set of algorithms
but the client's ClientKeyShare message did not contain an but the client's ClientKeyShare message did not contain an
acceptable offer. If it cannot find such a match, it will respond acceptable offer. If it cannot find such a match, it will respond
with a handshake failure alert. with a handshake failure alert.
Structure of this message: Structure of this message:
skipping to change at page 43, line 45 skipping to change at page 42, line 10
ClientHello/ClientKeyShare pair to the server. The ClientKeyShare ClientHello/ClientKeyShare pair to the server. The ClientKeyShare
MUST contain both the groups in the original ClientKeyShare as well MUST contain both the groups in the original ClientKeyShare as well
as a ClientKeyShareOffer consistent with the "selected_group" field. as a ClientKeyShareOffer consistent with the "selected_group" field.
I.e., it MUST be a superset of the previous ClientKeyShareOffer. I.e., it MUST be a superset of the previous ClientKeyShareOffer.
Upon re-sending the ClientHello/ClientKeyShare and receiving the Upon re-sending the ClientHello/ClientKeyShare and receiving the
server's ServerHello/ServerKeyShare, the client MUST verify that the server's ServerHello/ServerKeyShare, the client MUST verify that the
selected ciphersuite and NamedGroup match that supplied in the selected ciphersuite and NamedGroup match that supplied in the
HelloRetryRequest. HelloRetryRequest.
7.4.2.5. Hello Extensions 7.3.2.5. Hello Extensions
The extension format is: The extension format is:
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
} Extension; } Extension;
enum { enum {
signature_algorithms(13), early_data(TBD), (65535) signature_algorithms(13), early_data(TBD), (65535)
skipping to change at page 45, line 43 skipping to change at page 44, line 5
- It would be technically possible to use extensions to change major - It would be technically possible to use extensions to change major
aspects of the design of TLS; for example the design of cipher aspects of the design of TLS; for example the design of cipher
suite negotiation. This is not recommended; it would be more suite negotiation. This is not recommended; it would be more
appropriate to define a new version of TLS -- particularly since appropriate to define a new version of TLS -- particularly since
the TLS handshake algorithms have specific protection against the TLS handshake algorithms have specific protection against
version rollback attacks based on the version number, and the version rollback attacks based on the version number, and the
possibility of version rollback should be a significant possibility of version rollback should be a significant
consideration in any major design change. consideration in any major design change.
7.4.2.5.1. Signature Algorithms 7.3.2.5.1. Signature Algorithms
The client uses the "signature_algorithms" extension to indicate to The client uses the "signature_algorithms" extension to indicate to
the server which signature/hash algorithm pairs may be used in the server which signature/hash algorithm pairs may be used in
digital signatures. The "extension_data" field of this extension digital signatures. The "extension_data" field of this extension
contains a "supported_signature_algorithms" value. contains a "supported_signature_algorithms" value.
enum { enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255) sha512(6), (255)
} HashAlgorithm; } HashAlgorithm;
skipping to change at page 46, line 41 skipping to change at page 44, line 48
values indicate support for unhashed data, MD5 [RFC1321], SHA-1, values indicate support for unhashed data, MD5 [RFC1321], SHA-1,
SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The
"none" value is provided for future extensibility, in case of a "none" value is provided for future extensibility, in case of a
signature algorithm which does not require hashing before signing. signature algorithm which does not require hashing before signing.
signature signature
This field indicates the signature algorithm that may be used. This field indicates the signature algorithm that may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
[RFC3447] and DSA [DSS], and ECDSA [ECDSA], respectively. The [RFC3447] and DSA [DSS], and ECDSA [ECDSA], respectively. The
"anonymous" value is meaningless in this context but used in "anonymous" value is meaningless in this context but used in
Section 7.4.3. It MUST NOT appear in this extension. Section 7.3.3. It MUST NOT appear in this extension.
The semantics of this extension are somewhat complicated because the The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash cipher suite indicates permissible signature algorithms but not hash
algorithms. Section 7.4.5 and Section 7.4.3 describe the appropriate algorithms. Section 7.3.5 and Section 7.3.3 describe the appropriate
rules. rules.
If the client supports only the default hash and signature algorithms If the client supports only the default hash and signature algorithms
(listed in this section), it MAY omit the signature_algorithms (listed in this section), it MAY omit the signature_algorithms
extension. If the client does not support the default algorithms, or extension. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to supports other hash and signature algorithms (and it is willing to
use them for verifying messages sent by the server, i.e., server use them for verifying messages sent by the server, i.e., server
certificates and server key share), it MUST send the certificates and server key share), it MUST send the
signature_algorithms extension, listing the algorithms it is willing signature_algorithms extension, listing the algorithms it is willing
to accept. to accept.
skipping to change at page 47, line 36 skipping to change at page 45, line 44
However, even if clients do offer it, the rules specified in [TLSEXT] However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand. require servers to ignore extensions they do not understand.
Servers MUST NOT send this extension. TLS servers MUST support Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. receiving this extension.
When performing session resumption, this extension is not included in When performing session resumption, this extension is not included in
Server Hello, and the server ignores the extension in Client Hello Server Hello, and the server ignores the extension in Client Hello
(if present). (if present).
7.4.2.5.2. Negotiated Groups 7.3.2.5.2. Negotiated Groups
When sent by the client, the "supported_groups" extension indicates When sent by the client, the "supported_groups" extension indicates
the named groups which the client supports, ordered from most the named groups which the client supports, ordered from most
preferred to least preferred. preferred to least preferred.
Note: In versions of TLS prior to TLS 1.3, this extension was named Note: In versions of TLS prior to TLS 1.3, this extension was named
"elliptic curves" and only contained elliptic curve groups. See "elliptic curves" and only contained elliptic curve groups. See
[RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe]. [RFC4492] and [I-D.ietf-tls-negotiated-ff-dhe].
The "extension_data" field of this extension SHALL contain a The "extension_data" field of this extension SHALL contain a
skipping to change at page 49, line 22 skipping to change at page 47, line 30
across all cipher suites, then the server MUST generate a fatal across all cipher suites, then the server MUST generate a fatal
"handshake_failure" alert. "handshake_failure" alert.
NOTE: A server participating in an ECDHE-ECDSA key exchange may use NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii) different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyExchange message. The server the ephemeral ECDH key in the ServerKeyExchange message. The server
must consider the supported groups in both cases. must consider the supported groups in both cases.
[[TODO: IANA Considerations.]] [[TODO: IANA Considerations.]]
7.4.2.5.3. Supported Point Formats Extension 7.3.2.5.3. Early Data Extension
[[OPEN ISSUE: Can we simply mandate support for compressed points?
If so, we can omit this extension entirely.
https://github.com/tlswg/tls13-spec/issues/80.]]
A client that proposes ECC cipher suites in its ClientHello message
SHOULD send the Supported Point Formats Extension to indicate the
elliptic curve point formats it supports. If the Supported Point
Formats Extension is indeed sent, it MUST contain the value 0
(uncompressed) as one of the items in the list of point formats.
enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
Three point formats are included in the definition of ECPointFormat
above. The uncompressed point format is the default format in that
implementations of this document MUST support it for all of their
supported curves. Compressed point formats reduce bandwidth by
including only the x-coordinate and a single bit of the y-coordinate
of the point. Implementations of this document MAY support the
ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
where the former applies only to prime curves and the latter applies
only to characteristic-2 curves. (These formats are specified in
[X962].) Values 248 through 255 are reserved for private use.
The ECPointFormat name space is maintained by IANA. See Section 12
for information on how new value assignments are added.
Items in ec_point_format_list are ordered according to the sender's
preferences (favorite choice first).
An endpoint that can parse only the uncompressed point format (value
0) includes an extension consisting of the following octets; note
that the first two octets indicate the extension type (Supported
Point Formats Extension):
00 0B 00 02 01 00
An endpoint that in the case of prime fields prefers the compressed
format (ansiX962_compressed_prime, value 1) over the uncompressed
format (value 0), but in the case of characteristic-2 fields prefers
the uncompressed format (value 0) over the compressed format
(ansiX962_compressed_char2, value 2), may indicate these preferences
by including an extension consisting of the following octets:
00 0B 00 04 03 01 00 02
If the client supplies a Supported Points Formats Extension in the
ClientHello, the server may send its own Supported Points Format
extension in the ServerHello. This extension allows a server to
enumerate the point formats it can parse (for the curve that will
appear in its ServerKeyExchange message when using the ECDHE_ECDSA or
ECDHE_RSA key exchange algorithm, or for the curve that is used in
the server's public key that will appear in its Certificate message
when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).
The server's Supported Point Formats Extension has the same structure
and semantics as the client's Supported Point Formats Extension.
Note that the server may include items that were not found in the
client's list (e.g., the server may prefer to receive points in
compressed format even when a client cannot parse this format: the
same client may nevertheless be capable of outputting points in
compressed format).
An endpoint that receives a hello message containing a Supported
Point Formats Extension MUST respect the sender's choice of point
formats during the handshake. If no Supported Point Formats
Extension is received this is equivalent to an extension allowing
only the uncompressed point format.
7.4.2.5.4. Early Data Extension
TLS versions before 1.3 have a strict message ordering and do not TLS versions before 1.3 have a strict message ordering and do not
permit additional messages to follow the ClientHello. The EarlyData permit additional messages to follow the ClientHello. The EarlyData
extension allows TLS messages which would otherwise be sent as extension allows TLS messages which would otherwise be sent as
separate records to be instead inserted in the ClientHello. The separate records to be instead inserted in the ClientHello. The
extension simply contains the TLS records which would otherwise have extension simply contains the TLS records which would otherwise have
been included in the client's first flight. been included in the client's first flight.
struct { struct {
TLSCipherText messages<5 .. 2^24-1>; TLSCipherText messages<5 .. 2^24-1>;
skipping to change at page 52, line 5 skipping to change at page 48, line 25
serves as acknowledgement that it was processed as described above. serves as acknowledgement that it was processed as described above.
[[OPEN ISSUE: This is a fairly general mechanism which is possibly [[OPEN ISSUE: This is a fairly general mechanism which is possibly
overkill in the 1-RTT case, where it would potentially be more overkill in the 1-RTT case, where it would potentially be more
attractive to just have a "ClientKeyShare" extension. However, for attractive to just have a "ClientKeyShare" extension. However, for
the 0-RTT case we will want to send the Certificate, the 0-RTT case we will want to send the Certificate,
CertificateVerify, and application data, so a more general extension CertificateVerify, and application data, so a more general extension
seems appropriate at least until we have determined we don't need it seems appropriate at least until we have determined we don't need it
for 0-RTT.]] for 0-RTT.]]
7.4.3. Server Key Share Message 7.3.3. Server Key Share Message
When this message will be sent: When this message will be sent:
This message will be sent immediately after the ServerHello This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyShare message which message if the client has provided a ClientKeyShare message which
is compatible with the selected cipher suite and group parameters. is compatible with the selected cipher suite and group parameters.
Meaning of this message: Meaning of this message:
This message conveys cryptographic information to allow the client This message conveys cryptographic information to allow the client
skipping to change at page 52, line 30 skipping to change at page 48, line 50
Structure of this message: Structure of this message:
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ServerKeyShare; } ServerKeyShare;
group The named group for the key share offer. This identifies the group The named group for the key share offer. This identifies the
selected key exchange method from the ClientKeyShare message selected key exchange method from the ClientKeyShare message
(Section 7.4.2), identifying which value from the (Section 7.3.2), identifying which value from the
ClientKeyShareOffer the server has accepted as is responding to. ClientKeyShareOffer the server has accepted as is responding to.
key_exchange Key exchange information. The contents of this field key_exchange Key exchange information. The contents of this field
are determined by the value of NamedGroup entry and its are determined by the value of NamedGroup entry and its
corresponding definition. corresponding definition.
7.4.4. Encrypted Extensions 7.3.4. Encrypted Extensions
When this message will be sent: When this message will be sent:
If this message is sent, it MUST be sent immediately after the If this message is sent, it MUST be sent immediately after the
server's ChangeCipherSpec (and hence as the first handshake server's ServerKeyShare.
message after the ServerKeyShare).
Meaning of this message: Meaning of this message:
The EncryptedExtensions message simply contains any extensions The EncryptedExtensions message simply contains any extensions
which should be protected, i.e., any which are not needed to which should be protected, i.e., any which are not needed to
establish the cryptographic context. The same extension types establish the cryptographic context. The same extension types
MUST NOT appear in both the ServerHello and EncryptedExtensions. MUST NOT appear in both the ServerHello and EncryptedExtensions.
If the same extension appears in both locations, the client MUST If the same extension appears in both locations, the client MUST
rely only on the value in the EncryptedExtensions block. [[OPEN rely only on the value in the EncryptedExtensions block. [[OPEN
ISSUE: Should we just produce a canonical list of what goes where ISSUE: Should we just produce a canonical list of what goes where
skipping to change at page 53, line 18 skipping to change at page 49, line 38
Structure of this message: Structure of this message:
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
extensions extensions
A list of extensions. A list of extensions.
7.4.5. Server Certificate 7.3.5. Server Certificate
When this message will be sent: When this message will be sent:
The server MUST send a Certificate message whenever the agreed- The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document (this includes all key exchange methods defined in this document
except DH_anon). This message will always immediately follow the except DH_anon). This message will always immediately follow
ChangeCipherSpec which follows the server's ServerKeyShare either the EncryptedExtensions message if one is sent or the
message. ServerKeyShare message.
Meaning of this message: Meaning of this message:
This message conveys the server's certificate chain to the client. This message conveys the server's certificate chain to the client.
The certificate MUST be appropriate for the negotiated cipher The certificate MUST be appropriate for the negotiated cipher
suite's key exchange algorithm and any negotiated extensions. suite's key exchange algorithm and any negotiated extensions.
Structure of this message: Structure of this message:
skipping to change at page 55, line 29 skipping to change at page 52, line 5
Note that there are certificates that use algorithms and/or algorithm Note that there are certificates that use algorithms and/or algorithm
combinations that cannot be currently used with TLS. For example, a combinations that cannot be currently used with TLS. For example, a
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
SubjectPublicKeyInfo) cannot be used because TLS defines no SubjectPublicKeyInfo) cannot be used because TLS defines no
corresponding signature algorithm. corresponding signature algorithm.
As cipher suites that specify new key exchange methods are specified As cipher suites that specify new key exchange methods are specified
for the TLS protocol, they will imply the certificate format and the for the TLS protocol, they will imply the certificate format and the
required encoded keying information. required encoded keying information.
7.4.6. Certificate Request 7.3.6. Certificate Request
When this message will be sent: When this message will be sent:
A non-anonymous server can optionally request a certificate from A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the server's Certificate message, if sent, will immediately follow the server's Certificate
message). message).
Structure of this message: Structure of this message:
skipping to change at page 57, line 31 skipping to change at page 53, line 41
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 12. Section 12.
Note: Values listed as RESERVED may not be used. They were used in Note: Values listed as RESERVED may not be used. They were used in
SSLv3. SSLv3.
Note: It is a fatal handshake_failure alert for an anonymous server Note: It is a fatal handshake_failure alert for an anonymous server
to request client authentication. to request client authentication.
7.4.7. Server Certificate Verify 7.3.7. Server Certificate Verify
When this message will be sent: When this message will be sent:
This message is used to provide explicit proof that the server This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate. possesses the private key corresponding to its certificate.
certificate and also provides integrity for the handshake up to certificate and also provides integrity for the handshake up to
this point. This message is only sent when the server is this point. This message is only sent when the server is
authenticated via a certificate. When sent, it MUST be the last authenticated via a certificate. When sent, it MUST be the last
server handshake message prior to the Finished. server handshake message prior to the Finished.
Structure of this message: Structure of this message:
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_messages[handshake_messages_length]; opaque handshake_messages_hash[hash_length];
} }
} CertificateVerify; } CertificateVerify;
Here handshake_messages refers to all handshake messages sent or Here handshake_messages_hash is a digest of all handshake messages
received, starting at client hello and up to, but not including, sent or received, starting at ClientHello and up to, but not
this message, including the type and length fields of the including, this message, including the type and length fields of
handshake messages. This is the concatenation of all the the handshake messages. This is a digest of the concatenation of
Handshake structures (as defined in Section 7.4) exchanged thus all the Handshake structures (as defined in Section 7.3) exchanged
far. Note that this requires both sides to either buffer the thus far. For the PRF defined in Section 5, the digest MUST be
messages or compute running hashes for all potential hash the Hash used as the basis for the PRF. Any cipher suite which
algorithms up to the time of the CertificateVerify computation. defines a different PRF MUST also define the Hash to use in this
Servers can minimize this computation cost by offering a computation. Note that this is the same running hash that is used
restricted set of digest algorithms in the CertificateRequest in the Finished message Section 7.3.8.
message.
The context string for the signature is "TLS 1.3, server
CertificateVerify". A hash of the handshake messages is signed
rather than the messages themselves because the digitally-signed
format requires padding and context bytes at the beginning of the
input. Thus, by signing a digest of the messages, an
implementation need only maintain one running hash per hash type
for CertificateVerify, Finished and other messages.
If the client has offered the "signature_algorithms" extension, If the client has offered the "signature_algorithms" extension,
the signature algorithm and hash algorithm MUST be a pair listed the signature algorithm and hash algorithm MUST be a pair listed
in that extension. Note that there is a possibility for in that extension. Note that there is a possibility for
inconsistencies here. For instance, the client might offer inconsistencies here. For instance, the client might offer
DHE_DSS key exchange but omit any DSA pairs from its DHE_DSS key exchange but omit any DSA pairs from its
"signature_algorithms" extension. In order to negotiate "signature_algorithms" extension. In order to negotiate
correctly, the server MUST check any candidate cipher suites correctly, the server MUST check any candidate cipher suites
against the "signature_algorithms" extension before selecting against the "signature_algorithms" extension before selecting
them. This is somewhat inelegant but is a compromise designed to them. This is somewhat inelegant but is a compromise designed to
skipping to change at page 58, line 40 skipping to change at page 55, line 8
hash algorithm, there is a risk of hash substitution if multiple hash algorithm, there is a risk of hash substitution if multiple
hashes may be used with any key. Currently, DSA [DSS] may only be hashes may be used with any key. Currently, DSA [DSS] may only be
used with SHA-1. Future revisions of DSS [DSS-3] are expected to used with SHA-1. Future revisions of DSS [DSS-3] are expected to
allow the use of other digest algorithms with DSA, as well as allow the use of other digest algorithms with DSA, as well as
guidance as to which digest algorithms should be used with each guidance as to which digest algorithms should be used with each
key size. In addition, future revisions of [RFC3280] may specify key size. In addition, future revisions of [RFC3280] may specify
mechanisms for certificates to indicate which digest algorithms mechanisms for certificates to indicate which digest algorithms
are to be used with DSA. [[TODO: Update this to deal with DSS-3 are to be used with DSA. [[TODO: Update this to deal with DSS-3
and DSS-4. https://github.com/tlswg/tls13-spec/issues/59]] and DSS-4. https://github.com/tlswg/tls13-spec/issues/59]]
7.4.8. Server Finished 7.3.8. Server Finished
When this message will be sent: When this message will be sent:
The Server's Finished message is the final message sent by the The Server's Finished message is the final message sent by the
server and indicates that the key exchange and authentication server and indicates that the key exchange and authentication
processes were successful. processes were successful.
Meaning of this message: Meaning of this message:
Recipients of Finished messages MUST verify that the contents are Recipients of Finished messages MUST verify that the contents are
correct. Once a side has sent its Finished message and received correct. Once a side has sent its Finished message and received
and validated the Finished message from its peer, it may begin to and validated the Finished message from its peer, it may begin to
send and receive application data over the connection. send and receive application data over the connection. This data
will be protected under keys derived from the hs_master_secret
(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(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 finished". For Finished messages sent by the server, "client finished". For Finished messages sent by the server,
the string "server finished". the string "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
skipping to change at page 59, line 33 skipping to change at page 56, line 4
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
includes all existing cipher suites. Note that this includes all existing cipher suites. Note that this
representation has the same encoding as with previous versions. representation has the same encoding as with previous versions.
Future cipher suites MAY specify other lengths but such length Future cipher suites MAY specify other lengths but such length
MUST be at least 12 bytes. MUST be at least 12 bytes.
handshake_messages handshake_messages
All of the data from all messages in this handshake (not including All of the data from all messages in this handshake (not including
any HelloRequest messages) up to, but not including, this message. any HelloRequest messages) up to, but not including, this message.
This is only data visible at the handshake layer and does not This is only data visible at the handshake layer and does not
include record layer headers. This is the concatenation of all include record layer headers. This is the concatenation of all
the Handshake structures as defined in Section 7.4, exchanged thus the Handshake structures as defined in Section 7.3, exchanged thus
far. far.
It is a fatal error if a Finished message is not preceded by a
ChangeCipherSpec message at the appropriate point in the handshake.
The value handshake_messages includes all handshake messages starting The value handshake_messages includes all handshake messages starting
at ClientHello up to, but not including, this Finished message. This at ClientHello up to, but not including, this Finished message. This
may be different from handshake_messages in Section 7.4.7 or may be different from handshake_messages in Section 7.3.7 or
Section 7.4.10. Also, the handshake_messages for the Finished Section 7.3.10. Also, the handshake_messages for the Finished
message sent by the client will be different from that for the message sent by the client will be different from that for the
Finished message sent by the server, because the one that is sent Finished message sent by the server, because the one that is sent
second will include the prior one. second will include the prior one.
Note: ChangeCipherSpec messages, alerts, and any other record types Note: Alerts and any other record types are not handshake messages
are not handshake messages and are not included in the hash and are not included in the hash computations. Also, HelloRequest
computations. Also, HelloRequest messages are omitted from handshake messages are omitted from handshake hashes.
hashes.
7.4.9. Client Certificate 7.3.9. Client Certificate
When this message will be sent: When this message will be sent:
This message is the first handshake message the client can send This message is the first handshake message the client can send
after receiving the server's Finished and having sent its own after receiving the server's Finished. This message is only sent
ChangeCipherSpecs. This message is only sent if the server if the server requests a certificate. If no suitable certificate
requests a certificate. If no suitable certificate is available, is available, the client MUST send a certificate message
the client MUST send a certificate message containing no containing no certificates. That is, the certificate_list
certificates. That is, the certificate_list structure has a structure has a length of zero. If the client does not send any
length of zero. If the client does not send any certificates, the certificates, the server MAY at its discretion either continue the
server MAY at its discretion either continue the handshake without handshake without client authentication, or respond with a fatal
client authentication, or respond with a fatal handshake_failure handshake_failure alert. Also, if some aspect of the certificate
alert. Also, if some aspect of the certificate chain was chain was unacceptable (e.g., it was not signed by a known,
unacceptable (e.g., it was not signed by a known, trusted CA), the trusted CA), the server MAY at its discretion either continue the
server MAY at its discretion either continue the handshake handshake (considering the client unauthenticated) or send a fatal
(considering the client unauthenticated) or send a fatal alert. alert.
Client certificates are sent using the Certificate structure Client certificates are sent using the Certificate structure
defined in Section 7.4.5. defined in Section 7.3.5.
Meaning of this message: Meaning of this message:
This message conveys the client's certificate chain to the server; This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing) or message (when the client authentication is based on signing) or
calculating the premaster secret (for non-ephemeral Diffie- calculating the premaster secret (for non-ephemeral Diffie-
Hellman). The certificate MUST be appropriate for the negotiated Hellman). The certificate MUST be appropriate for the negotiated
cipher suite's key exchange algorithm, and any negotiated cipher suite's key exchange algorithm, and any negotiated
extensions. extensions.
skipping to change at page 61, line 36 skipping to change at page 58, line 6
rsa_fixed_ecdh ECDH-capable public key; MUST use the rsa_fixed_ecdh ECDH-capable public key; MUST use the
ecdsa_fixed_ecdh same curve as the server's key, and MUST use a ecdsa_fixed_ecdh same curve as the server's key, and MUST use a
point format supported by the server. point format supported by the server.
- If the certificate_authorities list in the certificate request - If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs. chain SHOULD be issued by one of the listed CAs.
- The certificates MUST be signed using an acceptable hash/ - The certificates MUST be signed using an acceptable hash/
signature algorithm pair, as described in Section 7.4.6. Note signature algorithm pair, as described in Section 7.3.6. Note
that this relaxes the constraints on certificate-signing that this relaxes the constraints on certificate-signing
algorithms found in prior versions of TLS. algorithms found in prior versions of TLS.
Note that, as with the server certificate, there are certificates Note that, as with the server certificate, there are certificates
that use algorithms/algorithm combinations that cannot be currently that use algorithms/algorithm combinations that cannot be currently
used with TLS. used with TLS.
7.4.10. Client Certificate Verify 7.3.10. Client Certificate Verify
When this message will be sent: When this message will be sent:
This message is used to provide explicit verification of a client This message is used to provide explicit verification of a client
certificate. This message is only sent following a client certificate. This message is only sent following a client
certificate that has signing capability (i.e., all certificates certificate that has signing capability (i.e., all certificates
except those containing fixed Diffie-Hellman parameters). When except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client's Certificate message. sent, it MUST immediately follow the client's Certificate message.
The contents of the message are computed as described in The contents of the message are computed as described in
Section 7.4.7. Section 7.3.7, except that the context string is "TLS 1.3, client
CertificateVerify".
The hash and signature algorithms used in the signature MUST be The hash and signature algorithms used in the signature MUST be
one of those present in the supported_signature_algorithms field one of those present in the supported_signature_algorithms field
of the CertificateRequest message. In addition, the hash and of the CertificateRequest message. In addition, the hash and
signature algorithms MUST be compatible with the key in the signature algorithms MUST be compatible with the key in the
client's end-entity certificate. RSA keys MAY be used with any client's end-entity certificate. RSA keys MAY be used with any
permitted hash algorithm, subject to restrictions in the permitted hash algorithm, subject to restrictions in the
certificate, if any. certificate, if any.
Because DSA signatures do not contain any secure indication of Because DSA signatures do not contain any secure indication of
skipping to change at page 62, line 38 skipping to change at page 59, line 9
In order to begin connection protection, the TLS Record Protocol In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, key the client and server random values. The authentication, key
agreement, and record protection algorithms are determined by the agreement, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello cipher_suite selected by the server and revealed in the ServerHello
message. The random values are exchanged in the hello messages. All message. The random values are exchanged in the hello messages. All
that remains is to calculate the master secret. that remains is to calculate the master secret.
8.1. Computing the Master Secret 8.1. Computing the Master Secret
For all key exchange methods, the same algorithm is used to convert The pre_master_secret is used to generate a series of master secret
the pre_master_secret into the master_secret. The pre_master_secret values, as shown in the following diagram and described below.
should be deleted from memory once the master_secret has been
computed.
master_secret = PRF(pre_master_secret, "master secret", Premaster Secret <---------+
ClientHello.random + ServerHello.random) | |
PRF |
| |
v |
Handshake <-PRF- Handshake |
Traffic Keys Master Secret |
| | Via
| | Session
+----------+----------+ | Cache
| | |
PRF PRF |
| | |
v v |
Application <-PRF- Master Resumption |
Traffic Keys Secret Premaster --+
Secret
First, as soon as the ClientKeyShare and ServerKeyShare messages have
been exchanged, the client and server each use the unauthenticated
key shares to generate a master secret which is used for the
protection of the remaining handshake records. Specifically, they
generate:
hs_master_secret = PRF(pre_master_secret, "handshake master secret",
session_hash)
[0..47];
During resumption, the premaster secret is initialized with the
"resumption premaster secret", rather than using the values from the
ClientKeyShare/ServerKeyShare exchange.
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
used with TLS Exporters [RFC5705].
Once the hs_master_secret has been computed, the premaster secret
SHOULD be deleted from memory.
Once the last non-Finished message has been sent, the client and
server then compute the master secret which will be used for the
remainder of the session:
master_secret = PRF(hs_master_secret, "extended master secret",
session_hash)
[0..47]; [0..47];
The master secret is always exactly 48 bytes in length. The length If the server does not request client authentication, the master
secret can be computed at the time that the server sends its
Finished, thus allowing the server to send traffic on its first
flight (see [TODO] for security considerations on this practice.) If
the server requests client authentication, this secret can be
computed after the client's Certificate and CertificateVerify have
been sent, or, if the client refuses client authentication, after the
client's empty Certificate message has been sent.
For full handshakes, each side also derives a new secret which will
be used as the premaster_secret for future resumptions of the newly
established session. This is computed as:
resumption_premaster_secret = PRF(hs_master_secret,
"resumption premaster secret",
session_hash)
[0..47];
The session_hash value is a running hash of the handshake as defined
in Section 8.1.1. Thus, the hs_master_secret is generated using a
different session_hash from the other two secrets.
All master secrets are always exactly 48 bytes in length. The length
of the premaster secret will vary depending on key exchange method. of the premaster secret will vary depending on key exchange method.
8.1.1. Diffie-Hellman 8.1.1. The Session Hash
When a handshake takes place, we define
session_hash = Hash(handshake_messages)
where "handshake_messages" refers to all handshake messages sent or
received, starting at client hello up to the present time, with the
exception of the Finished message, including the type and length
fields of the handshake messages. This is the concatenation of all
the exchanged Handshake structures.
For concreteness, at the point where the handshake master secret is
derived, the session hash includes the ClientHello, ClientKeyShare,
ServerHello, and ServerKeyShare, and HelloRetryRequest (if any)
(though see [https://github.com/tlswg/tls13-spec/issues/104]). At
the point where the master secret is derived, it includes every
handshake message, with the exception of the Finished messages. Note
that if client authentication is not used, then the session hash is
complete at the point when the server has sent its first flight.
Otherwise, it is only complete when the client has sent its first
flight, as it covers the client's Certificate and CertificateVerify.
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 Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's certificate. be either ephemeral or contained within the server's certificate.
8.1.2. 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
found in this octet string MUST NOT be truncated. found in this octet string MUST NOT be truncated.
skipping to change at page 64, line 44 skipping to change at page 62, line 49
- TLS HandshakeType Registry: Future values are allocated via - TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC2434]. Standards Action [RFC2434].
This document also uses a registry originally created in [RFC4366]. This document also uses a registry originally created in [RFC4366].
IANA has updated it to reference this document. The registry and its IANA has updated it to reference this document. The registry and its
allocation policy (unchanged from [RFC4366]) is listed below: allocation policy (unchanged from [RFC4366]) is listed below:
- TLS ExtensionType Registry: Future values are allocated via IETF - TLS ExtensionType Registry: Future values are allocated via IETF
Consensus [RFC2434]. IANA has updated this registry to include Consensus [RFC2434]. IANA has updated this registry to include
the signature_algorithms extension and its corresponding value the signature_algorithms extension and its corresponding value
(see Section 7.4.2.5). (see Section 7.3.2.5).
This document also uses two registries originally created in This document also uses two registries originally created in
[RFC4492]. IANA [should update/has updated] it to reference this [RFC4492]. IANA [should update/has updated] it to reference this
document. The registries and their allocation policies are listed document. The registries and their allocation policies are listed
below. below.
- TLS NamedCurve registry: Future values are allocated via IETF - TLS NamedCurve registry: Future values are allocated via IETF
Consensus [RFC2434]. Consensus [RFC2434].
- TLS ECPointFormat Registry: Future values are allocated via IETF - TLS ECPointFormat Registry: Future values are allocated via IETF
Consensus [RFC2434]. Consensus [RFC2434].
In addition, this document defines two new registries to be In addition, this document defines two new registries to be
maintained by IANA: maintained by IANA:
- TLS SignatureAlgorithm Registry: The registry has been initially - TLS SignatureAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.2.5.1. Future populated with the values described in Section 7.3.2.5.1. Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal) Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434]. inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434]. Use [RFC2434].
- TLS HashAlgorithm Registry: The registry has been initially - TLS HashAlgorithm Registry: The registry has been initially
populated with the values described in Section 7.4.2.5.1. Future populated with the values described in Section 7.3.2.5.1. Future
values in the range 0-63 (decimal) inclusive are assigned via values in the range 0-63 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values in the range 64-223 (decimal) Standards Action [RFC2434]. Values in the range 64-223 (decimal)
inclusive are assigned via Specification Required [RFC2434]. inclusive are assigned via Specification Required [RFC2434].
Values from 224-255 (decimal) inclusive are reserved for Private Values from 224-255 (decimal) inclusive are reserved for Private
Use [RFC2434]. Use [RFC2434].
13. References 13. References
13.1. Normative References 13.1. Normative References
skipping to change at page 67, line 41 skipping to change at page 65, line 48
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-02 (work in progress), October 2014. ff-dhe-05 (work in progress), December 2014.
[I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-03 (work in progress), November 2014.
[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.
skipping to change at page 69, line 12 skipping to change at page 67, line 30
[RFC4506] Eisler, M., "XDR: External Data Representation Standard", [RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006. STD 67, RFC 4506, May 2006.
[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
Layer Security (TLS)", RFC 5705, March 2010.
[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 72, line 5 skipping to change at page 71, line 5
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
A.4. Handshake Protocol A.4. Handshake Protocol
enum { enum {
hello_request(0), client_hello(1), server_hello(2), reserved(0), client_hello(1), server_hello(2),
hello_retry_request(4), client_key_share(5), hello_retry_request(6),
certificate(11), server_key_share (17), server_key_share(7), certificate(11), reserved(12),
certificate_request(13), server_hello_done(14), certificate_request(13), certificate_verify(15),
certificate_verify(15), client_key_share(18), reserved(16), finished(20), (255)
finished(20),
(255)
} HandshakeType; } HandshakeType;
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_requst: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case certificate: Certificate; case certificate: Certificate;
case server_key_share: ServerKeyShare; case server_key_share: ServerKeyShare;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone; case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_share: ClientKeyShare; case client_key_share: ClientKeyShare;
case finished: Finished; case finished: Finished;
} body; } body;
} Handshake; } Handshake;
skipping to change at page 74, line 47 skipping to change at page 73, line 47
ClientKeyShareOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare; } ClientKeyShare;
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer; } ClientKeyShareOffer;
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_messages[handshake_messages_length]; opaque handshake_messages_hash[hash_length];
} }
} CertificateVerify; } CertificateVerify;
The context string for the signature is "TLS 1.3, client
CertificateVerify".
A.4.4. Handshake Finalization Message A.4.4. Handshake Finalization Message
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
A.5. The Cipher Suite A.5. 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.
skipping to change at page 77, line 51 skipping to change at page 76, line 51
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
digital signatures formed using ECDSA as well, thus allowing ECDSA digital signatures formed using ECDSA as well, thus allowing ECDSA
signatures to be used with digest algorithms other than SHA-1, signatures to be used with digest algorithms other than SHA-1,
provided such use is compatible with the certificate and any provided such use is compatible with the certificate and any
restrictions imposed by future revisions of [RFC3280]. restrictions imposed by future revisions of [RFC3280].
As described in Section 7.4.5 and Section 7.4.9, the restrictions on As described in Section 7.3.5 and Section 7.3.9, the restrictions on
the signature algorithms used to sign certificates are no longer tied the signature algorithms used to sign certificates are no longer tied
to the cipher suite (when used by the server) or the to the cipher suite (when used by the server) or the
ClientCertificateType (when used by the client). Thus, the ClientCertificateType (when used by the client). Thus, the
restrictions on the algorithm used to sign certificates specified in restrictions on the algorithm used to sign certificates specified in
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, Sections 2 and 3 of RFC 4492 are also relaxed. As in this document,
the restrictions on the keys in the end-entity certificate remain. the restrictions on the keys in the end-entity certificate remain.
Appendix B. Glossary Appendix B. Glossary
Advanced Encryption Standard (AES) Advanced Encryption Standard (AES)
skipping to change at page 83, line 11 skipping to change at page 82, line 11
you fragment handshake messages that exceed the maximum fragment you fragment handshake messages that exceed the maximum fragment
size? In particular, the certificate and certificate request size? In particular, the certificate and certificate request
handshake messages can be large enough to require fragmentation. handshake messages can be large enough to require fragmentation.
- Do you ignore the TLS record layer version number in all TLS - Do you ignore the TLS record layer version number in all TLS
records before ServerHello (see Appendix E.1)? records before ServerHello (see Appendix E.1)?
- Do you handle TLS extensions in ClientHello correctly, including - Do you handle TLS extensions in ClientHello correctly, including
omitting the extensions field completely? omitting the extensions field completely?
- Do you support renegotiation, both client and server initiated?
While renegotiation is an optional feature, supporting it is
highly recommended.
- When the server has requested a client certificate, but no - When the server has requested a client certificate, but no
suitable certificate is available, do you correctly send an empty suitable certificate is available, do you correctly send an empty
Certificate message, instead of omitting the whole message (see Certificate message, instead of omitting the whole message (see
Section 7.4.9)? Section 7.3.9)?
Cryptographic details: Cryptographic details:
- What countermeasures do you use to prevent timing attacks against - What countermeasures do you use to prevent timing attacks against
RSA signing operations [TIMING]. RSA signing operations [TIMING].
- When verifying RSA signatures, do you accept both NULL and missing - When verifying RSA signatures, do you accept both NULL and missing
parameters (see Section 4.7)? Do you verify that the RSA padding parameters (see Section 4.7)? Do you verify that the RSA padding
doesn't have additional data after the hash value? [FI06] doesn't have additional data after the hash value? [FI06]
- When using Diffie-Hellman key exchange, do you correctly strip - When using Diffie-Hellman key exchange, do you correctly strip
leading zero bytes from the negotiated key (see Section 8.1.1)? leading zero bytes from the negotiated key (see Section 8.1.2)?
- 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
skipping to change at page 88, line 15 skipping to change at page 87, line 6
leading to an acceptable certificate authority. Similarly, leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's server. Each party is responsible for verifying that the other's
certificate is valid and has not expired or been revoked. certificate is valid and has not expired or been revoked.
The general goal of the key exchange process is to create a The general goal of the key exchange process is to create a
pre_master_secret known to the communicating parties and not to pre_master_secret known to the communicating parties and not to
attackers. The pre_master_secret will be used to generate the attackers. The pre_master_secret will be used to generate the
master_secret (see Section 8.1). The master_secret is required to master_secret (see Section 8.1). The master_secret is required to
generate the Finished messages and record protection keys (see generate the Finished messages and record protection keys (see
Section 7.4.8 and Section 6.3). By sending a correct Finished Section 7.3.8 and Section 6.3). By sending a correct Finished
message, parties thus prove that they know the correct message, parties thus prove that they know the correct
pre_master_secret. pre_master_secret.
F.1.1.1. Anonymous Key Exchange F.1.1.1. Anonymous Key Exchange
Completely anonymous sessions can be established using Diffie-Hellman Completely anonymous sessions can be established using Diffie-Hellman
for key exchange. The server's public parameters are contained in for key exchange. The server's public parameters are contained in
the server key share message, and the client's are sent in the client the server key share message, and the client's are sent in the client
key share message. Eavesdroppers who do not know the private values key share message. Eavesdroppers who do not know the private values
should not be able to find the Diffie-Hellman result (i.e., the should not be able to find the Diffie-Hellman result (i.e., the
skipping to change at page 91, line 28 skipping to change at page 90, line 17
Appendix H. Contributors Appendix H. Contributors
Christopher Allen (co-editor of TLS 1.0) Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures Alacrity Ventures
ChristopherA@AlacrityManagement.com ChristopherA@AlacrityManagement.com
Martin Abadi Martin Abadi
University of California, Santa Cruz University of California, Santa Cruz
abadi@cs.ucsc.edu abadi@cs.ucsc.edu
Karthikeyan Bhargavan (co-author of [I-D.ietf-tls-session-hash])
INRIA
karthikeyan.bhargavan@inria.fr
Steven M. Bellovin Steven M. Bellovin
Columbia University Columbia University
smb@cs.columbia.edu smb@cs.columbia.edu
Simon Blake-Wilson (co-author of RFC4492) Simon Blake-Wilson (co-author of RFC4492)
BCI BCI
sblakewilson@bcisse.com sblakewilson@bcisse.com
Nelson Bolyard Nelson Bolyard
Sun Microsystems, Inc. Sun Microsystems, Inc.
nelson@bolyard.com (co-author of RFC4492) nelson@bolyard.com (co-author of RFC4492)
Ran Canetti Ran Canetti
IBM IBM
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])
INRIA
antoine.delignat-lavaud@inria.fr
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 41 skipping to change at page 91, line 37
Phil Karlton (co-author of SSLv3) Phil Karlton (co-author of SSLv3)
Paul Kocher (co-author of SSLv3) Paul Kocher (co-author of SSLv3)
Cryptography Research Cryptography Research
paul@cryptography.com paul@cryptography.com
Hugo Krawczyk Hugo Krawczyk
IBM IBM
hugo@ee.technion.ac.il hugo@ee.technion.ac.il
Adam Langley (co-author of [I-D.ietf-tls-session-hash])
Google
agl@google.com
Ilari Liusvaara
ilari.liusvaara@elisanet.fi
Jan Mikkelsen Jan Mikkelsen
Transactionware Transactionware
janm@transactionware.com janm@transactionware.com
Bodo Moeller (co-author of RFC4492) Bodo Moeller (co-author of RFC4492)
Google Google
bodo@openssl.org bodo@openssl.org
Magnus Nystrom Magnus Nystrom
RSA Security RSA Security
magnus@rsasecurity.com magnus@rsasecurity.com
Alfredo Pironti
Alfredo Pironti (co-author of [I-D.ietf-tls-session-hash])
INRIA INRIA
alfredo.pironti@inria.fr alfredo.pironti@inria.fr
Marsh Ray (co-author of [I-D.ietf-tls-session-hash])
Microsoft
maray@microsoft.com
Robert Relyea Robert Relyea
Netscape Communications Netscape Communications
relyea@netscape.com relyea@netscape.com
Jim Roskind Jim Roskind
Netscape Communications Netscape Communications
jar@netscape.com jar@netscape.com
Michael Sabin Michael Sabin
 End of changes. 117 change blocks. 
532 lines changed or deleted 474 lines changed or added

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