Internet DRAFT - draft-bishop-httpbis-sni-altsvc
draft-bishop-httpbis-sni-altsvc
HTTPbis M. Bishop
Internet-Draft Akamai
Intended status: Standards Track May 24, 2018
Expires: November 25, 2018
The "SNI" Alt-Svc Parameter
draft-bishop-httpbis-sni-altsvc-02
Abstract
HTTP 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Bishop Expires November 25, 2018 [Page 1]
Internet-Draft SNI Alt-Svc May 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. The "sni" Alt-Svc Extension . . . . . . . . . . . . . . . . . 3
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SNI of Colocated Domain . . . . . . . . . . . . . . . . . 4
3.2. Wildcard Subdomains . . . . . . . . . . . . . . . . . . . 5
3.3. Omitting SNI . . . . . . . . . . . . . . . . . . . . . . 5
3.4. SNI of Unrelated Domain . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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 [SNI]
and the server's Certificate message [TLS12].
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
[TLS13], 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.
[SNIEncryption] 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.
Bishop Expires November 25, 2018 [Page 2]
Internet-Draft SNI Alt-Svc May 2018
1.1. Usage
In [AltSvc], 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 [RFC2818]." 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 Section 2 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
[SecondaryCerts]. The validation checks from [RFC2818] 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.
1.2. Notational Conventions
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 [RFC2119] [RFC8174] 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 [RFC6919].
Field definitions are given in Augmented Backus-Naur Form (ABNF), as
defined in [RFC5234].
2. The "sni" Alt-Svc Extension
When an origin wishes to nominate a "fronting server", it includes
the "sni" parameter in its alternative service entry.
Syntax:
Bishop Expires November 25, 2018 [Page 3]
Internet-Draft SNI Alt-Svc May 2018
sni = ( reg-name / empty-string )
empty-string = DQUOTE DQUOTE
"reg-name" is defined in Section 3.2.2 of [RFC3986].
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 hostname given is an empty string, clients
SHOULD omit the SNI extension from the TLS handshake. The server
MUST return a valid certificate which covers at least one of the
following:
o The hostname indicated in the SNI extension
o The hostname of the origin that published the alternative
o The hostname used for connecting to the alternative
The client MUST validate the certificate in the handshake for
authenticity according to [RFC2818] and ensure that it is valid for
at least one of these names. Clients SHOULD NOT accept certificates
issued to the IP address of the alternative unless the alternative is
specified as an IP literal.
If the certificate is not valid for the origin's hostname, the client
MUST NOT make requests to any origin corresponding to this
certificate. 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.
3. Examples
3.1. SNI of Colocated Domain
Suppose a client has received the following Alt-Svc entry for
sensitive.example.com in the past:
h2="innocence.org:443";ma=2635200;persist=true;sni=innocence.org
If the client now wishes to make a request to
https://sensitive.example.com/private, it would perform a DNS
resolution for innocence.org. The client would then open a TCP
connection to the resulting IP address and begin a TLS handshake.
Bishop Expires November 25, 2018 [Page 4]
Internet-Draft SNI Alt-Svc May 2018
In the client's TLS handshake, it would request a certificate for the
hostname "innocence.org". The TLS server would present such a
certificate, issued by an authority trusted by the client. The
client will validate the certificate for the name
"sensitive.example.com". When validation fails, the client will try
to validate the certificate for the name "innocence.org", which will
succeed. After validation succeeds, the client will send a
"CERTIFICATE_REQUEST" frame asking that the server also authenticate
with a certificate for sensitive.example.com.
After receiving the "CERTIFICATE" frame proving possession of a
certificate for sensitive.example.com, the client will verify that
this certificate is trusted. If so, the client will proceed to send
HTTP/2 requests to the server requesting the resource
https://sensitive.example.com/private.
3.2. Wildcard Subdomains
Suppose a client has received the following Alt-Svc entry for
sensitive.example.com in the past:
h2="www.example.com:443";ma=2635200;persist=true;sni=www.example.com
If the client now wishes to make a request to
https://sensitive.example.com/private, it would perform a DNS
resolution for www.example.com, the specified alternative. The
client would then open a TCP connection to the resulting IP address
and begin a TLS handshake.
In the client's TLS handshake, it would request a certificate for the
hostname www.example.com. The TLS server would present a certificate
which included www.example.com as one of the covered hostnames.
Suppose that the certificate with which the server authenticated also
contained a Subject Alternative Name of "*.example.com". Because the
certificate covers the desired origin, the client would perform
validity checks on this certificate.
If the certificate is trusted, the client will proceed to send HTTP/2
requests to the server requesting the resource
https://sensitive.example.com/private.
3.3. Omitting SNI
Suppose a client has received the following Alt-Svc entry for
sensitive.example.com in the past:
h2="alternative.example.com:443";ma=2635200;persist=true;sni=""
Bishop Expires November 25, 2018 [Page 5]
Internet-Draft SNI Alt-Svc May 2018
If the client now wishes to make a request to
https://sensitive.example.com/private, it would perform a DNS
resolution for alternative.example.com, the specified alternative.
The client would then open a TCP connection to the resulting IP
address and begin a TLS handshake.
In the client's TLS handshake, it would omit the Server Name
Indication extension. The TLS server would present a certificate
according to its configured defaults.
The server would supply a certificate that covers
sensitive.example.com, for example because it contains a Subject
Alternative Name of "*.example.com", and the client would perform
validity checks on this certificate.
If the supplied certificate does not cover sensitive.example.com, or
is not valid, the client will terminate the connection.
3.4. SNI of Unrelated Domain
Suppose a client has received the following Alt-Svc entry for
sensitive.example.com in the past:
h2=":443";ma=2635200;persist=true;sni=other.example
If the client now wishes to make a request to
https://sensitive.example.com/private, it would perform a DNS
resolution for sensitive.example.com (the Alt-Svc entry does not
specify a different hostname). The client would then open a TCP
connection to the resulting IP address and begin a TLS handshake.
In the client's TLS handshake, it would request a certificate for the
hostname "other.example". The TLS server does not a have a
certificate for this hostname, but it would return a certificate for
sensitive.example.com, issued by an authority trusted by the client,
and the client will successfully validate the certificate for the
name "sensitive.example.com".
Note that an active attacker could identify this server by sending a
Client Hello with the same SNI value and observing the certificate
the server uses to authenticate. The server could mitigate this by
authenticating with a certificate for other.example.
4. Security Considerations
[AltSvc] 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
Bishop Expires November 25, 2018 [Page 6]
Internet-Draft SNI Alt-Svc May 2018
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
[RFC7858] or [DoH].
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.
While concealing information from passive observers is beneficial,
low-effort active attacks still exist. If an attacker can collect
the actual server identity by sending a Client Hello with the same
SNI value, the usefulness of this technique is limited. Server
deployments SHOULD reserve sensitive domains for use with Secondary
Certificates or conceal them inside wildcards in order to mitigate
this.
5. IANA Considerations
The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry"
defines the name space for parameters, as described in [AltSvc]. It
is maintained at http://www.iana.org/assignments/http-alt-svc-
parameters [1].
This document registers the following parameter:
Name: "sni"
Specification: This document
6. References
Bishop Expires November 25, 2018 [Page 7]
Internet-Draft SNI Alt-Svc May 2018
6.1. Normative References
[AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
for Use in RFCs to Indicate Requirement Levels", RFC 6919,
DOI 10.17487/RFC6919, April 2013,
<https://www.rfc-editor.org/info/rfc6919>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SecondaryCerts]
Bishop, M., Sullivan, N., and M. Thomson, "Secondary
Certificate Authentication in HTTP/2", draft-bishop-
httpbis-http2-additional-certs-05 (work in progress),
October 2017.
[SNI] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
Bishop Expires November 25, 2018 [Page 8]
Internet-Draft SNI Alt-Svc May 2018
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
6.2. Informative References
[DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DOH)", draft-ietf-doh-dns-over-https-08 (work in
progress), May 2018.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[SNIEncryption]
Huitema, C. and E. Rescorla, "Issues and Requirements for
SNI Encryption in TLS", draft-ietf-tls-sni-encryption-03
(work in progress), May 2018.
6.3. URIs
[1] http://www.iana.org/assignments/http-alt-svc-parameters
Appendix A. Acknowledgements
Conversations with Benjamin Schwartz helped to flesh out this idea.
Author's Address
Mike Bishop
Akamai
Email: mbishop@evequefou.be
Bishop Expires November 25, 2018 [Page 9]
