| Network Working Group | E. Stark |
| Internet-Draft | |
| Intended status: Experimental | December 01, 2016 |
| Expires: June 4, 2017 |
Expect-CT Extension for HTTP
draft-stark-expect-ct-01
This document defines a new HTTP header, named Expect-CT, that allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. When configured in enforcement mode, user agents (UAs) will remember that hosts expect SCTs and will refuse connections that do not conform to the UA’s Certificate Transparency policy. When configured in report-only mode, UAs will report the lack of valid SCTs to a URI configured by the host, but will allow the connection. By turning on Expect-CT, web host operators can discover misconfigurations in their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2017.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document defines a new HTTP header that enables UAs to identify web hosts that expect the presence of Signed Certificate Timestamps (SCTs) [RFC6962] in future Transport Layer Security (TLS) [RFC5246] connections.
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 Expect-CT Host for compliance with the UA’s Certificate Transparency (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 connection, depending on the configuration that the Expect-CT Host has chosen.
If misconfigured, Expect-CT can cause unwanted connection failures (for example, if a host deploys Expect-CT but then switches to a legitimate certificate that is not logged in Certificate Transparency logs, or if a web host operator believes their certificate to conform to all UAs’ CT policies but is mistaken). Web host operators are advised to deploy Expect-CT with caution, by using the reporting feature and gradually increasing the interval where the UA remembers the host as a Known Expect-CT Host. These precautions can help web host operators gain confidence that their Expect-CT deployment is not causing unwanted connection failures.
Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to require SCTs for the connection. Thus, the UA will not be able to detect and thwart an attack on the UA’s first connection to the host. Still, Expect-CT provides value by 1) allowing UAs to detect the use of unlogged certificates after the initial communication, and 2) allowing web hosts to be confident that UAs are only trusting publicly-auditable certificates.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119].
Terminology is defined in this section.
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 evaluate connections to the host emitting the header for CT compliance (Section 2.5).
Figure 1 describes the syntax (Augmented Backus-Naur Form) of the header field, using the grammar defined in RFC 5234 [RFC5234] and the rules defined in Section 3.2 of RFC 7230 [RFC7230].
Expect-CT-Directives = directive *( OWS ";" OWS directive ) directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token / quoted-string
Figure 1: Syntax of the Expect-CT header field
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 in Section 3.2.6 of RFC 7230 [RFC7230].
The directives defined in this specification are described below. The overall requirements for directives are:
The OPTIONAL report-uri directive indicates the URI to which the UA SHOULD report Expect-CT failures (Section 2.5). The UA POSTs the reports to the given URI as described in Section 3.
The report-uri directive is REQUIRED to have a directive value, for which the syntax is defined in Figure 2.
report-uri-value = absolute-URI
Figure 2: Syntax of the report-uri directive value
absolute-URI is defined in Section 4.3 of RFC 3986 [RFC3986].
Hosts may set report-uris that use HTTP or HTTPS. If the scheme in the report-uri is one that uses TLS (e.g., HTTPS), UAs MUST check Expect-CT compliance when the host in the report-uri is a Known Expect-CT Host; similarly, UAs MUST apply HSTS if the host in the report-uri is a Known HSTS Host.
Note that the report-uri need not necessarily be in the same Internet domain or web origin as the host being reported about.
UAs SHOULD make their best effort to report Expect-CT failures to the report-uri, but they may fail to report in exceptional conditions. For example, if connecting the report-uri itself incurs an Expect-CT failure or other certificate validation failure, the UA MUST cancel the connection. Similarly, if Expect-CT Host A sets a report-uri referring to Expect-CT Host B, and if B sets a report-uri referring to A, and if both hosts fail to comply to the UA’s CT Policy, the UA SHOULD detect and break the loop by failing to send reports to and about those hosts.
UAs SHOULD limit the rate at which they send reports. For example, it is unnecessary to send the same report to the same report-uri more than once.
The OPTIONAL enforce directive is a valueless directive that, if present (i.e., it is “asserted”), signals to the UA that compliance to the CT Policy should be enforced (rather than report-only) and that the UA should refuse future connections that violate its CT Policy. When both the enforce directive and report-uri directive (as defined in Figure 2) are present, the configuration is referred to as an “enforce-and-report” configuration, signalling to the UA both that compliance to the CT Policy should be enforced and that violations should be reported.
The max-age directive specifies the number of seconds after the reception of the Expect-CT header field during which the UA SHOULD regard the host from whom the message was received as a Known Expect-CT Host.
The max-age directive is REQUIRED to be present within an “Expect-CT” header field. The max-age directive is REQUIRED to have a directive value, for which the syntax (after quoted-string unescaping, if necessary) is defined in Figure 3.
max-age-value = delta-seconds delta-seconds = 1*DIGIT
Figure 3: Syntax of the max-age directive value
delta-seconds is used as defined in Section 1.2.1 of RFC 7234 [RFC7234].
This section describes the processing model that Expect-CT Hosts implement. The model has 2 parts: (1) the processing rules for HTTP request messages received over a secure transport (e.g., authenticated, non-anonymous TLS); and (2) the processing rules for HTTP request messages received over non-secure transports, such as TCP.
When replying to an HTTP request that was conveyed over a secure transport, an Expect-CT Host SHOULD include in its response exactly one Expect-CT header field. The header field MUST satisfy the grammar specified in Section 2.1.
Establishing a given host as an Expect-CT Host, in the context of a given UA, is accomplished as follows:
Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP responses conveyed over non-secure transport. UAs MUST ignore any Expect-CT header received in an HTTP response conveyed over non-secure transport.
The UA processing model relies on parsing domain names. Note that internationalized domain names SHALL be canonicalized according to the scheme in Section 10 of [RFC6797].
If the UA receives, over a secure transport, an HTTP response that includes an Expect-CT header field conforming to the grammar 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, and then process the Expect-CT header field as follows.
If the connection complies with the UA’s CT Policy (i.e. the connection is CT-qualified), then the UA MUST either:
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 Expect-CT Host.
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 is not CT-qualified), and the UA has not already sent an Expect-CT report for this connection, then the UA SHOULD send a 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 grammar specified in Section 2.1.
The “effective Expect-CT date” of a Known Expect-CT Host is the time that the UA observed a valid Expect-CT header for the host. The “effective expiration date” of a Known Expect-CT Host is the effective Expect-CT date plus the max-age. 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.
Known Expect-CT Hosts are identified only by domain names, and never IP addresses. If the substring matching the host production from the Request-URI (of the message to which the host responded) 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 Known Expect-CT Host.
Otherwise, if the substring does not congruently match an existing 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 to the Known Expect-CT Host cache. The UA caches:
If any other metadata from optional or future Expect-CT header directives are present in the Expect-CT header, and the UA 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 have noted erroneous Expect-CT hosts (whether by accident or due to 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 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 sets a max- age directive of 90 days in its Expect-CT header, the UA MAY behave as if the max-age were effectively 60 days. (One way to achieve this behavior is for the UA to simply store a value of 60 days instead of the 90-day value provided by the Expect-CT host.)
UAs MUST NOT heed http-equiv="Expect-CT" attribute settings on <meta> elements [W3C.REC-html401-19991224] in received content.
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.
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 connection without allowing the user to proceed anyway. (This behavior is the same as that required by [RFC6797].)
If the connection has no errors, then the UA will apply an additional correctness check: compliance with a CT Policy. A UA should evaluate compliance with its CT Policy whenever connecting to a Known Expect-CT Host, as soon as possible. It is acceptable to skip this CT compliance check for some hosts according to local policy. For example, a UA may disable CT compliance checks for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform).
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 Host’s Expect-CT metadata indicates an enforce configuration, the 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 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 (Section 3).
A UA that has previously noted a host as a Known Expect-CT Host MUST evaluate CT compliance when setting up the TLS session, before beginning an HTTP conversation over the TLS channel.
If the UA does not evaluate CT compliance, e.g. because the user has elected to disable it, or because a presented certificate chain chains up to a user-defined trust anchor, UAs SHOULD NOT send Expect-CT reports.
When the UA attempts to connect to a Known Expect-CT Host and the connection is not CT-qualified, the UA SHOULD report Expect-CT failures to the report-uri, if any, in the Known Expect-CT Host’s Expect-CT metadata.
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 an Expect-CT report for this connection, then the UA SHOULD report Expect-CT failures to the configured report-uri, if any.
To generate a violation report object, the UA constructs a JSON message of the following form:
{
"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 RFC 3339 [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 failed the CT compliance check. It is provided as an integer.
The effective-expiration-date is the Effective Expiration Date for the Expect-CT Host that failed the CT compliance check. It is provided as a string formatted according to Section 5.6, “Internet Date/Time Format”, of RFC 3339 [RFC3339].
The served-certificate-chain is the certificate chain, as served by the Expect-CT Host during TLS session setup. It is provided as an array of strings, which MUST appear in the order that the certificates were served; each string pem1, … pemN is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in RFC 7468 [RFC7468].
The validated-certificate-chain is the certificate chain, as constructed by the UA during certificate chain verification. (This may differ from the served-certificate-chain.) It is provided as an array of strings, which MUST appear in the order matching the chain that the UA validated; each string pem1, … pemN is the Privacy-Enhanced Mail (PEM) representation of each X.509 certificate as described in RFC 7468 [RFC7468].
The scts are JSON messages representing the SCTs (if any) that the UA received for the Expect-CT host and their validation statuses. The format of sct1, … sctN is shown in Figure 5. The SCTs may appear in any order.
{
"sct": sct,
"status": status,
"source": source
}
Figure 5: JSON format of an SCT object
The sct is as defined in Section 4.1 of RFC 6962 [RFC6962].
The status is a string that the UA MUST set to one of the following values: “unknown” (indicating that the UA does not have or does not trust the public key of the log from which the SCT was issued), “valid” (indicating that the UA successfully validated the SCT as described in Section 5.2 of [RFC6962]), 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 SCT, as defined in Section 3.3 of RFC 6962 [RFC6962]. The UA MUST set source to one of the following values: “tls-extension”, “ocsp”, or “embedded”.
When an Expect-CT header field contains the report-uri directive, and the connection does not comply with the UA’s CT Policy, or when the UA connects to a Known Expect-CT Host with Expect-CT metadata that contains a report-uri, the UA SHOULD report the failure as follows:
1 year?
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 for UAs to explain the reason why.
It is advisable that UAs have a way for users to clear Known Expect-CT Hosts and that UAs allow users to query Known Expect-CT Hosts.