idnits 2.17.1 draft-ietf-httpbis-expect-ct-00.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 == Line 146 has weird spacing: '... Policy is a ...' == Line 152 has weird spacing: '...alified descr...' == Line 165 has weird spacing: '...CT Host is a ...' == Line 170 has weird spacing: '...CT Host is an...' == Line 177 has weird spacing: '...CT Host is an...' -- The document date (February 8, 2017) is 2605 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '4' on line 597 -- Looks like a reference, but probably isn't: '5' on line 597 -- Looks like a reference, but probably isn't: '1' on line 757 -- Looks like a reference, but probably isn't: '2' on line 759 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group E. Stark 3 Internet-Draft Google 4 Intended status: Experimental February 8, 2017 5 Expires: August 12, 2017 7 Expect-CT Extension for HTTP 8 draft-ietf-httpbis-expect-ct-00 10 Abstract 12 This document defines a new HTTP header, named Expect-CT, that allows 13 web host operators to instruct user agents to expect valid Signed 14 Certificate Timestamps (SCTs) to be served on connections to these 15 hosts. When configured in enforcement mode, user agents (UAs) will 16 remember that hosts expect SCTs and will refuse connections that do 17 not conform to the UA's Certificate Transparency policy. When 18 configured in report-only mode, UAs will report the lack of valid 19 SCTs to a URI configured by the host, but will allow the connection. 20 By turning on Expect-CT, web host operators can discover 21 misconfigurations in their Certificate Transparency deployments and 22 ensure that misissued certificates accepted by UAs are discoverable 23 in Certificate Transparency logs. 25 Note to Readers 27 Discussion of this draft takes place on the HTTP working group 28 mailing list (ietf-http-wg@w3.org), which is archived at 29 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 31 Working Group information can be found at http://httpwg.github.io/ ; 32 source code and issues list for this draft can be found at 33 https://github.com/httpwg/http-extensions/labels/expect-ct . 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 12, 2017. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 4 72 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 4 73 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 5 74 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6 75 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 6 76 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7 77 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7 78 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 7 79 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8 80 2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 8 81 2.3.2. Noting an Expect-CT Host - Storage Model . . . . . . 9 82 2.3.3. HTTP-Equiv Element Attribute . . . . . . . . . 10 83 2.4. Noting Expect-CT . . . . . . . . . . . . . . . . . . . . 10 84 2.5. Evaluating Expect-CT Connections for CT Compliance . . . 10 85 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11 86 3.1. Generating a violation report . . . . . . . . . . . . . . 11 87 3.2. Sending a violation report . . . . . . . . . . . . . . . 13 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14 90 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15 91 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 7. Usability Considerations . . . . . . . . . . . . . . . . . . 16 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 96 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 This document defines a new HTTP header that enables UAs to identify 103 web hosts that expect the presence of Signed Certificate Timestamps 104 (SCTs) [RFC6962] in future Transport Layer Security (TLS) [RFC5246] 105 connections. 107 Web hosts that serve the Expect-CT HTTP header are noted by the UA as 108 Known Expect-CT Hosts. The UA evaluates each connection to a Known 109 Expect-CT Host for compliance with the UA's Certificate Transparency 110 (CT) Policy. If the connection violates the CT Policy, the UA sends 111 a report to a URI configured by the Expect-CT Host and/or fails the 112 connection, depending on the configuration that the Expect-CT Host 113 has chosen. 115 If misconfigured, Expect-CT can cause unwanted connection failures 116 (for example, if a host deploys Expect-CT but then switches to a 117 legitimate certificate that is not logged in Certificate Transparency 118 logs, or if a web host operator believes their certificate to conform 119 to all UAs' CT policies but is mistaken). Web host operators are 120 advised to deploy Expect-CT with caution, by using the reporting 121 feature and gradually increasing the interval where the UA remembers 122 the host as a Known Expect-CT Host. These precautions can help web 123 host operators gain confidence that their Expect-CT deployment is not 124 causing unwanted connection failures. 126 Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a 127 UA connects to a host, it lacks the information necessary to require 128 SCTs for the connection. Thus, the UA will not be able to detect and 129 thwart an attack on the UA's first connection to the host. Still, 130 Expect-CT provides value by 1) allowing UAs to detect the use of 131 unlogged certificates after the initial communication, and 2) 132 allowing web hosts to be confident that UAs are only trusting 133 publicly-auditable certificates. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in RFC 140 2119 [RFC2119]. 142 1.2. Terminology 144 Terminology is defined in this section. 146 Certificate Transparency Policy is a policy defined by the UA 147 concerning the number, sources, and delivery mechanisms of Signed 148 Certificate Timestamps that are served on TLS connections. The 149 policy defines the properties of a connection that must be met in 150 order for the UA to consider it CT-qualified. 152 Certificate Transparency Qualified describes a TLS connection for 153 which the UA has determined that a sufficient quantity and quality 154 of Signed Certificate Timestamps have been provided. 156 CT-qualified See Certificate Transparency Qualified. 158 CT Policy See Certificate Transparency Policy. 160 Expect-CT Host See HTTP Expect-CT Host. 162 HTTP Expect-CT is the overall name for the combined UA- and server- 163 side security policy defined by this specification. 165 HTTP Expect-CT Host is a conformant host implementing the HTTP 166 server aspects of HTTP Expect-CT. This means that an Expect-CT 167 Host returns the "Expect-CT" HTTP response header field in its 168 HTTP response messages sent over secure transport. 170 Known Expect-CT Host is an Expect-CT Host that the UA has noted as 171 such. See Section 2.4 for particulars. 173 UA is an acronym for "user agent". For the purposes of this 174 specification, a UA is an HTTP client application typically 175 actively manipulated by a user [RFC2616]. 177 Unknown Expect-CT Host is an Expect-CT Host that the UA has not 178 noted. 180 2. Server and Client Behavior 182 2.1. Response Header Field Syntax 184 The "Expect-CT" header field is a new response header defined in this 185 specification. It is used by a server to indicate that UAs should 186 evaluate connections to the host emitting the header for CT 187 compliance (Section 2.5). 189 Figure 1 describes the syntax (Augmented Backus-Naur Form) of the 190 header field, using the grammar defined in RFC 5234 [RFC5234] and the 191 rules defined in Section 3.2 of RFC 7230 [RFC7230]. 193 Expect-CT-Directives = directive *( OWS ";" OWS directive ) 194 directive = directive-name [ "=" directive-value ] 195 directive-name = token 196 directive-value = token / quoted-string 198 Figure 1: Syntax of the Expect-CT header field 200 Optional white space ("OWS") is used as defined in Section 3.2.3 of 201 RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined 202 in Section 3.2.6 of RFC 7230 [RFC7230]. 204 The directives defined in this specification are described below. 205 The overall requirements for directives are: 207 1. The order of appearance of directives is not significant. 209 2. A given directive MUST NOT appear more than once in a given 210 header field. Directives are either optional or required, as 211 stipulated in their definitions. 213 3. Directive names are case insensitive. 215 4. UAs MUST ignore any header fields containing directives, or other 216 header field value data, that do not conform to the syntax 217 defined in this specification. In particular, UAs must not 218 attempt to fix malformed header fields. 220 5. If a header field contains any directive(s) the UA does not 221 recognize, the UA MUST ignore those directives. 223 6. If the Expect-CT header field otherwise satisfies the above 224 requirements (1 through 5), the UA MUST process the directives it 225 recognizes. 227 2.1.1. The report-uri Directive 229 The OPTIONAL "report-uri" directive indicates the URI to which the UA 230 SHOULD report Expect-CT failures (Section 2.5). The UA POSTs the 231 reports to the given URI as described in Section 3. 233 The "report-uri" directive is REQUIRED to have a directive value, for 234 which the syntax is defined in Figure 2. 236 report-uri-value = absolute-URI 238 Figure 2: Syntax of the report-uri directive value 240 "absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986]. 242 Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme in 243 the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check 244 Expect-CT compliance when the host in the "report-uri" is a Known 245 Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the 246 "report-uri" is a Known HSTS Host. 248 Note that the report-uri need not necessarily be in the same Internet 249 domain or web origin as the host being reported about. 251 UAs SHOULD make their best effort to report Expect-CT failures to the 252 "report-uri", but they may fail to report in exceptional conditions. 253 For example, if connecting the "report-uri" itself incurs an Expect- 254 CT failure or other certificate validation failure, the UA MUST 255 cancel the connection. Similarly, if Expect-CT Host A sets a 256 "report-uri" referring to Expect-CT Host B, and if B sets a "report- 257 uri" referring to A, and if both hosts fail to comply to the UA's CT 258 Policy, the UA SHOULD detect and break the loop by failing to send 259 reports to and about those hosts. 261 UAs SHOULD limit the rate at which they send reports. For example, 262 it is unnecessary to send the same report to the same "report-uri" 263 more than once. 265 2.1.2. The enforce Directive 267 The OPTIONAL "enforce" directive is a valueless directive that, if 268 present (i.e., it is "asserted"), signals to the UA that compliance 269 to the CT Policy should be enforced (rather than report-only) and 270 that the UA should refuse future connections that violate its CT 271 Policy. When both the "enforce" directive and "report-uri" directive 272 (as defined in Figure 2) are present, the configuration is referred 273 to as an "enforce-and-report" configuration, signalling to the UA 274 both that compliance to the CT Policy should be enforced and that 275 violations should be reported. 277 2.1.3. The max-age Directive 279 The "max-age" directive specifies the number of seconds after the 280 reception of the Expect-CT header field during which the UA SHOULD 281 regard the host from whom the message was received as a Known Expect- 282 CT Host. 284 The "max-age" directive is REQUIRED to be present within an "Expect- 285 CT" header field. The "max-age" directive is REQUIRED to have a 286 directive value, for which the syntax (after quoted-string 287 unescaping, if necessary) is defined in Figure 3. 289 max-age-value = delta-seconds 290 delta-seconds = 1*DIGIT 292 Figure 3: Syntax of the max-age directive value 294 "delta-seconds" is used as defined in Section 1.2.1 of RFC 7234 295 [RFC7234]. 297 2.2. Server Processing Model 299 This section describes the processing model that Expect-CT Hosts 300 implement. The model has 2 parts: (1) the processing rules for HTTP 301 request messages received over a secure transport (e.g., 302 authenticated, non-anonymous TLS); and (2) the processing rules for 303 HTTP request messages received over non-secure transports, such as 304 TCP. 306 2.2.1. HTTP-over-Secure-Transport Request Type 308 When replying to an HTTP request that was conveyed over a secure 309 transport, an Expect-CT Host SHOULD include in its response exactly 310 one Expect-CT header field. The header field MUST satisfy the 311 grammar specified in Section 2.1. 313 Establishing a given host as an Expect-CT Host, in the context of a 314 given UA, is accomplished as follows: 316 1. Over the HTTP protocol running over secure transport, by 317 correctly returning (per this specification) at least one valid 318 Expect-CT header field to the UA. 320 2. Through other mechanisms, such as a client-side preloaded Expect- 321 CT Host list. 323 2.2.2. HTTP Request Type 325 Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP 326 responses conveyed over non-secure transport. UAs MUST ignore any 327 Expect-CT header received in an HTTP response conveyed over non- 328 secure transport. 330 2.3. User Agent Processing Model 332 The UA processing model relies on parsing domain names. Note that 333 internationalized domain names SHALL be canonicalized according to 334 the scheme in Section 10 of [RFC6797]. 336 2.3.1. Expect-CT Header Field Processing 338 If the UA receives, over a secure transport, an HTTP response that 339 includes an Expect-CT header field conforming to the grammar 340 specified in Section 2.1, the UA MUST evaluate the connection on 341 which the header was received for compliance with the UA's CT Policy, 342 and then process the Expect-CT header field as follows. 344 If the connection complies with the UA's CT Policy (i.e. the 345 connection is CT-qualified), then the UA MUST either: 347 o Note the host as a Known Expect-CT Host if it is not already so 348 noted (see Section 2.4), or 350 o Update the UA's cached information for the Known Expect-CT Host if 351 the "enforce", "max-age", or "report-uri" header field value 352 directives convey information different from that already 353 maintained by the UA. If the "max-age" directive has a value of 354 0, the UA MUST remove its cached Expect-CT information if the host 355 was previously noted as a Known Expect-CT Host, and MUST NOT note 356 this host as a Known Expect-CT Host if it is not already noted. 358 If the connection does not comply with the UA's CT Policy (i.e. is 359 not CT-qualified), then the UA MUST NOT note this host as a Known 360 Expect-CT Host. 362 If the header field includes a "report-uri" directive, and the 363 connection does not comply with the UA's CT Policy (i.e. the 364 connection is not CT-qualified), and the UA has not already sent an 365 Expect-CT report for this connection, then the UA SHOULD send a 366 report to the specified "report-uri" as specified in Section 3. 368 If a UA receives more than one Expect-CT header field in an HTTP 369 response message over secure transport, then the UA MUST process only 370 the first Expect-CT header field. 372 The UA MUST ignore any Expect-CT header field not conforming to the 373 grammar specified in Section 2.1. 375 2.3.2. Noting an Expect-CT Host - Storage Model 377 The "effective Expect-CT date" of a Known Expect-CT Host is the time 378 that the UA observed a valid Expect-CT header for the host. The 379 "effective expiration date" of a Known Expect-CT Host is the 380 effective Expect-CT date plus the max-age. An Expect-CT Host is 381 "expired" if the effective expiration date refers to a date in the 382 past. The UA MUST ignore any expired Expect-CT Hosts in its cache. 384 Known Expect-CT Hosts are identified only by domain names, and never 385 IP addresses. If the substring matching the host production from the 386 Request-URI (of the message to which the host responded) 387 syntactically matches the IP-literal or IPv4address productions from 388 Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a 389 Known Expect-CT Host. 391 Otherwise, if the substring does not congruently match an existing 392 Known Expect-CT Host's domain name, per the matching procedure 393 specified in Section 8.2 of [RFC6797], then the UA MUST add this host 394 to the Known Expect-CT Host cache. The UA caches: 396 o the Expect-CT Host's domain name, 398 o whether the "enforce" directive is present 400 o the effective expiration date, or enough information to calculate 401 it (the effective Expect-CT date and the value of the "max-age" 402 directive), 404 o the value of the "report-uri" directive, if present. 406 If any other metadata from optional or future Expect-CT header 407 directives are present in the Expect-CT header, and the UA 408 understands them, the UA MAY note them as well. 410 UAs MAY set an upper limit on the value of max-age, so that UAs that 411 have noted erroneous Expect-CT hosts (whether by accident or due to 412 attack) have some chance of recovering over time. If the server sets 413 a max-age greater than the UA's upper limit, the UA MAY behave as if 414 the server set the max-age to the UA's upper limit. For example, if 415 the UA caps max-age at 5,184,000 seconds (60 days), and a Pinned Host 416 sets a max- age directive of 90 days in its Expect-CT header, the UA 417 MAY behave as if the max-age were effectively 60 days. (One way to 418 achieve this behavior is for the UA to simply store a value of 60 419 days instead of the 90-day value provided by the Expect-CT host.) 421 2.3.3. HTTP-Equiv Element Attribute 423 UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on 424 "" elements [W3C.REC-html401-19991224] in received content. 426 2.4. Noting Expect-CT 428 Upon receipt of the Expect-CT response header field, the UA notes the 429 host as a Known Expect-CT Host, storing the host's domain name and 430 its associated Expect-CT directives in non-volatile storage. The 431 domain name and associated Expect-CT directives are collectively 432 known as "Expect-CT metadata". 434 The UA MUST note a host as a Known Expect-CT Host if and only if it 435 received the Expect-CT response header field over an error-free TLS 436 connection, including the validation added in Section 2.5. 438 To note a host as a Known Expect-CT Host, the UA MUST set its Expect- 439 CT metadata given in the most recently received valid Expect-CT 440 header. 442 For forward compatibility, the UA MUST ignore any unrecognized 443 Expect-CT header directives, while still processing those directives 444 it does recognize. Section 2.1 specifies the directives "enforce", 445 "max-age", and "report-uri", but future specifications and 446 implementations might use additional directives. 448 2.5. Evaluating Expect-CT Connections for CT Compliance 450 When a UA connects to a Known Expect-CT Host using a TLS connection, 451 if the TLS connection has errors, the UA MUST terminate the 452 connection without allowing the user to proceed anyway. (This 453 behavior is the same as that required by [RFC6797].) 455 If the connection has no errors, then the UA will apply an additional 456 correctness check: compliance with a CT Policy. A UA should evaluate 457 compliance with its CT Policy whenever connecting to a Known Expect- 458 CT Host, as soon as possible. It is acceptable to skip this CT 459 compliance check for some hosts according to local policy. For 460 example, a UA may disable CT compliance checks for hosts whose 461 validated certificate chain terminates at a user-defined trust 462 anchor, rather than a trust anchor built-in to the UA (or underlying 463 platform). 465 If a connection to a Known CT Host violates the UA's CT policy (i.e. 466 the connection is not CT-qualified), and if the Known Expect-CT 467 Host's Expect-CT metadata indicates an "enforce" configuration, the 468 UA MUST treat the CT compliance failure as a non-recoverable error. 470 If a connection to a Known CT Host violates the UA's CT policy, and 471 if the Known Expect-CT Host's Expect-CT metadata includes a "report- 472 uri", the UA SHOULD send an Expect-CT report to that "report-uri" 473 (Section 3). 475 A UA that has previously noted a host as a Known Expect-CT Host MUST 476 evaluate CT compliance when setting up the TLS session, before 477 beginning an HTTP conversation over the TLS channel. 479 If the UA does not evaluate CT compliance, e.g. because the user has 480 elected to disable it, or because a presented certificate chain 481 chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect- 482 CT reports. 484 3. Reporting Expect-CT Failure 486 When the UA attempts to connect to a Known Expect-CT Host and the 487 connection is not CT-qualified, the UA SHOULD report Expect-CT 488 failures to the "report-uri", if any, in the Known Expect-CT Host's 489 Expect-CT metadata. 491 When the UA receives an Expect-CT response header field over a 492 connection that is not CT-qualified, if the UA has not already sent 493 an Expect-CT report for this connection, then the UA SHOULD report 494 Expect-CT failures to the configured "report-uri", if any. 496 3.1. Generating a violation report 498 To generate a violation report object, the UA constructs a JSON 499 message of the following form: 501 { 502 "date-time": date-time, 503 "hostname": hostname, 504 "port": port, 505 "effective-expiration-date": expiration-date, 506 "served-certificate-chain": [ (MUST be in the order served) 507 pem1, ... pemN 508 ], 509 "validated-certificate-chain": [ 510 pem1, ... pemN 511 ], 512 "scts": [ 513 sct1, ... sctN 514 ] 515 } 517 Figure 4: JSON format of a violation report object 519 Whitespace outside of quoted strings is not significant. The key/ 520 value pairs may appear in any order, but each MUST appear only once. 522 The "date-time" indicates the time the UA observed the CT compliance 523 failure. It is provided as a string formatted according to 524 Section 5.6, "Internet Date/Time Format", of [RFC3339]. 526 The "hostname" is the hostname to which the UA made the original 527 request that failed the CT compliance check. It is provided as a 528 string. 530 The "port" is the port to which the UA made the original request that 531 failed the CT compliance check. It is provided as an integer. 533 The "effective-expiration-date" is the Effective Expiration Date for 534 the Expect-CT Host that failed the CT compliance check. It is 535 provided as a string formatted according to Section 5.6, "Internet 536 Date/Time Format", of [RFC3339]. 538 The "served-certificate-chain" is the certificate chain, as served by 539 the Expect-CT Host during TLS session setup. It is provided as an 540 array of strings, which MUST appear in the order that the 541 certificates were served; each string "pem1", ... "pemN" is the 542 Privacy-Enhanced Mail (PEM) representation of each X.509 certificate 543 as described in [RFC7468]. 545 The "validated-certificate-chain" is the certificate chain, as 546 constructed by the UA during certificate chain verification. (This 547 may differ from the "served-certificate-chain".) It is provided as 548 an array of strings, which MUST appear in the order matching the 549 chain that the UA validated; each string "pem1", ... "pemN" is the 550 Privacy-Enhanced Mail (PEM) representation of each X.509 certificate 551 as described in [RFC7468]. 553 The "scts" are JSON messages representing the SCTs (if any) that the 554 UA received for the Expect-CT host and their validation statuses. 555 The format of "sct1", ... "sctN" is shown in Figure 5. The SCTs may 556 appear in any order. 558 { 559 "sct": sct, 560 "status": status, 561 "source": source 562 } 564 Figure 5: JSON format of an SCT object 566 The "sct" is as defined in Section 4.1 of RFC 6962 [RFC6962]. 568 The "status" is a string that the UA MUST set to one of the following 569 values: "unknown" (indicating that the UA does not have or does not 570 trust the public key of the log from which the SCT was issued), 571 "valid" (indicating that the UA successfully validated the SCT as 572 described in Section 5.2 of [RFC6962]), or "invalid" (indicating that 573 the SCT validation failed because of, e.g., a bad signature). 575 The "source" is a string that indicates from where the UA obtained 576 the SCT, as defined in Section 3.3 of [RFC6962]. The UA MUST set 577 "source" to one of the following values: "tls-extension", "ocsp", or 578 "embedded". 580 3.2. Sending a violation report 582 When an Expect-CT header field contains the "report-uri" directive, 583 and the connection does not comply with the UA's CT Policy, or when 584 the UA connects to a Known Expect-CT Host with Expect-CT metadata 585 that contains a "report-uri", the UA SHOULD report the failure as 586 follows: 588 1. Prepare a JSON object "report object" with the single key 589 "expect-ct-report", whose value is the result of generating a 590 violation report object as described in Figure 4. 592 2. Let "report body" by the JSON stringification of "report object". 594 3. Let "report-uri" be the value of the "report-uri" directive in 595 the Expect-CT header field. 597 4. Queue a task [4] to fetch [5] "report-uri", with the synchronous 598 flag not set, using HTTP method "POST", with a "Content-Type" 599 header field of "application/expect-ct-report", and an entity 600 body consisting of "report body". 602 4. Security Considerations 604 When UAs support the Expect-CT header, it becomes a potential vector 605 for hostile header attacks against site owners. If a site owner uses 606 a certificate issued by a certificate authority which does not embed 607 SCTs nor serve SCTs via OCSP or TLS extension, a malicious server 608 operator or attacker could temporarily reconfigure the host to comply 609 with the UA's CT policy, and add the Expect-CT header in enforcing 610 mode with a long "max-age". Implementing user agents would note this 611 as an Expect-CT Host (see Section 2.4). After having done this, the 612 configuration could then be reverted to not comply with the CT 613 policy, prompting failures. Note this scenario would require the 614 attacker to have substantial control over the infrastructure in 615 question, being able to obtain different certificates, change server 616 software, or act as a man-in-the-middle in connections. 618 Site operators could themselves only cure this situation by one of: 619 reconfiguring their web server to transmit SCTs using the TLS 620 extension defined in Section 3.3 of [RFC6962], obtaining a 621 certificate from an alternative certificate authority which provides 622 SCTs by one of the other methods, or by waiting for the user agents' 623 persisted notation of this as an Expect-CT host to reach its "max- 624 age". User agents may choose to implement mechanisms for users to 625 cure this situation, as noted in Section 7. 627 4.1. Maximum max-age 629 There is a security trade-off in that low maximum values provide a 630 narrow window of protection for users that visit the Known Expect-CT 631 Host only infrequently, while high maximum values might result in a 632 denial of service to a UA in the event of a hostile header attack, or 633 simply an error on the part of the site-owner. 635 There is probably no ideal maximum for the "max-age" directive. 636 Since Expect-CT is primarily a policy-expansion and investigation 637 technology rather than an end-user protection, a value on the order 638 of 30 days (2,592,000 seconds) may be considered a balance between 639 these competing security concerns. 641 4.2. Avoiding amplification attacks 643 Another kind of hostile header attack uses the "report-uri" mechanism 644 on many hosts not currently exposing SCTs as a method to cause a 645 denial-of-service to the host receiving the reports. If some highly- 646 trafficked websites emitted a non-enforcing Expect-CT header with a 647 "report-uri", implementing UAs' reports could flood the reporting 648 host. It is noted in Section 2.1.1 that UAs should limit the rate at 649 which they emit reports, but an attacker may alter the Expect-CT 650 header's fields to induce UAs to submit different reports to 651 different URIs to still cause the same effect. 653 5. Privacy Considerations 655 Expect-CT can be used to infer what Certificate Transparency policy 656 is in use, by attempting to retrieve specially-configured websites 657 which pass one user agents' policies but not another's. Note that 658 this consideration is true of UAs which enforce CT policies without 659 Expect-CT as well. 661 Additionally, reports submitted to the "report-uri" could reveal 662 information to a third party about which webpage is being accessed 663 and by which IP address, by using individual "report-uri" values for 664 individually-tracked pages. This information could be leaked even if 665 client-side scripting were disabled. 667 Implementations must store state about Known Expect-CT Hosts, and 668 hence which domains the UA has contacted. 670 Violation reports, as noted in Section 3, contain information about 671 the certificate chain that has violated the CT policy. In some 672 cases, such as organization-wide compromise of the end-to-end 673 security of TLS, this may include information about the interception 674 tools and design used by the organization that the organization would 675 otherwise prefer not be disclosed. 677 Because Expect-CT causes remotely-detectable behavior, it's advisable 678 that UAs offer a way for privacy-sensitive users to clear currently 679 noted Expect-CT hosts, and allow users to query the current state of 680 Known Expect-CT Hosts. 682 6. IANA Considerations 684 TBD 686 7. Usability Considerations 688 When the UA detects a Known Expect-CT Host in violation of the UA's 689 CT Policy, users will experience denials of service. It is advisable 690 for UAs to explain the reason why. 692 8. References 694 8.1. Normative References 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", BCP 14, RFC 2119, 698 DOI 10.17487/RFC2119, March 1997, 699 . 701 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 702 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 703 Transfer Protocol -- HTTP/1.1", RFC 2616, 704 DOI 10.17487/RFC2616, June 1999, 705 . 707 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 708 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 709 . 711 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 712 Resource Identifier (URI): Generic Syntax", STD 66, 713 RFC 3986, DOI 10.17487/RFC3986, January 2005, 714 . 716 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 717 Specifications: ABNF", STD 68, RFC 5234, 718 DOI 10.17487/RFC5234, January 2008, 719 . 721 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 722 (TLS) Protocol Version 1.2", RFC 5246, 723 DOI 10.17487/RFC5246, August 2008, 724 . 726 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 727 Transport Security (HSTS)", RFC 6797, 728 DOI 10.17487/RFC6797, November 2012, 729 . 731 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 732 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 733 . 735 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 736 Protocol (HTTP/1.1): Message Syntax and Routing", 737 RFC 7230, DOI 10.17487/RFC7230, June 2014, 738 . 740 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 741 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 742 RFC 7234, DOI 10.17487/RFC7234, June 2014, 743 . 745 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 746 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 747 April 2015, . 749 [W3C.REC-html401-19991224] 750 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 751 Specification", World Wide Web Consortium Recommendation 752 REC-html401-19991224, December 1999, 753 . 755 8.2. URIs 757 [1] https://html.spec.whatwg.org/#queue-a-task 759 [2] https://fetch.spec.whatwg.org/#fetching 761 Author's Address 763 Emily Stark 764 Google 766 Email: estark@google.com