draft-ietf-tls-tls13-17.txt   draft-ietf-tls-tls13-18.txt 
Network Working Group E. Rescorla Network Working Group E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Obsoletes: 5077, 5246, 5746 (if October 20, 2016 Obsoletes: 5077, 5246, 5746 (if October 26, 2016
approved) approved)
Updates: 4492, 5705, 6066, 6961 (if Updates: 4492, 5705, 6066, 6961 (if
approved) approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 23, 2017 Expires: April 29, 2017
The Transport Layer Security (TLS) Protocol Version 1.3 The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-17 draft-ietf-tls-tls13-18
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. TLS allows client/server applications to communicate (TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping, over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery. tampering, and message forgery.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2017. This Internet-Draft will expire on April 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 38 skipping to change at page 2, line 38
2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 17 2.2. Resumption and Pre-Shared Key (PSK) . . . . . . . . . . . 17
2.3. Zero-RTT Data . . . . . . . . . . . . . . . . . . . . . . 19 2.3. Zero-RTT Data . . . . . . . . . . . . . . . . . . . . . . 19
3. Presentation Language . . . . . . . . . . . . . . . . . . . . 21 3. Presentation Language . . . . . . . . . . . . . . . . . . . . 21
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 21 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . 21
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3. Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 23 3.5. Enumerateds . . . . . . . . . . . . . . . . . . . . . . . 23
3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 24 3.6. Constructed Types . . . . . . . . . . . . . . . . . . . . 24
3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 24 3.7. Constants . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7.1. Variants . . . . . . . . . . . . . . . . . . . . . . 25 3.8. Variants . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8. Decoding Errors . . . . . . . . . . . . . . . . . . . . . 26 3.9. Decoding Errors . . . . . . . . . . . . . . . . . . . . . 26
4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 26 4. Handshake Protocol . . . . . . . . . . . . . . . . . . . . . 26
4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 27 4.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 27
4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 28 4.1.1. Cryptographic Negotiation . . . . . . . . . . . . . . 28
4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 29 4.1.2. Client Hello . . . . . . . . . . . . . . . . . . . . 29
4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 31 4.1.3. Server Hello . . . . . . . . . . . . . . . . . . . . 31
4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 33 4.1.4. Hello Retry Request . . . . . . . . . . . . . . . . . 33
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 34 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 36 4.2.1. Supported Versions . . . . . . . . . . . . . . . . . 36
4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 37 4.2.3. Signature Algorithms . . . . . . . . . . . . . . . . 37
4.2.4. Negotiated Groups . . . . . . . . . . . . . . . . . . 40 4.2.4. Negotiated Groups . . . . . . . . . . . . . . . . . . 40
4.2.5. Key Share . . . . . . . . . . . . . . . . . . . . . . 41 4.2.5. Key Share . . . . . . . . . . . . . . . . . . . . . . 41
4.2.6. Pre-Shared Key Extension . . . . . . . . . . . . . . 44 4.2.6. Pre-Shared Key Extension . . . . . . . . . . . . . . 44
4.2.7. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 46 4.2.7. Pre-Shared Key Exchange Modes . . . . . . . . . . . . 46
4.2.8. Early Data Indication . . . . . . . . . . . . . . . . 47 4.2.8. Early Data Indication . . . . . . . . . . . . . . . . 47
4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 50 4.3. Server Parameters . . . . . . . . . . . . . . . . . . . . 50
4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 50 4.3.1. Encrypted Extensions . . . . . . . . . . . . . . . . 50
4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 50 4.3.2. Certificate Request . . . . . . . . . . . . . . . . . 50
4.4. Authentication Messages . . . . . . . . . . . . . . . . . 52 4.4. Authentication Messages . . . . . . . . . . . . . . . . . 52
4.4.1. Certificate . . . . . . . . . . . . . . . . . . . . . 54 4.4.1. Certificate . . . . . . . . . . . . . . . . . . . . . 53
4.4.2. Certificate Verify . . . . . . . . . . . . . . . . . 57 4.4.2. Certificate Verify . . . . . . . . . . . . . . . . . 57
4.4.3. Finished . . . . . . . . . . . . . . . . . . . . . . 59 4.4.3. Finished . . . . . . . . . . . . . . . . . . . . . . 59
4.5. Post-Handshake Messages . . . . . . . . . . . . . . . . . 60 4.5. Post-Handshake Messages . . . . . . . . . . . . . . . . . 60
4.5.1. New Session Ticket Message . . . . . . . . . . . . . 61 4.5.1. New Session Ticket Message . . . . . . . . . . . . . 61
4.5.2. Post-Handshake Authentication . . . . . . . . . . . . 62 4.5.2. Post-Handshake Authentication . . . . . . . . . . . . 62
4.5.3. Key and IV Update . . . . . . . . . . . . . . . . . . 63 4.5.3. Key and IV Update . . . . . . . . . . . . . . . . . . 63
4.6. Handshake Layer and Key Changes . . . . . . . . . . . . . 64 4.6. Handshake Layer and Key Changes . . . . . . . . . . . . . 64
5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 64 5. Record Protocol . . . . . . . . . . . . . . . . . . . . . . . 64
5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 64 5.1. Record Layer . . . . . . . . . . . . . . . . . . . . . . 64
5.2. Record Payload Protection . . . . . . . . . . . . . . . . 66 5.2. Record Payload Protection . . . . . . . . . . . . . . . . 66
skipping to change at page 4, line 10 skipping to change at page 4, line 10
A.3.2. Server Parameters Messages . . . . . . . . . . . . . 100 A.3.2. Server Parameters Messages . . . . . . . . . . . . . 100
A.3.3. Authentication Messages . . . . . . . . . . . . . . . 101 A.3.3. Authentication Messages . . . . . . . . . . . . . . . 101
A.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 101 A.3.4. Ticket Establishment . . . . . . . . . . . . . . . . 101
A.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 102 A.3.5. Updating Keys . . . . . . . . . . . . . . . . . . . . 102
A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 102 A.4. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . 102
Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 103 Appendix B. Implementation Notes . . . . . . . . . . . . . . . . 103
B.1. API considerations for 0-RTT . . . . . . . . . . . . . . 103 B.1. API considerations for 0-RTT . . . . . . . . . . . . . . 103
B.2. Random Number Generation and Seeding . . . . . . . . . . 103 B.2. Random Number Generation and Seeding . . . . . . . . . . 103
B.3. Certificates and Authentication . . . . . . . . . . . . . 104 B.3. Certificates and Authentication . . . . . . . . . . . . . 104
B.4. Cipher Suite Support . . . . . . . . . . . . . . . . . . 104 B.4. Implementation Pitfalls . . . . . . . . . . . . . . . . . 104
B.5. Implementation Pitfalls . . . . . . . . . . . . . . . . . 104 B.5. Client Tracking Prevention . . . . . . . . . . . . . . . 105
B.6. Client Tracking Prevention . . . . . . . . . . . . . . . 106 B.6. Unauthenticated Operation . . . . . . . . . . . . . . . . 106
B.7. Unauthenticated Operation . . . . . . . . . . . . . . . . 106
Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 106 Appendix C. Backward Compatibility . . . . . . . . . . . . . . . 106
C.1. Negotiating with an older server . . . . . . . . . . . . 107 C.1. Negotiating with an older server . . . . . . . . . . . . 107
C.2. Negotiating with an older client . . . . . . . . . . . . 108 C.2. Negotiating with an older client . . . . . . . . . . . . 108
C.3. Zero-RTT backwards compatibility . . . . . . . . . . . . 108 C.3. Zero-RTT backwards compatibility . . . . . . . . . . . . 108
C.4. Backwards Compatibility Security Restrictions . . . . . . 109 C.4. Backwards Compatibility Security Restrictions . . . . . . 108
Appendix D. Overview of Security Properties . . . . . . . . . . 109 Appendix D. Overview of Security Properties . . . . . . . . . . 109
D.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 110 D.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 110
D.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 112 D.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . 112
Appendix E. Working Group Information . . . . . . . . . . . . . 114 Appendix E. Working Group Information . . . . . . . . . . . . . 114
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 114 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 114
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 118
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
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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
(*) indicates changes to the wire protocol which may require (*) indicates changes to the wire protocol which may require
implementations to update. implementations to update.
draft-18
- Remove unnecessary resumption_psk which is the only thing expanded
from the resumption master secret. (*).
- Fix signature_algorithms entry in extensions table.
- Restate rule from RFC 6066 that you can't resume unless SNI is the
same.
draft-17 draft-17
- Remove the 0-RTT Finished, resumption_context, and replace with a - Remove the 0-RTT Finished, resumption_context, and replace with a
psk_binder field in the PSK itself (*) psk_binder field in the PSK itself (*)
- Restructure PSK key exchange negotiation modes (*) - Restructure PSK key exchange negotiation modes (*)
- Add max_early_data_size field to TicketEarlyDataInfo (*) - Add max_early_data_size field to TicketEarlyDataInfo (*)
- Add a 0-RTT exporter and change the transcript for the regular - Add a 0-RTT exporter and change the transcript for the regular
skipping to change at page 6, line 42 skipping to change at page 7, line 4
- Add max_early_data_size field to TicketEarlyDataInfo (*) - Add max_early_data_size field to TicketEarlyDataInfo (*)
- Add a 0-RTT exporter and change the transcript for the regular - Add a 0-RTT exporter and change the transcript for the regular
exporter (*) exporter (*)
- Merge TicketExtensions and Extensions registry. Changes - Merge TicketExtensions and Extensions registry. Changes
ticket_early_data_info code point (*) ticket_early_data_info code point (*)
- Replace Client.key_shares in response to HRR (*) - Replace Client.key_shares in response to HRR (*)
- Remove redundant labels for traffic key derivation (*) - Remove redundant labels for traffic key derivation (*)
- Harmonize requirements about cipher suite matching: for resumption - Harmonize requirements about cipher suite matching: for resumption
you need to match KDF but for 0-RTT you need whole cipher suite. you need to match KDF but for 0-RTT you need whole cipher suite.
This allows PSKs to actually negotiate cipher suites. (*) This allows PSKs to actually negotiate cipher suites. (*)
- Move SCT and OCSP into Certificate.extensions (*)
- Explicitly allow non-offered extensions in NewSessionTicket - Explicitly allow non-offered extensions in NewSessionTicket
- Explicitly allow predicting ClientFinished for NST - Explicitly allow predicting ClientFinished for NST
- Clarify conditions for allowing 0-RTT with PSK - Clarify conditions for allowing 0-RTT with PSK
draft-16 draft-16
- Revise version negotiation (*) - Revise version negotiation (*)
- Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better - Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better
backwards compatibility (*) backwards compatibility (*)
- Move HelloRetryRequest.selected_group to an extension (*) - Move HelloRetryRequest.selected_group to an extension (*)
skipping to change at page 8, line 5 skipping to change at page 8, line 18
- Guidance on 0-RTT time windows. - Guidance on 0-RTT time windows.
- Rename a bunch of fields. - Rename a bunch of fields.
- Remove old PRNG text. - Remove old PRNG text.
- Explicitly require checking that handshake records not span key - Explicitly require checking that handshake records not span key
changes. changes.
draft-14
- Allow cookies to be longer (*) - Allow cookies to be longer (*)
- Remove the "context" from EarlyDataIndication as it was undefined - Remove the "context" from EarlyDataIndication as it was undefined
and nobody used it (*) and nobody used it (*)
- Remove 0-RTT EncryptedExtensions and replace the ticket_age - Remove 0-RTT EncryptedExtensions and replace the ticket_age
extension with an obfuscated version. Also necessitates a change extension with an obfuscated version. Also necessitates a change
to NewSessionTicket (*). to NewSessionTicket (*).
- Move the downgrade sentinel to the end of ServerHello.Random to - Move the downgrade sentinel to the end of ServerHello.Random to
skipping to change at page 10, line 41 skipping to change at page 11, line 5
- Change HKDF labeling to include protocol version and value - Change HKDF labeling to include protocol version and value
lengths. lengths.
- Shift the final decision to abort a handshake due to incompatible - Shift the final decision to abort a handshake due to incompatible
certificates to the client rather than having servers abort early. certificates to the client rather than having servers abort early.
- Deprecate SHA-1 with signatures. - Deprecate SHA-1 with signatures.
- Add MTI algorithms. - Add MTI algorithms.
draft-08
- Remove support for weak and lesser used named curves. - Remove support for weak and lesser used named curves.
- Remove support for MD5 and SHA-224 hashes with signatures. - Remove support for MD5 and SHA-224 hashes with signatures.
- Update lists of available AEAD cipher suites and error alerts. - Update lists of available AEAD cipher suites and error alerts.
- Reduce maximum permitted record expansion for AEAD from 2048 to - Reduce maximum permitted record expansion for AEAD from 2048 to
256 octets. 256 octets.
- Require digital signatures even when a previous configuration is - Require digital signatures even when a previous configuration is
skipping to change at page 24, line 11 skipping to change at page 24, line 11
The names of the elements of an enumeration are scoped within the The names of the elements of an enumeration are scoped within the
defined type. In the first example, a fully qualified reference to defined type. In the first example, a fully qualified reference to
the second element of the enumeration would be Color.blue. Such the second element of the enumeration would be Color.blue. Such
qualification is not required if the target of the assignment is well qualification is not required if the target of the assignment is well
specified. specified.
Color color = Color.blue; /* overspecified, legal */ Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */ Color color = blue; /* correct, type implicit */
For enumerateds that are never converted to external representation,
the numerical information may be omitted.
enum { low, medium, high } Amount;
The names assigned to enumerateds do not need to be unique. The The names assigned to enumerateds do not need to be unique. The
numerical value can describe a range over which the same name numerical value can describe a range over which the same name
applies. The value includes the minimum and maximum inclusive values applies. The value includes the minimum and maximum inclusive values
in that range, separated by two period characters. This is in that range, separated by two period characters. This is
principally useful for reserving regions of the space. principally useful for reserving regions of the space.
enum { sad(0), meh(1..254), happy (255) } Mood; enum { sad(0), meh(1..254), happy(255) } Mood;
3.6. Constructed Types 3.6. Constructed Types
Structure types may be constructed from primitive types for Structure types may be constructed from primitive types for
convenience. Each specification declares a new, unique type. The convenience. Each specification declares a new, unique type. The
syntax for definition is much like that of C. syntax for definition is much like that of C.
struct { struct {
T1 f1; T1 f1;
T2 f2; T2 f2;
skipping to change at page 25, line 5 skipping to change at page 24, line 47
3.7. Constants 3.7. Constants
Fields and variables may be assigned a fixed value using "=", as in: Fields and variables may be assigned a fixed value using "=", as in:
struct { struct {
T1 f1 = 8; /* T.f1 must always be 8 */ T1 f1 = 8; /* T.f1 must always be 8 */
T2 f2; T2 f2;
} T; } T;
3.7.1. Variants 3.8. Variants
Defined structures may have variants based on some knowledge that is Defined structures may have variants based on some knowledge that is
available within the environment. The selector must be an enumerated available within the environment. The selector must be an enumerated
type that defines the possible variants the structure defines. There type that defines the possible variants the structure defines. There
must be a case arm for every element of the enumeration declared in must be a case arm for every element of the enumeration declared in
the select. Case arms have limited fall-through: if two case arms the select. Case arms have limited fall-through: if two case arms
follow in immediate succession with no fields in between, then they follow in immediate succession with no fields in between, then they
both contain the same fields. Thus, in the example below, "orange" both contain the same fields. Thus, in the example below, "orange"
and "banana" both contain V2. Note that this piece of syntax was and "banana" both contain V2. Note that this piece of syntax was
added in TLS 1.2 [RFC5246]. Each case arm can have one or more added in TLS 1.2 [RFC5246]. Each case arm can have one or more
skipping to change at page 26, line 5 skipping to change at page 26, line 5
case e2: Te21; case e2: Te21;
Te22; Te22;
case e3: case e4: Te3; case e3: case e4: Te3;
.... ....
case en: Ten; case en: Ten;
} [[fv]]; } [[fv]];
} [[Tv]]; } [[Tv]];
For example: For example:
enum { apple, orange, banana } VariantTag; enum { apple(0), orange(1), banana(2) } VariantTag;
struct { struct {
uint16 number; uint16 number;
opaque string<0..10>; /* variable length */ opaque string<0..10>; /* variable length */
} V1; } V1;
struct { struct {
uint32 number; uint32 number;
opaque string[10]; /* fixed length */ opaque string[10]; /* fixed length */
} V2; } V2;
struct { struct {
select (VariantTag) { /* value of selector is implicit */ select (VariantTag) {
case apple: case apple:
V1; /* VariantBody, tag = apple */ V1; /* VariantBody, tag = apple */
case orange: case orange:
case banana: case banana:
V2; /* VariantBody, tag = orange or banana */ V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */ } variant_body; /* optional label on variant */
} VariantRecord; } VariantRecord;
3.8. Decoding Errors 3.9. Decoding Errors
TLS defines two generic alerts (see Section 6) to use upon failure to TLS defines two generic alerts (see Section 6) to use upon failure to
parse a message. Peers which receive a message which cannot be parse a message. Peers which receive a message which cannot be
parsed according to the syntax (e.g., have a length extending beyond parsed according to the syntax (e.g., have a length extending beyond
the message boundary or contain an out-of-range length) MUST the message boundary or contain an out-of-range length) MUST
terminate the connection with a "decode_error" alert. Peers which terminate the connection with a "decode_error" alert. Peers which
receive a message which is syntactically correct but semantically receive a message which is syntactically correct but semantically
invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST
terminate the connection with an "illegal_parameter" alert. terminate the connection with an "illegal_parameter" alert.
skipping to change at page 33, line 36 skipping to change at page 33, line 36
Structure of this message: Structure of this message:
struct { struct {
ProtocolVersion server_version; ProtocolVersion server_version;
Extension extensions<2..2^16-1>; Extension extensions<2..2^16-1>;
} HelloRetryRequest; } HelloRetryRequest;
The version and extensions fields have the same meanings as their The version and extensions fields have the same meanings as their
corresponding values in the ServerHello. The server SHOULD send only corresponding values in the ServerHello. The server SHOULD send only
the extensions necessary for the client to generate a correct the extensions necessary for the client to generate a correct
ClientHello pair (currently no such extensions exist). As with ClientHello pair. As with ServerHello, a HelloRetryRequest MUST NOT
ServerHello, a HelloRetryRequest MUST NOT contain any extensions that contain any extensions that were not first offered by the client in
were not first offered by the client in its ClientHello, with the its ClientHello, with the exception of optionally the "cookie" (see
exception of optionally the "cookie" (see Section 4.2.2) extension. Section 4.2.2) extension.
Upon receipt of a HelloRetryRequest, the client MUST verify that the Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise MUST abort the handshake extensions block is not empty and otherwise MUST abort the handshake
with a "decode_error" alert. Clients MUST abort the handshake with with a "decode_error" alert. Clients MUST abort the handshake with
an "illegal_parameter" alert if the HelloRetryRequest would not an "illegal_parameter" alert if the HelloRetryRequest would not
result in any change in the ClientHello. If a client receives a result in any change in the ClientHello. If a client receives a
second HelloRetryRequest in the same connection (i.e., where the second HelloRetryRequest in the same connection (i.e., where the
ClientHello was itself in response to a HelloRetryRequest), it MUST ClientHello was itself in response to a HelloRetryRequest), it MUST
abort the handshake with an "unexpected_message" alert. abort the handshake with an "unexpected_message" alert.
skipping to change at page 37, line 24 skipping to change at page 37, line 24
extension to the client (this is an exception to the usual rule that extension to the client (this is an exception to the usual rule that
the only extensions that may be sent are those that appear in the the only extensions that may be sent are those that appear in the
ClientHello). When sending the new ClientHello, the client MUST echo ClientHello). When sending the new ClientHello, the client MUST echo
the value of the extension. Clients MUST NOT use cookies in the value of the extension. Clients MUST NOT use cookies in
subsequent connections. subsequent connections.
4.2.3. Signature Algorithms 4.2.3. 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 algorithms may be used in digital the server which signature algorithms may be used in digital
signatures. Clients which desire the server to authenticate via a signatures. Clients which desire the server to authenticate itself
certificate MUST send this extension. If a server is authenticating via a certificate MUST send this extension. If a server is
via a certificate and the client has not sent a authenticating via a certificate and the client has not sent a
"signature_algorithms" extension then the server MUST abort the "signature_algorithms" extension then the server MUST abort the
handshake with a "missing_extension" alert (see Section 8.2). handshake with a "missing_extension" alert (see Section 8.2).
The "extension_data" field of this extension in a ClientHello The "extension_data" field of this extension in a ClientHello
contains a SignatureSchemeList value: contains a SignatureSchemeList value:
enum { enum {
/* RSASSA-PKCS1-v1_5 algorithms */ /* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha1 (0x0201),
rsa_pkcs1_sha256 (0x0401), rsa_pkcs1_sha256 (0x0401),
skipping to change at page 46, line 51 skipping to change at page 46, line 51
The server MUST NOT send a "psk_key_exchange_modes" extension. The server MUST NOT send a "psk_key_exchange_modes" extension.
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct { struct {
PskKeyExchangeMode ke_modes<1..255>; PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes; } PskKeyExchangeModes;
psk_ke PSK-only key establishment. In this mode, the server MUST psk_ke PSK-only key establishment. In this mode, the server MUST
not supply a "key_share" value. NOT supply a "key_share" value.
psk_dhe_ke PSK key establishment with (EC)DHE key establishment. In psk_dhe_ke PSK key establishment with (EC)DHE key establishment. In
this mode, the client and servers MUST supply "key_share" values this mode, the client and servers MUST supply "key_share" values
as described in Section 4.2.5. as described in Section 4.2.5.
4.2.8. Early Data Indication 4.2.8. Early Data Indication
When a PSK is used, the client can send application data in its first When a PSK is used, the client can send application data in its first
flight of messages. If the client opts to do so, it MUST supply an flight of messages. If the client opts to do so, it MUST supply an
"early_data" extension as well as the "pre_shared_key" extension. "early_data" extension as well as the "pre_shared_key" extension.
skipping to change at page 48, line 5 skipping to change at page 48, line 5
followed by an "end_of_early_data" alert, which will be encrypted followed by an "end_of_early_data" alert, which will be encrypted
with the 0-RTT traffic keys. with the 0-RTT traffic keys.
A server which receives an "early_data" extension can behave in one A server which receives an "early_data" extension can behave in one
of two ways: 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 its own 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.
- Request that the client send another ClientHello by responding - Request that the client send another ClientHello by responding
with a HelloRetryRequest. A client MUST NOT include the with a HelloRetryRequest. A client MUST NOT include the
"early_data" extension in its followup ClientHello. "early_data" extension in its followup ClientHello.
In order to accept early data, the server MUST have accepted a PSK In order to accept early data, the server MUST have accepted a PSK
cipher suite and selected the first key offered in the client's cipher suite and selected the first key offered in the client's
"pre_shared_key" extension. In addition, it MUST verify that the "pre_shared_key" extension. In addition, it MUST verify that the
skipping to change at page 52, line 31 skipping to change at page 52, line 31
o The Extended Key Usage extension in a certificate matches the o The Extended Key Usage extension in a certificate matches the
request when all key purpose OIDs present in the request are request when all key purpose OIDs present in the request are
also found in the Extended Key Usage certificate extension. also found in the Extended Key Usage certificate extension.
The special anyExtendedKeyUsage OID MUST NOT be used in the The special anyExtendedKeyUsage OID MUST NOT be used in the
request. request.
Separate specifications may define matching rules for other Separate specifications may define matching rules for other
certificate extensions. certificate extensions.
Servers which are authenticating with a PSK MUST not send the Servers which are authenticating with a PSK MUST NOT send the
CertificateRequest message. CertificateRequest message.
4.4. Authentication Messages 4.4. Authentication Messages
As discussed in Section 2, TLS uses a common set of messages for As discussed in Section 2, TLS uses a common set of messages for
authentication, key confirmation, and handshake integrity: authentication, key confirmation, and handshake integrity:
Certificate, CertificateVerify, and Finished. These messages are Certificate, CertificateVerify, and Finished. These messages are
always sent as the last messages in their handshake flight. The always sent as the last messages in their handshake flight. The
Certificate and CertificateVerify messages are only sent under Certificate and CertificateVerify messages are only sent under
certain circumstances, as defined below. The Finished message is certain circumstances, as defined below. The Finished message is
skipping to change at page 53, line 28 skipping to change at page 53, line 28
Certificate and the Finished MACs the Handshake Context + Certificate Certificate and the Finished MACs the Handshake Context + Certificate
+ CertificateVerify, this is mostly equivalent to keeping a running + CertificateVerify, this is mostly equivalent to keeping a running
hash of the handshake messages (exactly so in the pure 1-RTT cases). hash of the handshake messages (exactly so in the pure 1-RTT cases).
Note, however, that subsequent post-handshake authentications do not Note, however, that subsequent post-handshake authentications do not
include each other, just the messages through the end of the main include each other, just the messages through the end of the main
handshake. handshake.
The following table defines the Handshake Context and MAC Base Key The following table defines the Handshake Context and MAC Base Key
for each scenario: for each scenario:
+-----------+-----------------------------+-------------------------+ +------------+-----------------------------+------------------------+
| Mode | Handshake Context | Base Key | | Mode | Handshake Context | Base Key |
+-----------+-----------------------------+-------------------------+ +------------+-----------------------------+------------------------+
| 1-RTT | ClientHello ... later of En | [sender]_handshake_traf | | Server | ClientHello ... later of En | server_handshake_traff |
| (Server) | cryptedExtensions/Certifica | fic_secret | | | cryptedExtensions/Certifica | ic_secret |
| | teRequest | | | | teRequest | |
| | | | | | | |
| 1-RTT | ClientHello ... | [sender]_handshake_traf | | Client | ClientHello ... | client_handshake_traff |
| (Client) | ServerFinished | fic_secret | | | ServerFinished | ic_secret |
| | | | | | | |
| Post- | ClientHello ... | [sender]_traffic_secret | | Post- | ClientHello ... | client_traffic_secret_ |
| Handshake | ClientFinished + | _N | | Handshake | ClientFinished + | N |
| | CertificateRequest | | | | CertificateRequest | |
+-----------+-----------------------------+-------------------------+ +------------+-----------------------------+------------------------+
The [sender] in this table denotes the sending side.
In all cases, the handshake context is formed by concatenating the In all cases, the handshake context is formed by concatenating the
indicated handshake messages, including the handshake message type indicated handshake messages, including the handshake message type
and length fields. and length fields.
4.4.1. Certificate 4.4.1. Certificate
The server MUST send a Certificate message whenever the agreed-upon The server MUST send a Certificate message whenever the agreed-upon
key exchange method uses certificates for authentication (this key exchange method uses certificates for authentication (this
includes all key exchange methods defined in this document except includes all key exchange methods defined in this document except
skipping to change at page 61, line 15 skipping to change at page 61, line 15
Handshake messages sent after the handshake MUST NOT be interleaved Handshake messages sent after the handshake MUST NOT be interleaved
with other record types. That is, if a message is split over two or with other record types. That is, if a message is split over two or
more handshake records, there MUST NOT be any other records between more handshake records, there MUST NOT be any other records between
them. them.
4.5.1. New Session Ticket Message 4.5.1. New Session Ticket Message
At any time after the server has received the client Finished At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message. This message message, it MAY send a NewSessionTicket message. This message
creates a pre-shared key (PSK) binding between the ticket value and creates a pre-shared key (PSK) binding between the ticket value and
the following two values derived from the resumption master secret: the resumption master secret.
resumption_psk = HKDF-Expand-Label(resumption_secret,
"resumption psk", "", Hash.Length)
The client MAY use this PSK for future handshakes by including the The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello ticket value in the "pre_shared_key" extension in its ClientHello
(Section 4.2.6). Servers MAY send multiple tickets on a single (Section 4.2.6). Servers MAY send multiple tickets on a single
connection, either immediately after each other or after specific connection, either immediately after each other or after specific
events. For instance, the server might send a new ticket after post- events. For instance, the server might send a new ticket after post-
handshake authentication in order to encapsulate the additional handshake authentication in order to encapsulate the additional
client authentication state. Clients SHOULD attempt to use each client authentication state. Clients SHOULD attempt to use each
ticket no more than once, with more recent tickets being used first. ticket no more than once, with more recent tickets being used first.
Any ticket MUST only be resumed with a cipher suite that has the same Any ticket MUST only be resumed with a cipher suite that has the same
KDF hash as that used to establish the original connection. KDF hash as that used to establish the original connection, and if
the client provides the same SNI value as described in Section 3 of
[RFC6066].
Note: Although the resumption_psk depends on the client's second Note: Although the resumption master secret depends on the client's
flight, servers which do not request client authentication MAY second flight, servers which do not request client authentication MAY
compute the remainder of the transcript independently and then send a compute the remainder of the transcript independently and then send a
NewSessionTicket immediately upon sending its Finished rather than NewSessionTicket immediately upon sending its Finished rather than
waiting for the client Finished. waiting for the client Finished.
struct { struct {
uint32 ticket_lifetime; uint32 ticket_lifetime;
uint32 ticket_age_add; uint32 ticket_age_add;
opaque ticket<1..2^16-1>; opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>; Extension extensions<0..2^16-2>;
} NewSessionTicket; } NewSessionTicket;
skipping to change at page 74, line 41 skipping to change at page 74, line 41
decrypt_error A handshake cryptographic operation failed, including decrypt_error A handshake cryptographic operation failed, including
being unable to correctly verify a signature or validate a being unable to correctly verify a signature or validate a
Finished message or a PSK binder. Finished message or a PSK binder.
protocol_version The protocol version the peer has attempted to protocol_version The protocol version the peer has attempted to
negotiate is recognized but not supported. (see Appendix C) negotiate is recognized but not supported. (see Appendix C)
insufficient_security Returned instead of "handshake_failure" when a insufficient_security Returned instead of "handshake_failure" when a
negotiation has failed specifically because the server requires negotiation has failed specifically because the server requires
ciphers more secure than those supported by the client. parameters more secure than those supported by the client.
internal_error An internal error unrelated to the peer or the internal_error An internal error unrelated to the peer or the
correctness of the protocol (such as a memory allocation failure) correctness of the protocol (such as a memory allocation failure)
makes it impossible to continue. makes it impossible to continue.
inappropriate_fallback Sent by a server in response to an invalid inappropriate_fallback Sent by a server in response to an invalid
connection retry attempt from a client. (see [RFC7507]) connection retry attempt from a client. (see [RFC7507])
missing_extension Sent by endpoints that receive a hello message not missing_extension Sent by endpoints that receive a hello message not
containing an extension that is mandatory to send for the offered containing an extension that is mandatory to send for the offered
skipping to change at page 76, line 52 skipping to change at page 76, line 52
for generating the client_early_traffic_secret. for generating the client_early_traffic_secret.
0 0
| |
v v
PSK -> HKDF-Extract PSK -> HKDF-Extract
| |
v v
Early Secret Early Secret
| |
+------> Derive-Secret(., "client early traffic secret",
| ClientHello)
| = client_early_traffic_secret
|
+------> Derive-Secret(., +------> Derive-Secret(.,
| "external psk binder key" | | "external psk binder key" |
| "resumption psk binder key", | "resumption psk binder key",
| "") | "")
| = binder_key | = binder_key
| |
+------> Derive-Secret(., "client early traffic secret",
| ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "early exporter master secret", +-----> Derive-Secret(., "early exporter master secret",
| ClientHello) | ClientHello)
| = early_exporter_secret | = early_exporter_secret
v v
(EC)DHE -> HKDF-Extract (EC)DHE -> HKDF-Extract
| |
v v
Handshake Secret Handshake Secret
| |
+-----> Derive-Secret(., "client handshake traffic secret", +-----> Derive-Secret(., "client handshake traffic secret",
skipping to change at page 81, line 13 skipping to change at page 81, line 13
computations. computations.
8. Compliance Requirements 8. Compliance Requirements
8.1. MTI Cipher Suites 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 otherwise, a TLS-compliant application MUST implement the
TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the
TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher
suites. suites. (see Appendix A.4)
A TLS-compliant application MUST support digital signatures with A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
TLS-compliant application MUST support key exchange with secp256r1 TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
8.2. MTI Extensions 8.2. MTI Extensions
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 following otherwise, a TLS-compliant application MUST implement the following
TLS extensions: TLS extensions:
- Supported Versions ("supported_versions"; Section 4.2.1) - Supported Versions ("supported_versions"; Section 4.2.1)
- Cookie ("cookie"; Section 4.2.2)
- Signature Algorithms ("signature_algorithms"; Section 4.2.3) - Signature Algorithms ("signature_algorithms"; Section 4.2.3)
- Negotiated Groups ("supported_groups"; Section 4.2.4) - Negotiated Groups ("supported_groups"; Section 4.2.4)
- Key Share ("key_share"; Section 4.2.5) - Key Share ("key_share"; Section 4.2.5)
- Pre-Shared Key ("pre_shared_key"; Section 4.2.6) - Pre-Shared Key ("pre_shared_key"; Section 4.2.6)
- Cookie ("cookie"; Section 4.2.2)
- Server Name Indication ("server_name"; Section 3 of [RFC6066]) - Server Name Indication ("server_name"; Section 3 of [RFC6066])
All implementations MUST send and use these extensions when offering All implementations MUST send and use these extensions when offering
applicable features: applicable features:
- "supported_versions" is REQUIRED for all ClientHello messages. - "supported_versions" is REQUIRED for all ClientHello messages.
- "signature_algorithms" is REQUIRED for certificate authentication. - "signature_algorithms" is REQUIRED for certificate authentication.
- "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE - "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE
skipping to change at page 82, line 32 skipping to change at page 82, line 32
Additionally, all implementations MUST support use of the Additionally, all implementations MUST support use of the
"server_name" extension with applications capable of using it. "server_name" extension with applications capable of using it.
Servers MAY require clients to send a valid "server_name" extension. Servers MAY require clients to send a valid "server_name" extension.
Servers requiring this extension SHOULD respond to a ClientHello Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension by terminating the connection with lacking a "server_name" extension by terminating the connection with
a "missing_extension" alert. a "missing_extension" alert.
9. Security Considerations 9. Security Considerations
Security issues are discussed throughout this memo, especially in Security issues are discussed throughout this memo, especially in
Appendices B, C, and D. Appendix B, Appendix C, and Appendix D.
10. IANA Considerations 10. IANA Considerations
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 are below: registries and their allocation policies are below:
- TLS Cipher Suite Registry: Values with the first byte in the range - TLS Cipher Suite Registry: Values with the first byte in the range
0-254 (decimal) are assigned via Specification Required [RFC5226]. 0-254 (decimal) are assigned via Specification Required [RFC5226].
Values with the first byte 255 (decimal) are reserved for Private Values with the first byte 255 (decimal) are reserved for Private
skipping to change at page 84, line 43 skipping to change at page 84, line 43
| cert_type [RFC6091] | Yes | Encrypte | No | | cert_type [RFC6091] | Yes | Encrypte | No |
| | | d | | | | | d | |
| | | | | | | | | |
| supported_groups [RFC7919] | Yes | Encrypte | No | | supported_groups [RFC7919] | Yes | Encrypte | No |
| | | d | | | | | d | |
| | | | | | | | | |
| ec_point_formats [RFC4492] | Yes | No | No | | ec_point_formats [RFC4492] | Yes | No | No |
| | | | | | | | | |
| srp [RFC5054] | No | No | No | | srp [RFC5054] | No | No | No |
| | | | | | | | | |
| signature_algorithms | Yes | Clear | No | | signature_algorithms | Yes | Client | No |
| [RFC5246] | | | | | [RFC5246] | | | |
| | | | | | | | | |
| use_srtp [RFC5764] | Yes | Encrypte | No | | use_srtp [RFC5764] | Yes | Encrypte | No |
| | | d | | | | | d | |
| | | | | | | | | |
| heartbeat [RFC6520] | Yes | Encrypte | No | | heartbeat [RFC6520] | Yes | Encrypte | No |
| | | d | | | | | d | |
| | | | | | | | | |
| application_layer_protocol_ | Yes | Encrypte | No | | application_layer_protocol_ | Yes | Encrypte | No |
| negotiation [RFC7301] | | d | | | negotiation [RFC7301] | | d | |
skipping to change at page 89, line 37 skipping to change at page 89, line 37
[FW15] Florian Weimer, ., "Factoring RSA Keys With TLS Perfect [FW15] Florian Weimer, ., "Factoring RSA Keys With TLS Perfect
Forward Secrecy", September 2015. Forward Secrecy", September 2015.
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of [GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", Operation: Galois/Counter Mode (GCM) and GMAC",
NIST Special Publication 800-38D, November 2007. NIST Special Publication 800-38D, November 2007.
[I-D.sandj-tls-iana-registry-updates] [I-D.sandj-tls-iana-registry-updates]
Salowey, J. and S. Turner, "D/TLS IANA Registry Updates", Salowey, J. and S. Turner, "D/TLS IANA Registry Updates",
draft-sandj-tls-iana-registry-updates-00 (work in draft-sandj-tls-iana-registry-updates-01 (work in
progress), September 2016. progress), October 2016.
[IEEE1363] [IEEE1363]
IEEE, "Standard Specifications for Public Key IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363 , 2000. Cryptography", IEEE 1363 , 2000.
[LXZFH16] Li, X., Xu, J., Feng, D., Zhang, Z., and H. Hu, "Multiple [LXZFH16] Li, X., Xu, J., Feng, D., Zhang, Z., and H. Hu, "Multiple
Handshakes Security of TLS 1.3 Candidates", Proceedings of Handshakes Security of TLS 1.3 Candidates", Proceedings of
IEEE Symposium on Security and Privacy (Oakland) 2016 , IEEE Symposium on Security and Privacy (Oakland) 2016 ,
2016. 2016.
skipping to change at page 104, line 18 skipping to change at page 104, line 18
[RFC4086] provides guidance on the generation of random values. [RFC4086] provides guidance on the generation of random values.
B.3. Certificates and Authentication B.3. 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.
Applications SHOULD also enforce minimum and maximum key sizes. For
example, certification paths containing keys or signatures weaker
than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure
applications.
B.4. Cipher Suite Support B.4. Implementation Pitfalls
TLS supports a range of key sizes and security levels, including some
that provide no or minimal security. A proper implementation will
probably not support many cipher suites. Applications SHOULD also
enforce minimum and maximum key sizes. For example, certification
paths containing keys or signatures weaker than 2048-bit RSA or
224-bit ECDSA are not appropriate for secure applications. See also
Appendix C.4.
B.5. 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:
skipping to change at page 106, line 5 skipping to change at page 105, line 46
private values, the ECDSA "k" parameter, and other security- private values, the ECDSA "k" parameter, and other security-
critical values? It is RECOMMENDED that implementations implement critical values? It is RECOMMENDED that implementations implement
"deterministic ECDSA" as specified in [RFC6979]. "deterministic ECDSA" as specified in [RFC6979].
- Do you zero-pad Diffie-Hellman public key values to the group size - Do you zero-pad Diffie-Hellman public key values to the group size
(see Section 4.2.5.1)? (see Section 4.2.5.1)?
- Do you verify signatures after making them to protect against RSA- - Do you verify signatures after making them to protect against RSA-
CRT key leaks? [FW15] CRT key leaks? [FW15]
B.6. Client Tracking Prevention B.5. Client Tracking Prevention
Clients SHOULD NOT reuse a session ticket for multiple connections. Clients SHOULD NOT reuse a session ticket for multiple connections.
Reuse of a session ticket allows passive observers to correlate Reuse of a session ticket allows passive observers to correlate
different connections. Servers that issue session tickets SHOULD different connections. Servers that issue session tickets SHOULD
offer at least as many session tickets as the number of connections offer at least as many session tickets as the number of connections
that a client might use; for example, a web browser using HTTP/1.1 that a client might use; for example, a web browser using HTTP/1.1
[RFC7230] might open six connections to a server. Servers SHOULD [RFC7230] might open six connections to a server. Servers SHOULD
issue new session tickets with every connection. This ensures that issue new session tickets with every connection. This ensures that
clients are always able to use a new session ticket when creating a clients are always able to use a new session ticket when creating a
new connection. new connection.
B.7. Unauthenticated Operation B.6. Unauthenticated Operation
Previous versions of TLS offered explicitly unauthenticated cipher Previous versions of TLS offered explicitly unauthenticated cipher
suites based on anonymous Diffie-Hellman. These modes have been suites based on anonymous Diffie-Hellman. These modes have been
deprecated in TLS 1.3. However, it is still possible to negotiate deprecated in TLS 1.3. However, it is still possible to negotiate
parameters that do not provide verifiable server authentication by parameters that do not provide verifiable server authentication by
several methods, including: several methods, including:
- Raw public keys [RFC7250]. - Raw public keys [RFC7250].
- Using a public key contained in a certificate but without - Using a public key contained in a certificate but without
skipping to change at page 111, line 41 skipping to change at page 111, line 38
resumption master secret computed by connection N and needed to form resumption master secret computed by connection N and needed to form
connection N+1 is separate from the traffic keys used by connection connection N+1 is separate from the traffic keys used by connection
N, thus providing forward secrecy between the connections. N, thus providing forward secrecy between the connections.
The PSK binder value forms a binding between a PSK and the current The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the session where the PSK was handshake, as well as between the session where the PSK was
established and the session where it was used. This binding established and the session where it was used. This binding
transitively includes the original handshake transcript, because that transitively includes the original handshake transcript, because that
transcript is digested into the values which produce the Resumption transcript is digested into the values which produce the Resumption
Master Secret. This requires that both the KDF used to produce the Master Secret. This requires that both the KDF used to produce the
RMS and the MAC used to compute the binder be collision resistant. resumption master secret and the MAC used to compute the binder be
These are properties of HKDF and HMAC respectively when used with collision resistant. These are properties of HKDF and HMAC
collision resistant hash functions and producing output of at least respectively when used with collision resistant hash functions and
256 bits. Any future replacement of these functions MUST also producing output of at least 256 bits. Any future replacement of
provide collision resistance. Note: The binder does not cover the these functions MUST also provide collision resistance. Note: The
binder values from other PSKs, though they are included in the binder does not cover the binder values from other PSKs, though they
Finished MAC. are included in the Finished MAC.
If an exporter is used, then it produces values which are unique and If an exporter is used, then it produces values which are unique and
secret (because they are generated from a unique session key). secret (because they are generated from a unique session key).
Exporters computed with different labels and contexts are Exporters computed with different labels and contexts are
computationally independent, so it is not feasible to compute one computationally independent, so it is not feasible to compute one
from another or the session secret from the exported value. Note: from another or the session secret from the exported value. Note:
exporters can produce arbitrary-length values. If exporters are to exporters can produce arbitrary-length values. If exporters are to
be used as channel bindings, the exported value MUST be large enough be used as channel bindings, the exported value MUST be large enough
to provide collision resistance. The exporters provided in TLS 1.3 to provide collision resistance. The exporters provided in TLS 1.3
are derived from the same handshake contexts as the early traffic are derived from the same handshake contexts as the early traffic
 End of changes. 44 change blocks. 
90 lines changed or deleted 88 lines changed or added

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