draft-ietf-trans-gossip-00.txt | draft-ietf-trans-gossip-01.txt | |||
---|---|---|---|---|
TRANS L. Nordberg | TRANS L. Nordberg | |||
Internet-Draft NORDUnet | Internet-Draft NORDUnet | |||
Intended status: Experimental D. Gillmor | Intended status: Experimental D. Gillmor | |||
Expires: February 29, 2016 ACLU | Expires: April 22, 2016 ACLU | |||
T. Ritter | T. Ritter | |||
August 28, 2015 | October 20, 2015 | |||
Gossiping in CT | Gossiping in CT | |||
draft-ietf-trans-gossip-00 | draft-ietf-trans-gossip-01 | |||
Abstract | Abstract | |||
This document describes three gossiping mechanisms for Certificate | The logs in Certificate Transparency are untrusted in the sense that | |||
Transparency (CT) [RFC6962]: SCT Feedback, STH Pollination and | the users of the system don't have to trust that they behave | |||
Trusted Auditor Relationship. | correctly since the behaviour of a log can be verified to be correct. | |||
SCT Feedback enables HTTPS clients to share Signed Certificate | ||||
Timestamps (SCTs) (Section 3.2 of [RFC6962]) with CT auditors in a | ||||
privacy-preserving manner by sending SCTs to originating HTTPS | ||||
servers which in turn share them with CT auditors. | ||||
In STH Pollination, HTTPS clients use HTTPS servers as pools sharing | ||||
Signed Tree Heads (STHs) (Section 3.5 of [RFC6962]) with other | ||||
connecting clients in the hope that STHs will find their way to | ||||
auditors and monitors. | ||||
HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs | This document tries to solve the problem with logs presenting a | |||
with trusted auditors or monitors directly, with expectations of | "split view" of their operations. It describes three gossiping | |||
privacy sensitive data being handled according to whatever privacy | mechanisms for Certificate Transparency: SCT Feedback, STH | |||
policy is agreed on between client and trusted party. | Pollination and Trusted Auditor Relationship. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 February 29, 2016. | ||||
This Internet-Draft will expire on April 22, 2016. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Defining the problem . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology and data flow . . . . . . . . . . . . . . . . . . 4 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Who gossips . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Terminology and data flow . . . . . . . . . . . . . . . . . . 5 | |||
5. What to gossip about and how . . . . . . . . . . . . . . . . 6 | 5. Who gossips with whom . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 6 | 6. What to gossip about and how . . . . . . . . . . . . . . . . 6 | |||
5.1.1. HTTPS client to server . . . . . . . . . . . . . . . 6 | 7. Gossip Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1.2. HTTPS server to auditors . . . . . . . . . . . . . . 8 | 7.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1.3. SCT Feedback data format . . . . . . . . . . . . . . 9 | 7.1.1. HTTPS client to server . . . . . . . . . . . . . . . 7 | |||
5.2. STH pollination . . . . . . . . . . . . . . . . . . . . . 9 | 7.1.2. HTTPS server to auditors . . . . . . . . . . . . . . 9 | |||
5.2.1. HTTPS client STH and Inclusion Proof Fetching . . . . 10 | 7.1.3. SCT Feedback data format . . . . . . . . . . . . . . 10 | |||
5.2.2. Auditor and Monitor Action . . . . . . . . . . . . . 11 | 7.2. STH pollination . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.2.3. STH Pollination data format . . . . . . . . . . . . . 11 | 7.2.1. HTTPS Clients and Proof Fetching . . . . . . . . . . 12 | |||
5.3. Trusted Auditor Stream . . . . . . . . . . . . . . . . . 12 | 7.2.2. STH Pollination without Proof Fetching . . . . . . . 13 | |||
5.3.1. Trusted Auditor data format . . . . . . . . . . . . . 12 | 7.2.3. Auditor and Monitor Action . . . . . . . . . . . . . 13 | |||
6. Security considerations . . . . . . . . . . . . . . . . . . . 12 | 7.2.4. STH Pollination data format . . . . . . . . . . . . . 13 | |||
6.1. Privacy considerations . . . . . . . . . . . . . . . . . 12 | 7.3. Trusted Auditor Stream . . . . . . . . . . . . . . . . . 14 | |||
6.1.1. Privacy and SCTs . . . . . . . . . . . . . . . . . . 13 | 7.3.1. Trusted Auditor data format . . . . . . . . . . . . . 14 | |||
6.1.2. Privacy in SCT Feedback . . . . . . . . . . . . . . . 13 | 8. 3-Method Ecosystem . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.1.3. Privacy for HTTPS clients requesting STHs . . . . . . 13 | 8.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.1.4. Privacy in STH Pollination . . . . . . . . . . . . . 14 | 8.2. STH Pollination . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.1.5. Trusted Auditors for HTTPS Clients . . . . . . . . . 14 | 8.3. Trusted Auditor Relationship . . . . . . . . . . . . . . 16 | |||
6.1.6. HTTPS Clients as Auditors . . . . . . . . . . . . . . 15 | 8.4. Interaction . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 | 9. Security considerations . . . . . . . . . . . . . . . . . . . 17 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 | 9.1. Censorship/Blocking considerations . . . . . . . . . . . 17 | |||
9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 9.2. Privacy considerations . . . . . . . . . . . . . . . . . 19 | |||
9.1. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 | 9.2.1. Privacy and SCTs . . . . . . . . . . . . . . . . . . 19 | |||
9.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 16 | 9.2.2. Privacy in SCT Feedback . . . . . . . . . . . . . . . 19 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 9.2.3. Privacy for HTTPS clients performing STH Proof | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 | Fetching . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 17 | 9.2.4. Privacy in STH Pollination . . . . . . . . . . . . . 20 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | 9.2.5. Privacy in STH Interaction . . . . . . . . . . . . . 21 | |||
9.2.6. Trusted Auditors for HTTPS Clients . . . . . . . . . 21 | ||||
9.2.7. HTTPS Clients as Auditors . . . . . . . . . . . . . . 22 | ||||
10. Policy Recommendations . . . . . . . . . . . . . . . . . . . 22 | ||||
10.1. Mixing Recommendations . . . . . . . . . . . . . . . . . 22 | ||||
10.2. Blocking Recommendations . . . . . . . . . . . . . . . . 24 | ||||
10.2.1. Frustrating blocking . . . . . . . . . . . . . . . . 24 | ||||
10.2.2. Responding to possible blocking . . . . . . . . . . 24 | ||||
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 25 | ||||
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
13. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
13.1. Changes between ietf-00 and ietf-01 . . . . . . . . . . 25 | ||||
13.2. Changes between -01 and -02 . . . . . . . . . . . . . . 25 | ||||
13.3. Changes between -00 and -01 . . . . . . . . . . . . . . 25 | ||||
14. Normative References . . . . . . . . . . . . . . . . . . . . 26 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | ||||
1. Introduction | 1. Introduction | |||
The purpose of the protocols in this document is to detect | The purpose of the protocols in this document, collectively referred | |||
misbehavior by CT logs. In particular, CT logs can misbehave either | to as CT Gossip, is to detect certain misbehavior by CT logs. In | |||
by rewriting history or by presenting a "split view" of their | particular, CT Gossip aims to detect logs that are providing | |||
operations, also known as a partitioning attack [THREAT-ANALYSIS]. | incosistent views to different log clients and logs failing to | |||
CT provides mechanisms for detection of these misbehaviors, but only | include submitted certificates within the time period stipulated by | |||
if the community dependent on the log knows what to do with them. In | MMD. | |||
order for the community to effectively detect log misbehavior, it | ||||
needs a well-defined way to "gossip" about the activity of the logs | [TODO: enumerate the interfaces used for detecting misbehaviour?] | |||
that makes use of the available mechanisms. | ||||
One of the major challenges of any gossip protocol is limiting damage | One of the major challenges of any gossip protocol is limiting damage | |||
to user privacy. The goal of CT gossip is to publish and distribute | to user privacy. The goal of CT gossip is to publish and distribute | |||
information about the logs and their operations, but not to leak any | information about the logs and their operations, but not to leak any | |||
additional information about the operation of any of the other | additional information about the operation of any of the other | |||
particpants. Privacy of consumers of log information (in particular, | participants. Privacy of consumers of log information (in | |||
of web browsers and other TLS clients) should not be damaged by | particular, of web browsers and other TLS clients) should not be | |||
gossip. | undermined by gossip. | |||
This document presents three different, complementary mechanisms for | This document presents three different, complementary mechanisms for | |||
non-log players in the CT ecosystem to exchange information about | non-log elements of the CT ecosystem to exchange information about | |||
logs in a manner that preserves the privacy of the non-log players | logs in a manner that preserves the privacy of HTTPS clients. They | |||
involved. They should provide protective benefits for the system as | should provide protective benefits for the system as a whole even if | |||
a whole even if their adoption is not universal. | their adoption is not universal. | |||
2. Overview | 2. Defining the problem | |||
Public append-only untrusted logs have to be monitored for | When a log provides different views of the log to different clients | |||
consistency, i.e., that they should never rewrite history. | this is described as a partitioning attack. Each client would be | |||
able to verify the append-only nature of the log but, in the extreme | ||||
case, each client might see a unique view of the log. | ||||
The CT logs are public, append-only and untrusted and thus have to be | ||||
monitored for consistency, i.e., they should never rewrite history. | ||||
Additionally, monitors and other log clients need to exchange | Additionally, monitors and other log clients need to exchange | |||
information about monitored logs in order to be able to detect a | information about monitored logs in order to be able to detect a | |||
partitioning attack. | partitioning attack (as described above). | |||
A partitioning attack is when a log serves different views of the log | ||||
to different clients. Each client would be able to verify the | ||||
append-only nature of the log while in the extreme case being the | ||||
only client seeing this particular view. | ||||
Gossiping about what's known about logs helps solve the problem of | Gossiping about log responses to queries helps address the problem of | |||
detecting malicious or compromised logs mounting such a partitioning | detecting malicious or compromised logs with respect to a | |||
attack. We want some side of the partitioned tree, and ideally both | partitioning attack. We want some side of the partitioned tree, and | |||
sides, to see the other side. | ideally both sides, to see the other side. | |||
Disseminating known information about a log poses a potential threat | Disseminating information about a log poses a potential threat to the | |||
to the privacy of end users. Some data of interest (e.g. SCTs) are | privacy of end users. Some data of interest (e.g. SCTs) are | |||
linkable to specific log entries and thereby to specific sites, which | linkable to specific log entries and thereby to specific sites, which | |||
makes them privacy-sensitive. Gossip about this data has to take | makes sharing them with others privacy-sensitive. Gossiping about | |||
privacy considerations into account in order not to leak associations | this data has to take privacy considerations into account in order | |||
between users of the log (e.g., web browsers) and certificate holders | not to leak associations between users of the log (e.g., web | |||
(e.g., web sites). Even sharing STHs (which do not link to specific | browsers) and certificate holders (e.g., web sites). Even sharing | |||
log entries) can be problematic - user tracking by fingerprinting | STHs (which do not link to specific log entries) can be problematic - | |||
through rare STHs is one potential attack. | user tracking by fingerprinting through rare STHs is one potential | |||
attack (see Section 7.2). | ||||
However, there is no loss in privacy if a client sends SCTs for a | 3. Overview | |||
given site to the site corresponding to the SCT, because the site's | ||||
access logs would already indicate that the client is accessing that | SCT Feedback enables HTTPS clients to share Signed Certificate | |||
site. In this way a site can accumulate records of SCTs that have | Timestamps (SCTs) (Section 3.3 of [RFC-6962-BIS]) with CT auditors in | |||
been issued by various logs for that site, providing a consolidated | a privacy-preserving manner by sending SCTs to originating HTTPS | |||
repository of SCTs which can be queried by auditors. | servers which in turn share them with CT auditors. | |||
In STH Pollination, HTTPS clients use HTTPS servers as pools sharing | ||||
Signed Tree Heads (STHs) (Section 3.6 of [RFC-6962-BIS]) with other | ||||
connecting clients in the hope that STHs will find their way to | ||||
auditors and monitors. | ||||
HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs | ||||
with trusted auditors or monitors directly, with expectations of | ||||
privacy sensitive data being handled according to whatever privacy | ||||
policy is agreed on between client and trusted party. | ||||
Despite the privacy risks with sharing SCTs there is no loss in | ||||
privacy if a client sends SCTs for a given site to the site | ||||
corresponding to the SCT. This is because the site's logs would | ||||
already indicate that the client is accessing that site. In this way | ||||
a site can accumulate records of SCTs that have been issued by | ||||
various logs for that site, providing a consolidated repository of | ||||
SCTs that could be shared with auditors. Auditors can use this | ||||
information to detect logs that misbehaves by not including | ||||
certificates within the time period stipulated by the MMD metadata. | ||||
Sharing an STH is considered reasonably safe from a privacy | Sharing an STH is considered reasonably safe from a privacy | |||
perspective as long as the same STH is shared by a large number of | perspective as long as the same STH is shared by a large number of | |||
other clients. This "safety in numbers" is achieved by requiring | other log clients. This "safety in numbers" can be achieved by | |||
gossip only for STHs of a certain "freshness" and limiting the | requiring gossiping of STHs only of a certain "freshness" while also | |||
frequency by which logs can issue STHs. | refusing to gossip about STHs from logs with too high an STH issuance | |||
frequency (see Section 7.2). | ||||
3. Terminology and data flow | 4. Terminology and data flow | |||
This document relies on terminology and data structures defined in | This document relies on terminology and data structures defined in | |||
[RFC6962], including STH, SCT, Version, LogID, SCT timestamp, | [RFC-6962-BIS], including STH, SCT, Version, LogID, SCT timestamp, | |||
CtExtensions, SCT signature, Merkle Tree Hash. | CtExtensions, SCT signature, Merkle Tree Hash. | |||
The following picture shows how certificates, SCTs and STHs flow | The following picture shows how certificates, SCTs and STHs flow | |||
through a CT system with SCT Feedback and STH Pollination. It does | through a CT system with SCT Feedback and STH Pollination. It does | |||
not show what goes in the Trusted Auditor Relationship stream. | not show what goes in the Trusted Auditor Relationship stream. | |||
+- Cert ---- +----------+ | +- Cert ---- +----------+ | |||
| | CA | ----------+ | | | CA | ----------+ | |||
| + SCT -> +----------+ | | | + SCT -> +----------+ | | |||
v | Cert [& SCT] | v | Cert [& SCT] | |||
skipping to change at page 5, line 39 | skipping to change at page 6, line 5 | |||
# Auditor Log | # Auditor Log | |||
[1] |--- get-sth ------------------->| | [1] |--- get-sth ------------------->| | |||
|<-- STH ------------------------| | |<-- STH ------------------------| | |||
[2] |--- leaf hash + tree size ----->| | [2] |--- leaf hash + tree size ----->| | |||
|<-- index + inclusion proof --->| | |<-- index + inclusion proof --->| | |||
[3] |--- tree size 1 + tree size 2 ->| | [3] |--- tree size 1 + tree size 2 ->| | |||
|<-- consistency proof ----------| | |<-- consistency proof ----------| | |||
[4] SCT, cert and STH among multiple Auditors and Monitors | [4] SCT, cert and STH among multiple Auditors and Monitors | |||
4. Who gossips | 5. Who gossips with whom | |||
o HTTPS clients and servers (SCT Feedback and STH Pollination) | o HTTPS clients and servers (SCT Feedback and STH Pollination) | |||
o HTTPS servers and CT auditors (SCT Feedback) | o HTTPS servers and CT auditors (SCT Feedback) | |||
o CT auditors and monitors (Trusted Auditor Relationship) | o CT auditors and monitors (Trusted Auditor Relationship) | |||
Additionally, some HTTPS clients may engage with an auditor who they | Additionally, some HTTPS clients may engage with an auditor who they | |||
trust with their privacy: | trust with their privacy: | |||
o HTTPS clients and CT auditors (Trusted Auditor Relationship) | o HTTPS clients and CT auditors (Trusted Auditor Relationship) | |||
5. What to gossip about and how | 6. What to gossip about and how | |||
There are three separate gossip streams: | There are three separate gossip streams: | |||
o SCT Feedback, transporting SCTs and certificate chains from HTTPS | o SCT Feedback - transporting SCTs and certificate chains from HTTPS | |||
clients to CT auditors/monitors via HTTPS servers. | clients to CT auditors/monitors via HTTPS servers. | |||
o STH Pollination, HTTPS clients and CT auditors/monitors using | o STH Pollination - HTTPS clients and CT auditors/monitors using | |||
HTTPS servers as STH pools for exchanging STHs. | HTTPS servers as STH pools for exchanging STHs. | |||
o Trusted Auditor Stream, HTTPS clients communicating directly with | o Trusted Auditor Stream, HTTPS clients communicating directly with | |||
trusted CT auditors/monitors sharing SCTs, certificate chains and | trusted CT auditors/monitors sharing SCTs, certificate chains and | |||
STHs. | STHs. | |||
5.1. SCT Feedback | 7. Gossip Mechanisms | |||
7.1. SCT Feedback | ||||
The goal of SCT Feedback is for clients to share SCTs and certificate | The goal of SCT Feedback is for clients to share SCTs and certificate | |||
chains with CT auditors and monitors in a privacy-preserving manner. | chains with CT auditors and monitors while still preserving the | |||
privacy of the end user. The sharing of SCTs contribute to the | ||||
overall goal of detecting misbehaving logs by providing auditors and | ||||
monitors with SCTs from many vantage points, making it possible to | ||||
catch a higher number of violations of MMD and also catch logs | ||||
presenting inconsistent views. | ||||
HTTPS clients store SCTs and certificate chains they see and later | SCT Feedback is the most privacy-preserving gossip mechanism, as it | |||
send them to the originating HTTPS server by posting them to a .well- | does not directly expose any links between an end user and the sites | |||
known URL. This is described in Section 5.1.1. Note that clients | they've visisted to any third party. | |||
send the same SCTs and chains to servers multiple times with the | ||||
assumption that a potential man-in-the-middle attack eventually will | [Here's an alternative to that paragraph: SCT Feedback is the most | |||
cease so that an honest server will receive collected malicious SCTs | privacy-preserving gossip mechanism, as it does not create any | |||
and certificate chains. | potential cross-origin tracking mechanisms. ] | |||
HTTPS clients store SCTs and certificate chains they see, and later | ||||
send them to the originating HTTPS server by posting them to a well- | ||||
known URL (associated with that server), as described in | ||||
Section 7.1.1. Note that clients will send the same SCTs and chains | ||||
to servers multiple times with the assumption that a potential man- | ||||
in-the-middle attack eventually will cease, and an honest server will | ||||
receive collected malicious SCTs and certificate chains. | ||||
HTTPS servers store SCTs and certificate chains received from clients | HTTPS servers store SCTs and certificate chains received from clients | |||
and later share them with CT auditors by either posting them or | and later share them with CT auditors by either posting them to | |||
making them available on a .well-known URL. This is described in | auditors or making them available via a well-known URL. This is | |||
Section 5.1.2. | described in Section 7.1.2. | |||
5.1.1. HTTPS client to server | 7.1.1. HTTPS client to server | |||
An HTTPS client connects to an HTTPS server for a particular domain. | When an HTTPS client connects to an HTTPS server, the client receives | |||
The client receives a set of SCTs as part of the TLS handshake. The | a set of SCTs as part of the TLS handshake. The client MUST discard | |||
client MUST discard SCTs that are not signed by a known log and | SCTs that are not signed by a log known to the client and SHOULD | |||
SHOULD store the remaining SCTs together with the corresponding | store the remaining SCTs together with the corresponding certificate | |||
certificate chain for later use in feedback. | chain for later use in SCT Feedback. | |||
When the client later reconnects to any HTTPS server for the same | When the client later reconnects to any HTTPS server for the same | |||
domain it again receives a set of SCTs. The client MUST add new SCTs | domain, it again receives a set of SCTs. The client MUST add new | |||
from known logs to its store of SCTs for the server. The client MUST | SCTs from known logs to its store of SCTs for the server. The client | |||
send to the server the ones in the store that are for that server and | MUST send to the server any SCTs in the store that are associated | |||
were not received from that server. | with that server but which were not received from that server. | |||
[ TODO: fix the above paragraph - it is vague and confusing. maybe | [TODO: fix the above paragraph - it is vague and confusing. maybe an | |||
an example including a client caching at most one SCT per host+log | example including a client caching at most one SCT per host+log would | |||
would clarify ] | clarify] | |||
[TODO: define "same domain"] | ||||
Note that the SCT store also contains SCTs received in certificates. | Note that the SCT store also contains SCTs received in certificates. | |||
The client MUST NOT send the same set of SCTs to the same server more | The client MUST NOT send the same set of SCTs to the same server more | |||
often than TBD. [benl: "sent to the server" only really counts if | often than TBD. | |||
the server presented a valid SCT in the handshake and the certificate | ||||
is known to be unrevoked (which will be hard for a MitM to sustain)] | [benl says: "sent to the server" only really counts if the server | |||
presented a valid SCT in the handshake and the certificate is known | ||||
to be unrevoked (which will be hard for a MitM to sustain)] | ||||
[TODO: expand on rate/resource limiting motivation] | [TODO: expand on rate/resource limiting motivation] | |||
Refer to Section 10.1 for recommendations about strategies. | ||||
An SCT MUST NOT be sent to any other HTTPS server than one serving | An SCT MUST NOT be sent to any other HTTPS server than one serving | |||
the domain that the certificate signed by the SCT refers to. This | the domain to which the certificate signed by the SCT refers. Not | |||
would lead to two types of privacy leaks. First, the server | following this constraint would lead to two types of privacy leaks. | |||
receiving the SCT would learn about other sites visited by the HTTPS | First, the server receiving the SCT would learn about other sites | |||
client. Secondly, auditors or monitors receiving SCTs from the HTTPS | visited by the HTTPS client. Secondly, auditors or monitors | |||
server would learn information about the other HTTPS servers visited | receiving SCTs from the HTTPS server would learn information about | |||
by its clients. | the other HTTPS servers visited by its clients. | |||
If the HTTPS client has configuration options for not sending cookies | If the HTTPS client has configuration options for not sending cookies | |||
to third parties, SCTs MUST be treated as cookies with respect to | to third parties, SCTs of third parties MUST be treated as cookies | |||
this setting. [TODO: expand on why - local storage cleanup; more?] | with respect to this setting. This prevents third party tracking | |||
through the use of SCTs/certificates, which would bypass the cookie | ||||
policy. | ||||
SCTs and corresponding certificates are POSTed to the originating | SCTs and corresponding certificates are POSTed to the originating | |||
HTTPS server at the well-known URL: | HTTPS server at the well-known URL: | |||
https://<domain>/.well-known/ct/v1/sct-feedback | https://<domain>/.well-known/ct/v1/sct-feedback | |||
The data sent in the POST is defined in Section 5.1.3. | The data sent in the POST is defined in Section 7.1.3. | |||
HTTPS servers perform a number of sanity checks on SCTs from clients | HTTPS servers perform a number of sanity checks on SCTs from clients | |||
before storing them: | before storing them: | |||
1. if a bit-wise compare of an SCT plus chain matches a pair already | 1. if a bit-wise compare of an SCT plus chain matches a pair already | |||
in the store, this SCT and chain pair MAY be discarded | in the store, this SCT and chain pair MAY be discarded | |||
2. if the SCT can't be verified to be a valid SCT for the | 2. if the SCT can't be verified to be a valid SCT for the | |||
accompanying leaf cert, issued by a known log, the SCT SHOULD be | accompanying leaf cert, issued by a known log, the SCT SHOULD be | |||
discarded | discarded | |||
3. if the leaf cert is not for a domain that the server is | 3. if the leaf cert is not for a domain for which the server is | |||
authoritative for, the SCT MUST be discarded | authoritative, the SCT MUST be discarded | |||
Check number 1 is for detecting duplicates. It's important to note | Check number 1 is for detecting duplicates and minimizing processing | |||
that the check must be on pairs of SCT and chain in order to catch | and storage by the server. It's important to note that the check | |||
different chains accompanied by the same SCT. [XXX why is this | should be on pairs of SCT and chain in order to catch different | |||
important?] | chains accompanied by the same SCT. This mis-matched chain | |||
Check number 2 is to prevent spamming attacks where an adversary can | information may be useful as a diagnostic tool for HTTPS server | |||
fill up the store prior to attacking a client, or a denial of service | operators. | |||
Check number 2 is to prevent DoS attacks where an adversary can fill | ||||
up the store prior to attacking a client, or a denial of service | ||||
attack on the server's storage space. | attack on the server's storage space. | |||
Check number 3 is to help malfunctioning clients from leaking which | Check number 3 is to help malfunctioning clients from leaking which | |||
sites they visit and additionally to prevent spamming attacks. | sites they visit and additionally to prevent DoS attacks. | |||
Note that an HTTPS server MAY perform a certificate chain validation | Note that an HTTPS server MAY choose to store a submitted SCT and the | |||
on a submitted certificate chain, and if it matches a trust root | accompanying certificate chain even when the SCT can't be verified | |||
configured on the server (but is otherwise unknown to the server), | according to check number 2. One such case would be when a | |||
the HTTPS server MAY store the certificate chain and MAY choose to | certificate chain validation is performed and the chain ends in a | |||
store any submitted SCTs even if they are unable to be verified. The | trust anchor configured on the server. In this instance, the server | |||
risk of spamming and denial of service can be mitigated by | could also be configured to not bother with known-to-be-good (i.e. | |||
configuring the server with all known acceptable certificates (or | administratively-vetted) leaf certificates, and only store unknown | |||
certificate hashes). | leaf certificates that chain to a known trust anchor. The risk of | |||
spamming and denial of service can be mitigated by configuring the | ||||
server with all known acceptable certificates (or certificate hashes) | ||||
applicable to this server. This information may enable a HTTPS | ||||
server operator to detect attacks or unusual behavior of Certificate | ||||
Authorities even outside the Certificate Transparency ecosystem. | ||||
5.1.2. HTTPS server to auditors | 7.1.2. HTTPS server to auditors | |||
HTTPS servers receiving SCTs from clients SHOULD share SCTs and | HTTPS servers receiving SCTs from clients SHOULD share SCTs and | |||
certificate chains with CT auditors by either providing the well- | certificate chains with CT auditors by either serving them on the | |||
known URL: | well-known URL: | |||
https://<domain>/.well-known/ct/v1/collected-sct-feedback | https://<domain>/.well-known/ct/v1/collected-sct-feedback | |||
or by HTTPS POSTing them to a number of preconfigured auditors. This | or by HTTPS POSTing them to a set of preconfigured auditors. This | |||
allows an HTTPS server to choose between an active push model or a | allows an HTTPS server to choose between an active push model or a | |||
passive pull model. | passive pull model. | |||
The data received in a GET of the well-known URL or sent in the POST | The data received in a GET of the well-known URL or sent in the POST | |||
is defined in Section 5.1.3. | is defined in Section 7.1.3. | |||
HTTPS servers SHOULD share all SCTs and accompanying certificate | HTTPS servers SHOULD share all SCTs and accompanying certificate | |||
chains they see that pass the checks in Section 5.1.1. | chains they see that pass the checks in Section 7.1.1. If this is an | |||
infeasible amount of data, the server may choose to expire | ||||
submissions according to an undefined policy. Suggestions for such a | ||||
policy can be found in Section 10.1. | ||||
HTTPS servers MUST NOT share any other data that they may learn from | HTTPS servers MUST NOT share any other data that they may learn from | |||
the submission of SCT Feedback by HTTPS clients. | the submission of SCT Feedback by HTTPS clients, like the HTTPS | |||
client IP address or the time of submission. | ||||
Auditors SHOULD provide the following URL accepting HTTPS POSTing of | Auditors SHOULD provide the following URL accepting HTTPS POSTing of | |||
SCT feedback data: | SCT feedback data: | |||
https://<auditor>/ct/v1/sct-feedback | https://<auditor>/ct/v1/sct-feedback | |||
Auditors SHOULD regularly poll HTTPS servers at the well-known | Auditors SHOULD regularly poll HTTPS servers at the well-known | |||
collected-sct-feedback URL. The frequency of the polling and how to | collected-sct-feedback URL. The frequency of the polling and how to | |||
determine which domains to poll is outside the scope of this | determine which domains to poll is outside the scope of this | |||
document. However, the selection MUST NOT be influenced by potential | document. However, the selection MUST NOT be influenced by potential | |||
HTTPS clients connecting directly to the auditor, as it would reveal | HTTPS clients connecting directly to the auditor. For example, if a | |||
private information provided by the clients. | poll to example.com occurs directly after a client submits an SCT for | |||
example.com, an adversary observing the auditor can trivially | ||||
conclude the activity of the client. | ||||
5.1.3. SCT Feedback data format | 7.1.3. SCT Feedback data format | |||
The data shared between HTTPS clients and servers as well as between | The data shared between HTTPS clients and servers, as well as between | |||
HTTPS servers and CT auditors/monitors is a JSON object [RFC7159] | HTTPS servers and CT auditors/monitors, is a JSON object [RFC7159] | |||
with the following content: | with the following content: | |||
o sct_feedback: An array of objects consisting of | o sct_feedback: An array of objects consisting of | |||
* x509_chain: An array of base64-encoded X.509 certificates. The | * x509_chain: An array of base64-encoded X.509 certificates. The | |||
first element is the end-entity certificate, the second chains | first element is the end-entity certificate, the second chains | |||
to the first and so on. | to the first and so on. | |||
* sct_data: An array of objects consisting of the base64 | * sct_data: An array of objects consisting of the base64 | |||
representation of the binary SCT data as defined in [RFC6962] | representation of the binary SCT data as defined in | |||
Section 3.2. | [RFC-6962-BIS] Section 3.3. | |||
The 'x509_chain' element MUST contain the leaf certificate and the | The 'x509_chain' element MUST contain at least the leaf certificate | |||
full chain to a known root. | and SHOULD contain the full chain to a root accepted by all of the | |||
logs in the set of logs issuing all the SCTs in the 'sct_data' | ||||
element. | ||||
5.2. STH pollination | Some clients have trust anchors that are locally added (e.g. by an | |||
administrator or by the user themselves). A local trust anchors is | ||||
potentially privacy-sensitive since it may carry information about | ||||
the specific computer or user. If a certificate is covered by SCTs | ||||
issued by publicly trusted logs, but it chains to a privacy-sensitive | ||||
local trust anchor, the client SHOULD submit it as an "x509\_chain" | ||||
consisting only of the leaf certificate. | ||||
[TBD: Be strict about what sct_data may contain or is this | ||||
sufficiently implied by previous sections?] | ||||
[TBD: There was discussion about including a few field for | ||||
client->server reporting, which is the exact set and order of | ||||
certificates sent by the HTTPS server to the client. This is | ||||
additional diagnostic information that a HTTPS server could use to | ||||
check it's deployment... but is pretty much useless to CT or gossip. | ||||
Right now we're not including this, but we're polling server | ||||
operators to see if they would welcome this data.] | ||||
7.2. STH pollination | ||||
The goal of sharing Signed Tree Heads (STHs) through pollination is | The goal of sharing Signed Tree Heads (STHs) through pollination is | |||
to share STHs between HTTPS clients, CT auditors, and monitors in a | to share STHs between HTTPS clients, CT auditors, and monitors in | |||
privacy-preserving manner. | while still preserving the privacy of the end user. The sharing of | |||
STHs contribute to the overall goal of detecting misbehaving logs by | ||||
providing CT auditors and monitors with SCTs from many vantage | ||||
points, making it possible to detect logs that are presenting | ||||
inconsistent views. | ||||
HTTPS servers supporting the protocol act as STH pools. HTTPS | HTTPS servers supporting the protocol act as STH pools. HTTPS | |||
clients and others in the possesion of STHs should pollinate STH | clients and CT auditors and monitors in the possession of STHs should | |||
pools by sending STHs to them, and retrieving new STHs to send to new | pollinate STH pools by sending STHs to them, and retrieving new STHs | |||
servers. CT auditors and monitors should retrieve STHs from pools by | to send to other STH pools. CT auditors and monitors should perform | |||
downloading STHs from them. | their auditing and monitoring duties by retrieving STHs from pools. | |||
STH Pollination is carried out by sending STHs to HTTPS servers | STH Pollination is carried out by sending STHs to HTTPS servers | |||
supporting the protocol, and retrieving new STHs. In the case of | supporting the protocol, and retrieving new STHs. In the case of | |||
HTTPS clients, STHs are sent in an already established TLS session. | HTTPS clients, STHs SHOULD be sent in an already established TLS | |||
This makes it hard for an attacker to disrupt STH gossiping without | session. This makes it hard for an attacker to disrupt STH gossiping | |||
also disturbing ordinary secure browsing (https://). | without also disturbing ordinary secure browsing (https://). This is | |||
discussed more in Section 10.2.1. | ||||
STHs are sent by POSTing them to the .well-known URL: | HTPS clients send STHs to HTTPS servers by POSTing them to the well- | |||
known URL: | ||||
https://<domain>/.well-known/ct/v1/sth-pollination | https://<domain>/.well-known/ct/v1/sth-pollination | |||
The data sent in the POST is defined in Section 5.2.3. | The data sent in the POST is defined in Section 7.2.4. | |||
The response contains zero or more STHs in the same format, described | The response contains zero or more STHs in the same format, described | |||
in Section 5.2.3. | in Section 7.2.4. | |||
An HTTPS client may acquire STHs by several methods: | An HTTPS client may acquire STHs by several methods: | |||
o in replies to pollination POSTs; | o in replies to pollination POSTs; | |||
o asking its supported logs for the current STH directly or | o asking logs that it recognises for the current STH, either | |||
indirectly; | directly (v2/get-sth) or indirectly (for example over DNS) | |||
o via some other (currently unspecified) mechanism. | o resolving an SCT and certificate to an STH via an inclusion proof | |||
o resolving one STH to another via a consistency proof | ||||
HTTPS clients (who have STHs), CT auditors, and monitors SHOULD | HTTPS clients (who have STHs), CT auditors, and monitors SHOULD | |||
pollinate STH pools with STHs. Which STHs to send and how often | pollinate STH pools with STHs. Which STHs to send and how often | |||
pollination should happen is regarded as policy and out of scope for | pollination should happen is regarded as undefined policy with the | |||
this document with exception of certain privacy concerns. | exception of privacy concerns explained in the next section. | |||
Suggestions for the policy may be found in Section 10.1. | ||||
An HTTPS client could be tracked by giving it a unique or rare STH. | An HTTPS client could be tracked by giving it a unique or rare STH. | |||
To address this concern, we place restrictions on different | To address this concern, we place restrictions on different | |||
components of the system to ensure an STH will not be rare. | components of the system to ensure an STH will not be rare. | |||
o Logs cannot issue STHs too frequently. This is restricted to 1 | o HTTPS clients sliently ignore STHs from logs with an STH issuance | |||
per hour. | frequency of more than one STH per hour. Logs use the STH | |||
Frequency Count metadata to express this ([RFC-6962-BIS] sections | ||||
3.6 and 5.1). | ||||
o HTTPS clients silently ignore STHs which are not fresh. | o HTTPS clients silently ignore STHs which are not fresh. | |||
An STH is considered fresh iff its timestamp is less than 14 days in | An STH is considered fresh iff its timestamp is less than 14 days in | |||
the past. Given a maximum STH issuance rate of one per hour, an | the past. Given a maximum STH issuance rate of one per hour, an | |||
attacker has 336 unique STHs per log for tracking. | attacker has 336 unique STHs per log for tracking. Clients MUST | |||
ignore STHs older than 14 days. We consider STHs within this | ||||
validity window to be personally identifiable data, and STHs outside | ||||
this window not personally identifiable. | ||||
When multiplied by the number of logs that a client accepts STHs for, | A log may cease operation, in which case there will soon be no STH | |||
this number of unique STHs grow and the negative privacy implications | within the validity window. Clients SHOULD perform all three methods | |||
grow with it. It's important that this is taken into account when | of gossip about a log that has ceased operation - it is possible the | |||
logs are chosen for default settings in HTTPS clients. | log was still compromised and gossip can detect that. STH | |||
Pollination is the one mechanism where a client must know about a log | ||||
shutdown. A client who does not know about a log shutdown MUST NOT | ||||
attempt any heuristic to detect a shutdown. Instead the client MUST | ||||
be informed about the shutdown from a verifiable source (e.g. a | ||||
software update). The client SHOULD be provided the final STH issued | ||||
by the log and SHOULD resolve SCTs and STHs to this final STH. If an | ||||
SCT or STH cannot be resolved to the final STH... XXX? | ||||
[TBD urge HTTPS clients to store STHs retrieved in responses?] | When multiplied by the number of logs from which a client accepts | |||
STHs, this number of unique STHs grow and the negative privacy | ||||
implications grow with it. It's important that this is taken into | ||||
account when logs are chosen for default settings in HTTPS clients. | ||||
This concern is discussed upon in Section 9.2.5. | ||||
[TBD share inclusion proofs and consistency proofs too?] | 7.2.1. HTTPS Clients and Proof Fetching | |||
5.2.1. HTTPS client STH and Inclusion Proof Fetching | There are two types of proofs a client may retrieve. | |||
An HTTPS client retrieves SCTs from an HTTPS server, and must obtain | An HTTPS client will retrieve SCTs from an HTTPS server, and must | |||
an inclusion proof to an STH in order to verify the promise made by | obtain an inclusion proof to an STH in order to verify the promise | |||
the SCT. This retrieval mechanism reveals the client's browsing | made by the SCT. | |||
habits when the client requests the proof diretly from the log. To | ||||
mitigate this risk, an HTTPS client MUST retrieve the proof in a | ||||
manner that disguises the client from the log. | ||||
Additionally, for this inclusion proof to be acceptable to the | An HTTPS client may receive SCT bundled with an inclusion proof to a | |||
client, the inclusion proof MUST reference a STH that is within the | historical STH via an unspecified future mechanism. Because this | |||
acceptable freshness interval. | historical STH is considered personally identifiable information per | |||
above, the client must obtain a consistency proof to a more recent | ||||
STH. | ||||
If a client requested either proof directly from a log or auditor, it | ||||
would reveal the client's browsing habits to a third party. To | ||||
mitigate this risk, an HTTPS client MUST retrieve the proof in a | ||||
manner that disguises the client. | ||||
Depending on the client's DNS provider, DNS may provide an | Depending on the client's DNS provider, DNS may provide an | |||
appropriate intermediate layer that obfuscates the linkability | appropriate intermediate layer that obfuscates the linkability | |||
between the user of the client and the request for inclusion (while | between the user of the client and the request for inclusion (while | |||
at the same time providing a caching layer for oft-requested | at the same time providing a caching layer for oft-requested | |||
inclusion proofs.) | inclusion proofs.) | |||
Also Tor. | [TODO: Add a reference to Google's DNS mechanism more proper than | |||
http://www.certificate-transparency.org/august-2015-newsletter] | ||||
5.2.2. Auditor and Monitor Action | Anonymity networks such as Tor also present a mechanism for a client | |||
to anonymously retrieve a proof from an auditor or log. | ||||
7.2.2. STH Pollination without Proof Fetching | ||||
An HTTPS client MAY participate in STH Pollination without fetching | ||||
proofs. In this situation, the client receives STHs from a server, | ||||
applies the same validation logic to them (signed by a known log, | ||||
within a validity window) and will later pass them to a HTTPS server. | ||||
When operating in this fashion, the HTTPS client is promoting gossip | ||||
for Certificate Transparency, but derives no direct benefit itself. | ||||
In comparison, a client who resolves SCTs or historical STHs to | ||||
recent STHs and pollinates them is assured that if it was attacked, | ||||
there is a probability that the ecosystem will detect and respond to | ||||
the attack (by distrusting the log). | ||||
7.2.3. Auditor and Monitor Action | ||||
Auditors and Monitors participate in STH pollination by retrieving | Auditors and Monitors participate in STH pollination by retrieving | |||
STHs from HTTPS servers. They verify that the STH is valid by | STHs from HTTPS servers. They verify that the STH is valid by | |||
checking the signature, and requesting a consistency proof from the | checking the signature, and requesting a consistency proof from the | |||
STH to the most recent STH. | STH to the most recent STH. | |||
After retrieving the consistency proof to the most recent STH, they | After retrieving the consistency proof to the most recent STH, they | |||
SHOULD pollinate this new STH among participating HTTPS Servers. In | SHOULD pollinate this new STH among participating HTTPS Servers. In | |||
this way, as STHs "age out" and are no longer fresh, their "lineage" | this way, as STHs "age out" and are no longer fresh, their "lineage" | |||
continues to be tracked in the system. | continues to be tracked in the system. | |||
5.2.3. STH Pollination data format | 7.2.4. STH Pollination data format | |||
The data sent from HTTPS clients and CT monitors and auditors to | The data sent from HTTPS clients and CT monitors and auditors to | |||
HTTPS servers is a JSON object [RFC7159] with the following content: | HTTPS servers is a JSON object [RFC7159] with the following content: | |||
o sths - an array of 0 or more fresh STH objects [XXX recently | o sths - an array of 0 or more fresh SignedTreeHead's as defined in | |||
collected] from the log associated with log_id. Each of these | [RFC-6962-BIS] Section 3.6.1. | |||
objects consists of | ||||
* sth_version: Version as defined in [RFC6962] Section 3.2, as a | ||||
number. The version of the protocol to which the sth_gossip | ||||
object conforms. | ||||
* tree_size: The size of the tree, in entries, as a number. | ||||
* timestamp: The timestamp of the STH as defined in [RFC6962] | ||||
Section 3.2, as a number. | ||||
* sha256_root_hash: The Merkle Tree Hash of the tree as defined | ||||
in [RFC6962] Section 2.1, as a base64 encoded string. | ||||
* tree_head_signature: A TreeHeadSignature as defined in | ||||
[RFC6962] Section 3.5 for the above data, as a base64 encoded | ||||
string. | ||||
* log_id: LogID as defined in [RFC6962] Section 3.2, as a base64 | ||||
encoded string. | ||||
[XXX An STH is considered recently collected iff TBD.] | [XXX An STH is considered fresh iff TBD.] | |||
5.3. Trusted Auditor Stream | 7.3. Trusted Auditor Stream | |||
HTTPS clients MAY send SCTs and cert chains, as well as STHs, | HTTPS clients MAY send SCTs and cert chains, as well as STHs, | |||
directly to auditors. Note that there are privacy implications in | directly to auditors. Note that there are privacy implications in | |||
doing so, these are outlined in Section 6.1.1 and Section 6.1.5. | doing so, these are outlined in Section 9.2.1 and Section 9.2.6. | |||
The most natural trusted auditor arrangement arguably is a web | The most natural trusted auditor arrangement arguably is a web | |||
browser that is "logged in to" a provider of various internet | browser that is "logged in to" a provider of various internet | |||
services. Another equivalent arrangement is a trusted party like a | services. Another equivalent arrangement is a trusted party like a | |||
corporation to which an employee is connected through a VPN or by | corporation to which an employee is connected through a VPN or by | |||
other similar means. A third might be individuals or smaller groups | other similar means. A third might be individuals or smaller groups | |||
of people running their own services. In such a setting, retrieving | of people running their own services. In such a setting, retrieving | |||
STHs and inclusion proofs from that third party in order to validate | proofs from that third party could be considered reasonable from a | |||
SCTs could be considered reasonable from a privacy perspective. The | privacy perspective. The HTTPS client does its own auditing and | |||
HTTPS client does its own auditing and might additionally share SCTs | might additionally share SCTs and STHs with the trusted party to | |||
and STHs with the trusted party to contribute to herd immunity. | contribute to herd immunity. Here, the ordinary [RFC-6962-BIS] | |||
Here, the ordinary [RFC6962] protocol is sufficient for the client to | protocol is sufficient for the client to do the auditing while SCT | |||
do the auditing while SCT Feedback and STH Pollination can be used in | Feedback and STH Pollination can be used in whole or in parts for the | |||
whole or in parts for the gossip part. | gossip part. | |||
Another well established trusted party arrangement on the internet | Another well established trusted party arrangement on the internet | |||
today is the relation between internet users and their providers of | today is the relation between internet users and their providers of | |||
DNS resolver services. DNS resolvers are typically provided by the | DNS resolver services. DNS resolvers are typically provided by the | |||
internet service provider (ISP) used, which by the nature of name | internet service provider (ISP) used, which by the nature of name | |||
resolving already know a great deal about which sites their users | resolving already know a great deal about which sites their users | |||
visit. As mentioned in Section XXX, in order for HTTPS clients to be | visit. As mentioned in Section XXX, in order for HTTPS clients to be | |||
able to retrieve inclusion proofs for certificates in a privacy | able to retrieve proofs in a privacy preserving manner, logs could | |||
preserving manner, logs could expose a DNS interface in addition to | expose a DNS interface in addition to the ordinary HTTPS interface. | |||
the ordinary HTTPS interface. An informal writeup of such a protocol | An informal writeup of such a protocol can be found at XXX. | |||
can be found at XXX. | ||||
5.3.1. Trusted Auditor data format | 7.3.1. Trusted Auditor data format | |||
[TBD specify something here or leave this for others?] | [TBD specify something here or leave this for others?] | |||
6. Security considerations | 8. 3-Method Ecosystem | |||
6.1. Privacy considerations | The use of three distinct methods for monitoring logs may seem | |||
excessive, but each represents a needed component in the CT | ||||
ecosystem. To understand why, the drawbacks of each component must | ||||
be outlined. In this discussion we assume that an attacker knows | ||||
which mechanisms an HTTPS client and HTTPS server implement. | ||||
The most sensitive relationships in the CT ecosystem are the | 8.1. SCT Feedback | |||
relationships between HTTPS clients and HTTPS servers. Client-server | ||||
relationships can be aggregated into a network graph with potentially | SCT Feedback requires the cooperation of HTTPS clients and more | |||
serious implications for correlative de-anonymisation of clients and | importantly HTTPS servers. Although SCT Feedback does require a | |||
significant amount of server-side logic to respond to the | ||||
corresponding APIs, this functionality does not require | ||||
customization, so it may be pre-provides and work out of the box. | ||||
However, to take full advantage of the system, an HTTPS server would | ||||
wish to perform some configuration to optimize its operation: | ||||
o Minimize its disk commitment by whitelisting known SCTs and | ||||
certificate chains | ||||
o Maximize its chance of detecting a misissued certificate by | ||||
configuring a trust store of CAs | ||||
o Establish a "push" mechanism for POSTing SCTs to Auditors and | ||||
Monitors | ||||
These configuration needs, and the simple fact that it would require | ||||
some deployment of software, means that some percentage of HTTPS | ||||
servers will not deploy SCT Feedback. | ||||
If SCT Feedback was the only mechanism in the ecosystem, any server | ||||
that did not implement the feature, would open itself and its users | ||||
to attack without any possibility of detection. | ||||
If SCT Feedback was not deployed, users who wished to have the | ||||
strongest measure of privacy protection (by disabling STH Pollination | ||||
Proof Fetching and forgoing a Trusted Auditor) could be attacked | ||||
without risk of detection. | ||||
8.2. STH Pollination | ||||
STH Pollination requires the cooperation of HTTPS clients, HTTPS | ||||
servers, and logs. | ||||
For a client to fully participate in STH Pollination, and have this | ||||
mechanism detect attacks against it, the client must have a way to | ||||
safely perform Proof Fetching in a privacy preserving manner. The | ||||
client may pollinate STHs it receives without performing Proof | ||||
Fetching, but we do not consider this option in this section. | ||||
HTTPS Servers must deploy software (although, as in the case with SCT | ||||
Feedback this logic can be pre-provided) and commit some configurable | ||||
amount of disk space to the endeavor. | ||||
Logs must provide access to clients to query proofs in a privacy | ||||
preserving manner, most likely through DNS. | ||||
Unlike SCT Feedback, the STH Pollination mechanism is not hampered if | ||||
only a minority of HTTPS servers deploy it. However, it makes an | ||||
assumption that an HTTPS client performs anonymized Proof Fetching | ||||
(such as the DNS mechanism discussed). However, any manner that is | ||||
anonymous for some (such as clients who use shared DNS services such | ||||
as a large ISP), may not be anonymous for others. | ||||
For instance, DNS leaks a considerable amount of information | ||||
(including what data is already present in the cache) in plaintext | ||||
over the network. For this reason, some percentage of HTTPS clients | ||||
may choose to not enable the Proof Fetching component of STH | ||||
pollination. (Although they can still request and send STHs among | ||||
participating HTTPS servers, as mentioned earlier this affords them | ||||
no direct benefit.) | ||||
If STH Pollination was the only mechanism deployed, users that | ||||
disable it would be able to be attacked without risk of detection. | ||||
If STH Pollination was not deployed, HTTPS Clients visiting HTTPS | ||||
Servers who did not deploy SCT Feedback could be attacked without | ||||
risk of detection. | ||||
8.3. Trusted Auditor Relationship | ||||
The Trusted Auditor Relationship is expected to be the rarest gossip | ||||
mechanism, as an HTTPS Client is providing an unadulterated report of | ||||
its browsing history to a third party. While there are valid and | ||||
common reasons for doing so, there is no appropriate way to enter | ||||
into this relationship without retrieving informed consent from the | ||||
user. | ||||
However, the Trusted Auditor Relationship mechanism still provides | ||||
value to a class of HTTPS Clients. For example, web crawlers have no | ||||
concept of a "user" and no expectation of privacy. Organizations | ||||
already performing network monitoring for anomalies or attacks can | ||||
run their own Trusted Auditor for the same purpose with marginal | ||||
increase in privacy concerns. | ||||
The ability to change one's Trusted Auditor is a form of Trust | ||||
Agility that allows a user to choose who to trust, and be able to | ||||
revise that decision later without consequence. A Trusted Auditor | ||||
connection can be made more confidential than DNS (through the use of | ||||
TLS), and can even be made (somewhat) anonymous through the use of | ||||
anonymity services such as Tor. (Note that this does ignore the de- | ||||
anonymization possibilities available from viewing a user's browsing | ||||
history.) | ||||
If the Trusted Auditor relationship was the only mechanism deployed, | ||||
users who do not enable it (the majority) would be able to be | ||||
attacked without risk of detection. | ||||
If the Trusted Auditor relationship was not deployed, crawlers and | ||||
organizations would build it themselves for their own needs. By | ||||
standardizing it, users who wish to opt-in (for instance those | ||||
unwilling to participate fully in STH Pollination) can have an | ||||
interoperable standard they can use to choose and change their | ||||
trusted auditor. | ||||
8.4. Interaction | ||||
The interactions of the mechanisms is thus outlined: | ||||
HTTPS Clients can be attacked without risk of detection if they do | ||||
not participate in any of the three mechanisms. | ||||
HTTPS Clients are afforded the greatest chance of detecting an attack | ||||
when they either participate in STH Pollination with Proof Fetching | ||||
or have a Trusted Auditor relationship. Participating in SCT | ||||
Feedback enables a HTTPS Client to assist in detecting the exact | ||||
target of an attack, although they do not gain any direct benefit | ||||
from it. | ||||
HTTPS Servers that omit SCT Feedback may never learn about targeted | ||||
attacks against them, even if the attack occurred and the log | ||||
distrusted. They do gain some herd immunity, enabling them to detect | ||||
attacks, through their clients participating in STH Pollination or a | ||||
Trusted Auditor Relationship. | ||||
When HTTPS Servers omit SCT feedback, it allow a portion of their | ||||
users to be attacked without detection; the vulnerable users are | ||||
those who do not participate in STH Pollination with Proof Fetching | ||||
and that not have a Trusted Auditor relationship. | ||||
9. Security considerations | ||||
9.1. Censorship/Blocking considerations | ||||
We assume a network attacker who is able to fully control the | ||||
client's internet connection for some period of time - including | ||||
selectively blocking requests to certain hosts and truncating TLS | ||||
connections based on information observed or guessed about client | ||||
behavior. In order to successfully detect log misbehavior, the | ||||
gossip mechanisms must still work even in these conditions. | ||||
There are several gossip connections that can be blocked: | ||||
1. Clients sending SCTs to servers in SCT Feedback | ||||
2. Servers sending SCTs to auditors in SCT Feedback (server push | ||||
mechanism) | ||||
3. Servers making SCTs available to auditors (auditor pull | ||||
mechanism) | ||||
4. Clients fetching proofs in STH Pollination | ||||
5. Clients sending STHs to servers in STH Pollination | ||||
6. Servers sending STHs to clients in STH Pollination | ||||
7. Clients sending SCTs to Trusted Auditors | ||||
If a party cannot connect to another party, it can be assured that | ||||
the connection did not succeed. While it may not have been | ||||
maliciously blocked, it knows the transaction did not succeed. | ||||
Mechanisms which result in a positive affirmation from the recipient | ||||
that the transaction succeeded allow confirmation that a connection | ||||
was not blocked. In this situation, the party can factor this into | ||||
strategies suggested in Section 10.1 and in Section 10.2.2. | ||||
The connections that allow positive affirmation are 1, 2, 4, 5, and | ||||
7. | ||||
More insidious is blocking the connections that do not allow positive | ||||
confirmation: 3 and 6. An attacker may truncate a or drop a response | ||||
from a server to a client, such that the server believes it has | ||||
shared data with the recipient, when it has not. However, in both | ||||
scenatios (3 and 6), the server cannot distinguish the client as a | ||||
cooperating member of the CT ecosystem or as an attacker performing a | ||||
sybil attack, aiming to flush the server's data store. Therefore the | ||||
fact that these connections can be undetectably blocked does not | ||||
actually alter the threat model of servers responding to these | ||||
requests. The choice of algorithm to release data is crucial to | ||||
protect against these attacks, strategies are suggested in | ||||
Section 10.1. | ||||
Handling censorship and network blocking (which is indistinguishable | ||||
from network error) is relegated to the implementation policy chosen | ||||
by clients. Suggestions for client behavior are specified in | ||||
Section 10.2. | ||||
9.2. Privacy considerations | ||||
CT Gossip deals with HTTPS Clients which are trying to share | ||||
indicators that correspond to their browsing history. The most | ||||
sensitive relationships in the CT ecosystem are the relationships | ||||
between HTTPS clients and HTTPS servers. Client-server relationships | ||||
can be aggregated into a network graph with potentially serious | ||||
implications for correlative de-anonymisation of clients and | ||||
relationship-mapping or clustering of servers or of clients. | relationship-mapping or clustering of servers or of clients. | |||
6.1.1. Privacy and SCTs | There are, however, certain clients that do not require privacy | |||
protection. Examples of these clients are web crawlers or robots but | ||||
even in this case, the method by which these clients crawl the web | ||||
may in fact be considered sensitive information. In general, it is | ||||
better to err on the side of safety, and not assume a client is okay | ||||
with giving up its privacy. | ||||
9.2.1. Privacy and SCTs | ||||
An SCT contains information that links it to a particular web site. | An SCT contains information that links it to a particular web site. | |||
Because the client-server relationship is sensitive, gossip between | Because the client-server relationship is sensitive, gossip between | |||
clients and servers about unrelated SCTs is risky. Therefore, a | clients and servers about unrelated SCTs is risky. Therefore, a | |||
client with an SCT for a given server should transmit that | client with an SCT for a given server should transmit that | |||
information in only two channels: to a server associated with the SCT | information in only two channels: to a server associated with the SCT | |||
itself; and to a trusted CT auditor, if one exists. | itself; and to a trusted CT auditor, if one exists. | |||
6.1.2. Privacy in SCT Feedback | 9.2.2. Privacy in SCT Feedback | |||
SCTs introduce yet another mechanism for HTTPS servers to store state | SCTs introduce yet another mechanism for HTTPS servers to store state | |||
on an HTTPS client, and potentially track users. HTTPS clients which | on an HTTPS client, and potentially track users. HTTPS clients which | |||
allow users to clear history or cookies associated with an origin | allow users to clear history or cookies associated with an origin | |||
MUST clear stored SCTs associated with the origin as well. | MUST clear stored SCTs associated with the origin as well. | |||
Auditors should treat all SCTs as sensitive data. SCTs received | Auditors should treat all SCTs as sensitive data. SCTs received | |||
directly from an HTTPS client are especially sensitive, because the | directly from an HTTPS client are especially sensitive, because the | |||
auditor is a trusted by the client to not reveal their associations | auditor is a trusted by the client to not reveal their associations | |||
with servers. Auditors MUST NOT share such SCTs in any way, | with servers. Auditors MUST NOT share such SCTs in any way, | |||
including sending them to an external log, without first mixing them | including sending them to an external log, without first mixing them | |||
with multiple other SCTs learned through submissions from multiple | with multiple other SCTs learned through submissions from multiple | |||
other clients. The details of mixing SCTs are TBD. | other clients. Suggestions for mixing SCTs are presented in | |||
Section 10.1. | ||||
There is a possible fingerprinting attack where a log issues a unique | There is a possible fingerprinting attack where a log issues a unique | |||
SCT for targeted log client(s). A colluding log and HTTPS server | SCT for targeted log client(s). A colluding log and HTTPS server | |||
operator could therefore be a threat to the privacy of an HTTPS | operator could therefore be a threat to the privacy of an HTTPS | |||
client. Given all the other opportunities for HTTPS servers to | client. Given all the other opportunities for HTTPS servers to | |||
fingerprint clients - TLS session tickets, HPKP and HSTS headers, | fingerprint clients - TLS session tickets, HPKP and HSTS headers, | |||
HTTP Cookies, etc. - this is acceptable. | HTTP Cookies, etc. - this is acceptable. | |||
The fingerprinting attack described above could be avoided by | The fingerprinting attack described above would be mitigated by a | |||
requiring that logs i) MUST return the same SCT for a given cert | requirement that logs MUST use a deterministic signature scheme when | |||
chain ([RFC6962] Section 3) and ii) use a deterministic signature | signing SCTs ([RFC-6962-BIS] Section 2.1.4). A log signing using RSA | |||
scheme when signing the SCT ([RFC6962] Section 2.1.4). | is not required to use a deterministic signature scheme. | |||
Since logs are allowed to issue a new SCT for a certificate already | ||||
present in the log, mandating deterministic signatures does not stop | ||||
this fingerprinting attack altogether. It does make the attack | ||||
harder to pull off without being detected though. | ||||
There is another similar fingerprinting attack where an HTTPS server | There is another similar fingerprinting attack where an HTTPS server | |||
tracks a client by using a variation of cert chains. The risk for | tracks a client by using a variation of cert chains. The risk for | |||
this attack is accepted on the same grounds as the unique SCT attack | this attack is accepted on the same grounds as the unique SCT attack | |||
described above. [XXX any mitigations possible here?] | described above. [XXX any mitigations possible here?] | |||
6.1.3. Privacy for HTTPS clients requesting STHs | 9.2.3. Privacy for HTTPS clients performing STH Proof Fetching | |||
An HTTPS client that does not act as an auditor should only request | An HTTPS client performing Proof Fetching should only request proofs | |||
an STH from a CT log that it accepts SCTs from. An HTTPS client | from a CT log that it accepts SCTs from. An HTTPS client should | |||
should regularly [XXX how regularly? This has operational | regularly [TBD how regularly? This has operational implications for | |||
implications for log operators] request an STH from all logs it is | log operators] request an STH from all logs it is willing to accept, | |||
willing to accept, even if it has seen no SCTs from that log. | even if it has seen no SCTs from that log. | |||
6.1.4. Privacy in STH Pollination | The actual mechanism by which Proof Fetching is done carries | |||
considerable privacy concerns. Although out of scope for the | ||||
document, DNS is a mechanism currently discussed. DNS leaks data in | ||||
plaintext over the network (including what sites the user is visiting | ||||
and what sites they have previously visited) - thus it may not be | ||||
suitable for some. | ||||
9.2.4. Privacy in STH Pollination | ||||
An STH linked to an HTTPS client may indicate the following about | An STH linked to an HTTPS client may indicate the following about | |||
that client: | that client: | |||
o that the client gossips; | o that the client gossips; | |||
o that the client been using CT at least until the time that the | o that the client has been using CT at least until the time that the | |||
timestamp and the tree size indicate; | timestamp and the tree size indicate; | |||
o that the client is talking, possibly indirectly, to the log | o that the client is talking, possibly indirectly, to the log | |||
indicated by the tree hash; | indicated by the tree hash; | |||
o which software and software version is being used. | o which software and software version is being used. | |||
There is a possible fingerprinting attack where a log issues a unique | There is a possible fingerprinting attack where a log issues a unique | |||
STH for a targeted log auditor or HTTPS client. This is similar to | STH for a targeted HTTPS client. This is similar to the | |||
the fingerprinting attack described in Section 6.1.2, but it is | fingerprinting attack described in Section 9.2.2, but can operate | |||
mitigated by the following factors: | cross-origin. If a log (or HTTPS Server cooperating with a log) | |||
provides a unique STH to a client, the targeted client will be the | ||||
only client pollinating that STH cross-origin. | ||||
o the relationship between auditors and logs is not sensitive in the | It is mitigated partially because the log is limited in the number of | |||
way that the relationship between HTTPS clients and HTTPS servers | STHs it can issue. It must 'save' one of its STHs each MMD to | |||
is; | perform the attack. | |||
o because auditors regularly exchange STHs with each other, the re- | 9.2.5. Privacy in STH Interaction | |||
appearance of a targeted STH from some auditor does not imply that | ||||
the auditor was the original one targeted by the log; | ||||
o an HTTPS client's relationship to a log is not sensitive in the | An HTTPS client may pollinate any STH within the last 14 days. An | |||
way that its relationship to an HTTPS server is. As long as the | HTTPS Client may also pollinate an STH for any log that it knows | |||
client does not query the log for anything other than individual | about. When a client pollinates STHs to a server, it will release | |||
STHs, the client should not leak anything else to the log itself. | more than one STH at a time. It is unclear if a server may 'prime' a | |||
However, a log and an HTTPS server which are collaborating could | client and be able to reliably detect the client at a later time. | |||
use this technique to fingerprint a targeted HTTPS client. | ||||
Note that an HTTPS client in the configuration described in this | It's clear that a single site can track a user any way they wish, but | |||
document doesn't make direct use of the STH itself. Its fetching of | this attack works cross-origin and is therefore more concerning. Two | |||
the STH and reporting via STH Pollination provides a benefit to the | independent sites A and B want to collaborate to track a user cross- | |||
CT ecosystem as a whole by providing oversight on logs, but the HTTPS | origin. A feeds a client Carol some N specific STHs from the M logs | |||
client itself will not necessarily derive direct benefit. | Carol trusts, chosen to be older and less common, but still in the | |||
validity window. Carol visits B and chooses to release some of the | ||||
STHs she has stored, according to some policy. | ||||
6.1.5. Trusted Auditors for HTTPS Clients | Modeling a representation for how common older STHs are in the pools | |||
of clients, and examining that with a given policy of how to choose | ||||
which of those STHs to send to B, it should be possible to calculate | ||||
statistics about how unique Carol looks when talking to B and how | ||||
useful/accurate such a tracking mechanism is. | ||||
Building such a model is likely impossible without some real world | ||||
data, and requires a given implementation of a policy. To combat | ||||
this attack, suggestions are provided in Section 10.1 to attempt to | ||||
minimize it, but follow-up testing with real world deployment to | ||||
improvise the policy will be required. | ||||
9.2.6. Trusted Auditors for HTTPS Clients | ||||
Some HTTPS clients may choose to use a trusted auditor. This trust | Some HTTPS clients may choose to use a trusted auditor. This trust | |||
relationship leaks a certain amount of information from the client to | relationship leaks a large amount of information from the client to | |||
the auditor. In particular, it is likely to identify the web sites | the auditor. In particular, it will identify the web sites that the | |||
that the client has visited to the auditor. Some clients may already | client has visited to the auditor. Some clients may already share | |||
share this information to a third party, for example, when using a | this information to a third party, for example, when using a server | |||
server to synchronize browser history across devices in a server- | to synchronize browser history across devices in a server-visible | |||
visible way, or when doing DNS lookups through a trusted DNS | way, or when doing DNS lookups through a trusted DNS resolver. For | |||
resolver. For clients with such a relationship already established, | clients with such a relationship already established, sending SCTs to | |||
sending SCT Feedback to the same organization does not appear to leak | a trusted auditor run by the same organization does not appear to | |||
any additional information to the trusted third party. | leak any additional information to the trusted third party. | |||
Clients who wish to contact an auditor without associating their | Clients who wish to contact an auditor without associating their | |||
identities with their SCT Feedback may wish to use an anonymizing | identities with their SCTs may wish to use an anonymizing network | |||
network like Tor to submit SCT Feedback to the auditor. Auditors | like Tor to submit SCT Feedback to the auditor. Auditors SHOULD | |||
SHOULD accept SCT Feedback that arrives over such anonymizing | accept SCT Feedback that arrives over such anonymizing networks. | |||
networks. | ||||
Clients sending feedback to an auditor may prefer to reduce the | Clients sending feedback to an auditor may prefer to reduce the | |||
temporal granularity of the history leakage to the auditor by caching | temporal granularity of the history leakage to the auditor by caching | |||
and delaying their SCT Feedback reports. This strategy is only as | and delaying their SCT Feedback reports. This elaborated upon in XXX | |||
effective as the granularity of the timestamps embedded in the SCTs | Mixing. This strategy is only as effective as the granularity of the | |||
and STHs. | timestamps embedded in the SCTs and STHs. | |||
6.1.6. HTTPS Clients as Auditors | 9.2.7. HTTPS Clients as Auditors | |||
Some HTTPS Clients may choose to act as Auditors themselves. A | Some HTTPS Clients may choose to act as Auditors themselves. A | |||
Client taking on this role needs to consider the following: | Client taking on this role needs to consider the following: | |||
o an Auditing HTTPS Client potentially leaks their history to the | o an Auditing HTTPS Client potentially leaks their history to the | |||
logs that they query. Querying the log through a cache or a proxy | logs that they query. Querying the log through a cache or a proxy | |||
with many other users may avoid this leakage, but may leak | with many other users may avoid this leakage, but may leak | |||
information to the cache or proxy, in the same way that an non- | information to the cache or proxy, in the same way that an non- | |||
Auditing HTTPS Client leaks information to a trusted Auditor. | Auditing HTTPS Client leaks information to a trusted auditor. | |||
o an effective Auditor needs a strategy about what to do in the | o an effective Auditor needs a strategy about what to do in the | |||
event that it discovers misbehavior from a log. Misbehavior from | event that it discovers misbehavior from a log. Misbehavior from | |||
a log involves the log being unable to provide either (a) a | a log involves the log being unable to provide either (a) a | |||
consistency proof between two valid STHs or (b) an inclusion proof | consistency proof between two valid STHs or (b) an inclusion proof | |||
for a certificate to an STH any time after the log's MMD has | for a certificate to an STH any time after the log's MMD has | |||
elapsed from the issuance of the SCT. The log's inability to | elapsed from the issuance of the SCT. The log's inability to | |||
provide either proof will not be externally cryptographically- | provide either proof will not be externally cryptographically- | |||
verifiable, as it may be indistinguishable from a network error. | verifiable, as it may be indistinguishable from a network error. | |||
7. IANA considerations | 10. Policy Recommendations | |||
TBD | This section is intended as suggestions to implementors of HTTPS | |||
Clients, HTTPS Servers, and Auditors. It is not a requirement for | ||||
technique of implementation, so long as privacy considerations | ||||
established above are obeyed. | ||||
8. Contributors | 10.1. Mixing Recommendations | |||
In several components of the CT Gossip ecosystem, the recommendation | ||||
is made that data from multiple sources be ingested, mixed, provided | ||||
to a third party, stored for an indeterminate period of time, and | ||||
eventually deleted. The instances of these recommendations in this | ||||
draft are: | ||||
o When a client receives SCTs during SCT Feedback, it should store | ||||
the SCTs and Certificates for some amount of time, provide some of | ||||
them back to the server at some point, and eventually remove them | ||||
from its store | ||||
o When a client receives STHs during STH Pollination, it should | ||||
store them for some amount of time, mix them with other STHs, | ||||
release some of them them to various servers at some point, | ||||
resolve some of them to new STHs, and eventually remove them from | ||||
its store | ||||
o When a server receives SCTs during SCT Feedback, it should store | ||||
them for some period of time, provide them to auditors some number | ||||
of times, and may eventually remove them | ||||
o When a server receives STHs during STH Pollination, it should | ||||
store them for some period of time, mix them with other STHs, | ||||
provide some of them to connecting clients, may resolve them to | ||||
new STHs via Proof Fetching, and eventually remove them from its | ||||
store | ||||
o When a Trusted Auditor receives SCTs or historical STHs from | ||||
clients, it should store them for some period of time, mix them | ||||
with SCTs received from other clients, and act upon them at some | ||||
period of time | ||||
Each of these instances have specific requirements for user privacy, | ||||
and each have options that may not be invoked. As one example, a | ||||
HTTPS client should not mix SCTs from server A with SCTs from server | ||||
B and release server B's SCTs to Server A. As another example, a | ||||
HTTPS server may choose to resolve several STHs to a single more | ||||
current STH via proof fetching, but it is under no obligation to do | ||||
so. | ||||
These requirements should be met, but the general problem of | ||||
aggregating multiple pieces of data, choosing when and how many to | ||||
release, and when to remove is shared. This problem has been | ||||
previously been considered in the case of Mix Networks and Remailers, | ||||
including papers such as [X], [Y], and [Z]. | ||||
Certain common recommendations can be made: | ||||
o When choosing how many times to release data before expiring it | ||||
from a cache, use a random number chosen from a distribution, | ||||
rather than a fixed number. This prevents an adversary from | ||||
knowing with certainty that it has successfully flushed a cache of | ||||
a potentially incriminating piece of data. | ||||
o [TODO Enumerating the problems of different types of mixes vs | ||||
Cottrell Mix] | ||||
o [TODO Integrating the IP address into the algorithm for releasing | ||||
data] | ||||
o [TODO Prefer aggregating multiple piece of data into a single STH | ||||
when possible] | ||||
o [TODO The importance of Flushing Attacks, and tying in network | ||||
connection, and time interval] | ||||
10.2. Blocking Recommendations | ||||
10.2.1. Frustrating blocking | ||||
When making gossip connections to HTTPS Servers or Trusted Auditors, | ||||
it is desirable to minimize the plaintext metadata in the connection | ||||
that can be used to identify the connection as a gossip connection | ||||
and therefore be of interest to block. Additionally, introducing | ||||
some randomness into client behavior may be important - we assume | ||||
that the adversary is able to inspect the behavior of the HTTPS | ||||
client and understand how it makes gossip connections. | ||||
As an example, if a client, after establishing a TLS connection (and | ||||
receiving an SCT, but not making it's own HTTPS request yet), | ||||
immediately opens a second TLS connection for the purpose of gossip - | ||||
the adversary can reliably block this second connection to block | ||||
gossip without affecting normal browsing. For this reason it is | ||||
recommended to run the gossip protocols over an existing connection | ||||
to the server, making use of connection multiplexing such as HTTP | ||||
Keep-Alives or SPDY. | ||||
Truncation is also a concern -if a client always establishes a TLS | ||||
connection, makes a request, receives a response, and then always | ||||
attempts a gossip communication immediately following the first | ||||
response - truncation will allow an attacker to block gossip | ||||
reliably. | ||||
10.2.2. Responding to possible blocking | ||||
[Not sure here. Maybe this section will get folded up into the | ||||
above. Or maybe it relates to the escape valve. -tjr] | ||||
11. IANA considerations | ||||
[TBD] | ||||
12. Contributors | ||||
The authors would like to thank the following contributors for | The authors would like to thank the following contributors for | |||
valuable suggestions: Al Cutter, Ben Laurie, Benjamin Kaduk, Karen | valuable suggestions: Al Cutter, Ben Laurie, Benjamin Kaduk, Karen | |||
Seo, Magnus Ahltorp, Yan Zhu. | Seo, Magnus Ahltorp, Steven Kent, Yan Zhu. | |||
9. ChangeLog | 13. ChangeLog | |||
9.1. Changes between -01 and -02 | 13.1. Changes between ietf-00 and ietf-01 | |||
o Improve langugage and readability based on feedback from Stephen | ||||
Kent. | ||||
o STH Pollination Proof Fetching defined and indicated as optional. | ||||
o 3-Method Ecosystem section added. | ||||
o Cases with Logs ceasing operation handled. | ||||
o Text on tracking via STH Interaction added. | ||||
o Section with some early recommendations for mixing added. | ||||
o Section detailing blocking connections, frustrating it, and the | ||||
implications added. | ||||
13.2. Changes between -01 and -02 | ||||
o STH Pollination defined. | o STH Pollination defined. | |||
o Trusted Auditor Relationship defined. | o Trusted Auditor Relationship defined. | |||
o Overview section rewritten. | o Overview section rewritten. | |||
o Data flow picture added. | o Data flow picture added. | |||
o Section on privacy considerations expanded. | o Section on privacy considerations expanded. | |||
9.2. Changes between -00 and -01 | 13.3. Changes between -00 and -01 | |||
o Add the SCT feedback mechanism: Clients send SCTs to originating | o Add the SCT feedback mechanism: Clients send SCTs to originating | |||
web server which shares them with auditors. | web server which shares them with auditors. | |||
o Stop assuming that clients see STHs. | o Stop assuming that clients see STHs. | |||
o Don't use HTTP headers but instead .well-known URL's - avoid that | o Don't use HTTP headers but instead .well-known URL's - avoid that | |||
battle. | battle. | |||
o Stop referring to trans-gossip and trans-gossip-transport-https - | o Stop referring to trans-gossip and trans-gossip-transport-https - | |||
too complicated. | too complicated. | |||
o Remove all protocols but HTTPS in order to simplify - let's come | o Remove all protocols but HTTPS in order to simplify - let's come | |||
back and add more later. | back and add more later. | |||
o Add more reasoning about privacy. | o Add more reasoning about privacy. | |||
o Do specify data formats. | o Do specify data formats. | |||
10. References | 14. Normative References | |||
10.1. Normative References | ||||
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate | [RFC-6962-BIS] | |||
Transparency", RFC 6962, June 2013. | Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. | |||
Stradling, "Certificate Transparency", October 2015, | ||||
<https://datatracker.ietf.org/doc/draft-ietf-trans- | ||||
rfc6962-bis/>. | ||||
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data | [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data | |||
Interchange Format", RFC 7159, March 2014. | Interchange Format", RFC 7159, March 2014. | |||
10.2. Informative References | ||||
[THREAT-ANALYSIS] | ||||
Kent, S., "Threat Analysis for Certificate Transparency", | ||||
2015, <https://datatracker.ietf.org/doc/draft-ietf-trans- | ||||
threat-analysis/>. | ||||
Authors' Addresses | Authors' Addresses | |||
Linus Nordberg | Linus Nordberg | |||
NORDUnet | NORDUnet | |||
Email: linus@nordu.net | Email: linus@nordu.net | |||
Daniel Kahn Gillmor | Daniel Kahn Gillmor | |||
ACLU | ACLU | |||
End of changes. 112 change blocks. | ||||
330 lines changed or deleted | 792 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |