idnits 2.17.1 draft-ietf-httpbis-http2-secondary-certs-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 2012 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 1048 -- Looks like a reference, but probably isn't: '2' on line 1050 -- Looks like a reference, but probably isn't: '3' on line 1052 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-07 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Bishop 3 Internet-Draft Akamai 4 Intended status: Standards Track N. Sullivan 5 Expires: April 26, 2019 Cloudflare 6 M. Thomson 7 Mozilla 8 October 23, 2018 10 Secondary Certificate Authentication in HTTP/2 11 draft-ietf-httpbis-http2-secondary-certs-03 13 Abstract 15 A use of TLS Exported Authenticators is described which enables 16 HTTP/2 clients and servers to offer additional certificate-based 17 credentials after the connection is established. The means by which 18 these credentials are used with requests is defined. 20 Note to Readers 22 Discussion of this draft takes place on the HTTP working group 23 mailing list (ietf-http-wg@w3.org), which is archived at 24 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 26 Working Group information can be found at http://httpwg.github.io/ 27 [2]; source code and issues list for this draft can be found at 28 https://github.com/httpwg/http-extensions/labels/secondary-certs [3]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 26, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Server Certificate Authentication . . . . . . . . . . . . 3 66 1.2. Client Certificate Authentication . . . . . . . . . . . . 4 67 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier . . . . . . . . . 5 68 1.2.2. HTTP/1.1 Using TLS 1.3 . . . . . . . . . . . . . . . 6 69 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7 71 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 72 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8 73 2.1. Indicating Support for HTTP-Layer Certificate 74 Authentication . . . . . . . . . . . . . . . . . . . . . 8 75 2.2. Making Certificates or Requests Available . . . . . . . . 9 76 2.3. Requiring Certificate Authentication . . . . . . . . . . 10 77 2.3.1. Requiring Additional Server Certificates . . . . . . 10 78 2.3.2. Requiring Additional Client Certificates . . . . . . 11 79 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 12 80 3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 12 81 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 14 82 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 15 83 3.3.1. Exported Authenticator Request Characteristics . . . 16 84 3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 16 85 3.4.1. Exported Authenticator Characteristics . . . . . . . 17 86 4. Indicating Failures During HTTP-Layer Certificate 87 Authentication . . . . . . . . . . . . . . . . . . . . . . . 18 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 89 5.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 19 90 5.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 19 91 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 19 92 5.4. Confusion About State . . . . . . . . . . . . . . . . . . 20 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 94 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 20 95 6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 21 96 6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 21 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 7.2. Informative References . . . . . . . . . . . . . . . . . 22 100 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 102 A.1. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 23 103 A.2. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 23 104 A.3. Since draft-bishop-httpbis-http2-additional-certs-05: . . 23 105 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 108 1. Introduction 110 HTTP clients need to know that the content they receive on a 111 connection comes from the origin that they intended to retrieve in 112 from. The traditional form of server authentication in HTTP has been 113 in the form of a single X.509 certificate provided during the TLS 114 ([RFC5246], [I-D.ietf-tls-tls13]) handshake. 116 Many existing HTTP [RFC7230] servers also have authentication 117 requirements for the resources they serve. Of the bountiful 118 authentication options available for authenticating HTTP requests, 119 client certificates present a unique challenge for resource-specific 120 authentication requirements because of the interaction with the 121 underlying TLS layer. 123 TLS 1.2 [RFC5246] supports one server and one client certificate on a 124 connection. These certificates may contain multiple identities, but 125 only one certificate may be provided. 127 Many HTTP servers host content from several origins. HTTP/2 permits 128 clients to reuse an existing HTTP connection to a server provided 129 that the secondary origin is also in the certificate provided during 130 the TLS handshake. In many cases, servers choose to maintain 131 separate certificates for different origins but still desire the 132 benefits of a shared HTTP connection. 134 1.1. Server Certificate Authentication 136 Section 9.1.1 of [RFC7540] describes how connections may be used to 137 make requests from multiple origins as long as the server is 138 authoritative for both. A server is considered authoritative for an 139 origin if DNS resolves the origin to the IP address of the server and 140 (for TLS) if the certificate presented by the server contains the 141 origin in the Subject Alternative Names field. 143 [RFC7838] enables a step of abstraction from the DNS resolution. If 144 both hosts have provided an Alternative Service at hostnames which 145 resolve to the IP address of the server, they are considered 146 authoritative just as if DNS resolved the origin itself to that 147 address. However, the server's one TLS certificate is still required 148 to contain the name of each origin in question. 150 [RFC8336] relaxes the requirement to perform the DNS lookup if 151 already connected to a server with an appropriate certificate which 152 claims support for a particular origin. 154 Servers which host many origins often would prefer to have separate 155 certificates for some sets of origins. This may be for ease of 156 certificate management (the ability to separately revoke or renew 157 them), due to different sources of certificates (a CDN acting on 158 behalf of multiple origins), or other factors which might drive this 159 administrative decision. Clients connecting to such origins cannot 160 currently reuse connections, even if both client and server would 161 prefer to do so. 163 Because the TLS SNI extension is exchanged in the clear, clients 164 might also prefer to retrieve certificates inside the encrypted 165 context. When this information is sensitive, it might be 166 advantageous to request a general-purpose certificate or anonymous 167 ciphersuite at the TLS layer, while acquiring the "real" certificate 168 in HTTP after the connection is established. 170 1.2. Client Certificate Authentication 172 For servers that wish to use client certificates to authenticate 173 users, they might request client authentication during or immediately 174 after the TLS handshake. However, if not all users or resources need 175 certificate-based authentication, a request for a certificate has the 176 unfortunate consequence of triggering the client to seek a 177 certificate, possibly requiring user interaction, network traffic, or 178 other time-consuming activities. During this time, the connection is 179 stalled in many implementations. Such a request can result in a poor 180 experience, particularly when sent to a client that does not expect 181 the request. 183 The TLS 1.3 CertificateRequest can be used by servers to give clients 184 hints about which certificate to offer. Servers that rely on 185 certificate-based authentication might request different certificates 186 for different resources. Such a server cannot use contextual 187 information about the resource to construct an appropriate TLS 188 CertificateRequest message during the initial handshake. 190 Consequently, client certificates are requested at connection 191 establishment time only in cases where all clients are expected or 192 required to have a single certificate that is used for all resources. 193 Many other uses for client certificates are reactive, that is, 194 certificates are requested in response to the client making a 195 request. 197 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier 199 In HTTP/1.1, a server that relies on client authentication for a 200 subset of users or resources does not request a certificate when the 201 connection is established. Instead, it only requests a client 202 certificate when a request is made to a resource that requires a 203 certificate. TLS 1.2 [RFC5246] accommodates this by permitting the 204 server to request a new TLS handshake, in which the server will 205 request the client's certificate. 207 Figure 1 shows the server initiating a TLS-layer renegotiation in 208 response to receiving an HTTP/1.1 request to a protected resource. 210 Client Server 211 -- (HTTP) GET /protected -------------------> *1 212 <---------------------- (TLS) HelloRequest -- *2 213 -- (TLS) ClientHello -----------------------> 214 <------------------ (TLS) ServerHello, ... -- 215 <---------------- (TLS) CertificateRequest -- *3 216 -- (TLS) ..., Certificate ------------------> *4 217 -- (TLS) Finished --------------------------> 218 <-------------------------- (TLS) Finished -- 219 <--------------------------- (HTTP) 200 OK -- *5 221 Figure 1: HTTP/1.1 reactive certificate authentication with TLS 1.2 223 In this example, the server receives a request for a protected 224 resource (at *1 on Figure 1). Upon performing an authorization 225 check, the server determines that the request requires authentication 226 using a client certificate and that no such certificate has been 227 provided. 229 The server initiates TLS renegotiation by sending a TLS HelloRequest 230 (at *2). The client then initiates a TLS handshake. Note that some 231 TLS messages are elided from the figure for the sake of brevity. 233 The critical messages for this example are the server requesting a 234 certificate with a TLS CertificateRequest (*3); this request might 235 use information about the request or resource. The client then 236 provides a certificate and proof of possession of the private key in 237 Certificate and CertificateVerify messages (*4). 239 When the handshake completes, the server performs any authorization 240 checks a second time. With the client certificate available, it then 241 authorizes the request and provides a response (*5). 243 1.2.2. HTTP/1.1 Using TLS 1.3 245 TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication 246 mechanism that allows for clients to authenticate after the handshake 247 has been completed. For the purposes of authenticating an HTTP 248 request, this is functionally equivalent to renegotiation. Figure 2 249 shows the simpler exchange this enables. 251 Client Server 252 -- (HTTP) GET /protected -------------------> 253 <---------------- (TLS) CertificateRequest -- 254 -- (TLS) Certificate, CertificateVerify, 255 Finished -----------------------> 256 <--------------------------- (HTTP) 200 OK -- 258 Figure 2: HTTP/1.1 reactive certificate authentication with TLS 1.3 260 TLS 1.3 does not support renegotiation, instead supporting direct 261 client authentication. In contrast to the TLS 1.2 example, in TLS 262 1.3, a server can simply request a certificate. 264 1.2.3. HTTP/2 266 An important part of the HTTP/1.1 exchange is that the client is able 267 to easily identify the request that caused the TLS renegotiation. 268 The client is able to assume that the next unanswered request on the 269 connection is responsible. The HTTP stack in the client is then able 270 to direct the certificate request to the application or component 271 that initiated that request. This ensures that the application has 272 the right contextual information for processing the request. 274 In HTTP/2, a client can have multiple outstanding requests. Without 275 some sort of correlation information, a client is unable to identify 276 which request caused the server to request a certificate. 278 Thus, the minimum necessary mechanism to support reactive certificate 279 authentication in HTTP/2 is an identifier that can be use to 280 correlate an HTTP request with a request for a certificate. Since 281 streams are used for individual requests, correlation with a stream 282 is sufficient. 284 [RFC7540] prohibits renegotiation after any application data has been 285 sent. This completely blocks reactive certificate authentication in 286 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 287 extension or update to HTTP/2, such an identifier could be added to 288 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 289 implementations do not permit application data to continue during a 290 renegotiation. This is problematic for a multiplexed protocol like 291 HTTP/2. 293 1.3. HTTP-Layer Certificate Authentication 295 This draft defines HTTP/2 frames to carry the relevant certificate 296 messages, enabling certificate-based authentication of both clients 297 and servers independent of TLS version. This mechanism can be 298 implemented at the HTTP layer without breaking the existing interface 299 between HTTP and applications above it. 301 This could be done in a naive manner by replicating the TLS messages 302 as HTTP/2 frames on each stream. However, this would create needless 303 redundancy between streams and require frequent expensive signing 304 operations. Instead, TLS Exported Authenticators 305 [I-D.ietf-tls-exported-authenticator] are exchanged on stream zero 306 and other frames incorporate them to particular requests by reference 307 as needed. 309 TLS Exported Authenticators are structured messages that can be 310 exported by either party of a TLS connection and validated by the 311 other party. Given an established TLS connection, a request can be 312 constructed which describes the desired certificate and an 313 authenticator message can be constructed proving possession of a 314 certificate and a corresponding private key. Both requests and 315 authenticators can be generated by either the client or the server. 316 Exported Authenticators use the message structures from Sections 317 4.3.2 and 4.4 of [I-D.ietf-tls-tls13], but different parameters. 319 Each Authenticator is computed using a Handshake Context and Finished 320 MAC Key derived from the TLS session. The Handshake Context is 321 identical for both parties of the TLS connection, while the Finished 322 MAC Key is dependent on whether the Authenticator is created by the 323 client or the server. 325 Successfully verified Authenticators result in certificate chains, 326 with verified possession of the corresponding private key, which can 327 be supplied into a collection of available certificates. Likewise, 328 descriptions of desired certificates can be supplied into these 329 collections. 331 Section 2 describes how the feature is employed, defining means to 332 detect support in peers (Section 2.1), make certificates and requests 333 available (Section 2.2), and indicate when streams are blocked 334 waiting on an appropriate certificate (Section 2.3). Section 3 335 defines the required frame types, which parallel the TLS 1.3 message 336 exchange. Finally, Section 4 defines new error types which can be 337 used to notify peers when the exchange has not been successful. 339 1.4. Terminology 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 343 "OPTIONAL" in this document are to be interpreted as described in BCP 344 14 [RFC2119] [RFC8174] when, and only when, they appear in all 345 capitals, as shown here. 347 2. Discovering Additional Certificates at the HTTP/2 Layer 349 A certificate chain with proof of possession of the private key 350 corresponding to the end-entity certificate is sent as a sequence of 351 "CERTIFICATE" frames (see Section 3.4) on stream zero. Once the 352 holder of a certificate has sent the chain and proof, this 353 certificate chain is cached by the recipient and available for future 354 use. Clients can proactively indicate the certificate they intend to 355 use on each request using an unsolicited "USE_CERTIFICATE" frame, if 356 desired. The previously-supplied certificates are available for 357 reference without having to resend them. 359 Otherwise, the server uses a "CERTIFICATE_REQUEST" frame to describe 360 a class of certificates on stream zero, then uses 361 "CERTIFICATE_NEEDED" frames to associate these with individual 362 requests. The client responds with a "USE_CERTIFICATE" frame 363 indicating the certificate which should be used to satisfy the 364 request. 366 Data sent by each peer is correlated by the ID given in each frame. 367 This ID is unrelated to values used by the other peer, even if each 368 uses the same ID in certain cases. "USE_CERTIFICATE" frames indicate 369 whether they are sent proactively or are in response to a 370 "CERTIFICATE_NEEDED" frame. 372 2.1. Indicating Support for HTTP-Layer Certificate Authentication 374 Clients and servers that will accept requests for HTTP-layer 375 certificate authentication indicate this using the HTTP/2 376 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 378 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 379 indicating that the peer does not support HTTP-layer certificate 380 authentication. If a peer does support HTTP-layer certificate 381 authentication, the value is non-zero. 383 In order to ensure that the TLS connection is direct to the server, 384 rather than via a TLS-terminating proxy, each side will separately 385 compute and confirm the value of this setting. The setting is 386 derived from a TLS exporter (see Section 7.5 of [I-D.ietf-tls-tls13] 387 and [RFC5705] for more details on exporters). Clients MUST NOT use 388 an early exporter during their 0-RTT flight, but MUST send an updated 389 SETTINGS frame using a regular exporter after the TLS handshake 390 completes. 392 The exporter is constructed with the following input: 394 o Label: 396 * "EXPORTER HTTP CERTIFICATE client" for clients 398 * "EXPORTER HTTP CERTIFICATE server" for servers 400 o Context: Empty 402 o Length: Four bytes 404 The resulting exporter is converted to a setting value as: 406 (Exporter & 0x3fffffff) | 0x80000000 408 That is, the most significant bit will always be set, regardless of 409 the value of the exporter. Each endpoint will compute the expected 410 value from their peer. If the setting is not received, or if the 411 value received is not the expected value, the frames defined in this 412 document SHOULD NOT be sent. 414 2.2. Making Certificates or Requests Available 416 When both peers have advertised support for HTTP-layer certificates 417 as in Section 2.1, either party can supply additional certificates 418 into the connection at any time. This means that clients or servers 419 which predict a certificate will be required could supply the 420 certificate before being asked. These certificates are available for 421 reference by future "USE_CERTIFICATE" frames. 423 Certificates supplied by servers can be considered by clients without 424 further action by the server. A server SHOULD NOT send certificates 425 which do not cover origins which it is prepared to service on the 426 current connection, but MAY use the ORIGIN frame [RFC8336] to 427 indicate that not all covered origins will be served. 429 Client Server 430 <------------------ (stream 0) CERTIFICATE -- 431 ... 432 -- (stream N) GET /from-new-origin ---------> 433 <----------------------- (stream N) 200 OK -- 435 Figure 3: Proactive server authentication 437 Client Server 438 -- (stream 0) CERTIFICATE ------------------> 439 -- (stream 0) USE_CERTIFICATE (S=1) --------> 440 -- (stream 0) USE_CERTIFICATE (S=3) --------> 441 -- (streams 1,3) GET /protected ------------> 442 <-------------------- (streams 1,3) 200 OK -- 444 Figure 4: Proactive client authentication 446 Likewise, either party can supply a "CERTIFICATE_REQUEST" that 447 outlines parameters of a certificate they might request in the 448 future. Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD 449 provide a corresponding certificate in anticipation of a request 450 shortly being blocked. Clients MAY wait for a "CERTIFICATE_NEEDED" 451 frame to assist in associating the certificate request with a 452 particular HTTP transaction. 454 2.3. Requiring Certificate Authentication 456 2.3.1. Requiring Additional Server Certificates 458 As defined in [RFC7540], when a client finds that a https:// origin 459 (or Alternative Service [RFC7838]) to which it needs to make a 460 request has the same IP address as a server to which it is already 461 connected, it MAY check whether the TLS certificate provided contains 462 the new origin as well, and if so, reuse the connection. 464 If the TLS certificate does not contain the new origin, but the 465 server has claimed support for that origin (with an ORIGIN frame, see 466 [RFC8336]) and advertised support for HTTP-layer certificates (see 467 Section 2.1), the client MAY send a "CERTIFICATE_REQUEST" frame 468 describing the desired origin. The client then sends a 469 "CERTIFICATE_NEEDED" frame for stream zero referencing the request, 470 indicating that the connection cannot be used for that origin until 471 the certificate is provided. 473 If the server does not have the desired certificate, it MUST send an 474 Empty Authenticator, as described in Section 5 of 476 [I-D.ietf-tls-exported-authenticator], in a "CERTIFICATE" frame in 477 response to the request, followed by a "USE_CERTIFICATE" frame for 478 stream zero which references the Empty Authenticator. In this case, 479 or if the server has not advertised support for HTTP-layer 480 certificates, the client MUST NOT send any requests for resources in 481 that origin on the current connection. 483 Client Server 484 <----------------------- (stream 0) ORIGIN -- 485 -- (stream 0) CERTIFICATE_REQUEST ----------> 486 -- (stream 0) CERTIFICATE_NEEDED (S=0) -----> 487 <------------------ (stream 0) CERTIFICATE -- 488 <-------- (stream 0) USE_CERTIFICATE (S=0) -- 489 -- (stream N) GET /from-new-origin ---------> 490 <----------------------- (stream N) 200 OK -- 492 Figure 5: Client-requested certificate 494 If a client receives a "PUSH_PROMISE" referencing an origin for which 495 it has not yet received the server's certificate, this is a fatal 496 connection error (see section 8.2 of [RFC7540]). To avoid this, 497 servers MUST supply the associated certificates before pushing 498 resources from a different origin. 500 2.3.2. Requiring Additional Client Certificates 502 Likewise, the server sends a "CERTIFICATE_NEEDED" frame for each 503 stream where certificate authentication is required. The client 504 answers with a "USE_CERTIFICATE" frame indicating the certificate to 505 use on that stream. If the request parameters or the responding 506 certificate are not already available, they will need to be sent as 507 described in Section 2.2 as part of this exchange. 509 Client Server 510 <---------- (stream 0) CERTIFICATE_REQUEST -- 511 ... 512 -- (stream N) GET /protected ---------------> 513 <----- (stream 0) CERTIFICATE_NEEDED (S=N) -- 514 -- (stream 0) CERTIFICATE ------------------> 515 -- (stream 0) USE_CERTIFICATE (S=N) --------> 516 <----------------------- (stream N) 200 OK -- 518 Figure 6: Reactive certificate authentication 520 If the client does not have the desired certificate, it instead sends 521 an Empty Authenticator, as described in Section 5 of 522 [I-D.ietf-tls-exported-authenticator], in a "CERTIFICATE" frame in 523 response to the request, followed by a "USE_CERTIFICATE" frame which 524 references the Empty Authenticator. In this case, or if the client 525 has not advertised support for HTTP-layer certificates, the server 526 processes the request based solely on the certificate provided during 527 the TLS handshake, if any. This might result in an error response 528 via HTTP, such as a status code 403 (Not Authorized). 530 3. Certificates Frames for HTTP/2 532 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 533 correlated by their "Request-ID" field. Subsequent 534 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 535 sent for other streams where the sender is expecting a certificate 536 with the same parameters. 538 The "CERTIFICATE", and "USE_CERTIFICATE" frames are correlated by 539 their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with the 540 same "Cert-ID" MAY be sent in response to other "CERTIFICATE_NEEDED" 541 frames and refer to the same certificate. 543 "CERTIFICATE_NEEDED" and "USE_CERTIFICATE" frames are correlated by 544 the Stream ID they reference. Unsolicited "USE_CERTIFICATE" frames 545 are not responses to "CERTIFICATE_NEEDED" frames; otherwise, each 546 "USE_CERTIFICATE" frame for a stream is considered to respond to a 547 "CERTIFICATE_NEEDED" frame for the same stream in sequence. 549 +---------+ +---------+ 550 | REQUEST | | CERT | 551 +---------+ +---------+ 552 | | 553 | Request-ID | Cert-ID 554 | | 555 v v 556 +---------+ Stream ID +---------+ 557 | NEEDED |---------->| USE | 558 +---------+ +---------+ 560 Figure 7: Frame correlation 562 "Request-ID" and "Cert-ID" are independent and sender-local. The use 563 of the same value by the other peer or in the other context does not 564 imply any correlation between these frames. These values MUST be 565 unique per sender for each space over the lifetime of the connection. 567 3.1. The CERTIFICATE_NEEDED Frame 569 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD1) is sent on stream zero 570 to indicate that the HTTP request on the indicated stream is blocked 571 pending certificate authentication. The frame includes stream ID and 572 a request identifier which can be used to correlate the stream with a 573 previous "CERTIFICATE_REQUEST" frame sent on stream zero. The 574 "CERTIFICATE_REQUEST" describes the certificate the sender requires 575 to make progress on the stream in question. 577 0 1 2 3 578 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 579 +---------------------------------------------------------------+ 580 |R| Stream ID (31) | 581 +-------------------------------+-------------------------------+ 582 | Request-ID (16) | 583 +-------------------------------+ 585 Figure 8: CERTIFICATE_NEEDED frame payload 587 The "CERTIFICATE_NEEDED" frame contains 6 octets. The first four 588 octets indicate the Stream ID of the affected stream. The following 589 two octets are the authentication request identifier, "Request-ID". 590 A peer that receives a "CERTIFICATE_NEEDED" of any other length MUST 591 treat this as a stream error of type "PROTOCOL_ERROR". Frames with 592 identical request identifiers refer to the same 593 "CERTIFICATE_REQUEST". 595 A server MAY send multiple "CERTIFICATE_NEEDED" frames for the same 596 stream. If a server requires that a client provide multiple 597 certificates before authorizing a single request, each required 598 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 599 frame, each of which MUST have a different request identifier 600 (referencing different "CERTIFICATE_REQUEST" frames describing each 601 required certificate). To reduce the risk of client confusion, 602 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 603 frames for the same stream at any given time. 605 Clients MUST only send multiple "CERTIFICATE_NEEDED" frames for 606 stream zero. Multiple "CERTIFICATE_NEEDED" frames on any other 607 stream MUST be considered a stream error of type "PROTOCOL_ERROR". 609 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has 610 not advertised support for HTTP-layer certificate authentication. 612 The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the 613 "half-closed (local)" or "closed" states [RFC7540]. A client that 614 receives a "CERTIFICATE_NEEDED" frame for a stream which is not in a 615 valid state SHOULD treat this as a stream error of type 616 "PROTOCOL_ERROR". 618 3.2. The USE_CERTIFICATE Frame 620 The "USE_CERTIFICATE" frame (0xFRAME-TBD4) is sent on stream zero to 621 indicate which certificate is being used on a particular request 622 stream. 624 The "USE_CERTIFICATE" frame defines a single flag: 626 UNSOLICITED (0x01): Indicates that no "CERTIFICATE_NEEDED" frame has 627 yet been received for this stream. 629 The payload of the "USE_CERTIFICATE" frame is as follows: 631 0 1 2 3 632 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 633 +---------------------------------------------------------------+ 634 |R| Stream ID (31) | 635 +-------------------------------+-------------------------------+ 636 | [Cert-ID (16)] | 637 +-------------------------------+ 639 Figure 9: USE_CERTIFICATE frame payload 641 The first four octets indicate the Stream ID of the affected stream. 642 The following two octets, if present, contain the two-octet "Cert-ID" 643 of the certificate the sender wishes to use. This MUST be the ID of 644 a certificate for which proof of possession has been presented in a 645 "CERTIFICATE" frame. Recipients of a "USE_CERTIFICATE" frame of any 646 other length MUST treat this as a stream error of type 647 "PROTOCOL_ERROR". Frames with identical certificate identifiers 648 refer to the same certificate chain. 650 A "USE_CERTIFICATE" frame which omits the Cert-ID refers to the 651 certificate provided at the TLS layer, if any. If no certificate was 652 provided at the TLS layer, the stream should be processed with no 653 authentication, likely returning an authentication-related error at 654 the HTTP level (e.g. 403) for servers or routing the request to a new 655 connection for clients. 657 The "UNSOLICITED" flag MAY be set by clients on the first 658 "USE_CERTIFICATE" frame referring to a given stream. This permits a 659 client to proactively indicate which certificate should be used when 660 processing a new request. When such an unsolicited indication refers 661 to a request that has not yet been received, servers SHOULD cache the 662 indication briefly in anticipation of the request. 664 Receipt of more than one unsolicited "USE_CERTIFICATE" frames or an 665 unsolicited "USE_CERTIFICATE" frame which is not the first in 666 reference to a given stream MUST be treated as a stream error of type 667 "CERTIFICATE_OVERUSED". 669 Each "USE_CERTIFICATE" frame which is not marked as unsolicited is 670 considered to respond in order to the "CERTIFICATE_NEEDED" frames for 671 the same stream. If a "USE_CERTIFICATE" frame is received for which 672 a "CERTIFICATE_NEEDED" frame has not been sent, this MUST be treated 673 as a stream error of type "CERTIFICATE_OVERUSED". 675 Receipt of a "USE_CERTIFICATE" frame with an unknown "Cert-ID" MUST 676 result in a stream error of type "PROTOCOL_ERROR". 678 The referenced certificate chain needs to conform to the requirements 679 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 680 ability, or the recipient is likely to reject it as unsuitable 681 despite properly validating the authenticator. If the recipient 682 considers the certificate unsuitable, it MAY at its discretion either 683 return an error at the HTTP semantic layer, or respond with a stream 684 error [RFC7540] on any stream where the certificate is used. 685 Section 4 defines certificate-related error codes which might be 686 applicable. 688 3.3. The CERTIFICATE_REQUEST Frame 690 The "CERTIFICATE_REQUEST" frame (id=0xFRAME-TBD2) provides a exported 691 authenticator request message from the TLS layer that specifies a 692 desired certificate. This describes the certificate the sender 693 wishes to have presented. 695 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 696 has not advertised support for HTTP-layer certificate authentication. 698 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 699 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 700 rejected with a stream error of type "PROTOCOL_ERROR". 702 0 1 2 3 703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 704 +-------------------------------+-------------------------------+ 705 | Request-ID (16) | Request (?) ... 706 +---------------------------------------------------------------+ 708 Figure 10: CERTIFICATE_REQUEST frame payload 710 The frame contains the following fields: 712 Request-ID: "Request-ID" is a 16-bit opaque identifier used to 713 correlate subsequent certificate-related frames with this request. 714 The identifier MUST be unique in the session for the sender. 716 Request: An exported authenticator request, generated using the 717 "request" API described in [I-D.ietf-tls-exported-authenticator]. 718 See Section 3.4.1 for more details on the input to this API. 720 3.3.1. Exported Authenticator Request Characteristics 722 The Exported Authenticator "request" API defined in 723 [I-D.ietf-tls-exported-authenticator] takes as input a set of desired 724 certificate characteristics and a "certificate_request_context", 725 which needs to be unpredictable. When generating exported 726 authenticators for use with this extension, the 727 "certificate_request_context" MUST contain both the two-octet 728 Request-ID as well as at least 96 bits of additional entropy. 730 The TLS library on the authenticating peer will provide mechanisms to 731 select an appropriate certificate to respond to the transported 732 request. TLS libraries on servers MUST be able to recognize the 733 "server_name" extension ([RFC6066]) at a minimum. Clients MUST 734 always specify the desired origin using this extension, though other 735 extensions MAY also be included. 737 3.4. The CERTIFICATE Frame 739 The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides a exported 740 authenticator message from the TLS layer that provides a chain of 741 certificates, associated extensions and proves possession of the 742 private key corresponding to the end-entity certificate. 744 The "CERTIFICATE" frame defines two flags: 746 TO_BE_CONTINUED (0x01): Indicates that the exported authenticator 747 spans more than one frame. 749 0 1 2 3 750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 751 +-------------------------------+-------------------------------+ 752 | Cert-ID (16) | Authenticator Fragment (*)... 753 +---------------------------------------------------------------+ 755 Figure 11: CERTIFICATE frame payload 757 The frame contains the following fields: 759 Cert-ID: "Cert-ID" is a 16-bit opaque identifier used to correlate 760 other certificate- related frames with this exported authenticator 761 fragment. 763 Authenticator Fragment: A portion of the opaque data returned from 764 the TLS connection exported authenticator "authenticate" API. See 765 Section 3.4.1 for more details on the input to this API. 767 An exported authenticator is transported in zero or more 768 "CERTIFICATE" frames with the "TO_BE_CONTINUED" flag set, followed by 769 one "CERTIFICATE" frame with the "TO_BE_CONTINUED" flag unset. Each 770 of these frames contains the same "Cert-ID" field, permitting them to 771 be associated with each other. Receipt of any "CERTIFICATE" frame 772 with the same "Cert-ID" following the receipt of a "CERTIFICATE" 773 frame with "TO_BE_CONTINUED" unset MUST be treated as a connection 774 error of type "PROTOCOL_ERROR". 776 Upon receiving a complete series of "CERTIFICATE" frames, the 777 receiver may validate the Exported Authenticator value by using the 778 exported authenticator API. This returns either an error indicating 779 that the message was invalid, or the certificate chain and extensions 780 used to create the message. 782 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 783 frame received on any other stream MUST be rejected with a stream 784 error of type "PROTOCOL_ERROR". 786 3.4.1. Exported Authenticator Characteristics 788 The Exported Authenticator API defined in 789 [I-D.ietf-tls-exported-authenticator] takes as input a request, a set 790 of certificates, and supporting information about the certificate 791 (OCSP, SCT, etc.). The result is an opaque token which is used when 792 generating the "CERTIFICATE" frame. 794 Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the 795 following steps to validate the token it contains: 797 o Using the "get context" API, retrieve the 798 "certificate_request_context" used to generate the authenticator, 799 if any. 801 o Verify that the "certificate_request_context" is either empty 802 (clients only) or contains the Request-ID of a previously-sent 803 "CERTIFICATE_REQUEST" frame. 805 o Use the "validate" API to confirm the validity of the 806 authenticator with regard to the generated request (if any). 808 Once the authenticator is accepted, the endpoint can perform any 809 other checks for the acceptability of the certificate itself. 811 4. Indicating Failures During HTTP-Layer Certificate Authentication 813 Because this draft permits certificates to be exchanged at the HTTP 814 framing layer instead of the TLS layer, several certificate-related 815 errors which are defined at the TLS layer might now occur at the HTTP 816 framing layer. In this section, those errors are restated and added 817 to the HTTP/2 error code registry. 819 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 820 signatures that did not verify correctly, etc. 822 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 823 unsupported type or did not contain required extensions 825 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 826 signer 828 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 829 not currently valid 831 CERTIFICATE_GENERAL (0xERROR-TBD5): Any other certificate-related 832 error 834 CERTIFICATE_OVERUSED (0xERROR-TBD6): More certificates were used on 835 a request than were requested 837 As described in [RFC7540], implementations MAY choose to treat a 838 stream error as a connection error at any time. Of particular note, 839 a stream error cannot occur on stream 0, which means that 840 implementations cannot send non-session errors in response to 841 "CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations 842 which do not wish to terminate the connection MAY either send 843 relevant errors on any stream which references the failing 844 certificate in question or process the requests as unauthenticated 845 and provide error information at the HTTP semantic layer. 847 5. Security Considerations 849 This mechanism defines an alternate way to obtain server and client 850 certificates other than in the initial TLS handshake. While the 851 signature of exported authenticator values is expected to be equally 852 secure, it is important to recognize that a vulnerability in this 853 code path is at least equal to a vulnerability in the TLS handshake. 855 5.1. Impersonation 857 This mechanism could increase the impact of a key compromise. Rather 858 than needing to subvert DNS or IP routing in order to use a 859 compromised certificate, a malicious server now only needs a client 860 to connect to _some_ HTTPS site under its control in order to present 861 the compromised certificate. As recommended in [RFC8336], clients 862 opting not to consult DNS ought to employ some alternative means to 863 increase confidence that the certificate is legitimate. 865 As noted in the Security Considerations of 866 [I-D.ietf-tls-exported-authenticator], it difficult to formally prove 867 that an endpoint is jointly authoritative over multiple certificates, 868 rather than individually authoritative on each certificate. As a 869 result, clients MUST NOT assume that because one origin was 870 previously collocated with another, those origins will be reachable 871 via the same endpoints in the future. Clients MUST NOT consider 872 previous secondary certificates to be validated after TLS session 873 resumption. However, clients MAY proactively query for previously- 874 presented secondary certificates. 876 5.2. Fingerprinting 878 This draft defines a mechanism which could be used to probe servers 879 for origins they support, but opens no new attack versus making 880 repeat TLS connections with different SNI values. Servers SHOULD 881 impose similar denial-of-service mitigations (e.g. request rate 882 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 884 While the extensions in the "CERTIFICATE_REQUEST" frame permit the 885 sender to enumerate the acceptable Certificate Authorities for the 886 requested certificate, it might not be prudent (either for security 887 or data consumption) to include the full list of trusted Certificate 888 Authorities in every request. Senders, particularly clients, SHOULD 889 send only the extensions that narrowly specify which certificates 890 would be acceptable. 892 5.3. Denial of Service 894 Failure to provide a certificate on a stream after receiving 895 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 896 standard timeouts used to guard against unresponsive peers. 898 Validating a multitude of signatures can be computationally 899 expensive, while generating an invalid signature is computationally 900 cheap. Implementations will require checks for attacks from this 901 direction. Invalid exported authenticators SHOULD be treated as a 902 session error, to avoid further attacks from the peer, though an 903 implementation MAY instead disable HTTP-layer certificates for the 904 current connection instead. 906 5.4. Confusion About State 908 Implementations need to be aware of the potential for confusion about 909 the state of a connection. The presence or absence of a validated 910 certificate can change during the processing of a request, 911 potentially multiple times, as "USE_CERTIFICATE" frames are received. 912 A server that uses certificate authentication needs to be prepared to 913 reevaluate the authorization state of a request as the set of 914 certificates changes. 916 Client implementations need to carefully consider the impact of 917 setting the "AUTOMATIC_USE" flag. This flag is a performance 918 optimization, permitting the client to avoid a round-trip on each 919 request where the server checks for certificate authentication. 920 However, once this flag has been sent, the client has zero knowledge 921 about whether the server will use the referenced cert for any future 922 request, or even for an existing request which has not yet completed. 923 Clients MUST NOT set this flag on any certificate which is not 924 appropriate for currently-in-flight requests, and MUST NOT make any 925 future requests on the same connection which they are not willing to 926 have associated with the provided certificate. 928 6. IANA Considerations 930 This draft adds entries in three registries. 932 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 933 Section 6.1. Four frame types are registered in Section 6.2. Six 934 error codes are registered in Section 6.3. 936 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 938 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 939 Settings" registry established in [RFC7540]. 941 Name: SETTINGS_HTTP_CERT_AUTH 943 Code: 0xSETTING-TBD 945 Initial Value: 0 947 Specification: This document. 949 6.2. New HTTP/2 Frames 951 Four new frame types are registered in the "HTTP/2 Frame Types" 952 registry established in [RFC7540]. The entries in the following 953 table are registered by this document. 955 +---------------------+--------------+---------------+ 956 | Frame Type | Code | Specification | 957 +---------------------+--------------+---------------+ 958 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | 959 | | | | 960 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | 961 | | | | 962 | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | 963 | | | | 964 | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | 965 +---------------------+--------------+---------------+ 967 6.3. New HTTP/2 Error Codes 969 Six new error codes are registered in the "HTTP/2 Error Code" 970 registry established in [RFC7540]. The entries in the following 971 table are registered by this document. 973 +-------------------------+--------------+---------------+ 974 | Name | Code | Specification | 975 +-------------------------+--------------+---------------+ 976 | BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 | 977 | | | | 978 | UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | Section 4 | 979 | | | | 980 | CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 | 981 | | | | 982 | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 | 983 | | | | 984 | CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 | 985 | | | | 986 | CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 | 987 +-------------------------+--------------+---------------+ 989 7. References 991 7.1. Normative References 993 [I-D.ietf-tls-exported-authenticator] 994 Sullivan, N., "Exported Authenticators in TLS", draft- 995 ietf-tls-exported-authenticator-07 (work in progress), 996 June 2018. 998 [I-D.ietf-tls-tls13] 999 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1000 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1001 March 2018. 1003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1004 Requirement Levels", BCP 14, RFC 2119, 1005 DOI 10.17487/RFC2119, March 1997, 1006 . 1008 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1009 (TLS) Protocol Version 1.2", RFC 5246, 1010 DOI 10.17487/RFC5246, August 2008, 1011 . 1013 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1014 Extensions: Extension Definitions", RFC 6066, 1015 DOI 10.17487/RFC6066, January 2011, 1016 . 1018 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1019 Protocol (HTTP/1.1): Message Syntax and Routing", 1020 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1021 . 1023 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1024 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1025 DOI 10.17487/RFC7540, May 2015, 1026 . 1028 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1029 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1030 May 2017, . 1032 7.2. Informative References 1034 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1035 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1036 March 2010, . 1038 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1039 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1040 April 2016, . 1042 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 1043 RFC 8336, DOI 10.17487/RFC8336, March 2018, 1044 . 1046 7.3. URIs 1048 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1050 [2] http://httpwg.github.io/ 1052 [3] https://github.com/httpwg/http-extensions/labels/secondary-certs 1054 Appendix A. Change Log 1056 *RFC Editor's Note:* Please remove this section prior to 1057 publication of a final version of this document. 1059 A.1. Since draft-ietf-httpbis-http2-secondary-certs-01: 1061 o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than 1062 speculatively reserving a stream for an origin. 1064 o Use SETTINGS to disable when a TLS-terminating proxy is present 1065 (#617,#651) 1067 A.2. Since draft-ietf-httpbis-http2-secondary-certs-00: 1069 o All frames sent on stream zero; replaced "AUTOMATIC_USE" on 1070 "CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566) 1072 o Use Exported Requests from the TLS Exported Authenticators draft; 1073 eliminate facilities for expressing certificate requirements in 1074 "CERTIFICATE_REQUEST" frame. (#481) 1076 A.3. Since draft-bishop-httpbis-http2-additional-certs-05: 1078 o Adopted as draft-ietf-httpbis-http2-secondary-certs 1080 Acknowledgements 1082 Eric Rescorla pointed out several failings in an earlier revision. 1083 Andrei Popov contributed to the TLS considerations. 1085 A substantial portion of Mike's work on this draft was supported by 1086 Microsoft during his employment there. 1088 Authors' Addresses 1090 Mike Bishop 1091 Akamai 1093 Email: mbishop@evequefou.be 1094 Nick Sullivan 1095 Cloudflare 1097 Email: nick@cloudflare.com 1099 Martin Thomson 1100 Mozilla 1102 Email: martin.thomson@gmail.com