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