idnits 2.17.1 draft-ietf-httpbis-expect-ct-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 149 has weird spacing: '... Policy is a ...' == Line 155 has weird spacing: '...alified descr...' == Line 163 has weird spacing: '...CT Date is th...' == Line 171 has weird spacing: '...CT Host is a ...' == Line 176 has weird spacing: '...CT Host is an...' == (1 more instance...) -- The document date (May 24, 2017) is 2529 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'HTML' is defined on line 721, but no explicit reference was found in the text == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-24 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). 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 May 24, 2017 5 Expires: November 25, 2017 7 Expect-CT Extension for HTTP 8 draft-ietf-httpbis-expect-ct-01 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 November 25, 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 . . . . . . . . . . . . . . . . 7 76 2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 7 77 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7 78 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7 79 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8 80 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8 81 2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 8 82 2.3.2. HTTP-Equiv Element Attribute . . . . . . . . . 9 83 2.3.3. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9 84 2.3.4. Storage Model . . . . . . . . . . . . . . . . . . . . 9 85 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10 86 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11 87 3.1. Generating a violation report . . . . . . . . . . . . . . 11 88 3.2. Sending a violation report . . . . . . . . . . . . . . . 13 89 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14 91 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 14 92 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 94 7. Usability Considerations . . . . . . . . . . . . . . . . . . 15 95 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 15 96 8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 15 98 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 9.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 15 100 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 This document defines a new HTTP header that enables UAs to identify 106 web hosts that expect the presence of Signed Certificate Timestamps 107 (SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer 108 Security (TLS) [RFC5246] connections. 110 Web hosts that serve the Expect-CT HTTP header are noted by the UA as 111 Known Expect-CT Hosts. The UA evaluates each connection to a Known 112 Expect-CT Host for compliance with the UA's Certificate Transparency 113 (CT) Policy. If the connection violates the CT Policy, the UA sends 114 a report to a URI configured by the Expect-CT Host and/or fails the 115 connection, depending on the configuration that the Expect-CT Host 116 has chosen. 118 If misconfigured, Expect-CT can cause unwanted connection failures 119 (for example, if a host deploys Expect-CT but then switches to a 120 legitimate certificate that is not logged in Certificate Transparency 121 logs, or if a web host operator believes their certificate to conform 122 to all UAs' CT policies but is mistaken). Web host operators are 123 advised to deploy Expect-CT with caution, by using the reporting 124 feature and gradually increasing the interval where the UA remembers 125 the host as a Known Expect-CT Host. These precautions can help web 126 host operators gain confidence that their Expect-CT deployment is not 127 causing unwanted connection failures. 129 Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a 130 UA connects to a host, it lacks the information necessary to require 131 SCTs for the connection. Thus, the UA will not be able to detect and 132 thwart an attack on the UA's first connection to the host. Still, 133 Expect-CT provides value by 1) allowing UAs to detect the use of 134 unlogged certificates after the initial communication, and 2) 135 allowing web hosts to be confident that UAs are only trusting 136 publicly-auditable certificates. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in RFC 143 2119 [RFC2119]. 145 1.2. Terminology 147 Terminology is defined in this section. 149 Certificate Transparency Policy is a policy defined by the UA 150 concerning the number, sources, and delivery mechanisms of Signed 151 Certificate Timestamps that are served on TLS connections. The 152 policy defines the properties of a connection that must be met in 153 order for the UA to consider it CT-qualified. 155 Certificate Transparency Qualified describes a TLS connection for 156 which the UA has determined that a sufficient quantity and quality 157 of Signed Certificate Timestamps have been provided. 159 CT-qualified See Certificate Transparency Qualified. 161 CT Policy See Certificate Transparency Policy. 163 Effective Expect-CT Date is the time at which a UA observed a valid 164 Expect-CT header for a given host. 166 Expect-CT Host See HTTP Expect-CT Host. 168 HTTP Expect-CT is the overall name for the combined UA- and server- 169 side security policy defined by this specification. 171 HTTP Expect-CT Host is a conformant host implementing the HTTP 172 server aspects of HTTP Expect-CT. This means that an Expect-CT 173 Host returns the "Expect-CT" HTTP response header field in its 174 HTTP response messages sent over secure transport. 176 Known Expect-CT Host is an Expect-CT Host that the UA has noted as 177 such. See Section 2.3.3 for particulars. 179 UA is an acronym for "user agent". For the purposes of this 180 specification, a UA is an HTTP client application typically 181 actively manipulated by a user [RFC7230]. 183 Unknown Expect-CT Host is an Expect-CT Host that the UA has not 184 noted. 186 2. Server and Client Behavior 188 2.1. Response Header Field Syntax 190 The "Expect-CT" header field is a new response header defined in this 191 specification. It is used by a server to indicate that UAs should 192 evaluate connections to the host emitting the header for CT 193 compliance (Section 2.4). 195 Figure 1 describes the syntax (Augmented Backus-Naur Form) of the 196 header field, using the grammar defined in RFC 5234 [RFC5234] and the 197 rules defined in Section 3.2 of RFC 7230 [RFC7230]. 199 Expect-CT = #expect-ct-directive 200 expect-ct-directive = directive-name [ "=" directive-value ] 201 directive-name = token 202 directive-value = token / quoted-string 204 Figure 1: Syntax of the Expect-CT header field 206 Optional white space ("OWS") is used as defined in Section 3.2.3 of 207 RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined 208 in Section 3.2.6 of RFC 7230 [RFC7230]. 210 The directives defined in this specification are described below. 211 The overall requirements for directives are: 213 1. The order of appearance of directives is not significant. 215 2. A given directive MUST NOT appear more than once in a given 216 header field. Directives are either optional or required, as 217 stipulated in their definitions. 219 3. Directive names are case insensitive. 221 4. UAs MUST ignore any header fields containing directives, or other 222 header field value data, that do not conform to the syntax 223 defined in this specification. In particular, UAs must not 224 attempt to fix malformed header fields. 226 5. If a header field contains any directive(s) the UA does not 227 recognize, the UA MUST ignore those directives. 229 6. If the Expect-CT header field otherwise satisfies the above 230 requirements (1 through 5), the UA MUST process the directives it 231 recognizes. 233 2.1.1. The report-uri Directive 235 The OPTIONAL "report-uri" directive indicates the URI to which the UA 236 SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the 237 reports to the given URI as described in Section 3. 239 The "report-uri" directive is REQUIRED to have a directive value, for 240 which the syntax is defined in Figure 2. 242 report-uri-value = absolute-URI 244 Figure 2: Syntax of the report-uri directive value 246 "absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986]. 248 Hosts may set "report-uri"s that use HTTP or HTTPS. If the scheme in 249 the "report-uri" is one that uses TLS (e.g., HTTPS), UAs MUST check 250 Expect-CT compliance when the host in the "report-uri" is a Known 251 Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the 252 "report-uri" is a Known HSTS Host. 254 Note that the report-uri need not necessarily be in the same Internet 255 domain or web origin as the host being reported about. 257 UAs SHOULD make their best effort to report Expect-CT failures to the 258 "report-uri", but they may fail to report in exceptional conditions. 259 For example, if connecting the "report-uri" itself incurs an Expect- 260 CT failure or other certificate validation failure, the UA MUST 261 cancel the connection. Similarly, if Expect-CT Host A sets a 262 "report-uri" referring to Expect-CT Host B, and if B sets a "report- 263 uri" referring to A, and if both hosts fail to comply to the UA's CT 264 Policy, the UA SHOULD detect and break the loop by failing to send 265 reports to and about those hosts. 267 UAs SHOULD limit the rate at which they send reports. For example, 268 it is unnecessary to send the same report to the same "report-uri" 269 more than once. 271 2.1.2. The enforce Directive 273 The OPTIONAL "enforce" directive is a valueless directive that, if 274 present (i.e., it is "asserted"), signals to the UA that compliance 275 to the CT Policy should be enforced (rather than report-only) and 276 that the UA should refuse future connections that violate its CT 277 Policy. When both the "enforce" directive and "report-uri" directive 278 (as defined in Figure 2) are present, the configuration is referred 279 to as an "enforce-and-report" configuration, signalling to the UA 280 both that compliance to the CT Policy should be enforced and that 281 violations should be reported. 283 2.1.3. The max-age Directive 285 The "max-age" directive specifies the number of seconds after the 286 reception of the Expect-CT header field during which the UA SHOULD 287 regard the host from whom the message was received as a Known Expect- 288 CT Host. 290 The "max-age" directive is REQUIRED to be present within an "Expect- 291 CT" header field. The "max-age" directive is REQUIRED to have a 292 directive value, for which the syntax (after quoted-string 293 unescaping, if necessary) is defined in Figure 3. 295 max-age-value = delta-seconds 296 delta-seconds = 1*DIGIT 298 Figure 3: Syntax of the max-age directive value 300 "delta-seconds" is used as defined in Section 1.2.1 of RFC 7234 301 [RFC7234]. 303 2.1.4. Examples 305 The following examples demonstrate valid Expect-CT response header 306 fields: 308 Expect-CT: max-age=86400,enforce 310 Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report" 312 Expect-CT: max-age=86400,report-uri="https://foo.example/report" 314 Figure 4: Examples of valid Expect-CT response header fields 316 2.2. Server Processing Model 318 This section describes the processing model that Expect-CT Hosts 319 implement. The model has 2 parts: (1) the processing rules for HTTP 320 request messages received over a secure transport (e.g., 321 authenticated, non-anonymous TLS); and (2) the processing rules for 322 HTTP request messages received over non-secure transports, such as 323 TCP. 325 2.2.1. HTTP-over-Secure-Transport Request Type 327 When replying to an HTTP request that was conveyed over a secure 328 transport, an Expect-CT Host SHOULD include in its response exactly 329 one Expect-CT header field. The header field MUST satisfy the 330 grammar specified in Section 2.1. 332 Establishing a given host as an Expect-CT Host, in the context of a 333 given UA, is accomplished as follows: 335 1. Over the HTTP protocol running over secure transport, by 336 correctly returning (per this specification) at least one valid 337 Expect-CT header field to the UA. 339 2. Through other mechanisms, such as a client-side preloaded Expect- 340 CT Host list. 342 2.2.2. HTTP Request Type 344 Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP 345 responses conveyed over non-secure transport. UAs MUST ignore any 346 Expect-CT header received in an HTTP response conveyed over non- 347 secure transport. 349 2.3. User Agent Processing Model 351 The UA processing model relies on parsing domain names. Note that 352 internationalized domain names SHALL be canonicalized according to 353 the scheme in Section 10 of [RFC6797]. 355 2.3.1. Expect-CT Header Field Processing 357 If the UA receives, over a secure transport, an HTTP response that 358 includes an Expect-CT header field conforming to the grammar 359 specified in Section 2.1, the UA MUST evaluate the connection on 360 which the header was received for compliance with the UA's CT Policy, 361 and then process the Expect-CT header field as follows. 363 If the connection complies with the UA's CT Policy (i.e. the 364 connection is CT-qualified), then the UA MUST either: 366 o Note the host as a Known Expect-CT Host if it is not already so 367 noted (see Section 2.3.3), or 369 o Update the UA's cached information for the Known Expect-CT Host if 370 the "enforce", "max-age", or "report-uri" header field value 371 directives convey information different from that already 372 maintained by the UA. If the "max-age" directive has a value of 373 0, the UA MUST remove its cached Expect-CT information if the host 374 was previously noted as a Known Expect-CT Host, and MUST NOT note 375 this host as a Known Expect-CT Host if it is not already noted. 377 If the connection does not comply with the UA's CT Policy (i.e. is 378 not CT-qualified), then the UA MUST NOT note this host as a Known 379 Expect-CT Host. 381 If the header field includes a "report-uri" directive, and the 382 connection does not comply with the UA's CT Policy (i.e. the 383 connection is not CT-qualified), and the UA has not already sent an 384 Expect-CT report for this connection, then the UA SHOULD send a 385 report to the specified "report-uri" as specified in Section 3. 387 The UA MUST ignore any Expect-CT header field not conforming to the 388 grammar specified in Section 2.1. 390 2.3.2. HTTP-Equiv Element Attribute 392 UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on 393 "" elements [W3C.REC-html401-19991224] in received content. 395 2.3.3. Noting Expect-CT 397 Upon receipt of the Expect-CT response header field over an error- 398 free TLS connection (including the validation adding in Section 2.4), 399 the UA MUST note the host as a Known Expect-CT Host, storing the 400 host's domain name and its associated Expect-CT directives in non- 401 volatile storage. The domain name and associated Expect-CT 402 directives are collectively known as "Expect-CT metadata". 404 To note a host as a Known Expect-CT Host, the UA MUST set its Expect- 405 CT metadata given in the most recently received valid Expect-CT 406 header, as specified in Section 2.3.4. 408 For forward compatibility, the UA MUST ignore any unrecognized 409 Expect-CT header directives, while still processing those directives 410 it does recognize. Section 2.1 specifies the directives "enforce", 411 "max-age", and "report-uri", but future specifications and 412 implementations might use additional directives. 414 2.3.4. Storage Model 416 Known Expect-CT Hosts are identified only by domain names, and never 417 IP addresses. If the substring matching the host production from the 418 Request-URI (of the message to which the host responded) 419 syntactically matches the IP-literal or IPv4address productions from 420 Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a 421 Known Expect-CT Host. 423 Otherwise, if the substring does not congruently match an existing 424 Known Expect-CT Host's domain name, per the matching procedure 425 specified in Section 8.2 of [RFC6797], then the UA MUST add this host 426 to the Known Expect-CT Host cache. The UA caches: 428 o the Expect-CT Host's domain name, 429 o whether the "enforce" directive is present 431 o the Effective Expiration Date, which is the Effective Expect-CT 432 Date plus the value of the "max-age" directive. Alternatively, 433 the UA MAY cache enough information to calculate the Effective 434 Expiration Date. 436 o the value of the "report-uri" directive, if present. 438 If any other metadata from optional or future Expect-CT header 439 directives are present in the Expect-CT header, and the UA 440 understands them, the UA MAY note them as well. 442 UAs MAY set an upper limit on the value of max-age, so that UAs that 443 have noted erroneous Expect-CT hosts (whether by accident or due to 444 attack) have some chance of recovering over time. If the server sets 445 a max-age greater than the UA's upper limit, the UA MAY behave as if 446 the server set the max-age to the UA's upper limit. For example, if 447 the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT 448 Host sets a max- age directive of 90 days in its Expect-CT header, 449 the UA MAY behave as if the max-age were effectively 60 days. (One 450 way to achieve this behavior is for the UA to simply store a value of 451 60 days instead of the 90-day value provided by the Expect-CT host.) 453 2.4. Evaluating Expect-CT Connections for CT Compliance 455 When a UA connects to a Known Expect-CT Host using a TLS connection, 456 if the TLS connection has errors, the UA MUST terminate the 457 connection without allowing the user to proceed anyway. (This 458 behavior is the same as that required by [RFC6797].) 460 If the connection has no errors, then the UA will apply an additional 461 correctness check: compliance with a CT Policy. A UA should evaluate 462 compliance with its CT Policy whenever connecting to a Known Expect- 463 CT Host, as soon as possible. It is acceptable to skip this CT 464 compliance check for some hosts according to local policy. For 465 example, a UA may disable CT compliance checks for hosts whose 466 validated certificate chain terminates at a user-defined trust 467 anchor, rather than a trust anchor built-in to the UA (or underlying 468 platform). 470 An Expect-CT Host is "expired" if the effective expiration date 471 refers to a date in the past. The UA MUST ignore any expired Expect- 472 CT Hosts in its cache and not treat such hosts as Known Expect-CT 473 hosts. 475 If a connection to a Known CT Host violates the UA's CT policy (i.e. 476 the connection is not CT-qualified), and if the Known Expect-CT 477 Host's Expect-CT metadata indicates an "enforce" configuration, the 478 UA MUST treat the CT compliance failure as a non-recoverable error. 480 If a connection to a Known CT Host violates the UA's CT policy, and 481 if the Known Expect-CT Host's Expect-CT metadata includes a "report- 482 uri", the UA SHOULD send an Expect-CT report to that "report-uri" 483 (Section 3). 485 A UA that has previously noted a host as a Known Expect-CT Host MUST 486 evaluate CT compliance when setting up the TLS session, before 487 beginning an HTTP conversation over the TLS channel. 489 If the UA does not evaluate CT compliance, e.g. because the user has 490 elected to disable it, or because a presented certificate chain 491 chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect- 492 CT reports. 494 3. Reporting Expect-CT Failure 496 When the UA attempts to connect to a Known Expect-CT Host and the 497 connection is not CT-qualified, the UA SHOULD report Expect-CT 498 failures to the "report-uri", if any, in the Known Expect-CT Host's 499 Expect-CT metadata. 501 When the UA receives an Expect-CT response header field over a 502 connection that is not CT-qualified, if the UA has not already sent 503 an Expect-CT report for this connection, then the UA SHOULD report 504 Expect-CT failures to the configured "report-uri", if any. 506 3.1. Generating a violation report 508 To generate a violation report object, the UA constructs a JSON 509 object with the following keys and values: 511 o "date-time": the value for this key indicates the time the UA 512 observed the CT compliance failure. The value is a string 513 formatted according to Section 5.6, "Internet Date/Time Format", 514 of [RFC3339]. 516 o "hostname": the value is the hostname to which the UA made the 517 original request that failed the CT compliance check. The value 518 is provided as a string. 520 o "port": the value is the port to which the UA made the original 521 request that failed the CT compliance check. The value is 522 provided as an integer. 524 o "effective-expiration-date": the value indicates the Effective 525 Expiration Date (see Section 2.3.4) for the Expect-CT Host that 526 failed the CT compliance check. The value is provided as a string 527 formatted according to Section 5.6, "Internet Date/Time Format", 528 of [RFC3339]. 530 o "served-certificate-chain": the value is the certificate chain as 531 served by the Expect-CT Host during TLS session setup. The value 532 is provided as an array of strings, which MUST appear in the order 533 that the certificates were served; each string in the array is the 534 Privacy-Enhanced Mail (PEM) representation of each X.509 535 certificate as described in [RFC7468]. 537 o "validated-certificate-chain": the value is the certificate chain 538 as constructed by the UA during certificate chain verification. 539 (This may differ from the value of the "served-certificate-chain" 540 key.) The value is provided as an array of strings, which MUST 541 appear in the order matching the chain that the UA validated; each 542 string in the array is the Privacy-Enhanced Mail (PEM) 543 representation of each X.509 certificate as described in 544 [RFC7468]. 546 o "scts": the value represents the SCTs (if any) that the UA 547 received for the Expect-CT host and their validation statuses. 548 The value is provided as an array of JSON objects. The SCTs may 549 appear in any order. Each JSON object in the array has the 550 following keys: 552 * The "sct" key, with a value as defined in Section 4.6 of 553 [I-D.ietf-trans-rfc6962-bis]. 555 * The "status" key, with a string value that the UA MUST set to 556 one of the following values: "unknown" (indicating that the UA 557 does not have or does not trust the public key of the log from 558 which the SCT was issued), "valid" (indicating that the UA 559 successfully validated the SCT as described in Section 8.2.3 of 560 [I-D.ietf-trans-rfc6962-bis]), or "invalid" (indicating that 561 the SCT validation failed because of, e.g., a bad signature). 563 * The "source" key, with a string value that indicates from where 564 the UA obtained the SCT, as defined in Section 6 of 565 [I-D.ietf-trans-rfc6962-bis]. The UA MUST set the value to one 566 of "tls-extension", "ocsp", or "embedded". 568 3.2. Sending a violation report 570 The UA SHOULD report an Expect-CT failure when a connection to a 571 Known Expect-CT Host does not comply with the UA's CT Policy and the 572 host's Expect-CT metadata contains a "report-uri". Additionally, the 573 UA SHOULD report an Expect-CT failure when it receives an Expect-CT 574 header field which contains the "report-uri" directive over a 575 connection that does not comply with the UA's CT Policy. 577 The steps to report an Expect-CT failure are as follows. 579 1. Prepare a JSON object "report object" with the single key 580 "expect-ct-report", whose value is the result of generating a 581 violation report object as described in Section 3.1. 583 2. Let "report body" by the JSON stringification of "report object". 585 3. Let "report-uri" be the value of the "report-uri" directive in 586 the Expect-CT header field. 588 4. Send an HTTP POST request to "report-uri" with a "Content-Type" 589 header field of "application/expect-ct-report+json", and an 590 entity body consisting of "report body". 592 The UA MAY perform other operations as part of sending the HTTP POST 593 request, for example sending a CORS preflight as part of [FETCH]. 595 4. Security Considerations 597 When UAs support the Expect-CT header, it becomes a potential vector 598 for hostile header attacks against site owners. If a site owner uses 599 a certificate issued by a certificate authority which does not embed 600 SCTs nor serve SCTs via OCSP or TLS extension, a malicious server 601 operator or attacker could temporarily reconfigure the host to comply 602 with the UA's CT policy, and add the Expect-CT header in enforcing 603 mode with a long "max-age". Implementing user agents would note this 604 as an Expect-CT Host (see Section 2.3.3). After having done this, 605 the configuration could then be reverted to not comply with the CT 606 policy, prompting failures. Note this scenario would require the 607 attacker to have substantial control over the infrastructure in 608 question, being able to obtain different certificates, change server 609 software, or act as a man-in-the-middle in connections. 611 Site operators could themselves only cure this situation by one of: 612 reconfiguring their web server to transmit SCTs using the TLS 613 extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis], 614 obtaining a certificate from an alternative certificate authority 615 which provides SCTs by one of the other methods, or by waiting for 616 the user agents' persisted notation of this as an Expect-CT host to 617 reach its "max-age". User agents may choose to implement mechanisms 618 for users to cure this situation, as noted in Section 7. 620 4.1. Maximum max-age 622 There is a security trade-off in that low maximum values provide a 623 narrow window of protection for users that visit the Known Expect-CT 624 Host only infrequently, while high maximum values might result in a 625 denial of service to a UA in the event of a hostile header attack, or 626 simply an error on the part of the site-owner. 628 There is probably no ideal maximum for the "max-age" directive. 629 Since Expect-CT is primarily a policy-expansion and investigation 630 technology rather than an end-user protection, a value on the order 631 of 30 days (2,592,000 seconds) may be considered a balance between 632 these competing security concerns. 634 4.2. Avoiding amplification attacks 636 Another kind of hostile header attack uses the "report-uri" mechanism 637 on many hosts not currently exposing SCTs as a method to cause a 638 denial-of-service to the host receiving the reports. If some highly- 639 trafficked websites emitted a non-enforcing Expect-CT header with a 640 "report-uri", implementing UAs' reports could flood the reporting 641 host. It is noted in Section 2.1.1 that UAs should limit the rate at 642 which they emit reports, but an attacker may alter the Expect-CT 643 header's fields to induce UAs to submit different reports to 644 different URIs to still cause the same effect. 646 5. Privacy Considerations 648 Expect-CT can be used to infer what Certificate Transparency policy 649 is in use, by attempting to retrieve specially-configured websites 650 which pass one user agents' policies but not another's. Note that 651 this consideration is true of UAs which enforce CT policies without 652 Expect-CT as well. 654 Additionally, reports submitted to the "report-uri" could reveal 655 information to a third party about which webpage is being accessed 656 and by which IP address, by using individual "report-uri" values for 657 individually-tracked pages. This information could be leaked even if 658 client-side scripting were disabled. 660 Implementations must store state about Known Expect-CT Hosts, and 661 hence which domains the UA has contacted. 663 Violation reports, as noted in Section 3, contain information about 664 the certificate chain that has violated the CT policy. In some 665 cases, such as organization-wide compromise of the end-to-end 666 security of TLS, this may include information about the interception 667 tools and design used by the organization that the organization would 668 otherwise prefer not be disclosed. 670 Because Expect-CT causes remotely-detectable behavior, it's advisable 671 that UAs offer a way for privacy-sensitive users to clear currently 672 noted Expect-CT hosts, and allow users to query the current state of 673 Known Expect-CT Hosts. 675 6. IANA Considerations 677 TBD 679 7. Usability Considerations 681 When the UA detects a Known Expect-CT Host in violation of the UA's 682 CT Policy, users will experience denials of service. It is advisable 683 for UAs to explain the reason why. 685 8. Authoring Considerations 687 8.1. HTTP Header 689 Expect-CT could be specified as a TLS extension or X.509 certificate 690 extension instead of an HTTP response header. Using an HTTP header 691 as the mechanism for Expect-CT introduces a layering mismatch: for 692 example, the software that terminates TLS and validates Certificate 693 Transparency information might know nothing about HTTP. 694 Nevertheless, an HTTP header was chosen primarily for ease of 695 deployment. In practice, deploying new certificate extensions 696 requires certificate authorities to support them, and new TLS 697 extensions require server software updates, including possibly to 698 servers outside of the site owner's direct control (such as in the 699 case of a third-party CDN). Ease of deployment is a high priority 700 for Expect-CT because it is intended as a temporary transition 701 mechanism for user agents that are transitioning to universal 702 Certificate Transparency requirements. 704 9. Changes 706 9.1. Since -00 708 o Editorial changes 709 o Change Content-Type header of reports to 'application/expect-ct- 710 report+json' 712 o Update header field syntax to match convention (issue #327) 714 o Reference RFC 6962-bis instead of RFC 6962 716 10. Normative References 718 [FETCH] van Kesteren, A., "Fetch", n.d., 719 . 721 [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, 722 P., and D. Denicola, "HTML", n.d., 723 . 725 [I-D.ietf-trans-rfc6962-bis] 726 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 727 Stradling, "Certificate Transparency Version 2.0", draft- 728 ietf-trans-rfc6962-bis-24 (work in progress), December 729 2016. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 737 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 738 . 740 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 741 Resource Identifier (URI): Generic Syntax", STD 66, 742 RFC 3986, DOI 10.17487/RFC3986, January 2005, 743 . 745 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 746 Specifications: ABNF", STD 68, RFC 5234, 747 DOI 10.17487/RFC5234, January 2008, 748 . 750 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 751 (TLS) Protocol Version 1.2", RFC 5246, 752 DOI 10.17487/RFC5246, August 2008, 753 . 755 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 756 Transport Security (HSTS)", RFC 6797, 757 DOI 10.17487/RFC6797, November 2012, 758 . 760 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 761 Protocol (HTTP/1.1): Message Syntax and Routing", 762 RFC 7230, DOI 10.17487/RFC7230, June 2014, 763 . 765 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 766 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 767 RFC 7234, DOI 10.17487/RFC7234, June 2014, 768 . 770 [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, 771 PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, 772 April 2015, . 774 [W3C.REC-html401-19991224] 775 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 776 Specification", World Wide Web Consortium Recommendation 777 REC-html401-19991224, December 1999, 778 . 780 Author's Address 782 Emily Stark 783 Google 785 Email: estark@google.com