idnits 2.17.1 draft-ietf-trans-gossip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6962]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 260: '... client MUST discard SCTs that are n...' RFC 2119 keyword, line 261: '... SHOULD store the remaining SCTs tog...' RFC 2119 keyword, line 265: '...of SCTs. The client MUST add new SCTs...' RFC 2119 keyword, line 266: '... SCTs for the server. The client MUST...' RFC 2119 keyword, line 276: '... The client MUST NOT send the same s...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2015) is 3164 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 203 -- Looks like a reference, but probably isn't: '2' on line 205 -- Looks like a reference, but probably isn't: '3' on line 207 -- Looks like a reference, but probably isn't: '4' on line 209 ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRANS L. Nordberg 3 Internet-Draft NORDUnet 4 Intended status: Experimental D. Gillmor 5 Expires: February 29, 2016 ACLU 6 T. Ritter 8 August 28, 2015 10 Gossiping in CT 11 draft-ietf-trans-gossip-00 13 Abstract 15 This document describes three gossiping mechanisms for Certificate 16 Transparency (CT) [RFC6962]: SCT Feedback, STH Pollination and 17 Trusted Auditor Relationship. 19 SCT Feedback enables HTTPS clients to share Signed Certificate 20 Timestamps (SCTs) (Section 3.2 of [RFC6962]) with CT auditors in a 21 privacy-preserving manner by sending SCTs to originating HTTPS 22 servers which in turn share them with CT auditors. 24 In STH Pollination, HTTPS clients use HTTPS servers as pools sharing 25 Signed Tree Heads (STHs) (Section 3.5 of [RFC6962]) with other 26 connecting clients in the hope that STHs will find their way to 27 auditors and monitors. 29 HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs 30 with trusted auditors or monitors directly, with expectations of 31 privacy sensitive data being handled according to whatever privacy 32 policy is agreed on between client and trusted party. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 29, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology and data flow . . . . . . . . . . . . . . . . . . 4 70 4. Who gossips . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5. What to gossip about and how . . . . . . . . . . . . . . . . 6 72 5.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1.1. HTTPS client to server . . . . . . . . . . . . . . . 6 74 5.1.2. HTTPS server to auditors . . . . . . . . . . . . . . 8 75 5.1.3. SCT Feedback data format . . . . . . . . . . . . . . 9 76 5.2. STH pollination . . . . . . . . . . . . . . . . . . . . . 9 77 5.2.1. HTTPS client STH and Inclusion Proof Fetching . . . . 10 78 5.2.2. Auditor and Monitor Action . . . . . . . . . . . . . 11 79 5.2.3. STH Pollination data format . . . . . . . . . . . . . 11 80 5.3. Trusted Auditor Stream . . . . . . . . . . . . . . . . . 12 81 5.3.1. Trusted Auditor data format . . . . . . . . . . . . . 12 82 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 83 6.1. Privacy considerations . . . . . . . . . . . . . . . . . 12 84 6.1.1. Privacy and SCTs . . . . . . . . . . . . . . . . . . 13 85 6.1.2. Privacy in SCT Feedback . . . . . . . . . . . . . . . 13 86 6.1.3. Privacy for HTTPS clients requesting STHs . . . . . . 13 87 6.1.4. Privacy in STH Pollination . . . . . . . . . . . . . 14 88 6.1.5. Trusted Auditors for HTTPS Clients . . . . . . . . . 14 89 6.1.6. HTTPS Clients as Auditors . . . . . . . . . . . . . . 15 90 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 92 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 9.1. Changes between -01 and -02 . . . . . . . . . . . . . . . 16 94 9.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 10.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 100 1. Introduction 102 The purpose of the protocols in this document is to detect 103 misbehavior by CT logs. In particular, CT logs can misbehave either 104 by rewriting history or by presenting a "split view" of their 105 operations, also known as a partitioning attack [THREAT-ANALYSIS]. 106 CT provides mechanisms for detection of these misbehaviors, but only 107 if the community dependent on the log knows what to do with them. In 108 order for the community to effectively detect log misbehavior, it 109 needs a well-defined way to "gossip" about the activity of the logs 110 that makes use of the available mechanisms. 112 One of the major challenges of any gossip protocol is limiting damage 113 to user privacy. The goal of CT gossip is to publish and distribute 114 information about the logs and their operations, but not to leak any 115 additional information about the operation of any of the other 116 particpants. Privacy of consumers of log information (in particular, 117 of web browsers and other TLS clients) should not be damaged by 118 gossip. 120 This document presents three different, complementary mechanisms for 121 non-log players in the CT ecosystem to exchange information about 122 logs in a manner that preserves the privacy of the non-log players 123 involved. They should provide protective benefits for the system as 124 a whole even if their adoption is not universal. 126 2. Overview 128 Public append-only untrusted logs have to be monitored for 129 consistency, i.e., that they should never rewrite history. 130 Additionally, monitors and other log clients need to exchange 131 information about monitored logs in order to be able to detect a 132 partitioning attack. 134 A partitioning attack is when a log serves different views of the log 135 to different clients. Each client would be able to verify the 136 append-only nature of the log while in the extreme case being the 137 only client seeing this particular view. 139 Gossiping about what's known about logs helps solve the problem of 140 detecting malicious or compromised logs mounting such a partitioning 141 attack. We want some side of the partitioned tree, and ideally both 142 sides, to see the other side. 144 Disseminating known information about a log poses a potential threat 145 to the privacy of end users. Some data of interest (e.g. SCTs) are 146 linkable to specific log entries and thereby to specific sites, which 147 makes them privacy-sensitive. Gossip about this data has to take 148 privacy considerations into account in order not to leak associations 149 between users of the log (e.g., web browsers) and certificate holders 150 (e.g., web sites). Even sharing STHs (which do not link to specific 151 log entries) can be problematic - user tracking by fingerprinting 152 through rare STHs is one potential attack. 154 However, there is no loss in privacy if a client sends SCTs for a 155 given site to the site corresponding to the SCT, because the site's 156 access logs would already indicate that the client is accessing that 157 site. In this way a site can accumulate records of SCTs that have 158 been issued by various logs for that site, providing a consolidated 159 repository of SCTs which can be queried by auditors. 161 Sharing an STH is considered reasonably safe from a privacy 162 perspective as long as the same STH is shared by a large number of 163 other clients. This "safety in numbers" is achieved by requiring 164 gossip only for STHs of a certain "freshness" and limiting the 165 frequency by which logs can issue STHs. 167 3. Terminology and data flow 169 This document relies on terminology and data structures defined in 170 [RFC6962], including STH, SCT, Version, LogID, SCT timestamp, 171 CtExtensions, SCT signature, Merkle Tree Hash. 173 The following picture shows how certificates, SCTs and STHs flow 174 through a CT system with SCT Feedback and STH Pollination. It does 175 not show what goes in the Trusted Auditor Relationship stream. 177 +- Cert ---- +----------+ 178 | | CA | ----------+ 179 | + SCT -> +----------+ | 180 v | Cert [& SCT] 181 +----------+ | 182 | Log | ---------- SCT -----------+ 183 +----------+ v 184 | ^ +----------+ 185 | | SCT & Certs --- | Website | 186 | |[1] | +----------+ 187 | |[2] STH ^ | 188 | |[3] v | | 189 | | +----------+ | | 190 | +--------> | Auditor | | HTTPS traffic 191 | +----------+ | | 192 | / | SCT 193 | / SCT & Certs | 194 Log entries / | | 195 | / STH STH 196 v /[4] | | 197 +----------+ | v 198 | Monitor | +----------+ 199 +----------+ | Browser | 200 +----------+ 202 # Auditor Log 203 [1] |--- get-sth ------------------->| 204 |<-- STH ------------------------| 205 [2] |--- leaf hash + tree size ----->| 206 |<-- index + inclusion proof --->| 207 [3] |--- tree size 1 + tree size 2 ->| 208 |<-- consistency proof ----------| 209 [4] SCT, cert and STH among multiple Auditors and Monitors 211 4. Who gossips 213 o HTTPS clients and servers (SCT Feedback and STH Pollination) 215 o HTTPS servers and CT auditors (SCT Feedback) 217 o CT auditors and monitors (Trusted Auditor Relationship) 219 Additionally, some HTTPS clients may engage with an auditor who they 220 trust with their privacy: 222 o HTTPS clients and CT auditors (Trusted Auditor Relationship) 224 5. What to gossip about and how 226 There are three separate gossip streams: 228 o SCT Feedback, transporting SCTs and certificate chains from HTTPS 229 clients to CT auditors/monitors via HTTPS servers. 231 o STH Pollination, HTTPS clients and CT auditors/monitors using 232 HTTPS servers as STH pools for exchanging STHs. 234 o Trusted Auditor Stream, HTTPS clients communicating directly with 235 trusted CT auditors/monitors sharing SCTs, certificate chains and 236 STHs. 238 5.1. SCT Feedback 240 The goal of SCT Feedback is for clients to share SCTs and certificate 241 chains with CT auditors and monitors in a privacy-preserving manner. 243 HTTPS clients store SCTs and certificate chains they see and later 244 send them to the originating HTTPS server by posting them to a .well- 245 known URL. This is described in Section 5.1.1. Note that clients 246 send the same SCTs and chains to servers multiple times with the 247 assumption that a potential man-in-the-middle attack eventually will 248 cease so that an honest server will receive collected malicious SCTs 249 and certificate chains. 251 HTTPS servers store SCTs and certificate chains received from clients 252 and later share them with CT auditors by either posting them or 253 making them available on a .well-known URL. This is described in 254 Section 5.1.2. 256 5.1.1. HTTPS client to server 258 An HTTPS client connects to an HTTPS server for a particular domain. 259 The client receives a set of SCTs as part of the TLS handshake. The 260 client MUST discard SCTs that are not signed by a known log and 261 SHOULD store the remaining SCTs together with the corresponding 262 certificate chain for later use in feedback. 264 When the client later reconnects to any HTTPS server for the same 265 domain it again receives a set of SCTs. The client MUST add new SCTs 266 from known logs to its store of SCTs for the server. The client MUST 267 send to the server the ones in the store that are for that server and 268 were not received from that server. 270 [ TODO: fix the above paragraph - it is vague and confusing. maybe 271 an example including a client caching at most one SCT per host+log 272 would clarify ] 274 Note that the SCT store also contains SCTs received in certificates. 276 The client MUST NOT send the same set of SCTs to the same server more 277 often than TBD. [benl: "sent to the server" only really counts if 278 the server presented a valid SCT in the handshake and the certificate 279 is known to be unrevoked (which will be hard for a MitM to sustain)] 280 [TODO: expand on rate/resource limiting motivation] 282 An SCT MUST NOT be sent to any other HTTPS server than one serving 283 the domain that the certificate signed by the SCT refers to. This 284 would lead to two types of privacy leaks. First, the server 285 receiving the SCT would learn about other sites visited by the HTTPS 286 client. Secondly, auditors or monitors receiving SCTs from the HTTPS 287 server would learn information about the other HTTPS servers visited 288 by its clients. 290 If the HTTPS client has configuration options for not sending cookies 291 to third parties, SCTs MUST be treated as cookies with respect to 292 this setting. [TODO: expand on why - local storage cleanup; more?] 294 SCTs and corresponding certificates are POSTed to the originating 295 HTTPS server at the well-known URL: 297 https:///.well-known/ct/v1/sct-feedback 299 The data sent in the POST is defined in Section 5.1.3. 301 HTTPS servers perform a number of sanity checks on SCTs from clients 302 before storing them: 304 1. if a bit-wise compare of an SCT plus chain matches a pair already 305 in the store, this SCT and chain pair MAY be discarded 307 2. if the SCT can't be verified to be a valid SCT for the 308 accompanying leaf cert, issued by a known log, the SCT SHOULD be 309 discarded 311 3. if the leaf cert is not for a domain that the server is 312 authoritative for, the SCT MUST be discarded 314 Check number 1 is for detecting duplicates. It's important to note 315 that the check must be on pairs of SCT and chain in order to catch 316 different chains accompanied by the same SCT. [XXX why is this 317 important?] 318 Check number 2 is to prevent spamming attacks where an adversary can 319 fill up the store prior to attacking a client, or a denial of service 320 attack on the server's storage space. 322 Check number 3 is to help malfunctioning clients from leaking which 323 sites they visit and additionally to prevent spamming attacks. 325 Note that an HTTPS server MAY perform a certificate chain validation 326 on a submitted certificate chain, and if it matches a trust root 327 configured on the server (but is otherwise unknown to the server), 328 the HTTPS server MAY store the certificate chain and MAY choose to 329 store any submitted SCTs even if they are unable to be verified. The 330 risk of spamming and denial of service can be mitigated by 331 configuring the server with all known acceptable certificates (or 332 certificate hashes). 334 5.1.2. HTTPS server to auditors 336 HTTPS servers receiving SCTs from clients SHOULD share SCTs and 337 certificate chains with CT auditors by either providing the well- 338 known URL: 340 https:///.well-known/ct/v1/collected-sct-feedback 342 or by HTTPS POSTing them to a number of preconfigured auditors. This 343 allows an HTTPS server to choose between an active push model or a 344 passive pull model. 346 The data received in a GET of the well-known URL or sent in the POST 347 is defined in Section 5.1.3. 349 HTTPS servers SHOULD share all SCTs and accompanying certificate 350 chains they see that pass the checks in Section 5.1.1. 352 HTTPS servers MUST NOT share any other data that they may learn from 353 the submission of SCT Feedback by HTTPS clients. 355 Auditors SHOULD provide the following URL accepting HTTPS POSTing of 356 SCT feedback data: 358 https:///ct/v1/sct-feedback 360 Auditors SHOULD regularly poll HTTPS servers at the well-known 361 collected-sct-feedback URL. The frequency of the polling and how to 362 determine which domains to poll is outside the scope of this 363 document. However, the selection MUST NOT be influenced by potential 364 HTTPS clients connecting directly to the auditor, as it would reveal 365 private information provided by the clients. 367 5.1.3. SCT Feedback data format 369 The data shared between HTTPS clients and servers as well as between 370 HTTPS servers and CT auditors/monitors is a JSON object [RFC7159] 371 with the following content: 373 o sct_feedback: An array of objects consisting of 375 * x509_chain: An array of base64-encoded X.509 certificates. The 376 first element is the end-entity certificate, the second chains 377 to the first and so on. 379 * sct_data: An array of objects consisting of the base64 380 representation of the binary SCT data as defined in [RFC6962] 381 Section 3.2. 383 The 'x509_chain' element MUST contain the leaf certificate and the 384 full chain to a known root. 386 5.2. STH pollination 388 The goal of sharing Signed Tree Heads (STHs) through pollination is 389 to share STHs between HTTPS clients, CT auditors, and monitors in a 390 privacy-preserving manner. 392 HTTPS servers supporting the protocol act as STH pools. HTTPS 393 clients and others in the possesion of STHs should pollinate STH 394 pools by sending STHs to them, and retrieving new STHs to send to new 395 servers. CT auditors and monitors should retrieve STHs from pools by 396 downloading STHs from them. 398 STH Pollination is carried out by sending STHs to HTTPS servers 399 supporting the protocol, and retrieving new STHs. In the case of 400 HTTPS clients, STHs are sent in an already established TLS session. 401 This makes it hard for an attacker to disrupt STH gossiping without 402 also disturbing ordinary secure browsing (https://). 404 STHs are sent by POSTing them to the .well-known URL: 406 https:///.well-known/ct/v1/sth-pollination 408 The data sent in the POST is defined in Section 5.2.3. 410 The response contains zero or more STHs in the same format, described 411 in Section 5.2.3. 413 An HTTPS client may acquire STHs by several methods: 415 o in replies to pollination POSTs; 417 o asking its supported logs for the current STH directly or 418 indirectly; 420 o via some other (currently unspecified) mechanism. 422 HTTPS clients (who have STHs), CT auditors, and monitors SHOULD 423 pollinate STH pools with STHs. Which STHs to send and how often 424 pollination should happen is regarded as policy and out of scope for 425 this document with exception of certain privacy concerns. 427 An HTTPS client could be tracked by giving it a unique or rare STH. 428 To address this concern, we place restrictions on different 429 components of the system to ensure an STH will not be rare. 431 o Logs cannot issue STHs too frequently. This is restricted to 1 432 per hour. 434 o HTTPS clients silently ignore STHs which are not fresh. 436 An STH is considered fresh iff its timestamp is less than 14 days in 437 the past. Given a maximum STH issuance rate of one per hour, an 438 attacker has 336 unique STHs per log for tracking. 440 When multiplied by the number of logs that a client accepts STHs for, 441 this number of unique STHs grow and the negative privacy implications 442 grow with it. It's important that this is taken into account when 443 logs are chosen for default settings in HTTPS clients. 445 [TBD urge HTTPS clients to store STHs retrieved in responses?] 447 [TBD share inclusion proofs and consistency proofs too?] 449 5.2.1. HTTPS client STH and Inclusion Proof Fetching 451 An HTTPS client retrieves SCTs from an HTTPS server, and must obtain 452 an inclusion proof to an STH in order to verify the promise made by 453 the SCT. This retrieval mechanism reveals the client's browsing 454 habits when the client requests the proof diretly from the log. To 455 mitigate this risk, an HTTPS client MUST retrieve the proof in a 456 manner that disguises the client from the log. 458 Additionally, for this inclusion proof to be acceptable to the 459 client, the inclusion proof MUST reference a STH that is within the 460 acceptable freshness interval. 462 Depending on the client's DNS provider, DNS may provide an 463 appropriate intermediate layer that obfuscates the linkability 464 between the user of the client and the request for inclusion (while 465 at the same time providing a caching layer for oft-requested 466 inclusion proofs.) 468 Also Tor. 470 5.2.2. Auditor and Monitor Action 472 Auditors and Monitors participate in STH pollination by retrieving 473 STHs from HTTPS servers. They verify that the STH is valid by 474 checking the signature, and requesting a consistency proof from the 475 STH to the most recent STH. 477 After retrieving the consistency proof to the most recent STH, they 478 SHOULD pollinate this new STH among participating HTTPS Servers. In 479 this way, as STHs "age out" and are no longer fresh, their "lineage" 480 continues to be tracked in the system. 482 5.2.3. STH Pollination data format 484 The data sent from HTTPS clients and CT monitors and auditors to 485 HTTPS servers is a JSON object [RFC7159] with the following content: 487 o sths - an array of 0 or more fresh STH objects [XXX recently 488 collected] from the log associated with log_id. Each of these 489 objects consists of 491 * sth_version: Version as defined in [RFC6962] Section 3.2, as a 492 number. The version of the protocol to which the sth_gossip 493 object conforms. 495 * tree_size: The size of the tree, in entries, as a number. 497 * timestamp: The timestamp of the STH as defined in [RFC6962] 498 Section 3.2, as a number. 500 * sha256_root_hash: The Merkle Tree Hash of the tree as defined 501 in [RFC6962] Section 2.1, as a base64 encoded string. 503 * tree_head_signature: A TreeHeadSignature as defined in 504 [RFC6962] Section 3.5 for the above data, as a base64 encoded 505 string. 507 * log_id: LogID as defined in [RFC6962] Section 3.2, as a base64 508 encoded string. 510 [XXX An STH is considered recently collected iff TBD.] 512 5.3. Trusted Auditor Stream 514 HTTPS clients MAY send SCTs and cert chains, as well as STHs, 515 directly to auditors. Note that there are privacy implications in 516 doing so, these are outlined in Section 6.1.1 and Section 6.1.5. 518 The most natural trusted auditor arrangement arguably is a web 519 browser that is "logged in to" a provider of various internet 520 services. Another equivalent arrangement is a trusted party like a 521 corporation to which an employee is connected through a VPN or by 522 other similar means. A third might be individuals or smaller groups 523 of people running their own services. In such a setting, retrieving 524 STHs and inclusion proofs from that third party in order to validate 525 SCTs could be considered reasonable from a privacy perspective. The 526 HTTPS client does its own auditing and might additionally share SCTs 527 and STHs with the trusted party to contribute to herd immunity. 528 Here, the ordinary [RFC6962] protocol is sufficient for the client to 529 do the auditing while SCT Feedback and STH Pollination can be used in 530 whole or in parts for the gossip part. 532 Another well established trusted party arrangement on the internet 533 today is the relation between internet users and their providers of 534 DNS resolver services. DNS resolvers are typically provided by the 535 internet service provider (ISP) used, which by the nature of name 536 resolving already know a great deal about which sites their users 537 visit. As mentioned in Section XXX, in order for HTTPS clients to be 538 able to retrieve inclusion proofs for certificates in a privacy 539 preserving manner, logs could expose a DNS interface in addition to 540 the ordinary HTTPS interface. An informal writeup of such a protocol 541 can be found at XXX. 543 5.3.1. Trusted Auditor data format 545 [TBD specify something here or leave this for others?] 547 6. Security considerations 549 6.1. Privacy considerations 551 The most sensitive relationships in the CT ecosystem are the 552 relationships between HTTPS clients and HTTPS servers. Client-server 553 relationships can be aggregated into a network graph with potentially 554 serious implications for correlative de-anonymisation of clients and 555 relationship-mapping or clustering of servers or of clients. 557 6.1.1. Privacy and SCTs 559 An SCT contains information that links it to a particular web site. 560 Because the client-server relationship is sensitive, gossip between 561 clients and servers about unrelated SCTs is risky. Therefore, a 562 client with an SCT for a given server should transmit that 563 information in only two channels: to a server associated with the SCT 564 itself; and to a trusted CT auditor, if one exists. 566 6.1.2. Privacy in SCT Feedback 568 SCTs introduce yet another mechanism for HTTPS servers to store state 569 on an HTTPS client, and potentially track users. HTTPS clients which 570 allow users to clear history or cookies associated with an origin 571 MUST clear stored SCTs associated with the origin as well. 573 Auditors should treat all SCTs as sensitive data. SCTs received 574 directly from an HTTPS client are especially sensitive, because the 575 auditor is a trusted by the client to not reveal their associations 576 with servers. Auditors MUST NOT share such SCTs in any way, 577 including sending them to an external log, without first mixing them 578 with multiple other SCTs learned through submissions from multiple 579 other clients. The details of mixing SCTs are TBD. 581 There is a possible fingerprinting attack where a log issues a unique 582 SCT for targeted log client(s). A colluding log and HTTPS server 583 operator could therefore be a threat to the privacy of an HTTPS 584 client. Given all the other opportunities for HTTPS servers to 585 fingerprint clients - TLS session tickets, HPKP and HSTS headers, 586 HTTP Cookies, etc. - this is acceptable. 588 The fingerprinting attack described above could be avoided by 589 requiring that logs i) MUST return the same SCT for a given cert 590 chain ([RFC6962] Section 3) and ii) use a deterministic signature 591 scheme when signing the SCT ([RFC6962] Section 2.1.4). 593 There is another similar fingerprinting attack where an HTTPS server 594 tracks a client by using a variation of cert chains. The risk for 595 this attack is accepted on the same grounds as the unique SCT attack 596 described above. [XXX any mitigations possible here?] 598 6.1.3. Privacy for HTTPS clients requesting STHs 600 An HTTPS client that does not act as an auditor should only request 601 an STH from a CT log that it accepts SCTs from. An HTTPS client 602 should regularly [XXX how regularly? This has operational 603 implications for log operators] request an STH from all logs it is 604 willing to accept, even if it has seen no SCTs from that log. 606 6.1.4. Privacy in STH Pollination 608 An STH linked to an HTTPS client may indicate the following about 609 that client: 611 o that the client gossips; 613 o that the client been using CT at least until the time that the 614 timestamp and the tree size indicate; 616 o that the client is talking, possibly indirectly, to the log 617 indicated by the tree hash; 619 o which software and software version is being used. 621 There is a possible fingerprinting attack where a log issues a unique 622 STH for a targeted log auditor or HTTPS client. This is similar to 623 the fingerprinting attack described in Section 6.1.2, but it is 624 mitigated by the following factors: 626 o the relationship between auditors and logs is not sensitive in the 627 way that the relationship between HTTPS clients and HTTPS servers 628 is; 630 o because auditors regularly exchange STHs with each other, the re- 631 appearance of a targeted STH from some auditor does not imply that 632 the auditor was the original one targeted by the log; 634 o an HTTPS client's relationship to a log is not sensitive in the 635 way that its relationship to an HTTPS server is. As long as the 636 client does not query the log for anything other than individual 637 STHs, the client should not leak anything else to the log itself. 638 However, a log and an HTTPS server which are collaborating could 639 use this technique to fingerprint a targeted HTTPS client. 641 Note that an HTTPS client in the configuration described in this 642 document doesn't make direct use of the STH itself. Its fetching of 643 the STH and reporting via STH Pollination provides a benefit to the 644 CT ecosystem as a whole by providing oversight on logs, but the HTTPS 645 client itself will not necessarily derive direct benefit. 647 6.1.5. Trusted Auditors for HTTPS Clients 649 Some HTTPS clients may choose to use a trusted auditor. This trust 650 relationship leaks a certain amount of information from the client to 651 the auditor. In particular, it is likely to identify the web sites 652 that the client has visited to the auditor. Some clients may already 653 share this information to a third party, for example, when using a 654 server to synchronize browser history across devices in a server- 655 visible way, or when doing DNS lookups through a trusted DNS 656 resolver. For clients with such a relationship already established, 657 sending SCT Feedback to the same organization does not appear to leak 658 any additional information to the trusted third party. 660 Clients who wish to contact an auditor without associating their 661 identities with their SCT Feedback may wish to use an anonymizing 662 network like Tor to submit SCT Feedback to the auditor. Auditors 663 SHOULD accept SCT Feedback that arrives over such anonymizing 664 networks. 666 Clients sending feedback to an auditor may prefer to reduce the 667 temporal granularity of the history leakage to the auditor by caching 668 and delaying their SCT Feedback reports. This strategy is only as 669 effective as the granularity of the timestamps embedded in the SCTs 670 and STHs. 672 6.1.6. HTTPS Clients as Auditors 674 Some HTTPS Clients may choose to act as Auditors themselves. A 675 Client taking on this role needs to consider the following: 677 o an Auditing HTTPS Client potentially leaks their history to the 678 logs that they query. Querying the log through a cache or a proxy 679 with many other users may avoid this leakage, but may leak 680 information to the cache or proxy, in the same way that an non- 681 Auditing HTTPS Client leaks information to a trusted Auditor. 683 o an effective Auditor needs a strategy about what to do in the 684 event that it discovers misbehavior from a log. Misbehavior from 685 a log involves the log being unable to provide either (a) a 686 consistency proof between two valid STHs or (b) an inclusion proof 687 for a certificate to an STH any time after the log's MMD has 688 elapsed from the issuance of the SCT. The log's inability to 689 provide either proof will not be externally cryptographically- 690 verifiable, as it may be indistinguishable from a network error. 692 7. IANA considerations 694 TBD 696 8. Contributors 698 The authors would like to thank the following contributors for 699 valuable suggestions: Al Cutter, Ben Laurie, Benjamin Kaduk, Karen 700 Seo, Magnus Ahltorp, Yan Zhu. 702 9. ChangeLog 704 9.1. Changes between -01 and -02 706 o STH Pollination defined. 708 o Trusted Auditor Relationship defined. 710 o Overview section rewritten. 712 o Data flow picture added. 714 o Section on privacy considerations expanded. 716 9.2. Changes between -00 and -01 718 o Add the SCT feedback mechanism: Clients send SCTs to originating 719 web server which shares them with auditors. 721 o Stop assuming that clients see STHs. 723 o Don't use HTTP headers but instead .well-known URL's - avoid that 724 battle. 726 o Stop referring to trans-gossip and trans-gossip-transport-https - 727 too complicated. 729 o Remove all protocols but HTTPS in order to simplify - let's come 730 back and add more later. 732 o Add more reasoning about privacy. 734 o Do specify data formats. 736 10. References 738 10.1. Normative References 740 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 741 Transparency", RFC 6962, June 2013. 743 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 744 Interchange Format", RFC 7159, March 2014. 746 10.2. Informative References 748 [THREAT-ANALYSIS] 749 Kent, S., "Threat Analysis for Certificate Transparency", 750 2015, . 753 Authors' Addresses 755 Linus Nordberg 756 NORDUnet 758 Email: linus@nordu.net 760 Daniel Kahn Gillmor 761 ACLU 763 Email: dkg@fifthhorseman.net 765 Tom Ritter 767 Email: tom@ritter.vg