idnits 2.17.1 draft-ietf-trans-gossip-01.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 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 301: '...LS handshake. The client MUST discard...' RFC 2119 keyword, line 302: '...y a log known to the client and SHOULD...' RFC 2119 keyword, line 307: '... set of SCTs. The client MUST add new...' RFC 2119 keyword, line 309: '... MUST send to the server any SCTs in...' RFC 2119 keyword, line 320: '... The client MUST NOT send the same s...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2015) is 3112 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 231 -- Looks like a reference, but probably isn't: '2' on line 233 -- Looks like a reference, but probably isn't: '3' on line 235 -- Looks like a reference, but probably isn't: '4' on line 237 == Missing Reference: 'X' is mentioned on line 1088, but not defined == Missing Reference: 'Y' is mentioned on line 1088, but not defined == Missing Reference: 'Z' is mentioned on line 1088, but not defined == Missing Reference: 'TBD' is mentioned on line 1144, but not defined ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 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: April 22, 2016 ACLU 6 T. Ritter 8 October 20, 2015 10 Gossiping in CT 11 draft-ietf-trans-gossip-01 13 Abstract 15 The logs in Certificate Transparency are untrusted in the sense that 16 the users of the system don't have to trust that they behave 17 correctly since the behaviour of a log can be verified to be correct. 19 This document tries to solve the problem with logs presenting a 20 "split view" of their operations. It describes three gossiping 21 mechanisms for Certificate Transparency: SCT Feedback, STH 22 Pollination and Trusted Auditor Relationship. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 22, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Defining the problem . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Terminology and data flow . . . . . . . . . . . . . . . . . . 5 62 5. Who gossips with whom . . . . . . . . . . . . . . . . . . . . 6 63 6. What to gossip about and how . . . . . . . . . . . . . . . . 6 64 7. Gossip Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1.1. HTTPS client to server . . . . . . . . . . . . . . . 7 67 7.1.2. HTTPS server to auditors . . . . . . . . . . . . . . 9 68 7.1.3. SCT Feedback data format . . . . . . . . . . . . . . 10 69 7.2. STH pollination . . . . . . . . . . . . . . . . . . . . . 10 70 7.2.1. HTTPS Clients and Proof Fetching . . . . . . . . . . 12 71 7.2.2. STH Pollination without Proof Fetching . . . . . . . 13 72 7.2.3. Auditor and Monitor Action . . . . . . . . . . . . . 13 73 7.2.4. STH Pollination data format . . . . . . . . . . . . . 13 74 7.3. Trusted Auditor Stream . . . . . . . . . . . . . . . . . 14 75 7.3.1. Trusted Auditor data format . . . . . . . . . . . . . 14 76 8. 3-Method Ecosystem . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 15 78 8.2. STH Pollination . . . . . . . . . . . . . . . . . . . . . 15 79 8.3. Trusted Auditor Relationship . . . . . . . . . . . . . . 16 80 8.4. Interaction . . . . . . . . . . . . . . . . . . . . . . . 17 81 9. Security considerations . . . . . . . . . . . . . . . . . . . 17 82 9.1. Censorship/Blocking considerations . . . . . . . . . . . 17 83 9.2. Privacy considerations . . . . . . . . . . . . . . . . . 19 84 9.2.1. Privacy and SCTs . . . . . . . . . . . . . . . . . . 19 85 9.2.2. Privacy in SCT Feedback . . . . . . . . . . . . . . . 19 86 9.2.3. Privacy for HTTPS clients performing STH Proof 87 Fetching . . . . . . . . . . . . . . . . . . . . . . 20 88 9.2.4. Privacy in STH Pollination . . . . . . . . . . . . . 20 89 9.2.5. Privacy in STH Interaction . . . . . . . . . . . . . 21 90 9.2.6. Trusted Auditors for HTTPS Clients . . . . . . . . . 21 91 9.2.7. HTTPS Clients as Auditors . . . . . . . . . . . . . . 22 92 10. Policy Recommendations . . . . . . . . . . . . . . . . . . . 22 93 10.1. Mixing Recommendations . . . . . . . . . . . . . . . . . 22 94 10.2. Blocking Recommendations . . . . . . . . . . . . . . . . 24 95 10.2.1. Frustrating blocking . . . . . . . . . . . . . . . . 24 96 10.2.2. Responding to possible blocking . . . . . . . . . . 24 98 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 25 99 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 100 13. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 13.1. Changes between ietf-00 and ietf-01 . . . . . . . . . . 25 102 13.2. Changes between -01 and -02 . . . . . . . . . . . . . . 25 103 13.3. Changes between -00 and -01 . . . . . . . . . . . . . . 25 104 14. Normative References . . . . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 107 1. Introduction 109 The purpose of the protocols in this document, collectively referred 110 to as CT Gossip, is to detect certain misbehavior by CT logs. In 111 particular, CT Gossip aims to detect logs that are providing 112 incosistent views to different log clients and logs failing to 113 include submitted certificates within the time period stipulated by 114 MMD. 116 [TODO: enumerate the interfaces used for detecting misbehaviour?] 118 One of the major challenges of any gossip protocol is limiting damage 119 to user privacy. The goal of CT gossip is to publish and distribute 120 information about the logs and their operations, but not to leak any 121 additional information about the operation of any of the other 122 participants. Privacy of consumers of log information (in 123 particular, of web browsers and other TLS clients) should not be 124 undermined by gossip. 126 This document presents three different, complementary mechanisms for 127 non-log elements of the CT ecosystem to exchange information about 128 logs in a manner that preserves the privacy of HTTPS clients. They 129 should provide protective benefits for the system as a whole even if 130 their adoption is not universal. 132 2. Defining the problem 134 When a log provides different views of the log to different clients 135 this is described as a partitioning attack. Each client would be 136 able to verify the append-only nature of the log but, in the extreme 137 case, each client might see a unique view of the log. 139 The CT logs are public, append-only and untrusted and thus have to be 140 monitored for consistency, i.e., they should never rewrite history. 141 Additionally, monitors and other log clients need to exchange 142 information about monitored logs in order to be able to detect a 143 partitioning attack (as described above). 145 Gossiping about log responses to queries helps address the problem of 146 detecting malicious or compromised logs with respect to a 147 partitioning attack. We want some side of the partitioned tree, and 148 ideally both sides, to see the other side. 150 Disseminating information about a log poses a potential threat to the 151 privacy of end users. Some data of interest (e.g. SCTs) are 152 linkable to specific log entries and thereby to specific sites, which 153 makes sharing them with others privacy-sensitive. Gossiping about 154 this data has to take privacy considerations into account in order 155 not to leak associations between users of the log (e.g., web 156 browsers) and certificate holders (e.g., web sites). Even sharing 157 STHs (which do not link to specific log entries) can be problematic - 158 user tracking by fingerprinting through rare STHs is one potential 159 attack (see Section 7.2). 161 3. Overview 163 SCT Feedback enables HTTPS clients to share Signed Certificate 164 Timestamps (SCTs) (Section 3.3 of [RFC-6962-BIS]) with CT auditors in 165 a privacy-preserving manner by sending SCTs to originating HTTPS 166 servers which in turn share them with CT auditors. 168 In STH Pollination, HTTPS clients use HTTPS servers as pools sharing 169 Signed Tree Heads (STHs) (Section 3.6 of [RFC-6962-BIS]) with other 170 connecting clients in the hope that STHs will find their way to 171 auditors and monitors. 173 HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs 174 with trusted auditors or monitors directly, with expectations of 175 privacy sensitive data being handled according to whatever privacy 176 policy is agreed on between client and trusted party. 178 Despite the privacy risks with sharing SCTs there is no loss in 179 privacy if a client sends SCTs for a given site to the site 180 corresponding to the SCT. This is because the site's logs would 181 already indicate that the client is accessing that site. In this way 182 a site can accumulate records of SCTs that have been issued by 183 various logs for that site, providing a consolidated repository of 184 SCTs that could be shared with auditors. Auditors can use this 185 information to detect logs that misbehaves by not including 186 certificates within the time period stipulated by the MMD metadata. 188 Sharing an STH is considered reasonably safe from a privacy 189 perspective as long as the same STH is shared by a large number of 190 other log clients. This "safety in numbers" can be achieved by 191 requiring gossiping of STHs only of a certain "freshness" while also 192 refusing to gossip about STHs from logs with too high an STH issuance 193 frequency (see Section 7.2). 195 4. Terminology and data flow 197 This document relies on terminology and data structures defined in 198 [RFC-6962-BIS], including STH, SCT, Version, LogID, SCT timestamp, 199 CtExtensions, SCT signature, Merkle Tree Hash. 201 The following picture shows how certificates, SCTs and STHs flow 202 through a CT system with SCT Feedback and STH Pollination. It does 203 not show what goes in the Trusted Auditor Relationship stream. 205 +- Cert ---- +----------+ 206 | | CA | ----------+ 207 | + SCT -> +----------+ | 208 v | Cert [& SCT] 209 +----------+ | 210 | Log | ---------- SCT -----------+ 211 +----------+ v 212 | ^ +----------+ 213 | | SCT & Certs --- | Website | 214 | |[1] | +----------+ 215 | |[2] STH ^ | 216 | |[3] v | | 217 | | +----------+ | | 218 | +--------> | Auditor | | HTTPS traffic 219 | +----------+ | | 220 | / | SCT 221 | / SCT & Certs | 222 Log entries / | | 223 | / STH STH 224 v /[4] | | 225 +----------+ | v 226 | Monitor | +----------+ 227 +----------+ | Browser | 228 +----------+ 230 # Auditor Log 231 [1] |--- get-sth ------------------->| 232 |<-- STH ------------------------| 233 [2] |--- leaf hash + tree size ----->| 234 |<-- index + inclusion proof --->| 235 [3] |--- tree size 1 + tree size 2 ->| 236 |<-- consistency proof ----------| 237 [4] SCT, cert and STH among multiple Auditors and Monitors 239 5. Who gossips with whom 241 o HTTPS clients and servers (SCT Feedback and STH Pollination) 243 o HTTPS servers and CT auditors (SCT Feedback) 245 o CT auditors and monitors (Trusted Auditor Relationship) 247 Additionally, some HTTPS clients may engage with an auditor who they 248 trust with their privacy: 250 o HTTPS clients and CT auditors (Trusted Auditor Relationship) 252 6. What to gossip about and how 254 There are three separate gossip streams: 256 o SCT Feedback - transporting SCTs and certificate chains from HTTPS 257 clients to CT auditors/monitors via HTTPS servers. 259 o STH Pollination - HTTPS clients and CT auditors/monitors using 260 HTTPS servers as STH pools for exchanging STHs. 262 o Trusted Auditor Stream, HTTPS clients communicating directly with 263 trusted CT auditors/monitors sharing SCTs, certificate chains and 264 STHs. 266 7. Gossip Mechanisms 268 7.1. SCT Feedback 270 The goal of SCT Feedback is for clients to share SCTs and certificate 271 chains with CT auditors and monitors while still preserving the 272 privacy of the end user. The sharing of SCTs contribute to the 273 overall goal of detecting misbehaving logs by providing auditors and 274 monitors with SCTs from many vantage points, making it possible to 275 catch a higher number of violations of MMD and also catch logs 276 presenting inconsistent views. 278 SCT Feedback is the most privacy-preserving gossip mechanism, as it 279 does not directly expose any links between an end user and the sites 280 they've visisted to any third party. 282 [Here's an alternative to that paragraph: SCT Feedback is the most 283 privacy-preserving gossip mechanism, as it does not create any 284 potential cross-origin tracking mechanisms. ] 285 HTTPS clients store SCTs and certificate chains they see, and later 286 send them to the originating HTTPS server by posting them to a well- 287 known URL (associated with that server), as described in 288 Section 7.1.1. Note that clients will send the same SCTs and chains 289 to servers multiple times with the assumption that a potential man- 290 in-the-middle attack eventually will cease, and an honest server will 291 receive collected malicious SCTs and certificate chains. 293 HTTPS servers store SCTs and certificate chains received from clients 294 and later share them with CT auditors by either posting them to 295 auditors or making them available via a well-known URL. This is 296 described in Section 7.1.2. 298 7.1.1. HTTPS client to server 300 When an HTTPS client connects to an HTTPS server, the client receives 301 a set of SCTs as part of the TLS handshake. The client MUST discard 302 SCTs that are not signed by a log known to the client and SHOULD 303 store the remaining SCTs together with the corresponding certificate 304 chain for later use in SCT Feedback. 306 When the client later reconnects to any HTTPS server for the same 307 domain, it again receives a set of SCTs. The client MUST add new 308 SCTs from known logs to its store of SCTs for the server. The client 309 MUST send to the server any SCTs in the store that are associated 310 with that server but which were not received from that server. 312 [TODO: fix the above paragraph - it is vague and confusing. maybe an 313 example including a client caching at most one SCT per host+log would 314 clarify] 316 [TODO: define "same domain"] 318 Note that the SCT store also contains SCTs received in certificates. 320 The client MUST NOT send the same set of SCTs to the same server more 321 often than TBD. 323 [benl says: "sent to the server" only really counts if the server 324 presented a valid SCT in the handshake and the certificate is known 325 to be unrevoked (which will be hard for a MitM to sustain)] 327 [TODO: expand on rate/resource limiting motivation] 329 Refer to Section 10.1 for recommendations about strategies. 331 An SCT MUST NOT be sent to any other HTTPS server than one serving 332 the domain to which the certificate signed by the SCT refers. Not 333 following this constraint would lead to two types of privacy leaks. 334 First, the server receiving the SCT would learn about other sites 335 visited by the HTTPS client. Secondly, auditors or monitors 336 receiving SCTs from the HTTPS server would learn information about 337 the other HTTPS servers visited by its clients. 339 If the HTTPS client has configuration options for not sending cookies 340 to third parties, SCTs of third parties MUST be treated as cookies 341 with respect to this setting. This prevents third party tracking 342 through the use of SCTs/certificates, which would bypass the cookie 343 policy. 345 SCTs and corresponding certificates are POSTed to the originating 346 HTTPS server at the well-known URL: 348 https:///.well-known/ct/v1/sct-feedback 350 The data sent in the POST is defined in Section 7.1.3. 352 HTTPS servers perform a number of sanity checks on SCTs from clients 353 before storing them: 355 1. if a bit-wise compare of an SCT plus chain matches a pair already 356 in the store, this SCT and chain pair MAY be discarded 358 2. if the SCT can't be verified to be a valid SCT for the 359 accompanying leaf cert, issued by a known log, the SCT SHOULD be 360 discarded 362 3. if the leaf cert is not for a domain for which the server is 363 authoritative, the SCT MUST be discarded 365 Check number 1 is for detecting duplicates and minimizing processing 366 and storage by the server. It's important to note that the check 367 should be on pairs of SCT and chain in order to catch different 368 chains accompanied by the same SCT. This mis-matched chain 369 information may be useful as a diagnostic tool for HTTPS server 370 operators. 372 Check number 2 is to prevent DoS attacks where an adversary can fill 373 up the store prior to attacking a client, or a denial of service 374 attack on the server's storage space. 376 Check number 3 is to help malfunctioning clients from leaking which 377 sites they visit and additionally to prevent DoS attacks. 379 Note that an HTTPS server MAY choose to store a submitted SCT and the 380 accompanying certificate chain even when the SCT can't be verified 381 according to check number 2. One such case would be when a 382 certificate chain validation is performed and the chain ends in a 383 trust anchor configured on the server. In this instance, the server 384 could also be configured to not bother with known-to-be-good (i.e. 385 administratively-vetted) leaf certificates, and only store unknown 386 leaf certificates that chain to a known trust anchor. The risk of 387 spamming and denial of service can be mitigated by configuring the 388 server with all known acceptable certificates (or certificate hashes) 389 applicable to this server. This information may enable a HTTPS 390 server operator to detect attacks or unusual behavior of Certificate 391 Authorities even outside the Certificate Transparency ecosystem. 393 7.1.2. HTTPS server to auditors 395 HTTPS servers receiving SCTs from clients SHOULD share SCTs and 396 certificate chains with CT auditors by either serving them on the 397 well-known URL: 399 https:///.well-known/ct/v1/collected-sct-feedback 401 or by HTTPS POSTing them to a set of preconfigured auditors. This 402 allows an HTTPS server to choose between an active push model or a 403 passive pull model. 405 The data received in a GET of the well-known URL or sent in the POST 406 is defined in Section 7.1.3. 408 HTTPS servers SHOULD share all SCTs and accompanying certificate 409 chains they see that pass the checks in Section 7.1.1. If this is an 410 infeasible amount of data, the server may choose to expire 411 submissions according to an undefined policy. Suggestions for such a 412 policy can be found in Section 10.1. 414 HTTPS servers MUST NOT share any other data that they may learn from 415 the submission of SCT Feedback by HTTPS clients, like the HTTPS 416 client IP address or the time of submission. 418 Auditors SHOULD provide the following URL accepting HTTPS POSTing of 419 SCT feedback data: 421 https:///ct/v1/sct-feedback 423 Auditors SHOULD regularly poll HTTPS servers at the well-known 424 collected-sct-feedback URL. The frequency of the polling and how to 425 determine which domains to poll is outside the scope of this 426 document. However, the selection MUST NOT be influenced by potential 427 HTTPS clients connecting directly to the auditor. For example, if a 428 poll to example.com occurs directly after a client submits an SCT for 429 example.com, an adversary observing the auditor can trivially 430 conclude the activity of the client. 432 7.1.3. SCT Feedback data format 434 The data shared between HTTPS clients and servers, as well as between 435 HTTPS servers and CT auditors/monitors, is a JSON object [RFC7159] 436 with the following content: 438 o sct_feedback: An array of objects consisting of 440 * x509_chain: An array of base64-encoded X.509 certificates. The 441 first element is the end-entity certificate, the second chains 442 to the first and so on. 444 * sct_data: An array of objects consisting of the base64 445 representation of the binary SCT data as defined in 446 [RFC-6962-BIS] Section 3.3. 448 The 'x509_chain' element MUST contain at least the leaf certificate 449 and SHOULD contain the full chain to a root accepted by all of the 450 logs in the set of logs issuing all the SCTs in the 'sct_data' 451 element. 453 Some clients have trust anchors that are locally added (e.g. by an 454 administrator or by the user themselves). A local trust anchors is 455 potentially privacy-sensitive since it may carry information about 456 the specific computer or user. If a certificate is covered by SCTs 457 issued by publicly trusted logs, but it chains to a privacy-sensitive 458 local trust anchor, the client SHOULD submit it as an "x509\_chain" 459 consisting only of the leaf certificate. 461 [TBD: Be strict about what sct_data may contain or is this 462 sufficiently implied by previous sections?] 464 [TBD: There was discussion about including a few field for 465 client->server reporting, which is the exact set and order of 466 certificates sent by the HTTPS server to the client. This is 467 additional diagnostic information that a HTTPS server could use to 468 check it's deployment... but is pretty much useless to CT or gossip. 469 Right now we're not including this, but we're polling server 470 operators to see if they would welcome this data.] 472 7.2. STH pollination 474 The goal of sharing Signed Tree Heads (STHs) through pollination is 475 to share STHs between HTTPS clients, CT auditors, and monitors in 476 while still preserving the privacy of the end user. The sharing of 477 STHs contribute to the overall goal of detecting misbehaving logs by 478 providing CT auditors and monitors with SCTs from many vantage 479 points, making it possible to detect logs that are presenting 480 inconsistent views. 482 HTTPS servers supporting the protocol act as STH pools. HTTPS 483 clients and CT auditors and monitors in the possession of STHs should 484 pollinate STH pools by sending STHs to them, and retrieving new STHs 485 to send to other STH pools. CT auditors and monitors should perform 486 their auditing and monitoring duties by retrieving STHs from pools. 488 STH Pollination is carried out by sending STHs to HTTPS servers 489 supporting the protocol, and retrieving new STHs. In the case of 490 HTTPS clients, STHs SHOULD be sent in an already established TLS 491 session. This makes it hard for an attacker to disrupt STH gossiping 492 without also disturbing ordinary secure browsing (https://). This is 493 discussed more in Section 10.2.1. 495 HTPS clients send STHs to HTTPS servers by POSTing them to the well- 496 known URL: 498 https:///.well-known/ct/v1/sth-pollination 500 The data sent in the POST is defined in Section 7.2.4. 502 The response contains zero or more STHs in the same format, described 503 in Section 7.2.4. 505 An HTTPS client may acquire STHs by several methods: 507 o in replies to pollination POSTs; 509 o asking logs that it recognises for the current STH, either 510 directly (v2/get-sth) or indirectly (for example over DNS) 512 o resolving an SCT and certificate to an STH via an inclusion proof 514 o resolving one STH to another via a consistency proof 516 HTTPS clients (who have STHs), CT auditors, and monitors SHOULD 517 pollinate STH pools with STHs. Which STHs to send and how often 518 pollination should happen is regarded as undefined policy with the 519 exception of privacy concerns explained in the next section. 520 Suggestions for the policy may be found in Section 10.1. 522 An HTTPS client could be tracked by giving it a unique or rare STH. 523 To address this concern, we place restrictions on different 524 components of the system to ensure an STH will not be rare. 526 o HTTPS clients sliently ignore STHs from logs with an STH issuance 527 frequency of more than one STH per hour. Logs use the STH 528 Frequency Count metadata to express this ([RFC-6962-BIS] sections 529 3.6 and 5.1). 531 o HTTPS clients silently ignore STHs which are not fresh. 533 An STH is considered fresh iff its timestamp is less than 14 days in 534 the past. Given a maximum STH issuance rate of one per hour, an 535 attacker has 336 unique STHs per log for tracking. Clients MUST 536 ignore STHs older than 14 days. We consider STHs within this 537 validity window to be personally identifiable data, and STHs outside 538 this window not personally identifiable. 540 A log may cease operation, in which case there will soon be no STH 541 within the validity window. Clients SHOULD perform all three methods 542 of gossip about a log that has ceased operation - it is possible the 543 log was still compromised and gossip can detect that. STH 544 Pollination is the one mechanism where a client must know about a log 545 shutdown. A client who does not know about a log shutdown MUST NOT 546 attempt any heuristic to detect a shutdown. Instead the client MUST 547 be informed about the shutdown from a verifiable source (e.g. a 548 software update). The client SHOULD be provided the final STH issued 549 by the log and SHOULD resolve SCTs and STHs to this final STH. If an 550 SCT or STH cannot be resolved to the final STH... XXX? 552 When multiplied by the number of logs from which a client accepts 553 STHs, this number of unique STHs grow and the negative privacy 554 implications grow with it. It's important that this is taken into 555 account when logs are chosen for default settings in HTTPS clients. 556 This concern is discussed upon in Section 9.2.5. 558 7.2.1. HTTPS Clients and Proof Fetching 560 There are two types of proofs a client may retrieve. 562 An HTTPS client will retrieve SCTs from an HTTPS server, and must 563 obtain an inclusion proof to an STH in order to verify the promise 564 made by the SCT. 566 An HTTPS client may receive SCT bundled with an inclusion proof to a 567 historical STH via an unspecified future mechanism. Because this 568 historical STH is considered personally identifiable information per 569 above, the client must obtain a consistency proof to a more recent 570 STH. 572 If a client requested either proof directly from a log or auditor, it 573 would reveal the client's browsing habits to a third party. To 574 mitigate this risk, an HTTPS client MUST retrieve the proof in a 575 manner that disguises the client. 577 Depending on the client's DNS provider, DNS may provide an 578 appropriate intermediate layer that obfuscates the linkability 579 between the user of the client and the request for inclusion (while 580 at the same time providing a caching layer for oft-requested 581 inclusion proofs.) 583 [TODO: Add a reference to Google's DNS mechanism more proper than 584 http://www.certificate-transparency.org/august-2015-newsletter] 586 Anonymity networks such as Tor also present a mechanism for a client 587 to anonymously retrieve a proof from an auditor or log. 589 7.2.2. STH Pollination without Proof Fetching 591 An HTTPS client MAY participate in STH Pollination without fetching 592 proofs. In this situation, the client receives STHs from a server, 593 applies the same validation logic to them (signed by a known log, 594 within a validity window) and will later pass them to a HTTPS server. 596 When operating in this fashion, the HTTPS client is promoting gossip 597 for Certificate Transparency, but derives no direct benefit itself. 598 In comparison, a client who resolves SCTs or historical STHs to 599 recent STHs and pollinates them is assured that if it was attacked, 600 there is a probability that the ecosystem will detect and respond to 601 the attack (by distrusting the log). 603 7.2.3. Auditor and Monitor Action 605 Auditors and Monitors participate in STH pollination by retrieving 606 STHs from HTTPS servers. They verify that the STH is valid by 607 checking the signature, and requesting a consistency proof from the 608 STH to the most recent STH. 610 After retrieving the consistency proof to the most recent STH, they 611 SHOULD pollinate this new STH among participating HTTPS Servers. In 612 this way, as STHs "age out" and are no longer fresh, their "lineage" 613 continues to be tracked in the system. 615 7.2.4. STH Pollination data format 617 The data sent from HTTPS clients and CT monitors and auditors to 618 HTTPS servers is a JSON object [RFC7159] with the following content: 620 o sths - an array of 0 or more fresh SignedTreeHead's as defined in 621 [RFC-6962-BIS] Section 3.6.1. 623 [XXX An STH is considered fresh iff TBD.] 625 7.3. Trusted Auditor Stream 627 HTTPS clients MAY send SCTs and cert chains, as well as STHs, 628 directly to auditors. Note that there are privacy implications in 629 doing so, these are outlined in Section 9.2.1 and Section 9.2.6. 631 The most natural trusted auditor arrangement arguably is a web 632 browser that is "logged in to" a provider of various internet 633 services. Another equivalent arrangement is a trusted party like a 634 corporation to which an employee is connected through a VPN or by 635 other similar means. A third might be individuals or smaller groups 636 of people running their own services. In such a setting, retrieving 637 proofs from that third party could be considered reasonable from a 638 privacy perspective. The HTTPS client does its own auditing and 639 might additionally share SCTs and STHs with the trusted party to 640 contribute to herd immunity. Here, the ordinary [RFC-6962-BIS] 641 protocol is sufficient for the client to do the auditing while SCT 642 Feedback and STH Pollination can be used in whole or in parts for the 643 gossip part. 645 Another well established trusted party arrangement on the internet 646 today is the relation between internet users and their providers of 647 DNS resolver services. DNS resolvers are typically provided by the 648 internet service provider (ISP) used, which by the nature of name 649 resolving already know a great deal about which sites their users 650 visit. As mentioned in Section XXX, in order for HTTPS clients to be 651 able to retrieve proofs in a privacy preserving manner, logs could 652 expose a DNS interface in addition to the ordinary HTTPS interface. 653 An informal writeup of such a protocol can be found at XXX. 655 7.3.1. Trusted Auditor data format 657 [TBD specify something here or leave this for others?] 659 8. 3-Method Ecosystem 661 The use of three distinct methods for monitoring logs may seem 662 excessive, but each represents a needed component in the CT 663 ecosystem. To understand why, the drawbacks of each component must 664 be outlined. In this discussion we assume that an attacker knows 665 which mechanisms an HTTPS client and HTTPS server implement. 667 8.1. SCT Feedback 669 SCT Feedback requires the cooperation of HTTPS clients and more 670 importantly HTTPS servers. Although SCT Feedback does require a 671 significant amount of server-side logic to respond to the 672 corresponding APIs, this functionality does not require 673 customization, so it may be pre-provides and work out of the box. 674 However, to take full advantage of the system, an HTTPS server would 675 wish to perform some configuration to optimize its operation: 677 o Minimize its disk commitment by whitelisting known SCTs and 678 certificate chains 680 o Maximize its chance of detecting a misissued certificate by 681 configuring a trust store of CAs 683 o Establish a "push" mechanism for POSTing SCTs to Auditors and 684 Monitors 686 These configuration needs, and the simple fact that it would require 687 some deployment of software, means that some percentage of HTTPS 688 servers will not deploy SCT Feedback. 690 If SCT Feedback was the only mechanism in the ecosystem, any server 691 that did not implement the feature, would open itself and its users 692 to attack without any possibility of detection. 694 If SCT Feedback was not deployed, users who wished to have the 695 strongest measure of privacy protection (by disabling STH Pollination 696 Proof Fetching and forgoing a Trusted Auditor) could be attacked 697 without risk of detection. 699 8.2. STH Pollination 701 STH Pollination requires the cooperation of HTTPS clients, HTTPS 702 servers, and logs. 704 For a client to fully participate in STH Pollination, and have this 705 mechanism detect attacks against it, the client must have a way to 706 safely perform Proof Fetching in a privacy preserving manner. The 707 client may pollinate STHs it receives without performing Proof 708 Fetching, but we do not consider this option in this section. 710 HTTPS Servers must deploy software (although, as in the case with SCT 711 Feedback this logic can be pre-provided) and commit some configurable 712 amount of disk space to the endeavor. 714 Logs must provide access to clients to query proofs in a privacy 715 preserving manner, most likely through DNS. 717 Unlike SCT Feedback, the STH Pollination mechanism is not hampered if 718 only a minority of HTTPS servers deploy it. However, it makes an 719 assumption that an HTTPS client performs anonymized Proof Fetching 720 (such as the DNS mechanism discussed). However, any manner that is 721 anonymous for some (such as clients who use shared DNS services such 722 as a large ISP), may not be anonymous for others. 724 For instance, DNS leaks a considerable amount of information 725 (including what data is already present in the cache) in plaintext 726 over the network. For this reason, some percentage of HTTPS clients 727 may choose to not enable the Proof Fetching component of STH 728 pollination. (Although they can still request and send STHs among 729 participating HTTPS servers, as mentioned earlier this affords them 730 no direct benefit.) 732 If STH Pollination was the only mechanism deployed, users that 733 disable it would be able to be attacked without risk of detection. 735 If STH Pollination was not deployed, HTTPS Clients visiting HTTPS 736 Servers who did not deploy SCT Feedback could be attacked without 737 risk of detection. 739 8.3. Trusted Auditor Relationship 741 The Trusted Auditor Relationship is expected to be the rarest gossip 742 mechanism, as an HTTPS Client is providing an unadulterated report of 743 its browsing history to a third party. While there are valid and 744 common reasons for doing so, there is no appropriate way to enter 745 into this relationship without retrieving informed consent from the 746 user. 748 However, the Trusted Auditor Relationship mechanism still provides 749 value to a class of HTTPS Clients. For example, web crawlers have no 750 concept of a "user" and no expectation of privacy. Organizations 751 already performing network monitoring for anomalies or attacks can 752 run their own Trusted Auditor for the same purpose with marginal 753 increase in privacy concerns. 755 The ability to change one's Trusted Auditor is a form of Trust 756 Agility that allows a user to choose who to trust, and be able to 757 revise that decision later without consequence. A Trusted Auditor 758 connection can be made more confidential than DNS (through the use of 759 TLS), and can even be made (somewhat) anonymous through the use of 760 anonymity services such as Tor. (Note that this does ignore the de- 761 anonymization possibilities available from viewing a user's browsing 762 history.) 764 If the Trusted Auditor relationship was the only mechanism deployed, 765 users who do not enable it (the majority) would be able to be 766 attacked without risk of detection. 768 If the Trusted Auditor relationship was not deployed, crawlers and 769 organizations would build it themselves for their own needs. By 770 standardizing it, users who wish to opt-in (for instance those 771 unwilling to participate fully in STH Pollination) can have an 772 interoperable standard they can use to choose and change their 773 trusted auditor. 775 8.4. Interaction 777 The interactions of the mechanisms is thus outlined: 779 HTTPS Clients can be attacked without risk of detection if they do 780 not participate in any of the three mechanisms. 782 HTTPS Clients are afforded the greatest chance of detecting an attack 783 when they either participate in STH Pollination with Proof Fetching 784 or have a Trusted Auditor relationship. Participating in SCT 785 Feedback enables a HTTPS Client to assist in detecting the exact 786 target of an attack, although they do not gain any direct benefit 787 from it. 789 HTTPS Servers that omit SCT Feedback may never learn about targeted 790 attacks against them, even if the attack occurred and the log 791 distrusted. They do gain some herd immunity, enabling them to detect 792 attacks, through their clients participating in STH Pollination or a 793 Trusted Auditor Relationship. 795 When HTTPS Servers omit SCT feedback, it allow a portion of their 796 users to be attacked without detection; the vulnerable users are 797 those who do not participate in STH Pollination with Proof Fetching 798 and that not have a Trusted Auditor relationship. 800 9. Security considerations 802 9.1. Censorship/Blocking considerations 804 We assume a network attacker who is able to fully control the 805 client's internet connection for some period of time - including 806 selectively blocking requests to certain hosts and truncating TLS 807 connections based on information observed or guessed about client 808 behavior. In order to successfully detect log misbehavior, the 809 gossip mechanisms must still work even in these conditions. 811 There are several gossip connections that can be blocked: 813 1. Clients sending SCTs to servers in SCT Feedback 815 2. Servers sending SCTs to auditors in SCT Feedback (server push 816 mechanism) 818 3. Servers making SCTs available to auditors (auditor pull 819 mechanism) 821 4. Clients fetching proofs in STH Pollination 823 5. Clients sending STHs to servers in STH Pollination 825 6. Servers sending STHs to clients in STH Pollination 827 7. Clients sending SCTs to Trusted Auditors 829 If a party cannot connect to another party, it can be assured that 830 the connection did not succeed. While it may not have been 831 maliciously blocked, it knows the transaction did not succeed. 832 Mechanisms which result in a positive affirmation from the recipient 833 that the transaction succeeded allow confirmation that a connection 834 was not blocked. In this situation, the party can factor this into 835 strategies suggested in Section 10.1 and in Section 10.2.2. 837 The connections that allow positive affirmation are 1, 2, 4, 5, and 838 7. 840 More insidious is blocking the connections that do not allow positive 841 confirmation: 3 and 6. An attacker may truncate a or drop a response 842 from a server to a client, such that the server believes it has 843 shared data with the recipient, when it has not. However, in both 844 scenatios (3 and 6), the server cannot distinguish the client as a 845 cooperating member of the CT ecosystem or as an attacker performing a 846 sybil attack, aiming to flush the server's data store. Therefore the 847 fact that these connections can be undetectably blocked does not 848 actually alter the threat model of servers responding to these 849 requests. The choice of algorithm to release data is crucial to 850 protect against these attacks, strategies are suggested in 851 Section 10.1. 853 Handling censorship and network blocking (which is indistinguishable 854 from network error) is relegated to the implementation policy chosen 855 by clients. Suggestions for client behavior are specified in 856 Section 10.2. 858 9.2. Privacy considerations 860 CT Gossip deals with HTTPS Clients which are trying to share 861 indicators that correspond to their browsing history. The most 862 sensitive relationships in the CT ecosystem are the relationships 863 between HTTPS clients and HTTPS servers. Client-server relationships 864 can be aggregated into a network graph with potentially serious 865 implications for correlative de-anonymisation of clients and 866 relationship-mapping or clustering of servers or of clients. 868 There are, however, certain clients that do not require privacy 869 protection. Examples of these clients are web crawlers or robots but 870 even in this case, the method by which these clients crawl the web 871 may in fact be considered sensitive information. In general, it is 872 better to err on the side of safety, and not assume a client is okay 873 with giving up its privacy. 875 9.2.1. Privacy and SCTs 877 An SCT contains information that links it to a particular web site. 878 Because the client-server relationship is sensitive, gossip between 879 clients and servers about unrelated SCTs is risky. Therefore, a 880 client with an SCT for a given server should transmit that 881 information in only two channels: to a server associated with the SCT 882 itself; and to a trusted CT auditor, if one exists. 884 9.2.2. Privacy in SCT Feedback 886 SCTs introduce yet another mechanism for HTTPS servers to store state 887 on an HTTPS client, and potentially track users. HTTPS clients which 888 allow users to clear history or cookies associated with an origin 889 MUST clear stored SCTs associated with the origin as well. 891 Auditors should treat all SCTs as sensitive data. SCTs received 892 directly from an HTTPS client are especially sensitive, because the 893 auditor is a trusted by the client to not reveal their associations 894 with servers. Auditors MUST NOT share such SCTs in any way, 895 including sending them to an external log, without first mixing them 896 with multiple other SCTs learned through submissions from multiple 897 other clients. Suggestions for mixing SCTs are presented in 898 Section 10.1. 900 There is a possible fingerprinting attack where a log issues a unique 901 SCT for targeted log client(s). A colluding log and HTTPS server 902 operator could therefore be a threat to the privacy of an HTTPS 903 client. Given all the other opportunities for HTTPS servers to 904 fingerprint clients - TLS session tickets, HPKP and HSTS headers, 905 HTTP Cookies, etc. - this is acceptable. 907 The fingerprinting attack described above would be mitigated by a 908 requirement that logs MUST use a deterministic signature scheme when 909 signing SCTs ([RFC-6962-BIS] Section 2.1.4). A log signing using RSA 910 is not required to use a deterministic signature scheme. 912 Since logs are allowed to issue a new SCT for a certificate already 913 present in the log, mandating deterministic signatures does not stop 914 this fingerprinting attack altogether. It does make the attack 915 harder to pull off without being detected though. 917 There is another similar fingerprinting attack where an HTTPS server 918 tracks a client by using a variation of cert chains. The risk for 919 this attack is accepted on the same grounds as the unique SCT attack 920 described above. [XXX any mitigations possible here?] 922 9.2.3. Privacy for HTTPS clients performing STH Proof Fetching 924 An HTTPS client performing Proof Fetching should only request proofs 925 from a CT log that it accepts SCTs from. An HTTPS client should 926 regularly [TBD how regularly? This has operational implications for 927 log operators] request an STH from all logs it is willing to accept, 928 even if it has seen no SCTs from that log. 930 The actual mechanism by which Proof Fetching is done carries 931 considerable privacy concerns. Although out of scope for the 932 document, DNS is a mechanism currently discussed. DNS leaks data in 933 plaintext over the network (including what sites the user is visiting 934 and what sites they have previously visited) - thus it may not be 935 suitable for some. 937 9.2.4. Privacy in STH Pollination 939 An STH linked to an HTTPS client may indicate the following about 940 that client: 942 o that the client gossips; 944 o that the client has been using CT at least until the time that the 945 timestamp and the tree size indicate; 947 o that the client is talking, possibly indirectly, to the log 948 indicated by the tree hash; 950 o which software and software version is being used. 952 There is a possible fingerprinting attack where a log issues a unique 953 STH for a targeted HTTPS client. This is similar to the 954 fingerprinting attack described in Section 9.2.2, but can operate 955 cross-origin. If a log (or HTTPS Server cooperating with a log) 956 provides a unique STH to a client, the targeted client will be the 957 only client pollinating that STH cross-origin. 959 It is mitigated partially because the log is limited in the number of 960 STHs it can issue. It must 'save' one of its STHs each MMD to 961 perform the attack. 963 9.2.5. Privacy in STH Interaction 965 An HTTPS client may pollinate any STH within the last 14 days. An 966 HTTPS Client may also pollinate an STH for any log that it knows 967 about. When a client pollinates STHs to a server, it will release 968 more than one STH at a time. It is unclear if a server may 'prime' a 969 client and be able to reliably detect the client at a later time. 971 It's clear that a single site can track a user any way they wish, but 972 this attack works cross-origin and is therefore more concerning. Two 973 independent sites A and B want to collaborate to track a user cross- 974 origin. A feeds a client Carol some N specific STHs from the M logs 975 Carol trusts, chosen to be older and less common, but still in the 976 validity window. Carol visits B and chooses to release some of the 977 STHs she has stored, according to some policy. 979 Modeling a representation for how common older STHs are in the pools 980 of clients, and examining that with a given policy of how to choose 981 which of those STHs to send to B, it should be possible to calculate 982 statistics about how unique Carol looks when talking to B and how 983 useful/accurate such a tracking mechanism is. 985 Building such a model is likely impossible without some real world 986 data, and requires a given implementation of a policy. To combat 987 this attack, suggestions are provided in Section 10.1 to attempt to 988 minimize it, but follow-up testing with real world deployment to 989 improvise the policy will be required. 991 9.2.6. Trusted Auditors for HTTPS Clients 993 Some HTTPS clients may choose to use a trusted auditor. This trust 994 relationship leaks a large amount of information from the client to 995 the auditor. In particular, it will identify the web sites that the 996 client has visited to the auditor. Some clients may already share 997 this information to a third party, for example, when using a server 998 to synchronize browser history across devices in a server-visible 999 way, or when doing DNS lookups through a trusted DNS resolver. For 1000 clients with such a relationship already established, sending SCTs to 1001 a trusted auditor run by the same organization does not appear to 1002 leak any additional information to the trusted third party. 1004 Clients who wish to contact an auditor without associating their 1005 identities with their SCTs may wish to use an anonymizing network 1006 like Tor to submit SCT Feedback to the auditor. Auditors SHOULD 1007 accept SCT Feedback that arrives over such anonymizing networks. 1009 Clients sending feedback to an auditor may prefer to reduce the 1010 temporal granularity of the history leakage to the auditor by caching 1011 and delaying their SCT Feedback reports. This elaborated upon in XXX 1012 Mixing. This strategy is only as effective as the granularity of the 1013 timestamps embedded in the SCTs and STHs. 1015 9.2.7. HTTPS Clients as Auditors 1017 Some HTTPS Clients may choose to act as Auditors themselves. A 1018 Client taking on this role needs to consider the following: 1020 o an Auditing HTTPS Client potentially leaks their history to the 1021 logs that they query. Querying the log through a cache or a proxy 1022 with many other users may avoid this leakage, but may leak 1023 information to the cache or proxy, in the same way that an non- 1024 Auditing HTTPS Client leaks information to a trusted auditor. 1026 o an effective Auditor needs a strategy about what to do in the 1027 event that it discovers misbehavior from a log. Misbehavior from 1028 a log involves the log being unable to provide either (a) a 1029 consistency proof between two valid STHs or (b) an inclusion proof 1030 for a certificate to an STH any time after the log's MMD has 1031 elapsed from the issuance of the SCT. The log's inability to 1032 provide either proof will not be externally cryptographically- 1033 verifiable, as it may be indistinguishable from a network error. 1035 10. Policy Recommendations 1037 This section is intended as suggestions to implementors of HTTPS 1038 Clients, HTTPS Servers, and Auditors. It is not a requirement for 1039 technique of implementation, so long as privacy considerations 1040 established above are obeyed. 1042 10.1. Mixing Recommendations 1044 In several components of the CT Gossip ecosystem, the recommendation 1045 is made that data from multiple sources be ingested, mixed, provided 1046 to a third party, stored for an indeterminate period of time, and 1047 eventually deleted. The instances of these recommendations in this 1048 draft are: 1050 o When a client receives SCTs during SCT Feedback, it should store 1051 the SCTs and Certificates for some amount of time, provide some of 1052 them back to the server at some point, and eventually remove them 1053 from its store 1055 o When a client receives STHs during STH Pollination, it should 1056 store them for some amount of time, mix them with other STHs, 1057 release some of them them to various servers at some point, 1058 resolve some of them to new STHs, and eventually remove them from 1059 its store 1061 o When a server receives SCTs during SCT Feedback, it should store 1062 them for some period of time, provide them to auditors some number 1063 of times, and may eventually remove them 1065 o When a server receives STHs during STH Pollination, it should 1066 store them for some period of time, mix them with other STHs, 1067 provide some of them to connecting clients, may resolve them to 1068 new STHs via Proof Fetching, and eventually remove them from its 1069 store 1071 o When a Trusted Auditor receives SCTs or historical STHs from 1072 clients, it should store them for some period of time, mix them 1073 with SCTs received from other clients, and act upon them at some 1074 period of time 1076 Each of these instances have specific requirements for user privacy, 1077 and each have options that may not be invoked. As one example, a 1078 HTTPS client should not mix SCTs from server A with SCTs from server 1079 B and release server B's SCTs to Server A. As another example, a 1080 HTTPS server may choose to resolve several STHs to a single more 1081 current STH via proof fetching, but it is under no obligation to do 1082 so. 1084 These requirements should be met, but the general problem of 1085 aggregating multiple pieces of data, choosing when and how many to 1086 release, and when to remove is shared. This problem has been 1087 previously been considered in the case of Mix Networks and Remailers, 1088 including papers such as [X], [Y], and [Z]. 1090 Certain common recommendations can be made: 1092 o When choosing how many times to release data before expiring it 1093 from a cache, use a random number chosen from a distribution, 1094 rather than a fixed number. This prevents an adversary from 1095 knowing with certainty that it has successfully flushed a cache of 1096 a potentially incriminating piece of data. 1098 o [TODO Enumerating the problems of different types of mixes vs 1099 Cottrell Mix] 1101 o [TODO Integrating the IP address into the algorithm for releasing 1102 data] 1104 o [TODO Prefer aggregating multiple piece of data into a single STH 1105 when possible] 1107 o [TODO The importance of Flushing Attacks, and tying in network 1108 connection, and time interval] 1110 10.2. Blocking Recommendations 1112 10.2.1. Frustrating blocking 1114 When making gossip connections to HTTPS Servers or Trusted Auditors, 1115 it is desirable to minimize the plaintext metadata in the connection 1116 that can be used to identify the connection as a gossip connection 1117 and therefore be of interest to block. Additionally, introducing 1118 some randomness into client behavior may be important - we assume 1119 that the adversary is able to inspect the behavior of the HTTPS 1120 client and understand how it makes gossip connections. 1122 As an example, if a client, after establishing a TLS connection (and 1123 receiving an SCT, but not making it's own HTTPS request yet), 1124 immediately opens a second TLS connection for the purpose of gossip - 1125 the adversary can reliably block this second connection to block 1126 gossip without affecting normal browsing. For this reason it is 1127 recommended to run the gossip protocols over an existing connection 1128 to the server, making use of connection multiplexing such as HTTP 1129 Keep-Alives or SPDY. 1131 Truncation is also a concern -if a client always establishes a TLS 1132 connection, makes a request, receives a response, and then always 1133 attempts a gossip communication immediately following the first 1134 response - truncation will allow an attacker to block gossip 1135 reliably. 1137 10.2.2. Responding to possible blocking 1139 [Not sure here. Maybe this section will get folded up into the 1140 above. Or maybe it relates to the escape valve. -tjr] 1142 11. IANA considerations 1144 [TBD] 1146 12. Contributors 1148 The authors would like to thank the following contributors for 1149 valuable suggestions: Al Cutter, Ben Laurie, Benjamin Kaduk, Karen 1150 Seo, Magnus Ahltorp, Steven Kent, Yan Zhu. 1152 13. ChangeLog 1154 13.1. Changes between ietf-00 and ietf-01 1156 o Improve langugage and readability based on feedback from Stephen 1157 Kent. 1159 o STH Pollination Proof Fetching defined and indicated as optional. 1161 o 3-Method Ecosystem section added. 1163 o Cases with Logs ceasing operation handled. 1165 o Text on tracking via STH Interaction added. 1167 o Section with some early recommendations for mixing added. 1169 o Section detailing blocking connections, frustrating it, and the 1170 implications added. 1172 13.2. Changes between -01 and -02 1174 o STH Pollination defined. 1176 o Trusted Auditor Relationship defined. 1178 o Overview section rewritten. 1180 o Data flow picture added. 1182 o Section on privacy considerations expanded. 1184 13.3. Changes between -00 and -01 1186 o Add the SCT feedback mechanism: Clients send SCTs to originating 1187 web server which shares them with auditors. 1189 o Stop assuming that clients see STHs. 1191 o Don't use HTTP headers but instead .well-known URL's - avoid that 1192 battle. 1194 o Stop referring to trans-gossip and trans-gossip-transport-https - 1195 too complicated. 1197 o Remove all protocols but HTTPS in order to simplify - let's come 1198 back and add more later. 1200 o Add more reasoning about privacy. 1202 o Do specify data formats. 1204 14. Normative References 1206 [RFC-6962-BIS] 1207 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 1208 Stradling, "Certificate Transparency", October 2015, 1209 . 1212 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 1213 Interchange Format", RFC 7159, March 2014. 1215 Authors' Addresses 1217 Linus Nordberg 1218 NORDUnet 1220 Email: linus@nordu.net 1222 Daniel Kahn Gillmor 1223 ACLU 1225 Email: dkg@fifthhorseman.net 1227 Tom Ritter 1229 Email: tom@ritter.vg