idnits 2.17.1 draft-bishop-httpbis-sni-altsvc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2018) is 2299 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 275 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Obsolete normative reference: RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-02 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis M. Bishop 3 Internet-Draft Akamai 4 Intended status: Standards Track January 9, 2018 5 Expires: July 13, 2018 7 The "SNI" Alt-Svc Parameter 8 draft-bishop-httpbis-sni-altsvc-01 10 Abstract 12 HTTP Alternative Services provides a mechanism for an origin to 13 declare that its content is accessible via some other combination of 14 host, port, and protocol. In the process of using such an 15 alternative, an observer can identify that the client is requesting 16 resources from a particular hostname. 18 This document extends HTTP Alternative Services, in combination with 19 Secondary Certificate Authentication, to enable clients not to 20 disclose the origin to which they intend to connect. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 13, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 59 2. The "sni" Alt-Svc Extension . . . . . . . . . . . . . . . . . 3 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 5.2. Informative References . . . . . . . . . . . . . . . . . 6 65 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 Confidentiality and authentication during communication are primary 72 goals of using TLS to secure traffic on the Internet. However, due 73 to the nature of TLS, certain information is inherently not 74 confidential - notably, the hostname and the corresponding 75 certificate of the origin to which the client is connecting are 76 transferred unencrypted in the Server Name Indication extension [SNI] 77 and the server's Certificate message [TLS12]. 79 While the client identity can be obscured by using TLS renegotiation 80 immediately after the handshake (in TLS 1.2) or by using TLS 1.3 81 [TLS13], the server is not afforded such privacy considerations. 83 Servers may also have wildcard certificates which do not enumerate 84 specific subdomains, but clients will disclose the first subdomain 85 used on a connection via the SNI extension when establishing the 86 connection. 88 [SNIEncryption] discusses a potential solution to these issues in 89 Section 3, HTTP Co-Tenancy Fronting, but notes both discoverability 90 and server authentication issues with that approach. This document 91 provides a mechanism to address both limitations. 93 1.1. Usage 95 In [AltSvc], once a client has received a validated Alternative 96 Service record for an origin, it "SHOULD use that alternative service 97 for all requests to the associated origin as soon as it is available, 98 provided the alternative service information is fresh (Section 2.2) 99 and the security properties of the alternative service protocol are 100 desirable, as compared to the existing connection." However, the 101 client "MUST have reasonable assurances that the alternative service 102 is under control of and valid for the whole origin ... established 103 through use of a TLS-based protocol with the certificate checks 104 defined in [RFC2818]." This causes the origin to be disclosed in the 105 SNI extension while connecting to the alternative, and the origin's 106 certificate to be returned by the alternative, creating the same 107 privacy issues as connecting directly to the origin. 109 The extension described in Section 2 enables an origin to declare 110 that reasonable assurances should be obtained, not by requesting the 111 desired hostname in the TLS handshake, but by requesting it via 112 [SecondaryCerts]. The validation checks from [RFC2818] are applied 113 to this certificate. 115 Because the entire exchange happens inside TLS, a passive observer 116 cannot identify the hostname(s) the client might be requesting. 118 1.2. Notational Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER", 127 "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", 128 "COULD", "POSSIBLE", and "MIGHT" in this document are to be 129 interpreted as described in [RFC6919]. 131 Field definitions are given in Augmented Backus-Naur Form (ABNF), as 132 defined in [RFC5234]. 134 2. The "sni" Alt-Svc Extension 136 When an origin wishes to nominate a "fronting server", it includes 137 the "sni" parameter in its alternative service entry. 139 Syntax: 141 sni = host 143 "host" is defined in Section 3.2.2 of [RFC3986]. 145 When processing such an alternative, clients SHOULD present the 146 hostname given in the "sni" parameter in the SNI extension during the 147 TLS handshake. If the resulting certificate is also for the origin 148 which published the alternative service, the client MUST validate the 149 certificate in the handshake for authenticity according to [RFC2818]. 151 Otherwise, the client MAY choose not to validate the certificate, but 152 MUST NOT make requests to any origin corresponding to this 153 certificate unless the certificate has been successfully validated. 154 In this case, the client SHOULD send a "CERTIFICATE_REQUEST" frame 155 including an SNI extension indicating the origin which published the 156 alternative service immediately upon connecting. If no corresponding 157 "CERTIFICATE" frame is presented by the server after a reasonable 158 timeout, or if the server's SETTINGS frame does not include the 159 "SETTINGS_HTTP_CERT_AUTH" setting, the client MUST consider the 160 alternative connection to have failed. 162 3. Security Considerations 164 [AltSvc] permits clients to ignore unrecognized parameters. As a 165 result, servers publishing records with the "sni" parameter cannot be 166 assured that clients will not include their origin in the SNI header 167 when connecting to the nominated alternative. If, for security 168 reasons, an origin wishes its identity never to be disclosed when the 169 alternative is being used, an alternative mechanism would be required 170 to ascertain client support before generating the Alt-Svc record. 172 Clients will need to connect directly to the origin at least once in 173 order to receive the Alt-Svc entry via an HTTP header or "ALTSVC" 174 frame, thus disclosing their use of the origin to the network on the 175 first connection. This could be mitigated by future work defining a 176 way to publish alternative services in a mechanism which can be 177 retrieved confidentially, such as via DNS in combination with 178 [RFC7858] or [DoH]. 180 However, servers which publish Alt-Svc records over unencrypted 181 channels (HTTP connections without TLS) or channels without client 182 authorization (DNS, or publicly accessible HTTP resources) enable 183 active observers to build a map of fronting servers by collecting 184 Alt-Svc advertisements. Servers SHOULD CONSIDER this trade-off in 185 deciding when and how to make Alt-Svc records available to 186 unauthenticated parties. 188 4. IANA Considerations 190 The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" 191 defines the name space for parameters, as described in [AltSvc]. It 192 is maintained at http://www.iana.org/assignments/http-alt-svc- 193 parameters [1]. 195 This document registers the following parameter: 197 Name: "sni" 199 Specification: This document 201 5. References 203 5.1. Normative References 205 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 206 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 207 April 2016, . 209 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 210 Requirement Levels", BCP 14, RFC 2119, 211 DOI 10.17487/RFC2119, March 1997, 212 . 214 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 215 DOI 10.17487/RFC2818, May 2000, 216 . 218 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 219 Resource Identifier (URI): Generic Syntax", STD 66, 220 RFC 3986, DOI 10.17487/RFC3986, January 2005, 221 . 223 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 224 Specifications: ABNF", STD 68, RFC 5234, 225 DOI 10.17487/RFC5234, January 2008, 226 . 228 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 229 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 230 DOI 10.17487/RFC6919, April 2013, 231 . 233 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 234 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 235 May 2017, . 237 [SecondaryCerts] 238 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 239 Certificate Authentication in HTTP/2", draft-bishop- 240 httpbis-http2-additional-certs-05 (work in progress), 241 October 2017. 243 [SNI] Eastlake 3rd, D., "Transport Layer Security (TLS) 244 Extensions: Extension Definitions", RFC 6066, 245 DOI 10.17487/RFC6066, January 2011, 246 . 248 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 249 (TLS) Protocol Version 1.2", RFC 5246, 250 DOI 10.17487/RFC5246, August 2008, 251 . 253 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 254 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 255 January 2018. 257 5.2. Informative References 259 [DoH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 260 draft-ietf-doh-dns-over-https-02 (work in progress), 261 November 2017. 263 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 264 and P. Hoffman, "Specification for DNS over Transport 265 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 266 2016, . 268 [SNIEncryption] 269 Huitema, C. and E. Rescorla, "SNI Encryption in TLS 270 Through Tunneling", draft-ietf-tls-sni-encryption-00 (work 271 in progress), August 2017. 273 5.3. URIs 275 [1] http://www.iana.org/assignments/http-alt-svc-parameters 277 Appendix A. Acknowledgements 279 Conversations with Benjamin Schwartz helped to flesh out this idea. 281 Author's Address 283 Mike Bishop 284 Akamai 286 Email: mbishop@evequefou.be