draft-ietf-httpbis-expect-ct-03.txt   draft-ietf-httpbis-expect-ct-04.txt 
HTTP E. Stark HTTP E. Stark
Internet-Draft Google Internet-Draft Google
Intended status: Experimental February 26, 2018 Intended status: Experimental May 19, 2018
Expires: August 30, 2018 Expires: November 20, 2018
Expect-CT Extension for HTTP Expect-CT Extension for HTTP
draft-ietf-httpbis-expect-ct-03 draft-ietf-httpbis-expect-ct-04
Abstract Abstract
This document defines a new HTTP header, named Expect-CT, that allows This document defines a new HTTP header field, named Expect-CT, that
web host operators to instruct user agents to expect valid Signed allows web host operators to instruct user agents to expect valid
Certificate Timestamps (SCTs) to be served on connections to these Signed Certificate Timestamps (SCTs) to be served on connections to
hosts. When configured in enforcement mode, user agents (UAs) will these hosts. When configured in enforcement mode, user agents (UAs)
remember that hosts expect SCTs and will refuse connections that do will remember that hosts expect SCTs and will refuse connections that
not conform to the UA's Certificate Transparency policy. When do 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
SCTs to a URI configured by the host, but will allow the connection. SCTs to a URI configured by the host, but will allow the connection.
By turning on Expect-CT, web host operators can discover By turning on Expect-CT, web host operators can discover
misconfigurations in their Certificate Transparency deployments and misconfigurations in their Certificate Transparency deployments and
ensure that misissued certificates accepted by UAs are discoverable ensure that misissued certificates accepted by UAs are discoverable
in Certificate Transparency logs. in Certificate Transparency logs.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 30, 2018. This Internet-Draft will expire on November 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 5 skipping to change at page 3, line 5
3.2. Sending a violation report . . . . . . . . . . . . . . . 13 3.2. Sending a violation report . . . . . . . . . . . . . . . 13
3.3. Receiving a violation report . . . . . . . . . . . . . . 14 3.3. Receiving a violation report . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15
4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15 4.2. Avoiding amplification attacks . . . . . . . . . . . . . 15
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Usability Considerations . . . . . . . . . . . . . . . . . . 16 7. Usability Considerations . . . . . . . . . . . . . . . . . . 16
8. Authoring Considerations . . . . . . . . . . . . . . . . . . 16 8. Authoring Considerations . . . . . . . . . . . . . . . . . . 16
8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. HTTP Header . . . . . . . . . . . . . . . . . . . . . . . 16
9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
9.3. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 17 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 A.1. Since -03 . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 18
A.4. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines a new HTTP header that enables UAs to identify This document defines a new HTTP header field that enables UAs to
web hosts that expect the presence of Signed Certificate Timestamps identify web hosts that expect the presence of Signed Certificate
(SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport Layer Timestamps (SCTs) [I-D.ietf-trans-rfc6962-bis] in future Transport
Security (TLS) [RFC5246] connections. Layer 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 field are noted by the
Known Expect-CT Hosts. The UA evaluates each connection to a Known UA as Known Expect-CT Hosts. The UA evaluates each connection to a
Expect-CT Host for compliance with the UA's Certificate Transparency Known Expect-CT Host for compliance with the UA's Certificate
(CT) Policy. If the connection violates the CT Policy, the UA sends Transparency (CT) Policy. If the connection violates the CT Policy,
a report to a URI configured by the Expect-CT Host and/or fails the the UA sends a report to a URI configured by the Expect-CT Host and/
connection, depending on the configuration that the Expect-CT Host or fails the connection, depending on the configuration that the
has chosen. Expect-CT Host has chosen.
If misconfigured, Expect-CT can cause unwanted connection failures If misconfigured, Expect-CT can cause unwanted connection failures
(for example, if a host deploys Expect-CT but then switches to a (for example, if a host deploys Expect-CT but then switches to a
legitimate certificate that is not logged in Certificate Transparency legitimate certificate that is not logged in Certificate Transparency
logs, or if a web host operator believes their certificate to conform logs, or if a web host operator believes their certificate to conform
to all UAs' CT policies but is mistaken). Web host operators are to all UAs' CT policies but is mistaken). Web host operators are
advised to deploy Expect-CT with caution, by using the reporting advised to deploy Expect-CT with caution, by using the reporting
feature and gradually increasing the interval where the UA remembers feature and gradually increasing the interval where the UA remembers
the host as a Known Expect-CT Host. These precautions can help web the host as a Known Expect-CT Host. These precautions can help web
host operators gain confidence that their Expect-CT deployment is not host operators gain confidence that their Expect-CT deployment is not
skipping to change at page 4, line 16 skipping to change at page 4, line 16
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
Terminology is defined in this section. Terminology is defined in this section.
Certificate Transparency Policy is a policy defined by the UA o "Certificate Transparency Policy" is a policy defined by the UA
concerning the number, sources, and delivery mechanisms of Signed concerning the number, sources, and delivery mechanisms of Signed
Certificate Timestamps that are served on TLS connections. The Certificate Timestamps that are served on TLS connections. The
policy defines the properties of a connection that must be met in policy defines the properties of a connection that must be met in
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 o "Certificate Transparency Qualified" describes a TLS connection
which the UA has determined that a sufficient quantity and quality for which the UA has determined that a sufficient quantity and
of Signed Certificate Timestamps have been provided. quality of Signed Certificate Timestamps have been provided.
CT-qualified See Certificate Transparency Qualified.
CT Policy See Certificate Transparency Policy.
Effective Expect-CT Date is the time at which a UA observed a valid o "CT-qualified" is an abbreviation for "Certificate Transparency
Expect-CT header for a given host. Qualified".
Expect-CT Host See HTTP Expect-CT Host. o "CT Policy" is an abbreviation for "Certificate Transparency
Policy".
HTTP Expect-CT is the overall name for the combined UA- and server- o "Effective Expect-CT Date" is the time at which a UA observed a
side security policy defined by this specification. valid Expect-CT header field for a given host.
HTTP Expect-CT Host is a conformant host implementing the HTTP o "Expect-CT Host" is a conformant host implementing the HTTP server
server aspects of HTTP Expect-CT. This means that an Expect-CT aspects of Expect-CT. This means that an Expect-CT Host returns
Host returns the "Expect-CT" HTTP response header field in its the "Expect-CT" HTTP response header field in its HTTP response
HTTP response messages sent over secure transport. messages sent over secure transport.
Known Expect-CT Host is an Expect-CT Host that the UA has noted as o "Known Expect-CT Host" is an Expect-CT Host that the UA has noted
such. See Section 2.3.3 for particulars. as such. See Section 2.3.3 for particulars.
UA is an acronym for "user agent". For the purposes of this o 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 [RFC7230]. actively manipulated by a user [RFC7230].
Unknown Expect-CT Host is an Expect-CT Host that the UA has not o "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" response header field is a new field 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 field for CT
compliance (Section 2.4). 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 [RFC5234] and the rules header field, using the grammar defined in [RFC5234] and the rules
defined in Section 3.2 of [RFC7230]. defined in Section 3.2 of [RFC7230].
Expect-CT = #expect-ct-directive Expect-CT = #expect-ct-directive
expect-ct-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
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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 [RFC7234]. "delta-seconds" is used as defined in Section 1.2.1 of [RFC7234].
2.1.4. Examples 2.1.4. Examples
The following examples demonstrate valid Expect-CT response header The following examples demonstrate valid Expect-CT response header
fields: fields:
Expect-CT: max-age=86400,enforce Expect-CT: max-age=86400, enforce
Expect-CT: max-age=86400, enforce, report-uri="https://foo.example/report" Expect-CT: max-age=86400,enforce,report-uri="https://foo.example/report"
Expect-CT: max-age=86400,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 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.,
skipping to change at page 8, line 26 skipping to change at page 8, line 26
correctly returning (per this specification) at least one valid correctly returning (per this specification) at least one valid
Expect-CT header field to the UA. Expect-CT header field to the UA.
2. Through other mechanisms, such as a client-side preloaded Expect- 2. Through other mechanisms, such as a client-side preloaded Expect-
CT Host list. CT Host list.
2.2.2. HTTP Request Type 2.2.2. HTTP Request Type
Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP Expect-CT Hosts SHOULD NOT include the Expect-CT header field in HTTP
responses conveyed over non-secure transport. UAs MUST ignore any responses conveyed over non-secure transport. UAs MUST ignore any
Expect-CT header received in an HTTP response conveyed over non- Expect-CT header field received in an HTTP response conveyed over
secure transport. non-secure transport.
2.3. User Agent Processing Model 2.3. User Agent Processing Model
The UA processing model relies on parsing domain names. Note that The UA processing model relies on parsing domain names. Note that
internationalized domain names SHALL be canonicalized according to internationalized domain names SHALL be canonicalized according to
the scheme in Section 10 of [RFC6797]. the scheme in Section 10 of [RFC6797].
2.3.1. Expect-CT Header Field Processing 2.3.1. Expect-CT Header Field Processing
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 field was received for compliance with the UA's CT
and then process the Expect-CT header field as follows. Policy, 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.3.3), 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
skipping to change at page 9, line 24 skipping to change at page 9, line 24
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.
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. HTTP-Equiv <meta> Element Attribute 2.3.2. HTTP-Equiv <meta> Element Attribute
UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on UAs MUST NOT heed "http-equiv="Expect-CT"" attribute settings on
"<meta>" elements [W3C.REC-html51-20161101] in received content. "<meta>" elements [HTML] [HTML5] in received content.
2.3.3. Noting Expect-CT 2.3.3. Noting Expect-CT
Upon receipt of the Expect-CT response header field over an error- Upon receipt of the Expect-CT response header field over an error-
free TLS connection (including the validation adding in Section 2.4), 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 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- host's domain name and its associated Expect-CT directives in non-
volatile storage. The domain name and associated Expect-CT volatile storage. The domain name and associated Expect-CT
directives are collectively known as "Expect-CT metadata". directives are collectively known as "Expect-CT metadata".
To note a host as a Known Expect-CT Host, the UA MUST set its Expect- 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 CT metadata given in the most recently received valid Expect-CT
header, as specified in Section 2.3.4. header field, as specified in Section 2.3.4.
For forward compatibility, the UA MUST ignore any unrecognized For forward compatibility, the UA MUST ignore any unrecognized
Expect-CT header directives, while still processing those directives Expect-CT header field directives, while still processing those
it does recognize. Section 2.1 specifies the directives "enforce", directives it does recognize. Section 2.1 specifies the directives
"max-age", and "report-uri", but future specifications and "enforce", "max-age", and "report-uri", but future specifications and
implementations might use additional directives. implementations might use additional directives.
2.3.4. Storage Model 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.
skipping to change at page 10, line 24 skipping to change at page 10, line 24
o whether the "enforce" directive is present o whether the "enforce" directive is present
o the Effective Expiration Date, which is the Effective Expect-CT o the Effective Expiration Date, which is the Effective Expect-CT
Date plus the value of the "max-age" directive. Alternatively, Date plus the value of the "max-age" directive. Alternatively,
the UA MAY cache enough information to calculate the Effective the UA MAY cache enough information to calculate the Effective
Expiration Date. 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 field, 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 an Expect-CT the UA caps max-age at 5,184,000 seconds (60 days), and an Expect-CT
Host sets a max- age directive of 90 days in its Expect-CT header, 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 field, the UA MAY behave as if the max-age were effectively 60 days.
way to achieve this behavior is for the UA to simply store a value of (One way to achieve this behavior is for the UA to simply store a
60 days instead of the 90-day value provided by the Expect-CT host.) value of 60 days instead of the 90-day value provided by the Expect-
CT host.)
2.4. 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
skipping to change at page 14, line 28 skipping to change at page 14, line 31
or the report server does not expect to receive reports for the or the report server does not expect to receive reports for the
hostname in the "hostname" field, the report server MUST respond with hostname in the "hostname" field, the report server MUST respond with
a 4xx (Client Error) status code. a 4xx (Client Error) status code.
If the report's "test-report" key is set to true, the server MAY If the report's "test-report" key is set to true, the server MAY
discard the report without further processing but MUST still return a discard the report without further processing but MUST still return a
2xx (Successful) status code. 2xx (Successful) status code.
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 field, it becomes a potential
for hostile header attacks against site owners. If a site owner uses vector for hostile header attacks against site owners. If a site
a certificate issued by a certificate authority which does not embed owner uses a certificate issued by a certificate authority which does
SCTs nor serve SCTs via OCSP or TLS extension, a malicious server not embed SCTs nor serve SCTs via OCSP or TLS extension, a malicious
operator or attacker could temporarily reconfigure the host to comply server operator or attacker could temporarily reconfigure the host to
with the UA's CT policy, and add the Expect-CT header in enforcing comply with the UA's CT policy, and add the Expect-CT header field in
mode with a long "max-age". Implementing user agents would note this enforcing mode with a long "max-age". Implementing user agents would
as an Expect-CT Host (see Section 2.3.3). After having done this, note this as an Expect-CT Host (see Section 2.3.3). After having
the configuration could then be reverted to not comply with the CT done this, the configuration could then be reverted to not comply
policy, prompting failures. Note this scenario would require the with the CT policy, prompting failures. Note this scenario would
attacker to have substantial control over the infrastructure in require the attacker to have substantial control over the
question, being able to obtain different certificates, change server infrastructure in question, being able to obtain different
software, or act as a man-in-the-middle in connections. certificates, change server 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 6.5 of [I-D.ietf-trans-rfc6962-bis], extension defined in Section 6.5 of [I-D.ietf-trans-rfc6962-bis],
obtaining a certificate from an alternative certificate authority obtaining a certificate from an alternative certificate authority
which provides SCTs by one of the other methods, or by waiting for which provides SCTs by one of the other methods, or by waiting for
the user agents' persisted notation of this as an Expect-CT host to the user agents' persisted notation of this as an Expect-CT host to
reach its "max-age". User agents may choose to implement mechanisms reach its "max-age". User agents may choose to implement mechanisms
for users to cure this situation, as noted in Section 7. for users to cure this situation, as noted in Section 7.
skipping to change at page 15, line 24 skipping to change at page 15, line 26
Since Expect-CT is primarily a policy-expansion and investigation Since Expect-CT is primarily a policy-expansion and investigation
technology rather than an end-user protection, a value on the order technology rather than an end-user protection, a value on the order
of 30 days (2,592,000 seconds) may be considered a balance between of 30 days (2,592,000 seconds) may be considered a balance between
these competing security concerns. these competing security concerns.
4.2. Avoiding amplification attacks 4.2. Avoiding amplification attacks
Another kind of hostile header attack uses the "report-uri" mechanism Another kind of hostile header attack uses the "report-uri" mechanism
on many hosts not currently exposing SCTs as a method to cause a on many hosts not currently exposing SCTs as a method to cause a
denial-of-service to the host receiving the reports. If some highly- denial-of-service to the host receiving the reports. If some highly-
trafficked websites emitted a non-enforcing Expect-CT header with a trafficked websites emitted a non-enforcing Expect-CT header field
"report-uri", implementing UAs' reports could flood the reporting with a "report-uri", implementing UAs' reports could flood the
host. It is noted in Section 2.1.1 that UAs should limit the rate at reporting host. It is noted in Section 2.1.1 that UAs should limit
which they emit reports, but an attacker may alter the Expect-CT the rate at which they emit reports, but an attacker may alter the
header's fields to induce UAs to submit different reports to Expect-CT header's fields to induce UAs to submit different reports
different URIs to still cause the same effect. to different URIs to still cause the same effect.
5. Privacy Considerations 5. Privacy Considerations
Expect-CT can be used to infer what Certificate Transparency policy Expect-CT can be used to infer what Certificate Transparency policy
is in use, by attempting to retrieve specially-configured websites is in use, by attempting to retrieve specially-configured websites
which pass one user agents' policies but not another's. Note that which pass one user agents' policies but not another's. Note that
this consideration is true of UAs which enforce CT policies without this consideration is true of UAs which enforce CT policies without
Expect-CT as well. Expect-CT as well.
Additionally, reports submitted to the "report-uri" could reveal Additionally, reports submitted to the "report-uri" could reveal
skipping to change at page 16, line 27 skipping to change at page 16, line 29
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. Authoring Considerations 8. Authoring Considerations
8.1. HTTP Header 8.1. HTTP Header
Expect-CT could be specified as a TLS extension or X.509 certificate Expect-CT could be specified as a TLS extension or X.509 certificate
extension instead of an HTTP response header. Using an HTTP header extension instead of an HTTP response header field. Using an HTTP
as the mechanism for Expect-CT introduces a layering mismatch: for header field as the mechanism for Expect-CT introduces a layering
example, the software that terminates TLS and validates Certificate mismatch: for example, the software that terminates TLS and validates
Transparency information might know nothing about HTTP. Certificate Transparency information might know nothing about HTTP.
Nevertheless, an HTTP header was chosen primarily for ease of Nevertheless, an HTTP header field was chosen primarily for ease of
deployment. In practice, deploying new certificate extensions deployment. In practice, deploying new certificate extensions
requires certificate authorities to support them, and new TLS requires certificate authorities to support them, and new TLS
extensions require server software updates, including possibly to extensions require server software updates, including possibly to
servers outside of the site owner's direct control (such as in the 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 case of a third-party CDN). Ease of deployment is a high priority
for Expect-CT because it is intended as a temporary transition for Expect-CT because it is intended as a temporary transition
mechanism for user agents that are transitioning to universal mechanism for user agents that are transitioning to universal
Certificate Transparency requirements. Certificate Transparency requirements.
9. Changes 9. References
9.1. Since -02
o Add concept of test reports and specify that servers must respond
with 2xx status codes to valid reports.
o Add "failure-mode" key to reports to allow report servers to
distinguish report-only from enforced failures.
9.2. Since -01
o Change SCT reporting format to support both RFC 6962 and 6962-bis
SCTs.
9.3. 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. References
10.1. Normative References
[FETCH] van Kesteren, A., "Fetch", n.d.,
<https://fetch.spec.whatwg.org/>.
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, 9.1. Normative References
P., and D. Denicola, "HTML", n.d.,
<https://html.spec.whatwg.org/>.
[I-D.ietf-trans-rfc6962-bis] [I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency Version 2.0", draft- Stradling, "Certificate Transparency Version 2.0", draft-
ietf-trans-rfc6962-bis-27 (work in progress), October ietf-trans-rfc6962-bis-27 (work in progress), October
2017. 2017.
[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,
skipping to change at page 18, line 14 skipping to change at page 17, line 28
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://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,
<https://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://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
skipping to change at page 18, line 42 skipping to change at page 18, line 5
[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,
<https://www.rfc-editor.org/info/rfc7234>. <https://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, <https://www.rfc-editor.org/info/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[W3C.REC-html51-20161101] 9.2. Informative References
Faulkner, S., Eicholz, A., Leithead, T., and A. Danilo,
"HTML 5.1", World Wide Web Consortium Recommendation REC-
html51-20161101, November 2016,
<https://www.w3.org/TR/2016/REC-html51-20161101>.
10.2. URIs [FETCH] WHATWG, "Fetch - Living Standard", n.d.,
<https://fetch.spec.whatwg.org>.
[HTML] WHATWG, "HTML - Living Standard", n.d.,
<https://html.spec.whatwg.org>.
[HTML5] Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and
S. Moon, "HTML 5.2", World Wide Web Consortium
Recommendation REC-html52-20171214, December 2017,
<https://www.w3.org/TR/2017/REC-html52-20171214>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
9.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/expect-ct [3] https://github.com/httpwg/http-extensions/labels/expect-ct
Appendix A. Changes
A.1. Since -03
o Editorial changes
A.2. Since -02
o Add concept of test reports and specify that servers must respond
with 2xx status codes to valid reports.
o Add "failure-mode" key to reports to allow report servers to
distinguish report-only from enforced failures.
A.3. Since -01
o Change SCT reporting format to support both RFC 6962 and 6962-bis
SCTs.
A.4. 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
Author's Address Author's Address
Emily Stark Emily Stark
Google Google
Email: estark@google.com Email: estark@google.com
 End of changes. 36 change blocks. 
137 lines changed or deleted 142 lines changed or added

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