The "SNI" Alt-Svc ParameterAkamaimbishop@evequefou.be
Applications
HTTPbisInternet-DraftHTTP Alternative Services provides a mechanism for an origin to declare that its
content is accessible via some other combination of host, port, and protocol.
In the process of using such an alternative, an observer can identify that the
client is requesting resources from a particular hostname.This document extends HTTP Alternative Services, in combination with Secondary
Certificate Authentication, to enable clients not to disclose the origin to
which they intend to connect.Confidentiality and authentication during communication are primary goals of
using TLS to secure traffic on the Internet. However, due to the nature of TLS,
certain information is inherently not confidential – notably, the hostname and
the corresponding certificate of the origin to which the client is connecting
are transferred unencrypted in the Server Name Indication extension
and the server’s Certificate message .While the client identity can be obscured by using TLS renegotiation immediately
after the handshake (in TLS 1.2) or by using TLS 1.3
, the server is not afforded such privacy
considerations.Servers may also have wildcard certificates which do not enumerate specific
subdomains, but clients will disclose the first subdomain used on a connection
via the SNI extension when establishing the connection. discusses a potential solution to
these issues in Section 3, HTTP Co-Tenancy Fronting, but notes both
discoverability and server authentication issues with that approach. This
document provides a mechanism to address both limitations.In , once a client has received a validated Alternative
Service record for an origin, it “SHOULD use that alternative service for all
requests to the associated origin as soon as it is available, provided the
alternative service information is fresh (Section 2.2) and the security
properties of the alternative service protocol are desirable, as compared to the
existing connection.” However, the client “MUST have reasonable assurances that
the alternative service is under control of and valid for the whole origin …
established through use of a TLS-based protocol with the certificate checks
defined in .” This causes the origin to be disclosed in the SNI
extension while connecting to the alternative, and the origin’s certificate to
be returned by the alternative, creating the same privacy issues as connecting
directly to the origin.The extension described in enables an origin to declare that
reasonable assurances should be obtained, not by requesting the desired hostname
in the TLS handshake, but by requesting it via
. The validation
checks from are applied to this certificate.Because the entire exchange happens inside TLS, a passive observer cannot
identify the hostname(s) the client might be requesting.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.The key words “MUST (BUT WE KNOW YOU WON’T)”, “SHOULD CONSIDER”, “REALLY SHOULD
NOT”, “OUGHT TO”, “WOULD PROBABLY”, “MAY WISH TO”, “COULD”, “POSSIBLE”, and
“MIGHT” in this document are to be interpreted as described in .Field definitions are given in Augmented Backus-Naur Form (ABNF), as defined in
.When an origin wishes to nominate a “fronting server”, it includes the sni
parameter in its alternative service entry.Syntax:host is defined in Section 3.2.2 of .When processing such an alternative, clients SHOULD present the hostname given
in the sni parameter in the SNI extension during the TLS handshake.
If the resulting certificate is also for the origin which published the
alternative service, the client MUST validate the certificate in the handshake
for authenticity according to .Otherwise, the client MAY choose not to validate the certificate, but MUST NOT
make requests to any origin corresponding to this certificate unless the
certificate has been successfully validated. In this case, the client SHOULD
send a CERTIFICATE_REQUEST frame including an SNI extension indicating the
origin which published the alternative service immediately upon connecting. If
no corresponding CERTIFICATE frame is presented by the server after a
reasonable timeout, or if the server’s SETTINGS frame does not include the
SETTINGS_HTTP_CERT_AUTH setting, the client MUST consider the alternative
connection to have failed. permits clients to ignore unrecognized parameters. As a result,
servers publishing records with the sni parameter cannot be assured that
clients will not include their origin in the SNI header when connecting to the
nominated alternative. If, for security reasons, an origin wishes its identity
never to be disclosed when the alternative is being used, an alternative
mechanism would be required to ascertain client support before generating the
Alt-Svc record.Clients will need to connect directly to the origin at least once in order to
receive the Alt-Svc entry via an HTTP header or ALTSVC frame, thus disclosing
their use of the origin to the network on the first connection. This could be
mitigated by future work defining a way to publish alternative services in a
mechanism which can be retrieved confidentially, such as via DNS in combination
with or .However, servers which publish Alt-Svc records over unencrypted channels (HTTP
connections without TLS) or channels without client authorization (DNS, or
publicly accessible HTTP resources) enable active observers to build a map of
fronting servers by collecting Alt-Svc advertisements. Servers SHOULD CONSIDER
this trade-off in deciding when and how to make Alt-Svc records available to
unauthenticated parties.The “Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry” defines the
name space for parameters, as described in . It is maintained at
http://www.iana.org/assignments/http-alt-svc-parameters.This document registers the following parameter:sni
This documentTransport Layer Security (TLS) Extensions: Extension DefinitionsThis document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.2This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.HTTP Alternative ServicesThis document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.HTTP Over TLSThis memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.Secondary Certificate Authentication in HTTP/2TLS provides fundamental mutual authentication services for HTTP, supporting up to one server certificate and up to one client certificate associated to the session to prove client and server identities as necessary. This draft provides mechanisms for providing additional such certificates at the HTTP layer when these constraints are not sufficient. Many HTTP servers host content from several origins. HTTP/2 [RFC7540] permits clients to reuse an existing HTTP connection to a server provided that the secondary origin is also in the certificate provided during the TLS [I-D.ietf-tls-tls13] handshake. In many cases, servers will wish to maintain separate certificates for different origins but still desire the benefits of a shared HTTP connection. Similarly, servers may require clients to present authentication, but have different requirements based on the content the client is attempting to access. This document describes how TLS exported authenticators [I-D.ietf-tls-exported-authenticator] can be used to provide proof of ownership of additional certificates to the HTTP layer to support both scenarios.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Further Key Words for Use in RFCs to Indicate Requirement LevelsRFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Uniform Resource Identifier (URI): Generic SyntaxA Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]SNI Encryption in TLS Through TunnelingThis draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft starts by listing known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and then presents two potential TLS layer solutions that might mitigate these attacks. The first solution is based on TLS in TLS "quasi tunneling", and the second solution is based on "combined tickets". These solutions only require minimal extensions to the TLS protocol.Specification for DNS over Transport Layer Security (TLS)This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.DNS Queries over HTTPSDNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. [[ There is a repository for this draft at https://github.com/dohwg/ draft-ietf-doh-dns-over-https ]].Conversations with Benjamin Schwartz helped to flesh out this idea.