< draft-ietf-tls-esni-03.txt   draft-ietf-tls-esni-04.txt >
tls E. Rescorla tls E. Rescorla
Internet-Draft RTFM, Inc. Internet-Draft RTFM, Inc.
Intended status: Experimental K. Oku Intended status: Experimental K. Oku
Expires: September 12, 2019 Fastly Expires: January 9, 2020 Fastly
N. Sullivan N. Sullivan
Cloudflare Cloudflare
C. Wood C. Wood
Apple, Inc. Apple, Inc.
March 11, 2019 July 08, 2019
Encrypted Server Name Indication for TLS 1.3 Encrypted Server Name Indication for TLS 1.3
draft-ietf-tls-esni-03 draft-ietf-tls-esni-04
Abstract Abstract
This document defines a simple mechanism for encrypting the Server This document defines a simple mechanism for encrypting the Server
Name Indication for TLS 1.3. Name Indication for TLS 1.3.
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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 22 skipping to change at page 2, line 22
3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SNI Encryption . . . . . . . . . . . . . . . . . . . . . 5 3.2. SNI Encryption . . . . . . . . . . . . . . . . . . . . . 5
4. Publishing the SNI Encryption Key in the DNS . . . . . . . . 5 4. Publishing the SNI Encryption Key in the DNS . . . . . . . . 5
4.1. Encrypted SNI Record . . . . . . . . . . . . . . . . . . 6 4.1. Encrypted SNI Record . . . . . . . . . . . . . . . . . . 6
4.2. Encrypted SNI DNS Resolution . . . . . . . . . . . . . . 8 4.2. Encrypted SNI DNS Resolution . . . . . . . . . . . . . . 8
4.2.1. Address Set Extension . . . . . . . . . . . . . . . . 8 4.2.1. Address Set Extension . . . . . . . . . . . . . . . . 8
4.2.2. Resolution Algorithm . . . . . . . . . . . . . . . . 9 4.2.2. Resolution Algorithm . . . . . . . . . . . . . . . . 9
5. The "encrypted_server_name" extension . . . . . . . . . . . . 10 5. The "encrypted_server_name" extension . . . . . . . . . . . . 10
5.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 11 5.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Sending an encrypted SNI . . . . . . . . . . . . . . 11 5.1.1. Sending an encrypted SNI . . . . . . . . . . . . . . 11
5.1.2. Handling the server response . . . . . . . . . . . . 13 5.1.2. Handling the server response . . . . . . . . . . . . 14
5.1.3. Verifying against the public name . . . . . . . . . . 15 5.1.3. Authenticating for the public name . . . . . . . . . 15
5.2. Client-Facing Server Behavior . . . . . . . . . . . . . . 16 5.1.4. GREASE extensions . . . . . . . . . . . . . . . . . . 16
5.3. Shared Mode Server Behavior . . . . . . . . . . . . . . . 17 5.2. Client-Facing Server Behavior . . . . . . . . . . . . . . 17
5.4. Split Mode Server Behavior . . . . . . . . . . . . . . . 17 5.3. Shared Mode Server Behavior . . . . . . . . . . . . . . . 19
6. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 18 5.4. Split Mode Server Behavior . . . . . . . . . . . . . . . 19
6.1. Misconfiguration and Deployment Concerns . . . . . . . . 18 6. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 20
6.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Misconfiguration and Deployment Concerns . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.2. Comparison Against Criteria . . . . . . . . . . . . . . . 20 7.1. Why is cleartext DNS OK? . . . . . . . . . . . . . . . . 21
7.2.1. Mitigate against replay attacks . . . . . . . . . . . 20 7.2. Optional Record Digests and Trial Decryption . . . . . . 21
7.2.2. Avoid widely-deployed shared secrets . . . . . . . . 20 7.3. Encrypting other Extensions . . . . . . . . . . . . . . . 22
7.2.3. Prevent SNI-based DoS attacks . . . . . . . . . . . . 20 7.4. Related Privacy Leaks . . . . . . . . . . . . . . . . . . 22
7.2.4. Do not stick out . . . . . . . . . . . . . . . . . . 20 7.5. Comparison Against Criteria . . . . . . . . . . . . . . . 22
7.2.5. Forward secrecy . . . . . . . . . . . . . . . . . . . 20 7.5.1. Mitigate against replay attacks . . . . . . . . . . . 22
7.2.6. Proper security context . . . . . . . . . . . . . . . 21 7.5.2. Avoid widely-deployed shared secrets . . . . . . . . 23
7.2.7. Split server spoofing . . . . . . . . . . . . . . . . 21 7.5.3. Prevent SNI-based DoS attacks . . . . . . . . . . . . 23
7.2.8. Supporting multiple protocols . . . . . . . . . . . . 21 7.5.4. Do not stick out . . . . . . . . . . . . . . . . . . 23
7.3. Misrouting . . . . . . . . . . . . . . . . . . . . . . . 21 7.5.5. Forward secrecy . . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.5.6. Proper security context . . . . . . . . . . . . . . . 23
8.1. Update of the TLS ExtensionType Registry . . . . . . . . 21 7.5.7. Split server spoofing . . . . . . . . . . . . . . . . 24
8.2. Update of the TLS Alert Registry . . . . . . . . . . . . 22 7.5.8. Supporting multiple protocols . . . . . . . . . . . . 24
8.3. Update of the Resource Record (RR) TYPEs Registry . . . . 22 7.6. Misrouting . . . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.1. Update of the TLS ExtensionType Registry . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Update of the TLS Alert Registry . . . . . . . . . . . . 24
Appendix A. Communicating SNI and Nonce to Backend Server . . . 24 8.3. Update of the Resource Record (RR) TYPEs Registry . . . . 25
Appendix B. Alternative SNI Protection Designs . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
B.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 26
B.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 25 Appendix A. Communicating SNI and Nonce to Backend Server . . . 27
B.2. Application-layer . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Alternative SNI Protection Designs . . . . . . . . . 27
B.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 25 B.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix C. Total Client Hello Encryption . . . . . . . . . . . 25 B.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 27
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 26 B.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 B.2. Application-layer . . . . . . . . . . . . . . . . . . . . 28
B.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 28
Appendix C. Total Client Hello Encryption . . . . . . . . . . . 28
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
DISCLAIMER: This is very early a work-in-progress design and has not DISCLAIMER: This is very early a work-in-progress design and has not
yet seen significant (or really any) security analysis. It should yet seen significant (or really any) security analysis. It should
not be used as a basis for building production systems. not be used as a basis for building production systems.
Although TLS 1.3 [RFC8446] encrypts most of the handshake, including Although TLS 1.3 [RFC8446] encrypts most of the handshake, including
the server certificate, there are several other channels that allow the server certificate, there are several other channels that allow
an on-path attacker to determine the domain name the client is trying an on-path attacker to determine the domain name the client is trying
skipping to change at page 4, line 16 skipping to change at page 4, line 21
SNI does not indicate that the client is attempting to reach a SNI does not indicate that the client is attempting to reach a
private origin, but only that it is going to a particular service private origin, but only that it is going to a particular service
provider, which the observer could already tell from the IP address. provider, which the observer could already tell from the IP address.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here. All TLS notation comes from [RFC8446];
Section 3.
3. Overview 3. Overview
This document is designed to operate in one of two primary topologies This document is designed to operate in one of two primary topologies
shown below, which we call "Shared Mode" and "Split Mode" shown below, which we call "Shared Mode" and "Split Mode"
3.1. Topologies 3.1. Topologies
+---------------------+ +---------------------+
| | | |
skipping to change at page 5, line 48 skipping to change at page 5, line 48
served by an ESNI-supporting provider, it sends an served by an ESNI-supporting provider, it sends an
"encrypted_server_name" extension, which contains the true extension "encrypted_server_name" extension, which contains the true extension
encrypted under the provider's public key. The provider can then encrypted under the provider's public key. The provider can then
decrypt the extension and either terminate the connection (in Shared decrypt the extension and either terminate the connection (in Shared
Mode) or forward it to the backend server (in Split Mode). Mode) or forward it to the backend server (in Split Mode).
4. Publishing the SNI Encryption Key in the DNS 4. Publishing the SNI Encryption Key in the DNS
Publishing ESNI keys in the DNS requires care to ensure correct Publishing ESNI keys in the DNS requires care to ensure correct
behavior. There are deployment environments in which a domain is behavior. There are deployment environments in which a domain is
served by multiple server operators who do not manage the ESNI Keys. served by multiple server operators who do not manage the ESNI keys.
Because ESNIKeys and A/AAAA lookup are independent, it is therefore Because ESNI and A/AAAA lookups are independent, it is therefore
possible to obtain an ESNIKeys record which does not match the A/AAAA possible to obtain an ESNI record which does not match the A/AAAA
records. (That is, the host to which an A or AAAA record refers is records. (That is, the host to which an A or AAAA record refers is
not in possession of the ESNI keys.) The design of the system must not in possession of the ESNI keys.) The design of the system must
therefore allow clients to detect and recover from this situation. therefore allow clients to detect and recover from this situation
(see Section 4.2 for more details).
Servers operating in Split Mode SHOULD have DNS configured to return Content providers operating in Split Mode SHOULD ensure that the A
the same A (or AAAA) record for all ESNI-enabled servers they and AAAA records for ESNI-enabled server names do not allow
service. This yields an anonymity set of cardinality equal to the identifying the server name from the IP address. This can for
number of ESNI-enabled server domains supported by a given client- example be achieved by always returning the same records for all
facing server. Thus, even with SNI encryption, an attacker which can ESNI-enabled names, or by having the function that picks addresses
enumerate the set of ESNI-enabled domains supported by a client- from a pool not depend on the server name. This yields an anonymity
facing server can guess the correct SNI with probability at least 1/ set of cardinality equal to the number of ESNI-enabled server domains
K, where K is the size of this ESNI-enabled server anonymity set. supported by a given client-facing server. Thus, even with SNI
This probability may be increased via traffic analysis or other encryption, an attacker which can enumerate the set of ESNI-enabled
mechanisms. domains supported by a client-facing server can guess the correct SNI
with probability at least 1/K, where K is the size of this ESNI-
enabled server anonymity set. This probability may be increased via
traffic analysis or other mechanisms.
The following sections describe a DNS record format that achieve The following sections describe a DNS record format that achieve
these goals. these goals.
4.1. Encrypted SNI Record 4.1. Encrypted SNI Record
SNI Encryption keys can be published using the following ESNIKeys SNI Encryption keys can be published using the following ESNIRecord
structure. structure.
// Copied from TLS 1.3 // Copied from TLS 1.3
struct { struct {
NamedGroup group; NamedGroup group;
opaque key_exchange<1..2^16-1>; opaque key_exchange<1..2^16-1>;
} KeyShareEntry; } KeyShareEntry;
struct { struct {
uint16 version; uint16 version;
uint8 checksum[4];
opaque public_name<1..2^16-1>; opaque public_name<1..2^16-1>;
KeyShareEntry keys<4..2^16-1>; KeyShareEntry keys<4..2^16-1>;
CipherSuite cipher_suites<2..2^16-2>; CipherSuite cipher_suites<2..2^16-2>;
uint16 padded_length; uint16 padded_length;
uint64 not_before;
uint64 not_after;
Extension extensions<0..2^16-1>; Extension extensions<0..2^16-1>;
} ESNIKeys; } ESNIKeys;
struct {
ESNIKeys esni_keys;
Extension dns_extensions<0..2^16-1>;
} ESNIRecord;
The outermost ESNIRecord structure contains the following fields:
esni_keys An ESNIKeys structure that contains the actual keys used
to encrypt the SNI as well as some metadata related to those keys.
dns_extensions A list of extensions that the client can take into
consideration when resolving the target DNS name. The format is
defined in [RFC8446]; Section 4.2. The purpose of the field is to
provide room for additional features in the future. An extension
may be tagged as mandatory by using an extension type codepoint
with the high order bit set to 1. A client which receives a
mandatory extension they do not understand must reject the
ESNIRecord values.
The ESNIKeys structure contains the following fields:
version The version of the structure. For this specification, that version The version of the structure. For this specification, that
value SHALL be 0xff02. Clients MUST ignore any ESNIKeys structure value SHALL be 0xff03. Clients MUST ignore any ESNIKeys structure
with a version they do not understand. [[NOTE: This means that with a version they do not understand. [[NOTE: This means that
the RFC will presumably have a nonzero value.]] the RFC will presumably have a nonzero value.]]
checksum The first four (4) octets of the SHA-256 message digest
[RFC6234] of the ESNIKeys structure. For the purpose of computing
the checksum, the value of the "checksum" field MUST be set to
zero.
public_name The non-empty name of the entity trusted to update these public_name The non-empty name of the entity trusted to update these
encryption keys. This is used to repair misconfigurations, as encryption keys. This is used to repair misconfigurations, as
described in Section 5.1.2. described in Section 5.1.2.
keys The list of keys which can be used by the client to encrypt the keys The list of keys which can be used by the client to encrypt the
SNI. Every key being listed MUST belong to a different group. SNI. Every key being listed MUST belong to a different group.
padded_length : The length to pad the ServerNameList value to prior padded_length The length to pad the ServerNameList value to prior to
to encryption. This value SHOULD be set to the largest encryption. This value SHOULD be set to the largest ServerNameList
ServerNameList the server expects to support rounded up the nearest the server expects to support rounded up the nearest multiple of 16.
multiple of 16. If the server supports wildcard names, it SHOULD set If the server supports arbitrary wildcard names, it SHOULD set this
this value to 260. value to 260. Clients SHOULD reject ESNIKeys as invalid if
padded_length is greater than 260.
not_before The moment when the keys become valid for use. The value
is represented as seconds from 00:00:00 UTC on Jan 1 1970, not
including leap seconds.
not_after The moment when the keys become invalid. Uses the same
unit as not_before.
extensions A list of extensions that the client can take into extensions A list of extensions that the client can take into
consideration when generating a Client Hello message. The format consideration when generating a Client Hello message. The format
is defined in [RFC8446]; Section 4.2. The purpose of the field is is defined in [RFC8446]; Section 4.2. The purpose of the field is
to provide room for additional features in the future. An to provide room for additional features in the future. An
extension may be tagged as mandatory by using an extension type extension may be tagged as mandatory by using an extension type
codepoint with the high order bit set to 1. A client which codepoint with the high order bit set to 1. A client which
receives a mandatory extension they do not understand must reject receives a mandatory extension they do not understand must reject
the record. the ESNIRecord value.
The semantics of this structure are simple: any of the listed keys Any of the listed keys in the ESNIKeys value may be used to encrypt
may be used to encrypt the SNI for the associated domain name. The the SNI for the associated domain name. The cipher suite list is
cipher suite list is orthogonal to the list of keys, so each key may orthogonal to the list of keys, so each key may be used with any
be used with any cipher suite. Clients MUST parse the extension list cipher suite. Clients MUST parse the extension list and check for
and check for unsupported mandatory extensions. If an unsupported unsupported mandatory extensions. If an unsupported mandatory
mandatory extension is present, clients MUST reject the ESNIKeys extension is present, clients MUST reject the ESNIRecord value.
record.
This structure is placed in the RRData section of an ESNI record as- The ESNIRecord structure is placed in the RRData section of an ESNI
is. Servers MAY supply multiple ESNIKeys values, either of the same record as-is. Servers MAY supply multiple ESNIRecord values, with
or of different versions. This allows a server to support multiple ESNIKeys either of the same or of different versions. This allows a
versions at once. If the server does not supply any ESNIKeys values server to support multiple versions at once. If the server does not
with a version known to the client, then the client MUST behave as if supply any ESNIRecord values with an ESNIKeys version known to the
no ESNIKeys were found. client, then the client MUST behave as if no ESNI records were found.
The name of each ESNI record MUST match the query domain name or the The name of each ESNI record MUST match the query domain name or the
query domain name's canonicalized form. That is, if a client queries query domain name's canonicalized form. That is, if a client queries
example.com, the ESNI Resource Record might be: example.com, the ESNI Resource Record might be:
example.com. 60S IN ESNI "..." "..." example.com. 60S IN ESNI "..." "..."
The "checksum" field provides protection against transmission errors, In the event that ESNIKeys is corrupt in transit or otherwise
including those caused by intermediaries such as a DNS proxy running invalid, servers will initiate the retry mechanism described in
on a home router. Section 5.2 and deliver valid ESNIKeys to clients.
"not_before" and "not_after" fields represent the validity period of
the published ESNI keys. Clients MUST NOT use ESNI keys that was
covered by an invalid checksum or beyond the published period. If
none of the ESNI keys values are acceptable, the client SHOULD behave
as if no ESNIKeys were found.
Servers SHOULD set the Resource Record TTL small enough so that the
record gets discarded by the cache before the ESNI keys reach the end
of their validity period. Note that servers MAY need to retain the
decryption key for some time after "not_after", and will need to
consider clock skew, internal caches and the like, when selecting the
"not_before" and "not_after" values.
Client MAY cache the ESNIKeys for a particular domain based on the
TTL of the Resource Record, but SHOULD NOT cache it based on the
not_after value, to allow servers to rotate the keys often and
improve forward secrecy.
Note that the length of this structure MUST NOT exceed 2^16 - 1, as Note that the length of the ESNIRecord structure MUST NOT exceed 2^16
the RDLENGTH is only 16 bits [RFC1035]. - 1, as the RDLENGTH is only 16 bits [RFC1035].
4.2. Encrypted SNI DNS Resolution 4.2. Encrypted SNI DNS Resolution
This section describes a client ESNI resolution algorithm using a new This section describes a client ESNI resolution algorithm using an
"address_set" extension described below. Future specifications may "address_set" extension for the ESNIRecord structure. Future
introduce new extensions and corresponding resolution algorithms. specifications may introduce new ESNIRecord extensions and
corresponding resolution algorithms.
4.2.1. Address Set Extension 4.2.1. Address Set Extension
ESNIKeys records MAY indicate a specific IP address(es) for the ESNIRecord values MAY indicate one or more IP addresses for the
host(s) in possession of the ESNI private key via the following host(s) in possession of the private key corresponding to one of the
mandatory "address_set" ESNIKeys extension: keys provided in the ESNIKeys structure, via the following mandatory
"address_set" extension:
enum { enum {
address_set(0x1001), (65535) address_set(0x1001), (65535)
} ExtensionType; } ExtensionType;
The body of this extension is encoded using the following structure. The body of this extension is encoded using the following structure.
enum { enum {
address_v4(4), address_v4(4),
address_v6(6), address_v6(6),
skipping to change at page 9, line 29 skipping to change at page 9, line 29
} }
} Address; } Address;
struct { struct {
Address address_set<1..2^16-1>; Address address_set<1..2^16-1>;
} AddressSet; } AddressSet;
address_set A set of Address structures containing IPv4 or IPv6 address_set A set of Address structures containing IPv4 or IPv6
addresses to hosts which have the corresponding private ESNI key. addresses to hosts which have the corresponding private ESNI key.
This extension MUST NOT be placed in the ESNIKeys extensions field,
but only in the ESNIRecord dns_extensions field.
4.2.2. Resolution Algorithm 4.2.2. Resolution Algorithm
Clients obtain ESNI records by querying the DNS for ESNI-enabled Clients obtain ESNI records by querying the DNS for ESNI-enabled
server domains. In cases where the domain of the A or AAAA records server domains. In cases where the domain of the A or AAAA records
being resolved do not match the SNI Server Name, such as when being resolved do not match the SNI Server Name, such as when
[RFC7838] is being used, the alternate domain should be used for [RFC7838] is being used, the alternate domain should be used for
querying the ESNI TXT record. (See Section 2.3 of [RFC7838] for more querying the ESNI record. (See Section 2.3 of [RFC7838] for more
details.) details.)
Clients SHOULD initiate ESNI queries in parallel alongside normal A Clients SHOULD initiate ESNI queries in parallel alongside normal A
or AAAA queries to obtain address information in a timely manner in or AAAA queries to obtain address information in a timely manner in
the event that ESNI is available. The following algorithm describes the event that ESNI is available. The following algorithm describes
a procedure by which clients can process ESNIKeys responses as they a procedure by which clients can process ESNI responses as they
arrive to produce addresses for ESNI-capable hosts. arrive to produce addresses for ESNI-capable hosts.
1. If an ESNIKeys response with an "address_set" extension arrives before an A or 1. If an ESNI response containing an ESNIRecord value with an "address_set" extension arrives before an A or
AAAA response, clients SHOULD initiate TLS with ESNI to the provided address(es). AAAA response, clients SHOULD initiate TLS with ESNI to the provided address(es).
2. If an A or AAAA response arrives before the ESNIKeys response, clients SHOULD wait up 2. If an A or AAAA response arrives before the ESNI response, clients SHOULD wait up
to CD milliseconds before initiating TLS to either address. (Clients may begin to CD milliseconds before initiating TLS to either address. (Clients may begin
TCP connections in this time. QUIC connections should wait.) If an ESNIKeys TCP connections in this time. QUIC connections should wait.) If an ESNI
response with an "address_set" extension arrives in this time, clients SHOULD response with an "address_set" extension arrives in this time, clients SHOULD
initiate TLS with ESNI to the provided address(es). If an ESNIKeys response initiate TLS with ESNI to the provided address(es). If an ESNI response
without an "address_set" extension arrives in this time, clients MAY initiate without an "address_set" extension arrives in this time, clients MAY initiate
TLS with ESNI to the address(es) in the A or AAAA response. If no ESNIKeys response TLS with ESNI to the address(es) in the A or AAAA response. If no ESNI response
arrives in this time, clients SHOULD initiate TLS without ESNI to the available address(es). arrives in this time, clients SHOULD initiate TLS without ESNI to the available address(es).
CD (Connection Delay) is a configurable parameter. The recommended CD (Connection Delay) is a configurable parameter. The recommended
value is 50 milliseconds, as per the guidance in [RFC8305]. value is 50 milliseconds, as per the guidance in [RFC8305].
5. The "encrypted_server_name" extension 5. The "encrypted_server_name" extension
The encrypted SNI is carried in an "encrypted_server_name" extension, The encrypted SNI is carried in an "encrypted_server_name" extension,
defined as follows: defined as follows:
skipping to change at page 10, line 46 skipping to change at page 10, line 46
opaque encrypted_sni<0..2^16-1>; opaque encrypted_sni<0..2^16-1>;
} ClientEncryptedSNI; } ClientEncryptedSNI;
suite The cipher suite used to encrypt the SNI. suite The cipher suite used to encrypt the SNI.
key_share The KeyShareEntry carrying the client's public ephemeral key_share The KeyShareEntry carrying the client's public ephemeral
key shared used to derive the ESNI key. key shared used to derive the ESNI key.
record_digest A cryptographic hash of the ESNIKeys structure from record_digest A cryptographic hash of the ESNIKeys structure from
which the ESNI key was obtained, i.e., from the first byte of which the ESNI key was obtained, i.e., from the first byte of
"checksum" to the end of the structure. This hash is computed "version" to the end of the structure. This hash is computed
using the hash function associated with "suite". using the hash function associated with "suite".
encrypted_sni The ClientESNIInner structure, AEAD-encrypted using encrypted_sni The ClientESNIInner structure, AEAD-encrypted using
cipher suite "suite" and the key generated as described below. cipher suite "suite" and the key generated as described below.
For servers (in EncryptedExtensions), this extension contains the For servers (in EncryptedExtensions), this extension contains the
following structure: following structure:
enum { enum {
esni_accept(0), esni_accept(0),
skipping to change at page 12, line 10 skipping to change at page 12, line 10
In order to send an encrypted SNI, the client MUST first select one In order to send an encrypted SNI, the client MUST first select one
of the server ESNIKeyShareEntry values and generate an (EC)DHE share of the server ESNIKeyShareEntry values and generate an (EC)DHE share
in the matching group. This share will then be sent to the server in in the matching group. This share will then be sent to the server in
the "encrypted_sni" extension and used to derive the SNI encryption the "encrypted_sni" extension and used to derive the SNI encryption
key. It does not affect the (EC)DHE shared secret used in the TLS key. It does not affect the (EC)DHE shared secret used in the TLS
key schedule. It MUST also select an appropriate cipher suite from key schedule. It MUST also select an appropriate cipher suite from
the list of suites offered by the server. If the client is unable to the list of suites offered by the server. If the client is unable to
select an appropriate group or suite it SHOULD ignore that ESNIKeys select an appropriate group or suite it SHOULD ignore that ESNIKeys
value and MAY attempt to use another value provided by the server. value and MAY attempt to use another value provided by the server.
(Recall that servers might provide multiple ESNIKeys in response to a (Recall that servers might provide multiple ESNIRecord values in
ESNI record query.) The client MUST NOT send encrypted SNI using response to a ESNI record query, each containing an ESNIKeys value.)
groups or cipher suites not advertised by the server. The client MUST NOT send encrypted SNI using groups or cipher suites
not advertised by the server.
When offering an encrypted SNI, the client MUST NOT offer to resume When offering an encrypted SNI, the client MUST NOT offer to resume
any non-ESNI PSKs. It additionally MUST NOT offer to resume any any non-ESNI PSKs. It additionally MUST NOT offer to resume any
sessions for TLS 1.2 or below. sessions for TLS 1.2 or below.
Let Z be the DH shared secret derived from a key share in ESNIKeys Let Z be the DH shared secret derived from a key share in ESNIKeys
and the corresponding client share in ClientEncryptedSNI.key_share. and the corresponding client share in ClientEncryptedSNI.key_share.
The SNI encryption key is computed from Z as follows: The SNI encryption key is computed from Z as follows:
Zx = HKDF-Extract(0, Z) Zx = HKDF-Extract(0, Z)
key = HKDF-Expand-Label(Zx, "esni key", Hash(ESNIContents), key_length) key = HKDF-Expand-Label(Zx, KeyLabel, Hash(ESNIContents), key_length)
iv = HKDF-Expand-Label(Zx, "esni iv", Hash(ESNIContents), iv_length) iv = HKDF-Expand-Label(Zx, IVLabel, Hash(ESNIContents), iv_length)
where ESNIContents is as specified below and Hash is the hash where ESNIContents is as specified below and Hash is the hash
function associated with the HKDF instantiation. function associated with the HKDF instantiation. The salt argument
for HKDF-Extract is a string consisting of Hash.length bytes set to
zeros. For a client's first ClientHello, KeyLabel = "esni key" and
IVLabel = "esni iv", whereas for a client's second ClientHello, sent
in response to a HelloRetryRequest, KeyLabel = "hrr esni key" and
IVLabel = "hrr esni iv". (This label variance is done to prevent
nonce re-use since the client's ESNI key share, and thus the value of
Zx, does not change across ClientHello retries.)
[[TODO: label swapping fixes a bug in the spec, though this may not
be the best way to deal with HRR. See https://github.com/tlswg/
draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft-
ietf-tls-esni/pull/170 for more details.]]
struct { struct {
opaque record_digest<0..2^16-1>; opaque record_digest<0..2^16-1>;
KeyShareEntry esni_key_share; KeyShareEntry esni_key_share;
Random client_hello_random; Random client_hello_random;
} ESNIContents; } ESNIContents;
The client then creates a ClientESNIInner structure: The client then creates a ClientESNIInner structure:
struct { struct {
ServerNameList sni; opaque dns_name<1..2^16-1>;
opaque zeros[ESNIKeys.padded_length - length(sni)]; opaque zeros[ESNIKeys.padded_length - length(sni)];
} PaddedServerNameList; } PaddedServerNameList;
struct { struct {
uint8 nonce[16]; uint8 nonce[16];
PaddedServerNameList realSNI; PaddedServerNameList realSNI;
} ClientESNIInner; } ClientESNIInner;
nonce A random 16-octet value to be echoed by the server in the nonce A random 16-octet value to be echoed by the server in the
"encrypted_server_name" extension. "encrypted_server_name" extension.
sni The true SNI, that is, the ServerNameList that would have been dns_name The true SNI DNS name, that is, the HostName value that
sent in the plaintext "server_name" extension. would have been sent in the plaintext "server_name" extension.
(NameType values other than "host_name" are unsupported since SNI
extensibility failed [SNIExtensibilityFailed]).
zeros Zero padding whose length makes the serialized zeros Zero padding whose length makes the serialized
PaddedServerNameList struct have a length equal to PaddedServerNameList struct have a length equal to
ESNIKeys.padded_length. ESNIKeys.padded_length.
This value consists of the serialized ServerNameList from the This value consists of the serialized ServerNameList from the
"server_name" extension, padded with enough zeroes to make the total "server_name" extension, padded with enough zeroes to make the total
structure ESNIKeys.padded_length bytes long. The purpose of the structure ESNIKeys.padded_length bytes long. The purpose of the
padding is to prevent attackers from using the length of the padding is to prevent attackers from using the length of the
"encrypted_server_name" extension to determine the true SNI. If the "encrypted_server_name" extension to determine the true SNI. If the
serialized ServerNameList is longer than ESNIKeys.padded_length, the serialized ServerNameList is longer than ESNIKeys.padded_length, the
client MUST NOT use the "encrypted_server_name" extension. client MUST NOT use the "encrypted_server_name" extension.
The ClientEncryptedSNI.encrypted_sni value is then computed using the The ClientEncryptedSNI.encrypted_sni value is then computed using the
usual TLS 1.3 AEAD: usual TLS 1.3 AEAD:
encrypted_sni = AEAD-Encrypt(key, iv, ClientHello.KeyShareClientHello, ClientESNIInner) encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello, ClientESNIInner)
Where ClientHello.KeyShareClientHello is the body of the extension Where KeyShareClientHello is the "extension_data" field of the
but not including the extension header. Including "key_share" extension in a Client Hello (Section 4.2.8 of
ClientHello.KeyShareClientHello in the AAD of AEAD-Encrypt binds the [RFC8446])). Including KeyShareClientHello in the AAD of AEAD-
ClientEncryptedSNI value to the ClientHello and prevents cut-and- Encrypt binds the ClientEncryptedSNI value to the ClientHello and
paste attacks. prevents cut-and-paste attacks.
Note: future extensions may end up reusing the server's Note: future extensions may end up reusing the server's
ESNIKeyShareEntry for other purposes within the same message (e.g., ESNIKeyShareEntry for other purposes within the same message (e.g.,
encrypting other values). Those usages MUST have their own HKDF encrypting other values). Those usages MUST have their own HKDF
labels to avoid reuse. labels to avoid reuse.
[[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT [[OPEN ISSUE: If in the future you were to reuse these keys for 0-RTT
priming, then you would have to worry about potentially expanding priming, then you would have to worry about potentially expanding
twice of Z_extracted. We should think about how to harmonize these twice of Z_extracted. We should think about how to harmonize these
to make sure that we maintain key separation.]] to make sure that we maintain key separation.]]
skipping to change at page 14, line 8 skipping to change at page 14, line 24
5.1.2. Handling the server response 5.1.2. Handling the server response
If the server negotiates TLS 1.3 or above and provides an If the server negotiates TLS 1.3 or above and provides an
"encrypted_server_name" extension in EncryptedExtensions, the client "encrypted_server_name" extension in EncryptedExtensions, the client
then processes the extension's "response_type" field: then processes the extension's "response_type" field:
o If the value is "esni_accept", the client MUST check that the o If the value is "esni_accept", the client MUST check that the
extension's "nonce" field matches ClientESNIInner.nonce and extension's "nonce" field matches ClientESNIInner.nonce and
otherwise abort the connection with an "illegal_parameter" alert. otherwise abort the connection with an "illegal_parameter" alert.
The client then proceeds with the connection as usual, verifying The client then proceeds with the connection as usual,
the certificate against the desired name. authenticating the connection for the origin server.
o If the value is "esni_retry_request", the client proceeds with the o If the value is "esni_retry_request", the client proceeds with the
handshake, verifying the certificate against ESNIKeys.public_name handshake, authenticating for ESNIKeys.public_name as described in
as described in Section 5.1.3. If verification or the handshake Section 5.1.3. If authentication or the handshake fails, the
fails, the client MUST return a failure to the calling client MUST return a failure to the calling application. It MUST
application. It MUST NOT use the retry keys. NOT use the retry keys.
Otherwise, when the handshake completes successfully with the Otherwise, when the handshake completes successfully with the
public name verified, the client MUST abort the connection with an public name authenticated, the client MUST abort the connection
"esni_required" alert. It then processes the "retry_keys" field with an "esni_required" alert. It then processes the "retry_keys"
from the server's "encrypted_server_name" extension. field from the server's "encrypted_server_name" extension.
If one of the values contains a version supported by the client, If one of the values contains a version supported by the client,
it can regard the ESNI keys as securely replaced by the server. it can regard the ESNI keys as securely replaced by the server.
It SHOULD retry the handshake with a new transport connection, It SHOULD retry the handshake with a new transport connection,
using that value to encrypt the SNI. The value may only be using that value to encrypt the SNI. The value may only be
applied to the retry connection. The client MUST continue to use applied to the retry connection. The client MUST continue to use
the previously-advertised keys for subsequent connections. This the previously-advertised keys for subsequent connections. This
avoids introducing pinning concerns or a tracking vector, should a avoids introducing pinning concerns or a tracking vector, should a
malicious server present client-specific retry keys to identify malicious server present client-specific retry keys to identify
clients. clients.
skipping to change at page 14, line 42 skipping to change at page 15, line 10
If none of the values provided in "retry_keys" contains a If none of the values provided in "retry_keys" contains a
supported version, the client can regard ESNI as securely disabled supported version, the client can regard ESNI as securely disabled
by the server. As below, it SHOULD then retry the handshake with by the server. As below, it SHOULD then retry the handshake with
a new transport connection and ESNI disabled. a new transport connection and ESNI disabled.
o If the field contains any other value, the client MUST abort the o If the field contains any other value, the client MUST abort the
connection with an "illegal_parameter" alert. connection with an "illegal_parameter" alert.
If the server negotiates an earlier version of TLS, or if it does not If the server negotiates an earlier version of TLS, or if it does not
provide an "encrypted_server_name" extension in EncryptedExtensions, provide an "encrypted_server_name" extension in EncryptedExtensions,
the client proceeds with the handshake, verifying the certificate the client proceeds with the handshake, authenticating for
against ESNIKeys.public_name as described in Section 5.1.3. The ESNIKeys.public_name as described in Section 5.1.3. If an earlier
client MUST NOT enable the False Start optimization [RFC7918] for version was negotiated, the client MUST NOT enable the False Start
this handshake. If verification or the handshake fails, the client optimization [RFC7918] for this handshake. If authentication or the
MUST return a failure to the calling application. It MUST NOT treat handshake fails, the client MUST return a failure to the calling
this as a secure signal to disable ESNI. application. It MUST NOT treat this as a secure signal to disable
ESNI.
Otherwise, when the handshake completes successfully with the public Otherwise, when the handshake completes successfully with the public
name verified, the client MUST abort the connection with an name authenticated, the client MUST abort the connection with an
"esni_required" alert. The client can then regard ESNI as securely "esni_required" alert. The client can then regard ESNI as securely
disabled by the server. It SHOULD retry the handshake with a new disabled by the server. It SHOULD retry the handshake with a new
transport connection and ESNI disabled. transport connection and ESNI disabled.
[[TODO: Key replacement is significantly less scary than saying that [[TODO: Key replacement is significantly less scary than saying that
ESNI-naive servers bounce ESNI off. Is it worth defining a strict ESNI-naive servers bounce ESNI off. Is it worth defining a strict
mode toggle in the ESNI keys, for a deployment to indicate it is mode toggle in the ESNI keys, for a deployment to indicate it is
ready for that? ]] ready for that? ]]
Clients SHOULD implement a limit on retries caused by Clients SHOULD implement a limit on retries caused by
"esni_retry_request" or servers which do not acknowledge the "esni_retry_request" or servers which do not acknowledge the
"encrypted_server_name" extension. If the client does not retry in "encrypted_server_name" extension. If the client does not retry in
either scenario, it MUST report an error to the calling application. either scenario, it MUST report an error to the calling application.
If the server sends a HelloRetryRequest in response to the If the server sends a HelloRetryRequest in response to the
ClientHello and the client can send a second updated ClientHello per ClientHello and the client can send a second updated ClientHello per
the rules in [RFC8446], the "encrypted_server_name" extension values the rules in [RFC8446], the "encrypted_server_name" extension values
which do not depend on the (possibly updated) which do not depend on the (possibly updated) KeyShareClientHello,
ClientHello.KeyShareClientHello, i.e,, ClientEncryptedSNI.suite, i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and
ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest, ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello
MUST NOT change across ClientHello messages. Moreover, messages. Moreover, ClientESNIInner MUST not change across
ClientESNIInner.nonce and ClientESNIInner.realSNI MUST not change ClientHello messages. Informally, the values of all unencrypted
across ClientHello messages. Informally, the values of all extension information, as well as the inner extension plaintext, must
unencrypted extension information, as well as the inner extension be consistent between the first and second ClientHello messages.
plaintext, must be consistent between the first and second
ClientHello messages.
5.1.3. Verifying against the public name 5.1.3. Authenticating for the public name
When the server cannot decrypt or does not process the When the server cannot decrypt or does not process the
"encrypted_server_name" extension, it continues with the handshake "encrypted_server_name" extension, it continues with the handshake
using the cleartext "server_name" extension instead (see using the cleartext "server_name" extension instead (see
Section 5.2). Clients that offer ESNI then verify the certificate Section 5.2). Clients that offer ESNI then authenticate the
with the public name, as follows: connection with the public name, as follows:
o If the server resumed a session or negotiated a session that did o If the server resumed a session or negotiated a session that did
not use a certificate for authentication, the client MUST abort not use a certificate for authentication, the client MUST abort
the connection with an "illegal_parameter" alert. This case is the connection with an "illegal_parameter" alert. This case is
invalid because Section 5.1.1 requires the client to only offer invalid because Section 5.1.1 requires the client to only offer
ESNI-established sessions, and Section 5.2 requires the server to ESNI-established sessions, and Section 5.2 requires the server to
decline ESNI-established sessions if it did not accept ESNI. decline ESNI-established sessions if it did not accept ESNI.
o The client MUST verify that the certificate is valid for o The client MUST verify that the certificate is valid for
ESNIKeys.public_name. If invalid, it MUST abort the connection ESNIKeys.public_name. If invalid, it MUST abort the connection
with the appropriate alert. with the appropriate alert.
o If the server requests a client certificate, the client MUST o If the server requests a client certificate, the client MUST
respond with an empty Certificate message, denoting no client respond with an empty Certificate message, denoting no client
certificate. certificate.
Note that verifying a connection for the public name does not verify Note that authenticating a connection for the public name does not
it for the origin. The TLS implementation MUST NOT report such authenticate it for the origin. The TLS implementation MUST NOT
connections as successful to the application. It additionally MUST report such connections as successful to the application. It
ignore all session tickets and session IDs presented by the server. additionally MUST ignore all session tickets and session IDs
These connections are only used to trigger retries, as described in presented by the server. These connections are only used to trigger
Section 5.1.2. This may be implemented, for instance, by reporting a retries, as described in Section 5.1.2. This may be implemented, for
failed connection with a dedicated error code. instance, by reporting a failed connection with a dedicated error
code.
5.1.4. GREASE extensions
If the client attempts to connect to a server and does not have an
ESNIKeys structure available for the server, it SHOULD send a GREASE
[I-D.ietf-tls-grease] "encrypted_server_name" extension as follows:
o Select a supported cipher suite, named group, and padded_length
value. The padded_length value SHOULD be 260 or a multiple of 16
less than
1. Set the "suite" field to the selected cipher suite. These
selections SHOULD vary to exercise all supported
configurations, but MAY be held constant for successive
connections to the same server in the same session.
o Set the "key_share" field to a randomly-generated valid public key
for the named group.
o Set the "record_digest" field to a randomly-generated string of
hash_length bytes, where hash_length is the length of the hash
function associated with the chosen cipher suite.
o Set the "encrypted_sni" field to a randomly-generated string of 16
+ padded_length + tag_length bytes, where tag_length is the tag
length of the chosen cipher suite's associated AEAD.
If the server sends an "encrypted_server_name" extension, the client
MUST check the extension syntactically and abort the connection with
a "decode_error" alert if it is invalid. If the "response_type"
field contains "esni_retry_requested", the client MUST ignore the
extension and proceed with the handshake. If it contains
"esni_accept" or any other value, the client MUST abort the
connection with an "illegal_parameter" alert.
Offering a GREASE extension is not considered offering an encrypted
SNI for purposes of requirements in Section 5.1. In particular, the
client MAY offer to resume sessions established without ESNI.
5.2. Client-Facing Server Behavior 5.2. Client-Facing Server Behavior
Upon receiving an "encrypted_server_name" extension, the client- Upon receiving an "encrypted_server_name" extension, the client-
facing server MUST check that it is able to negotiate TLS 1.3 or facing server MUST check that it is able to negotiate TLS 1.3 or
greater. If not, it MUST abort the connection with a greater. If not, it MUST abort the connection with a
"handshake_failure" alert. "handshake_failure" alert.
If the ClientEncryptedSNI.record_digest value does not match the The ClientEncryptedSNI value is said to match a known ESNIKeys if
cryptographic hash of any known ESNIKeys structure, it MUST ignore there exists an ESNIKeys that can be used to successfully decrypt
the extension and proceed with the connection, with the following ClientEncryptedSNI.encrypted_sni. This matching procedure should be
added behavior: done using one of the following two checks:
1. Compare ClientEncryptedSNI.record_digest against cryptographic
hashes of known ESNIKeys and choose the one that matches.
2. Use trial decryption of ClientEncryptedSNI.encrypted_sni with
known ESNIKeys and choose the one that succeeds.
Some uses of ESNI, such as local discovery mode, may omit the
ClientEncryptedSNI.record_digest since it can be used as a tracking
vector. In such cases, trial decryption should be used for matching
ClientEncryptedSNI to known ESNIKeys. Unless specified by the
application using (D)TLS or externally configured on both sides,
implementations MUST use the first method.
If the ClientEncryptedSNI value does not match any known ESNIKeys
structure, it MUST ignore the extension and proceed with the
connection, with the following added behavior:
o It MUST include the "encrypted_server_name" extension in o It MUST include the "encrypted_server_name" extension in
EncryptedExtensions message with the "response_type" field set to EncryptedExtensions message with the "response_type" field set to
"esni_retry_requested" and the "retry_keys" field set to one or "esni_retry_requested" and the "retry_keys" field set to one or
more ESNIKeys structures with up-to-date keys. Servers MAY supply more ESNIKeys structures with up-to-date keys. Servers MAY supply
multiple ESNIKeys values of different versions. This allows a multiple ESNIKeys values of different versions. This allows a
server to support multiple versions at once. server to support multiple versions at once.
o The server MUST ignore all PSK identities in the ClientHello which o The server MUST ignore all PSK identities in the ClientHello which
correspond to ESNI PSKs. ESNI PSKs offered by the client are correspond to ESNI PSKs. ESNI PSKs offered by the client are
associated with the ESNI name. The server was unable to decrypt associated with the ESNI name. The server was unable to decrypt
then ESNI name, so it should not resume them when using the then ESNI name, so it should not resume them when using the
cleartext SNI name. This restriction allows a client to reject cleartext SNI name. This restriction allows a client to reject
resumptions in Section 5.1.3. resumptions in Section 5.1.3.
If the ClientEncryptedSNI.record_digest value does match the Note that an unrecognized ClientEncryptedSNI.record_digest value may
cryptographic hash of a known ESNIKeys, the server performs the be a GREASE ESNI extension (see Section 5.1.4), so it is necessary
following checks: for servers to proceed with the connection and rely on the client to
abort if ESNI was required. In particular, the unrecognized value
alone does not indicate a misconfigured ESNI advertisement
(Section 6.1). Instead, servers can measure occurrences of the
"esni_required" alert to detect this case.
If the ClientEncryptedSNI value does match a known ESNIKeys, the
server performs the following checks:
o If the ClientEncryptedSNI.key_share group does not match one in o If the ClientEncryptedSNI.key_share group does not match one in
the ESNIKeys.keys, it MUST abort the connection with an the ESNIKeys.keys, it MUST abort the connection with an
"illegal_parameter" alert. "illegal_parameter" alert.
o If the length of the "encrypted_server_name" extension is o If the length of the "encrypted_server_name" extension is
inconsistent with the advertised padding length (plus AEAD inconsistent with the advertised padding length (plus AEAD
expansion) the server MAY abort the connection with an expansion) the server MAY abort the connection with an
"illegal_parameter" alert without attempting to decrypt. "illegal_parameter" alert without attempting to decrypt.
Assuming these checks succeed, the server then computes K_sni and Assuming these checks succeed, the server then computes K_sni and
decrypts the ServerName value. If decryption fails, the server MUST decrypts the ServerName value. If decryption fails, the server MUST
abort the connection with a "decrypt_error" alert. abort the connection with a "decrypt_error" alert.
If the decrypted value's length is different from the advertised If the decrypted value's length is different from the advertised
ESNIKeys.padded_length or the padding consists of any value other ESNIKeys.padded_length or the padding consists of any value other
than 0, then the server MUST abort the connection with an than 0, then the server MUST abort the connection with an
illegal_parameter alert. Otherwise, the server uses the "illegal_parameter" alert. Otherwise, the server uses the
PaddedServerNameList.sni value as if it were the "server_name" PaddedServerNameList.sni value as if it were the "server_name"
extension. Any actual "server_name" extension is ignored, which also extension. Any actual "server_name" extension is ignored, which also
means the server MUST NOT send the "server_name" extension to the means the server MUST NOT send the "server_name" extension to the
client. client.
Upon determining the true SNI, the client-facing server then either Upon determining the true SNI, the client-facing server then either
serves the connection directly (if in Shared Mode), in which case it serves the connection directly (if in Shared Mode), in which case it
executes the steps in the following section, or forwards the TLS executes the steps in the following section, or forwards the TLS
connection to the backend server (if in Split Mode). In the latter connection to the backend server (if in Split Mode). In the latter
case, it does not make any changes to the TLS messages, but just case, it does not make any changes to the TLS messages, but just
blindly forwards them. blindly forwards them.
If the ClientHello is the result of a HelloRetryRequest, servers MUST
abort the connection with an "illegal_parameter" alert if any of the
ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share,
ClientEncryptedSNI.record_digest, or decrypted ClientESNIInner values
from the second ClientHello do not match that of the first
ClientHello.
5.3. Shared Mode Server Behavior 5.3. Shared Mode Server Behavior
A server operating in Shared Mode uses PaddedServerNameList.sni as if A server operating in Shared Mode uses PaddedServerNameList.sni as if
it were the "server_name" extension to finish the handshake. It it were the "server_name" extension to finish the handshake. It
SHOULD pad the Certificate message, via padding at the record layer, SHOULD pad the Certificate message, via padding at the record layer,
such that its length equals the size of the largest possible such that its length equals the size of the largest possible
Certificate (message) covered by the same ESNI key. Moreover, the Certificate (message) covered by the same ESNI key. Moreover, the
server MUST include the "encrypted_server_name" extension in server MUST include the "encrypted_server_name" extension in
EncryptedExtensions with the "response_type" field set to EncryptedExtensions with the "response_type" field set to
"esni_accept" and the "nonce" field set to the decrypted "esni_accept" and the "nonce" field set to the decrypted
PaddedServerNameList.nonce value from the client PaddedServerNameList.nonce value from the client
"encrypted_server_name" extension. "encrypted_server_name" extension.
If the server sends a NewSessionTicket message, the corresponding If the server sends a NewSessionTicket message, the corresponding
ESNI PSK MUST be ignored by all other servers in the deployment when ESNI PSK MUST be ignored by all other servers in the deployment when
not negotiating ESNI, including servers which do not implement this not negotiating ESNI, including servers which do not implement this
specification. This may be implemented by adding a new field to the specification.
server session state which earlier implementations cannot parse.
This restriction provides robustness for rollbacks (see Section 6.1). This restriction provides robustness for rollbacks (see Section 6.1).
5.4. Split Mode Server Behavior 5.4. Split Mode Server Behavior
In Split Mode, the backend server must know In Split Mode, the backend server must know
PaddedServerNameList.nonce to echo it back in EncryptedExtensions and PaddedServerNameList.nonce to echo it back in EncryptedExtensions and
complete the handshake. Appendix A describes one mechanism for complete the handshake. Appendix A describes one mechanism for
sending both PaddedServerNameList.sni and ClientESNIInner.nonce to sending both PaddedServerNameList.sni and ClientESNIInner.nonce to
the backend server. Thus, backend servers function the same as the backend server. Thus, backend servers function the same as
skipping to change at page 18, line 36 skipping to change at page 20, line 29
6.1. Misconfiguration and Deployment Concerns 6.1. Misconfiguration and Deployment Concerns
It is possible for ESNI advertisements and servers to become It is possible for ESNI advertisements and servers to become
inconsistent. This may occur, for instance, from DNS inconsistent. This may occur, for instance, from DNS
misconfiguration, caching issues, or an incomplete rollout in a misconfiguration, caching issues, or an incomplete rollout in a
multi-server deployment. This may also occur if a server loses its multi-server deployment. This may also occur if a server loses its
ESNI keys, or if a deployment of ESNI must be rolled back on the ESNI keys, or if a deployment of ESNI must be rolled back on the
server. server.
The retry mechanism repairs most such inconsistencies. If server and The retry mechanism repairs inconsistencies, provided the server is
advertised keys mismatch, the server will respond with authoritative for the public name. If server and advertised keys
esni_retry_requested. If the server does not understand the mismatch, the server will respond with esni_retry_requested. If the
"encrypted_server_name" extension at all, it will ignore it as server does not understand the "encrypted_server_name" extension at
required by [RFC8446]; Section 4.1.2. Provided the server can all, it will ignore it as required by [RFC8446]; Section 4.1.2.
present a certificate valid for the public name, the client can Provided the server can present a certificate valid for the public
safely retry with updated settings, as described in Section 5.1.2. name, the client can safely retry with updated settings, as described
in Section 5.1.2.
Unless ESNI is disabled as a result of successfully establishing a Unless ESNI is disabled as a result of successfully establishing a
connection to the public name, the client MUST NOT fall back to connection to the public name, the client MUST NOT fall back to
cleartext SNI, as this allows a network attacker to disclose the SNI. cleartext SNI, as this allows a network attacker to disclose the SNI.
It MAY attempt to use another server from the DNS results, if one is It MAY attempt to use another server from the DNS results, if one is
provided. provided.
6.2. Middleboxes 6.2. Middleboxes
A more serious problem is MITM proxies which do not support this A more serious problem is MITM proxies which do not support this
skipping to change at page 19, line 30 skipping to change at page 21, line 22
extension, substituting its own KeyShare value, will result in the extension, substituting its own KeyShare value, will result in the
client-facing server recognizing the key, but failing to decrypt the client-facing server recognizing the key, but failing to decrypt the
SNI. This causes a hard failure. Clients SHOULD NOT attempt to SNI. This causes a hard failure. Clients SHOULD NOT attempt to
repair the connection in this case. repair the connection in this case.
7. Security Considerations 7. Security Considerations
7.1. Why is cleartext DNS OK? 7.1. Why is cleartext DNS OK?
In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no Records are signed via a server private key, ESNI records have no
authenticity or provenance information. This means that any attacker authenticity or provenance information. This means that any attacker
which can inject DNS responses or poison DNS caches, which is a which can inject DNS responses or poison DNS caches, which is a
common scenario in client access networks, can supply clients with common scenario in client access networks, can supply clients with
fake ESNIKeys (so that the client encrypts SNI to them) or strip the fake ESNI records (so that the client encrypts SNI to them) or strip
ESNIKeys from the response. However, in the face of an attacker that the ESNI record from the response. However, in the face of an
controls DNS, no SNI encryption scheme can work because the attacker attacker that controls DNS, no SNI encryption scheme can work because
can replace the IP address, thus blocking client connections, or the attacker can replace the IP address, thus blocking client
substituting a unique IP address which is 1:1 with the DNS name that connections, or substituting a unique IP address which is 1:1 with
was looked up (modulo DNS wildcards). Thus, allowing the ESNIKeys in the DNS name that was looked up (modulo DNS wildcards). Thus,
the clear does not make the situation significantly worse. allowing the ESNI records in the clear does not make the situation
significantly worse.
Clearly, DNSSEC (if the client validates and hard fails) is a defense Clearly, DNSSEC (if the client validates and hard fails) is a defense
against this form of attack, but DoH/DPRIVE are also defenses against against this form of attack, but DoH/DPRIVE are also defenses against
DNS attacks by attackers on the local network, which is a common case DNS attacks by attackers on the local network, which is a common case
where SNI is desired. Moreover, as noted in the introduction, SNI where SNI is desired. Moreover, as noted in the introduction, SNI
encryption is less useful without encryption of DNS queries in encryption is less useful without encryption of DNS queries in
transit via DoH or DPRIVE mechanisms. transit via DoH or DPRIVE mechanisms.
7.2. Comparison Against Criteria 7.2. Optional Record Digests and Trial Decryption
Supporting optional record digests and trial decryption opens oneself
up to DoS attacks. Specifically, an adversary may send malicious
ClientHello messages, i.e., those which will not decrypt with any
known ESNI key, in order to force decryption. Servers that support
this feature should, for example, implement some form of rate
limiting mechanism to limit the damage caused by such attacks.
7.3. Encrypting other Extensions
ESNI protects only the SNI in transit. Other ClientHello extensions,
such as ALPN, might also reveal privacy-sensitive information to the
network. As such, it might be desirable to encrypt other extensions
alongside the SNI. However, the SNI extension is unique in that non-
TLS-terminating servers or load balancers may act on its contents.
Thus, using keys specifically for SNI encryption promotes key
separation between client-facing servers and endpoints party to TLS
connections. Moreover, the ESNI design described herein does not
preclude a mechanism for generic ClientHello extension encryption.
7.4. Related Privacy Leaks
ESNI requires encrypted DNS to be an effective privacy protection
mechanism. However, verifying the server's identity from the
Certificate message, particularly when using the X509
CertificateType, may result in additional network traffic that may
reveal the server identity. Examples of this traffic may include
requests for revocation information, such as OCSP or CRL traffic, or
requests for repository information, such as
authorityInformationAccess. It may also include implementation-
specific traffic for additional information sources as part of
verification.
Implementations SHOULD avoid leaking information that may identify
the server. Even when sent over an encrypted transport, such
requests may result in indirect exposure of the server's identity,
such as indicating a specific CA or service being used. To mitigate
this risk, servers SHOULD deliver such information in-band when
possible, such as through the use of OCSP stapling, and clients
SHOULD take steps to minimize or protect such requests during
certificate validation.
7.5. Comparison Against Criteria
[I-D.ietf-tls-sni-encryption] lists several requirements for SNI [I-D.ietf-tls-sni-encryption] lists several requirements for SNI
encryption. In this section, we re-iterate these requirements and encryption. In this section, we re-iterate these requirements and
assess the ESNI design against them. assess the ESNI design against them.
7.2.1. Mitigate against replay attacks 7.5.1. Mitigate against replay attacks
Since the SNI encryption key is derived from a (EC)DH operation Since the SNI encryption key is derived from a (EC)DH operation
between the client's ephemeral and server's semi-static ESNI key, the between the client's ephemeral and server's semi-static ESNI key, the
ESNI encryption is bound to the Client Hello. It is not possible for ESNI encryption is bound to the Client Hello. It is not possible for
an attacker to "cut and paste" the ESNI value in a different Client an attacker to "cut and paste" the ESNI value in a different Client
Hello, with a different ephemeral key share, as the terminating Hello, with a different ephemeral key share, as the terminating
server will fail to decrypt and verify the ESNI value. server will fail to decrypt and verify the ESNI value.
7.2.2. Avoid widely-deployed shared secrets 7.5.2. Avoid widely-deployed shared secrets
This design depends upon DNS as a vehicle for semi-static public key This design depends upon DNS as a vehicle for semi-static public key
distribution. Server operators may partition their private keys distribution. Server operators may partition their private keys
however they see fit provided each server behind an IP address has however they see fit provided each server behind an IP address has
the corresponding private key to decrypt a key. Thus, when one ESNI the corresponding private key to decrypt a key. Thus, when one ESNI
key is provided, sharing is optimally bound by the number of hosts key is provided, sharing is optimally bound by the number of hosts
that share an IP address. Server operators may further limit sharing that share an IP address. Server operators may further limit sharing
by sending different Resource Records containing ESNIKeys with by sending different Resource Records containing ESNIRecord and
different keys using a short TTL. ESNIKeys values with different keys using a short TTL.
7.2.3. Prevent SNI-based DoS attacks 7.5.3. Prevent SNI-based DoS attacks
This design requires servers to decrypt ClientHello messages with This design requires servers to decrypt ClientHello messages with
ClientEncryptedSNI extensions carrying valid digests. Thus, it is ClientEncryptedSNI extensions carrying valid digests. Thus, it is
possible for an attacker to force decryption operations on the possible for an attacker to force decryption operations on the
server. This attack is bound by the number of valid TCP connections server. This attack is bound by the number of valid TCP connections
an attacker can open. an attacker can open.
7.2.4. Do not stick out 7.5.4. Do not stick out
As more clients enable ESNI support, e.g., as normal part of Web As more clients enable ESNI support, e.g., as normal part of Web
browser functionality, with keys supplied by shared hosting browser functionality, with keys supplied by shared hosting
providers, the presence of ESNI extensions becomes less suspicious providers, the presence of ESNI extensions becomes less suspicious
and part of common or predictable client behavior. In other words, and part of common or predictable client behavior. In other words,
if all Web browsers start using ESNI, the presence of this value does if all Web browsers start using ESNI, the presence of this value does
not signal suspicious behavior to passive eavesdroppers. not signal suspicious behavior to passive eavesdroppers.
7.2.5. Forward secrecy Additionally, this specification allows for clients to send GREASE
ESNI extensions (see Section 5.1.4), which helps ensure the ecosystem
handles the values correctly.
7.5.5. Forward secrecy
This design is not forward secret because the server's ESNI key is This design is not forward secret because the server's ESNI key is
static. However, the window of exposure is bound by the key static. However, the window of exposure is bound by the key
lifetime. It is RECOMMENDED that servers rotate keys frequently. lifetime. It is RECOMMENDED that servers rotate keys frequently.
7.2.6. Proper security context 7.5.6. Proper security context
This design permits servers operating in Split Mode to forward This design permits servers operating in Split Mode to forward
connections directly to backend origin servers, thereby avoiding connections directly to backend origin servers, thereby avoiding
unnecessary MiTM attacks. unnecessary MiTM attacks.
7.2.7. Split server spoofing 7.5.7. Split server spoofing
Assuming ESNIKeys retrieved from DNS are validated, e.g., via DNSSEC Assuming ESNI records retrieved from DNS are validated, e.g., via
or fetched from a trusted Recursive Resolver, spoofing a server DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
operating in Split Mode is not possible. See Section 7.1 for more server operating in Split Mode is not possible. See Section 7.1 for
details regarding cleartext DNS. more details regarding cleartext DNS.
Validating the ESNIKeys structure additionally validates the public Validating the ESNIKeys structure additionally validates the public
name. This validates any retry signals from the server because the name. This validates any retry signals from the server because the
client validates the server certificate against the public name client validates the server certificate against the public name
before retrying. before retrying.
7.2.8. Supporting multiple protocols 7.5.8. Supporting multiple protocols
This design has no impact on application layer protocol negotiation. This design has no impact on application layer protocol negotiation.
It may affect connection routing, server certificate selection, and It may affect connection routing, server certificate selection, and
client certificate verification. Thus, it is compatible with client certificate verification. Thus, it is compatible with
multiple protocols. multiple protocols.
7.3. Misrouting 7.6. Misrouting
Note that the backend server has no way of knowing what the SNI was, Note that the backend server has no way of knowing what the SNI was,
but that does not lead to additional privacy exposure because the but that does not lead to additional privacy exposure because the
backend server also only has one identity. This does, however, backend server also only has one identity. This does, however,
change the situation slightly in that the backend server might change the situation slightly in that the backend server might
previously have checked SNI and now cannot (and an attacker can route previously have checked SNI and now cannot (and an attacker can route
a connection with an encrypted SNI to any backend server and the TLS a connection with an encrypted SNI to any backend server and the TLS
connection will still complete). However, the client is still connection will still complete). However, the client is still
responsible for verifying the server's identity in its certificate. responsible for verifying the server's identity in its certificate.
skipping to change at page 22, line 23 skipping to change at page 25, line 17
IANA is requested to create an entry, ESNI(0xff9f), in the existing IANA is requested to create an entry, ESNI(0xff9f), in the existing
registry for Resource Record (RR) TYPEs (defined in [RFC6895]) with registry for Resource Record (RR) TYPEs (defined in [RFC6895]) with
"Meaning" column value being set to "Encrypted SNI". "Meaning" column value being set to "Encrypted SNI".
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tls-exported-authenticator] [I-D.ietf-tls-exported-authenticator]
Sullivan, N., "Exported Authenticators in TLS", draft- Sullivan, N., "Exported Authenticators in TLS", draft-
ietf-tls-exported-authenticator-08 (work in progress), ietf-tls-exported-authenticator-09 (work in progress), May
October 2018. 2019.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 23, line 39 skipping to change at page 26, line 35
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-doh-dns-over-https] [I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-14 (work in (DoH)", draft-ietf-doh-dns-over-https-14 (work in
progress), August 2018. progress), August 2018.
[I-D.ietf-tls-grease]
Benjamin, D., "Applying GREASE to TLS Extensibility",
draft-ietf-tls-grease-02 (work in progress), January 2019.
[I-D.ietf-tls-sni-encryption] [I-D.ietf-tls-sni-encryption]
Huitema, C. and E. Rescorla, "Issues and Requirements for Huitema, C. and E. Rescorla, "Issues and Requirements for
SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04
(work in progress), November 2018. (work in progress), November 2018.
[I-D.kazuho-protected-sni] [I-D.kazuho-protected-sni]
Oku, K., "TLS Extensions for Protecting SNI", draft- Oku, K., "TLS Extensions for Protecting SNI", draft-
kazuho-protected-sni-00 (work in progress), July 2017. kazuho-protected-sni-00 (work in progress), July 2017.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
[SNIExtensibilityFailed]
"Accepting that other SNI name types will never work",
n.d., <https://mailarchive.ietf.org/arch/msg/
tls/1t79gzNItZd71DwwoaqcQQ_4Yxc>.
Appendix A. Communicating SNI and Nonce to Backend Server Appendix A. Communicating SNI and Nonce to Backend Server
When operating in Split Mode, backend servers will not have access to When operating in Split Mode, backend servers will not have access to
PaddedServerNameList.sni or ClientESNIInner.nonce without access to PaddedServerNameList.sni or ClientESNIInner.nonce without access to
the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni.
One way to address this for a single connection, at the cost of One way to address this for a single connection, at the cost of
having communication not be unmodified TLS 1.3, is as follows. having communication not be unmodified TLS 1.3, is as follows.
Assume there is a shared (symmetric) key between the client-facing Assume there is a shared (symmetric) key between the client-facing
server and the backend server and use it to AEAD-encrypt Z and send server and the backend server and use it to AEAD-encrypt Z and send
 End of changes. 71 change blocks. 
222 lines changed or deleted 365 lines changed or added

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