draft-ietf-httpbis-expect-ct-00.txt   draft-ietf-httpbis-expect-ct-01.txt 
HTTP Working Group E. Stark HTTP Working Group E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental February 8, 2017 Intended status: Experimental May 24, 2017
Expires: August 12, 2017 Expires: November 25, 2017
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-00 draft-ietf-httpbis-expect-ct-01
Abstract Abstract
This document defines a new HTTP header, named Expect-CT, that allows This document defines a new HTTP header, named Expect-CT, that allows
web host operators to instruct user agents to expect valid Signed web host operators to instruct user agents to expect valid Signed
Certificate Timestamps (SCTs) to be served on connections to these Certificate Timestamps (SCTs) to be served on connections to these
hosts. When configured in enforcement mode, user agents (UAs) will hosts. When configured in enforcement mode, user agents (UAs) will
remember that hosts expect SCTs and will refuse connections that do remember that hosts expect SCTs and will refuse connections that do
not conform to the UA's Certificate Transparency policy. When not conform to the UA's Certificate Transparency policy. When
configured in report-only mode, UAs will report the lack of valid configured in report-only mode, UAs will report the lack of valid
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2017. This Internet-Draft will expire on November 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Server and Client Behavior . . . . . . . . . . . . . . . . . 4 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 4
2.1. Response Header Field Syntax . . . . . . . . . . . . . . 4 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 4
2.1.1. The report-uri Directive . . . . . . . . . . . . . . 5 2.1.1. The report-uri Directive . . . . . . . . . . . . . . 5
2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6 2.1.2. The enforce Directive . . . . . . . . . . . . . . . . 6
2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 6 2.1.3. The max-age Directive . . . . . . . . . . . . . . . . 7
2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7
2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7
2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 7 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8
2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8
2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 8 2.3.1. Expect-CT Header Field Processing . . . . . . . . . . 8
2.3.2. Noting an Expect-CT Host - Storage Model . . . . . . 9 2.3.2. HTTP-Equiv <meta> Element Attribute . . . . . . . . . 9
2.3.3. HTTP-Equiv <meta> Element Attribute . . . . . . . . . 10 2.3.3. Noting Expect-CT . . . . . . . . . . . . . . . . . . 9
2.4. Noting Expect-CT . . . . . . . . . . . . . . . . . . . . 10 2.3.4. Storage Model . . . . . . . . . . . . . . . . . . . . 9
2.5. Evaluating Expect-CT Connections for CT Compliance . . . 10 2.4. Evaluating Expect-CT Connections for CT Compliance . . . 10
3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11 3. Reporting Expect-CT Failure . . . . . . . . . . . . . . . . . 11
3.1. Generating a violation report . . . . . . . . . . . . . . 11 3.1. Generating a violation report . . . . . . . . . . . . . . 11
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 14
4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 14
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Usability Considerations . . . . . . . . . . . . . . . . . . 16 7. Usability Considerations . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document defines a new HTTP header that enables UAs to identify This document defines a new HTTP header that enables UAs to identify
web hosts that expect the presence of Signed Certificate Timestamps web hosts that expect the presence of Signed Certificate Timestamps
(SCTs) [RFC6962] in future Transport Layer Security (TLS) [RFC5246] (SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer
connections. Security (TLS) [RFC5246] connections.
Web hosts that serve the Expect-CT HTTP header are noted by the UA as Web hosts that serve the Expect-CT HTTP header are noted by the UA as
Known Expect-CT Hosts. The UA evaluates each connection to a Known Known Expect-CT Hosts. The UA evaluates each connection to a Known
Expect-CT Host for compliance with the UA's Certificate Transparency Expect-CT Host for compliance with the UA's Certificate Transparency
(CT) Policy. If the connection violates the CT Policy, the UA sends (CT) Policy. If the connection violates the CT Policy, the UA sends
a report to a URI configured by the Expect-CT Host and/or fails the a report to a URI configured by the Expect-CT Host and/or fails the
connection, depending on the configuration that the Expect-CT Host connection, depending on the configuration that the Expect-CT Host
has chosen. has chosen.
If misconfigured, Expect-CT can cause unwanted connection failures If misconfigured, Expect-CT can cause unwanted connection failures
skipping to change at page 4, line 23 skipping to change at page 4, line 23
order for the UA to consider it CT-qualified. order for the UA to consider it CT-qualified.
Certificate Transparency Qualified describes a TLS connection for Certificate Transparency Qualified describes a TLS connection for
which the UA has determined that a sufficient quantity and quality which the UA has determined that a sufficient quantity and quality
of Signed Certificate Timestamps have been provided. of Signed Certificate Timestamps have been provided.
CT-qualified See Certificate Transparency Qualified. CT-qualified See Certificate Transparency Qualified.
CT Policy See Certificate Transparency Policy. CT Policy See Certificate Transparency Policy.
Effective Expect-CT Date is the time at which a UA observed a valid
Expect-CT header for a given host.
Expect-CT Host See HTTP Expect-CT Host. Expect-CT Host See HTTP Expect-CT Host.
HTTP Expect-CT is the overall name for the combined UA- and server- HTTP Expect-CT is the overall name for the combined UA- and server-
side security policy defined by this specification. side security policy defined by this specification.
HTTP Expect-CT Host is a conformant host implementing the HTTP HTTP Expect-CT Host is a conformant host implementing the HTTP
server aspects of HTTP Expect-CT. This means that an Expect-CT server aspects of HTTP Expect-CT. This means that an Expect-CT
Host returns the "Expect-CT" HTTP response header field in its Host returns the "Expect-CT" HTTP response header field in its
HTTP response messages sent over secure transport. HTTP response messages sent over secure transport.
Known Expect-CT Host is an Expect-CT Host that the UA has noted as Known Expect-CT Host is an Expect-CT Host that the UA has noted as
such. See Section 2.4 for particulars. such. See Section 2.3.3 for particulars.
UA is an acronym for "user agent". For the purposes of this UA is an acronym for "user agent". For the purposes of this
specification, a UA is an HTTP client application typically specification, a UA is an HTTP client application typically
actively manipulated by a user [RFC2616]. actively manipulated by a user [RFC7230].
Unknown Expect-CT Host is an Expect-CT Host that the UA has not Unknown Expect-CT Host is an Expect-CT Host that the UA has not
noted. noted.
2. Server and Client Behavior 2. Server and Client Behavior
2.1. Response Header Field Syntax 2.1. Response Header Field Syntax
The "Expect-CT" header field is a new response header defined in this The "Expect-CT" header field is a new response header defined in this
specification. It is used by a server to indicate that UAs should specification. It is used by a server to indicate that UAs should
evaluate connections to the host emitting the header for CT evaluate connections to the host emitting the header for CT
compliance (Section 2.5). compliance (Section 2.4).
Figure 1 describes the syntax (Augmented Backus-Naur Form) of the Figure 1 describes the syntax (Augmented Backus-Naur Form) of the
header field, using the grammar defined in RFC 5234 [RFC5234] and the header field, using the grammar defined in RFC 5234 [RFC5234] and the
rules defined in Section 3.2 of RFC 7230 [RFC7230]. rules defined in Section 3.2 of RFC 7230 [RFC7230].
Expect-CT-Directives = directive *( OWS ";" OWS directive ) Expect-CT = #expect-ct-directive
directive = directive-name [ "=" directive-value ] expect-ct-directive = directive-name [ "=" directive-value ]
directive-name = token directive-name = token
directive-value = token / quoted-string directive-value = token / quoted-string
Figure 1: Syntax of the Expect-CT header field Figure 1: Syntax of the Expect-CT header field
Optional white space ("OWS") is used as defined in Section 3.2.3 of Optional white space ("OWS") is used as defined in Section 3.2.3 of
RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined RFC 7230 [RFC7230]. "token" and "quoted-string" are used as defined
in Section 3.2.6 of RFC 7230 [RFC7230]. in Section 3.2.6 of RFC 7230 [RFC7230].
The directives defined in this specification are described below. The directives defined in this specification are described below.
The overall requirements for directives are: The overall requirements for directives are:
skipping to change at page 5, line 46 skipping to change at page 5, line 48
5. If a header field contains any directive(s) the UA does not 5. If a header field contains any directive(s) the UA does not
recognize, the UA MUST ignore those directives. recognize, the UA MUST ignore those directives.
6. If the Expect-CT header field otherwise satisfies the above 6. If the Expect-CT header field otherwise satisfies the above
requirements (1 through 5), the UA MUST process the directives it requirements (1 through 5), the UA MUST process the directives it
recognizes. recognizes.
2.1.1. The report-uri Directive 2.1.1. The report-uri Directive
The OPTIONAL "report-uri" directive indicates the URI to which the UA The OPTIONAL "report-uri" directive indicates the URI to which the UA
SHOULD report Expect-CT failures (Section 2.5). The UA POSTs the SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the
reports to the given URI as described in Section 3. reports to the given URI as described in Section 3.
The "report-uri" directive is REQUIRED to have a directive value, for The "report-uri" directive is REQUIRED to have a directive value, for
which the syntax is defined in Figure 2. which the syntax is defined in Figure 2.
report-uri-value = absolute-URI report-uri-value = absolute-URI
Figure 2: Syntax of the report-uri directive value Figure 2: Syntax of the report-uri directive value
"absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986]. "absolute-URI" is defined in Section 4.3 of RFC 3986 [RFC3986].
skipping to change at page 7, line 18 skipping to change at page 7, line 25
unescaping, if necessary) is defined in Figure 3. unescaping, if necessary) is defined in Figure 3.
max-age-value = delta-seconds max-age-value = delta-seconds
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
Figure 3: Syntax of the max-age directive value Figure 3: Syntax of the max-age directive value
"delta-seconds" is used as defined in Section 1.2.1 of RFC 7234 "delta-seconds" is used as defined in Section 1.2.1 of RFC 7234
[RFC7234]. [RFC7234].
2.1.4. Examples
The following examples demonstrate valid Expect-CT response header
fields:
Expect-CT: max-age=86400,enforce
Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report"
Expect-CT: max-age=86400,report-uri="https://foo.example/report"
Figure 4: Examples of valid Expect-CT response header fields
2.2. Server Processing Model 2.2. Server Processing Model
This section describes the processing model that Expect-CT Hosts This section describes the processing model that Expect-CT Hosts
implement. The model has 2 parts: (1) the processing rules for HTTP implement. The model has 2 parts: (1) the processing rules for HTTP
request messages received over a secure transport (e.g., request messages received over a secure transport (e.g.,
authenticated, non-anonymous TLS); and (2) the processing rules for authenticated, non-anonymous TLS); and (2) the processing rules for
HTTP request messages received over non-secure transports, such as HTTP request messages received over non-secure transports, such as
TCP. TCP.
2.2.1. HTTP-over-Secure-Transport Request Type 2.2.1. HTTP-over-Secure-Transport Request Type
skipping to change at page 8, line 23 skipping to change at page 8, line 40
If the UA receives, over a secure transport, an HTTP response that If the UA receives, over a secure transport, an HTTP response that
includes an Expect-CT header field conforming to the grammar includes an Expect-CT header field conforming to the grammar
specified in Section 2.1, the UA MUST evaluate the connection on specified in Section 2.1, the UA MUST evaluate the connection on
which the header was received for compliance with the UA's CT Policy, which the header was received for compliance with the UA's CT Policy,
and then process the Expect-CT header field as follows. and then process the Expect-CT header field as follows.
If the connection complies with the UA's CT Policy (i.e. the If the connection complies with the UA's CT Policy (i.e. the
connection is CT-qualified), then the UA MUST either: connection is CT-qualified), then the UA MUST either:
o Note the host as a Known Expect-CT Host if it is not already so o Note the host as a Known Expect-CT Host if it is not already so
noted (see Section 2.4), or noted (see Section 2.3.3), or
o Update the UA's cached information for the Known Expect-CT Host if o Update the UA's cached information for the Known Expect-CT Host if
the "enforce", "max-age", or "report-uri" header field value the "enforce", "max-age", or "report-uri" header field value
directives convey information different from that already directives convey information different from that already
maintained by the UA. If the "max-age" directive has a value of maintained by the UA. If the "max-age" directive has a value of
0, the UA MUST remove its cached Expect-CT information if the host 0, the UA MUST remove its cached Expect-CT information if the host
was previously noted as a Known Expect-CT Host, and MUST NOT note was previously noted as a Known Expect-CT Host, and MUST NOT note
this host as a Known Expect-CT Host if it is not already noted. this host as a Known Expect-CT Host if it is not already noted.
If the connection does not comply with the UA's CT Policy (i.e. is If the connection does not comply with the UA's CT Policy (i.e. is
not CT-qualified), then the UA MUST NOT note this host as a Known not CT-qualified), then the UA MUST NOT note this host as a Known
Expect-CT Host. Expect-CT Host.
If the header field includes a "report-uri" directive, and the If the header field includes a "report-uri" directive, and the
connection does not comply with the UA's CT Policy (i.e. the connection does not comply with the UA's CT Policy (i.e. the
connection is not CT-qualified), and the UA has not already sent an connection is not CT-qualified), and the UA has not already sent an
Expect-CT report for this connection, then the UA SHOULD send a Expect-CT report for this connection, then the UA SHOULD send a
report to the specified "report-uri" as specified in Section 3. report to the specified "report-uri" as specified in Section 3.
If a UA receives more than one Expect-CT header field in an HTTP
response message over secure transport, then the UA MUST process only
the first Expect-CT header field.
The UA MUST ignore any Expect-CT header field not conforming to the The UA MUST ignore any Expect-CT header field not conforming to the
grammar specified in Section 2.1. grammar specified in Section 2.1.
2.3.2. Noting an Expect-CT Host - Storage Model 2.3.2. HTTP-Equiv <meta> Element Attribute
The "effective Expect-CT date" of a Known Expect-CT Host is the time UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
that the UA observed a valid Expect-CT header for the host. The "<meta>" elements [W3C.REC-html401-19991224] in received content.
"effective expiration date" of a Known Expect-CT Host is the
effective Expect-CT date plus the max-age. An Expect-CT Host is 2.3.3. Noting Expect-CT
"expired" if the effective expiration date refers to a date in the
past. The UA MUST ignore any expired Expect-CT Hosts in its cache. Upon receipt of the Expect-CT response header field over an error-
free TLS connection (including the validation adding in Section 2.4),
the UA MUST note the host as a Known Expect-CT Host, storing the
host's domain name and its associated Expect-CT directives in non-
volatile storage. The domain name and associated Expect-CT
directives are collectively known as "Expect-CT metadata".
To note a host as a Known Expect-CT Host, the UA MUST set its Expect-
CT metadata given in the most recently received valid Expect-CT
header, as specified in Section 2.3.4.
For forward compatibility, the UA MUST ignore any unrecognized
Expect-CT header directives, while still processing those directives
it does recognize. Section 2.1 specifies the directives "enforce",
"max-age", and "report-uri", but future specifications and
implementations might use additional directives.
2.3.4. Storage Model
Known Expect-CT Hosts are identified only by domain names, and never Known Expect-CT Hosts are identified only by domain names, and never
IP addresses. If the substring matching the host production from the IP addresses. If the substring matching the host production from the
Request-URI (of the message to which the host responded) Request-URI (of the message to which the host responded)
syntactically matches the IP-literal or IPv4address productions from syntactically matches the IP-literal or IPv4address productions from
Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a
Known Expect-CT Host. Known Expect-CT Host.
Otherwise, if the substring does not congruently match an existing Otherwise, if the substring does not congruently match an existing
Known Expect-CT Host's domain name, per the matching procedure Known Expect-CT Host's domain name, per the matching procedure
skipping to change at page 9, line 27 skipping to change at page 10, line 4
syntactically matches the IP-literal or IPv4address productions from syntactically matches the IP-literal or IPv4address productions from
Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a
Known Expect-CT Host. Known Expect-CT Host.
Otherwise, if the substring does not congruently match an existing Otherwise, if the substring does not congruently match an existing
Known Expect-CT Host's domain name, per the matching procedure Known Expect-CT Host's domain name, per the matching procedure
specified in Section 8.2 of [RFC6797], then the UA MUST add this host specified in Section 8.2 of [RFC6797], then the UA MUST add this host
to the Known Expect-CT Host cache. The UA caches: to the Known Expect-CT Host cache. The UA caches:
o the Expect-CT Host's domain name, o the Expect-CT Host's domain name,
o whether the "enforce" directive is present o whether the "enforce" directive is present
o the effective expiration date, or enough information to calculate o the Effective Expiration Date, which is the Effective Expect-CT
it (the effective Expect-CT date and the value of the "max-age" Date plus the value of the "max-age" directive. Alternatively,
directive), the UA MAY cache enough information to calculate the Effective
Expiration Date.
o the value of the "report-uri" directive, if present. o the value of the "report-uri" directive, if present.
If any other metadata from optional or future Expect-CT header If any other metadata from optional or future Expect-CT header
directives are present in the Expect-CT header, and the UA directives are present in the Expect-CT header, and the UA
understands them, the UA MAY note them as well. understands them, the UA MAY note them as well.
UAs MAY set an upper limit on the value of max-age, so that UAs that UAs MAY set an upper limit on the value of max-age, so that UAs that
have noted erroneous Expect-CT hosts (whether by accident or due to have noted erroneous Expect-CT hosts (whether by accident or due to
attack) have some chance of recovering over time. If the server sets attack) have some chance of recovering over time. If the server sets
a max-age greater than the UA's upper limit, the UA MAY behave as if a max-age greater than the UA's upper limit, the UA MAY behave as if
the server set the max-age to the UA's upper limit. For example, if the server set the max-age to the UA's upper limit. For example, if
the UA caps max-age at 5,184,000 seconds (60 days), and a Pinned Host the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT
sets a max- age directive of 90 days in its Expect-CT header, the UA Host sets a max- age directive of 90 days in its Expect-CT header,
MAY behave as if the max-age were effectively 60 days. (One way to the UA MAY behave as if the max-age were effectively 60 days. (One
achieve this behavior is for the UA to simply store a value of 60 way to achieve this behavior is for the UA to simply store a value of
days instead of the 90-day value provided by the Expect-CT host.) 60 days instead of the 90-day value provided by the Expect-CT host.)
2.3.3. HTTP-Equiv <meta> Element Attribute
UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
"<meta>" elements [W3C.REC-html401-19991224] in received content.
2.4. Noting Expect-CT
Upon receipt of the Expect-CT response header field, the UA notes the
host as a Known Expect-CT Host, storing the host's domain name and
its associated Expect-CT directives in non-volatile storage. The
domain name and associated Expect-CT directives are collectively
known as "Expect-CT metadata".
The UA MUST note a host as a Known Expect-CT Host if and only if it
received the Expect-CT response header field over an error-free TLS
connection, including the validation added in Section 2.5.
To note a host as a Known Expect-CT Host, the UA MUST set its Expect-
CT metadata given in the most recently received valid Expect-CT
header.
For forward compatibility, the UA MUST ignore any unrecognized
Expect-CT header directives, while still processing those directives
it does recognize. Section 2.1 specifies the directives "enforce",
"max-age", and "report-uri", but future specifications and
implementations might use additional directives.
2.5. Evaluating Expect-CT Connections for CT Compliance 2.4. Evaluating Expect-CT Connections for CT Compliance
When a UA connects to a Known Expect-CT Host using a TLS connection, When a UA connects to a Known Expect-CT Host using a TLS connection,
if the TLS connection has errors, the UA MUST terminate the if the TLS connection has errors, the UA MUST terminate the
connection without allowing the user to proceed anyway. (This connection without allowing the user to proceed anyway. (This
behavior is the same as that required by [RFC6797].) behavior is the same as that required by [RFC6797].)
If the connection has no errors, then the UA will apply an additional If the connection has no errors, then the UA will apply an additional
correctness check: compliance with a CT Policy. A UA should evaluate correctness check: compliance with a CT Policy. A UA should evaluate
compliance with its CT Policy whenever connecting to a Known Expect- compliance with its CT Policy whenever connecting to a Known Expect-
CT Host, as soon as possible. It is acceptable to skip this CT CT Host, as soon as possible. It is acceptable to skip this CT
compliance check for some hosts according to local policy. For compliance check for some hosts according to local policy. For
example, a UA may disable CT compliance checks for hosts whose example, a UA may disable CT compliance checks for hosts whose
validated certificate chain terminates at a user-defined trust validated certificate chain terminates at a user-defined trust
anchor, rather than a trust anchor built-in to the UA (or underlying anchor, rather than a trust anchor built-in to the UA (or underlying
platform). platform).
An Expect-CT Host is "expired" if the effective expiration date
refers to a date in the past. The UA MUST ignore any expired Expect-
CT Hosts in its cache and not treat such hosts as Known Expect-CT
hosts.
If a connection to a Known CT Host violates the UA's CT policy (i.e. If a connection to a Known CT Host violates the UA's CT policy (i.e.
the connection is not CT-qualified), and if the Known Expect-CT the connection is not CT-qualified), and if the Known Expect-CT
Host's Expect-CT metadata indicates an "enforce" configuration, the Host's Expect-CT metadata indicates an "enforce" configuration, the
UA MUST treat the CT compliance failure as a non-recoverable error. UA MUST treat the CT compliance failure as a non-recoverable error.
If a connection to a Known CT Host violates the UA's CT policy, and If a connection to a Known CT Host violates the UA's CT policy, and
if the Known Expect-CT Host's Expect-CT metadata includes a "report- if the Known Expect-CT Host's Expect-CT metadata includes a "report-
uri", the UA SHOULD send an Expect-CT report to that "report-uri" uri", the UA SHOULD send an Expect-CT report to that "report-uri"
(Section 3). (Section 3).
skipping to change at page 11, line 34 skipping to change at page 11, line 36
Expect-CT metadata. Expect-CT metadata.
When the UA receives an Expect-CT response header field over a When the UA receives an Expect-CT response header field over a
connection that is not CT-qualified, if the UA has not already sent connection that is not CT-qualified, if the UA has not already sent
an Expect-CT report for this connection, then the UA SHOULD report an Expect-CT report for this connection, then the UA SHOULD report
Expect-CT failures to the configured "report-uri", if any. Expect-CT failures to the configured "report-uri", if any.
3.1. Generating a violation report 3.1. Generating a violation report
To generate a violation report object, the UA constructs a JSON To generate a violation report object, the UA constructs a JSON
message of the following form: object with the following keys and values:
{
"date-time": date-time,
"hostname": hostname,
"port": port,
"effective-expiration-date": expiration-date,
"served-certificate-chain": [ (MUST be in the order served)
pem1, ... pemN
],
"validated-certificate-chain": [
pem1, ... pemN
],
"scts": [
sct1, ... sctN
]
}
Figure 4: JSON format of a violation report object
Whitespace outside of quoted strings is not significant. The key/
value pairs may appear in any order, but each MUST appear only once.
The "date-time" indicates the time the UA observed the CT compliance
failure. It is provided as a string formatted according to
Section 5.6, "Internet Date/Time Format", of [RFC3339].
The "hostname" is the hostname to which the UA made the original
request that failed the CT compliance check. It is provided as a
string.
The "port" is the port to which the UA made the original request that o "date-time": the value for this key indicates the time the UA
failed the CT compliance check. It is provided as an integer. observed the CT compliance failure. The value is a string
formatted according to Section 5.6, "Internet Date/Time Format",
of [RFC3339].
The "effective-expiration-date" is the Effective Expiration Date for o "hostname": the value is the hostname to which the UA made the
the Expect-CT Host that failed the CT compliance check. It is original request that failed the CT compliance check. The value
provided as a string formatted according to Section 5.6, "Internet is provided as a string.
Date/Time Format", of [RFC3339].
The "served-certificate-chain" is the certificate chain, as served by o "port": the value is the port to which the UA made the original
the Expect-CT Host during TLS session setup. It is provided as an request that failed the CT compliance check. The value is
array of strings, which MUST appear in the order that the provided as an integer.
certificates were served; each string "pem1", ... "pemN" is the
Privacy-Enhanced Mail (PEM) representation of each X.509 certificate
as described in [RFC7468].
The "validated-certificate-chain" is the certificate chain, as o "effective-expiration-date": the value indicates the Effective
constructed by the UA during certificate chain verification. (This Expiration Date (see Section 2.3.4) for the Expect-CT Host that
may differ from the "served-certificate-chain".) It is provided as failed the CT compliance check. The value is provided as a string
an array of strings, which MUST appear in the order matching the formatted according to Section 5.6, "Internet Date/Time Format",
chain that the UA validated; each string "pem1", ... "pemN" is the of [RFC3339].
Privacy-Enhanced Mail (PEM) representation of each X.509 certificate
as described in [RFC7468].
The "scts" are JSON messages representing the SCTs (if any) that the o "served-certificate-chain": the value is the certificate chain as
UA received for the Expect-CT host and their validation statuses. served by the Expect-CT Host during TLS session setup. The value
The format of "sct1", ... "sctN" is shown in Figure 5. The SCTs may is provided as an array of strings, which MUST appear in the order
appear in any order. that the certificates were served; each string in the array is the
Privacy-Enhanced Mail (PEM) representation of each X.509
certificate as described in [RFC7468].
{ o "validated-certificate-chain": the value is the certificate chain
"sct": sct, as constructed by the UA during certificate chain verification.
"status": status, (This may differ from the value of the "served-certificate-chain"
"source": source key.) The value is provided as an array of strings, which MUST
} appear in the order matching the chain that the UA validated; each
string in the array is the Privacy-Enhanced Mail (PEM)
representation of each X.509 certificate as described in
[RFC7468].
Figure 5: JSON format of an SCT object o "scts": the value represents the SCTs (if any) that the UA
received for the Expect-CT host and their validation statuses.
The value is provided as an array of JSON objects. The SCTs may
appear in any order. Each JSON object in the array has the
following keys:
The "sct" is as defined in Section 4.1 of RFC 6962 [RFC6962]. * The "sct" key, with a value as defined in Section 4.6 of
[I-D.ietf-trans-rfc6962-bis].
The "status" is a string that the UA MUST set to one of the following * The "status" key, with a string value that the UA MUST set to
values: "unknown" (indicating that the UA does not have or does not one of the following values: "unknown" (indicating that the UA
trust the public key of the log from which the SCT was issued), does not have or does not trust the public key of the log from
"valid" (indicating that the UA successfully validated the SCT as which the SCT was issued), "valid" (indicating that the UA
described in Section 5.2 of [RFC6962]), or "invalid" (indicating that successfully validated the SCT as described in Section 8.2.3 of
the SCT validation failed because of, e.g., a bad signature). [I-D.ietf-trans-rfc6962-bis]), or "invalid" (indicating that
the SCT validation failed because of, e.g., a bad signature).
The "source" is a string that indicates from where the UA obtained * The "source" key, with a string value that indicates from where
the SCT, as defined in Section 3.3 of [RFC6962]. The UA MUST set the UA obtained the SCT, as defined in Section 6 of
"source" to one of the following values: "tls-extension", "ocsp", or [I-D.ietf-trans-rfc6962-bis]. The UA MUST set the value to one
"embedded". of "tls-extension", "ocsp", or "embedded".
3.2. Sending a violation report 3.2. Sending a violation report
When an Expect-CT header field contains the "report-uri" directive, The UA SHOULD report an Expect-CT failure when a connection to a
and the connection does not comply with the UA's CT Policy, or when Known Expect-CT Host does not comply with the UA's CT Policy and the
the UA connects to a Known Expect-CT Host with Expect-CT metadata host's Expect-CT metadata contains a "report-uri". Additionally, the
that contains a "report-uri", the UA SHOULD report the failure as UA SHOULD report an Expect-CT failure when it receives an Expect-CT
follows: header field which contains the "report-uri" directive over a
connection that does not comply with the UA's CT Policy.
The steps to report an Expect-CT failure are as follows.
1. Prepare a JSON object "report object" with the single key 1. Prepare a JSON object "report object" with the single key
"expect-ct-report", whose value is the result of generating a "expect-ct-report", whose value is the result of generating a
violation report object as described in Figure 4. violation report object as described in Section 3.1.
2. Let "report body" by the JSON stringification of "report object". 2. Let "report body" by the JSON stringification of "report object".
3. Let "report-uri" be the value of the "report-uri" directive in 3. Let "report-uri" be the value of the "report-uri" directive in
the Expect-CT header field. the Expect-CT header field.
4. Queue a task [4] to fetch [5] "report-uri", with the synchronous 4. Send an HTTP POST request to "report-uri" with a "Content-Type"
flag not set, using HTTP method "POST", with a "Content-Type" header field of "application/expect-ct-report+json", and an
header field of "application/expect-ct-report", and an entity entity body consisting of "report body".
body consisting of "report body".
The UA MAY perform other operations as part of sending the HTTP POST
request, for example sending a CORS preflight as part of [FETCH].
4. Security Considerations 4. Security Considerations
When UAs support the Expect-CT header, it becomes a potential vector When UAs support the Expect-CT header, it becomes a potential vector
for hostile header attacks against site owners. If a site owner uses for hostile header attacks against site owners. If a site owner uses
a certificate issued by a certificate authority which does not embed a certificate issued by a certificate authority which does not embed
SCTs nor serve SCTs via OCSP or TLS extension, a malicious server SCTs nor serve SCTs via OCSP or TLS extension, a malicious server
operator or attacker could temporarily reconfigure the host to comply operator or attacker could temporarily reconfigure the host to comply
with the UA's CT policy, and add the Expect-CT header in enforcing with the UA's CT policy, and add the Expect-CT header in enforcing
mode with a long "max-age". Implementing user agents would note this mode with a long "max-age". Implementing user agents would note this
as an Expect-CT Host (see Section 2.4). After having done this, the as an Expect-CT Host (see Section 2.3.3). After having done this,
configuration could then be reverted to not comply with the CT the configuration could then be reverted to not comply with the CT
policy, prompting failures. Note this scenario would require the policy, prompting failures. Note this scenario would require the
attacker to have substantial control over the infrastructure in attacker to have substantial control over the infrastructure in
question, being able to obtain different certificates, change server question, being able to obtain different certificates, change server
software, or act as a man-in-the-middle in connections. software, or act as a man-in-the-middle in connections.
Site operators could themselves only cure this situation by one of: Site operators could themselves only cure this situation by one of:
reconfiguring their web server to transmit SCTs using the TLS reconfiguring their web server to transmit SCTs using the TLS
extension defined in Section 3.3 of [RFC6962], obtaining a extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis],
certificate from an alternative certificate authority which provides obtaining a certificate from an alternative certificate authority
SCTs by one of the other methods, or by waiting for the user agents' which provides SCTs by one of the other methods, or by waiting for
persisted notation of this as an Expect-CT host to reach its "max- the user agents' persisted notation of this as an Expect-CT host to
age". User agents may choose to implement mechanisms for users to reach its "max-age". User agents may choose to implement mechanisms
cure this situation, as noted in Section 7. for users to cure this situation, as noted in Section 7.
4.1. Maximum max-age 4.1. Maximum max-age
There is a security trade-off in that low maximum values provide a There is a security trade-off in that low maximum values provide a
narrow window of protection for users that visit the Known Expect-CT narrow window of protection for users that visit the Known Expect-CT
Host only infrequently, while high maximum values might result in a Host only infrequently, while high maximum values might result in a
denial of service to a UA in the event of a hostile header attack, or denial of service to a UA in the event of a hostile header attack, or
simply an error on the part of the site-owner. simply an error on the part of the site-owner.
There is probably no ideal maximum for the "max-age" directive. There is probably no ideal maximum for the "max-age" directive.
skipping to change at page 16, line 11 skipping to change at page 15, line 27
6. IANA Considerations 6. IANA Considerations
TBD TBD
7. Usability Considerations 7. Usability Considerations
When the UA detects a Known Expect-CT Host in violation of the UA's When the UA detects a Known Expect-CT Host in violation of the UA's
CT Policy, users will experience denials of service. It is advisable CT Policy, users will experience denials of service. It is advisable
for UAs to explain the reason why. for UAs to explain the reason why.
8. References 8. Authoring Considerations
8.1. Normative References 8.1. HTTP Header
Expect-CT could be specified as a TLS extension or X.509 certificate
extension instead of an HTTP response header. Using an HTTP header
as the mechanism for Expect-CT introduces a layering mismatch: for
example, the software that terminates TLS and validates Certificate
Transparency information might know nothing about HTTP.
Nevertheless, an HTTP header was chosen primarily for ease of
deployment. In practice, deploying new certificate extensions
requires certificate authorities to support them, and new TLS
extensions require server software updates, including possibly to
servers outside of the site owner's direct control (such as in the
case of a third-party CDN). Ease of deployment is a high priority
for Expect-CT because it is intended as a temporary transition
mechanism for user agents that are transitioning to universal
Certificate Transparency requirements.
9. Changes
9.1. Since -00
o Editorial changes
o Change Content-Type header of reports to 'application/expect-ct-
report+json'
o Update header field syntax to match convention (issue #327)
o Reference RFC 6962-bis instead of RFC 6962
10. Normative References
[FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt,
P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>.
[I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency Version 2.0", draft-
ietf-trans-rfc6962-bis-24 (work in progress), December
2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <http://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 16, line 50 skipping to change at page 17, line 10
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>. <http://www.rfc-editor.org/info/rfc6797>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <http://www.rfc-editor.org/info/rfc7468>. April 2015, <http://www.rfc-editor.org/info/rfc7468>.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
8.2. URIs
[1] https://html.spec.whatwg.org/#queue-a-task
[2] https://fetch.spec.whatwg.org/#fetching
Author's Address Author's Address
Emily Stark Emily Stark
Google Google
Email: estark@google.com Email: estark@google.com
 End of changes. 48 change blocks. 
182 lines changed or deleted 201 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/