draft-ietf-tls-tls13-07.txt   draft-ietf-tls-tls13-08.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 3268, 4346, 4366, 5246, 5077 July 08, 2015 Obsoletes: 5077, 5246, 5746 (if August 28, 2015
(if approved) approved)
Updates: 4492 (if approved) Updates: 4492 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 9, 2016 Expires: February 29, 2016
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-07 draft-ietf-tls-tls13-08
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 allows client/server applications
over the Internet. The protocol allows client/server applications to to communicate over the Internet in a way that is designed to prevent
communicate in a way that is designed to prevent eavesdropping, eavesdropping, tampering, and message forgery.
tampering, or message forgery.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 9, 2016. This Internet-Draft will expire on February 29, 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 25 skipping to change at page 2, line 24
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Goals of This Document . . . . . . . . . . . . . . . . . . . 8 3. Goals of This Document . . . . . . . . . . . . . . . . . . . 8
4. Presentation Language . . . . . . . . . . . . . . . . . . . . 8 4. Presentation Language . . . . . . . . . . . . . . . . . . . . 9
4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 8 4.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 9
4.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 11 4.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 12
4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 12 4.6.1. Variants . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 13 4.8. Primitive Types . . . . . . . . . . . . . . . . . . . . . 14
4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 14 4.9. Cryptographic Attributes . . . . . . . . . . . . . . . . 14
4.9.1. Digital Signing . . . . . . . . . . . . . . . . . . . 14 4.9.1. Digital Signing . . . . . . . . . . . . . . . . . . . 14
4.9.2. Authenticated Encryption with Additional Data (AEAD) 15 4.9.2. Authenticated Encryption with Additional Data (AEAD) 16
5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16 5. The TLS Record Protocol . . . . . . . . . . . . . . . . . . . 16
5.1. Connection States . . . . . . . . . . . . . . . . . . . . 17 5.1. Connection States . . . . . . . . . . . . . . . . . . . . 17
5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 19
5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19 5.2.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 19
5.2.2. Record Payload Protection . . . . . . . . . . . . . . 20 5.2.2. Record Payload Protection . . . . . . . . . . . . . . 21
6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 22 6. The TLS Handshaking Protocols . . . . . . . . . . . . . . . . 23
6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23 6.1. Alert Protocol . . . . . . . . . . . . . . . . . . . . . 23
6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 24 6.1.1. Closure Alerts . . . . . . . . . . . . . . . . . . . 25
6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 25 6.1.2. Error Alerts . . . . . . . . . . . . . . . . . . . . 26
6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 29 6.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 30
6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 32 6.2.1. Incorrect DHE Share . . . . . . . . . . . . . . . . . 33
6.2.2. Cached Server Configuration . . . . . . . . . . . . . 33 6.2.2. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 34
6.2.3. Zero-RTT Exchange . . . . . . . . . . . . . . . . . . 34 6.2.3. Resumption and PSK . . . . . . . . . . . . . . . . . 36
6.2.4. Resumption and PSK . . . . . . . . . . . . . . . . . 35
6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 36 6.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 38
6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 37 6.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 38
6.3.2. Server Key Share . . . . . . . . . . . . . . . . . . 54 6.3.2. Hello Extensions . . . . . . . . . . . . . . . . . . 43
6.3.3. Encrypted Extensions . . . . . . . . . . . . . . . . 55 6.3.3. Server Key Share . . . . . . . . . . . . . . . . . . 56
6.3.4. Server Certificate . . . . . . . . . . . . . . . . . 55 6.3.4. Encrypted Extensions . . . . . . . . . . . . . . . . 56
6.3.5. Certificate Request . . . . . . . . . . . . . . . . . 58 6.3.5. Server Certificate . . . . . . . . . . . . . . . . . 57
6.3.6. Server Configuration . . . . . . . . . . . . . . . . 59 6.3.6. Certificate Request . . . . . . . . . . . . . . . . . 60
6.3.7. Server Certificate Verify . . . . . . . . . . . . . . 61 6.3.7. Server Configuration . . . . . . . . . . . . . . . . 61
6.3.8. Server Finished . . . . . . . . . . . . . . . . . . . 62 6.3.8. Server Certificate Verify . . . . . . . . . . . . . . 63
6.3.9. Client Certificate . . . . . . . . . . . . . . . . . 63 6.3.9. Server Finished . . . . . . . . . . . . . . . . . . . 64
6.3.10. Client Certificate Verify . . . . . . . . . . . . . . 64 6.3.10. Client Certificate . . . . . . . . . . . . . . . . . 65
6.3.11. New Session Ticket Message . . . . . . . . . . . . . 65 6.3.11. Client Certificate Verify . . . . . . . . . . . . . . 67
7. Cryptographic Computations . . . . . . . . . . . . . . . . . 66 6.3.12. New Session Ticket Message . . . . . . . . . . . . . 68
7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 66 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 68
7.2. Traffic Key Calculation . . . . . . . . . . . . . . . . . 67 7.1. Key Schedule . . . . . . . . . . . . . . . . . . . . . . 69
7.2.1. The Handshake Hash . . . . . . . . . . . . . . . . . 68 7.2. Traffic Key Calculation . . . . . . . . . . . . . . . . . 70
7.2.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 69 7.2.1. The Handshake Hash . . . . . . . . . . . . . . . . . 71
7.2.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 69 7.2.2. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 72
8. Mandatory Cipher Suites . . . . . . . . . . . . . . . . . . . 70 7.2.3. Elliptic Curve Diffie-Hellman . . . . . . . . . . . . 72
9. Application Data Protocol . . . . . . . . . . . . . . . . . . 70 8. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . . 72
10. Security Considerations . . . . . . . . . . . . . . . . . . . 70 8.1. MTI Cipher Suites . . . . . . . . . . . . . . . . . . . . 73
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 8.2. MTI Extensions . . . . . . . . . . . . . . . . . . . . . 73
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 9. Application Data Protocol . . . . . . . . . . . . . . . . . . 74
12.1. Normative References . . . . . . . . . . . . . . . . . . 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12.2. Informative References . . . . . . . . . . . . . . . . . 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
Appendix A. Protocol Data Structures and Constant Values . . . . 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 75
A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 77 12.2. Informative References . . . . . . . . . . . . . . . . . 77
A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 77 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 78 Appendix A. Protocol Data Structures and Constant Values . . . . 81
A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 79 A.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 81
A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 82 A.2. Alert Messages . . . . . . . . . . . . . . . . . . . . . 81
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 83 A.3. Handshake Protocol . . . . . . . . . . . . . . . . . . . 82
A.3.4. Handshake Finalization Messages . . . . . . . . . . . 84 A.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 83
A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 84 A.3.2. Key Exchange Messages . . . . . . . . . . . . . . . . 86
A.4. The Cipher Suite . . . . . . . . . . . . . . . . . . . . 84 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 87
A.5. The Security Parameters . . . . . . . . . . . . . . . . . 86 A.3.4. Handshake Finalization Messages . . . . . . . . . . . 88
A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 86 A.3.5. Ticket Establishment . . . . . . . . . . . . . . . . 88
Appendix B. Cipher Suite Definitions . . . . . . . . . . . . . . 87 A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 88
Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 87 A.5. The Security Parameters . . . . . . . . . . . . . . . . . 91
C.1. Random Number Generation and Seeding . . . . . . . . . . 87 A.6. Changes to RFC 4492 . . . . . . . . . . . . . . . . . . . 91
C.2. Certificates and Authentication . . . . . . . . . . . . . 87 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 92
C.3. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 88 B.1. Random Number Generation and Seeding . . . . . . . . . . 92
C.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 88 B.2. Certificates and Authentication . . . . . . . . . . . . . 92
Appendix D. Backward Compatibility . . . . . . . . . . . . . . . 89 B.3. Cipher Suite Support . . . . . . . . . . . . . . . . . . 93
D.1. Negotiating with an older server . . . . . . . . . . . . 89 B.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 93
D.2. Negotiating with an older client . . . . . . . . . . . . 90 Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 94
D.3. Backwards Compatibility Security Restrictions . . . . . . 90 C.1. Negotiating with an older server . . . . . . . . . . . . 95
Appendix E. Security Analysis . . . . . . . . . . . . . . . . . 91 C.2. Negotiating with an older client . . . . . . . . . . . . 95
E.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 91 C.3. Backwards Compatibility Security Restrictions . . . . . . 96
E.1.1. Authentication and Key Exchange . . . . . . . . . . . 92 Appendix D. Security Analysis . . . . . . . . . . . . . . . . . 96
E.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 93 D.1. Handshake Protocol . . . . . . . . . . . . . . . . . . . 97
E.1.3. Detecting Attacks Against the Handshake Protocol . . 93 D.1.1. Authentication and Key Exchange . . . . . . . . . . . 97
E.2. Protecting Application Data . . . . . . . . . . . . . . . 93 D.1.2. Version Rollback Attacks . . . . . . . . . . . . . . 98
E.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 94 D.1.3. Detecting Attacks Against the Handshake Protocol . . 98
E.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 94 D.2. Protecting Application Data . . . . . . . . . . . . . . . 99
Appendix F. Working Group Information . . . . . . . . . . . . . 94 D.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 99
Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 95 D.4. Final Notes . . . . . . . . . . . . . . . . . . . . . . . 99
Appendix E. Working Group Information . . . . . . . . . . . . . 100
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 100
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
managed in GitHub, but any substantive change should be discussed on managed in GitHub, but any substantive change should be discussed on
the TLS mailing list. the TLS mailing list.
The primary goal of the TLS protocol is to provide privacy and data The primary goal of the TLS protocol is to provide privacy and data
integrity between two communicating applications. The protocol is integrity between two communicating peers. The TLS protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP [RFC0793]), is the TLS Record Protocol. transport protocol (e.g., TCP [RFC0793]), is the TLS Record Protocol.
The TLS Record Protocol provides connection security that has two The TLS Record Protocol provides connection security that has two
basic properties: basic properties:
- The connection is private. Symmetric cryptography is used for - The connection is private. Symmetric cryptography is used for
data encryption (e.g., AES [AES], etc.). The keys for this data encryption (e.g., AES [AES], etc.). The keys for this
symmetric encryption are generated uniquely for each connection symmetric encryption are generated uniquely for each connection
and are based on a secret negotiated by another protocol (such as and are based on a secret negotiated by another protocol (such as
the TLS Handshake Protocol). The Record Protocol can also be used the TLS Handshake Protocol).
without encryption, i.e., in integrity-only modes.
- The connection is reliable. Messages include an authentication - The connection is reliable. Messages include an authentication
tag which protects them against modification. tag which protects them against modification.
- The Record Protocol can operate in an insecure mode but is Note: The TLS Record Protocol can operate in an insecure mode but is
generally only used in this mode while another protocol is using generally only used in this mode while another protocol is using the
the Record Protocol as a transport for negotiating security TLS Record Protocol as a transport for negotiating security
parameters. parameters.
The TLS Record Protocol is used for encapsulation of various higher- The TLS Record Protocol is used for encapsulation of various higher-
level protocols. One such encapsulated protocol, the TLS Handshake level protocols. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys before to negotiate an encryption algorithm and cryptographic keys before
the application protocol transmits or receives its first byte of the application protocol transmits or receives its first byte of
data. The TLS Handshake Protocol provides connection security that data. The TLS Handshake Protocol provides connection security that
has three basic properties: has three basic properties:
- The peer's identity can be authenticated using asymmetric, or - The peer's identity can be authenticated using asymmetric, or
skipping to change at page 6, line 20 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. draft-08
- Add initial 0-RTT support - Remove support for weak and lesser used named curves.
- Remove resumption and replace with PSK + tickets - Remove support for MD5 and SHA-224 hashes with signatures.
- Move ClientKeyShare into an extension. - Update lists of available AEAD cipher suites and error alerts.
- Move to HKDF - Reduce maximum permitted record expansion for AEAD from 2048 to
256 octets.
draft-06 - Require digital signatures even when a previous configuration is
used.
- Merge EarlyDataIndication and KnownConfiguration.
- Change code point for server_configuration to avoid collision with
server_hello_done.
- Relax certificate_list ordering requirement to match current
practice.
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.
- 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.
draft-05 draft-05
- Prohibit SSL negotiation for backwards compatibility. - Prohibit SSL negotiation for backwards compatibility.
- Fix which MS is used for exporters. - Fix which MS is used for exporters.
draft-04 draft-04
- Modify key computations to include session hash. - Modify key computations to include session hash.
- Remove ChangeCipherSpec - Remove ChangeCipherSpec.
- Renumber the new handshake messages to be somewhat more consistent - Renumber the new handshake messages to be somewhat more consistent
with existing convention and to remove a duplicate registration. with existing convention and to remove a duplicate registration.
- Remove renegotiation. - Remove renegotiation.
- Remove point format negotiation. - Remove point format negotiation.
draft-03 draft-03
- Remove GMT time. - Remove GMT time.
- Merge in support for ECC from RFC 4492 but without explicit - Merge in support for ECC from RFC 4492 but without explicit
curves. curves.
- Remove the unnecessary length field from the AD input to AEAD - Remove the unnecessary length field from the AD input to AEAD
ciphers. ciphers.
- Rename {Client,Server}KeyExchange to {Client,Server}KeyShare - Rename {Client,Server}KeyExchange to {Client,Server}KeyShare.
- Add an explicit HelloRetryRequest to reject the client's - Add an explicit HelloRetryRequest to reject the client's.
draft-02 draft-02
- Increment version number. - Increment version number.
- Reworked handshake to provide 1-RTT mode. - Rework handshake to provide 1-RTT mode.
- Remove custom DHE groups. - Remove custom DHE groups.
- Removed support for compression. - Remove support for compression.
- Removed support for static RSA and DH key exchange. - Remove support for static RSA and DH key exchange.
- Removed support for non-AEAD ciphers - Remove support for non-AEAD ciphers.
2. Goals 2. Goals
The goals of the TLS protocol, in order of priority, are as follows: The goals of the TLS protocol, in order of priority, are as follows:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange develop applications utilizing TLS that can successfully exchange
skipping to change at page 8, line 20 skipping to change at page 8, line 42
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 have evolved from the SSL This document and the TLS protocol itself have evolved from the SSL
3.0 Protocol Specification as published by Netscape. The differences 3.0 Protocol Specification as published by Netscape. The differences
between this protocol and previous versions are significant enough between this version and previous versions are significant enough
that the various versions of TLS and SSL 3.0 do not interoperate that the various versions of TLS and SSL 3.0 do not interoperate
(although each protocol incorporates a mechanism by which an (although each protocol incorporates a mechanism by which an
implementation can back down to prior versions). This document is implementation can back down to prior versions). This document is
intended primarily for readers who will be implementing the protocol intended primarily for readers who will be implementing the protocol
and for those doing cryptographic analysis of it. The specification and for those doing cryptographic analysis of it. The specification
has been written with this in mind, and it is intended to reflect the has been written with this in mind, and it is intended to reflect the
needs of those two groups. For that reason, many of the algorithm- needs of those two groups. For that reason, many of the algorithm-
dependent data structures and rules are included in the body of the dependent data structures and rules are included in the body of the
text (as opposed to in an appendix), providing easier access to them. text (as opposed to in an appendix), providing easier access to them.
skipping to change at page 14, line 24 skipping to change at page 14, line 38
4.9.1. Digital Signing 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 6.3.2.1
Section 6.3.1.4.1 for the definition of this field). Note that the for the definition of this field). Note that the algorithm field was
algorithm field was introduced in TLS 1.2, and is not in earlier introduced in TLS 1.2, and is not in earlier versions. The signature
versions. The signature is a digital signature using those is a digital signature using those algorithms over the contents of
algorithms over the contents of the element. The contents themselves the element. The contents themselves do not appear on the wire but
do not appear on the wire but are simply calculated. The length of are simply calculated. The length of the signature is specified by
the signature is specified by the signing algorithm and key. 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
octet 32 in order to clear that chosen-prefix. octet 32 in order to clear that chosen-prefix.
Following that padding is a NUL-terminated context string in order to Following that padding is a NUL-terminated context string in order to
disambiguate signatures for different purposes. The context string disambiguate signatures for different purposes. The context string
will be specified whenever a digitally-signed element is used. will be specified whenever a digitally-signed element is used.
skipping to change at page 16, line 33 skipping to change at page 16, line 43
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.
5. The TLS Record Protocol 5. 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 TLS Record Protocol takes messages to be transmitted, fragments
data into manageable blocks, protects the records, and transmits the the data into manageable blocks, protects the records, and transmits
result. Received data is decrypted and verified, reassembled, and the result. Received data is decrypted and verified, reassembled,
then delivered to higher-level clients. and then delivered to higher-level clients.
Three protocols that use the record protocol are described in this Three protocols that use the TLS Record Protocol are described in
document: the handshake protocol, the alert protocol, and the this document: the TLS Handshake Protocol, the Alert Protocol, and
application data protocol. In order to allow extension of the TLS the application data protocol. In order to allow extension of the
protocol, additional record content types can be supported by the TLS protocol, additional record content types can be supported by the
record protocol. New record content type values are assigned by IANA TLS Record Protocol. New record content type values are assigned by
in the TLS Content Type Registry as described in Section 11. IANA 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 (e.g., padding, cover traffic) to
information leakage. minimize information leakage.
5.1. Connection States 5.1. Connection States
[[TODO: I plan to totally rewrite or remove this. IT seems like just [[TODO: I plan to totally rewrite or remove this. IT seems like just
cruft.]] 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
skipping to change at page 17, line 44 skipping to change at page 18, line 6
Hash algorithm Hash algorithm
An algorithm used to generate keys from the appropriate secret An algorithm used to generate keys from the appropriate secret
(see Section 7.1 and Section 7.2). (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 5.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 only in the initial handshake. This specification includes the
size of this algorithm and of the nonce for the AEAD algorithm. key size of this algorithm and of the nonce for the AEAD
algorithm.
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 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.
skipping to change at page 20, line 28 skipping to change at page 20, line 46
The application data. This data is transparent and treated as an The application data. This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol independent block to be dealt with by the higher-level protocol
specified by the type field. specified by the type field.
This document describes TLS Version 1.3, which uses the version { 3, This document describes TLS Version 1.3, which uses the version { 3,
4 }. The version value 3.4 is historical, deriving from the use of { 4 }. The version value 3.4 is historical, deriving from the use of {
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 C.
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.
5.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
skipping to change at page 21, line 26 skipping to change at page 21, line 41
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 }. Note that the TLSPlaintext.record_version and is always { 3, 1 }. Note that the
handshake protocol including the ClientHello and ServerHello handshake protocol including the ClientHello and ServerHello
messages authenticates the protocol version, so this value is messages authenticates the protocol version, so this value is
redundant. 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 + 256. An endpoint that receives
a record that exceeds this length MUST generate a fatal
"record_overflow" alert.
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
algorithm where N_MAX is less than 8 bytes MUST not be used with TLS. algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS.
The per-record nonce for the AEAD construction is formed as follows: The per-record nonce for the AEAD construction is formed as follows:
1. The 64-bit record sequence number is padded to the left with 1. The 64-bit record sequence number is padded to the left with
zeroes to iv_length. zeroes to iv_length.
2. The padded sequence number is XORed with the static 2. The padded sequence number is XORed with the static
client_write_iv or server_write_iv, depending on the role. client_write_iv or server_write_iv, depending on the role.
The resulting quantity (of length iv_length) is used as the per- The resulting quantity (of length iv_length) is used as the per-
record nonce. record nonce.
skipping to change at page 22, line 20 skipping to change at page 22, line 37
Note: In versions of TLS prior to 1.3, the additional_data included a Note: In versions of TLS prior to 1.3, the additional_data included a
length field. This presents a problem for cipher constructions with length field. This presents a problem for cipher constructions with
data-dependent padding (such as CBC). TLS 1.3 removes the length data-dependent padding (such as CBC). TLS 1.3 removes the length
field and relies on the AEAD cipher to provide integrity for the field and relies on the AEAD cipher to provide integrity for the
length of the data. length of the data.
The AEAD output consists of the ciphertext output by the AEAD The AEAD output consists of the ciphertext output by the AEAD
encryption operation. The length will generally be larger than encryption operation. The length will generally be larger than
TLSPlaintext.length, but by an amount that varies with the AEAD TLSPlaintext.length, but by an amount that varies with the AEAD
cipher. Since the ciphers might incorporate padding, the amount of cipher. Since the ciphers might incorporate padding, the amount of
overhead could vary with different TLSPlaintext.length values. Each overhead could vary with different TLSPlaintext.length values.
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically, Symbolically,
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
additional_data) additional_data)
[[OPEN ISSUE: Reduce these values? https://github.com/tlswg/tls13-
spec/issues/55]]
In order to decrypt and verify, the cipher takes as input the key, In order to decrypt and verify, the cipher takes as input the key,
nonce, the "additional_data", and the AEADEncrypted value. The nonce, the "additional_data", and the AEADEncrypted value. The
output is either the plaintext or an error indicating that the output is either the plaintext or an error indicating that the
decryption failed. There is no separate integrity check. That is: decryption failed. There is no separate integrity check. That is:
TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce, TLSPlaintext.fragment = AEAD-Decrypt(write_key, nonce,
AEADEncrypted, AEADEncrypted,
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.
An AEAD cipher MUST NOT produce an expansion of greater than 256
bytes. An endpoint that receives a record that is larger than 2^14 +
256 octets MUST generate a fatal "record_overflow" alert.
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. The TLS Handshaking Protocols 6. 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 TLS Handshake Protocol is responsible for negotiating a session,
which consists of the following items: which consists of the following items:
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
hash for use with HKDF to generate keying material, and the record hash for use with HKDF to generate keying material, and the record
protection algorithm (See Appendix A.5 for formal definition.) protection algorithm (See Appendix A.5 for formal definition.)
skipping to change at page 24, line 9 skipping to change at page 24, line 12
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.
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
enum { enum {
close_notify(0), close_notify(0),
unexpected_message(10), /* fatal */ unexpected_message(10), /* fatal */
bad_record_mac(20), /* fatal */ bad_record_mac(20), /* fatal */
decryption_failed_RESERVED(21), /* fatal */ decryption_failed_RESERVED(21), /* fatal */
record_overflow(22), /* fatal */ record_overflow(22), /* fatal */
decompression_failure_RESERVED(30), /* fatal */ decompression_failure_RESERVED(30), /* fatal */
handshake_failure(40), /* fatal */ handshake_failure(40), /* fatal */
no_certificate_RESERVED(41), /* fatal */ no_certificate_RESERVED(41), /* fatal */
bad_certificate(42), bad_certificate(42),
unsupported_certificate(43), unsupported_certificate(43),
certificate_revoked(44), certificate_revoked(44),
certificate_expired(45), certificate_expired(45),
certificate_unknown(46), certificate_unknown(46),
illegal_parameter(47), /* fatal */ illegal_parameter(47), /* fatal */
unknown_ca(48), /* fatal */ unknown_ca(48), /* fatal */
access_denied(49), /* fatal */ access_denied(49), /* fatal */
decode_error(50), /* fatal */ decode_error(50), /* fatal */
decrypt_error(51), /* fatal */ decrypt_error(51), /* fatal */
export_restriction_RESERVED(60), /* fatal */ export_restriction_RESERVED(60), /* fatal */
protocol_version(70), /* fatal */ protocol_version(70), /* fatal */
insufficient_security(71), /* fatal */ insufficient_security(71), /* fatal */
internal_error(80), /* fatal */ internal_error(80), /* fatal */
inappropriate_fallback(86), /* fatal */
user_canceled(90), user_canceled(90),
no_renegotiation(100), /* fatal */ no_renegotiation_RESERVED(100), /* fatal */
unsupported_extension(110), /* fatal */ missing_extension(109), /* fatal */
unsupported_extension(110), /* fatal */
certificate_unobtainable(111),
unrecognized_name(112),
bad_certificate_status_response(113), /* fatal */
bad_certificate_hash_value(114), /* fatal */
unknown_psk_identity(115),
(255) (255)
} AlertDescription; } AlertDescription;
struct { struct {
AlertLevel level; AlertLevel level;
AlertDescription description; AlertDescription description;
} Alert; } Alert;
6.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. Failure to properly
initiate the exchange of closing messages. close a connection does not prohibit a session from being resumed.
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. Any data received after a
failure to properly close a connection no longer requires that a closure MUST be ignored.
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice. user_canceled
This message notifies the recipient that the sender is canceling
the handshake for some reason unrelated to a protocol failure. If
a user cancels an operation after the handshake is complete, just
closing the connection by sending a "close_notify" is more
appropriate. This alert SHOULD be followed by a "close_notify".
This alert is generally a warning.
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. If a transport- Any data received after a closure alert is ignored. If a transport-
level close is received prior to a close_notify, the receiver cannot level close is received prior to a "close_notify", the receiver
know that all the data that was sent has been received. cannot know that all the data that was sent has been received.
Unless some other fatal alert has been transmitted, each party is Each party MUST send a "close_notify" alert before closing the write
required to send a "close_notify" alert before closing the write side side of the connection, unless some other fatal alert has been
of the connection. The other party MUST respond with a transmitted. The other party MUST respond with a "close_notify"
"close_notify" alert of its own and close down the connection alert of its own and close down the connection immediately,
immediately, discarding any pending writes. It is not required for discarding any pending writes. The initiator of the close need not
the initiator of the close to wait for the responding "close_notify" wait for the responding "close_notify" alert before closing the read
alert before closing the read side of the connection. 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
carried over the underlying transport after the TLS connection is carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding closed, the TLS implementation must receive the responding
"close_notify" alert before indicating to the application layer that "close_notify" alert before indicating to the application layer that
the TLS connection has ended. If the application protocol will not the TLS connection has ended. If the application protocol will not
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.
6.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 its peer.
party. Upon transmission or receipt of a fatal alert message, both Upon transmission or receipt of a fatal alert message, both parties
parties immediately close the connection. Servers and clients MUST immediately close the connection. Servers and clients MUST forget
forget any session-identifiers, keys, and secrets associated with a any session-identifiers, keys, and secrets associated with a failed
failed connection. Thus, any connection terminated with a fatal connection. Thus, any connection terminated with a fatal alert MUST
alert MUST NOT be resumed. NOT be resumed.
Whenever an implementation encounters a condition which is defined as Whenever an implementation encounters a condition which is defined as
a fatal alert, it MUST send the appropriate alert prior to closing a fatal alert, it MUST send the appropriate alert prior to closing
the connection. For all errors where an alert level is not the connection. For all errors where an alert level is not
explicitly specified, the sending party MAY determine at its explicitly specified, the sending party MAY determine at its
discretion whether to treat this as a fatal error or not. If the discretion whether to treat this as a fatal error or not. If the
implementation chooses to send an alert but intends to close the implementation chooses to send an alert but intends to close the
connection immediately afterwards, it MUST send that alert at the connection immediately afterwards, it MUST send that alert at the
fatal alert level. fatal alert level.
If an alert with a level of warning is sent and received, generally If an alert with a level of warning is sent and received, generally
the connection can continue normally. If the receiving party decides the connection can continue normally. If the receiving party decides
not to proceed with the connection (e.g., after having received a not to proceed with the connection (e.g., after having received a
"no_renegotiation" alert that it is not willing to accept), it SHOULD "user_canceled" alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection. Given this, the send a fatal alert to terminate the connection. Given this, the
sending party cannot, in general, know how the receiving party will sending peer cannot, in general, know how the receiving party will
behave. Therefore, warning alerts are not very useful when the behave. Therefore, warning alerts are not very useful when the
sending party wants to continue the connection, and thus are sending party wants to continue the connection, and thus are
sometimes omitted. For example, if a peer decides to accept an sometimes omitted. For example, if a party decides to accept an
expired certificate (perhaps after confirming this with the user) and expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a wants to continue the connection, it would not generally send a
"certificate_expired" alert. "certificate_expired" alert.
The following error alerts are defined: The following error alerts are defined:
unexpected_message unexpected_message
An inappropriate message was received. This alert is always fatal An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper and should never be observed in communication between proper
implementations. implementations.
bad_record_mac bad_record_mac
This alert is returned if a record is received which cannot be This alert is returned if a record is received which cannot be
deprotected. Because AEAD algorithms combine decryption and deprotected. Because AEAD algorithms combine decryption and
verification, this message is used for all deprotection failures. verification, this alert is used for all deprotection failures.
This message is always fatal and should never be observed in This alert is always fatal and should never be observed in
communication between proper implementations (except when messages communication between proper implementations (except when messages
were corrupted in the network). were corrupted in the network).
decryption_failed_RESERVED decryption_failed_RESERVED
This alert was used in some earlier versions of TLS, and may have This alert was used in some earlier versions of TLS, and may have
permitted certain attacks against the CBC mode [CBCATT]. It MUST permitted certain attacks against the CBC mode [CBCATT]. It MUST
NOT be sent by compliant implementations. This message is always NOT be sent by compliant implementations. This alert is always
fatal. fatal.
record_overflow record_overflow
A TLSCiphertext record was received that had a length more than A TLSCiphertext record was received that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSPlaintext record 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record
with more than 2^14 bytes. This message is always fatal and with more than 2^14 bytes. This alert is always fatal and should
should never be observed in communication between proper never be observed in communication between proper implementations
implementations (except when messages were corrupted in the (except when messages were corrupted in the network).
network).
decompression_failure_RESERVED decompression_failure_RESERVED
This alert was used in previous versions of TLS. TLS 1.3 does not This alert was used in previous versions of TLS. TLS 1.3 does not
include compression and TLS 1.3 implementations MUST NOT send this include compression and TLS 1.3 implementations MUST NOT send this
alert when in TLS 1.3 mode. This message is always fatal. alert when in TLS 1.3 mode. This alert is always fatal.
handshake_failure handshake_failure
Reception of a "handshake_failure" alert message indicates that Reception of a "handshake_failure" alert message indicates that
the sender was unable to negotiate an acceptable set of security the sender was unable to negotiate an acceptable set of security
parameters given the options available. This message is always parameters given the options available. This alert is always
fatal. fatal.
no_certificate_RESERVED no_certificate_RESERVED
This alert was used in SSL 3.0 but not any version of TLS. It This alert was used in SSL 3.0 but not any version of TLS. It
MUST NOT be sent by compliant implementations. This message is MUST NOT be sent by compliant implementations. This alert is
always fatal. always fatal.
bad_certificate bad_certificate
A certificate was corrupt, contained signatures that did not A certificate was corrupt, contained signatures that did not
verify correctly, etc. verify correctly, etc.
unsupported_certificate unsupported_certificate
A certificate was of an unsupported type. A certificate was of an unsupported type.
certificate_revoked certificate_revoked
skipping to change at page 27, line 33 skipping to change at page 27, line 51
certificate_expired certificate_expired
A certificate has expired or is not currently valid. A certificate has expired or is not currently valid.
certificate_unknown certificate_unknown
Some other (unspecified) issue arose in processing the Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable. certificate, rendering it unacceptable.
illegal_parameter illegal_parameter
A field in the handshake was out of range or inconsistent with A field in the handshake was out of range or inconsistent with
other fields. This message is always fatal. other fields. This alert is always fatal.
unknown_ca unknown_ca
A valid certificate chain or partial chain was received, but the A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This be located or couldn't be matched with a known, trusted CA. This
message is always fatal. alert is always fatal.
access_denied access_denied
A valid certificate was received, but when access control was A valid certificate or PSK was received, but when access control
applied, the sender decided not to proceed with negotiation. This was applied, the sender decided not to proceed with negotiation.
message is always fatal. This alert is always fatal.
decode_error decode_error
A message could not be decoded because some field was out of the A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect. This specified range or the length of the message was incorrect. This
message is always fatal and should never be observed in alert is always fatal and should never be observed in
communication between proper implementations (except when messages communication between proper implementations (except when messages
were corrupted in the network). were corrupted in the network).
decrypt_error decrypt_error
A handshake cryptographic operation failed, including being unable A handshake cryptographic operation failed, including being unable
to correctly verify a signature or validate a Finished message. to correctly verify a signature or validate a Finished message.
This message is always fatal. This alert is always fatal.
export_restriction_RESERVED export_restriction_RESERVED
This alert was used in some earlier versions of TLS. It MUST NOT This alert was used in some earlier versions of TLS. It MUST NOT
be sent by compliant implementations. This message is always be sent by compliant implementations. This alert is always fatal.
fatal.
protocol_version protocol_version
The protocol version the peer has attempted to negotiate is The protocol version the peer has attempted to negotiate is
recognized but not supported. (For example, old protocol versions recognized but not supported. (For example, old protocol versions
might be avoided for security reasons.) This message is always might be avoided for security reasons.) This alert is always
fatal. fatal.
insufficient_security insufficient_security
Returned instead of "handshake_failure" when a negotiation has Returned instead of "handshake_failure" when a negotiation has
failed specifically because the server requires ciphers more failed specifically because the server requires ciphers more
secure than those supported by the client. This message is always secure than those supported by the client. This alert is always
fatal. fatal.
internal_error internal_error
An internal error unrelated to the peer or the correctness of the An internal error unrelated to the peer or the correctness of the
protocol (such as a memory allocation failure) makes it impossible protocol (such as a memory allocation failure) makes it impossible
to continue. This message is always fatal. to continue. This alert is always fatal.
user_canceled inappropriate_fallback
This handshake is being canceled for some reason unrelated to a Sent by a server in response to an invalid connection retry
protocol failure. If the user cancels an operation after the attempt from a client. (see [RFC7507]) This alert is always fatal.
handshake is complete, just closing the connection by sending a
"close_notify" is more appropriate. This alert should be followed
by a "close_notify". This message is generally a warning.
no_renegotiation no_renegotiation_RESERVED
Sent by the client in response to a HelloRequest or by the server This alert was used in previous versions of TLS. TLS 1.3 does not
in response to a ClientHello after initial handshaking. Versions include renegotiation and TLS 1.3 implementations MUST NOT send
of TLS prior to TLS 1.3 supported renegotiation of a previously this alert when in TLS 1.3 mode. This alert is always fatal.
established connection; TLS 1.3 removes this feature. This
message is always fatal. missing_extension
Sent by endpoints that receive a hello message not containing an
extension that is mandatory to send for the offered TLS version.
This message is always fatal. [[TODO: IANA Considerations.]]
unsupported_extension unsupported_extension
sent by clients that receive an extended ServerHello containing an Sent by endpoints receiving any hello message containing an
extension that they did not put in the corresponding ClientHello. extension known to be prohibited for inclusion in the given hello
This message is always fatal. message, including any extensions in a ServerHello not first
offered in the corresponding ClientHello. This alert is always
fatal.
certificate_unobtainable
Sent by servers when unable to obtain a certificate from a URL
provided by the client via the "client_certificate_url" extension
[RFC6066].
unrecognized_name
Sent by servers when no server exists identified by the name
provided by the client via the "server_name" extension [RFC6066].
bad_certificate_status_response
Sent by clients when an invalid or unacceptable OCSP response is
provided by the server via the "status_request" extension
[RFC6066]. This alert is always fatal.
bad_certificate_hash_value
Sent by servers when a retrieved object does not have the correct
hash provided by the client via the "client_certificate_url"
extension [RFC6066]. This alert is always fatal.
unknown_psk_identity
Sent by servers when a PSK cipher suite is selected but no
acceptable PSK identity is provided by the client. Sending this
alert is OPTIONAL; servers MAY instead choose to send a
"decrypt_error" alert to merely indicate an invalid PSK identity.
[[TODO: This doesn't really make sense with the current PSK
negotiation scheme where the client provides multiple PSKs in
flight 1. https://github.com/tlswg/tls13-spec/issues/230]]
New Alert values are assigned by IANA as described in Section 11. New Alert values are assigned by IANA as described in Section 11.
6.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 establish shared secret optionally authenticate each other, and establish shared secret
skipping to change at page 30, line 5 skipping to change at page 31, line 5
Static Secret (SS): A secret which may be derived from static or Static Secret (SS): A secret which may be derived from static or
semi-static keying material, such as a pre-shared key or the server's semi-static keying material, such as a pre-shared key or the server's
semi-static (EC)DH share. semi-static (EC)DH share.
In some cases, as with the DH handshake shown in Figure 1, these In some cases, as with the DH handshake shown in Figure 1, these
secrets are the same, but having both allows for a uniform key secrets are the same, but having both allows for a uniform key
derivation scheme for all cipher modes. derivation scheme for all cipher modes.
The basic TLS Handshake for DH is shown in Figure 1: The basic TLS Handshake for DH is shown in Figure 1:
Client Server Client Server
ClientHello ClientHello
+ ClientKeyShare --------> + ClientKeyShare -------->
ServerHello ServerHello
ServerKeyShare* ServerKeyShare*
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
* Indicates optional or situation-dependent messages that are not always sent. * Indicates optional or situation-dependent
messages that are not always sent.
{} Indicates messages protected using keys derived from the ephemeral secret. {} Indicates messages protected using keys
derived from the ephemeral secret.
[] Indicates messages protected using keys derived from the master secret. [] Indicates messages protected using keys
derived from the master secret.
Figure 1: Message flow for full TLS Handshake Figure 1: Message flow for full TLS Handshake
The first message sent by the client is the ClientHello The first message sent by the client is the ClientHello
Section 6.3.1.1 which contains a random nonce (ClientHello.random), Section 6.3.1.1 which contains a random nonce (ClientHello.random),
its offered protocol version, cipher suite, and extensions, and one its offered protocol version, cipher suite, and extensions, and one
or more Diffie-Hellman key shares in the ClientKeyShare extension or more Diffie-Hellman key shares in the ClientKeyShare extension
Section 6.3.1.5. Section 6.3.2.3.
The server processes the ClientHello and determines the appropriate The server processes the ClientHello and determines the appropriate
cryptographic parameters for the connection. It then responds with cryptographic parameters for the connection. It then responds with
the following messages: the following messages:
ServerHello ServerHello
indicates the negotiated connection parameters. [Section 6.3.1.2] indicates the negotiated connection parameters. [Section 6.3.1.2]
ServerKeyShare ServerKeyShare
the server's ephemeral Diffie-Hellman Share which must be in the the server's ephemeral Diffie-Hellman Share which must be in the
same group as one of the shares offered by the client. This 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 message will be omitted if DH is not in use (i.e., a pure PSK
cipher suite is selected). The ClientKeyShare and ServerKeyShare cipher suite is selected). The ClientKeyShare and ServerKeyShare
are used together to derive the Static Secret and Ephemeral Secret are used together to derive the Static Secret and Ephemeral Secret
(in this mode they are the same). [Section 6.3.2] (in this mode they are the same). [Section 6.3.3]
ServerConfiguration ServerConfiguration
supplies a configuration for a future handshake (see supplies a configuration for 0-RTT handshakes (see Section 6.2.2).
Section 6.2.2). [Section 6.3.6] [Section 6.3.7]
EncryptedExtensions EncryptedExtensions
responses to any extensions which are not required in order to responses to any extensions which are not required in order to
determine the cryptographic parameters. [Section 6.3.3] determine the cryptographic parameters. [Section 6.3.4]
Certificate Certificate
the server certificate. This message will be omitted if the the server certificate. This message will be omitted if the
server is not authenticating via a certificates. [Section 6.3.4] server is not authenticating via a certificates. [Section 6.3.5]
CertificateRequest CertificateRequest
if certificate-based client authentication is desired, the desired if certificate-based client authentication is desired, the desired
parameters for that certificate. This message will be omitted if parameters for that certificate. This message will be omitted if
client authentication is not desired. [[OPEN ISSUE: See client authentication is not desired. [[OPEN ISSUE: See
https://github.com/tlswg/tls13-spec/issues/184]]. [Section 6.3.5] https://github.com/tlswg/tls13-spec/issues/184]]. [Section 6.3.6]
CertificateVerify CertificateVerify
a signature over the entire handshake using the public key in the a signature over the entire handshake using the public key in the
Certificate message. This message will be omitted if the server Certificate message. This message will be omitted if the server
is not authenticating via a certificate. [Section 6.3.7] is not authenticating via a certificate. [Section 6.3.8]
Finished Finished
a MAC over the entire handshake computed using the Static Secret. a MAC over the entire handshake computed using the Static Secret.
This message provides key confirmation and In some modes (see This message provides key confirmation and In some modes (see
Section 6.2.2) it also authenticates the handshake using the the Section 6.2.2) it also authenticates the handshake using the the
Static Secret. [Section 6.3.8] Static Secret. [Section 6.3.9]
Upon receiving the server's messages, the client responds with his Upon receiving the server's messages, the client responds with his
final flight of messages: final flight of messages:
Certificate Certificate
the client's certificate. This message will be omitted if the the client's certificate. This message will be omitted if the
client is not authenticating via a certificates. [Section 6.3.9] client is not authenticating via a certificates. [Section 6.3.10]
CertificateVerify CertificateVerify
a signature over the entire handshake using the public key in the a signature over the entire handshake using the private key
Certificate message. This message will be omitted if the client corresponding to the public key in the Certificate message. This
is not authenticating via a certificate. [Section 6.3.10] message will be omitted if the client is not authenticating via a
certificate. [Section 6.3.11]
Finished Finished
a MAC over the entire handshake computed using the Static Secret a MAC over the entire handshake computed using the Static Secret
and providing key confirmation. [Section 6.3.8] and providing key confirmation. [Section 6.3.9]
At this point, the handshake is complete, and the client and server At this point, the handshake is complete, and the client and server
may exchange application layer data. Application data MUST NOT be may exchange application layer data. Application data MUST NOT be
sent prior to sending the Finished message. If client authentication sent prior to sending the Finished message. If client authentication
is requested, the server MUST NOT send application data before it is requested, the server MUST NOT send application data before it
receives the client's Finished. receives the client's Finished.
[[TODO: Move this elsewhere? Note that higher layers should not be [[TODO: Move this elsewhere? Note that higher layers should not be
overly reliant on whether TLS always negotiates the strongest overly reliant on whether TLS always negotiates the strongest
possible connection between two peers. There are a number of ways in possible connection between two endpoints. There are a number of
which a man-in-the-middle attacker can attempt to make two entities ways in which a man-in-the-middle attacker can attempt to make two
drop down to the least secure method they support. The protocol has entities drop down to the least secure method they support (i.e.,
been designed to minimize this risk, but there are still attacks perform a downgrade attack). The TLS protocol has been designed to
available. For example, an attacker could block access to the port a minimize this risk, but there are still attacks available: for
secure service runs on or attempt to get the peers to negotiate an example, an attacker could block access to the port a secure service
unauthenticated connection. The fundamental rule is that higher runs on, or attempt to get the peers to negotiate an unauthenticated
levels must be cognizant of what their security requirements are and connection. The fundamental rule is that higher levels must be
never transmit information over a channel less secure than what they cognizant of what their security requirements are and never transmit
require. The TLS protocol is secure in that any cipher suite offers information over a channel less secure than what they require. The
its promised level of security: if you negotiate AES-GCM [GCM] with a TLS protocol is secure in that any cipher suite offers its promised
255-bit ECDHE key exchange with a host whose certificate chain you level of security: if you negotiate AES-GCM [GCM] with a 255-bit
have verified, you can expect that to be reasonably "secure" against 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.]] algorithmic attacks, at least in the year 2015.]]
6.2.1. Incorrect DHE Share 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}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
skipping to change at page 33, line 39 skipping to change at page 34, line 39
[[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 "handshake_failure" or "insufficient_security" fatal
alert (see Section 6.1).
TLS also allows several optimized variants of the basic handshake, as TLS also allows several optimized variants of the basic handshake, as
described below. described below.
6.2.2. Cached Server Configuration 6.2.2. Zero-RTT Exchange
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).
When a known configuration is used, the server's long-term DHE key is
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 TLS 1.3 supports a "0-RTT" mode in which the client can send
application data as well as its Certificate and CertificateVerify (if application data as well as its Certificate and CertificateVerify (if
client authentication is requested) on its first flight, thus client authentication is requested) on its first flight, thus
reducing handshake latency, as shown below. reducing handshake latency. In order to enable this functionality,
the server provides a ServerConfiguration message containing a long-
term (EC)DH share. On future connections to the same server, the
client can use that share to encrypt the first-flight data.
Client Server Client Server
ClientHello ClientHello
+ ClientKeyShare + ClientKeyShare
(Certificate*) + EarlyDataIndication
(CertificateVerify*) (EncryptedExtensions)
(Application Data) --------> (Certificate*)
ServerHello (CertificateVerify*)
ServerKeyShare (Application Data) -------->
<-------- {Finished} ServerHello
{Finished} --------> + EarlyDataIndication
ServerKeyShare
{EncryptedExtensions}
{ServerConfiguration*}
{Certificate*}
{CertificateRequest*}
{CertificateVerify*}
<-------- {Finished}
{Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
() Indicates messages protected using keys derived from the static secret. () Indicates messages protected using keys
derived from the static secret.
Figure 3: Message flow for a zero round trip handshake Figure 3: Message flow for a zero round trip handshake
Note: because sequence numbers continue to increment between the Note: because sequence numbers continue to increment between the
initial (early) application data and the application data sent after initial (early) application data and the application data sent after
the handshake has complete, an attacker cannot remove early the handshake has completed, an attacker cannot remove early
application data messages. application data messages.
IMPORTANT NOTE: The security properties for 0-RTT data (regardless of IMPORTANT NOTE: The security properties for 0-RTT data (regardless of
the cipher suite) are weaker than those for other kinds of TLS data. the cipher suite) are weaker than those for other kinds of TLS data.
Specifically. Specifically.
1. This data is not forward secure, because it is encrypted solely 1. This data is not forward secure, because it is encrypted solely
with the server's semi-static (EC)DH share. with the server's semi-static (EC)DH share.
2. There are no guarantees of non-replay between connections. 2. There are no guarantees of non-replay between connections.
Unless the server takes special measures outside those provided Unless the server takes special measures outside those provided
by TLS (See Section 6.3.1.5.5.1), the server has no guarantee by TLS (See Section 6.3.2.5.2), the server has no guarantee that
that the same 0-RTT data was not transmitted on multiple 0-RTT the same 0-RTT data was not transmitted on multiple 0-RTT
connections. This is especially relevant if the data is connections. This is especially relevant if the data is
authenticated either with TLS client authentication or inside the authenticated either with TLS client authentication or inside the
application layer protocol. However, 0-RTT data cannot be application layer protocol. However, 0-RTT data cannot be
duplicated within a connection (i.e., the server will not process duplicated within a connection (i.e., the server will not process
the same data twice for the same connection) and also cannot be the same data twice for the same connection) and also cannot be
sent as if it were ordinary TLS data. sent as if it were ordinary TLS data.
3. If the server key is compromised, and client authentication is 3. If the server key is compromised, and client authentication is
used, then the attacker can impersonate the client to the server used, then the attacker can impersonate the client to the server
(as it knows the traffic key). (as it knows the traffic key).
6.2.4. Resumption and PSK 6.2.3. Resumption and PSK
Finally, TLS provides a pre-shared key (PSK) mode which allows a Finally, TLS provides a pre-shared key (PSK) mode which allows a
client and server who share an existing secret (e.g., a key client and server who share an existing secret (e.g., a key
established out of band) to establish a connection authenticated by established out of band) to establish a connection authenticated by
that key. PSKs can also be established in a previous session and that key. PSKs can also be established in a previous session and
then reused ("session resumption"). Once a handshake has completed, then reused ("session resumption"). Once a handshake has completed,
the server can send the client a PSK identity which corresponds to a 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 key derived from the initial handshake (See Section 6.3.12). The
client can then use that PSK identity in future handshakes to client can then use that PSK identity in future handshakes to
negotiate use of the PSK; if the server accepts it, then the security 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 context of the original connection is tied to the new connection. In
TLS 1.2 and below, this functionality was provided by "session TLS 1.2 and below, this functionality was provided by "session
resumption" and "session tickets" [RFC5077]. Both mechanisms are resumption" and "session tickets" [RFC5077]. Both mechanisms are
obsoleted in TLS 1.3. obsoleted in TLS 1.3.
PSK ciphersuites can either use PSK in combination with an (EC)DHE PSK cipher suites can either use PSK in combination with an (EC)DHE
exchange in order to provide forward secrecy in combination with exchange in order to provide forward secrecy in combination with
shared keys, or can use PSKs alone, at the cost of losing forward shared keys, or can use PSKs alone, at the cost of losing forward
secrecy. secrecy.
Figure 4 shows a pair of handshakes in which the first establishes a Figure 4 shows a pair of handshakes in which the first establishes a
PSK and the second uses it: PSK and the second uses it:
Client Server Client Server
Initial Handshake: Initial Handshake:
skipping to change at page 36, line 8 skipping to change at page 37, line 8
exchange in order to provide forward secrecy in combination with exchange in order to provide forward secrecy in combination with
shared keys, or can use PSKs alone, at the cost of losing forward shared keys, or can use PSKs alone, at the cost of losing forward
secrecy. secrecy.
Figure 4 shows a pair of handshakes in which the first establishes a Figure 4 shows a pair of handshakes in which the first establishes a
PSK and the second uses it: PSK and the second uses it:
Client Server Client Server
Initial Handshake: Initial Handshake:
ClientHello ClientHello
+ ClientKeyShare --------> + ClientKeyShare -------->
ServerHello ServerHello
ServerKeyShare ServerKeyShare
{EncryptedExtensions} {EncryptedExtensions}
{ServerConfiguration*} {ServerConfiguration*}
{Certificate*} {Certificate*}
{CertificateRequest*} {CertificateRequest*}
{CertificateVerify*} {CertificateVerify*}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{CertificateVerify*} {CertificateVerify*}
{Finished} --------> {Finished} -------->
<-------- [NewSessionTicket] <-------- [NewSessionTicket]
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Subsequent Handshake: Subsequent Handshake:
ClientHello ClientHello
+ ClientKeyShare, + ClientKeyShare,
PreSharedKeyExtension --------> PreSharedKeyExtension -------->
ServerHello ServerHello
+PreSharedKeyExtension +PreSharedKeyExtension
{EncryptedExtensions}
<-------- {Finished} <-------- {Finished}
{Certificate*} {Certificate*}
{Finished} --------> {Finished} -------->
[Application Data] <-------> [Application Data] [Application Data] <-------> [Application Data]
Figure 4: Message flow for resumption and PSK Figure 4: Message flow for resumption and PSK
Note that the client supplies a ClientKeyShare to the server as well, 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 which allows the server to decline resumption and fall back to a full
handshake. However, because the server is authenticating via a PSK, handshake. However, because the server is authenticating via a PSK,
skipping to change at page 37, line 12 skipping to change at page 38, line 18
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 or TLSCiphertext structures, which are processed and TLSPlaintext or TLSCiphertext structures, which are processed and
transmitted as 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),
session_ticket(4), 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), server_configuration(14), certificate_request(13), server_configuration(17),
certificate_verify(15), 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 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 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; case session_ticket: NewSessionTicket;
} body; } body;
} Handshake; } Handshake;
The handshake protocol messages are presented below in the order they The TLS Handshake Protocol messages are presented below in the order
MUST be sent; sending handshake messages in an unexpected order they MUST be sent; sending handshake messages in an unexpected order
results in a fatal error. Unneeded handshake messages can be results in an "unexpected_message" fatal error. Unneeded handshake
omitted, however. messages can be 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 11. Section 11.
6.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.
skipping to change at page 38, line 18 skipping to change at page 39, line 18
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) except including send the same ClientHello (without modification) except including
a new ClientKeyShare. [[OPEN ISSUE: New random values? See: a new ClientKeyShare. [[OPEN ISSUE: New random values? See:
https://github.com/tlswg/tls13-spec/issues/185]] If a server https://github.com/tlswg/tls13-spec/issues/185]] If a server
receives a ClientHello at any other time, it MUST send a fatal receives a ClientHello at any other time, it MUST send a fatal
"no_renegotiation" alert. "unexpected_message" alert and close the connection.
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. See
Appendix B for additional information.
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.
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 hash to be used with HKDF. The server will select key length) and a hash to be used with HKDF. The server will select
skipping to change at page 39, line 35 skipping to change at page 40, line 35
determining whether there are bytes following the compression_methods determining whether there are bytes following the compression_methods
at the end of the ClientHello. Note that this method of detecting at the end of the ClientHello. Note that this method of detecting
optional data differs from the normal TLS method of having a optional data differs from the normal TLS method of having a
variable-length field, but it is used for compatibility with TLS variable-length field, but it is used for compatibility with TLS
before extensions were defined. before extensions were defined.
client_version client_version
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 C for details about backward compatibility.)
random random
A client-generated random structure. A client-generated random structure.
session_id session_id
Versions of TLS prior to TLS 1.3 supported a session resumption Versions of TLS prior to TLS 1.3 supported a session resumption
feature which has been merged with Pre-Shared Keys in this version feature which has been merged with Pre-Shared Keys in this version
(see Section 6.2.4). This field MUST be ignored by a server (see Section 6.2.3). This field MUST be ignored by a server
negotiating TLS 1.3 and should be set as a zero length vector 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 (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. 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. Values are client, with the client's first preference first. Values are
defined in Appendix A.4. defined in Appendix A.4.
compression_methods compression_methods
skipping to change at page 40, line 19 skipping to change at page 41, line 19
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 6.3.1.4. defined in Section 6.3.2.
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.
6.3.1.2. Server Hello 6.3.1.2. 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 extension 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 a "handshake_failure" fatal alert.
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Random random; Random random;
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
there are bytes following the cipher_suite field at the end of the there are bytes following the cipher_suite field at the end of the
ServerHello. ServerHello.
server_version server_version
This field will contain the lower of that suggested by the client This field will contain the lower of that suggested by the client
in the 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 C 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_len
A single 0 value for backward compatible formatting. [[OPEN
ISSUE: Should we remove?]]
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. [[TODO: the value from the state of the session being resumed. [[TODO:
interaction with PSK.]] 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 6.3.3 between the ServerHello and the EncryptedExtensions Section 6.3.4
message. The ServerHello MUST only include extensions which are message. The ServerHello MUST only include extensions which are
required to establish the cryptographic context. required to establish the cryptographic context.
6.3.1.3. 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 Servers send this message in response to a ClientHello message
message when it was able to find an acceptable set of algorithms when it was able to find an acceptable set of algorithms and
and groups that are mutually supported, but the client's groups that are mutually supported, but the client's
ClientKeyShare did not contain an acceptable offer. If it cannot ClientKeyShare did not contain an acceptable offer. If it cannot
find such a match, it will respond with a "handshake_failure" find such a match, it will respond with a "handshake_failure"
alert. 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;
skipping to change at page 43, line 5 skipping to change at page 43, line 44
Otherwise, the client MUST send a ClientHello with a new Otherwise, the client MUST send a ClientHello with a new
ClientKeyShare extension to the server. The ClientKeyShare MUST ClientKeyShare extension to the server. The ClientKeyShare MUST
append a new ClientKeyShareOffer which is consistent with the append a new ClientKeyShareOffer which is consistent with the
"selected_group" field to the groups in the original ClientKeyShare. "selected_group" field to the groups in the original ClientKeyShare.
Upon re-sending the ClientHello and receiving the server's Upon re-sending the ClientHello and receiving the server's
ServerHello/ServerKeyShare, the client MUST verify that the selected ServerHello/ServerKeyShare, the client MUST verify that the selected
CipherSuite and NamedGroup match that supplied in the CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest. HelloRetryRequest.
6.3.1.4. Hello Extensions 6.3.2. 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 {
supported_groups(10),
signature_algorithms(13), signature_algorithms(13),
early_data(TBD), early_data(TBD),
supported_groups(TBD), pre_shared_key(TBD),
known_configuration(TBD), client_key_shares(TBD),
pre_shared_key(TBD)
client_key_shares(TBD)
(65535) (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.
skipping to change at page 45, line 5 skipping to change at page 46, 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.
6.3.1.4.1. Signature Algorithms 6.3.2.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.
contains a "supported_signature_algorithms" value.
All clients MUST send a valid "signature_algorithms" extension
containing at least one supported SignatureAndHashAlgorithm when
offering any certificate authenticated cipher suites. Servers MUST
NOT negotiate use of a certificate authenticated cipher suite unless
the client supplies a supported SignatureAndHashAlgorithm. If the
extension is not provided and no alternative cipher suite is
available, the server MUST close the connection with a fatal
"missing_extension" alert. (see Section 8.2)
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the
connection.
The "extension_data" field of this extension contains a
"supported_signature_algorithms" value:
enum { enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), none(0),
sha512(6), (255) md5_RESERVED(1),
sha1(2),
sha224_RESERVED(3),
sha256(4), sha384(5), 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;
SignatureAlgorithm signature; SignatureAlgorithm signature;
} SignatureAndHashAlgorithm; } SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
Each SignatureAndHashAlgorithm value lists a single hash/signature Each SignatureAndHashAlgorithm value lists a single hash/signature
pair that the client is willing to verify. The values are indicated pair that the client is willing to verify. The values are indicated
in descending order of preference. in descending order of preference.
Note: Because not all signature algorithms and hash algorithms may be Note: Because not all signature algorithms and hash algorithms may be
accepted by an implementation (e.g., DSA with SHA-1, but not SHA- accepted by an implementation (e.g., DSA with SHA-1, but not SHA-
256), algorithms here are listed in pairs. 256), algorithms here are listed in pairs.
hash hash
This field indicates the hash algorithm which may be used. The This field indicates the hash algorithms which may be used. The
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.
The use of MD5 and SHA-224 are deprecated. The md5_RESERVED and
sha224_RESERVED values MUST NOT be offered or negotiated by any
implementation.
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], 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 6.3.2. It MUST NOT appear in this extension. Section 6.3.3. It MUST NOT appear in this extension.
The semantics of this extension are somewhat complicated because the The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash cipher suite indicates permissible signature algorithms but not hash
algorithms. Section 6.3.4 and Section 6.3.2 describe the appropriate algorithms. Section 6.3.5 and Section 6.3.3 describe the appropriate
rules. rules.
If the client supports only the default hash and signature algorithms Note: TLS 1.3 servers MAY receive TLS 1.2 ClientHellos which do not
(listed in this section), it MAY omit the signature_algorithms contain this extension. If those servers are willing to negotiate
extension. If the client does not support the default algorithms, or TLS 1.2, they MUST behave in accordance with the requirements of
supports other hash and signature algorithms (and it is willing to [RFC5246].
use them for verifying messages sent by the server, i.e., server
certificates and server key share), it MUST send the
signature_algorithms extension, listing the algorithms it is willing
to accept.
If the client does not send the signature_algorithms extension, the
server MUST do the following:
- If the negotiated key exchange algorithm is one of (DHE_RSA,
ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.
- If the negotiated key exchange algorithm is DHE_DSS, behave as if
the client had sent the value {sha1,dsa}.
- If the negotiated key exchange algorithm is ECDHE_ECDSA, behave as
if the client had sent value {sha1,ecdsa}.
Note: This extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in
[RFC6066] require servers to ignore extensions they do not
understand.
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension.
6.3.1.4.2. Negotiated Groups 6.3.2.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 All clients MUST send a valid "supported_groups" extension containing
at least one group for each ephemeral key exchange algorithm
(currently DHE and ECDHE) for which it offers a cipher suite.
Servers MUST NOT negotiate use of a DHE or ECDHE cipher suites unless
the client supplies a supported NamedGroup. If the extension is not
provided and no alternative cipher suite is available, the server
MUST close the connection with a fatal "missing_extension" alert.
(see Section 8.2) If the extension is provided, but no compatible
group is offered, the server MUST NOT negotiate a cipher suite of the
relevant type. For instance, if a client supplies only ECDHE groups,
the server MUST NOT negotiate finite field Diffie-Hellman. If no
acceptable group can be selected across all cipher suites, then the
server MUST generate a fatal "handshake_failure" alert.
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the
connection.
The "extension_data" field of this extension contains a
"NamedGroupList" value: "NamedGroupList" value:
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups.
sect163k1 (1), sect163r1 (2), sect163r2 (3), obsolete_RESERVED (1..22),
sect193r1 (4), sect193r2 (5), sect233k1 (6), secp256r1 (23), secp384r1 (24), secp521r1 (25),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
// Finite Field Groups. // Finite Field Groups.
ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe6144 (259), ffdhe8192 (260), ffdhe6144 (259), ffdhe8192 (260),
ffdhe_private_use (0x01FC..0x01FF), ffdhe_private_use (0x01FC..0x01FF),
// Reserved Code Points. // Reserved Code Points.
reserved (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
reserved(0xFF01), obsolete_RESERVED (0xFF01..0xFF02),
reserved(0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1>; NamedGroup named_group_list<1..2^16-1>;
} NamedGroupList; } NamedGroupList;
sect163k1, etc secp256r1, etc.
Indicates support of the corresponding named curve The named Indicates support of the corresponding named curve. Note that
curves defined here are those specified in SEC 2 [13]. Note that some curves are also recommended in ANSI X9.62 [X962] and FIPS
many of these curves are also recommended in ANSI X9.62 [X962] and 186-2 [DSS]. Values 0xFE00 through 0xFEFF are reserved for
FIPS 186-2 [DSS]. Values 0xFE00 through 0xFEFF are reserved for private use.
private use. Values 0xFF01 and 0xFF02 were used in previous
versions of TLS but MUST NOT be offered by TLS 1.3
implementations. [[OPEN ISSUE: Triage curve list.]]
ffdhe2432, etc ffdhe2048, etc.
Indicates support of the corresponding finite field group, defined Indicates support of the corresponding finite field group, defined
in [I-D.ietf-tls-negotiated-ff-dhe] in [I-D.ietf-tls-negotiated-ff-dhe]. Values 0x01FC through 0x01FF
are reserved for private use.
Values within "obsolete_RESERVED" ranges were used in previous
versions of TLS and MUST NOT be offered or negotiated by TLS 1.3
implementations. The obsolete curves have various known/theoretical
weaknesses or have had very little usage, in some cases only due to
unintentional server configuration issues. They are no longer
considered appropriate for general use and should be assumed to be
potentially unsafe. The set of curves specified here is sufficient
for interoperability with all currently deployed and properly
configured TLS implementations.
Items in named_curve_list are ordered according to the client's Items in named_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (most preferred choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192; As an example, a client that only supports secp256r1 (aka NIST P-256;
value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018)
and prefers to use secp192r1 would include a TLS extension consisting and prefers to use secp256r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the of the following octets. Note that the first two octets indicate the
extension type (Supported Group Extension): extension type (Supported Group Extension):
00 0A 00 06 00 04 00 13 00 15 00 0A 00 06 00 04 00 17 00 18
The client MUST supply a "named_groups" extension containing at least
one group for each key exchange algorithm (currently DHE and ECDHE)
for which it offers a cipher suite. If the client does not supply a
"named_groups" extension with a compatible group, the server MUST NOT
negotiate a cipher suite of the relevant type. For instance, if a
client supplies only ECDHE groups, the server MUST NOT negotiate
finite field Diffie-Hellman. If no acceptable group can be selected
across all cipher suites, then the server MUST generate a fatal
"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 ServerKeyShare 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.]]
6.3.1.5. Client Key Share 6.3.2.3. Client Key Share
The client_key_share extension MUST be provided by the client if it The "client_key_share" extension contains the client's cryptographic
offers any cipher suites that involve non-PSK (currently DHE or parameters for zero or more non-PSK key establishment methods
ECDHE) key exchange. It contains the client's cryptographic (currently DHE or ECDHE).
parameters for zero or more key establishment methods. [[OPEN ISSUE:
Would it be better to omit it if it's empty?.
https://github.com/tlswg/tls13-spec/issues/190]]
Meaning of this message: All clients MUST send a valid "client_key_share" extension when
offering any DHE or ECDHE cipher suites. Servers MUST NOT negotiate
use of a DHE or ECDHE cipher suites unless the client supplies a
(possibly empty) "client_key_share" extension. If the extension is
not provided and no alternative cipher suite is available, the server
MUST close the connection with a fatal "missing_extension" alert.
(see Section 8.2)
Servers MUST NOT send this extension. TLS servers MUST support
receiving this extension. Clients receiving this extension MUST
respond with an "unsupported_extension" alert and close the
connection.
[[OPEN ISSUE: Would it be better to omit it if it's empty?.
https://github.com/tlswg/tls13-spec/issues/190]]
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} ClientKeyShareOffer; } ClientKeyShareOffer;
group group
The named group for the key share offer. This identifies the The named group for the key share offer. This identifies the
specific key exchange method that the ClientKeyShareOffer specific key exchange method that the ClientKeyShareOffer
describes. Finite Field Diffie-Hellman [DH] parameters are describes. Finite Field Diffie-Hellman [DH] parameters are
described in Section 6.3.1.5.1; Elliptic Curve Diffie-Hellman described in Section 6.3.2.3.1; Elliptic Curve Diffie-Hellman
parameters are described in Section 6.3.1.5.2. parameters are described in Section 6.3.2.3.2.
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.
The "extension_data" field of this extension contains a
"ClientKeyShare" value:
struct { struct {
ClientKeyShareOffer offers<0..2^16-1>; ClientKeyShareOffer offers<0..2^16-1>;
} ClientKeyShare; } ClientKeyShare;
offers offers
A list of ClientKeyShareOffer values in descending order of client A list of ClientKeyShareOffer values in descending order of client
preference. preference.
Clients may offer an arbitrary number of ClientKeyShareOffer values, Clients may offer an arbitrary number of ClientKeyShareOffer values,
each representing a single set of key agreement parameters; for each representing a single set of key agreement parameters; for
instance a client might offer shares for several elliptic curves or instance a client might offer shares for several elliptic curves or
multiple integer DH groups. The shares for each ClientKeyShareOffer multiple integer DH groups. The shares for each ClientKeyShareOffer
MUST by generated independently. Clients MUST NOT offer multiple MUST by generated independently. Clients MUST NOT offer multiple
ClientKeyShareOffers for the same parameters. It is explicitly ClientKeyShareOffers for the same parameters. It is explicitly
permitted to send an empty client_key_share extension as this is used permitted to send an empty "client_key_share" extension as this is
to elicit the server's parameters if the client has no useful used to elicit the server's parameters if the client has no useful
information. [TODO: Recommendation about what the client offers. information.
Presumably which integer DH groups and which curves.]
6.3.1.5.1. Diffie-Hellman Parameters [[TODO: Recommendation about what the client offers. Presumably
which integer DH groups and which curves.]]
6.3.2.3.1. Diffie-Hellman Parameters
Diffie-Hellman [DH] parameters for both clients and servers are Diffie-Hellman [DH] parameters for both clients and servers are
encoded in the opaque key_exchange field of the ClientKeyShareOffer encoded in the opaque key_exchange field of the ClientKeyShareOffer
or ServerKeyShare structures. The opaque value contains the Diffie- or ServerKeyShare structures. The opaque value contains the Diffie-
Hellman public value (dh_Y = g^X mod p), encoded as a big-endian Hellman public value (dh_Y = g^X mod p), encoded as a big-endian
integer. integer.
opaque dh_Y<1..2^16-1>; opaque dh_Y<1..2^16-1>;
6.3.1.5.2. ECDHE Parameters 6.3.2.3.2. ECDHE Parameters
ECDHE parameters for both clients and servers are encoded in the ECDHE parameters for both clients and servers are encoded in the
opaque key_exchange field of the ClientKeyShareOffer or opaque key_exchange field of the ClientKeyShareOffer or
ServerKeyShare structures. The opaque value conveys the Elliptic ServerKeyShare structures. The opaque value conveys the Elliptic
Curve Diffie-Hellman public value (ecdh_Y) represented as a byte Curve Diffie-Hellman public value (ecdh_Y) represented as a byte
string ECPoint.point. string ECPoint.point.
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
point point
skipping to change at page 50, line 20 skipping to change at page 51, line 37
Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 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 1.3 removes this feature in favor of a single point format for each
curve. curve.
[[OPEN ISSUE: We will need to adjust the compressed/uncompressed [[OPEN ISSUE: We will need to adjust the compressed/uncompressed
point issue if we have new curves that don't need point compression. point issue if we have new curves that don't need point compression.
This depends on the CFRG's recommendations. The expectation is that This depends on the CFRG's recommendations. The expectation is that
future curves will come with defined point formats and that existing future curves will come with defined point formats and that existing
curves conform to X9.62.]] curves conform to X9.62.]]
6.3.1.5.3. Known Configuration Extension 6.3.2.4. Pre-Shared Key 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).
The pre_shared_key extension is used to indicate the identity of the All clients MUST send a valid "pre_shared_key" extension when
pre-shared key to be used with a given handshake in association with offering any PSK cipher suites. Servers MUST NOT negotiate use of a
a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background). PSK cipher suite unless the client supplies a "pre_shared_key"
extension. If the extension is not provided and no alternative
cipher suite is available, the server MUST close the connection with
a fatal "missing_extension" alert. (see Section 8.2)
opaque psk_identity<0..2^16-1>; The "extension_data" field of this extension contains a
"PreSharedKeyExtension" value:
struct { opaque psk_identity<0..2^16-1>;
select (Role) {
case client:
psk_identity identities<0..2^16-1>;
case server: struct {
psk_identity identity; select (Role) {
case client:
psk_identity identities<0..2^16-1>;
} PreSharedKeyExtension; case server:
psk_identity identity;
}
} PreSharedKeyExtension;
identifier identity
An opaque label for the pre-shared key. An opaque label for the pre-shared key.
When the client offers a PSK cipher suite, it MUST also supply a If no suitable identity is provided, the server MUST NOT negotiate a
PreSharedKeyExtension to indicate the PSK(s) to be used. If no such PSK cipher suite and MAY respond with an "unknown_psk_identity" alert
extension is present, the server MUST NOT negotiate a PSK cipher message. Sending this alert is OPTIONAL; servers MAY instead choose
suite. If no suitable identity is present, the server MUST NOT to send a "decrypt_error" alert to merely indicate an invalid PSK
negotiate a PSK cipher suite. identity or instead negotiate use of a non-PSK cipher suite, if
available.
If the server selects a PSK cipher suite, it MUST send a If the server selects a PSK cipher suite, it MUST send a
PreSharedKeyExtension with the identity that it selected. The client PreSharedKeyExtension with the identity that it selected. The client
MUST verify that the server has selected one of the identities that MUST verify that the server has selected one of the identities that
the client supplied. If any other identity is returned, the client the client supplied. If any other identity is returned, the client
MUST generate a fatal "handshake_failure" alert. MUST generate a fatal "unknown_psk_identity" alert and close the
connection.
6.3.1.5.5. Early Data Indication 6.3.2.5. Early Data Indication
In cases where TLS clients have previously interacted with the server In cases where TLS clients have previously interacted with the server
and the server has supplied a known configuration, the client can and the server has supplied a ServerConfiguration Section 6.3.7, the
send application data and its Certificate/CertificateVerify messages client can send application data and its Certificate/
(if client authentication is required). If the client opts to do so, CertificateVerify messages (if client authentication is required).
it MUST supply an Early Data Indication extension. This technique If the client opts to do so, it MUST supply an Early Data Indication
MUST only be used along with the "known_configuration" extension. extension.
enum { early_handshake(1), early_data(2), The "extension_data" field of this extension contains an
early_handshake_and_data(3), (255) } EarlyDataType; "EarlyDataIndication" value:
struct { enum { client_authentication(1), early_data(2),
select (Role) { client_authentication_and_data(3), (255) } EarlyDataType;
case client:
opaque context<0..255>; struct {
EarlyDataType type; select (Role) {
case server: case client:
struct {}; opaque configuration_id<1..2^16-1>;
} CipherSuite cipher_suite;
} EarlyDataIndication; Extension extensions<0..2^16-1>;
opaque context<0..255>;
EarlyDataType type;
case server:
struct {};
}
} EarlyDataIndication;
configuration_id
The label for the configuration in question.
cipher_suite
The cipher suite which the client is using to encrypt the early
data.
extensions
The extensions required to define the cryptographic configuration
for the clients early data (see below for details).
context context
An optional context value that can be used for anti-replay (see An optional context value that can be used for anti-replay (see
below). below).
type type
The type of early data that is being sent. "early_handshake" means The type of early data that is being sent. "client_authentication"
that only handshake data is being sent. "early_data" means that means that only handshake data is being sent. "early_data" means
only data is being sent. "early_handshake_and_data" means that that only data is being sent. "client_authentication_and_data"
both are being sent. means that both are being sent.
The client specifies the cryptographic configuration for the 0-RTT
data using the "configuration", "cipher_suite", and "extensions"
values. For configurations received in-band (in a previous TLS
connection) the client MUST:
- Send the same cryptographic determining parameters
(Section Section 6.3.2.5.1) with the previous connection. If a
0-RTT handshake is being used with a PSK that was negotiated via a
non-PSK handshake, then the client MUST use the same symmetric
cipher parameters as were negotiated on that handshake but with a
PSK cipher suite.
- Indicate the same parameters as the server indicated in that
connection.
If TLS client authentication is being used, then either If TLS client authentication is being used, then either
"early_handshake" or "early_handshake_and_data" MUST be indicated in "early_handshake" or "early_handshake_and_data" MUST be indicated in
order to send the client authentication data on the first flight. In order to send the client authentication data on the first flight. In
either case, the client Certificate and CertificateVerify (assuming either case, the client Certificate and CertificateVerify (assuming
that the Certificate is non-empty) MUST be sent on the first flight A that the Certificate is non-empty) MUST be sent on the first flight.
server which receives an initial flight with only "early_data" and A server which receives an initial flight with only "early_data" and
which expects certificate-based client authentication MUST not accept which expects certificate-based client authentication MUST NOT accept
early data. early data.
In order to allow servers to readily distinguish between messages In order to allow servers to readily distinguish between messages
sent in the first flight and in the second flight (in cases where the sent in the first flight and in the second flight (in cases where the
server does not accept the EarlyDataIndication extension), the client server does not accept the EarlyDataIndication extension), the client
MUST send the handshake messages as content type "early_handshake". MUST send the handshake messages as content type "early_handshake".
A server which does not accept the extension proceeds by skipping all A server which does not accept the extension proceeds by skipping all
records after the ClientHello and until the next client message of records after the ClientHello and until the next client message of
type "handshake". [[OPEN ISSUE: This relies on content types not type "handshake". [[OPEN ISSUE: This needs replacement when we add
being encrypted. If we had content types that were encrypted, this encrypted content types.]]
would basically require trial decryption.]]
A server which receives an EarlyDataIndication extension can behave A server which receives an EarlyDataIndication extension can behave
in one of two ways: in one of two ways:
- Ignore the extension and return no response. This indicates that - Ignore the extension and return no response. This indicates that
the server has ignored any early data and an ordinary 1-RTT the server has ignored any early data and an ordinary 1-RTT
handshake is required. handshake is required.
- Return an empty extension, indicating that it intends to process - Return an empty extension, indicating that it intends to process
the early data. It is not possible for the server to accept only the early data. It is not possible for the server to accept only
a subset of the early data messages. a subset of the early data messages.
The server MUST first validate that the client's Prior to accepting the EarlyDataIndication extension, the server MUST
"known_configuration" extension is valid and that the client has perform the following checks:
suppled a valid key share in the "client_key_shares" extension. If
not, it MUST ignore the extension and discard the early handshake - The configuration_id matches a known server configuration.
data and early data.
- The client's cryptographic determining parameters match the
parameters that the server has negotiated based on the rest of the
ClientHello.
If any of these checks fail, the server MUST NOT respond with the
extension and must discard all the remaining first flight data (thus
falling back to 1-RTT).
[[TODO: How does the client behave if the indication is rejected.]] [[TODO: How does the client behave if the indication is rejected.]]
[[OPEN ISSUE: This just specifies the signaling for 0-RTT but not the [[OPEN ISSUE: This just specifies the signaling for 0-RTT but not the
the 0-RTT cryptographic transforms, including: the 0-RTT cryptographic transforms, including:
- What is in the handshake hash (including potentially some - What is in the handshake hash (including potentially some
speculative data from the server.) speculative data from the server).
- What is signed in the client's CertificateVerify - What is signed in the client's CertificateVerify.
- Whether we really want the Finished to not include the server's - Whether we really want the Finished to not include the server's
data at all. data at all.
What's here now needs a lot of cleanup before it is clear and What's here now needs a lot of cleanup before it is clear and
correct.]] correct.]]
[[TODO: We should really allow early_data to be used with PSKs. In 6.3.2.5.1. Cryptographic Determining Parameters
order to make this work, we need to either:
(a) explicitly signal the entire cryptographic parameter set (b) tie In order to allow the server to decrypt 0-RTT data, the client needs
it to the PSK identifier (as is presently done in the to provide enough information to allow the server to decrypt the
known_configuration extension). traffic without negotiation. This is accomplished by having the
client indicate the "cryptographic determining parameters" in its
ClientHello, which are necessary to decrypt the client's packets.
This includes the following values:
These two should match. ]] - The cipher suite identifier.
6.3.1.5.5.1. Replay Properties - If PSK is being used, the server's version of the PreSharedKey
extension (indicating the PSK the client is using).
As noted in Section 6.2.3, TLS does not provide any inter-connection [[TODO: Are there other extensions we need? I've gone over the list
and I don't see any, but...]] [[TODO: This should be the same list as
what you need for !EncryptedExtensions. Consolidate this list.]]
6.3.2.5.2. Replay Properties
As noted in Section 6.2.2, TLS does not provide any inter-connection
mechanism for replay protection for data sent by the client in the mechanism for replay protection for data sent by the client in the
first flight. As a special case, implementations where the server first flight. As a special case, implementations where the server
configuration, is delivered out of band (as has been proposed for configuration, is delivered out of band (as has been proposed for
DTLS-SRTP [RFC5763]), MAY use a unique server configuration DTLS-SRTP [RFC5763]), MAY use a unique server configuration
identifier for each connection, thus preventing replay. identifier for each connection, thus preventing replay.
Implementations are responsible for ensuring uniqueness of the Implementations are responsible for ensuring uniqueness of the
identifier in this case. identifier in this case.
6.3.2. Server Key Share 6.3.3. 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 extension message if the client has provided a ClientKeyShare extension
which is compatible with the selected cipher suite and group which is compatible with the selected cipher suite and group
parameters. parameters.
Meaning of this message: Meaning of this message:
skipping to change at page 54, line 48 skipping to change at page 56, line 31
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 selected key exchange method from the ClientKeyShare
(Section 6.3.1.5), identifying which value from the (Section 6.3.2.3), 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.
6.3.3. Encrypted Extensions 6.3.4. Encrypted Extensions
When this message will be sent: When this message will be sent:
If this message is sent, it MUST be sent immediately after the If this message is sent, it MUST be sent immediately after the
server's ServerKeyShare. This is the first message that is server's ServerKeyShare. This is the first message that is
encrypted under keys derived from ES. 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
skipping to change at page 55, line 38 skipping to change at page 57, line 21
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.
6.3.4. Server Certificate 6.3.5. Server Certificate
When this message will be sent: When this message will be sent:
The server MUST send a Certificate message whenever the agreed- The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document (this includes all key exchange methods defined in this document
except DH_anon and PSK), unless the KnownKeyExtension is used. except DH_anon and PSK). This message will always immediately
This message will always immediately follow either the follow the EncryptedExtensions 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:
opaque ASN1Cert<1..2^24-1>; opaque ASN1Cert<1..2^24-1>;
struct { struct {
ASN1Cert certificate_list<0..2^24-1>; ASN1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
certificate_list certificate_list
This is a sequence (chain) of certificates. The sender's This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because certificate SHOULD directly certify one preceding it. Because
certificate validation requires that root keys be distributed certificate validation requires that trust anchors be distributed
independently, the self-signed certificate that specifies the root independently, a self-signed certificate that specifies a trust
certificate authority MAY be omitted from the chain, under the anchor MAY be omitted from the chain, provided that supported
assumption that the remote end must already possess it in order to peers are known to possess any omitted certificates they may
validate it in any case. require.
Note: Prior to TLS 1.3, "certificate_list" ordering was required to
be strict, however some implementations already allowed for some
flexibility. For maximum compatibility, all implementations SHOULD
be prepared to handle potentially extraneous certificates and
arbitrary orderings from any TLS version (with the exception of the
sender's certificate). Some servers are configured to send both a
current and deprecated intermediate for transitional purposes, and
others are simply configured incorrectly, but these cases can
nonetheless be validated properly by clients capable of doing so.
Although the chain MAY be ordered in a variety of ways, the peer's
end-entity certificate MUST be the first element in the vector.
The same message type and structure will be used for the client's The same message type and structure will be used for the client's
response to a certificate request message. Note that a client MAY response to a certificate request message. Note that a client MAY
send no certificates if it does not have an appropriate certificate send no certificates if it does not have an appropriate certificate
to send in response to the server's authentication request. to send in response to the server's authentication request.
Note: PKCS #7 [PKCS7] is not used as the format for the certificate Note: PKCS #7 [PKCS7] is not used as the format for the certificate
vector because PKCS #6 [PKCS6] extended certificates are not used. vector because PKCS #6 [PKCS6] extended certificates are not used.
Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
of parsing the list more difficult. of parsing the list more difficult.
The following rules apply to the certificates sent by the server: The following rules apply to the certificates sent by the server:
- 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 server's end-entity certificate's public key (and associated
restrictions) MUST be compatible with the selected key exchange restrictions) MUST be compatible with the selected key exchange
algorithm. algorithm.
Key Exchange Alg. Certificate Key Type Key Exchange Alg. Certificate Key Type
DHE_RSA RSA public key; the certificate MUST allow the DHE_RSA RSA public key; the certificate MUST allow the
ECDHE_RSA key to be used for signing (the ECDHE_RSA key to be used for signing (i.e., the
digitalSignature bit MUST be set if the key digitalSignature bit MUST be set if the key
usage extension is present) with the signature usage extension is present) with the signature
scheme and hash algorithm that will be employed scheme and hash algorithm that will be employed
in the server key exchange message. in the ServerKeyShare message.
Note: ECDHE_RSA is defined in [RFC4492]. Note: ECDHE_RSA is defined in [RFC4492].
DHE_DSS DSA public key; the certificate MUST allow the DHE_DSS DSA public key; the certificate MUST allow the
key to be used for signing with the hash key to be used for signing with the hash
algorithm that will be employed in the server algorithm that will be employed in the server
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 ServerKeyShare 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. As servers MAY require the used to guide certificate selection. As servers MAY require the
presence of the server_name extension, clients SHOULD send this presence of the server_name extension, clients SHOULD send this
extension. extension.
If the client provided a "signature_algorithms" extension, then all 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 the "signature_algorithms"
signature algorithm pair that appears in that extension. Note that extension provided by the client (see Section 6.3.2.1). [[OPEN
this implies that a certificate containing a key for one signature ISSUE: changing this is under consideration]] Note that this implies
algorithm MAY be signed using a different signature algorithm (for that a certificate containing a key for one signature algorithm MAY
instance, an RSA key signed with a DSA key). be signed using a different signature algorithm (for instance, an RSA
key signed with a ECDSA 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
as transport layer endpoint, local configuration and preferences, as transport layer endpoint, local configuration and preferences,
etc.). If the server has a single certificate, it SHOULD attempt to etc.). If the server has a single certificate, it SHOULD attempt to
validate that it meets these criteria. validate that it meets these criteria.
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.
6.3.5. Certificate Request 6.3.6. Certificate Request
When this message will be sent: When this message will be sent:
A non-anonymous server can optionally request a certificate from A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the server's Certificate message, if sent, will immediately follow the server's Certificate
message). message.
Structure of this message: Structure of this message:
enum { enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), (255) fortezza_dms_RESERVED(20), (255)
} ClientCertificateType; } ClientCertificateType;
opaque DistinguishedName<1..2^16-1>; opaque DistinguishedName<1..2^16-1>;
skipping to change at page 59, line 45 skipping to change at page 61, line 45
New ClientCertificateType values are assigned by IANA as described in New ClientCertificateType values are assigned by IANA as described in
Section 11. 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.
6.3.6. Server Configuration 6.3.7. Server Configuration
When this message will be sent: When this message will be sent:
This message is used to provide a server configuration which the This message is used to provide a server configuration which the
client can use in future to skip handshake negotiation and client can use in future to skip handshake negotiation and
(optionally) to allow 0-RTT handshakes. The ServerConfiguration (optionally) to allow 0-RTT handshakes. The ServerConfiguration
message is sent as the last message before the CertificateVerify. message is sent as the last message before the CertificateVerify.
Structure of this Message: Structure of this Message:
enum { (65535) } ConfigurationExtensionType;
struct {
ConfigurationExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} ConfigurationExtension;
struct { struct {
opaque configuration_id<1..2^16-1>; opaque configuration_id<1..2^16-1>;
uint32 expiration_date; uint32 expiration_date;
NamedGroup group; NamedGroup group;
opaque server_key<1..2^16-1>; opaque server_key<1..2^16-1>;
Boolean early_data_allowed; EarlyDataType early_data_type;
ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration; } ServerConfiguration;
configuration_id configuration_id
The configuration identifier to be used with the known The configuration identifier to be used in 0-RTT mode.
configuration extension Section 6.3.1.5.3.
group group
The group for the long-term DH key that is being established for The group for the long-term DH key that is being established for
this configuration. this configuration.
expiration_date expiration_date
The last time when this configuration is expected to be valid (in The last time when this configuration is expected to be valid (in
seconds since the Unix epoch). Servers MUST NOT use any value seconds since the Unix epoch). Servers MUST NOT use any value
more than 604800 seconds (7 days) in the future. Clients MUST not more than 604800 seconds (7 days) in the future. Clients MUST not
cache configurations for longer than 7 days, regardless of the cache configurations for longer than 7 days, regardless of the
expiration_date. [[OPEN ISSUE: Is this the right value? The idea expiration_date. [[OPEN ISSUE: Is this the right value? The idea
is just to minimize exposure.]] is just to minimize exposure.]]
server_key server_key
The long-term DH key that is being established for this The long-term DH key that is being established for this
configuration. configuration.
early_data_allowed early_data_type
Whether the client may send data in its first flight (see The type of 0-RTT handshake that this configuration is to be used
Section 6.3.1.5.5). for (see Section 6.3.2.5). If "client_authentication" or
"client_authentication_and_data", then the client should select
the certificate for future handshakes based on the
CertificateRequest parameters supplied in this handshake. The
server MUST NOT send either of these two options unless it also
requested a certificate on this handshake. [[OPEN ISSUE: Should
we relax this?]]
extensions
This field is a placeholder for future extensions to the
ServerConfiguration format.
The semantics of this message are to establish a shared state between The semantics of this message are to establish a shared state between
the client and server for use with the "known_configuration" the client and server for use with the "known_configuration"
extension with the key specified in key and with the handshake extension with the key specified in key and with the handshake
parameters negotiated by this handshake. [[OPEN ISSUE: Should this parameters negotiated by this handshake.
allow some sort of parameter negotiation?]]
When the ServerConfiguration message is sent, the server MUST also When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if send a Certificate message and a CertificateVerify message, even if
the "known_configuration" extension was used for this handshake, thus the "known_configuration" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by requiring a signature over the configuration before it can be used by
the client. the client.
6.3.7. Server Certificate Verify 6.3.8. 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 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_hash[hash_length]; opaque handshake_hash[hash_length];
} }
} CertificateVerify; } CertificateVerify;
Where session_hash is as described in {{the-handshake-hash} and Where session_hash is as described in Section 7.2.1 and includes
includes the messages sent or received, starting at ClientHello the messages sent or received, starting at ClientHello and up to,
and up to, but not including, this message, including the type and but not including, this message, including the type and length
length fields of the handshake messages. This is a digest of the fields of the handshake messages. This is a digest of the
concatenation of all the Handshake structures (as defined in concatenation of all the Handshake structures (as defined in
Section 6.3) exchanged thus far. The digest MUST be the Hash used Section 6.3) exchanged thus far. The digest MUST be the Hash used
as the basis for HKDF. as the basis for HKDF.
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, The signature algorithm and hash algorithm MUST be a pair offered
the signature algorithm and hash algorithm MUST be a pair listed in the "signature_algorithms" extension (see Section 6.3.2.1).
in that extension. Note that there is a possibility for Note that there is a possibility for inconsistencies here. For
inconsistencies here. For instance, the client might offer instance, the client might offer DHE_DSS key exchange but omit any
DHE_DSS key exchange but omit any DSA pairs from its DSA pairs from its "signature_algorithms" extension. In order to
"signature_algorithms" extension. In order to negotiate negotiate correctly, the server MUST check any candidate cipher
correctly, the server MUST check any candidate cipher suites suites against the "signature_algorithms" extension before
against the "signature_algorithms" extension before selecting selecting them. This is somewhat inelegant but is a compromise
them. This is somewhat inelegant but is a compromise designed to designed to minimize changes to the original cipher suite design.
minimize changes to the original cipher suite design.
In addition, the hash and signature algorithms MUST be compatible In addition, the hash and signature algorithms MUST be compatible
with the key in the server's end-entity certificate. RSA keys MAY with the key in the server's end-entity certificate. RSA keys MAY
be used with any permitted hash algorithm, subject to restrictions be used with any permitted hash algorithm, subject to restrictions
in the certificate, if any. in the 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. [[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]]
6.3.8. Server Finished 6.3.9. 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 is essential for providing authentication of the server server and is essential for providing authentication of the server
side of the handshake and computed keys. 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
skipping to change at page 62, line 45 skipping to change at page 65, line 15
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: The verify_data value is computed as follows:
verify_data verify_data
HMAC(finished_secret, finished_label + '\0' + handshake_hash) HMAC(finished_secret, finished_label + '\0' + handshake_hash)
where HMAC uses the Hash algorithm for the handshake. See where HMAC [RFC2104] uses the Hash algorithm for the handshake.
Section 7.2.1 for the definition of handshake_hash. 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".
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 is the size of the HMAC long. In the current version of TLS, it is the size of the HMAC
output for the Hash used for the handshake. output for the Hash used for the handshake.
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 and the Finished message 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 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 same because the server's Finished does not include the client's
Certificate and CertificateVerify message. Certificate and CertificateVerify message.
6.3.9. Client Certificate 6.3.10. 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 6.3.4. defined in Section 6.3.5.
Meaning of this message: Meaning of this message:
This message conveys the client's certificate chain to the server; This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing). The message (when the client authentication is based on signing). The
certificate MUST be appropriate for the negotiated cipher suite's certificate MUST be appropriate for the negotiated cipher suite's
key exchange algorithm, and any negotiated extensions. key exchange algorithm, and any negotiated extensions.
In particular: In particular:
skipping to change at page 64, line 10 skipping to change at page 66, line 30
- 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:
Client Cert. Type Certificate Key Type Client Cert. Type Certificate Key Type
rsa_sign RSA public key; the certificate MUST allow the rsa_sign RSA public key; the certificate MUST allow the
key to be used for signing with the signature key to be used for signing with the signature
scheme and hash algorithm that will be scheme and hash algorithm that will be
employed in the certificate verify message. employed in the CertificateVerify message.
dss_sign DSA public key; the certificate MUST allow the dss_sign DSA public key; the certificate MUST allow the
key to be used for signing with the hash key to be used for signing with the hash
algorithm that will be employed in the algorithm that will be employed in the
certificate verify message. CertificateVerify message.
ecdsa_sign ECDSA-capable public key; the certificate MUST ecdsa_sign 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
certificate verify message; the public key CertificateVerify message; the public key
MUST use a curve and point format supported by MUST use a curve and point format supported by
the server. the server.
rsa_fixed_dh Diffie-Hellman public key; MUST use the same rsa_fixed_dh Diffie-Hellman public key; MUST use the same
dss_fixed_dh parameters as server's key. dss_fixed_dh parameters as server's key.
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 6.3.5. Note signature algorithm pair, as described in Section 6.3.6. Note
that this relaxes the constraints on certificate-signing that this relaxes the constraints on certificate-signing
algorithms found in prior versions of TLS. algorithms found in prior versions of TLS.
Note that, as with the server certificate, there are certificates Note that, as with the server certificate, there are certificates
that use algorithms/algorithm combinations that cannot be currently that use algorithms/algorithm combinations that cannot be currently
used with TLS. used with TLS.
6.3.10. Client Certificate Verify 6.3.11. 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 6.3.7, except that the context string is "TLS 1.3, client Section 6.3.8, 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.
6.3.11. New Session Ticket Message 6.3.12. New Session Ticket Message
After the server has received the client Finished message, it MAY After the server has received the client Finished message, it MAY
send a NewSessionTicket message. This message MUST be sent before send a NewSessionTicket message. This message MUST be sent before
the server sends any application data traffic, and is encrypted under the server sends any application data traffic, and is encrypted under
the application traffic key. This message creates a pre-shared key the application traffic key. This message creates a pre-shared key
(PSK) binding between the resumption master secret and the ticket (PSK) binding between the resumption master secret and the ticket
label. The client MAY use this PSK for future handshakes by label. The client MAY use this PSK for future handshakes by
including it in the pre_shared_key extension in its ClientHello including it in the "pre_shared_key" extension in its ClientHello
(Section 6.3.1.5.4) and supplying a suitable PSK cipher suite. (Section 6.3.2.4) and supplying a suitable PSK cipher suite.
struct { struct {
uint32 ticket_lifetime_hint; uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} NewSessionTicket; } NewSessionTicket;
ticket_lifetime_hint ticket_lifetime_hint
Indicates the lifetime in seconds as a 32-bit unsigned integer in Indicates the lifetime in seconds as a 32-bit unsigned integer in
network byte order. A value of zero is reserved to indicate that network byte order. A value of zero is reserved to indicate that
the lifetime of the ticket is unspecified. the lifetime of the ticket is unspecified.
skipping to change at page 66, line 43 skipping to change at page 69, line 21
The exact source of each of these secrets depends on the operational The exact source of each of these secrets depends on the operational
mode (DHE, ECDHE, PSK, etc.) and is summarized in the table below: mode (DHE, ECDHE, PSK, etc.) and is summarized in the table below:
Key Exchange Static Secret (SS) Ephemeral Secret (ES) Key Exchange Static Secret (SS) Ephemeral Secret (ES)
------------ ------------------ --------------------- ------------ ------------------ ---------------------
(EC)DHE Client ephemeral Client ephemeral (EC)DHE Client ephemeral Client ephemeral
(full handshake) w/ server ephemeral w/ server ephemeral (full handshake) w/ server ephemeral w/ server ephemeral
(EC)DHE Client ephemeral Client ephemeral (EC)DHE Client ephemeral Client ephemeral
(w/ known_configuration) w/ Known Key w/ server ephemeral (w/ 0-RTT) w/ server static w/ server ephemeral
PSK Pre-Shared Key Pre-shared key PSK Pre-Shared Key Pre-shared key
PSK + (EC)DHE Pre-Shared Key Client ephemeral PSK + (EC)DHE Pre-Shared Key Client ephemeral
w/ server ephemeral w/ server ephemeral
These shared secret values are used to generate cryptographic keys as These shared secret values are used to generate cryptographic keys as
shown below. shown below.
The derivation process is as follows, where L denotes the length of The derivation process is as follows, where L denotes the length of
the underlying hash function for HKDF. the underlying hash function for HKDF [RFC5869]. SS and ES denote
the sources from the table above. Whilst SS and ES may be the same
in some cases, the extracted xSS and xES will not.
HKDF-Expand-Label(Secret, Label, HashValue, Length) = HKDF-Expand-Label(Secret, Label, HashValue, Length) =
HKDF-Expand(Secret, Label + '\0' + HashValue, Length) HKDF-Expand(Secret, Label + '\0' + HashValue, Length)
1. xSS = HKDF(0, SS, "extractedSS", L) 1. xSS = HKDF(0, SS, "extractedSS", L)
2. xES = HKDF(0, ES, "extractedES", L) 2. xES = HKDF(0, ES, "extractedES", L)
3. master_secret= HKDF(xSS, xES, "master secret", L) 3. master_secret = HKDF(xSS, xES, "master secret", L)
4. finished_secret = HKDF-Expand-Label(xSS, 4. finished_secret = HKDF-Expand-Label(xSS,
"finished secret", "finished secret",
handshake_hash, L) handshake_hash, L)
Where handshake_hash includes all the messages in the Where handshake_hash includes all the messages in the
client's first flight and the server's flight, excluding client's first flight and the server's flight, excluding
the Finished messages (which are never included in the the Finished messages (which are never included in the
hashes). hashes).
skipping to change at page 69, line 12 skipping to change at page 72, line 8
handshake_messages handshake_messages
All handshake messages sent or received, starting at ClientHello All handshake messages sent or received, starting at ClientHello
up to the present time, with the exception of the Finished up to the present time, with the exception of the Finished
message, including the type and length fields of the handshake message, including the type and length fields of the handshake
messages. This is the concatenation of all the exchanged messages. This is the concatenation of all the exchanged
Handshake structures in plaintext form (even if they were Handshake structures in plaintext form (even if they were
encrypted on the wire). encrypted on the wire).
configuration configuration
When the known_configuration extension is in use When 0-RTT is in use (Section 6.3.2.5) this contains the
(Section 6.3.1.5.3, this contains the concatenation of the concatenation of the ServerConfiguration and Certificate messages
ServerConfiguration and Certificate messages from the handshake from the handshake where the configuration was established
where the configuration was established. Note that this requires (including the type and length fields). Note that this requires
the client and server to memorize these values. the client and server to memorize these values.
This final value of the handshake hash is referred to as the "session This final value of the handshake hash is referred to as the "session
hash" because it contains all the handshake messages required to hash" because it contains all the handshake messages required to
establish the session. Note that if client authentication is not establish the session. Note that if client authentication is not
used, then the session hash is complete at the point when the server 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 has sent its first flight. Otherwise, it is only complete when the
client has sent its first flight, as it covers the client's client has sent its first flight, as it covers the client's
Certificate and CertificateVerify. Certificate and CertificateVerify.
7.2.2. Diffie-Hellman 7.2.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the shared_secret, and is used in 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 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. zero bits are stripped before it is used as the input to HKDF.
7.2.3. Elliptic Curve Diffie-Hellman 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 shared secret is the x-coordinate of the function (KDF), so that the shared secret is the x-coordinate of 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 this secret for anything other than because TLS does not directly use this secret for anything other than
for computing other secrets.) for computing other secrets.)
8. Mandatory Cipher Suites 8. Mandatory Algorithms
8.1. MTI 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.)
8.2. MTI Extensions
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following
TLS extensions:
- Signature Algorithms ("signature_algorithms"; Section 6.3.2.1)
- Negotiated Groups ("supported_groups"; Section 6.3.2.2)
- Client Key Share ("client_key_share"; Section 6.3.2.3)
- Pre-Shared Key Extension ("pre_shared_key"; Section 6.3.2.4)
- Server Name Indication ("server_name"; Section 3 of [RFC6066])
All implementations MUST send and use these extensions when offering
applicable cipher suites:
- "signature_algorithms" is REQUIRED for certificate authenticated
cipher suites
- "supported_groups" and "client_key_share" are REQUIRED for DHE or
ECDHE cipher suites
- "pre_shared_key" is REQUIRED for PSK cipher suites
When negotiating use of applicable cipher suites, endpoints MUST
abort the connection with a "missing_extension" alert if the required
extension was not provided. Any endpoint that receives any invalid
combination of cipher suites and extensions MAY abort the connection
with a "missing_extension" alert, regardless of negotiated
parameters.
Additionally, all implementations MUST support use of the
"server_name" extension with applications capable of using it.
Servers MAY require clients to send a valid "server_name" extension.
Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension with a fatal "missing_extension"
alert.
9. 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.
10. 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 B, C, and D.
11. 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.
skipping to change at page 71, line 14 skipping to change at page 75, line 7
- 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 6.3.1.4). (see Section 6.3.2).
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 6.3.1.4.1. Future populated with the values described in Section 6.3.2.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 6.3.1.4.1. Future populated with the values described in Section 6.3.2.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].
12. References 12. References
12.1. Normative References 12.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.
skipping to change at page 72, line 18 skipping to change at page 76, line 9
(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.
Department of Commerce, "Digital Signature Standard", NIST Department of Commerce, "Digital Signature Standard", NIST
FIPS PUB 186-2, 2000. FIPS PUB 186-2, 2000.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [I-D.ietf-tls-chacha20-poly1305]
April 1992. Langley, A., Chang, W., Mavrogiannopoulos, N.,
Strombergson, J., and S. Josefsson, "The ChaCha20-Poly1305
AEAD Cipher for Transport Layer Security", draft-ietf-tls-
chacha20-poly1305-00 (work in progress), June 2015.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
skipping to change at page 73, line 5 skipping to change at page 76, line 46
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 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010. Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC6209] Kim, W., Lee, J., Park, J., and D. Kwon, "Addition of the
ARIA Cipher Suites to Transport Layer Security (TLS)", RFC
6209, April 2011.
[RFC6367] Kanno, S. and M. Kanda, "Addition of the Camellia Cipher
Suites to Transport Layer Security (TLS)", RFC 6367,
September 2011.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
TLS", RFC 7251, June 2014.
[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-4, March 2012.
[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.
skipping to change at page 74, line 20 skipping to change at page 78, line 25
[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.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[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)
Ciphersuites for Transport Layer Security (TLS)", RFC
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 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December for Transport Layer Security (TLS)", RFC 4279, December
2005. 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
skipping to change at page 75, line 19 skipping to change at page 79, line 23
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. 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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 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 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. 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.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, April 2015.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
June 2015. 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",
skipping to change at page 78, line 8 skipping to change at page 82, line 8
aead-ciphered struct { aead-ciphered struct {
opaque content[TLSPlaintext.length]; opaque content[TLSPlaintext.length];
} fragment; } fragment;
} TLSCiphertext; } TLSCiphertext;
A.2. Alert Messages A.2. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel; enum { warning(1), fatal(2), (255) } AlertLevel;
enum { enum {
close_notify(0), close_notify(0),
unexpected_message(10), /* fatal */ unexpected_message(10), /* fatal */
bad_record_mac(20), /* fatal */ bad_record_mac(20), /* fatal */
decryption_failed_RESERVED(21), /* fatal */ decryption_failed_RESERVED(21), /* fatal */
record_overflow(22), /* fatal */ record_overflow(22), /* fatal */
decompression_failure_RESERVED(30), /* fatal */ decompression_failure_RESERVED(30), /* fatal */
handshake_failure(40), /* fatal */ handshake_failure(40), /* fatal */
no_certificate_RESERVED(41), /* fatal */ no_certificate_RESERVED(41), /* fatal */
bad_certificate(42), bad_certificate(42),
unsupported_certificate(43), unsupported_certificate(43),
certificate_revoked(44), certificate_revoked(44),
certificate_expired(45), certificate_expired(45),
certificate_unknown(46), certificate_unknown(46),
illegal_parameter(47), /* fatal */ illegal_parameter(47), /* fatal */
unknown_ca(48), /* fatal */ unknown_ca(48), /* fatal */
access_denied(49), /* fatal */ access_denied(49), /* fatal */
decode_error(50), /* fatal */ decode_error(50), /* fatal */
decrypt_error(51), /* fatal */ decrypt_error(51), /* fatal */
export_restriction_RESERVED(60), /* fatal */ export_restriction_RESERVED(60), /* fatal */
protocol_version(70), /* fatal */ protocol_version(70), /* fatal */
insufficient_security(71), /* fatal */ insufficient_security(71), /* fatal */
internal_error(80), /* fatal */ internal_error(80), /* fatal */
inappropriate_fallback(86), /* fatal */
user_canceled(90), user_canceled(90),
no_renegotiation(100), /* fatal */ no_renegotiation_RESERVED(100), /* fatal */
unsupported_extension(110), /* fatal */ missing_extension(109), /* fatal */
unsupported_extension(110), /* fatal */
certificate_unobtainable(111),
unrecognized_name(112),
bad_certificate_status_response(113), /* fatal */
bad_certificate_hash_value(114), /* fatal */
unknown_psk_identity(115),
(255) (255)
} 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),
session_ticket(4), 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), server_configuration(14), certificate_request(13), server_configuration(17),
certificate_verify(15), 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 server_hello: ServerHello; case server_hello: ServerHello;
case hello_retry_request: HelloRetryRequest; case hello_retry_request: HelloRetryRequest;
skipping to change at page 80, line 4 skipping to change at page 84, 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;
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 80, line 27 skipping to change at page 84, line 26
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 {
supported_groups(10),
signature_algorithms(13), signature_algorithms(13),
early_data(TBD), early_data(TBD),
supported_groups(TBD), pre_shared_key(TBD),
known_configuration(TBD), client_key_shares(TBD),
pre_shared_key(TBD)
client_key_shares(TBD)
(65535) (65535)
} ExtensionType; } ExtensionType;
struct { opaque psk_identity<0..2^16-1>;
select (Role) {
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>;
struct { case server:
select (Role) { psk_identity identity;
case client: }
psk_identity identities<0..2^16-1>; } PreSharedKeyExtension;
case server: enum { client_authentication(1), early_data(2),
psk_identity identity; client_authentication_and_data(3), (255) } EarlyDataType;
} PreSharedKeyExtension; struct {
select (Role) {
case client:
enum { early_handshake(1), early_data(2), opaque configuration_id<1..2^16-1>;
early_handshake_and_data(3), (255) } EarlyDataType; CipherSuite cipher_suite;
Extension extensions<0..2^16-1>;
opaque context<0..255>;
EarlyDataType type;
struct { case server:
select (Role) { struct {};
case client: }
opaque context<0..255>; } EarlyDataIndication;
EarlyDataType type;
case server:
struct {};
}
} EarlyDataIndication;
struct { struct {
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} EncryptedExtensions; } EncryptedExtensions;
enum { (65535) } ConfigurationExtensionType;
struct {
ConfigurationExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} ConfigurationExtension;
struct { struct {
opaque configuration_id<1..2^16-1>; opaque configuration_id<1..2^16-1>;
uint32 expiration_date; uint32 expiration_date;
NamedGroup group; NamedGroup group;
opaque server_key<1..2^16-1>; opaque server_key<1..2^16-1>;
Boolean early_data_allowed; EarlyDataType early_data_type;
ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration; } 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),
sha512(6), (255) md5_RESERVED(1),
sha1(2),
sha224_RESERVED(3),
sha256(4), sha384(5), 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;
SignatureAlgorithm signature; SignatureAlgorithm signature;
} SignatureAndHashAlgorithm; } SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>; supported_signature_algorithms<2..2^16-2>;
A.3.1.2. Named Group Extension A.3.1.2. Named Group Extension
enum { enum {
// Elliptic Curve Groups. // Elliptic Curve Groups.
sect163k1 (1), sect163r1 (2), sect163r2 (3), obsolete_RESERVED (1..22),
sect193r1 (4), sect193r2 (5), sect233k1 (6), secp256r1 (23), secp384r1 (24), secp521r1 (25),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
// Finite Field Groups. // Finite Field Groups.
ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258), ffdhe2048 (256), ffdhe3072 (257), ffdhe4096 (258),
ffdhe6144 (259), ffdhe8192 (260), ffdhe6144 (259), ffdhe8192 (260),
ffdhe_private_use (0x01FC..0x01FF), ffdhe_private_use (0x01FC..0x01FF),
// Reserved Code Points. // Reserved Code Points.
reserved (0xFE00..0xFEFF), ecdhe_private_use (0xFE00..0xFEFF),
reserved(0xFF01), obsolete_RESERVED (0xFF01..0xFF02),
reserved(0xFF02),
(0xFFFF) (0xFFFF)
} NamedGroup; } NamedGroup;
struct { struct {
NamedGroup named_group_list<1..2^16-1>; NamedGroup named_group_list<1..2^16-1>;
} NamedGroupList; } NamedGroupList;
A.3.2. Key Exchange Messages A.3.2. Key Exchange Messages
struct { struct {
NamedGroup group; NamedGroup group;
skipping to change at page 84, line 18 skipping to change at page 88, line 18
opaque verify_data[verify_data_length]; opaque verify_data[verify_data_length];
} Finished; } Finished;
A.3.5. Ticket Establishment A.3.5. Ticket Establishment
struct { struct {
uint32 ticket_lifetime_hint; uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} NewSessionTicket; } NewSessionTicket;
A.4. The Cipher Suite A.4. Cipher Suites
The following values define the cipher suite codes used in the A cipher suite defines a cipher specification supported in TLS and
ClientHello and ServerHello messages. A cipher suite defines a negotiated via hello messages in the TLS handshake. Cipher suite
cipher specification supported in TLS. names follow a general naming convention composed of a series of
component algorithm names separated by underscores:
CipherSuite TLS_KEA_SIGN_WITH_CIPHER_HASH = VALUE;
Component Contents
TLS The string "TLS"
KEA The key exchange algorithm
SIGN The signature algorithm
WITH The string "WITH"
CIPHER The symmetric cipher used for record protection
HASH The hash algorithm used with HKDF
VALUE The two byte ID assigned for this cipher suite
The "CIPHER" component commonly has sub-components used to designate
the cipher name, bits, and mode, if applicable. For example,
"AES_256_GCM" represents 256-bit AES in the GCM mode of operation.
Cipher suite names that lack a "HASH" value that are defined for use
with TLS 1.2 or later use the SHA-256 hash algorithm by default.
The primary key exchange algorithm used in TLS is Ephemeral Diffie-
Hellman [DH]. The finite field based version is denoted "DHE" and
the elliptic curve based version is denoted "ECDHE". Prior versions
of TLS supported non-ephemeral key exchanges, however these are not
supported by TLS 1.3.
See the definitions of each cipher suite in its specification
document for the full details of each combination of algorithms that
is specified.
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.
CipherSuite TLS_NULL_WITH_NULL_NULL = {0x00,0x00}; CipherSuite TLS_NULL_WITH_NULL_NULL = {0x00,0x00};
The following cipher suite definitions, defined in [RFC5288], are The following is a list of standards track server-authenticated (and
used for server-authenticated (and optionally client-authenticated) optionally client-authenticated) cipher suites which are currently
Diffie-Hellman. DHE denotes ephemeral Diffie-Hellman, where the available in TLS 1.3:
Diffie-Hellman parameters are signed by a signature-capable
certificate, which has been signed by the CA. The signing algorithm
used by the server is specified after the DHE component of the
CipherSuite name. The server can request any signature-capable
certificate from the client for client authentication.
CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {0x00,0x9E}; Cipher Suite Name Value Specification
CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {0x00,0x9F}; TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 {0x00,0x9E} [RFC5288]
CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {0x00,0xA2}; TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 {0x00,0x9F} [RFC5288]
CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3}; TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 {0x00,0xA2} [RFC5288]
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 {0x00,0xA3} [RFC5288]
TLS_DHE_RSA_WITH_AES_128_CCM {0xC0,0x9E} [RFC6655]
TLS_DHE_RSA_WITH_AES_256_CCM {0xC0,0x9F} [RFC6655]
TLS_DHE_RSA_WITH_AES_128_CCM_8 {0xC0,0xA2} [RFC6655]
TLS_DHE_RSA_WITH_AES_256_CCM_8 {0xC0,0xA3} [RFC6655]
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305]
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305]
TLS_DHE_RSA_WITH_CHACHA20_POLY1305 {TBD,TBD} [I-D.ietf-tls-chacha20-poly1305]
The following cipher suite definitions, defined in [RFC5289], are [[TODO: CHACHA20_POLY1305 cipher suite IDs are TBD.]]
used for server-authenticated (and optionally client-authenticated)
Elliptic Curve Diffie-Hellman. ECDHE denotes ephemeral Diffie-
Hellman, where the Diffie-Hellman parameters are signed by a
signature-capable certificate, which has been signed by the CA. The
signing algorithm used by the server is specified after the DHE
component of the CipherSuite name. The server can request any
signature-capable certificate from the client for client
authentication.
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2B}; The following is a list of non-standards track server-authenticated
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x2C}; (and optionally client-authenticated) cipher suites which are
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2F}; currently available in TLS 1.3:
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30};
The following ciphers, defined in [RFC5288], are used for completely Cipher Suite Name Value Specification
anonymous Diffie-Hellman communications in which neither party is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 {0xC0,0x2B} [RFC5289]
authenticated. Note that this mode is vulnerable to man-in-the- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 {0xC0,0x2C} [RFC5289]
middle attacks. Using this mode therefore is of limited use: These TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 {0xC0,0x2F} [RFC5289]
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 {0xC0,0x30} [RFC5289]
TLS_ECDHE_ECDSA_WITH_AES_128_CCM {0xC0,0xAC} [RFC7251]
TLS_ECDHE_ECDSA_WITH_AES_256_CCM {0xC0,0xAD} [RFC7251]
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 {0xC0,0xAE} [RFC7251]
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 {0xC0,0xAF} [RFC7251]
TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x52} [RFC6209]
TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x53} [RFC6209]
TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256 {0xC0,0x56} [RFC6209]
TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384 {0xC0,0x57} [RFC6209]
TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x5C} [RFC6209]
TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x5D} [RFC6209]
TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 {0xC0,0x60} [RFC6209]
TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 {0xC0,0x61} [RFC6209]
TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x7C} [RFC6367]
TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x7D} [RFC6367]
TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x80} [RFC6367]
TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x81} [RFC6367]
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x86} [RFC6367]
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x87} [RFC6367]
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 {0xC0,0x8A} [RFC6367]
TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 {0xC0,0x8B} [RFC6367]
ECDHE AES GCM is not yet standards track, however it is already
widely deployed.
Note: In the case of the CCM mode of AES, two variations exist:
"CCM_8" which uses an 8-bit authentication tag and "CCM" which uses a
16-bit authentication tag. Both use the default hash, SHA-256.
In addition to authenticated cipher suites, completely anonymous
Diffie-Hellman cipher suites exist to provide communications in which
neither party is authenticated. This mode is vulnerable to man-in-
the-middle attacks and is therefore unsafe for general use. These
cipher suites MUST NOT be used by TLS implementations unless the cipher suites MUST NOT be used by TLS implementations unless the
application layer has specifically requested to allow anonymous key application layer has specifically requested to allow anonymous key
exchange. (Anonymous key exchange may sometimes be acceptable, for exchange. Anonymous key exchange may sometimes be acceptable, for
example, to support opportunistic encryption when no set-up for example, to support opportunistic encryption when no set-up for
authentication is in place, or when TLS is used as part of more authentication is in place, or when TLS is used as part of more
complex security protocols that have other means to ensure complex security protocols that have other means to ensure
authentication.) authentication. The following specifications provide "DH_anon" key
exchange cipher suites: AES-GCM [RFC5288], ARIA-GCM [RFC6209], and
CAMELLIA-GCM [RFC6367].
CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {0x00,0xA6}; All cipher suites in this section are specified for use with both TLS
CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {0x00,0xA7}; 1.2 and TLS 1.3, as well as the corresponding versions of DTLS. (see
Appendix C)
[[TODO: Add all the defined AEAD ciphers. This currently only lists Note that using non-anonymous key exchange without actually verifying
GCM. https://github.com/tlswg/tls13-spec/issues/53]] Note that using the key exchange is essentially equivalent to anonymous key exchange,
non-anonymous key exchange without actually verifying the key and the same precautions apply. While non-anonymous key exchange
exchange is essentially equivalent to anonymous key exchange, and the will generally involve a higher computational and communicational
same precautions apply. While non-anonymous key exchange will cost than anonymous key exchange, it may be in the interest of
generally involve a higher computational and communicational cost
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.
o For cipher suites ending with _SHA256, HKDF is used with SHA-256 as
the hash function.
o For cipher suites ending with _SHA384, HKDF is used with SHA-384 as
the hash function.
New cipher suite values are assigned by IANA as described in New cipher suite values are assigned by IANA as described in
Section 11. Section 11.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL
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_kdf_sha256, tls_kdf_sha384 } KDFAlgorithm; enum { tls_kdf_sha256, tls_kdf_sha384 } KDFAlgorithm;
skipping to change at page 86, line 48 skipping to change at page 92, line 15
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 6.3.4 and Section 6.3.9, the restrictions on As described in Section 6.3.5 and Section 6.3.10, 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. Implementation Notes
Cipher Suite Key Record
Exchange Protection Hash
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_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_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_256_GCM_SHA384 DH_anon AES_128_GCM SHA384
Appendix C. Implementation Notes
The TLS protocol cannot prevent many common security mistakes. This The TLS protocol cannot prevent many common security mistakes. This
section provides several recommendations to assist implementors. section provides several recommendations to assist implementors.
C.1. Random Number Generation and Seeding B.1. Random Number Generation and Seeding
TLS requires a cryptographically secure pseudorandom number generator TLS requires a cryptographically secure pseudorandom number generator
(PRNG). Care must be taken in designing and seeding PRNGs. PRNGs (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs
based on secure hash operations, most notably SHA-1, are acceptable, based on secure hash operations, most notably SHA-1, are acceptable,
but cannot provide more security than the size of the random number but cannot provide more security than the size of the random number
generator state. generator state.
To estimate the amount of seed material being produced, add the To estimate the amount of seed material being produced, add the
number of bits of unpredictable information in each seed byte. For number of bits of unpredictable information in each seed byte. For
example, keystroke timing values taken from a PC compatible 18.2 Hz example, keystroke timing values taken from a PC compatible 18.2 Hz
timer provide 1 or 2 secure bits each, even though the total size of timer provide 1 or 2 secure bits each, even though the total size of
the counter value is 16 bits or more. Seeding a 128-bit PRNG would the counter value is 16 bits or more. Seeding a 128-bit PRNG would
thus require approximately 100 such timer values. thus require approximately 100 such timer values.
[RFC4086] provides guidance on the generation of random values. [RFC4086] provides guidance on the generation of random values.
C.2. Certificates and Authentication B.2. Certificates and Authentication
Implementations are responsible for verifying the integrity of Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation certificates and should generally support certificate revocation
messages. Certificates should always be verified to ensure proper messages. Certificates should always be verified to ensure proper
signing by a trusted Certificate Authority (CA). The selection and signing by a trusted Certificate Authority (CA). The selection and
addition of trusted CAs should be done very carefully. Users should addition of trusted CAs should be done very carefully. Users should
be able to view information about the certificate and root CA. be able to view information about the certificate and root CA.
C.3. Cipher Suites B.3. Cipher Suite Support
TLS supports a range of key sizes and security levels, including some TLS supports a range of key sizes and security levels, including some
that provide no or minimal security. A proper implementation will that provide no or minimal security. A proper implementation will
probably not support many cipher suites. For instance, anonymous probably not support many cipher suites. For instance, anonymous
Diffie-Hellman is strongly discouraged because it cannot prevent man- Diffie-Hellman is strongly discouraged because it cannot prevent man-
in-the-middle attacks. Applications should also enforce minimum and in-the-middle attacks. Applications should also enforce minimum and
maximum key sizes. For example, certificate chains containing keys maximum key sizes. For example, certificate chains containing keys
or signatures weaker than 2048-bit RSA or 224-bit ECDSA are not or signatures weaker than 2048-bit RSA or 224-bit ECDSA are not
appropriate for secure applications. appropriate for secure applications. See also Appendix C.3.
C.4. Implementation Pitfalls B.4. Implementation Pitfalls
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 5.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 C)
- 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 C)
- 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 6.3.9)? Section 6.3.10)?
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.9)? 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 7.2.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 D.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 B.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 C. Backward Compatibility
The TLS protocol provides a built-in mechanism for version The TLS protocol provides a built-in mechanism for version
negotiation between endpoints potentially supporting different negotiation between endpoints potentially supporting different
versions of TLS. versions of TLS.
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can
also handle clients trying to use future versions of TLS as long as also handle clients trying to use future versions of TLS as long as
the ClientHello format remains compatible and the client supports the the ClientHello format remains compatible and the client supports the
highest protocol version available in the server. highest protocol version available in the server.
Prior versions of TLS used the record layer version number for Prior versions of TLS used the record layer version number for
various purposes. (TLSPlaintext.record_version & various purposes. (TLSPlaintext.record_version &
TLSCiphertext.record_version) As of TLS 1.3, this field is deprecated TLSCiphertext.record_version) As of TLS 1.3, this field is deprecated
and its value MUST be ignored by all implementations. Version and its value MUST be ignored by all implementations. Version
negotiation is performed using only the handshake versions. negotiation is performed using only the handshake versions.
(ClientHello.client_version & ServerHello.server_version) In order to (ClientHello.client_version & ServerHello.server_version) In order to
maximize interoperability with older endpoints, implementations that maximize interoperability with older endpoints, implementations that
negotiate the usage of TLS 1.0-1.2 SHOULD set the record layer negotiate the use of TLS 1.0-1.2 SHOULD set the record layer version
version number to the negotiated version for the ServerHello and all number to the negotiated version for the ServerHello and all records
records thereafter. thereafter.
D.1. Negotiating with an older server For maximum compatibility with previously non-standard behavior and
misconfigured deployments, all implementations SHOULD support
validation of certificate chains based on the expectations in this
document, even when handling prior TLS versions' handshakes. (see
Section 6.3.5)
C.1. Negotiating with an older server
A TLS 1.3 client who wishes to negotiate with such older servers will A TLS 1.3 client who wishes to negotiate with such older servers will
send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in send a normal TLS 1.3 ClientHello containing { 3, 4 } (TLS 1.3) in
ClientHello.client_version. If the server does not support this ClientHello.client_version. If the server does not support this
version it will respond with a ServerHello containing an older version it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol. negotiation will proceed as appropriate for the negotiated protocol.
A client resuming a session SHOULD initiate the connection using the A client resuming a session SHOULD initiate the connection using the
version that was previously negotiated. version that was previously negotiated.
If the version chosen by the server is not supported by the client If the version chosen by the server is not supported by the client
(or not acceptable), the client MUST send a "protocol_version" alert (or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection. message and close the connection.
If a TLS server receives a ClientHello containing a version number If a TLS server receives a ClientHello containing a version number
greater than the highest version supported by the server, it MUST greater than the highest version supported by the server, it MUST
reply according to the highest version supported by the server. reply according to the highest version supported by the server.
skipping to change at page 90, line 24 skipping to change at page 95, line 32
reply according to the highest version supported by the server. reply according to the highest version supported by the server.
Some legacy server implementations are known to not implement the TLS Some legacy server implementations are known to not implement the TLS
specification properly and might abort connections upon encountering specification properly and might abort connections upon encountering
TLS extensions or versions which it is not aware of. TLS extensions or versions which it is not aware of.
Interoperability with buggy servers is a complex topic beyond the Interoperability with buggy servers is a complex topic beyond the
scope of this document. Multiple connection attempts may be required scope of this document. Multiple connection attempts may be required
in order to negotiate a backwards compatible connection, however this in order to negotiate a backwards compatible connection, however this
practice is vulnerable to downgrade attacks and is NOT RECOMMENDED. practice is vulnerable to downgrade attacks and is NOT RECOMMENDED.
D.2. Negotiating with an older client C.2. Negotiating with an older client
A TLS server can also receive a ClientHello containing a version A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
proceed with a TLS 1.0 ServerHello. If the server only supports proceed with a TLS 1.0 ServerHello. If the server only supports
versions greater than client_version, it MUST send a versions greater than client_version, it MUST send a
"protocol_version" alert message and close the connection. "protocol_version" alert message and close the connection.
Note that earlier versions of TLS did not clearly specify the record Note that earlier versions of TLS did not clearly specify the record
layer version number value in all cases layer version number value in all cases
(TLSPlaintext.record_version). Servers will receive various TLS 1.x (TLSPlaintext.record_version). Servers will receive various TLS 1.x
versions in this field, however its value MUST always be ignored. versions in this field, however its value MUST always be ignored.
D.3. Backwards Compatibility Security Restrictions C.3. Backwards Compatibility Security Restrictions
If an implementation negotiates usage of TLS 1.2, then negotiation of If an implementation negotiates use of TLS 1.2, then negotiation of
cipher suites also supported by TLS 1.3 SHOULD be preferred, if cipher suites also supported by TLS 1.3 SHOULD be preferred, if
available. available.
The security of RC4 cipher suites is considered insufficient for the The security of RC4 cipher suites is considered insufficient for the
reasons cited in [RFC7465]. Implementations MUST NOT offer or reasons cited in [RFC7465]. Implementations MUST NOT offer or
negotiate RC4 cipher suites for any version of TLS for any reason. negotiate RC4 cipher suites for any version of TLS for any reason.
Old versions of TLS permitted the usage of very low strength ciphers. Old versions of TLS permitted the use of very low strength ciphers.
Ciphers with a strength less than 112 bits MUST NOT be offered or Ciphers with a strength less than 112 bits MUST NOT be offered or
negotiated for any version of TLS for any reason. negotiated for any version of TLS for any reason.
The security of SSL 2.0 [SSL2] is considered insufficient for the The security of SSL 2.0 [SSL2] is considered insufficient for the
reasons enumerated in [RFC6176], and MUST NOT be negotiated for any reasons enumerated in [RFC6176], and MUST NOT be negotiated for any
reason. reason.
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
skipping to change at page 91, line 32 skipping to change at page 96, line 42
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 [RFC7568], and MUST NOT be negotiated for any reasons enumerated in [RFC7568], and MUST NOT be 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 Implementations MUST NOT use the Truncated HMAC extension, defined in
Section 7 of [RFC6066], as it is not applicable to AEAD ciphers and
has been shown to be insecure in some scenarios.
Appendix D. Security Analysis
[[TODO: The entire security analysis needs a rewrite.]] [[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.
E.1. Handshake Protocol D.1. Handshake Protocol
The handshake protocol is responsible for selecting a cipher spec and The TLS Handshake Protocol is responsible for selecting a cipher spec
generating a master secret, which together comprise the primary and generating a master secret, which together comprise the primary
cryptographic parameters associated with a secure session. The cryptographic parameters associated with a secure session. The TLS
handshake protocol can also optionally authenticate parties who have Handshake Protocol can also optionally authenticate parties who have
certificates signed by a trusted certificate authority. certificates signed by a trusted certificate authority.
E.1.1. Authentication and Key Exchange D.1.1. Authentication and Key Exchange
TLS supports three authentication modes: authentication of both TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and parties, server authentication with an unauthenticated client, and
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.
[[TODO: Rewrite this because the master_secret is not used this way [[TODO: Rewrite this because the master_secret is not used this way
any more after Hugo's changes.]] The general goal of the key exchange any more after Hugo's changes.]] The general goal of the key exchange
process is to create a master_secret known to the communicating process is to create a master_secret known to the communicating
parties and not to attackers (see Section 7.1). The master_secret is parties and not to attackers (see Section 7.1). The master_secret is
required to generate the Finished messages and record protection keys required to generate the Finished messages and record protection keys
(see Section 6.3.8 and Section 7.2). By sending a correct Finished (see Section 6.3.9 and Section 7.2). By sending a correct Finished
message, parties thus prove that they know the correct master_secret. message, parties thus prove that they know the correct master_secret.
E.1.1.1. Anonymous Key Exchange D.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. should not be able to find the Diffie-Hellman result.
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 D.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
the client key exchange and server key exchange messages to send the client key exchange and server key exchange messages to send
temporary Diffie-Hellman parameters. The signature in the temporary Diffie-Hellman parameters. The signature in the
certificate verify message (if present) covers the entire handshake certificate verify message (if present) covers the entire handshake
up to that point and thus attests the certificate holder's desire to up to that point and thus attests the certificate holder's desire to
use the the ephemeral DHE keys. use the the ephemeral DHE keys.
Peers SHOULD validate each other's public key Y (dh_Ys offered by the Peers SHOULD validate each other's public key Y (dh_Ys offered by the
server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1. server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1.
skipping to change at page 93, line 4 skipping to change at page 98, line 18
When Diffie-Hellman key exchange is used, the client and server use When Diffie-Hellman key exchange is used, the client and server use
the client key exchange and server key exchange messages to send the client key exchange and server key exchange messages to send
temporary Diffie-Hellman parameters. The signature in the temporary Diffie-Hellman parameters. The signature in the
certificate verify message (if present) covers the entire handshake certificate verify message (if present) covers the entire handshake
up to that point and thus attests the certificate holder's desire to up to that point and thus attests the certificate holder's desire to
use the the ephemeral DHE keys. use the the ephemeral DHE keys.
Peers SHOULD validate each other's public key Y (dh_Ys offered by the Peers SHOULD validate each other's public key Y (dh_Ys offered by the
server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1. server or DH_Yc offered by the client) by ensuring that 1 < Y < p-1.
This simple check ensures that the remote peer is properly behaved This simple check ensures that the remote peer is properly behaved
and isn't forcing the local system into a small subgroup. and isn't forcing the local system into a small subgroup.
Additionally, using a fresh key for each handshake provides Perfect Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for each Forward Secrecy. Implementations SHOULD generate a new X for each
handshake when using DHE cipher suites. handshake when using DHE cipher suites.
E.1.2. Version Rollback Attacks D.1.2. Version Rollback Attacks
Because TLS includes substantial improvements over SSL Version 2.0, Because TLS includes substantial improvements over SSL Version 2.0,
attackers may try to make TLS-capable clients and servers fall back attackers may try to make TLS-capable clients and servers fall back
to Version 2.0. This attack can occur if (and only if) two TLS- to Version 2.0. This attack can occur if (and only if) two TLS-
capable parties use an SSL 2.0 handshake. capable parties use an SSL 2.0 handshake. (See also Appendix C.3.)
Although the solution using non-random PKCS #1 block type 2 message Although the solution using non-random PKCS #1 block type 2 message
padding is inelegant, it provides a reasonably secure way for Version padding is inelegant, it provides a reasonably secure way for Version
3.0 servers to detect the attack. This solution is not secure 3.0 servers to detect the attack. This solution is not secure
against attackers who can brute-force the key and substitute a new against attackers who can brute-force the key and substitute a new
ENCRYPTED-KEY-DATA message containing the same key (but with normal ENCRYPTED-KEY-DATA message containing the same key (but with normal
padding) before the application-specified wait threshold has expired. padding) before the application-specified wait threshold has expired.
Altering the padding of the least-significant 8 bytes of the PKCS Altering the padding of the least-significant 8 bytes of the PKCS
padding does not impact security for the size of the signed hashes padding does not impact security for the size of the signed hashes
and RSA key lengths used in the protocol, since this is essentially and RSA key lengths used in the protocol, since this is essentially
equivalent to increasing the input block size by 8 bytes. equivalent to increasing the input block size by 8 bytes.
E.1.3. Detecting Attacks Against the Handshake Protocol D.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 static 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.2. Protecting Application Data D.2. Protecting Application Data
The shared secrets are hashed with the handshake transcript to The shared secrets are hashed with the handshake transcript to
produce unique record protection secrets for each connection. produce unique record protection secrets for 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.
E.3. Denial of Service D.3. Denial of Service
TLS is susceptible to a number of denial-of-service (DoS) attacks. TLS is susceptible to a number of denial-of-service (DoS) attacks.
In particular, an attacker who initiates a large number of TCP In particular, an attacker who initiates a large number of TCP
connections can cause a server to consume large amounts of CPU doing connections can cause a server to consume large amounts of CPU doing
asymmetric crypto operations. However, because TLS is generally used asymmetric crypto operations. However, because TLS is generally used
over TCP, it is difficult for the attacker to hide his point of over TCP, it is difficult for the attacker to hide his point of
origin if proper TCP SYN randomization is used [RFC1948] by the TCP origin if proper TCP SYN randomization is used [RFC1948] by the TCP
stack. stack.
Because TLS runs over TCP, it is also susceptible to a number of DoS Because TLS runs over TCP, it is also susceptible to a number of DoS
attacks on individual connections. In particular, attackers can attacks on individual connections. In particular, attackers can
forge RSTs, thereby terminating connections, or forge partial TLS forge RSTs, thereby terminating connections, or forge partial TLS
records, thereby causing the connection to stall. These attacks records, thereby causing the connection to stall. These attacks
cannot in general be defended against by a TCP-using protocol. cannot in general be defended against by a TCP-using protocol.
Implementors or users who are concerned with this class of attack Implementors or users who are concerned with this class of attack
should use IPsec AH [RFC4302] or ESP [RFC4303]. should use IPsec AH [RFC4302] or ESP [RFC4303].
E.4. Final Notes D.4. Final Notes
For TLS to be able to provide a secure connection, both the client For TLS to be able to provide a secure connection, both the client
and server systems, keys, and applications must be secure. In and server systems, keys, and applications must be secure. In
addition, the implementation must be free of security errors. addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys and cryptographic functions should be used. Short public keys and
anonymous servers should be used with great caution. Implementations anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and and users must be careful when deciding which certificates and
certificate authorities are acceptable; a dishonest certificate certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage. authority can do tremendous damage.
Appendix F. Working Group Information Appendix E. Working Group Information
The discussion list for the IETF TLS working group is located at the The discussion list for the IETF TLS working group is located at the
e-mail address tls@ietf.org [2]. Information on the group and e-mail address tls@ietf.org [2]. Information on the group and
information on how to subscribe to the list is at information on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/tls https://www1.ietf.org/mailman/listinfo/tls
Archives of the list can be found at: https://www.ietf.org/mail- Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/tls/current/index.html archive/web/tls/current/index.html
Appendix G. Contributors Appendix F. Contributors
Martin Abadi Martin Abadi
University of California, Santa Cruz University of California, Santa Cruz
abadi@cs.ucsc.edu abadi@cs.ucsc.edu
Christopher Allen (co-editor of TLS 1.0) Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures Alacrity Ventures
ChristopherA@AlacrityManagement.com ChristopherA@AlacrityManagement.com
Steven M. Bellovin Steven M. Bellovin
 End of changes. 303 change blocks. 
807 lines changed or deleted 1039 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/