draft-ietf-tls-tls13-06.txt   draft-ietf-tls-tls13-07.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 3268, 4346, 4366, 5246 (if June 29, 2015 Obsoletes: 3268, 4346, 4366, 5246, 5077 July 08, 2015
approved) (if approved)
Updates: 4492 (if approved) Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 31, 2015 Expires: January 9, 2016
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-06 draft-ietf-tls-tls13-07
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 December 31, 2015. This Internet-Draft will expire on January 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6 1.2. Major Differences from TLS 1.2 . . . . . . . . . . . . . 6
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 7 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 8
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 8 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 8
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 8 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 8
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 11 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 11
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 11 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Cryptographic Attributes . . . . . . . . . . . . . . . . 12 4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Constants . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 13
5. The Pseudorandom Function . . . . . . . . . . . . . . . . . . 15 4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 14
6. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16 4.9.1. Digital Signing . . . . . . . . . . . . . . . . . . . 14
6.1. Connection States . . . . . . . . . . . . . . . . . . . . 17 4.9.2. Authenticated Encryption with Additional Data (AEAD) 15
6.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19 5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16
6.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19 5.1. Connection States . . . . . . . . . . . . . . . . . . . . 17
6.2.2. Record Payload Protection . . . . . . . . . . . . . . 20 5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Key Calculation . . . . . . . . . . . . . . . . . . . . . 22 5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19
7. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23 5.2.2. Record Payload Protection . . . . . . . . . . . . . . 20
7.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 24 6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 22
7.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25 6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23
7.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 26 6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 24
7.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 30 6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25
7.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 34 6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 29
7.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 35 6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 32
7.3.2. Client Key Share . . . . . . . . . . . . . . . . . . 38 6.2.2. Cached Server Configuration . . . . . . . . . . . . . 33
7.3.3. Server Key Share . . . . . . . . . . . . . . . . . . 49 6.2.3. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 34
7.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 50 6.2.4. Resumption and PSK . . . . . . . . . . . . . . . . . 35
7.3.5. Server Certificate . . . . . . . . . . . . . . . . . 50 6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 36
7.3.6. Certificate Request . . . . . . . . . . . . . . . . . 53 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 37
7.3.7. Server Certificate Verify . . . . . . . . . . . . . . 54 6.3.2. Server Key Share . . . . . . . . . . . . . . . . . . 54
7.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 56 6.3.3. Encrypted Extensions . . . . . . . . . . . . . . . . 55
7.3.9. Client Certificate . . . . . . . . . . . . . . . . . 57 6.3.4. Server Certificate . . . . . . . . . . . . . . . . . 55
7.3.10. Client Certificate Verify . . . . . . . . . . . . . . 59 6.3.5. Certificate Request . . . . . . . . . . . . . . . . . 58
8. Cryptographic Computations . . . . . . . . . . . . . . . . . 59 6.3.6. Server Configuration . . . . . . . . . . . . . . . . 59
8.1. Computing the Master Secret . . . . . . . . . . . . . . . 60 6.3.7. Server Certificate Verify . . . . . . . . . . . . . . 61
8.1.1. The Session Hash . . . . . . . . . . . . . . . . . . 61 6.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 62
8.1.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 62 6.3.9. Client Certificate . . . . . . . . . . . . . . . . . 63
8.1.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 62 6.3.10. Client Certificate Verify . . . . . . . . . . . . . . 64
9. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 62 6.3.11. New Session Ticket Message . . . . . . . . . . . . . 65
10. Application Data Protocol . . . . . . . . . . . . . . . . . . 62 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 66
11. Security Considerations . . . . . . . . . . . . . . . . . . . 63 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 66
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 7.2. Traffic Key Calculation . . . . . . . . . . . . . . . . . 67
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.2.1. The Handshake Hash . . . . . . . . . . . . . . . . . 68
13.1. Normative References . . . . . . . . . . . . . . . . . . 64 7.2.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 69
13.2. Informative References . . . . . . . . . . . . . . . . . 66 7.2.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 69
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 68 8. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 70
Appendix A. Protocol Data Structures and Constant Values . . . . 69 9. Application Data Protocol . . . . . . . . . . . . . . . . . . 70
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 70
A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 72
A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 74 12.2. Informative References . . . . . . . . . . . . . . . . . 73
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 74 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.3.4. Handshake Finalization Messages . . . . . . . . . . . 75 Appendix A. Protocol Data Structures and Constant Values . . . . 77
A.4. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 75 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 77
A.5. The Security Parameters . . . . . . . . . . . . . . . . . 76 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 77
A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 77 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 78
Appendix B. Cipher Suite Definitions . . . . . . . . . . . . . . 78 A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 79
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 78 A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 82
C.1. Random Number Generation and Seeding . . . . . . . . . . 78 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 83
C.2. Certificates and Authentication . . . . . . . . . . . . . 78 A.3.4. Handshake Finalization Messages . . . . . . . . . . . 84
C.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 79 A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 84
C.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 79 A.4. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 84
Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 80 A.5. The Security Parameters . . . . . . . . . . . . . . . . . 86
D.1. Negotiating with an older server . . . . . . . . . . . . 80 A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 86
D.2. Negotiating with an older client . . . . . . . . . . . . 81 Appendix B. Cipher Suite Definitions . . . . . . . . . . . . . . 87
D.3. Backwards Compatibility Security Restrictions . . . . . . 81 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 87
Appendix E. Security Analysis . . . . . . . . . . . . . . . . . 82 C.1. Random Number Generation and Seeding . . . . . . . . . . 87
E.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 82 C.2. Certificates and Authentication . . . . . . . . . . . . . 87
E.1.1. Authentication and Key Exchange . . . . . . . . . . . 83 C.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 88
E.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 84 C.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 88
E.1.3. Detecting Attacks Against the Handshake Protocol . . 84 Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 89
E.1.4. Resuming Sessions . . . . . . . . . . . . . . . . . . 84 D.1. Negotiating with an older server . . . . . . . . . . . . 89
D.2. Negotiating with an older client . . . . . . . . . . . . 90
E.2. Protecting Application Data . . . . . . . . . . . . . . . 85 D.3. Backwards Compatibility Security Restrictions . . . . . . 90
E.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 85 Appendix E. Security Analysis . . . . . . . . . . . . . . . . . 91
E.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 86 E.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 91
Appendix F. Working Group Information . . . . . . . . . . . . . 86 E.1.1. Authentication and Key Exchange . . . . . . . . . . . 92
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 86 E.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 93
E.1.3. Detecting Attacks Against the Handshake Protocol . . 93
E.2. Protecting Application Data . . . . . . . . . . . . . . . 93
E.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 94
E.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 94
Appendix F. Working Group Information . . . . . . . . . . . . . 94
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 95
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 6, line 12 skipping to change at page 6, line 20
sender: An endpoint that is transmitting records. sender: An endpoint that is transmitting records.
session: An association between a client and a server resulting from session: An association between a client and a server resulting from
a handshake. a handshake.
server: The endpoint which did not initiate the TLS connection. server: The endpoint which did not initiate the TLS connection.
1.2. Major Differences from TLS 1.2 1.2. Major Differences from TLS 1.2
draft-07 - Integration of semi-ephemeral DH proposal.
- Add initial 0-RTT support
- Remove resumption and replace with PSK + tickets
- Move ClientKeyShare into an extension.
- Move to HKDF
draft-06 draft-06
- Prohibit RC4 negotiation for backwards compatibility. - Prohibit RC4 negotiation for backwards compatibility.
- Freeze & deprecate record layer version field. - Freeze & deprecate record layer version field.
- Update format of signatures with context. - Update format of signatures with context.
- Remove explicit IV. - Remove explicit IV.
skipping to change at page 7, line 47 skipping to change at page 8, line 18
4. Relative efficiency: Cryptographic operations tend to be highly 4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations. For this CPU intensive, particularly public key operations. For this
reason, the TLS protocol has incorporated an optional session reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to caching scheme to reduce the number of connections that need to
be established from scratch. Additionally, care has been taken be established from scratch. Additionally, care has been taken
to reduce network activity. to reduce network activity.
3. Goals of This Document 3. Goals of This Document
This document and the TLS protocol itself are based on the SSL 3.0 This document and the TLS protocol itself have evolved from the SSL
Protocol Specification as published by Netscape. The differences 3.0 Protocol Specification as published by Netscape. The differences
between this protocol and SSL 3.0 are not dramatic, but they are between this protocol and previous versions are significant enough
significant enough that the various versions of TLS and SSL 3.0 do that the various versions of TLS and SSL 3.0 do not interoperate
not interoperate (although each protocol incorporates a mechanism by (although each protocol incorporates a mechanism by which an
which an implementation can back down to prior versions). This implementation can back down to prior versions). This document is
document is intended primarily for readers who will be implementing intended primarily for readers who will be implementing the protocol
the protocol and for those doing cryptographic analysis of it. The and for those doing cryptographic analysis of it. The specification
specification has been written with this in mind, and it is intended has been written with this in mind, and it is intended to reflect the
to reflect the needs of those two groups. For that reason, many of needs of those two groups. For that reason, many of the algorithm-
the algorithm-dependent data structures and rules are included in the dependent data structures and rules are included in the body of the
body of the text (as opposed to in an appendix), providing easier text (as opposed to in an appendix), providing easier access to them.
access to them.
This document is not intended to supply any details of service This document is not intended to supply any details of service
definition or of interface definition, although it does cover select definition or of interface definition, although it does cover select
areas of policy as they are required for the maintenance of solid areas of policy as they are required for the maintenance of solid
security. security.
4. Presentation Language 4. Presentation Language
This document deals with the formatting of data in an external This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually representation. The following very basic and somewhat casually
skipping to change at page 12, line 43 skipping to change at page 13, line 27
struct { struct {
select (VariantTag) { /* value of selector is implicit */ select (VariantTag) { /* value of selector is implicit */
case apple: case apple:
V1; /* VariantBody, tag = apple */ V1; /* VariantBody, tag = apple */
case orange: case orange:
case banana: case banana:
V2; /* VariantBody, tag = orange or banana */ V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */ } variant_body; /* optional label on variant */
} VariantRecord; } VariantRecord;
4.7. Cryptographic Attributes 4.7. Constants
Typed constants can be defined for purposes of specification by
declaring a symbol of the desired type and assigning values to it.
Under-specified types (opaque, variable-length vectors, and
structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided.
For example:
struct {
uint8 f1;
uint8 f2;
} Example1;
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
4.8. Primitive Types
The following common primitive types are defined and used
subsequently:
enum { false(0), true(1) } Boolean;
4.9. Cryptographic Attributes
The two cryptographic operations -- digital signing, and The two cryptographic operations -- digital signing, and
authenticated encryption with additional data (AEAD) -- are authenticated encryption with additional data (AEAD) -- are
designated digitally-signed, and aead-ciphered, respectively. A designated digitally-signed, and aead-ciphered, respectively. A
field's cryptographic processing is specified by prepending an field's cryptographic processing is specified by prepending an
appropriate key word designation before the field's type appropriate key word designation before the field's type
specification. Cryptographic keys are implied by the current session specification. Cryptographic keys are implied by the current session
state (see Section 6.1). state (see Section 5.1).
4.9.1. Digital Signing
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.3.2.5.1 for the definition of this field). Note that the Section 6.3.1.4.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 In previous versions of TLS, the ServerKeyExchange format meant that
attackers can obtain a signature of a message with a chosen, 32-byte 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 prefix. Because TLS 1.3 servers are likely to also implement prior
versions, the contents of the element always start with 64 bytes of versions, the contents of the element always start with 64 bytes of
skipping to change at page 14, line 26 skipping to change at page 15, line 38
hash functions specified in FIPS 180-2 may be used instead if the hash functions specified in FIPS 180-2 may be used instead if the
certificate containing the EC public key explicitly requires use of certificate containing the EC public key explicitly requires use of
another hash function. (The mechanism for specifying the required another hash function. (The mechanism for specifying the required
hash function has not been standardized, but this provision hash function has not been standardized, but this provision
anticipates such standardization and obviates the need to update this anticipates such standardization and obviates the need to update this
document in response. Future PKIX RFCs may choose, for example, to document in response. Future PKIX RFCs may choose, for example, to
specify the hash function to be used with a public key in the specify the hash function to be used with a public key in the
parameters field of subjectPublicKeyInfo.) [[OPEN ISSUE: This needs parameters field of subjectPublicKeyInfo.) [[OPEN ISSUE: This needs
updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]] updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]]
4.9.2. Authenticated Encryption with Additional Data (AEAD)
In AEAD encryption, the plaintext is simultaneously encrypted and In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected. The input may be of any length, and aead- integrity protected. The input may be of any length, and aead-
ciphered output is generally larger than the input in order to ciphered output is generally larger than the input in order to
accommodate the integrity check value. accommodate the integrity check value.
In the following example In the following example
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;
Assume that the context string for the signature was specified as Assume that the context string for the signature was specified as
skipping to change at page 15, line 9 skipping to change at page 16, line 29
followed by the encoding of the inner struct (field3 and field4). followed by the encoding of the inner struct (field3 and field4).
The length of the structure, in bytes, would be equal to two bytes 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 for field1 and field2, plus two bytes for the signature and hash
algorithm, plus two bytes for the length of the signature, plus the algorithm, plus two bytes for the length of the signature, plus the
length of the output of the signing algorithm. The length of 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 signature is known because the algorithm and key used for the signing
are known prior to encoding or decoding this structure. are known prior to encoding or decoding this structure.
4.8. Constants 5. The TLS Record Protocol
Typed constants can be defined for purposes of specification by
declaring a symbol of the desired type and assigning values to it.
Under-specified types (opaque, variable-length vectors, and
structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided.
For example:
struct {
uint8 f1;
uint8 f2;
} Example1;
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
5. The Pseudorandom Function
A construction is required to do expansion of secrets into blocks of
data for the purposes of key generation or validation. This
pseudorandom function (PRF) takes as input a secret, a seed, and an
identifying label and produces an output of arbitrary length.
In this section, we define one PRF, based on HMAC [RFC2104]. This
PRF with the SHA-256 hash function is used for all cipher suites
defined in this document and in TLS documents published prior to this
document when TLS 1.2 or later is negotiated. New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function.
First, we define a data expansion function, P_hash(secret, data),
that uses a single hash function to expand a secret and seed into an
arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...
where + indicates concatenation.
A() is defined as:
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
P_hash can be iterated as many times as necessary to produce the
required quantity of data. For example, if P_SHA256 is being used to
create 80 bytes of data, it will have to be iterated three times
(through A(3)), creating 96 bytes of output data; the last 16 bytes
of the final iteration will then be discarded, leaving 80 bytes of
output data.
TLS's PRF is created by applying P_hash to the secret as:
PRF(secret, label, seed) = P_<hash>(secret, label + seed)
The label is an ASCII string. It should be included in the exact
form it is given without a length byte or trailing null character.
For example, the label "slithy toves" would be processed by hashing
the following bytes:
73 6C 69 74 68 79 20 74 6F 76 65 73
6. The TLS Record Protocol
The TLS Record Protocol is a layered protocol. At each layer, The TLS Record Protocol is a layered protocol. At each layer,
messages may include fields for length, description, and content. messages may include fields for length, description, and content.
The Record Protocol takes messages to be transmitted, fragments the The Record Protocol takes messages to be transmitted, fragments the
data into manageable blocks, protects the records, and transmits the data into manageable blocks, protects the records, and transmits the
result. Received data is decrypted and verified, reassembled, and result. Received data is decrypted and verified, reassembled, and
then delivered to higher-level clients. then delivered to higher-level clients.
Three protocols that use the record protocol are described in this Three protocols that use the record protocol are described in this
document: the handshake protocol, the alert protocol, and the document: the handshake protocol, the alert protocol, and the
application data protocol. In order to allow extension of the TLS application data protocol. In order to allow extension of the TLS
protocol, additional record content types can be supported by the protocol, additional record content types can be supported by the
record protocol. New record content type values are assigned by IANA record protocol. New record content type values are assigned by IANA
in the TLS Content Type Registry as described in Section 12. in the TLS Content Type Registry as described in Section 11.
Implementations MUST NOT send record types not defined in this Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST send an implementation receives an unexpected record type, it MUST send an
"unexpected_message" alert. "unexpected_message" alert.
Any protocol designed for use over TLS must be carefully designed to Any protocol designed for use over TLS must be carefully designed to
deal with all possible attacks against it. As a practical matter, deal with all possible attacks against it. As a practical matter,
this means that the protocol designer must be aware of what security this means that the protocol designer must be aware of what security
properties TLS does and does not provide and cannot safely rely on properties TLS does and does not provide and cannot safely rely on
the latter. the latter.
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 5.1. Connection States
[[TODO: I plan to totally rewrite or remove this. IT seems like just
cruft.]]
A TLS connection state is the operating environment of the TLS Record A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a record protection algorithm and its Protocol. It specifies a record protection algorithm and its
parameters as well as the record protection keys and IVs for the parameters as well as the record protection keys and IVs for the
connection in both the read and the write directions. The security connection in both the read and the write directions. The security
parameters are set by the TLS Handshake Protocol, which also parameters are set by the TLS Handshake Protocol, which also
determines when new cryptographic keys are installed and used for determines when new cryptographic keys are installed and used for
record protection. The initial current state always specifies that record protection. The initial current state always specifies that
records are not protected. records are not protected.
The security parameters for a TLS Connection read and write state are The security parameters for a TLS Connection read and write state are
set by providing the following values: set by providing the following values:
connection end connection end
Whether this entity is considered the "client" or the "server" in Whether this entity is considered the "client" or the "server" in
this connection. this connection.
PRF algorithm Hash algorithm
An algorithm used to generate keys from the master secret (see An algorithm used to generate keys from the appropriate secret
Section 5 and Section 6.3). (see Section 7.1 and Section 7.2).
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 5.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 of the nonce for the AEAD algorithm. size of this algorithm and of the nonce for the AEAD algorithm.
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. and used to generate keys for protecting 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;
enum { tls_prf_sha256 } PRFAlgorithm; enum { tls_kdf_sha256, tls_kdf_sha384 } KDFAlgorithm;
enum { aes_gcm } RecordProtAlgorithm; enum { aes_gcm } RecordProtAlgorithm;
/* The algorithms specified in PRFAlgorithm and /* The algorithms specified in KDFAlgorithm and
RecordProtAlgorithm may be added to. */ RecordProtAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; KDFAlgorithm kdf_algorithm;
RecordProtAlgorithm record_prot_algorithm; RecordProtAlgorithm record_prot_algorithm;
uint8 enc_key_length; uint8 enc_key_length;
uint8 iv_length; uint8 iv_length;
opaque hs_master_secret[48]; 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 [TODO: update this to handle new key hierarchy.]
The connection state will use the security parameters to generate the
following four items: following four items:
client write key client write key
server write key server write key
client write iv client write iv
server write iv server write iv
The client write parameters are used by the server when receiving and The client write parameters are used by the server when receiving and
processing records and vice versa. The algorithm used for generating processing records and vice versa. The algorithm used for generating
these items from the security parameters is described in Section 6.3. these items from the security parameters is described in Section 7.2.
Once the security parameters have been set and the keys have been Once the security parameters have been set and the keys have been
generated, the connection states can be instantiated by making them generated, the connection states can be instantiated by making them
the current states. These current states MUST be updated for each the current states. These current states MUST be updated for each
record processed. Each connection state includes the following record processed. Each connection state includes the following
elements: elements:
cipher state cipher state
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 is set to zero at the beginning of a connection and
active state. Sequence numbers are of type uint64 and MUST NOT incremented by one thereafter. Sequence numbers are of type
exceed 2^64-1. Sequence numbers do not wrap. If a TLS uint64 and MUST NOT exceed 2^64-1. Sequence numbers do not wrap.
implementation would need to wrap a sequence number, it MUST If a TLS implementation would need to wrap a sequence number, it
terminate the connection. A sequence number is incremented after MUST terminate the connection. A sequence number is incremented
each record: specifically, the first record transmitted under a after each record: specifically, the first record transmitted
particular connection state MUST use sequence number 0. under a particular connection state MUST use sequence number 0.
NOTE: This is a change from previous versions of TLS, where
sequence numbers were reset whenever keys were changed.
6.2. Record Layer 5.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 5.2.1. Fragmentation
The record layer fragments information blocks into TLSPlaintext The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Client records carrying data in chunks of 2^14 bytes or less. Client
message boundaries are not preserved in the record layer (i.e., message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be into a single TLSPlaintext record, or a single message MAY be
fragmented across several records). fragmented across several records).
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
enum { enum {
reserved(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), early_handshake(25),
(255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
type type
skipping to change at page 20, line 26 skipping to change at page 20, line 34
3, 1 } for TLS 1.0 and { 3, 0 } for SSL 3.0. In order to maximize 3, 1 } for TLS 1.0 and { 3, 0 } for SSL 3.0. In order to maximize
backwards compatibility, the record layer version identifies as backwards compatibility, the record layer version identifies as
simply TLS 1.0. Endpoints supporting other versions negotiate the simply TLS 1.0. Endpoints supporting other versions negotiate the
version to use by following the procedure and requirements in version to use by following the procedure and requirements in
Appendix D. Appendix D.
Implementations MUST NOT send zero-length fragments of Handshake or Implementations MUST NOT send zero-length fragments of Handshake or
Alert types. Zero-length fragments of Application data MAY be sent Alert types. Zero-length fragments of Application data MAY be sent
as they are potentially useful as a traffic analysis countermeasure. as they are potentially useful as a traffic analysis countermeasure.
6.2.2. Record Payload Protection 5.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 modeled as "Authenticated Encryption with Additional ciphers are modeled 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.
AEAD ciphers take as input a single key, a nonce, a plaintext, and AEAD ciphers take as input a single key, a nonce, a plaintext, and
skipping to change at page 21, line 7 skipping to change at page 21, line 19
aead-ciphered struct { aead-ciphered struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
} fragment; } fragment;
} TLSCiphertext; } TLSCiphertext;
type type
The type field is identical to TLSPlaintext.type. The type field is identical to TLSPlaintext.type.
record_version record_version
The record_version field is identical to The record_version field is identical to
TLSPlaintext.record_version and is always { 3, 1 }. TLSPlaintext.record_version and is always { 3, 1 }. Note that the
handshake protocol including the ClientHello and ServerHello
messages authenticates the protocol version, so this value is
redundant.
length length
The length (in bytes) of the following TLSCiphertext.fragment. The length (in bytes) of the following TLSCiphertext.fragment.
The length MUST NOT exceed 2^14 + 2048. The length MUST NOT exceed 2^14 + 2048.
fragment fragment
The AEAD encrypted form of TLSPlaintext.fragment. The AEAD encrypted form of TLSPlaintext.fragment.
The length of the per-record nonce (iv_length) is set to max(8 bytes, The length of the per-record nonce (iv_length) is set to max(8 bytes,
N_MIN) for the AEAD algorithm (see [RFC5116] Section 4). An AEAD N_MIN) for the AEAD algorithm (see [RFC5116] Section 4). An AEAD
skipping to change at page 22, line 31 skipping to change at page 22, line 47
additional_data) additional_data)
If the decryption fails, a fatal "bad_record_mac" alert MUST be If the decryption fails, a fatal "bad_record_mac" alert MUST be
generated. generated.
As a special case, we define the NULL_NULL AEAD cipher which is As a special case, we define the NULL_NULL AEAD cipher which is
simply the identity operation and thus provides no security. This simply the identity operation and thus provides no security. This
cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL cipher MUST ONLY be used with the initial TLS_NULL_WITH_NULL_NULL
cipher suite. cipher suite.
6.3. Key Calculation 6. The TLS Handshaking Protocols
[[OPEN ISSUE: This needs to be revised. See
https://github.com/tlswg/tls13-spec/issues/5]] The Record Protocol
requires an algorithm to generate keys required by the current
connection state (see Appendix A.5) from the security parameters
provided by the handshake protocol.
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
encryption key. Each of these is generated from the byte sequence in
that order. Unused values are empty.
When keys are generated, the current master secret (MS) is used 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
key_block = PRF(MS,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
where MS is the relevant master secret. The PRF is computed enough
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]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.iv_length]
server_write_IV[SecurityParameters.iv_length]
7. The TLS Handshaking Protocols
TLS has three subprotocols that are used to allow peers to agree upon TLS has three subprotocols that are used to allow peers to agree upon
security parameters for the record layer, to authenticate themselves, security parameters for the record layer, to authenticate themselves,
to instantiate negotiated security parameters, and to report error to instantiate negotiated security parameters, and to report error
conditions to each other. conditions to each other.
The Handshake Protocol is responsible for negotiating a session, The Handshake Protocol is responsible for negotiating a session,
which consists of the following items: which consists of the following items:
session identifier
An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
peer certificate peer certificate
X509v3 [RFC5280] certificate of the peer. This element of the X509v3 [RFC5280] 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 hash for use with HKDF to generate keying material, and the record
the record protection algorithm (See Appendix A.5 for formal protection algorithm (See Appendix A.5 for formal definition.)
definition.)
resumption premaster secret
48-byte secret shared between the client and server.
is resumable resumption master secret
A flag indicating whether the session can be used to initiate new a secret shared between the client and server that can be used as
connections. a PSK in future 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 using a PSK established in
feature of the TLS Handshake Protocol. an initial handshake.
7.1. Alert Protocol 6.1. 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 41 skipping to change at page 24, line 41
no_renegotiation(100), /* fatal */ no_renegotiation(100), /* fatal */
unsupported_extension(110), /* fatal */ unsupported_extension(110), /* fatal */
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
7.1.1. Closure Alerts 6.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
with widespread implementation practice. with widespread implementation practice.
Either party MAY initiate a close by sending a "close_notify" alert. Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored. Any data received after a closure alert is ignored. If a transport-
level close is received prior to a close_notify, the receiver cannot
know that all the data that was sent has been received.
Unless some other fatal alert has been transmitted, each party is Unless some other fatal alert has been transmitted, each party is
required to send a "close_notify" alert before closing the write side required to send a "close_notify" alert before closing the write side
of the connection. The other party MUST respond with a of the connection. The other party MUST respond with a
"close_notify" alert of its own and close down the connection "close_notify" alert of its own and close down the connection
immediately, discarding any pending writes. It is not required for immediately, discarding any pending writes. It is not required for
the initiator of the close to wait for the responding "close_notify" the initiator of the close to wait for the responding "close_notify"
alert before closing the read side of the connection. alert before closing the read side of the connection.
If the application protocol using TLS provides that any data may be If the application protocol using TLS provides that any data may be
skipping to change at page 26, line 31 skipping to change at page 25, line 33
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.1.2. Error Alerts 6.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 49 skipping to change at page 28, line 51
in response to a ClientHello after initial handshaking. Versions in response to a ClientHello after initial handshaking. Versions
of TLS prior to TLS 1.3 supported renegotiation of a previously of TLS prior to TLS 1.3 supported renegotiation of a previously
established connection; TLS 1.3 removes this feature. This established connection; TLS 1.3 removes this feature. This
message is always fatal. message is always fatal.
unsupported_extension unsupported_extension
sent by clients that receive an extended ServerHello containing an sent by clients that receive an extended ServerHello containing an
extension that they did not put in the corresponding ClientHello. extension that they did not put in the corresponding ClientHello.
This message is always fatal. 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 11.
7.2. Handshake Protocol Overview 6.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 establish shared secret
techniques to generate shared secrets. keying material.
The TLS Handshake Protocol involves the following steps: TLS supports three basic key exchange modes:
- Exchange hello messages to agree on a protocol version, - Diffie-Hellman (of both the finite field and elliptic curve
algorithms, exchange random values, and check for session varieties).
resumption.
- Exchange the necessary cryptographic parameters to allow the - A pre-shared symmetric key (PSK)
client and server to agree on a premaster secret.
- Exchange certificates and cryptographic information to allow the - A combination of a symmetric key and Diffie-Hellman
client and server to authenticate themselves.
- Generate a master secret from the premaster secret and exchanged Which mode is used depends on the negotiated cipher suite.
random values. Conceptually, the handshake establishes two secrets which are used to
derive all the keys.
- Provide security parameters to the record layer. Ephemeral Secret (ES): A secret which is derived from fresh (EC)DHE
shares for this connection. Keying material derived from ES is
intended to be forward secure (with the exception of pre-shared key
only modes).
- Allow the client and server to verify that their peer has Static Secret (SS): A secret which may be derived from static or
calculated the same security parameters and that the handshake semi-static keying material, such as a pre-shared key or the server's
occurred without tampering by an attacker. semi-static (EC)DH share.
Note that higher layers should not be overly reliant on whether TLS In some cases, as with the DH handshake shown in Figure 1, these
always negotiates the strongest possible connection between two secrets are the same, but having both allows for a uniform key
peers. There are a number of ways in which a man-in-the-middle derivation scheme for all cipher modes.
attacker can attempt to make two entities drop down to the least
secure method they support. The protocol has been designed to
minimize this risk, but there are still attacks available. For
example, an attacker could block access to the port a secure service
runs on or attempt to get the peers to negotiate an unauthenticated
connection. The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require. The
TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate AES-GCM [GCM] with a 255-bit
ECDHE key exchange with a host whose certificate chain you have
verified, you can expect that to be reasonably secure.
These goals are achieved by the handshake protocol, which can be The basic TLS Handshake for DH is shown in Figure 1:
summarized as follows: The client sends a ClientHello message which
contains a random nonce (ClientHello.random), its preferences for
Protocol Version, Cipher Suite, and a variety of extensions. In the
same flight, it sends a ClientKeyShare message which contains its
share of the parameters for key agreement for some set of expected
server parameters (DHE/ECDHE groups, etc.).
If the client has provided a ClientKeyShare with an appropriate set Client Server
of keying material, the server responds to the ClientHello with a
ServerHello message. The ServerHello contains the server's nonce
(ServerHello.random), the server's choice of the Protocol Version,
Session ID and Cipher Suite, and the server's response to the
extensions the client offered.
The server can then generate its own keying material share and send a ClientHello
ServerKeyShare message which contains its share of the parameters for + ClientKeyShare -------->
the key agreement. The server can now compute the shared secret (the ServerHello
premaster secret). At this point, the server starts encrypting all ServerKeyShare*
remaining handshake traffic with the negotiated cipher suite using a {EncryptedExtensions}
key derived from the premaster secret (via the "handshake master {ServerConfiguration*}
secret"). The remainder of the server's handshake messages will be {Certificate*}
encrypted using that key. {CertificateRequest*}
{CertificateVerify*}
<-------- {Finished}
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Following these messages, the server will send an EncryptedExtensions * Indicates optional or situation-dependent messages that are not always sent.
message which contains a response to any client's extensions which
are not necessary to establish the Cipher Suite. The server will
then send its certificate in a Certificate message if it is to be
authenticated. The server may optionally request a certificate from
the client by sending a CertificateRequest message at this point.
Finally, if the server is authenticated, it will send a
CertificateVerify message which provides a signature over the entire
handshake up to this point. This serves both to authenticate the
server and to establish the integrity of the negotiation. Finally,
the server sends a Finished message which includes an integrity check
over the handshake keyed by the shared secret and demonstrates that
the server and client have agreed upon the same keys. [[TODO: If the
server is not requesting client authentication, it MAY start sending
application data following the Finished, though the server has no way
of knowing who will be receiving the data. Add this.]]
Once the client receives the ServerKeyShare, it can also compute the {} Indicates messages protected using keys derived from the ephemeral secret.
premaster secret and decrypt the server's remaining handshake
messages. The client generates its own sending keys based on the
premaster secret and will encrypt the remainder of its handshake
messages using those keys and the newly established cipher suite. If
the server has sent a CertificateRequest message, the client MUST
send the Certificate message, though it may contain zero
certificates. If the client has sent a certificate, a digitally-
signed CertificateVerify message is sent to explicitly verify
possession of the private key in the certificate. Finally, the
client sends the Finished message.
At this point, the handshake is complete, and the client and server [] Indicates messages protected using keys derived from the master secret.
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. Figure 1: Message flow for full TLS Handshake
[[TODO: can we make this clearer and more clearly match the text
above about server-side False Start.]] Client Server
ClientHello The first message sent by the client is the ClientHello
ClientKeyShare --------> Section 6.3.1.1 which contains a random nonce (ClientHello.random),
ServerHello its offered protocol version, cipher suite, and extensions, and one
ServerKeyShare or more Diffie-Hellman key shares in the ClientKeyShare extension
{EncryptedExtensions*} Section 6.3.1.5.
{Certificate*}
{CertificateRequest*}
{CertificateVerify*}
<-------- {Finished}
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 1. Message flow for a full handshake The server processes the ClientHello and determines the appropriate
cryptographic parameters for the connection. It then responds with
the following messages:
* Indicates optional or situation-dependent messages that are not ServerHello
always sent. indicates the negotiated connection parameters. [Section 6.3.1.2]
{} Indicates messages protected using keys derived from the handshake ServerKeyShare
master secret. the server's ephemeral Diffie-Hellman Share which must be in the
same group as one of the shares offered by the client. This
message will be omitted if DH is not in use (i.e., a pure PSK
cipher suite is selected). The ClientKeyShare and ServerKeyShare
are used together to derive the Static Secret and Ephemeral Secret
(in this mode they are the same). [Section 6.3.2]
[] Indicates messages protected using keys derived from the master ServerConfiguration
secret. supplies a configuration for a future handshake (see
Section 6.2.2). [Section 6.3.6]
EncryptedExtensions
responses to any extensions which are not required in order to
determine the cryptographic parameters. [Section 6.3.3]
Certificate
the server certificate. This message will be omitted if the
server is not authenticating via a certificates. [Section 6.3.4]
CertificateRequest
if certificate-based client authentication is desired, the desired
parameters for that certificate. This message will be omitted if
client authentication is not desired. [[OPEN ISSUE: See
https://github.com/tlswg/tls13-spec/issues/184]]. [Section 6.3.5]
CertificateVerify
a signature over the entire handshake using the public key in the
Certificate message. This message will be omitted if the server
is not authenticating via a certificate. [Section 6.3.7]
Finished
a MAC over the entire handshake computed using the Static Secret.
This message provides key confirmation and In some modes (see
Section 6.2.2) it also authenticates the handshake using the the
Static Secret. [Section 6.3.8]
Upon receiving the server's messages, the client responds with his
final flight of messages:
Certificate
the client's certificate. This message will be omitted if the
client is not authenticating via a certificates. [Section 6.3.9]
CertificateVerify
a signature over the entire handshake using the public key in the
Certificate message. This message will be omitted if the client
is not authenticating via a certificate. [Section 6.3.10]
Finished
a MAC over the entire handshake computed using the Static Secret
and providing key confirmation. [Section 6.3.8]
At this point, the handshake is complete, and the client and server
may exchange application layer data. Application data MUST NOT be
sent prior to sending the Finished message. If client authentication
is requested, the server MUST NOT send application data before it
receives the client's Finished.
[[TODO: Move this elsewhere? Note that higher layers should not be
overly reliant on whether TLS always negotiates the strongest
possible connection between two peers. There are a number of ways in
which a man-in-the-middle attacker can attempt to make two entities
drop down to the least secure method they support. The protocol has
been designed to minimize this risk, but there are still attacks
available. For example, an attacker could block access to the port a
secure service runs on or attempt to get the peers to negotiate an
unauthenticated connection. The fundamental rule is that higher
levels must be cognizant of what their security requirements are and
never transmit information over a channel less secure than what they
require. The TLS protocol is secure in that any cipher suite offers
its promised level of security: if you negotiate AES-GCM [GCM] with a
255-bit ECDHE key exchange with a host whose certificate chain you
have verified, you can expect that to be reasonably "secure" against
algorithmic attacks, at least in the year 2015.]]
6.2.1. Incorrect DHE Share
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
{EncryptedExtensions*} {EncryptedExtensions*}
{Certificate*} {ServerConfiguration*}
{CertificateRequest*} {Certificate*}
{CertificateVerify*} {CertificateRequest*}
<-------- {Finished} {CertificateVerify*}
{Certificate*} <-------- {Finished}
{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: Should we restart the handshake hash? [[OPEN ISSUE: Should we restart the handshake hash?
https://github.com/tlswg/tls13-spec/issues/104.]] [[OPEN ISSUE: We 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 TLS also allows several optimized variants of the basic handshake, as
duplicate an existing session (instead of negotiating new security described below.
parameters), the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to 6.2.2. Cached Server Configuration
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
connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both
client and server MUST proceed directly to sending Finished messages,
which are protected using handshake keys as described above, computed
using resumption premaster secret created in the first handshake as
the premaster secret. Once the re-establishment is complete, the
client and server MAY begin to exchange application layer data, which
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 During an initial handshake, the server can provide a
ServerConfiguration message containing a long-term (EC)DH share. On
future connections, the client can indicate to the server that it
knows the server's configuration and if that configuration is valid
the server can omit both the Certificate or CertificateVerify message
(provided that a new configuration is not supplied in this
handshake).
ClientHello When a known configuration is used, the server's long-term DHE key is
ClientKeyExhange --------> combined with the client's ClientKeyShare to produce SS. ES is
computed as above. This optimization allows the server to amortize
the transmission of these messages and the server's signature over
multiple handshakes, thus reducing the server's computational cost
for cipher suites where signatures are slower than key agreement,
principally RSA signatures paired with ECDHE.
6.2.3. Zero-RTT Exchange
When a cached ServerConfiguration is used, the client can also send
application data as well as its Certificate and CertificateVerify (if
client authentication is requested) on its first flight, thus
reducing handshake latency, as shown below.
Client Server
ClientHello
+ ClientKeyShare
(Certificate*)
(CertificateVerify*)
(Application Data) -------->
ServerHello ServerHello
<-------- {Finished} ServerKeyShare
{Finished} --------> <-------- {Finished}
[Application Data] <-------> [Application Data] {Finished} -------->
Figure 3. Message flow for an abbreviated handshake [Application Data] <-------> [Application Data]
() Indicates messages protected using keys derived from the static secret.
Figure 3: Message flow for a zero round trip handshake
Note: because sequence numbers continue to increment between the
initial (early) application data and the application data sent after
the handshake has complete, an attacker cannot remove early
application data messages.
IMPORTANT NOTE: The security properties for 0-RTT data (regardless of
the cipher suite) are weaker than those for other kinds of TLS data.
Specifically.
1. This data is not forward secure, because it is encrypted solely
with the server's semi-static (EC)DH share.
2. There are no guarantees of non-replay between connections.
Unless the server takes special measures outside those provided
by TLS (See Section 6.3.1.5.5.1), the server has no guarantee
that the same 0-RTT data was not transmitted on multiple 0-RTT
connections. This is especially relevant if the data is
authenticated either with TLS client authentication or inside the
application layer protocol. However, 0-RTT data cannot be
duplicated within a connection (i.e., the server will not process
the same data twice for the same connection) and also cannot be
sent as if it were ordinary TLS data.
3. If the server key is compromised, and client authentication is
used, then the attacker can impersonate the client to the server
(as it knows the traffic key).
6.2.4. Resumption and PSK
Finally, TLS provides a pre-shared key (PSK) mode which allows a
client and server who share an existing secret (e.g., a key
established out of band) to establish a connection authenticated by
that key. PSKs can also be established in a previous session and
then reused ("session resumption"). Once a handshake has completed,
the server can send the client a PSK identity which corresponds to a
key derived from the initial handshake (See Section 6.3.11). The
client can then use that PSK identity in future handshakes to
negotiate use of the PSK; if the server accepts it, then the security
context of the original connection is tied to the new connection. In
TLS 1.2 and below, this functionality was provided by "session
resumption" and "session tickets" [RFC5077]. Both mechanisms are
obsoleted in TLS 1.3.
PSK ciphersuites can either use PSK in combination with an (EC)DHE
exchange in order to provide forward secrecy in combination with
shared keys, or can use PSKs alone, at the cost of losing forward
secrecy.
Figure 4 shows a pair of handshakes in which the first establishes a
PSK and the second uses it:
Client Server
Initial Handshake:
ClientHello
+ ClientKeyShare -------->
ServerHello
ServerKeyShare
{EncryptedExtensions}
{ServerConfiguration*}
{Certificate*}
{CertificateRequest*}
{CertificateVerify*}
<-------- {Finished}
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ ClientKeyShare,
PreSharedKeyExtension -------->
ServerHello
+PreSharedKeyExtension
<-------- {Finished}
{Certificate*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 4: Message flow for resumption and PSK
Note that the client supplies a ClientKeyShare to the server as well,
which allows the server to decline resumption and fall back to a full
handshake. However, because the server is authenticating via a PSK,
it does not send a Certificate or a CertificateVerify. PSK-based
resumption cannot be used to provide a new ServerConfiguration.
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.3. Handshake Protocol 6.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 or TLSCiphertext structures, which are processed and
specified by the current active session state. transmitted as specified by the current active session state.
enum { enum {
reserved(0), client_hello(1), server_hello(2), reserved(0), client_hello(1), server_hello(2),
client_key_share(5), hello_retry_request(6), session_ticket(4), hello_retry_request(6),
server_key_share(7), certificate(11), reserved(12), server_key_share(7), certificate(11), reserved(12),
certificate_request(13), certificate_verify(15), certificate_request(13), server_configuration(14),
reserved(16), finished(20), (255) certificate_verify(15), 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 client_hello: ClientHello; case client_hello: ClientHello;
case client_key_share: ClientKeyShare;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case server_key_share: ServerKeyShare; case server_key_share: ServerKeyShare;
case server_configuration:ServerConfiguration;
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;
case session_ticket: NewSessionTicket;
} 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. omitted, however.
New handshake message types are assigned by IANA as described in New handshake message types are assigned by IANA as described in
Section 12. Section 11.
7.3.1. Hello Messages 6.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. initialized to NULL_NULL.
7.3.1.1. Client Hello 6.3.1.1. Client Hello
When this message will be sent: When this message will be sent:
When a client first connects to a server, it is required to send When a client first connects to a server, it is required to send
the ClientHello as its first message. The client will also send a the ClientHello as its first message. The client will also send a
ClientHello when the server has responded to its ClientHello with ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare. In that case, the client MUST match the client's ClientKeyShare. In that case, the client MUST
send the same ClientHello (without modification) along with the send the same ClientHello (without modification) except including
new ClientKeyShare. If a server receives a ClientHello at any a new ClientKeyShare. [[OPEN ISSUE: New random values? See:
other time, it MUST send a fatal "no_renegotiation" alert. https://github.com/tlswg/tls13-spec/issues/185]] If a server
receives a ClientHello at any other time, it MUST send a fatal
"no_renegotiation" alert.
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;
random_bytes random_bytes
32 bytes generated by a secure random number generator. 32 bytes generated by a secure random number generator.
Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the
Random value to encode the time since the UNIX epoch. Random value to encode the time since the UNIX epoch.
Note: The ClientHello message includes a variable-length session
identifier. If not empty, the value identifies a session between the
same client and server whose security parameters the client wishes to
reuse. The session identifier MAY be from an earlier connection,
this connection, or from another currently active connection. The
second option is useful if the client only wishes to update the
random structures and derived values of a connection, and the third
option makes it possible to establish several independent secure
connections without repeating the full handshake protocol. These
independent connections may occur sequentially or simultaneously; a
SessionID becomes valid when the handshake negotiating it completes
with the exchange of Finished messages and persists until it is
removed due to aging or because a fatal error was encountered on a
connection associated with the session. The actual contents of the
SessionID are defined by the server.
opaque SessionID<0..32>;
Warning: Because the SessionID is transmitted without confidentiality
or integrity protection, servers MUST NOT place confidential
information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the
handshake.)
The cipher suite list, passed from the client to the server in the The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's algorithms supported by the client in order of the client's
preference (favorite choice first). Each cipher suite defines a key preference (favorite choice first). Each cipher suite defines a key
exchange algorithm, a record protection algorithm (including secret exchange algorithm, a record protection algorithm (including secret
key length) and a PRF. The server will select a cipher suite or, if key length) and a hash to be used with HKDF. The server will select
no acceptable choices are presented, return a "handshake_failure" a cipher suite or, if no acceptable choices are presented, return a
alert and close the connection. If the list contains cipher suites "handshake_failure" alert and close the connection. If the list
the server does not recognize, support, or wish to use, the server contains cipher suites the server does not recognize, support, or
MUST ignore those cipher suites, and process the remaining ones as wish to use, the server MUST ignore those cipher suites, and process
usual. the remaining ones as usual.
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */ ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
skipping to change at page 38, line 4 skipping to change at page 39, line 42
The version of the TLS protocol by which the client wishes to The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this (highest valued) version supported by the client. For this
version of the specification, the version will be 3.4. (See version of the specification, the version will be 3.4. (See
Appendix D for details about backward compatibility.) Appendix D for details about backward compatibility.)
random random
A client-generated random structure. A client-generated random structure.
session_id session_id
The ID of a session the client wishes to use for this connection. Versions of TLS prior to TLS 1.3 supported a session resumption
This field is empty if no session_id is available, or if the feature which has been merged with Pre-Shared Keys in this version
client wishes to generate new security parameters. (see Section 6.2.4). This field MUST be ignored by a server
negotiating TLS 1.3 and should be set as a zero length vector
(i.e., a single zero byte length field) by clients which do not
have a cached session_id set by a pre-TLS 1.3 server.
cipher_suites cipher_suites
This is a list of the cryptographic options supported by the This is a list of the cryptographic options supported by the
client, with the client's first preference first. If the client, with the client's first preference first. Values are
session_id field is not empty (implying a session resumption defined in Appendix A.4.
request), this vector MUST include at least the cipher_suite from
that session. Values are defined in Appendix A.4.
compression_methods compression_methods
Versions of TLS before 1.3 supported compression and the list of Versions of TLS before 1.3 supported compression and the list of
compression methods was supplied in this field. For any TLS 1.3 compression methods was supplied in this field. For any TLS 1.3
ClientHello, this field MUST contain only the "null" compression ClientHello, this field MUST contain only the "null" compression
method with the code point of 0. If a TLS 1.3 ClientHello is method with the code point of 0. If a TLS 1.3 ClientHello is
received with any other value in this field, the server MUST received with any other value in this field, the server MUST
generate a fatal "illegal_parameter" alert. Note that TLS 1.3 generate a fatal "illegal_parameter" alert. Note that TLS 1.3
servers may receive TLS 1.2 or prior ClientHellos which contain servers may receive TLS 1.2 or prior ClientHellos which contain
other compression methods and MUST follow the procedures for the other compression methods and MUST follow the procedures for the
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.3.2.5. defined in Section 6.3.1.4.
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 or HelloRetryRequest message. ServerHello or HelloRetryRequest message.
7.3.2. Client Key Share 6.3.1.2. Server Hello
When this message will be sent:
This message is always sent by the client. It MUST immediately
follow the ClientHello message. In backward compatibility mode
(see Section XXX) it will be included in the EarlyData extension
(Section 7.3.2.5.3) in the ClientHello.
Meaning of this message:
This message contains the client's cryptographic parameters for
zero or more key establishment methods.
Structure of this message:
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer;
group
The named group for the key share offer. This identifies the
specific key exchange method that the ClientKeyShareOffer
describes. Finite Field Diffie-Hellman [DH] parameters are
described in Section 7.3.2.1; Elliptic Curve Diffie-Hellman
parameters are described in Section 7.3.2.2.
key_exchange
Key exchange information. The contents of this field are
determined by the value of NamedGroup entry and its corresponding
definition.
struct {
ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare;
offers
A list of ClientKeyShareOffer values.
Clients may offer an arbitrary number of ClientKeyShareOffer values,
each representing a single set of key agreement parameters; for
instance a client might offer shares for several elliptic curves or
multiple integer DH groups. The shares for each ClientKeyShareOffer
MUST by generated independently. Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters. It is explicitly
permitted to send an empty ClientKeyShare message, as this is used to
elicit the server's parameters if the client has no useful
information. [TODO: Recommendation about what the client offers.
Presumably which integer DH groups and which curves.] [TODO: Work
out how this interacts with PSK and SRP.]
7.3.2.1. Diffie-Hellman Parameters
Diffie-Hellman [DH] parameters for both clients and servers are
encoded in the opaque key_exchange field of the ClientKeyShareOffer
or ServerKeyShare structures. The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer.
opaque dh_Y<1..2^16-1>;
7.3.2.2. ECDHE Parameters
ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point.
opaque point <1..2^8-1>;
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
[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
point issue if we have new curves that don't need point compression.
This depends on the CFRG's recommendations. The expectation is that
future curves will come with defined point formats and that existing
curves conform to X9.62.]]
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 extension 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:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; uint8 session_id_len; // Must be 0.
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
} ServerHello; } ServerHello;
The presence of extensions can be detected by determining whether The presence of extensions can be detected by determining whether
skipping to change at page 41, line 32 skipping to change at page 41, line 32
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 ClientHello and the highest supported by the server. For in the ClientHello 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 D for details about backward compatibility.) Appendix D for details about backward compatibility.)
random random
This structure is generated by the server and MUST be generated This structure is generated by the server and MUST be generated
independently of the ClientHello.random. independently of the ClientHello.random.
session_id session_id_len
This is the identity of the session corresponding to this A single 0 value for backward compatible formatting. [[OPEN
connection. If the ClientHello.session_id was non-empty, the ISSUE: Should we remove?]]
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
using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed
directly to the Finished messages. Otherwise, this field will
contain a different value identifying the new session. The server
may return an empty session_id to indicate that the session will
not be cached and therefore cannot be resumed. If a session is
resumed, it must be resumed using the same cipher suite it was
originally negotiated with. Note that there is no requirement
that the server resume any session even if it had formerly
provided a session_id. Clients MUST be prepared to do a full
negotiation -- including negotiating new cipher suites -- during
any handshake.
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. [[TODO:
interaction with PSK.]]
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.3.4 between the ServerHello and the EncryptedExtensions Section 6.3.3
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.3.2.4. Hello Retry Request 6.3.1.3. Hello Retry Request
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 and groups that are mutually supported, but the client's
acceptable offer. If it cannot find such a match, it will respond ClientKeyShare did not contain an acceptable offer. If it cannot
with a "handshake_failure" alert. find such a match, it will respond with a "handshake_failure"
alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
NamedGroup selected_group; NamedGroup selected_group;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
[[OPEN ISSUE: Merge in DTLS Cookies?]] [[OPEN ISSUE: Merge in DTLS Cookies?]]
selected_group selected_group
The group which the client MUST use for its new ClientHello. The group which the client MUST use for its new ClientHello.
The "server_version", "cipher_suite" and "extensions" fields have the The "server_version", "cipher_suite" and "extensions" fields have the
same meanings as their corresponding values in the ServerHello. The same meanings as their corresponding values in the ServerHello. The
server SHOULD send only the extensions necessary for the client to server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello/ClientKeyShare pair. generate a correct ClientHello pair.
Upon receipt of a HelloRetryRequest, the client MUST send a new Upon receipt of a HelloRetryRequest, the client MUST first verify
ClientHello/ClientKeyShare pair to the server. The ClientKeyShare that the "selected_group" field does not identify a group which was
MUST contain both the groups in the original ClientKeyShare as well not in the original ClientHello. If it was present, then the client
as a ClientKeyShareOffer consistent with the "selected_group" field. MUST abort the handshake with a fatal "handshake_failure" alert.
I.e., it MUST be a superset of the previous ClientKeyShareOffer. Clients SHOULD also abort with "handshake_failure" in response to any
second HelloRetryRequest which was sent in the same connection (i.e.,
where the ClientHello was itself in response to a HelloRetryRequest).
Upon re-sending the ClientHello/ClientKeyShare and receiving the Otherwise, the client MUST send a ClientHello with a new
server's ServerHello/ServerKeyShare, the client MUST verify that the ClientKeyShare extension to the server. The ClientKeyShare MUST
selected CipherSuite and NamedGroup match that supplied in the append a new ClientKeyShareOffer which is consistent with the
"selected_group" field to the groups in the original ClientKeyShare.
Upon re-sending the ClientHello and receiving the server's
ServerHello/ServerKeyShare, the client MUST verify that the selected
CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest. HelloRetryRequest.
7.3.2.5. Hello Extensions 6.3.1.4. 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),
supported_groups(TBD),
known_configuration(TBD),
pre_shared_key(TBD)
client_key_shares(TBD)
(65535)
} ExtensionType; } ExtensionType;
Here: Here:
- "extension_type" identifies the particular extension type. - "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular - "extension_data" contains information specific to the particular
extension type. extension type.
The initial set of extensions is defined in [RFC6066]. The list of The initial set of extensions is defined in [RFC6066]. The list of
extension types is maintained by IANA as described in Section 12. extension types is maintained by IANA as described in Section 11.
An extension type MUST NOT appear in the ServerHello unless the same An extension type MUST NOT appear in the ServerHello or
extension type appeared in the corresponding ClientHello. If a HelloRetryRequest unless the same extension type appeared in the
client receives an extension type in ServerHello that it did not corresponding ClientHello. If a client receives an extension type in
request in the associated ClientHello, it MUST abort the handshake ServerHello or HelloRetryRequest that it did not request in the
with an "unsupported_extension" fatal alert. associated ClientHello, it MUST abort the handshake with an
"unsupported_extension" fatal alert.
Nonetheless, "server-oriented" extensions may be provided in the Nonetheless, "server-oriented" extensions may be provided in the
future within this framework. Such an extension (say, of type x) future within this framework. Such an extension (say, of type x)
would require the client to first send an extension of type x in a would require the client to first send an extension of type x in a
ClientHello with empty extension_data to indicate that it supports ClientHello with empty extension_data to indicate that it supports
the extension type. In this case, the client is offering the the extension type. In this case, the client is offering the
capability to understand the extension type, and the server is taking capability to understand the extension type, and the server is taking
the client up on its offer. the client up on its offer.
When multiple extensions of different types are present in the When multiple extensions of different types are present in the
ClientHello or ServerHello messages, the extensions MAY appear in any ClientHello or ServerHello messages, the extensions MAY appear in any
order. There MUST NOT be more than one extension of the same type. order. There MUST NOT be more than one extension of the same type.
Finally, note that extensions can be sent both when starting a new Finally, note that extensions can be sent both when starting a new
session and when requesting session resumption. Indeed, a client session and when requesting session resumption or 0-RTT mode.
that requests session resumption does not in general know whether the Indeed, a client that requests session resumption does not in general
server will accept this request, and therefore it SHOULD send the know whether the server will accept this request, and therefore it
same extensions as it would send if it were not attempting SHOULD send the same extensions as it would send if it were not
resumption. attempting resumption.
In general, the specification of each extension type needs to In general, the specification of each extension type needs to
describe the effect of the extension both during full handshake and describe the effect of the extension both during full handshake and
session resumption. Most current TLS extensions are relevant only session resumption. Most current TLS extensions are relevant only
when a session is initiated: when an older session is resumed, the when a session is initiated: when an older session is resumed, the
server does not process these extensions in ClientHello, and does not server does not process these extensions in ClientHello, and does not
include them in ServerHello. However, some extensions may specify include them in ServerHello. However, some extensions may specify
different behavior during session resumption. different behavior during session resumption. [[TODO: update this
and the previous paragraph to cover PSK-based resumption.]]
There are subtle (and not so subtle) interactions that may occur in There are subtle (and not so subtle) interactions that may occur in
this protocol between new features and existing features which may this protocol between new features and existing features which may
result in a significant reduction in overall security. The following result in a significant reduction in overall security. The following
considerations should be taken into account when designing new considerations should be taken into account when designing new
extensions: extensions:
- Some cases where a server does not agree to an extension are error - Some cases where a server does not agree to an extension are error
conditions, and some are simply refusals to support particular conditions, and some are simply refusals to support particular
features. In general, error alerts should be used for the former, features. In general, error alerts should be used for the former,
skipping to change at page 45, line 5 skipping to change at page 45, 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.3.2.5.1. Signature Algorithms 6.3.1.4.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 45, line 48 skipping to change at page 45, 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.3.3. It MUST NOT appear in this extension. Section 6.3.2. 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.3.5 and Section 7.3.3 describe the appropriate algorithms. Section 6.3.4 and Section 6.3.2 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 46, line 37 skipping to change at page 46, line 37
Note: This extension is not meaningful for TLS versions prior to 1.2. Note: This extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions. Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in However, even if clients do offer it, the rules specified in
[RFC6066] require servers to ignore extensions they do not [RFC6066] require servers to ignore extensions they do not
understand. 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 6.3.1.4.2. Negotiated Groups
ServerHello, and the server ignores the extension in ClientHello (if
present).
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 48, line 30 skipping to change at page 48, line 26
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.3.2.5.3. Early Data Extension 6.3.1.5. Client Key Share
TLS versions before 1.3 have a strict message ordering and do not The client_key_share extension MUST be provided by the client if it
permit additional messages to follow the ClientHello. The EarlyData offers any cipher suites that involve non-PSK (currently DHE or
extension allows TLS messages which would otherwise be sent as ECDHE) key exchange. It contains the client's cryptographic
separate records to be instead inserted in the ClientHello. The parameters for zero or more key establishment methods. [[OPEN ISSUE:
extension simply contains the TLS records which would otherwise have Would it be better to omit it if it's empty?.
been included in the client's first flight. https://github.com/tlswg/tls13-spec/issues/190]]
Meaning of this message:
struct { struct {
TLSCipherText messages<5 .. 2^24-1>; NamedGroup group;
} EarlyDataExtension; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer;
Extra messages for the client's first flight MAY either be group
transmitted standalone or sent as EarlyData. However, when a client The named group for the key share offer. This identifies the
does not know whether TLS 1.3 can be negotiated - e.g., because the specific key exchange method that the ClientKeyShareOffer
server may support a prior version of TLS or because of network describes. Finite Field Diffie-Hellman [DH] parameters are
intermediaries - it SHOULD use the EarlyData extension. If the described in Section 6.3.1.5.1; Elliptic Curve Diffie-Hellman
EarlyData extension is used, then clients MUST NOT send any messages parameters are described in Section 6.3.1.5.2.
other than the ClientHello in their initial flight.
Any data included in EarlyData is not integrated into the handshake key_exchange
hashes directly. E.g., if the ClientKeyShare is included in Key exchange information. The contents of this field are
EarlyData, then the handshake hashes consist of ClientHello + determined by the value of NamedGroup entry and its corresponding
ServerHello, etc. However, because the ClientKeyShare is in a definition.
ClientHello extension, it is still hashed transitively. This
procedure guarantees that the Finished message covers these messages
even if they are ultimately ignored by the server (e.g., because it
is sent to a TLS 1.2 server). TLS 1.3 servers MUST understand
messages sent in EarlyData, and aside from hashing them differently,
MUST treat them as if they had been sent immediately after the
ClientHello.
Servers MUST NOT send the EarlyData extension. Negotiating TLS 1.3 struct {
serves as acknowledgment that it was processed as described above. ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare;
[[OPEN ISSUE: This is a fairly general mechanism which is possibly offers
overkill in the 1-RTT case, where it would potentially be more A list of ClientKeyShareOffer values in descending order of client
attractive to just have a "ClientKeyShare" extension. However, for preference.
the 0-RTT case we will want to send the Certificate,
CertificateVerify, and application data, so a more general extension
seems appropriate at least until we have determined we don't need it
for 0-RTT.]]
7.3.3. Server Key Share Clients may offer an arbitrary number of ClientKeyShareOffer values,
each representing a single set of key agreement parameters; for
instance a client might offer shares for several elliptic curves or
multiple integer DH groups. The shares for each ClientKeyShareOffer
MUST by generated independently. Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters. It is explicitly
permitted to send an empty client_key_share extension as this is used
to elicit the server's parameters if the client has no useful
information. [TODO: Recommendation about what the client offers.
Presumably which integer DH groups and which curves.]
6.3.1.5.1. Diffie-Hellman Parameters
Diffie-Hellman [DH] parameters for both clients and servers are
encoded in the opaque key_exchange field of the ClientKeyShareOffer
or ServerKeyShare structures. The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer.
opaque dh_Y<1..2^16-1>;
6.3.1.5.2. ECDHE Parameters
ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point.
opaque point <1..2^8-1>;
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
[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
point issue if we have new curves that don't need point compression.
This depends on the CFRG's recommendations. The expectation is that
future curves will come with defined point formats and that existing
curves conform to X9.62.]]
6.3.1.5.3. Known Configuration Extension
The known_configuration extension allows the client to indicate that
it wishes to reuse the server's known configuration and semi-static
(EC)DHE key (see Section 6.3.6 for how to establish these
configurations. This extension allows the omission of the server
certificate and signature, with three potential benefits:
- Shortening the handshake because the certificate may be large.
- Reducing cryptographic burden on the server if the server has an
RSA certificate, as well as on the client if the server has an
ECDSA certificate.
- Allowing the client and server to do a 0-RTT exchange (See
Section 6.2.3)
The extension is defined as:
struct {
select (Role) {
case client:
opaque identifier<0..2^16-1>;
case server:
struct {};
}
} KnownConfigurationExtension
identifier
An opaque label for the configuration in question.
A client which wishes to reuse a known configuration MAY supply a
single KnownConfigurationExtension value which indicates the known
configuration it desires to use. It is a fatal error to supply more
than one extension. A server which wishes to use the key replies
with an empty extension (i.e., with a length field of 0) in its
ServerHello.
When the client and server mutually agree upon a known configuration
via this mechanism, then the Static Secret (SS) is computed based on
the server's (EC)DHE key from the identified configuration and the
client's key found in the ClientKeyShare. If no key from an
acceptable group is in the ClientKeyShare, the server MUST ignore the
known_configuration extension. When this mechanism is used, the
server MUST NOT send a Certificate/CertificateVerify message unless
the ServerConfiguration message is also sent.
When the known_configuration data extension is in use, the handshake
hash is extended to include the server's configuration data and
certificate (see Section 7.2.1) so as to tightly bind them together.
6.3.1.5.4. Pre-Shared Key Extension
The pre_shared_key extension is used to indicate the identity of the
pre-shared key to be used with a given handshake in association with
a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).
opaque psk_identity<0..2^16-1>;
struct {
select (Role) {
case client:
psk_identity identities<0..2^16-1>;
case server:
psk_identity identity;
} PreSharedKeyExtension;
identifier
An opaque label for the pre-shared key.
When the client offers a PSK cipher suite, it MUST also supply a
PreSharedKeyExtension to indicate the PSK(s) to be used. If no such
extension is present, the server MUST NOT negotiate a PSK cipher
suite. If no suitable identity is present, the server MUST NOT
negotiate a PSK cipher suite.
If the server selects a PSK cipher suite, it MUST send a
PreSharedKeyExtension with the identity that it selected. The client
MUST verify that the server has selected one of the identities that
the client supplied. If any other identity is returned, the client
MUST generate a fatal "handshake_failure" alert.
6.3.1.5.5. Early Data Indication
In cases where TLS clients have previously interacted with the server
and the server has supplied a known configuration, the client can
send application data and its Certificate/CertificateVerify messages
(if client authentication is required). If the client opts to do so,
it MUST supply an Early Data Indication extension. This technique
MUST only be used along with the "known_configuration" extension.
enum { early_handshake(1), early_data(2),
early_handshake_and_data(3), (255) } EarlyDataType;
struct {
select (Role) {
case client:
opaque context<0..255>;
EarlyDataType type;
case server:
struct {};
}
} EarlyDataIndication;
context
An optional context value that can be used for anti-replay (see
below).
type
The type of early data that is being sent. "early_handshake" means
that only handshake data is being sent. "early_data" means that
only data is being sent. "early_handshake_and_data" means that
both are being sent.
If TLS client authentication is being used, then either
"early_handshake" or "early_handshake_and_data" MUST be indicated in
order to send the client authentication data on the first flight. In
either case, the client Certificate and CertificateVerify (assuming
that the Certificate is non-empty) MUST be sent on the first flight A
server which receives an initial flight with only "early_data" and
which expects certificate-based client authentication MUST not accept
early data.
In order to allow servers to readily distinguish between messages
sent in the first flight and in the second flight (in cases where the
server does not accept the EarlyDataIndication extension), the client
MUST send the handshake messages as content type "early_handshake".
A server which does not accept the extension proceeds by skipping all
records after the ClientHello and until the next client message of
type "handshake". [[OPEN ISSUE: This relies on content types not
being encrypted. If we had content types that were encrypted, this
would basically require trial decryption.]]
A server which receives an EarlyDataIndication extension can behave
in one of two ways:
- Ignore the extension and return no response. This indicates that
the server has ignored any early data and an ordinary 1-RTT
handshake is required.
- Return an empty extension, indicating that it intends to process
the early data. It is not possible for the server to accept only
a subset of the early data messages.
The server MUST first validate that the client's
"known_configuration" extension is valid and that the client has
suppled a valid key share in the "client_key_shares" extension. If
not, it MUST ignore the extension and discard the early handshake
data and early data.
[[TODO: How does the client behave if the indication is rejected.]]
[[OPEN ISSUE: This just specifies the signaling for 0-RTT but not the
the 0-RTT cryptographic transforms, including:
- What is in the handshake hash (including potentially some
speculative data from the server.)
- What is signed in the client's CertificateVerify
- Whether we really want the Finished to not include the server's
data at all.
What's here now needs a lot of cleanup before it is clear and
correct.]]
[[TODO: We should really allow early_data to be used with PSKs. In
order to make this work, we need to either:
(a) explicitly signal the entire cryptographic parameter set (b) tie
it to the PSK identifier (as is presently done in the
known_configuration extension).
These two should match. ]]
6.3.1.5.5.1. Replay Properties
As noted in Section 6.2.3, TLS does not provide any inter-connection
mechanism for replay protection for data sent by the client in the
first flight. As a special case, implementations where the server
configuration, is delivered out of band (as has been proposed for
DTLS-SRTP [RFC5763]), MAY use a unique server configuration
identifier for each connection, thus preventing replay.
Implementations are responsible for ensuring uniqueness of the
identifier in this case.
6.3.2. Server Key Share
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 extension
is compatible with the selected cipher suite and group parameters. which 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
to compute the premaster secret: a Diffie-Hellman public key with to compute a shared secret secret: a Diffie-Hellman public key
which the client can complete a key exchange (with the result with which the client can complete a key exchange (with the result
being the premaster secret) or a public key for some other being the shared secret) or a public key for some other algorithm.
algorithm.
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 group
The named group for the key share offer. This identifies the 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
(Section 7.3.2), identifying which value from the (Section 6.3.1.5), 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
Key exchange information. The contents of this field are Key exchange information. The contents of this field are
determined by the value of NamedGroup entry and its corresponding determined by the value of NamedGroup entry and its corresponding
definition. definition.
7.3.4. Encrypted Extensions 6.3.3. 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 ServerKeyShare. server's ServerKeyShare. This is the first message that is
encrypted under keys derived from ES.
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 50, line 41 skipping to change at page 55, 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.3.5. Server Certificate 6.3.4. 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 except DH_anon and PSK), unless the KnownKeyExtension is used.
either the EncryptedExtensions message if one is sent or the This message will always immediately follow either the
ServerKeyShare message. EncryptedExtensions message if one is sent or the 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 52, line 28 skipping to change at page 57, line 28
key exchange message. key exchange message.
ECDHE_ECDSA ECDSA-capable public key; the certificate MUST ECDHE_ECDSA ECDSA-capable public key; the certificate MUST
allow the key to be used for signing with the allow the key to be used for signing with the
hash algorithm that will be employed in the hash algorithm that will be employed in the
server key exchange message. The public key server key exchange message. The public key
MUST use a curve and point format supported by MUST use a curve and point format supported by
the client, as described in [RFC4492]. the client, as described in [RFC4492].
- The "server_name" and "trusted_ca_keys" extensions [RFC6066] are - The "server_name" and "trusted_ca_keys" extensions [RFC6066] are
used to guide certificate selection. used to guide certificate selection. As servers MAY require the
presence of the server_name extension, clients SHOULD send this
extension.
If the client provided a "signature_algorithms" extension, then all If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a hash/ certificates provided by the server MUST be signed by a hash/
signature algorithm pair that appears in that extension. Note that signature algorithm pair that appears in that extension. Note that
this implies that a certificate containing a key for one signature this implies that a certificate containing a key for one signature
algorithm MAY be signed using a different signature algorithm (for algorithm MAY be signed using a different signature algorithm (for
instance, an RSA key signed with a DSA key). instance, an RSA key signed with a DSA key).
If the server has multiple certificates, it chooses one of them based If the server has multiple certificates, it chooses one of them based
on the above-mentioned criteria (in addition to other criteria, such on the above-mentioned criteria (in addition to other criteria, such
skipping to change at page 53, line 5 skipping to change at page 58, line 9
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.3.6. Certificate Request 6.3.5. 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 54, line 33 skipping to change at page 59, line 37
signed with RSA and containing a static DH key. In TLS 1.2, this signed with RSA and containing a static DH key. In TLS 1.2, this
functionality has been obsoleted by the functionality has been obsoleted by the
supported_signature_algorithms, and the certificate type no longer supported_signature_algorithms, and the certificate type no longer
restricts the algorithm used to sign the certificate. For restricts the algorithm used to sign the certificate. For
example, if the server sends dss_fixed_dh certificate type and example, if the server sends dss_fixed_dh certificate type and
{{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
with a certificate containing a static DH key, signed with RSA- with a certificate containing a static DH key, signed with RSA-
SHA1. SHA1.
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 12. Section 11.
Note: Values listed as RESERVED MUST NOT be used. They were used in Note: Values listed as RESERVED MUST NOT be used. They were used in
SSL 3.0. SSL 3.0.
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.3.7. Server Certificate Verify 6.3.6. Server Configuration
When this message will be sent:
This message is used to provide a server configuration which the
client can use in future to skip handshake negotiation and
(optionally) to allow 0-RTT handshakes. The ServerConfiguration
message is sent as the last message before the CertificateVerify.
Structure of this Message:
struct {
opaque configuration_id<1..2^16-1>;
uint32 expiration_date;
NamedGroup group;
opaque server_key<1..2^16-1>;
Boolean early_data_allowed;
} ServerConfiguration;
configuration_id
The configuration identifier to be used with the known
configuration extension Section 6.3.1.5.3.
group
The group for the long-term DH key that is being established for
this configuration.
expiration_date
The last time when this configuration is expected to be valid (in
seconds since the Unix epoch). Servers MUST NOT use any value
more than 604800 seconds (7 days) in the future. Clients MUST not
cache configurations for longer than 7 days, regardless of the
expiration_date. [[OPEN ISSUE: Is this the right value? The idea
is just to minimize exposure.]]
server_key
The long-term DH key that is being established for this
configuration.
early_data_allowed
Whether the client may send data in its first flight (see
Section 6.3.1.5.5).
The semantics of this message are to establish a shared state between
the client and server for use with the "known_configuration"
extension with the key specified in key and with the handshake
parameters negotiated by this handshake. [[OPEN ISSUE: Should this
allow some sort of parameter negotiation?]]
When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if
the "known_configuration" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by
the client.
6.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 and possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point. This also provides integrity for the handshake up to this point. This
message is only sent when the server is authenticated via a message is only sent when the server is authenticated via a
certificate. When sent, it MUST be the last server handshake certificate. When sent, it MUST be the last server handshake
message prior to the Finished. message prior to the Finished.
Structure of this message: Structure of this message:
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_messages_hash[hash_length]; opaque handshake_hash[hash_length];
} }
} CertificateVerify; } CertificateVerify;
Here handshake_messages_hash is a digest of all handshake messages Where session_hash is as described in {{the-handshake-hash} and
sent or received, starting at ClientHello and up to, but not includes the messages sent or received, starting at ClientHello
including, this message, including the type and length fields of and up to, but not including, this message, including the type and
the handshake messages. This is a digest of the concatenation of length fields of the handshake messages. This is a digest of the
all the Handshake structures (as defined in Section 7.3) exchanged concatenation of all the Handshake structures (as defined in
thus far. For the PRF defined in Section 5, the digest MUST be Section 6.3) exchanged thus far. The digest MUST be the Hash used
the Hash used as the basis for the PRF. Any cipher suite which as the basis for HKDF.
defines a different PRF MUST also define the Hash to use in this
computation. Note that this is the same running hash that is used
in the Finished message Section 7.3.8.
The context string for the signature is "TLS 1.3, server The context string for the signature is "TLS 1.3, server
CertificateVerify". A hash of the handshake messages is signed CertificateVerify". A hash of the handshake messages is signed
rather than the messages themselves because the digitally-signed rather than the messages themselves because the digitally-signed
format requires padding and context bytes at the beginning of the format requires padding and context bytes at the beginning of the
input. Thus, by signing a digest of the messages, an input. Thus, by signing a digest of the messages, an
implementation need only maintain one running hash per hash type implementation need only maintain one running hash per hash type
for CertificateVerify, Finished and other messages. for CertificateVerify, Finished and other messages.
If the client has offered the "signature_algorithms" extension, If the client has offered the "signature_algorithms" extension,
skipping to change at page 56, line 8 skipping to change at page 62, line 18
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 [RFC5280] may specify key size. In addition, future revisions of [RFC5280] 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.3.8. Server Finished 6.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 is essential for providing authentication of the server
processes were successful. side of the handshake and computed keys.
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. This data send and receive application data over the connection. This data
will be protected under keys derived from the hs_master_secret will be protected under keys derived from the ephemeral secret
(see Section 8). (see Section 7).
Structure of this message: Structure of this message:
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
The verify_data value is computed as follows:
verify_data verify_data
PRF(hs_master_secret, finished_label, Hash(handshake_messages)) HMAC(finished_secret, finished_label + '\0' + handshake_hash)
[0..verify_data_length-1]; where HMAC uses the Hash algorithm for the handshake. See
Section 7.2.1 for the definition of handshake_hash.
finished_label finished_label
For Finished messages sent by the client, the string "client For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the string finished". For Finished messages sent by the server, the string
"server finished". "server finished".
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
for the PRF. Any cipher suite which defines a different PRF MUST
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 is the size of the HMAC
suite. Any cipher suite which does not explicitly specify output for the Hash used for the handshake.
verify_data_length has a verify_data_length equal to 12. This
includes all existing cipher suites. Note that this
representation has the same encoding as with previous versions.
Future cipher suites MAY specify other lengths but such length
MUST be at least 12 bytes.
handshake_messages
All of the data from all messages in this handshake (not including
any HelloRequest messages) up to, but not including, this message.
This is only data visible at the handshake layer and does not
include record layer headers. This is the concatenation of all
the Handshake structures as defined in Section 7.3, exchanged thus
far.
The value handshake_messages includes all handshake messages starting
at ClientHello up to, but not including, this Finished message. This
may be different from handshake_messages in Section 7.3.7 or
Section 7.3.10. Also, the handshake_messages for the Finished
message sent by the client will be different from that for the
Finished message sent by the server, because the one that is sent
second will include the prior one.
Note: Alerts and any other record types are not handshake messages Note: Alerts and any other record types are not handshake messages
and are not included in the hash computations. Also, HelloRequest and are not included in the hash computations. Also, HelloRequest
messages are omitted from handshake hashes. messages and the Finished message are omitted from handshake hashes.
The input to the client and server Finished messages may not be the
same because the server's Finished does not include the client's
Certificate and CertificateVerify message.
7.3.9. Client Certificate 6.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. This message is only sent after receiving the server's Finished. This message is only sent
if the server requests a certificate. If no suitable certificate if the server requests a certificate. If no suitable certificate
is available, the client MUST send a certificate message is available, the client MUST send a certificate message
containing no certificates. That is, the certificate_list containing no certificates. That is, the certificate_list
structure has a length of zero. If the client does not send any structure has a length of zero. If the client does not send any
certificates, the server MAY at its discretion either continue the certificates, the server MAY at its discretion either continue the
handshake without client authentication, or respond with a fatal handshake without client authentication, or respond with a fatal
"handshake_failure" alert. Also, if some aspect of the "handshake_failure" alert. Also, if some aspect of the
certificate chain was unacceptable (e.g., it was not signed by a certificate chain was unacceptable (e.g., it was not signed by a
known, trusted CA), the server MAY at its discretion either known, trusted CA), the server MAY at its discretion either
continue the handshake (considering the client unauthenticated) or continue the handshake (considering the client unauthenticated) or
send a fatal alert. send a fatal alert.
Client certificates are sent using the Certificate structure Client certificates are sent using the Certificate structure
defined in Section 7.3.5. defined in Section 6.3.4.
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). The
calculating the premaster secret (for non-ephemeral Diffie- certificate MUST be appropriate for the negotiated cipher suite's
Hellman). The certificate MUST be appropriate for the negotiated key exchange algorithm, and any negotiated extensions.
cipher suite's key exchange algorithm, and any negotiated
extensions.
In particular: In particular:
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly - The certificate type MUST be X.509v3 [RFC5280], unless explicitly
negotiated otherwise (e.g., [RFC5081]). negotiated otherwise (e.g., [RFC5081]).
- The end-entity certificate's public key (and associated - The end-entity certificate's public key (and associated
restrictions) has to be compatible with the certificate types restrictions) has to be compatible with the certificate types
listed in CertificateRequest: listed in CertificateRequest:
skipping to change at page 59, line 6 skipping to change at page 64, line 36
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.3.6. Note signature algorithm pair, as described in Section 6.3.5. 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.3.10. Client Certificate Verify 6.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.3.7, except that the context string is "TLS 1.3, client Section 6.3.7, except that the context string is "TLS 1.3, client
CertificateVerify". 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
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 [RFC5280] may specify key size. In addition, future revisions of [RFC5280] may specify
mechanisms for certificates to indicate which digest algorithms mechanisms for certificates to indicate which digest algorithms
are to be used with DSA. are to be used with DSA.
8. Cryptographic Computations 6.3.11. New Session Ticket Message
After the server has received the client Finished message, it MAY
send a NewSessionTicket message. This message MUST be sent before
the server sends any application data traffic, and is encrypted under
the application traffic key. This message creates a pre-shared key
(PSK) binding between the resumption master secret and the ticket
label. The client MAY use this PSK for future handshakes by
including it in the pre_shared_key extension in its ClientHello
(Section 6.3.1.5.4) and supplying a suitable PSK cipher suite.
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
ticket_lifetime_hint
Indicates the lifetime in seconds as a 32-bit unsigned integer in
network byte order. A value of zero is reserved to indicate that
the lifetime of the ticket is unspecified.
ticket
The value of the ticket to be used as the PSK identifier.
The ticket lifetime hint is informative only. A client SHOULD delete
the ticket and associated state when the time expires. It MAY delete
the ticket earlier based on local policy. A server MAY treat a
ticket as valid for a shorter or longer period of time than what is
stated in the ticket_lifetime_hint.
The ticket itself is an opaque label. It MAY either be a database
lookup key or a self-encrypted and self-authenticated value.
Section 4 of [RFC5077] describes a recommended ticket construction
mechanism.
[[TODO: Should we require that tickets be bound to the existing
symmetric cipher suite. See the TODO above about early_data and
PSK.??]
7. Cryptographic Computations
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 key schedule.
8.1. Computing the Master Secret 7.1. Key Schedule
The pre_master_secret is used to generate a series of master secret The TLS handshake establishes secret keying material which is then
values, as shown in the following diagram and described below. used to protect traffic. This keying material is derived from the
two input secret values: Static Secret (SS) and Ephemeral Secret
(ES).
Premaster Secret <---------+ The exact source of each of these secrets depends on the operational
| | mode (DHE, ECDHE, PSK, etc.) and is summarized in the table below:
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 Key Exchange Static Secret (SS) Ephemeral Secret (ES)
been exchanged, the client and server each use the unauthenticated ------------ ------------------ ---------------------
key shares to generate a master secret which is used for the (EC)DHE Client ephemeral Client ephemeral
protection of the remaining handshake records. Specifically, they (full handshake) w/ server ephemeral w/ server ephemeral
generate:
hs_master_secret = PRF(pre_master_secret, "handshake master secret", (EC)DHE Client ephemeral Client ephemeral
session_hash) (w/ known_configuration) w/ Known Key w/ server ephemeral
[0..47];
During resumption, the premaster secret is initialized with the PSK Pre-Shared Key Pre-shared key
"resumption premaster secret", rather than using the values from the
ClientKeyShare/ServerKeyShare exchange.
This master secret value is used to generate the record protection PSK + (EC)DHE Pre-Shared Key Client ephemeral
keys used for the handshake, as described in Section 6.3. w/ server ephemeral
Once the hs_master_secret has been computed, the premaster secret These shared secret values are used to generate cryptographic keys as
SHOULD be deleted from memory. shown below.
Once the last non-Finished message has been sent, the client and The derivation process is as follows, where L denotes the length of
server then compute the master secret which will be used for the the underlying hash function for HKDF.
remainder of the session. It is also used with TLS Exporters
[RFC5705].
master_secret = PRF(hs_master_secret, "extended master secret", HKDF-Expand-Label(Secret, Label, HashValue, Length) =
session_hash) HKDF-Expand(Secret, Label + '\0' + HashValue, Length)
[0..47];
If the server does not request client authentication, the master 1. xSS = HKDF(0, SS, "extractedSS", L)
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 2. xES = HKDF(0, ES, "extractedES", L)
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, 3. master_secret= HKDF(xSS, xES, "master secret", L)
"resumption premaster secret",
session_hash)
[0..47];
The session_hash value is a running hash of the handshake as defined 4. finished_secret = HKDF-Expand-Label(xSS,
in Section 8.1.1. Thus, the hs_master_secret is generated using a "finished secret",
different session_hash from the other two secrets. handshake_hash, L)
All master secrets are always exactly 48 bytes in length. The length Where handshake_hash includes all the messages in the
of the premaster secret will vary depending on key exchange method. client's first flight and the server's flight, excluding
the Finished messages (which are never included in the
hashes).
8.1.1. The Session Hash 5. resumption_secret = HKDF-Expand-Label(master_secret,
"resumption master secret"
session_hash, L)
When a handshake takes place, we define Where session_hash is as defined in {{the-handshake-hash}}.
session_hash = Hash(handshake_messages) 6. exporter_secret = HKDF-Expand-Label(master_secret,
"exporter master secret",
session_hash, L)
where "handshake_messages" refers to all handshake messages sent or Where session_hash is the session hash as defined in
received, starting at ClientHello up to the present time, with the {{the-handshake-hash}} (i.e., the entire handshake except
exception of the Finished message, including the type and length for Finished).
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 The traffic keys are computed from xSS, xES, and the master_secret as
derived, the session hash includes the ClientHello, ClientKeyShare, described in Section 7.2 below.
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 7.2. Traffic Key Calculation
A conventional Diffie-Hellman computation is performed [DH]. The [[OPEN ISSUE: This needs to be revised. Most likely we'll extract
negotiated key (Z) is used as the pre_master_secret, and is converted each key component separately. See https://github.com/tlswg/tls13-
into the master_secret, as specified above. Leading bytes of Z that spec/issues/5]]
contain all zero bits are stripped before it is used as the
pre_master_secret.
8.1.3. Elliptic Curve Diffie-Hellman The Record Protocol requires an algorithm to generate keys required
by the current connection state (see Appendix A.5) from the security
parameters provided by the handshake protocol.
The traffic key computation takes four input values and returns a key
block of sufficient size to produce the needed traffic keys:
- A secret value
- A string label that indicates the purpose of keys being generated.
- The current handshake hash.
- The total length in octets of the key block.
The keying material is computed using:
key_block = HKDF-Expand-Label(Secret, Label,
handshake_hash,
total_length)
The key_block is partitioned as follows:
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.iv_length]
server_write_IV[SecurityParameters.iv_length]
The following table describes the inputs to the key calculation for
each class of traffic keys:
Record Type Secret Label Handshake Hash
----------- ------ ----- ---------------
Early data xSS "early data key expansion" ClientHello
Handshake xES "handshake key expansion" ClientHello...
ServerKeyShare
Application master "application data key expansion" All handshake
secret messages but
Finished
(session_hash)
7.2.1. The Handshake Hash
handshake_hash = Hash(
Hash(handshake_messages) ||
Hash(configuration)
)
handshake_messages
All handshake messages sent or received, starting at ClientHello
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 in plaintext form (even if they were
encrypted on the wire).
configuration
When the known_configuration extension is in use
(Section 6.3.1.5.3, this contains the concatenation of the
ServerConfiguration and Certificate messages from the handshake
where the configuration was established. Note that this requires
the client and server to memorize these values.
This final value of the handshake hash is referred to as the "session
hash" because it contains all the handshake messages required to
establish the session. 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.
7.2.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the shared_secret, and is used in the
key schedule as specified above. Leading bytes of Z that contain all
zero bits are stripped before it is used as the input to HKDF.
7.2.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 shared secret is the x-coordinate of the
the ECDH shared secret elliptic curve point represented as an octet 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.
(Note that this use of the identity KDF is a technicality. The (Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use the premaster secret for anything because TLS does not directly use this secret for anything other than
other than for computing the master secret.) for computing other secrets.)
9. Mandatory Cipher Suites 8. Mandatory Cipher Suites
In the absence of an application profile standard specifying In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the cipher otherwise, a TLS-compliant application MUST implement the cipher
suite TODO:Needs to be selected [1]. (See Appendix A.4 for the suite TODO:Needs to be selected [1]. (See Appendix A.4 for the
definition.) definition.)
10. Application Data Protocol 9. Application Data Protocol
Application data messages are carried by the record layer and are Application data messages are carried by the record layer and are
fragmented and encrypted based on the current connection state. The fragmented and encrypted based on the current connection state. The
messages are treated as transparent data to the record layer. messages are treated as transparent data to the record layer.
11. Security Considerations 10. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices C, D, and E. Appendices C, D, and E.
12. IANA Considerations 11. IANA Considerations
[[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]] [[TODO: Update https://github.com/tlswg/tls13-spec/issues/62]]
This document uses several registries that were originally created in This document uses several registries that were originally created in
[RFC4346]. IANA has updated these to reference this document. The [RFC4346]. IANA has updated these to reference this document. The
registries and their allocation policies (unchanged from [RFC4346]) registries and their allocation policies (unchanged from [RFC4346])
are listed below. are listed below.
- TLS ClientCertificateType Identifiers Registry: Future values in - TLS ClientCertificateType Identifiers Registry: Future values in
the range 0-63 (decimal) inclusive are assigned via Standards the range 0-63 (decimal) inclusive are assigned via Standards
skipping to change at page 63, line 49 skipping to change at page 71, line 15
- 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.3.2.5). (see Section 6.3.1.4).
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.3.2.5.1. Future populated with the values described in Section 6.3.1.4.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.3.2.5.1. Future populated with the values described in Section 6.3.1.4.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 12. References
12.1. Normative References
13.1. Normative References
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", NIST FIPS 197, November 2001. (AES)", NIST FIPS 197, November 2001.
[DH] Diffie, W. and M. Hellman, "New Directions in [DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory, Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n.6 , June 1977. V.IT-22 n.6 , June 1977.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
skipping to change at page 65, line 33 skipping to change at page 72, line 49
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008. August 2008.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010.
[SHS] National Institute of Standards and Technology, U.S. [SHS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", NIST FIPS Department of Commerce, "Secure Hash Standard", NIST FIPS
PUB 180-2, August 2002. PUB 180-2, August 2002.
[X680] ITU-T, "Information technology - Abstract Syntax Notation [X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ISO/IEC One (ASN.1): Specification of basic notation", ISO/IEC
8824-1:2002, 2002. 8824-1:2002, 2002.
[X690] ITU-T, "Information technology - ASN.1 encoding Rules: [X690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2002, 2002. (DER)", ISO/IEC 8825-1:2002, 2002.
[X962] ANSI, "Public Key Cryptography For The Financial Services [X962] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
13.2. Informative References 12.2. Informative References
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures", May 2004, Problems and Countermeasures", May 2004,
<https://www.openssl.org/~bodo/tls-cbc.txt>. <https://www.openssl.org/~bodo/tls-cbc.txt>.
[DSS-3] National Institute of Standards and Technology, U.S., [DSS-3] National Institute of Standards and Technology, U.S.,
"Digital Signature Standard", NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", NIST FIPS PUB 186-3 Draft,
2006. 2006.
[ECDSA] American National Standards Institute, "Public Key [ECDSA] American National Standards Institute, "Public Key
skipping to change at page 66, line 39 skipping to change at page 74, line 11
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-10 (work in progress), June 2015. ff-dhe-10 (work in progress), June 2015.
[I-D.ietf-tls-session-hash] [I-D.ietf-tls-session-hash]
Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
A., and M. Ray, "Transport Layer Security (TLS) Session A., and M. Ray, "Transport Layer Security (TLS) Session
Hash and Extended Master Secret Extension", draft-ietf- Hash and Extended Master Secret Extension", draft-ietf-
tls-session-hash-05 (work in progress), April 2015. tls-session-hash-05 (work in progress), April 2015.
[I-D.ietf-tls-sslv3-diediedie]
Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", draft-
ietf-tls-sslv3-diediedie-03 (work in progress), April
2015.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
Syntax Standard, version 1.5", November 1993. Syntax Standard, version 1.5", November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message
Syntax Standard, version 1.5", November 1993. Syntax Standard, version 1.5", November 1993.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
skipping to change at page 67, line 18 skipping to change at page 74, line 33
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002. 3268, June 2002.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December
2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
[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.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", RFC 5081, November Layer Security (TLS) Authentication", RFC 5081, November
2007. 2007.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010. Layer Security (TLS)", RFC 5705, March 2010.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer [RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer
(SSL) Version 2.0", RFC 6176, March 2011. (SSL) Version 2.0", RFC 6176, March 2011.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, [RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
February 2015. February 2015.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
June 2015.
[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.
[TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are [TIMING] Boneh, D. and D. Brumley, "Remote timing attacks are
practical", USENIX Security Symposium, 2003. practical", USENIX Security Symposium, 2003.
[X501] "Information Technology - Open Systems Interconnection - [X501] "Information Technology - Open Systems Interconnection -
The Directory: Models", ITU-T X.501, 1993. The Directory: Models", ITU-T X.501, 1993.
13.3. URIs 12.3. URIs
[1] https://github.com/tlswg/tls13-spec/issues/32 [1] https://github.com/tlswg/tls13-spec/issues/32
[2] mailto:tls@ietf.org [2] mailto:tls@ietf.org
Appendix A. Protocol Data Structures and Constant Values Appendix A. Protocol Data Structures and Constant Values
This section describes protocol types and constants. This section describes protocol types and constants.
A.1. Record Layer A.1. Record Layer
struct { struct {
uint8 major; uint8 major;
uint8 minor; uint8 minor;
} ProtocolVersion; } ProtocolVersion;
enum { enum {
reserved(20), alert(21), handshake(22), reserved(20), alert(21), handshake(22),
application_data(23), (255) application_data(23), early_handshake(25),
(255)
} ContentType; } ContentType;
struct { struct {
ContentType type; ContentType type;
ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */ ProtocolVersion record_version = { 3, 1 }; /* TLS v1.x */
uint16 length; uint16 length;
opaque fragment[TLSPlaintext.length]; opaque fragment[TLSPlaintext.length];
} TLSPlaintext; } TLSPlaintext;
struct { struct {
skipping to change at page 71, line 6 skipping to change at page 79, line 6
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
A.3. Handshake Protocol A.3. Handshake Protocol
enum { enum {
reserved(0), client_hello(1), server_hello(2), reserved(0), client_hello(1), server_hello(2),
client_key_share(5), hello_retry_request(6), session_ticket(4), hello_retry_request(6),
server_key_share(7), certificate(11), reserved(12), server_key_share(7), certificate(11), reserved(12),
certificate_request(13), certificate_verify(15), certificate_request(13), server_configuration(14),
reserved(16), finished(20), (255) certificate_verify(15), 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 client_hello: ClientHello; case client_hello: ClientHello;
case client_key_share: ClientKeyShare;
case server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
case server_key_share: ServerKeyShare; case server_key_share: ServerKeyShare;
case server_configuration:ServerConfiguration;
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;
case session_ticket: NewSessionTicket;
} body; } body;
} Handshake; } Handshake;
A.3.1. Hello Messages A.3.1. Hello Messages
opaque SessionID<0..32>;
uint8 CipherSuite[2]; /* Cryptographic suite selector */ uint8 CipherSuite[2]; /* Cryptographic suite selector */
enum { null(0), (255) } CompressionMethod; enum { null(0), (255) } CompressionMethod;
struct { struct {
ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */ ProtocolVersion client_version = { 3, 4 }; /* TLS v1.3 */
Random random; Random random;
SessionID session_id; SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>; CompressionMethod compression_methods<1..2^8-1>;
skipping to change at page 72, line 5 skipping to change at page 80, line 4
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
} ClientHello; } ClientHello;
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
SessionID session_id; uint8 session_id_len; // Must be 0.
CipherSuite cipher_suite; CipherSuite cipher_suite;
select (extensions_present) { select (extensions_present) {
case false: case false:
struct {}; struct {};
case true: case true:
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
}; };
} ServerHello; } ServerHello;
struct { struct {
skipping to change at page 72, line 28 skipping to change at page 80, line 27
NamedGroup selected_group; NamedGroup selected_group;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
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),
supported_groups(TBD),
known_configuration(TBD),
pre_shared_key(TBD)
client_key_shares(TBD)
(65535)
} ExtensionType; } ExtensionType;
struct { struct {
TLSCipherText messages<5 .. 2^24-1>; select (Role) {
} EarlyDataExtension; case client:
opaque identifier<0..2^16-1>;
case server:
struct {};
}
} KnownConfigurationExtension
opaque psk_identity<0..2^16-1>;
struct {
select (Role) {
case client:
psk_identity identities<0..2^16-1>;
case server:
psk_identity identity;
} PreSharedKeyExtension;
enum { early_handshake(1), early_data(2),
early_handshake_and_data(3), (255) } EarlyDataType;
struct {
select (Role) {
case client:
opaque context<0..255>;
EarlyDataType type;
case server:
struct {};
}
} EarlyDataIndication;
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
struct {
opaque configuration_id<1..2^16-1>;
uint32 expiration_date;
NamedGroup group;
opaque server_key<1..2^16-1>;
Boolean early_data_allowed;
} ServerConfiguration;
A.3.1.1. Signature Algorithm Extension A.3.1.1. Signature Algorithm Extension
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;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm; SignatureAlgorithm;
struct { struct {
HashAlgorithm hash; HashAlgorithm hash;
skipping to change at page 74, line 50 skipping to change at page 83, line 47
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
struct { struct {
digitally-signed struct { digitally-signed struct {
opaque handshake_messages_hash[hash_length]; opaque handshake_hash[hash_length];
} }
} CertificateVerify; } CertificateVerify;
A.3.4. Handshake Finalization Messages A.3.4. Handshake Finalization Messages
struct { struct {
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
A.3.5. Ticket Establishment
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
A.4. The Cipher Suite A.4. The Cipher Suite
The following values define the cipher suite codes used in the The following values define the cipher suite codes used in the
ClientHello and ServerHello messages. A cipher suite defines a ClientHello and ServerHello messages. A cipher suite defines a
cipher specification supported in TLS. cipher specification supported in TLS.
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but MUST TLS connection during the first handshake on that channel, but MUST
NOT be negotiated, as it provides no more protection than an NOT be negotiated, as it provides no more protection than an
unsecured connection. unsecured connection.
skipping to change at page 76, line 30 skipping to change at page 85, line 37
[[TODO: Add all the defined AEAD ciphers. This currently only lists [[TODO: Add all the defined AEAD ciphers. This currently only lists
GCM. https://github.com/tlswg/tls13-spec/issues/53]] Note that using GCM. https://github.com/tlswg/tls13-spec/issues/53]] Note that using
non-anonymous key exchange without actually verifying the key non-anonymous key exchange without actually verifying the key
exchange is essentially equivalent to anonymous key exchange, and the exchange is essentially equivalent to anonymous key exchange, and the
same precautions apply. While non-anonymous key exchange will same precautions apply. While non-anonymous key exchange will
generally involve a higher computational and communicational cost generally involve a higher computational and communicational cost
than anonymous key exchange, it may be in the interest of than anonymous key exchange, it may be in the interest of
interoperability not to disable non-anonymous key exchange when the interoperability not to disable non-anonymous key exchange when the
application layer is allowing anonymous key exchange. application layer is allowing anonymous key exchange.
The PRFs SHALL be as follows: o For cipher suites ending with _SHA256, HKDF is used with SHA-256 as
the hash function.
o For cipher suites ending with _SHA256, the PRF is the TLS PRF with
SHA-256 as the hash function.
o For cipher suites ending with _SHA384, the PRF is the TLS PRF with o For cipher suites ending with _SHA384, HKDF is used with SHA-384 as
SHA-384 as the hash function. the hash function.
New cipher suite values are been assigned by IANA as described in New cipher suite values are assigned by IANA as described in
Section 12. Section 11.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL reserved to avoid collision with Fortezza-based cipher suites in SSL
3.0. 3.0.
A.5. The Security Parameters A.5. The Security Parameters
These security parameters are determined by the TLS Handshake These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS record layer in order Protocol and provided as parameters to the TLS record layer in order
to initialize a connection state. SecurityParameters includes: to initialize a connection state. SecurityParameters includes:
enum { server, client } ConnectionEnd; enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm; enum { tls_kdf_sha256, tls_kdf_sha384 } KDFAlgorithm;
enum { aes_gcm } RecordProtAlgorithm; enum { aes_gcm } RecordProtAlgorithm;
/* The algorithms specified in PRFAlgorithm and /* The algorithms specified in KDFAlgorithm and
RecordProtAlgorithm may be added to. */ RecordProtAlgorithm may be added to. */
struct { struct {
ConnectionEnd entity; ConnectionEnd entity;
PRFAlgorithm prf_algorithm; KDFAlgorithm kdf_algorithm;
RecordProtAlgorithm record_prot_algorithm; RecordProtAlgorithm record_prot_algorithm;
uint8 enc_key_length; uint8 enc_key_length;
uint8 iv_length; uint8 iv_length;
opaque hs_master_secret[48]; 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;
A.6. Changes to RFC 4492 A.6. Changes to RFC 4492
skipping to change at page 77, line 42 skipping to change at page 86, line 48
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 [RFC5280]. restrictions imposed by future revisions of [RFC5280].
As described in Section 7.3.5 and Section 7.3.9, the restrictions on As described in Section 6.3.4 and Section 6.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. Cipher Suite Definitions Appendix B. Cipher Suite Definitions
Cipher Suite Key Record Cipher Suite Key Record
Exchange Protection PRF Exchange Protection Hash
TLS_NULL_WITH_NULL_NULL NULL NULL_NULL N/A TLS_NULL_WITH_NULL_NULL NULL NULL_NULL N/A
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA AES_128_GCM SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA AES_128_GCM SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE_RSA AES_256_GCM SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE_RSA AES_256_GCM SHA384
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE_DSS AES_128_GCM SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE_DSS AES_128_GCM SHA256
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE_DSS AES_256_GCM SHA384 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE_DSS AES_256_GCM SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256 DH_anon AES_128_GCM SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 DH_anon AES_128_GCM SHA256
TLS_DH_anon_WITH_AES_256_GCM_SHA384 DH_anon AES_128_GCM SHA384 TLS_DH_anon_WITH_AES_256_GCM_SHA384 DH_anon AES_128_GCM SHA384
Appendix C. Implementation Notes Appendix C. Implementation Notes
skipping to change at page 79, line 28 skipping to change at page 88, line 28
Implementation experience has shown that certain parts of earlier TLS Implementation experience has shown that certain parts of earlier TLS
specifications are not easy to understand, and have been a source of specifications are not easy to understand, and have been a source of
interoperability and security problems. Many of these areas have interoperability and security problems. Many of these areas have
been clarified in this document, but this appendix contains a short been clarified in this document, but this appendix contains a short
list of the most important things that require special attention from list of the most important things that require special attention from
implementors. implementors.
TLS protocol issues: TLS protocol issues:
- Do you correctly handle handshake messages that are fragmented to - Do you correctly handle handshake messages that are fragmented to
multiple TLS records (see Section 6.2.1)? Including corner cases multiple TLS records (see Section 5.2.1)? Including corner cases
like a ClientHello that is split to several small fragments? Do like a ClientHello that is split to several small fragments? Do
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? (see Appendix D) records? (see Appendix D)
- Have you ensured that all support for SSL, RC4, and EXPORT ciphers - Have you ensured that all support for SSL, RC4, and EXPORT ciphers
is completely removed from all possible configurations that is completely removed from all possible configurations that
support TLS 1.3 or later, and that attempts to use these obsolete support TLS 1.3 or later, and that attempts to use these obsolete
capabilities fail correctly? (see Appendix D) capabilities fail correctly? (see Appendix D)
- 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?
- 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.3.9)? Section 6.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.9)? 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.2)? leading zero bytes from the negotiated key (see Section 7.2.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 E.1.1.2)? by the server are acceptable (see Appendix E.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 C.1) Diffie-Hellman private values, number generator (see Appendix C.1) Diffie-Hellman private values,
the DSA "k" parameter, and other security-critical values? the DSA "k" parameter, and other security-critical values?
Appendix D. Backward Compatibility Appendix D. Backward Compatibility
skipping to change at page 82, line 23 skipping to change at page 91, line 23
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT- Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an
SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT
RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
order to negotiate older versions of TLS. order to negotiate older versions of TLS.
Implementations MUST NOT send or accept any records with a version Implementations MUST NOT send or accept any records with a version
less than { 3, 0 }. less than { 3, 0 }.
The security of SSL 3.0 [SSL3] is considered insufficient for the The security of SSL 3.0 [SSL3] is considered insufficient for the
reasons enumerated in [I-D.ietf-tls-sslv3-diediedie], and MUST NOT be reasons enumerated in [RFC7568], and MUST NOT be negotiated for any
negotiated for any reason. reason.
Implementations MUST NOT send a ClientHello.client_version or Implementations MUST NOT send a ClientHello.client_version or
ServerHello.server_version set to { 3, 0 } or less. Any endpoint ServerHello.server_version set to { 3, 0 } or less. Any endpoint
receiving a Hello message with ClientHello.client_version or receiving a Hello message with ClientHello.client_version or
ServerHello.server_version set to { 3, 0 } MUST respond with a ServerHello.server_version set to { 3, 0 } MUST respond with a
"protocol_version" alert message and close the connection. "protocol_version" alert message and close the connection.
Appendix E. Security Analysis Appendix E. Security Analysis
[[TODO: The entire security analysis needs a rewrite.]]
The TLS protocol is designed to establish a secure connection between The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel. otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety This appendix outlines how TLS has been designed to resist a variety
of attacks. of attacks.
skipping to change at page 83, line 19 skipping to change at page 92, line 19
total anonymity. Whenever the server is authenticated, the channel total anonymity. Whenever the server is authenticated, the channel
is secure against man-in-the-middle attacks, but completely anonymous is secure against man-in-the-middle attacks, but completely anonymous
sessions are inherently vulnerable to such attacks. Anonymous sessions are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is authenticated, servers cannot authenticate clients. If the server is authenticated,
its certificate message must provide a valid certificate chain its certificate message must provide a valid certificate chain
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 [[TODO: Rewrite this because the master_secret is not used this way
pre_master_secret known to the communicating parties and not to any more after Hugo's changes.]] The general goal of the key exchange
attackers. The pre_master_secret will be used to generate the process is to create a master_secret known to the communicating
master_secret (see Section 8.1). The master_secret is required to parties and not to attackers (see Section 7.1). The master_secret is
generate the Finished messages and record protection keys (see required to generate the Finished messages and record protection keys
Section 7.3.8 and Section 6.3). By sending a correct Finished (see Section 6.3.8 and Section 7.2). By sending a correct Finished
message, parties thus prove that they know the correct message, parties thus prove that they know the correct master_secret.
pre_master_secret.
E.1.1.1. Anonymous Key Exchange E.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.
pre_master_secret).
Warning: Completely anonymous connections only provide protection Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper-proof against passive eavesdropping. Unless an independent tamper-proof
channel is used to verify that the Finished messages were not channel is used to verify that the Finished messages were not
replaced by an attacker, server authentication is required in replaced by an attacker, server authentication is required in
environments where active man-in-the-middle attacks are a concern. environments where active man-in-the-middle attacks are a concern.
E.1.1.2. Diffie-Hellman Key Exchange with Authentication E.1.1.2. Diffie-Hellman Key Exchange with Authentication
When Diffie-Hellman key exchange is used, the client and server use When Diffie-Hellman key exchange is used, the client and server use
skipping to change at page 84, line 42 skipping to change at page 93, line 40
E.1.3. Detecting Attacks Against the Handshake Protocol E.1.3. Detecting Attacks Against the Handshake Protocol
An attacker might try to influence the handshake exchange to make the An attacker might try to influence the handshake exchange to make the
parties select different encryption algorithms than they would parties select different encryption algorithms than they would
normally choose. normally choose.
For this attack, an attacker must actively change one or more For this attack, an attacker must actively change one or more
handshake messages. If this occurs, the client and server will handshake messages. If this occurs, the client and server will
compute different values for the handshake message hashes. As a compute different values for the handshake message hashes. As a
result, the parties will not accept each others' Finished messages. result, the parties will not accept each others' Finished messages.
Without the master_secret, the attacker cannot repair the Finished Without the static secret, the attacker cannot repair the Finished
messages, so the attack will be discovered. messages, so the attack will be discovered.
E.1.4. Resuming Sessions
When a connection is established by resuming a session, new
ClientHello.random and ServerHello.random values are hashed with the
session's master_secret. Provided that the master_secret has not
been compromised and that the secure hash operations used to produce
the record protection keys are secure, the connection should be
secure and effectively independent from previous connections.
Attackers cannot use known keys to compromise the master_secret
without breaking the secure hash operations.
Sessions cannot be resumed unless both the client and server agree.
If either party suspects that the session may have been compromised,
or that certificates may have expired or been revoked, it should
force a full handshake. An upper limit of 24 hours is suggested for
session ID lifetimes, since an attacker who obtains a master_secret
may be able to impersonate the compromised party until the
corresponding session ID is retired. Applications that may be run in
relatively insecure environments should not write session IDs to
stable storage.
E.2. Protecting Application Data E.2. Protecting Application Data
The master_secret is hashed with the ClientHello.random and The shared secrets are hashed with the handshake transcript to
ServerHello.random to produce unique record protection secrets for produce unique record protection secrets for each connection.
each connection.
Outgoing data is protected using an AEAD algorithm before Outgoing data is protected using an AEAD algorithm before
transmission. The authentication data includes the sequence number, transmission. The authentication data includes the sequence number,
message type, message length, and the message contents. The message message type, message length, and the message contents. The message
type field is necessary to ensure that messages intended for one TLS type field is necessary to ensure that messages intended for one TLS
record layer client are not redirected to another. The sequence record layer client are not redirected to another. The sequence
number ensures that attempts to delete or reorder messages will be number ensures that attempts to delete or reorder messages will be
detected. Since sequence numbers are 64 bits long, they should never detected. Since sequence numbers are 64 bits long, they should never
overflow. Messages from one party cannot be inserted into the overflow. Messages from one party cannot be inserted into the
other's output, since they use independent keys. other's output, since they use independent keys.
skipping to change at page 88, line 33 skipping to change at page 97, line 10
ilari.liusvaara@elisanet.fi 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
Erik Nygren
Akamai Technologies
erik+ietf@nygren.org
Magnus Nystrom Magnus Nystrom
RSA Security RSA Security
magnus@rsasecurity.com magnus@rsasecurity.com
Alfredo Pironti (co-author of [I-D.ietf-tls-session-hash]) 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]) Marsh Ray (co-author of [I-D.ietf-tls-session-hash])
Microsoft Microsoft
 End of changes. 224 change blocks. 
889 lines changed or deleted 1238 lines changed or added

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