TRANS L. Nordberg Internet-Draft NORDUnet Intended status: Experimental D. Gillmor Expires:AprilSeptember 22, 2016 ACLU T. RitterOctober 20, 2015March 21, 2016 Gossiping in CTdraft-ietf-trans-gossip-01draft-ietf-trans-gossip-02 Abstract The logs in Certificate Transparency are untrusted in the sense that the users of the system don't have to trust that they behave correctly since the behaviour of a log can be verified to be correct. This document tries to solve the problem with logs presenting a "split view" of their operations. It describes three gossiping mechanisms for Certificate Transparency: SCT Feedback, STH Pollination and Trusted Auditor Relationship. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onAprilSeptember 22, 2016. Copyright Notice Copyright (c)20152016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Defining the problem . . . . . . . . . . . . . . . . . . . .34 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Terminologyand data flow. . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Pre-Loaded vs Locally Added Anchors . . . . . . . . . . . 5 5. Who gossips with whom . . . . . . . . . . . . . . . . . . . .65 6. What to gossip about and how . . . . . . . . . . . . . . . . 6 7. Data flow . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Gossip Mechanisms . . . . . . . . . . . . . . . . . . . . . .6 7.1.7 8.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . .6 7.1.1.7 8.1.1. SCT Feedback data format . . . . . . . . . . . . . . 8 8.1.2. HTTPS client to server . . . . . . . . . . . . . . .7 7.1.2.8 8.1.3. HTTPS serverto auditorsoperation . . . . . . . . . . . . . .9 7.1.3. SCT Feedback data format. 11 8.1.4. HTTPS server to auditors . . . . . . . . . . . . . .10 7.2.13 8.2. STH pollination . . . . . . . . . . . . . . . . . . . . .10 7.2.1.14 8.2.1. HTTPS Clients and Proof Fetching . . . . . . . . . .12 7.2.2.15 8.2.2. STH Pollination without Proof Fetching . . . . . . .13 7.2.3.17 8.2.3. Auditorand MonitorAction . . . . . . . . . . . . .13 7.2.4.. . . . . . 17 8.2.4. STH Pollination data format . . . . . . . . . . . . .13 7.3.17 8.3. Trusted Auditor Stream . . . . . . . . . . . . . . . . .14 7.3.1.17 8.3.1. Trusted Auditor data format . . . . . . . . . . . . .14 8.18 9. 3-Method Ecosystem . . . . . . . . . . . . . . . . . . . . .14 8.1.19 9.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . .15 8.2.19 9.2. STH Pollination . . . . . . . . . . . . . . . . . . . . .15 8.3.20 9.3. Trusted Auditor Relationship . . . . . . . . . . . . . .16 8.4.21 9.4. Interaction . . . . . . . . . . . . . . . . . . . . . . .17 9.22 10. Security considerations . . . . . . . . . . . . . . . . . . .17 9.1.22 10.1. Attacks by actively malicious logs . . . . . . . . . . . 22 10.2. Dual-CA Compromise . . . . . . . . . . . . . . . . . . . 23 10.3. Censorship/Blocking considerations . . . . . . . . . . .17 9.2.23 10.4. Privacy considerations . . . . . . . . . . . . . . . . .19 9.2.1.25 10.4.1. Privacy and SCTs . . . . . . . . . . . . . . . . . .19 9.2.2.25 10.4.2. Privacy in SCT Feedback . . . . . . . . . . . . . .. 19 9.2.3.25 10.4.3. Privacy for HTTPS clients performing STH Proof Fetching . . . . . . . . . . . . . . . . . . . . . .20 9.2.4.26 10.4.4. Privacy in STH Pollination . . . . . . . . . . . . .20 9.2.5.26 10.4.5. Privacy in STH Interaction . . . . . . . . . . . . .21 9.2.6.27 10.4.6. Trusted Auditors for HTTPS Clients . . . . . . . . .21 9.2.7.28 10.4.7. HTTPS Clients as Auditors . . . . . . . . . . . . .. 22 10.28 11. Policy Recommendations . . . . . . . . . . . . . . . . . . .22 10.1. Mixing29 11.1. Blocking Recommendations . . . . . . . . . . . . . . . .. 22 10.2. Blocking Recommendations29 11.1.1. Frustrating blocking . . . . . . . . . . . . . . . .24 10.2.1. Frustrating29 11.1.2. Responding to possible blocking . . . . . . . . . . 29 11.2. Proof Fetching Recommendations . . . . . .24 10.2.2. Responding to possible blocking. . . . . . . 31 11.3. Record Distribution Recommendations . . .24 11. IANA considerations. . . . . . . 31 11.3.1. Mixing Algorithm . . . . . . . . . . . . . .25 12. Contributors. . . . 32 11.3.2. Flushing Attacks . . . . . . . . . . . . . . . . . . 33 11.3.3. The Deletion Algorithm . .25 13. ChangeLog. . . . . . . . . . . . . 34 12. IANA considerations . . . . . . . . . . . . .25 13.1. Changes between ietf-00 and ietf-01. . . . . . . . 45 13. Contributors . .25 13.2. Changes between -01 and -02. . . . . . . . . . . . . .25 13.3. Changes between -00 and -01. . . . . . . . 45 14. ChangeLog . . . . . .25 14.. . . . . . . . . . . . . . . . . . . . 45 14.1. Changes between ietf-01 and ietf-02 . . . . . . . . . . 45 14.2. Changes between ietf-00 and ietf-01 . . . . . . . . . . 46 14.3. Changes between -01 and -02 . . . . . . . . . . . . . . 46 14.4. Changes between -00 and -01 . . . . . . . . . . . . . . 46 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 15.1. Normative References . . . . . . . . . . . . . . . . . . 47 15.2. Informative References . .26. . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .2647 1. Introduction The purpose of the protocols in this document, collectively referred to as CT Gossip, is to detect certain misbehavior by CT logs. In particular, CT Gossip aims to detect logs that are providingincosistentinconsistent views to different logclientsclients, and logs failing to include submitted certificates within the time period stipulated by MMD.[TODO:[ TODO: enumerate the interfaces used for detectingmisbehaviour?]misbehaviour? ] One of the major challenges of any gossip protocol is limiting damage to user privacy. The goal of CT gossip is to publish and distribute information about the logs and their operations, but not toleakexpose any additional information about the operation of any of the other participants. Privacy of consumers of log information (in particular, of web browsers and other TLS clients) should not be undermined by gossip. This document presents three different, complementary mechanisms for non-log elements of the CT ecosystem to exchange information about logs in a manner that preserves the privacy of HTTPS clients. They should provide protective benefits for the system as a whole even if their adoption is not universal. 2. Defining the problem When a log provides different views of the log to different clients this is described as a partitioning attack. Each client would be able to verify the append-only nature of the log but, in the extreme case, each client might see a unique view of the log. The CT logs are public, append-only and untrusted and thus have to bemonitoredaudited for consistency, i.e., they should never rewrite history. Additionally,monitorsauditors and other log clients need to exchange information aboutmonitoredlogs in order to be able to detect a partitioning attack (as described above). Gossiping about logresponses to queriesbehaviour helps address the problem of detecting malicious or compromised logs with respect to a partitioning attack. We want some side of the partitioned tree, and ideally both sides, to see the other side. Disseminating information about a log poses a potential threat to the privacy of end users. Some data of interest (e.g. SCTs)areis linkable to specific log entries and thereby to specificsites,websites, which makes sharing them with othersprivacy-sensitive.a privacy concern. Gossiping about this data has to take privacy considerations into account in order not toleakexpose associations between users of the log (e.g., web browsers) and certificate holders (e.g., web sites). Even sharing STHs (which do not link to specific log entries) can be problematic - user tracking by fingerprinting through rare STHs is one potential attack (see Section7.2).8.2). 3. Overview SCT Feedback enables HTTPS clients to share Signed Certificate Timestamps (SCTs) (Section 3.3 of[RFC-6962-BIS])[RFC-6962-BIS-09]) with CT auditors in a privacy-preserving manner by sending SCTs to originating HTTPSservers whichservers, who in turn share them with CT auditors. In STH Pollination, HTTPS clients use HTTPS servers as poolssharingto share Signed Tree Heads (STHs) (Section 3.6 of[RFC-6962-BIS])[RFC-6962-BIS-09]) with other connecting clients in the hope that STHs will find their way toauditors and monitors.CT auditors. HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs with trusted CT auditorsor monitorsdirectly, with expectations of privacy sensitive data being handled according to whatever privacy policy is agreed on between client and trusted party. Despite the privacy risks with sharing SCTs there is no loss in privacy if a client sends SCTs for a given site to the site corresponding to the SCT. This is because the site's logs would already indicate that the client is accessing that site. In this way a site can accumulate records of SCTs that have been issued by various logs for that site, providing a consolidated repository of SCTs that could be shared with auditors. Auditors can use this information to detect logs thatmisbehavesmisbehave by not including certificates within the time period stipulated by the MMD metadata. Sharing an STH is considered reasonably safe from a privacy perspective as long as the same STH is shared by a large number of other log clients. This"safetysafety innumbers"numbers can be achieved byrequiringonly allowing gossiping of STHsonly ofissued in a certain"freshness"window of time, while also refusing to gossip about STHs from logs with too high an STH issuance frequency (see Section7.2).8.2). 4. Terminologyand data flowThis document relies on terminology and data structures defined in[RFC-6962-BIS],[RFC-6962-BIS-09], including STH, SCT, Version, LogID, SCT timestamp, CtExtensions, SCT signature, Merkle Tree Hash.The following picture shows how certificates, SCTsThis document relies on terminology defined in [draft-ietf-trans-threat-analysis-03], including Auditing. 4.1. Pre-Loaded vs Locally Added Anchors Through the document, we refer to both Trust Anchors (Certificate Authorities) andSTHs flow throughLogs. Both Logs and Trust Anchors may be locally added by an administrator. Unless otherwise clarified, in both cases we refer to the set of Trust Anchors and Logs that come pre-loaded and pre-trusted in aCT systempiece of client software. 5. Who gossips withSCTwhom o HTTPS clients and servers (SCT Feedback and STHPollination. It does not show what goes in the Trusted Auditor Relationship stream. +- Cert ---- +----------+ |Pollination) o HTTPS servers and CT auditors (SCT Feedback and STH Pollination) o CT auditors (Trusted Auditor Relationship) Additionally, some HTTPS clients may engage with an auditor who they trust with their privacy: o HTTPS clients and CT auditors (Trusted Auditor Relationship) 6. What to gossip about and how There are three separate gossip streams: o SCT Feedback - transporting SCTs and certificate chains from HTTPS clients to CT auditors via HTTPS servers. o STH Pollination - HTTPS clients and CT auditors using HTTPS servers as STH pools for exchanging STHs. o Trusted Auditor Stream - HTTPS clients communicating directly with trusted CT auditors sharing SCTs, certificate chains and STHs. It is worthwhile to note that when an HTTPS Client or CT auditor interact with a log, they may equivalently interact with a log mirror or cache that replicates the log. 7. Data flow The following picture shows how certificates, SCTs and STHs flow through a CT system with SCT Feedback and STH Pollination. It does not show what goes in the Trusted Auditor Relationship stream. +- Cert ---- +----------+ | | CA | ----------+ | + SCT -> +----------+ | v | Cert [& SCT] +----------+ | | Log | ---------- SCT -----------+ +----------+ v | ^ +----------+ | | SCT & Certs --- | Website | | |[1] | +----------+ | |[2] STH ^ | | |[3] v | | | | +----------+ | | | +--------> | Auditor | | HTTPS traffic | +----------+ | || /STH | SCT |/SCT & Certs | Log entries/| | |/STH STH v/[4]| | +----------+ | v | Monitor | +----------+ +----------+ | Browser | +----------+ # Auditor Log [1] |--- get-sth ------------------->| |<-- STH ------------------------| [2] |--- leaf hash + tree size ----->| |<-- index + inclusion proof --->| [3] |--- tree size 1 + tree size 2 ->| |<-- consistency proof ----------|[4] SCT, cert and STH among multiple Auditors and Monitors 5. Who gossips with whom o HTTPS clients and servers (SCT8. Gossip Mechanisms 8.1. SCT Feedbackand STH Pollination) o HTTPS servers and CT auditors (SCT Feedback) o CT auditors and monitors (Trusted Auditor Relationship) Additionally, some HTTPS clients may engage with an auditor who they trust with their privacy: o HTTPSThe goal of SCT Feedback is for clients to share SCTs and certificate chains with CT auditors(Trusted Auditor Relationship) 6. What to gossip about and how There are three separate gossip streams: o SCT Feedback - transporting SCTs and certificate chains from HTTPS clients to CT auditors/monitors via HTTPS servers. o STH Pollination - HTTPS clients and CT auditors/monitors using HTTPS servers as STH pools for exchanging STHs. o Trusted Auditor Stream, HTTPS clients communicating directly with trusted CT auditors/monitors sharing SCTs, certificate chains and STHs. 7. Gossip Mechanisms 7.1. SCT Feedback The goal of SCT Feedback is for clients to share SCTs and certificate chains with CT auditors and monitorswhile still preserving the privacy of the end user. The sharing of SCTs contribute to the overall goal of detecting misbehaving logs by providing auditorsand monitorswith SCTs from many vantage points, making itpossiblemore likely to catch ahigher number of violationsviolation of a log's MMDand also catch logsor a log presenting inconsistent views. The sharing of certificate chains is beneficial to HTTPS server operators interested in direct feedback from clients for detecting bogus certificates issued in their name and therefore incentivises server operators to take part in SCT Feedback. SCT Feedback is the most privacy-preserving gossip mechanism, as it does not directly expose any links between an end user and the sites they've visisted to any third party.[Here's an alternative to that paragraph: SCT Feedback is the most privacy-preserving gossip mechanism, as it does not create any potential cross-origin tracking mechanisms. ]HTTPS clients store SCTs and certificate chains they see, and later send them to the originating HTTPS server by posting them to a well- known URL (associated with that server), as described in Section7.1.1.8.1.2. Note that clients will send the same SCTs and chains toserversa server multiple times with the assumption thata potential man- in-the-middleany man-in-the- middle attack eventually will cease, and an honest server will eventually receive collected malicious SCTs and certificate chains. HTTPS servers store SCTs and certificate chains received fromclients andclients, as described in Section 8.1.3. They later share them with CT auditors by either posting them to auditors or making them available via a well-known URL. This is described in Section7.1.2. 7.1.1. HTTPS client to server When an8.1.4. 8.1.1. SCT Feedback data format The data shared between HTTPSclient connects to anclients and servers, as well as between HTTPSserver,servers and CT auditors, is a JSON array [RFC7159]. Each item in theclient receivesarray is aset of SCTs as part ofJSON object with theTLS handshake.following content: o x509_chain: An array of base64-encoded X.509 certificates. Theclient MUST discard SCTs that are not signed by a log known tofirst element is theclient and SHOULD storeend-entity certificate, theremaining SCTs together withsecond certifies thecorresponding certificate chain for later use infirst and so on. o sct_data: An array of objects consisting of the base64 representation of the binary SCTFeedback.data as defined in [RFC-6962-BIS-09] Section 3.3. We will refer to this object as 'sct_feedback'. The x509_chain element always contains at least one element. It also always contains a full chain from a leaf certificate to a self-signed trust anchor. [ TBD: Be strict about what sct_data may contain or is this sufficiently implied by previous sections? ] 8.1.2. HTTPS client to server Whenthean HTTPS clientlater reconnectsconnects toanyan HTTPSserver forserver, thesame domain, it againclient receives a set ofSCTs. The client MUST add newSCTsfrom known logs to its storeas part of the TLS handshake. SCTsforare included in theserver.TLS handshake using one or more of the three mechanisms described in [RFC-6962-BIS-09] section 3.4 - in the server certificate, in a TLS extension, or in an OCSP extension. The client MUSTsend to the server anydiscard SCTsin the storethat areassociated with that server but which werenotreceived from that server. [TODO: fix the above paragraph - it is vague and confusing. maybe an example includingsigned by aclient caching at most one SCT per host+log would clarify] [TODO: define "same domain"] Note thatlog known to theSCTclient and SHOULD storealso containsthe remaining SCTsreceivedtogether with a locally constructed certificate chain which is trusted (i.e. terminated incertificates.a pre-loaded or locally installed Trust Anchor) in an sct_feedback object or equivalent data structure for later use in SCT Feedback. The SCTs stored on the client MUSTNOT sendbe keyed by thesame set of SCTs toexact domain name thesame server more often than TBD. [benl says: "sentclient contacted. They MUST NOT be sent to any domain not matching theserver" only really counts if the server presented a valid SCT in the handshake andoriginal domain (e.g. if thecertificateoriginal domain isknown to be unrevoked (which willsub.example.com they must not behard for a MitMsent tosustain)] [TODO: expand on rate/resource limiting motivation] Refersub.sub.example.com or toSection 10.1 for recommendations about strategies. An SCTexample.com.) They MUST NOT be sent to anyother HTTPS server than one servingSubject Alternate Names specified in thedomain to whichcertificate. In thecertificate signed bycase of certificates that validate multiple domain names, the same SCTrefers.is expected to be stored multiple times. Not followingthis constraintthese constraints wouldlead toincrease the risk for two types of privacyleaks.breaches. First, the HTTPS server receiving the SCT would learn about other sites visited by the HTTPS client.Secondly,Second, auditorsor monitorsreceiving SCTs from the HTTPS server would learn information abouttheother HTTPS servers visited by its clients. If theHTTPSclienthas configuration options for not sending cookies to third parties, SCTs of third parties MUST be treated as cookies with respect to this setting. This prevents third party tracking through the use of SCTs/certificates, which would bypass the cookie policy. SCTs and corresponding certificates are POSTedlater again connects to theoriginating HTTPS server at the well-known URL: https://<domain>/.well-known/ct/v1/sct-feedback The data sent in the POST is defined in Section 7.1.3.same HTTPSservers performserver, it again receives anumberset ofsanity checks onSCTsfrom clients before storing them: 1. ifand calculates abit-wise compare ofcertificate chain, and again creates anSCT plus chain matches a pair alreadysct_feedback or similar object. If this object does not exactly match an existing object in the store,this SCT and chain pair MAY be discarded 2. ifthen theSCT can't be verifiedclient MUST add this new object tobe a valid SCT for the accompanying leaf cert, issued by a known log,theSCT SHOULD be discarded 3. ifstore, associated with theleaf cert is not for aexact domainfor which the servername contacted, as described above. An exact comparison isauthoritative, the SCT MUST be discarded Check number 1 is for detecting duplicates and minimizing processing and storage by the server. It's importantneeded tonoteensure thatthe check should be on pairsattacks involving alternate chains are detected. An example ofSCT and chainsuch an attack is described inorder to catch different chains accompanied by[TODO double-CA-compromise attack]. However, at least one optimization is safe and MAY be performed: If thesame SCT. This mis-matchedcertificate chaininformation may be useful as a diagnostic tool for HTTPS server operators. Check number 2 is to prevent DoS attacks whereexactly matches anadversary can fill upexisting certificate chain, the client may storeprior to attacking a client, or a denialthe union ofservice attack ontheserver's storage space. Check number 3 is to help malfunctioning clientsSCTs fromleaking which sites they visit and additionallythe two objects in the first (existing) object. If the client does connect toprevent DoS attacks. Note that anthe same HTTPS serverMAY choose to storeasubmitted SCT and the accompanying certificate chain even when the SCT can't be verified accordingsubsequent time, it MUST send tocheck number 2. One such case would be when a certificate chain validation is performed andthechain endsserver sct_feedback objects ina trust anchor configured on the server. In this instance,theserver could also be configured to not bother with known-to-be-good (i.e. administratively-vetted) leaf certificates, and onlystoreunknown leaf certificatesthatchainare associated with that domain name. It is not necessary toa known trust anchor.send an sct_feedback object constructed from the current TLS session. Therisk of spamming and denialclient MUST NOT send the same set ofservice can be mitigated by configuringSCTs to the same serverwith all known acceptable certificates (or certificate hashes) applicablemore often than TBD. [ TODO: expand on rate/resource limiting motivation ] Refer tothis server. This information may enableSection 11.3 for recommendations about strategies. Because SCTs can be used as a tracking mechanism (see Section 10.4.2), they deserve special treatment when they are received from (and provided to) domains that are loaded as subresources from an origin domain. Such domains are commonly called 'third party domains'. An HTTPSserver operator to detect attacks or unusual behavior of Certificate Authorities even outsideClient SHOULD store SCT Feedback using a 'double-keying' approach, which isolates third party domains by theCertificate Transparency ecosystem. 7.1.2. HTTPS server to auditorsfirst party domain. This is described in XXX. Gossip would be performed normally for third party domains only when the user revisits the first party domain. In lieu of 'double-keying', an HTTPSservers receiving SCTs from clients SHOULD share SCTsClient MAY treat SCT Feedback in the same manner it treats other security mechanisms that can enable tracking (such as HSTS andcertificate chains with CT auditors by either serving them onHPKP.) [ XXX is currently https://www.torproject.org/projects/torbrowser/ design/#identifier-linkability How should it be references? Do we need to copy this out into another document? An appendix? ] If thewell-known URL: https://<domain>/.well-known/ct/v1/collected-sct-feedback or byHTTPSPOSTing themclient has configuration options for not sending cookies toa setthird parties, SCTs ofpreconfigured auditors.third parties MUST be treated as cookies with respect to this setting. Thisallows anprevents third party tracking through the use of SCTs/certificates, which would bypass the cookie policy. SCTs and corresponding certificates are POSTed to the originating HTTPS serverto choose between an active push model or a passive pull model. The data received in a GET ofat the well-knownURL orURL: https://<domain>/.well-known/ct-gossip/v1/sct-feedback The data sent in the POST is defined in Section7.1.3. HTTPS servers8.1.1. This data SHOULDshare all SCTs and accompanying certificate chains they see that pass the checksbe sent inSection 7.1.1. If this is an infeasible amount of data, the server may choose to expire submissions according toanundefined policy. Suggestionsalready established TLS session. This makes it hard forsuch a policy can be foundan attacker to disrupt SCT Feedback without also disturbing ordinary secure browsing (https://). This is discussed more in Section10.1. HTTPS servers MUST NOT share any other data11.1.1. Some clients have trust anchors or logs thatthey may learn from the submission of SCT Feedbackare locally added (e.g. byHTTPS clients, like the HTTPS client IP addressan administrator or by thetime of submission. Auditors SHOULD provide the following URL accepting HTTPS POSTing of SCT feedback data: https://<auditor>/ct/v1/sct-feedback Auditors SHOULD regularly poll HTTPS servers at the well-known collected-sct-feedback URL. The frequency of the polling and how to determine which domains to poll is outsideuser themselves). These additions are potentially privacy-sensitive because they can carry information about thescope ofspecific configuration, computer, or user. Certificates validated by locally added trust anchors will commonly have no SCTs associated with them, so in thisdocument. However, the selectioncase no action is needed with respect to CT Gossip. SCTs issued by locally added logs MUST NOT beinfluenced by potential HTTPS clients connecting directly to the auditor. For example, ifreported via SCT Feedback. If apollcertificate is validated by SCTs that are issued by publicly trusted logs, but chains toexample.com occurs directly aftera local trust anchor, the clientsubmits anMAY perfom SCT Feedback forexample.com, an adversary observingthis SCT and certificate chain bundle. If it does so, theauditor can trivially concludeclient MUST include theactivityfull chain of certificates chaining to theclient. 7.1.3.local trust anchor in the x509_chain array. Perfoming SCT Feedbackdata format The data shared between HTTPS clients and servers, as well as between HTTPS serversin this scenario may be advantageous for the broader internet and CTauditors/monitors, is a JSON object [RFC7159] with the following content: o sct_feedback: An array of objects consisting of * x509_chain: An array of base64-encoded X.509 certificates. The first element isecosystem, but may also disclose information about theend-entity certificate,client. If thesecond chainsclient elects tothe first and so on. * sct_data: An array of objects consisting of the base64 representation of the binaryomit SCTdataFeedback, it can still choose to perform STH Pollination after fetching an inclusion proof, asdefinedspecified in[RFC-6962-BIS]Section3.3. The 'x509_chain' element MUST contain at least8.2. We require theleaf certificate and SHOULD containclient to send the full chainto a root accepted by all of(or nothing at all) for two reasons. Firstly, it simplifies thelogs inoperation on theset of logs issuing allserver if there are not two code paths. Secondly, omitting theSCTschain does not actually preserve user privacy. The Issuer field in the'sct_data' element. Some clients have trust anchors that are locally added (e.g. by an administrator or bycertificate describes theuser themselves). A local trust anchorssigning certificate. And if the certificate ispotentially privacy-sensitive sincebeing submitted at all, itmay carry information aboutmeans thespecific computer or user. If acertificate iscovered by SCTs issued by publicly trusted logs, but it chains to a privacy-sensitive local trust anchor,logged, and has SCTs. This means that theclient SHOULD submit it as an "x509\_chain" consisting only ofIssuer can be queried and obtained from theleaf certificate. [TBD: Be strict about what sct_data may contain or is this sufficiently implied by previous sections?] [TBD: There was discussion about including a few field for client->server reporting, which islog so omitting theexact set and order of certificates sent byparent from the client's submission does not actually help user privacy. 8.1.3. HTTPS serverto the client. This is additional diagnostic information that aoperation HTTPS servers can be configured (or omit configuration), resulting in, broadly, two modes of operation. In the simpler mode, the servercould use to check it's deployment... but is pretty much uselesswill only track leaf certificates and SCTs applicable toCT or gossip. Right now we're not including this, but we're pollingthose leaf certificates. In the more complex mode, the serveroperators to see if they would welcome this data.] 7.2. STH pollinationwill confirm the client's chain validation and store the certificate chain. Thegoal of sharing Signed Tree Heads (STHs) through pollinationlatter mode requires more configuration, but is necessary toshare STHs between HTTPS clients, CT auditors, and monitors in while still preserving the privacyprevent denial of service (DoS) attacks on theend user. The sharing of STHs contribute toserver's storage space. In theoverall goalsimple mode ofdetecting misbehaving logs by providing CT auditors and monitors with SCTs from many vantage points, making it possible to detect logs that are presenting inconsistent views.operation, upon recieving a submission at the sct-feedback well-known URL, an HTTPSservers supportingserver will perform a set of operations, checking on each sct_feedback object before storing it: 1. theprotocol act as STH pools.HTTPSclients and CT auditorsserver MAY modify the sct_feedback object, andmonitorsdiscard all items in thepossession of STHs should pollinate STH pools by sending STHs to them, and retrieving new STHs to send to other STH pools. CT auditors and monitors should perform their auditing and monitoring duties by retrieving STHs from pools. STH Pollinationx509_chain array except the first item (which iscarried out by sending STHs to HTTPS servers supporting the protocol, and retrieving new STHs. Inthecaseend-entity certificate) 2. if a bit-wise compare ofHTTPS clients, STHsthe sct_feedback object matches one already in the store, this sct_feedback object SHOULD besent in an already established TLS session. This makes it harddiscarded 3. if the leaf cert is not foran attacker to disrupt STH gossiping without also disturbing ordinary secure browsing (https://). Thisa domain for which the server isdiscussed moreauthoritative, the SCT MUST be discarded 4. if an SCT inSection 10.2.1. HTPS clients send STHs to HTTPS servers by POSTing themthe sct_data array can't be verified to be a valid SCT for thewell-accompanying leaf cert, and issued by a knownURL: https://<domain>/.well-known/ct/v1/sth-pollinationlog, the individual SCT SHOULD be discarded Thedata sentmodification inthe POSTstep number 1 isdefinednecessary to prevent a malicious client from exhausting the server's storage space. A client can generate their own issuing certificate authorities, and create an arbitrary number of chains that terminate inSection 7.2.4. The response contains zero or more STHsan end-entity certificate with an existing SCT. By discarding all but the end- entity certificate, we prevent a simple HTTPS server from storing this data. Note that operation in this mode will not prevent thesame format,attack described in Section7.2.4. An HTTPS client may acquire STHs by several methods: o10.2. Skipping this step requires additional configuration as described below. The check inreplies to pollination POSTs; o asking logs that it recognisesstep 2 is for detecting duplicates and minimizing processing and storage by thecurrent STH, either directly (v2/get-sth) or indirectly (for example over DNS) o resolvingserver. As on the client, anSCT and certificateexact comparison is needed toan STH via an inclusion proof o resolvingensure that attacks involving alternate chains are detected. Again, at least oneSTH to another via a consistency proof HTTPS clients (who have STHs), CT auditors, and monitors SHOULD pollinate STH pools with STHs. Which STHs to send and how often pollination should happenoptimization isregarded as undefined policy withsafe and MAY be performed. If theexceptioncertificate chain exactly matches an existing certificate chain, the server may store the union ofprivacy concerns explained inthenext section. Suggestions forSCTs from thepolicy may be foundtwo objects inSection 10.1. An HTTPS client could be tracked by giving it a unique or rare STH. To addressthe first (existing) object. It should do thisconcern, we place restrictionsafter completing the validity check ondifferent components ofthesystemSCTs. The check in step 3 is toensure an STH will not be rare. o HTTPShelp malfunctioning clientssliently ignore STHsfromlogs with an STH issuance frequency of more than one STH per hour. Logs useexposing which sites they visit. It additionally helps prevent DoS attacks on theSTH Frequency Count metadata to express this ([RFC-6962-BIS] sections 3.6 and 5.1). o HTTPS clients silently ignore STHsserver. [ TBD: Thinking about building this, how does the SCT Feedback app know whichare not fresh. An STH is considered fresh iff its timestamp is less than 14 dayssites it's authoritative for? ] The check in step 4 is to prevent DoS attacks where an adversary fills up thepast. Givenstore prior to attacking amaximum STH issuance rate of one per hour,client (thus preventing the client's feedback from being recorded), or anattacker has 336 unique STHs per log for tracking. Clients MUST ignore STHs older than 14 days. We consider STHs within this validity windowattack where an adversary simply attempts tobe personally identifiable data, and STHs outside this window not personally identifiable. A log may cease operation, in which case therefill up server's storage space. The more advanced server configuration willsoon be no STH within the validity window. Clients SHOULD perform all three methods of gossip about a log that has ceased operation - it is possible the log was still compromised and gossip candetectthat. STH Pollination istheone mechanism where a client must know about a log shutdown. A client who does[TODO double- CA-compromise] attack. In this configuration the server will notknow about a log shutdown MUST NOT attempt any heuristicmodify the sct_feedback object prior todetectperforming checks 2, 3, and 4. To prevent ashutdown. Instead themalicious clientMUST be informed about the shutdownfroma verifiable source (e.g. a software update). The client SHOULD be providedfilling thefinal STH issued byserver's data store, thelog andHTTPS Server SHOULDresolve SCTs and STHs to this final STH. Ifperform anSCTadditional check: 1. if the x509_chain consists of an invalid certificate chain, orSTH cannot be resolved tothefinal STH... XXX? When multipliedculminating trust anchor is not recognized by thenumber of logs from which a client accepts STHs, this number of unique STHs grow andserver, thenegative privacy implications grow with it. It's important that this is taken into account when logs are chosen for default settings in HTTPS clients. This concern is discussed uponserver SHOULD modify the sct_feedback object, discarding all items inSection 9.2.5. 7.2.1.the x509_chain array except the first item The HTTPSClients and Proof Fetching There are two types of proofs a clientserver mayretrieve. An HTTPS client will retrieve SCTs from an HTTPS server, and must obtain an inclusion proof to an STH in orderchoose toverifyomit checks 4 or 5. This will place thepromise madeserver at risk of having its data store filled up bythe SCT. An HTTPS client may receive SCT bundled with an inclusion proofinvalid data, but can also allow a server to identify interesting certificate or certificate chains that omit valid SCTs, or do not chain to ahistorical STH via an unspecified future mechanism. Because this historical STH is considered personally identifiabletrusted root. This informationper above,may enable an HTTPS server operator to detect attacks or unusual behavior of Certificate Authorities even outside theclient must obtain a consistency proofCertificate Transparency ecosystem. 8.1.4. HTTPS server toa more recent STH. If a client requested either proof directlyauditors HTTPS servers receiving SCTs froma log or auditor, it would revealclients SHOULD share SCTs and certificate chains with CT auditors by either serving them on theclient's browsing habitswell-known URL: https://<domain>/.well-known/ct-gossip/v1/collected-sct-feedback or by HTTPS POSTing them to athird party. To mitigate this risk,set of preconfigured auditors. This allows an HTTPSclient MUST retrieve the proofserver to choose between an active push model or a passive pull model. The data received in amanner that disguisesGET of theclient. Depending onwell-known URL or sent in theclient's DNS provider, DNS may provide an appropriate intermediate layerPOST is defined in Section 8.1.1. HTTPS servers SHOULD share all sct_feedback objects they see thatobfuscates the linkability betweenpass theuserchecks in Section 8.1.3. If this is an infeasible amount of data, theclient and the request for inclusion (while at the same time providing a caching layer for oft-requested inclusion proofs.) [TODO: Add a referenceserver may choose toGoogle's DNS mechanism more proper than http://www.certificate-transparency.org/august-2015-newsletter] Anonymity networks such as Tor also present a mechanism for a clientexpire submissions according toanonymously retrieve a proof fromanauditor or log. 7.2.2. STH Pollination without Proof Fetching An HTTPS client MAY participateundefined policy. Suggestions for such a policy can be found inSTH Pollination without fetching proofs. In this situation, the client receives STHsSection 11.3. HTTPS servers MUST NOT share any other data that they may learn froma server, appliesthesame validation logic to them (signedsubmission of SCT Feedback bya known log, within a validity window) and will later pass them to aHTTPSserver. When operating in this fashion,clients, like the HTTPS clientis promoting gossip for Certificate Transparency, but derives no direct benefit itself.IP address or the time of submission. As described above, HTTPS servers can be configured (or omit configuration), resulting in two modes of operation. Incomparison,one mode, the x509_chain array will contain aclient who resolves SCTsfull certificate chain. This chain may terminate in a trust anchor the auditor may recognize, orhistorical STHs to recent STHs and pollinates them is assured that ifitwas attacked, theremay not. (One scenario where this could occur isa probability thatif theecosystem will detectclient submitted a chain terminiating in a locally added trust anchor, andrespond totheattack (by distrustingserver kept this chain.) In thelog). 7.2.3. Auditor and Monitor Action Auditors and Monitors participate in STH pollination by retrieving STHs from HTTPS servers. They verify thatother mode, theSTH is valid by checking the signature, and requestingx509_chain array will consist of only aconsistency proof fromsingle element, which is theSTH toend-entity certificate. Auditors SHOULD provide themost recent STH. After retrievingfollowing URL accepting HTTPS POSTing of SCT feedback data: https://<auditor>/ct-gossip/v1/sct-feedback [ TBD: Should that be .well-known? Depends on whether auditors will operate in their own URL name space or not. ] Auditors SHOULD regularly poll HTTPS servers at theconsistency proofwell-known collected-sct-feedback URL. The frequency of the polling and how to determine which domains to poll is outside themost recent STH, they SHOULD pollinatescope of thisnew STH among participatingdocument. However, the selection MUST NOT be influenced by potential HTTPSServers. In this way, as STHs "age out" and are no longer fresh, their "lineage" continuesclients connecting directly tobe tracked inthesystem. 7.2.4.auditor. For example, if a poll to example.com occurs directly after a client submits an SCT for example.com, an adversary observing the auditor can trivially conclude the activity of the client. 8.2. STHPollination data formatpollination Thedata sent fromgoal of sharing Signed Tree Heads (STHs) through pollination is to share STHs between HTTPS clients and CTmonitors andauditors while still preserving the privacy of the end user. The sharing of STHs contribute to the overall goal of detecting misbehaving logs by providing CT auditors with STHs from many vantage points, making it possible to detect logs that are presenting inconsistent views. HTTPS serversis a JSON object [RFC7159] withsupporting thefollowing content: o sths - an array of 0 or more fresh SignedTreeHead'sprotocol act asdefined in [RFC-6962-BIS] Section 3.6.1. [XXX AnSTHis considered fresh iff TBD.] 7.3. Trusted Auditor Streampools. HTTPS clientsMAY send SCTs and cert chains, as well as STHs, directly to auditors. Note that there are privacy implications in doing so, these are outlined in Section 9.2.1andSection 9.2.6. The most natural trusted auditor arrangement arguably is a web browser that is "loggedCT auditors into" a providerthe possession ofvarious internet services. Another equivalent arrangement is a trusted party like a corporation to which an employee is connected through a VPN orSTHs can pollinate STH pools by sending STHs to them, and retrieving new STHs to send to othersimilar means. A third might be individuals or smaller groupsSTH pools. CT auditors can improve the value ofpeople runningtheirown services. In such a setting,auditing by retrievingproofs from that third party could be considered reasonableSTHs froma privacy perspective. The HTTPS client does its own auditing and might additionally share SCTs andpools. HTPS clients send STHswith the trusted partytocontributeHTTPS servers by POSTing them toherd immunity. Here,theordinary [RFC-6962-BIS] protocolwell- known URL: https://<domain>/.well-known/ct-gossip/v1/sth-pollination The data sent in the POST issufficientdefined in Section 8.2.4. This data SHOULD be sent in an already established TLS session. This makes it hard forthe clientan attacker todo the auditing while SCT Feedback anddisrupt STHPollination can be usedgossiping without also disturbing ordinary secure browsing (https://). This is discussed more inwholeSection 11.1.1. The response contains zero or more STHs inpartsthe same format, described in Section 8.2.4. An HTTPS client may acquire STHs by several methods: o in replies to pollination POSTs; o asking logs that it recognises for thegossip part. Another well established trusted party arrangement on the internet today is the relation between internet userscurrent STH, either directly (v2/get-sth) or indirectly (for example over DNS) o resolving an SCT andtheir providers of DNS resolver services. DNS resolvers are typically provided by the internet service provider (ISP) used, which by the nature of namecertificate to an STH via an inclusion proof o resolvingalready knowone STH to another via agreat deal about which sites their users visit. As mentioned in Section XXX, in order forconsistency proof HTTPS clients (that have STHs) and CT auditors SHOULD pollinate STH pools with STHs. Which STHs tobe able to retrieve proofs in a privacy preserving manner, logs could expose a DNS interface in addition tosend and how often pollination should happen is regarded as undefined policy with theordinary HTTPS interface. An informal writeup of such a protocol can be found at XXX. 7.3.1. Trusted Auditor data format [TBD specify something here or leave this for others?] 8. 3-Method Ecosystem The useexception ofthree distinct methodsprivacy concerns explained below. Suggestions formonitoring logsthe policy mayseem excessive, but each represents a needed componentbe found inthe CT ecosystem. To understand why, the drawbacks of each component mustSection 11.3. An HTTPS client could beoutlined. Intracked by giving it a unique or rare STH. To address thisdiscussionconcern, weassume that an attacker knows which mechanisms an HTTPS client and HTTPS server implement. 8.1. SCT Feedback SCT Feedback requires the cooperationplace restrictions on different components of the system to ensure an STH will not be rare. o HTTPS clientsand more importantly HTTPS servers. Although SCT Feedback does require a significant amountsilently ignore STHs from logs with an STH issuance frequency ofserver-side logic to respond tomore than one STH per hour. Logs use thecorresponding APIs,STH Frequency Count metadata to express thisfunctionality does not require customization, so it may be pre-provides([RFC-6962-BIS-09] sections 3.6 andwork out of5.1). o HTTPS clients silently ignore STHs which are not fresh. An STH is considered fresh iff its timestamp is less than 14 days in thebox. However, to take full advantagepast. Given a maximum STH issuance rate ofthe system,one per hour, anHTTPS server would wishattacker has 336 unique STHs per log for tracking. Clients MUST ignore STHs older than 14 days. We consider STHs within this validity window not toperform some configurationbe personally identifiable data, and STHs outside this window tooptimize its operation: o Minimize its disk commitmentbe personally identifiable. When multiplied bywhitelisting known SCTs and certificate chains o Maximize its chancethe number ofdetecting a misissued certificate by configuringlogs from which atrust storeclient accepts STHs, this number ofCAs o Establish a "push" mechanism for POSTing SCTs to Auditors and Monitors These configuration needs,unique STHs grow and thesimple fact that it would require some deployment of software, meansnegative privacy implications grow with it. It's important thatsome percentage ofthis is taken into account when logs are chosen for default settings in HTTPSservers will not deploy SCT Feedback. If SCT Feedback was the only mechanismclients. This concern is discussed upon in Section 10.4.5. A log may cease operation, in which case there will soon be no STH within theecosystem, any server that did not implement the feature, would open itself and its users to attack without any possibilityvalidity window. Clients SHOULD perform all three methods ofdetection. If SCT Feedback was not deployed, users who wished to havegossip about a log that has ceased operation since it is possible thestrongest measure of privacy protection (by disabling STH Pollination Proof Fetchinglog was still compromised andforgoing a Trusted Auditor) could be attacked without risk of detection. 8.2. STH Pollinationgossip can detect that. STH Pollinationrequiresis thecooperation of HTTPS clients, HTTPS servers, and logs. Forone mechanism where a client must know about a log shutdown. A client who does not know about a log shutdown MUST NOT attempt any heuristic tofully participate in STH Pollination, and have this mechanismdetectattacks against it,a shutdown. Instead the clientmust haveMUST be informed about the shutdown from away to safely perform Proof Fetching inverifiable source (e.g. aprivacy preserving manner.software update). The clientmay pollinateSHOULD be provided the final STH issued by the log and SHOULD resolve SCTs and STHsit receives without performing Proof Fetching, but we do not consider this option into thissection. HTTPS Servers must deploy software (although, as in the case withfinal STH. If an SCTFeedback this logic canor STH cannot bepre-provided) and commit some configurable amount of disk spaceresolved to theendeavor. Logs must provide access tofinal STH, clientsto query proofs in a privacy preserving manner, most likely through DNS. Unlike SCT Feedback,should follow theSTH Pollination mechanism is not hampered if only a minority of HTTPS servers deploy it. However, it makes an assumption that anrequirements and recommendations set forth in Section 11.1.2. 8.2.1. HTTPSclient performs anonymizedClients and Proof Fetching(such as the DNS mechanism discussed). However, any manner that is anonymous for some (such as clients who use shared DNS services such asThere are two types of proofs alarge ISP),client maynot be anonymous for others. For instance, DNS leaks a considerable amount of information (including what data is already presentretrieve; inclusion proofs and consistency proofs. An HTTPS client will retrieve SCTs from an HTTPS server, and must obtain an inclusion proof to an STH in order to verify thecache) in plaintext overpromise made by thenetwork. For this reason, some percentage ofSCT. An HTTPSclientsclient maychoosealso receive an SCT bundled with an inclusion proof tonot enable the Proof Fetching component ofa historical STHpollination. (Although they can still request and send STHs among participating HTTPS servers, as mentioned earliervia an unspecified future mechanism. Because thisaffords them no direct benefit.) If STH Pollination was the only mechanism deployed, users that disable it would be able to be attacked without risk of detection. Ifhistorical STHPollination was not deployed, HTTPS Clients visiting HTTPS Servers who did not deploy SCT Feedback could be attacked without risk of detection. 8.3. Trusted Auditor Relationship The Trusted Auditor Relationshipisexpected to beconsidered personally identifiable information per above, therarest gossip mechanism, as an HTTPS Client is providing an unadulterated report of its browsing history toclient must obtain athird party. While there are valid and common reasonsconsistency proof to a more recent STH. A client SHOULD perform proof fetching. A client MUST NOT perform proof fetching fordoing so, there is no appropriate wayany SCTs or STHs issued by a locally added log. A client MAY fetch an inclusion proof for an SCT (issued by a pre- loaded log) that validates a certificate chaining toenter intoa locally added trust anchor. [ TBD: Linus doesn't like thisrelationship without retrieving informed consentbecause we're mandating behavior that is not necessarily safe. Is it unsafe? Not sure.] If a client requested either proof directly from a log or auditor, it would reveal theuser. However, the Trusted Auditor Relationship mechanism still provides valueclient's browsing habits to aclass ofthird party. To mitigate this risk, an HTTPSClients. For example, web crawlers have no concept of a "user" and no expectation of privacy. Organizations already performing network monitoring for anomalies or attacks can run their own Trusted Auditor forclient MUST retrieve thesame purpose with marginal increaseproof inprivacy concerns. The ability to change one's Trusted Auditor is a form of Trust Agility that allowsauser to choose who to trust, and be able to revisemanner thatdecision later without consequence. A Trusted Auditor connection can be made more confidential thandisguises the client. Depending on the client's DNS(throughprovider, DNS may provide an appropriate intermediate layer that obfuscates theuse of TLS), and can even be made (somewhat) anonymous throughlinkability between theuseuser ofanonymity services such as Tor. (Note that this does ignorethede- anonymization possibilities available from viewing a user's browsing history.) Ifclient and theTrusted Auditor relationship wasrequest for inclusion (while at theonlysame time providing a caching layer for oft-requested inclusion proofs.) [ TODO: Add a reference to Google's DNS mechanismdeployed, users who do not enable it (the majority) would be ablemore proper than http://www.certificate-transparency.org/august-2015-newsletter ] Anonymity networks such as Tor also present a mechanism for a client tobe attacked without risk of detection. Ifanonymously retrieve a proof from an auditor or log. Even when using a privacy-preserving layer between theTrusted Auditor relationship was not deployed, crawlersclient andorganizationsthe log, certain observations may be made about an anonymous client or general user behavior depending on how proofs are fetched. For example, if a client fetched all outstanding proofs at once, a log wouldbuild it themselves for their own needs. By standardizing it, users who wishknow that SCTs or STHs recieved around the same time are more likely toopt-in (for instance those unwillingcome from a particular client. This could potentially go so far as correlation of activity at different times toparticipate fully in STH Pollination) can have an interoperable standard they cana single client. In aggregate the data could reveal what sites are commonly visited together. HTTPS clients SHOULD use a strategy of proof fetching that attempts tochoose and change their trusted auditor. 8.4. Interaction The interactionsobfuscate these patterns. A suggestion ofthe mechanisms is thus outlined: HTTPS Clientssuch a policy can beattacked without risk of detection if they do not participatefound inanySection 11.2. Resolving either SCTs and STHs may result in errors. These errors may be routine downtime or other transient errors, or they may be indicative ofthe three mechanisms. HTTPSan attack. Clientsare affordedshould follow thegreatest chance of detecting an attackrequirements and recommendations set forth in Section 11.1.2 whenthey either participatehandling these errors in order to give the CT ecosystem the greatest chance of detecting and responding to a compromise. 8.2.2. STH Pollinationwithwithout Proof Fetchingor have a Trusted Auditor relationship. Participating in SCT Feedback enables aAn HTTPSClient to assistclient MAY participate indetectingSTH Pollination without fetching proofs. In this situation, theexact target of an attack, although they do not gain any direct benefitclient receives STHs fromit. HTTPS Servers that omit SCT Feedback may never learn about targeted attacks against them, even ifa server, applies theattack occurred andsame validation logic to them (signed by a known log, within thelog distrusted. They do gain some herd immunity, enablingvalidity window) and will later pass them todetect attacks, through their clients participating in STH Pollination or a Trusted Auditor Relationship.an HTTPS server. When operating in this fashion, the HTTPSServers omit SCT feedback,client is promoting gossip for Certificate Transparency, but derives no direct benefit itself. In comparison, a client who resolves SCTs or historical STHs to recent STHs and pollinates them is assured that if itallowwas attacked, there is aportion of their usersprobability that the ecosystem will detect and respond tobe attacked without detection;thevulnerable users are those who do notattack (by distrusting the log). 8.2.3. Auditor Action CT auditors participate in STHPollination with Proof Fetching andpollination by retrieving STHs from HTTPS servers. They verify thatnot have a Trusted Auditor relationship. 9. Security considerations 9.1. Censorship/Blocking considerations We assume a network attacker whothe STH isable to fully controlvalid by checking theclient's internet connection for some period of time - including selectively blocking requests to certain hostssignature, andtruncating TLS connections based on information observed or guessed about client behavior. In order to successfully detect log misbehavior,requesting a consistency proof from thegossip mechanisms must still work even in these conditions. There are several gossip connections that can be blocked: 1. Clients sending SCTs to servers in SCT Feedback 2. Servers sending SCTsSTH toauditors in SCT Feedback (server push mechanism) 3. Servers making SCTs availablethe most recent STH. After retrieving the consistency proof toauditors (auditor pull mechanism) 4. Clients fetching proofs inthe most recent STH, they SHOULD pollinate this new STHPollination 5. Clients sendingamong participating HTTPS Servers. In this way, as STHs "age out" and are no longer fresh, their "lineage" continues toserversbe tracked in the system. 8.2.4. STH Pollination6. Servers sending STHs todata format The data sent from HTTPS clientsin STH Pollination 7. Clients sending SCTs to Trusted Auditors If a party cannot connectand CT auditors toanother party, it can be assured that the connection did not succeed. While it may not have been maliciously blocked, it knows the transaction did not succeed. Mechanisms which result in a positive affirmation from the recipient that the transaction succeeded allow confirmation thatHTTPS servers is aconnection was not blocked. In this situation,JSON object [RFC7159] with theparty can factor this into strategies suggestedfollowing content: o sths - an array of 0 or more fresh SignedTreeHead's as defined in [RFC-6962-BIS-09] Section10.13.6.1. 8.3. Trusted Auditor Stream HTTPS clients MAY send SCTs andin Section 10.2.2. The connectionscert chains, as well as STHs, directly to auditors. If sent, this data MAY include data thatallow positive affirmationreflects locally added logs or trust anchors. Note that there are1, 2, 4, 5,privacy implications in doing so, these are outlined in Section 10.4.1 and7. More insidiousSection 10.4.6. The most natural trusted auditor arrangement arguably isblocking the connectionsa web browser thatdo not allow positive confirmation: 3 and 6. An attacker may truncateis "logged in to" aor dropprovider of various internet services. Another equivalent arrangement is aresponse fromtrusted party like aservercorporation to which an employee is connected through aclient,VPN or by other similar means. A third might be individuals or smaller groups of people running their own services. In such a setting, retrieving proofs from thatthe server believes it has shared datathird party could be considered reasonable from a privacy perspective. The HTTPS client may also do its own auditing and might additionally share SCTs and STHs with therecipient, when it has not. However, in both scenatios (3 and 6),trusted party to contribute to herd immunity. Here, theserver cannot distinguishordinary [RFC-6962-BIS-09] protocol is sufficient for the clientas a cooperating member of the CT ecosystem or as an attacker performing a sybil attack, aimingtoflush the server's data store. Thereforedo thefact that these connectionsauditing while SCT Feedback and STH Pollination can beundetectably blocked does not actually alter the threat model of servers responding to these requests. The choice of algorithm to release data is crucial to protect against these attacks, strategies are suggestedused inSection 10.1. Handling censorship and network blocking (which is indistinguishable from network error)whole or in parts for the gossip part. Another well established trusted party arrangement on the internet today isrelegated totheimplementation policy chosen by clients. Suggestions for client behaviorrelation between internet users and their providers of DNS resolver services. DNS resolvers arespecifiedtypically provided by the internet service provider (ISP) used, which by the nature of name resolving already know a great deal about which sites their users visit. As mentioned in Section10.2. 9.2. Privacy considerations CT Gossip deals with8.2.1, in order for HTTPSClients which are tryingclients toshare indicators that correspondbe able totheir browsing history. The most sensitive relationshipsretrieve proofs in a privacy preserving manner, logs could expose a DNS interface in addition to theCT ecosystem are the relationships between HTTPS clients andordinary HTTPSservers. Client-server relationshipsinterface. An informal writeup of such a protocol can beaggregated intofound at XXX. 8.3.1. Trusted Auditor data format Trusted Auditors expose anetwork graph with potentially serious implications for correlative de-anonymisation of clients and relationship-mapping or clustering of servers or of clients. There are, however, certain clients that do not require privacy protection. Examples of these clients are web crawlers or robots but even in this case,REST API at themethodfixed URI: https://<auditor>/ct-gossip/v1/trusted-auditor Submissions are made bywhich these clients crawlsending an HTTPS POST request, with theweb maybody of the POST infact be considered sensitive information. In general, it is better to err ona JSON object. Upon successful receipt thesideTrusted Auditor returns 200 OK. The JSON object consists ofsafety,two top-level keys: 'sct_feedback' andnot assume a client'sths'. The 'sct_feedback' value isokay with giving up its privacy. 9.2.1. Privacy and SCTs An SCT contains information that links it to a particular web site. Because the client-server relationship is sensitive, gossip between clients and servers about unrelated SCTsan array of JSON objects as defined in Section 8.1.1. The 'sths' value isrisky. Therefore, a client withanSCTarray of STHs as defined in Section 8.2.4. Example: { 'sct_feedback' : [ { 'x509_chain' : [ '----BEGIN CERTIFICATE---\n AAA...', '----BEGIN CERTIFICATE---\n AAA...', ... ], 'sct_data' : [ 'AAA...', 'AAA...', ... ] }, ... ], 'sths' : [ 'AAA...', 'AAA...', ... ] } 9. 3-Method Ecosystem The use of three distinct methods for auditing logs may seem excessive, but each represents agiven server should transmit that informationneeded component inonly two channels: to a server associated withtheSCT itself; and to a trustedCTauditor, if one exists. 9.2.2. Privacy in SCT Feedback SCTs introduce yet another mechanism for HTTPS servers to store state onecosystem. To understand why, the drawbacks of each component must be outlined. In this discussion we assume that an attacker knows which mechanisms an HTTPSclient,client andpotentially track users.HTTPS server implement. 9.1. SCT Feedback SCT Feedback requires the cooperation of HTTPS clientswhich allow usersand more importantly HTTPS servers. Although SCT Feedback does require a significant amount of server-side logic to respond toclear history or cookies associated with an origin MUST clear stored SCTs associated withtheorigin as well. Auditors should treat all SCTs as sensitive data. SCTs received directly from an HTTPS client are especially sensitive, becausecorresponding APIs, this functionality does not require customization, so it may be pre-provided and work out of theauditor is a trusted bybox. However, to take full advantage of theclientsystem, an HTTPS server would wish tonot reveal their associations with servers. Auditors MUST NOT share such SCTs in any way, including sending themperform some configuration toan external log, without first mixing them with multiple other SCTs learned through submissions from multiple other clients. Suggestions for mixingoptimize its operation: o Minimize its disk commitment by maintaining a list of known SCTsare presented in Section 10.1. There isand certificate chains (or hashes thereof) o Maximize its chance of detecting apossible fingerprinting attack wheremisissued certificate by configuring alog issuestrust store of CAs o Establish aunique SCT"push" mechanism fortargeted log client(s). A colluding log and HTTPS server operator could therefore be a threatPOSTing SCTs to CT auditors These configuration needs, and theprivacysimple fact that it would require some deployment of software, means that some percentage ofan HTTPS client. Given all the other opportunities forHTTPS serversto fingerprint clients - TLS session tickets, HPKP and HSTS headers, HTTP Cookies, etc. - thiswill not deploy SCT Feedback. It isacceptable. The fingerprinting attack described above would be mitigated by a requirementworthwhile to note thatlogs MUST usean attacker may be able to prevent detection of an attack on adeterministic signature scheme when signing SCTs ([RFC-6962-BIS] Section 2.1.4). A log signing using RSAwebserver (in all cases) if SCT Feedback is notrequired to use a deterministic signature scheme. Since logs are allowed to issue a newimplemented. This attack is detailed in Section 10.1). If SCTfor a certificate already presentFeedback was the only mechanism in thelog, mandating deterministic signatures doesecosystem, any server that did notstop this fingerprinting attack altogether. It does makeimplement theattack harderfeature would open itself and its users topull offattack withoutbeing detected though. Thereany possibility of detection. If SCT Feedback isanother similar fingerprinting attack where an HTTPS server tracks a clientnot deployed byusingavariation of cert chains. The risk for thiswebserver, malicious logs will be able to attackis accepted onall users of thesame grounds aswebserver (who do not have a Trusted Auditor relationship) with impunity. Additionally, users who wish to have theunique SCT attack described above. [XXX any mitigations possible here?] 9.2.3. Privacy for HTTPS clients performingstrongest measure of privacy protection (by disabling STH Pollination Proof FetchingAn HTTPS client performing Proof Fetching should only request proofs fromand forgoing aCT log that it accepts SCTs from. AnTrusted Auditor) could be attacked without risk of detection. 9.2. STH Pollination STH Pollination requires the cooperation of HTTPS clients, HTTPS servers, and logs. For a clientshould regularly [TBD how regularly? This has operational implications for log operators] request an STH from all logs it is willingtoaccept, even if it has seen no SCTs from that log. The actualfully participate in STH Pollination, and have this mechanismby which Proof Fetching is done carries considerable privacy concerns. Although out of scope fordetect attacks against it, thedocument, DNS isclient must have amechanism currently discussed. DNS leaks dataway to safely perform Proof Fetching inplaintext over the network (including what sites the user is visiting and what sites they have previously visited) - thus ita privacy preserving manner. (The client may pollinate STHs it receives without performing Proof Fetching, but we do notbe suitable for some. 9.2.4. Privacyconsider this option inSTH Pollination An STH linked to anthis section.) HTTPSclient may indicate the following about that client: o that the client gossips; o that the client has been using CT at least until the time that the timestamp and the tree size indicate; o that the client is talking, possibly indirectly, to the log indicated by the tree hash; o whichServers must deploy software (although, as in the case with SCT Feedback this logic can be pre-provided) andsoftware version is being used. There is a possible fingerprinting attack where a log issues a unique STH for a targeted HTTPS client. This is similarcommit some configurable amount of disk space to thefingerprinting attack described in Section 9.2.2, but can operate cross-origin. If a logendeavor. Logs (orHTTPS Server cooperating withalog) provides a unique STHthird party) must provide access to clients to query proofs in aclient, the targeted client will beprivacy preserving manner, most likely through DNS. Unlike SCT Feedback, theonly client pollinating thatSTHcross-origin. It is mitigated partially because the logPollination mechanism islimited in the numbernot hampered if only a minority ofSTHsHTTPS servers deploy it. However, itcan issue. It must 'save' one of its STHs each MMD to perform the attack. 9.2.5. Privacy in STH Interaction Anmakes an assumption that an HTTPS clientmay pollinate any STH withinperforms Proof Fetching (such as thelast 14 days. An HTTPS Client may also pollinate an STH forDNS mechanism discussed). Unfortunately, anylogmanner thatit knows about. When a client pollinates STHs to a server, it will release more than one STH at a time. Itisunclear ifanonymous for some (such as clients who use shared DNS services such as aserverlarge ISP), may'prime' a client andnot beable to reliably detect the client at a later time. It's clear that a single site can trackanonymous for others. For instance, DNS requests expose auser any way they wish, but this attack works cross-origin andconsiderable amount of sensitive information (including what data istherefore more concerning. Two independent sites A and B want to collaborate to track a user cross- origin. A feeds a client Carol some N specific STHs fromalready present in theM logs Carol trusts, chosen to be older and less common, but stillcache) in plaintext over thevalidity window. Carol visits B and chooses to releasenetwork. For this reason, some percentage ofthe STHs she has stored, accordingHTTPS clients may choose tosome policy. Modeling a representation for how common older STHs are innot enable thepoolsProof Fetching component ofclients,STH Pollination. (Although they can still request andexamining that with a given policy of how to choose which of those STHs tosendto B,STHs among participating HTTPS servers, even when this affords them no direct benefit.) If STH Pollination was the only mechanism deployed, users that disable itshouldwould bepossible to calculate statistics about how unique Carol looks when talkingable toB and how useful/accurate such a tracking mechanism is. Building such a model is likely impossiblebe attacked withoutsome real world data, and requires a given implementationrisk ofa policy. To combat this attack, suggestions are provided in Section 10.1 to attempt to minimize it, but follow-up testing with real world deployment to improvise the policy will be required. 9.2.6. Trusted Auditors fordetection. If STH Pollination was not deployed, HTTPS ClientsSomevisiting HTTPSclients may choose to use a trusted auditor. This trust relationship leaks a large amountServers who did not deploy SCT Feedback could be attacked without risk ofinformation from the client to the auditor. In particular, it will identify the web sites that the client has visiteddetection. 9.3. Trusted Auditor Relationship The Trusted Auditor Relationship is expected to be theauditor. Some clients may already share this informationrarest gossip mechanism, as an HTTPS Client is providing an unadulterated report of its browsing history to a thirdparty,party. While there are valid and common reasons forexample, when using a server to synchronize browser history across devices in a server-visible way, or whendoingDNS lookups throughso, there is no appropriate way to enter into this relationship without retrieving informed consent from the user. However, the Trusted Auditor Relationship mechanism still provides value to atrusted DNS resolver.class of HTTPS Clients. Forclients with suchexample, web crawlers have no concept of arelationship"user" and no expectation of privacy. Organizations alreadyestablished, sending SCTs to a trusted auditorperforming network auditing for anomalies or attacks can runbytheir own Trusted Auditor for the sameorganization does not appear to leak any additional information to the trusted third party. Clients who wish to contact an auditor without associating their identitiespurpose withtheir SCTs may wish to use an anonymizing network like Tor to submit SCT Feedbackmarginal increase in privacy concerns. The ability tothe auditor. Auditors SHOULD accept SCT Feedbackchange one's Trusted Auditor is a form of Trust Agility thatarrives over such anonymizing networks. Clients sending feedbackallows a user toan auditor may preferchoose who toreduce the temporal granularity of the history leakagetrust, and be able to revise that decision later without consequence. A Trusted Auditor connection can be made more confidential than DNS (through theauditor by cachinguse of TLS), anddelaying their SCT Feedback reports. This elaborated upon in XXX Mixing. This strategy is only as effective ascan even be made (somewhat) anonymous through thegranularityuse ofthe timestamps embedded in the SCTs and STHs. 9.2.7. HTTPS Clients as Auditors Some HTTPS Clients may choose to actanonymity services such asAuditors themselves. A Client taking on this role needs to consider the following: o an Auditing HTTPS Client potentially leaks their history to the logsTor. (Note thatthey query. Querying the log through a cache or a proxy with many other users may avoidthisleakage, but may leak information to the cache or proxy, indoes ignore thesame way that an non- Auditing HTTPS Client leaks information tode- anonymization possibilities available from viewing atrusted auditor. o an effectiveuser's browsing history.) If the Trusted Auditorneeds a strategy about what to do inrelationship was theevent thatonly mechanism deployed, users who do not enable itdiscovers misbehavior from a log. Misbehavior from a log involves the log being unable(the majority) would be able toprovide either (a) a consistency proof between two valid STHs or (b) an inclusion proofbe attacked without risk of detection. If the Trusted Auditor relationship was not deployed, crawlers and organizations would build it themselves fora certificatetheir own needs. By standardizing it, users who wish toanopt-in (for instance those unwilling to participate fully in STH Pollination) can have an interoperable standard they can use to choose and change their trusted auditor. 9.4. Interaction The interactions of the mechanisms is thus outlined: HTTPS Clients can be attacked without risk of detection if they do not participate in anytime afterof thelog's MMD has elapsed fromthree mechanisms. HTTPS Clients are afforded theissuancegreatest chance ofthe SCT. The log's inability to providedetecting an attack when they eitherproof will not be externally cryptographically- verifiable, as it may be indistinguishable fromparticipate in both SCT Feedback and STH Pollination with Proof Fetching or if they have anetwork error. 10. Policy Recommendations This sectionTrusted Auditor relationship. (Participating in SCT Feedback isintendedrequired to prevent a malicious log from refusing to ever resolve an SCT to an STH, assuggestionsput forward in Section 10.1). Additionally, participating in SCT Feedback enables an HTTPS Client toimplementorsassist in detecting the exact target of an attack. HTTPSClients, HTTPS Servers, and Auditors. It is not a requirement for techniqueServers that omit SCT Feedback enable malicious logs to carry out attacks without risk ofimplementation, so long as privacy considerations established abovedetection. If these servers areobeyed. 10.1. Mixing Recommendations In several components oftargeted specifically, even if theCT Gossip ecosystem, the recommendationattack ismadedetected, without SCT Feedback they may never learn thatdata from multiple sources be ingested, mixed, provided to a third party, stored for an indeterminate period of time, and eventually deleted. The instancesthey were specifically targeted. HTTPS servers without SCT Feedback do gain some measure ofthese recommendationsherd immunity, but only because their clients participate inthis draft are: o WhenSTH Pollination (with Proof Fetching) or have aclient receives SCTs duringTrusted Auditor Relationship. When HTTPS Servers omit SCTFeedback,feedback, itshould storeallows their users to be attacked without detection by a malicious log; theSCTs and Certificates for some amount of time, provide somevulnerable users are those who do not have a Trusted Auditor relationship. 10. Security considerations 10.1. Attacks by actively malicious logs One ofthem backthe most powerful attacks possible in the CT ecosystem is a trusted log that has actively decided to be malicious. It can carry out an attack in two ways: In theserver at some point, and eventually remove them from its store o Whenfirst attack, the log can present aclient receives STHs during STH Pollination, it should store them for some amount of time, mix them with other STHs, release somesplit view ofthem themthe log for all time. The only way to detect this attack is tovarious servers at some point,resolvesomeeach view ofthemthe log tonew STHs,the two most recent STHs andeventually remove them from its store o Whenthen force the log to present aserver receives SCTs during SCT Feedback,consistency proof. (Which itshould store them for some period of time, provide them to auditors some number of times, and may eventually remove them o When a server receives STHs duringcannot.) This attack can be detected by CT auditors participating in STH Pollination,it should store them for some period of time, mix them with other STHs, provide someas long as they are explicitly built to handle the situation ofthema log continuously presenting a split view. In the second attack, the log can sign an SCT, and refuse toconnecting clients, may resolve themever include the certificate that the SCT refers tonew STHs via Proof Fetching, and eventually remove them from its store o When a Trusted Auditor receives SCTs or historical STHs from clients,in the tree. (Alternately, itshould store them for some periodcan include it in a branch oftime, mix them with SCTs received from other clients,the tree andact upon them at some period of time Each of these instances have specific requirementsissue an STH, but then abandon that branch.) Whenever someone requests an inclusion proof foruser privacy, and each have optionsthatmay not be invoked. As one example,SCT (or aHTTPS client should not mix SCTsconsistency proof fromserver Athat STH), the log would respond withSCTs from server Ban error, andrelease server B's SCTs to Server A. As another example,aHTTPS serverclient maychoose to resolve several STHssimply regard the response as a transient error. This attack can be detected using SCT Feedback, or an Auditor of Last Resort, as presented in Section 11.1.2. 10.2. Dual-CA Compromise XXX describes an attack possible by an adversary who compromises two Certificate Authorites and a Log. This attack is difficult to defend against in the CT ecosystem, and XXX describes asingle more current STH via proof fetching, but itfew approaches to doing so. We note that Gossip is not intended to defend against this attack, but can in certain modes. Defending against the Dual-CA Compromise attack requires SCT Feedback, and explicitly requires the server to save full certificate chains (described in Section 8.1.3 as the 'complex' configuration.) After CT auditors receive the full certificate chains from servers, they must compare the chain built by clients to the chain supplied by the log. If the chains differ significantly, the auditor can raise a concern. [ What does 'differ significantly' mean? We should provide guidance. I _think_ the correct algorithm to raise a concern is: If one chain is not a subset of the other AND If the root certificates of the chains are different THEN It's suspicious. Justification: - Cross-Signatures could result in a different org being treated as the 'root', but in this case, one chain would be a subset of the other. - Intermediate swapping (e.g. different signature algorithms) could result in different chains, but the root would be the same. (Hitting both those cases at once would cause a false positive though.) What did I miss? ] 10.3. Censorship/Blocking considerations We assume a network attacker who is able to fully control the client's internet connection for some period of time, including selectively blocking requests to certain hosts and truncating TLS connections based on information observed or guessed about client behavior. In order to successfully detect log misbehavior, the gossip mechanisms must still work even in these conditions. There are several gossip connections that can be blocked: 1. Clients sending SCTs to servers in SCT Feedback 2. Servers sending SCTs to auditors in SCT Feedback (server push mechanism) 3. Servers making SCTs available to auditors (auditor pull mechanism) 4. Clients fetching proofs in STH Pollination 5. Clients sending STHs to servers in STH Pollination 6. Servers sending STHs to clients in STH Pollination 7. Clients sending SCTs to Trusted Auditors If a party cannot connect to another party, it can be assured that the connection did not succeed. While it may not have been maliciously blocked, it knows the transaction did not succeed. Mechanisms which result in a positive affirmation from the recipient that the transaction succeeded allow confirmation that a connection was not blocked. In this situation, the party can factor this into strategies suggested in Section 11.3 and in Section 11.1.2. The connections that allow positive affirmation are 1, 2, 4, 5, and 7. More insidious is blocking the connections that do not allow positive confirmation: 3 and 6. An attacker may truncate or drop a response from a server to a client, such that the server believes it has shared data with the recipient, when it has not. However, in both scenatios (3 and 6), the server cannot distinguish the client as a cooperating member of the CT ecosystem or as an attacker performing a sybil attack, aiming to flush the server's data store. Therefore the fact that these connections can be undetectably blocked does not actually alter the threat model of servers responding to these requests. The choice of algorithm to release data is crucial to protect against these attacks; strategies are suggested in Section 11.3. Handling censorship and network blocking (which is indistinguishable from network error) is relegated to the implementation policy chosen by clients. Suggestions for client behavior are specified in Section 11.1. 10.4. Privacy considerations CT Gossip deals with HTTPS Clients which are trying to share indicators that correspond to their browsing history. The most sensitive relationships in the CT ecosystem are the relationships between HTTPS clients and HTTPS servers. Client-server relationships can be aggregated into a network graph with potentially serious implications for correlative de-anonymisation of clients and relationship-mapping or clustering of servers or of clients. There are, however, certain clients that do not require privacy protection. Examples of these clients are web crawlers or robots. But even in this case, the method by which these clients crawl the web may in fact be considered sensitive information. In general, it is better to err on the side of safety, and not assume a client is okay with giving up its privacy. 10.4.1. Privacy and SCTs An SCT contains information that links it to a particular web site. Because the client-server relationship is sensitive, gossip between clients and servers about unrelated SCTs is risky. Therefore, a client with an SCT for a given server should transmit that information in only two channels: to the server associated with the SCT itself; and to a Trusted Auditor, if one exists. 10.4.2. Privacy in SCT Feedback SCTs introduce yet another mechanism for HTTPS servers to store state on an HTTPS client, and potentially track users. HTTPS clients which allow users to clear history or cookies associated with an origin MUST clear stored SCTs and certificate chains associated with the origin as well. Auditors should treat all SCTs as sensitive data. SCTs received directly from an HTTPS client are especially sensitive, because the auditor is a trusted by the client to not reveal their associations with servers. Auditors MUST NOT share such SCTs in any way, including sending them to an external log, without first mixing them with multiple other SCTs learned through submissions from multiple other clients. Suggestions for mixing SCTs are presented in Section 11.3. There is a possible fingerprinting attack where a log issues a unique SCT for targeted log client(s). A colluding log and HTTPS server operator could therefore be a threat to the privacy of an HTTPS client. Given all the other opportunities for HTTPS servers to fingerprint clients - TLS session tickets, HPKP and HSTS headers, HTTP Cookies, etc. - this is considered acceptable. The fingerprinting attack described above would be mitigated by a requirement that logs MUST use a deterministic signature scheme when signing SCTs ([RFC-6962-BIS-09] Section 2.1.4). A log signing using RSA is not required to use a deterministic signature scheme. Since logs are allowed to issue a new SCT for a certificate already present in the log, mandating deterministic signatures does not stop this fingerprinting attack altogether. It does make the attack harder to pull off without being detected though. There is another similar fingerprinting attack where an HTTPS server tracks a client by using a unqiue certificate or a variation of cert chains. The risk for this attack is accepted on the same grounds as the unique SCT attack described above. [XXX any mitigations possible here?] 10.4.3. Privacy for HTTPS clients performing STH Proof Fetching An HTTPS client performing Proof Fetching should only request proofs from a CT log that it accepts SCTs from. An HTTPS client MAY [TBD SHOULD?] regularly request an STH from all logs it is willing to accept, even if it has seen no SCTs from that log. [ TBD how regularly? This has operational implications for log operators ] The actual mechanism by which Proof Fetching is done carries considerable privacy concerns. Although out of scope for the document, DNS is a mechanism currently discussed. DNS exposes data in plaintext over the network (including what sites the user is visiting and what sites they have previously visited) an may not be suitable for some. 10.4.4. Privacy in STH Pollination An STH linked to an HTTPS client may indicate the following about that client: o that the client gossips; o that the client has been using CT at least until the time that the timestamp and the tree size indicate; o that the client is talking, possibly indirectly, to the log indicated by the tree hash; o which software and software version is being used. There is a possible fingerprinting attack where a log issues a unique STH for a targeted HTTPS client. This is similar to the fingerprinting attack described in Section 10.4.2, but can operate cross-origin. If a log (or HTTPS Server cooperating with a log) provides a unique STH to a client, the targeted client will be the only client pollinating that STH cross-origin. It is mitigated partially because the log is limited in the number of STHs it can issue. It must 'save' one of its STHs each MMD to perform the attack. 10.4.5. Privacy in STH Interaction An HTTPS client may pollinate any STH within the last 14 days. An HTTPS Client may also pollinate an STH for any log that it knows about. When a client pollinates STHs to a server, it will release more than one STH at a time. It is unclear if a server may 'prime' a client and be able to reliably detect the client at a later time. It's clear that a single site can track a user any way they wish, but this attack works cross-origin and is therefore more concerning. Two independent sites A and B want to collaborate to track a user cross- origin. A feeds a client Carol some N specific STHs from the M logs Carol trusts, chosen to be older and less common, but still in the validity window. Carol visits B and chooses to release some of the STHs she has stored, according to some policy. Modeling a representation for how common older STHs are in the pools of clients, and examining that with a given policy of how to choose which of those STHs to send to B, it should be possible to calculate statistics about how unique Carol looks when talking to B and how useful/accurate such a tracking mechanism is. Building such a model is likely impossible without some real world data, and requires a given implementation of a policy. To combat this attack, suggestions are provided in Section 11.3 to attempt to minimize it, but follow-up testing with real world deployment to improve the policy will be required. 10.4.6. Trusted Auditors for HTTPS Clients Some HTTPS clients may choose to use a trusted auditor. This trust relationship exposes a large amount of information about the client to the auditor. In particular, it will identify the web sites that the client has visited to the auditor. Some clients may already share this information to a third party, for example, when using a server to synchronize browser history across devices in a server- visible way, or when doing DNS lookups through a trusted DNS resolver. For clients with such a relationship already established, sending SCTs to a trusted auditor run by the same organization does not appear to expose any additional information to the trusted third party. Clients who wish to contact a CT auditor without associating their identities with their SCTs may wish to use an anonymizing network like Tor to submit SCT Feedback to the auditor. Auditors SHOULD accept SCT Feedback that arrives over such anonymizing networks. Clients sending feedback to an auditor may prefer to reduce the temporal granularity of the history exposure to the auditor by caching and delaying their SCT Feedback reports. This is elaborated upon in Section 11.3. This strategy is only as effective as the granularity of the timestamps embedded in the SCTs and STHs. 10.4.7. HTTPS Clients as Auditors Some HTTPS Clients may choose to act as CT auditors themselves. A Client taking on this role needs to consider the following: o an Auditing HTTPS Client potentially exposes its history to the logs that they query. Querying the log through a cache or a proxy with many other users may avoid this exposure, but may expose information to the cache or proxy, in the same way that a non- Auditing HTTPS Client exposes information to a Trusted Auditor. o an effective CT auditor needs a strategy about what to do in the event that it discovers misbehavior from a log. Misbehavior from a log involves the log being unable to provide either (a) a consistency proof between two valid STHs or (b) an inclusion proof for a certificate to an STH any time after the log's MMD has elapsed from the issuance of the SCT. The log's inability to provide either proof will not be externally cryptographically- verifiable, as it may be indistinguishable from a network error. 11. Policy Recommendations This section is intended as suggestions to implementors of HTTPS Clients, HTTPS Servers, and CT auditors. It is not a requirement for technique of implementation, so long as privacy considerations established above are obeyed. 11.1. Blocking Recommendations 11.1.1. Frustrating blocking When making gossip connections to HTTPS Servers or Trusted Auditors, it is desirable to minimize the plaintext metadata in the connection that can be used to identify the connection as a gossip connection and therefore be of interest to block. Additionally, introducing some randomness into client behavior may be important. We assume that the adversary is able to inspect the behavior of the HTTPS client and understand how it makes gossip connections. As an example, if a client, after establishing a TLS connection (and receiving an SCT, but not making its own HTTP request yet), immediately opens a second TLS connection for the purpose of gossip, the adversary can reliably block this second connection to block gossip without affecting normal browsing. For this reason it is recommended to run the gossip protocols over an existing connection to the server, making use of connection multiplexing such as HTTP Keep-Alives or SPDY. Truncation is also a concern. If a client always establishes a TLS connection, makes a request, receives a response, and then always attempts a gossip communication immediately following the first response, truncation will allow an attacker to block gossip reliably. For these reasons, we recommend that, if at all possible, clients SHOULD send gossip data in an already established TLS session. This can be done through the use of HTTP Pipelining, SPDY, or HTTP/2. 11.1.2. Responding to possible blocking In some cirsumstances a client may have a piece of data that they have attempted to share (via SCT Feedback or STH Pollination), but have been unable to do so: with every attempt they recieve an error. These situations are: 1. The client has an SCT and a certificate, and attempts to retrieve an inclusion proof - but recieves an error on every attempt. 2. The client has an STH, and attempts to resolve it to a newer STH via a consistency proof - but recieves an error on every attempt. 3. The client has attempted to share an SCT and constructed certificate via SCT Feedback - but recieves an error on every attempt. 4. The client has attempted to share an STH via STH Pollination - but recieves an error on every attempt. 5. The client has attempted to share a specific piece of data with a Trusted Auditor - but recieves an error on every attempt. In the case of 1 or 2, it is conceivable that the reason for the errors is that the log acted improperly, either through malicious actions or compromise. A proof may not be able to be fetched because it does not exist (and only errors or timeouts occur). One such situation may arise because of an actively malicious log, as presented in Section 10.1. This data is especially important to share with the broader internet to detect this situation. If an SCT has attempted to be resolved to an STH via an inclusion proof multiple times, and each time has failed, a client SHOULD make every effort to send this SCT via SCT Feedback. However the client MUST NOT share the data with any other third party (excepting a Trusted Auditor should one exist). If an STH has attempted to be resolved to a newer STH via a consistency proof multiple times, and each time has failed, a client MAY share the STH with an "Auditor of Last Resort" even if the STH in question is no longer within the validity window. This auditor may be pre-configured in the client, but the client SHOULD permit a user to disable the functionality or change whom data is sent to. The Auditor of Last Resort itself represents a point of failure, so if implemented, it should connect using public key pinning and not considered an item delivered until it recieves a confirmation. In the cases 3, 4, and 5, we assume that the webserver(s) or trusted auditor in question is either experiencing an operational failure, or being attacked. In both cases, a client SHOULD retain the data for later submission (subject to Private Browsing or other history- clearing actions taken by the user.) This is elaborated upon more in Section 11.3. 11.2. Proof Fetching Recommendations Proof fetching (both inclusion proofs and consistency proofs) should be performed at random time intervals. If proof fetching occured all at once, in a flurry of activity, a log would know that SCTs or STHs recieved around the same time are more likely to come from a particular client. While proof fetching is required to be done in a manner that attempts to be anonymous from the perspective of the log, the correlation of activity to a single client would still reveal patterns of user behavior we wish to keep confidential. These patterns could be recognizable as a single user, or could reveal what sites are commonly visited together in the aggregate. [ TBD: What other recommendations do we want to make here? We can talk more about the inadequecies of DNS... The first paragraph is 80% identical between here and above ] 11.3. Record Distribution Recommendations In several components of the CT Gossip ecosystem, the recommendation is made that data from multiple sources be ingested, mixed, stored for an indeterminate period of time, provided (multiple times) to a third party, and eventually deleted. The instances of these recommendations in this draft are: o When a client receives SCTs during SCT Feedback, it should store the SCTs and Certificate Chain for some amount of time, provide some of them back to the server at some point, and may eventually remove them from its store o When a client receives STHs during STH Pollination, it should store them for some amount of time, mix them with other STHs, release some of them them to various servers at some point, resolve some of them to new STHs, and eventually remove them from its store o When a server receives SCTs during SCT Feedback, it should store them for some period of time, provide them to auditors some number of times, and may eventually remove them o When a server receives STHs during STH Pollination, it should store them for some period of time, mix them with other STHs, provide some of them to connecting clients, may resolve them to new STHs via Proof Fetching, and eventually remove them from its store o When a Trusted Auditor receives SCTs or historical STHs from clients, it should store them for some period of time, mix them with SCTs received from other clients, and act upon them at some period of time Each of these instances have specific requirements for user privacy, and each have options that may not be invoked. As one example, an HTTPS client should not mix SCTs from server A with SCTs from server B and release server B's SCTs to Server A. As another example, an HTTPS server may choose to resolve STHs to a single more current STH via proof fetching, but it is under no obligation to do so. These requirements should be met, but the general problem of aggregating multiple pieces of data, choosing when and how many to release, and when to remove them is shared. This problem has previously been considered in the case of Mix Networks and Remailers, including papers such as "From a Trickle to a Flood: Active Attacks on Several Mix Types", [Y], and [Z]. There are several concerns to be addressed in this area, outlined below. 11.3.1. Mixing Algorithm When SCTs or STHs are recorded by a participant in CT Gossip and later used, it is important that they are selected from the datastore in a non-deterministic fashion. This is most important for servers, as they can be queried for SCTs and STHs anonymously. If the server used a predictable ordering algorithm, an attacker could exploit the predictability to learn information about a client. One such method would be by observing the (encrypted) traffic to a server. When a client of interest connects, the attacker makes a note. They observe more clients connecting, and predicts at what point the client-of-interest's data will be disclosed, and ensures that they query the server at that point. Although most important for servers, random ordering is still strongly recommended for clients and Trusted Auditors. The above attack can still occur for these entities, although the circumstances are less straightforward. For clients, an attacker could observe their behavior, note when they recieve an STH from a server, and use javascript to cause a network connection at the correct time to force a client to disclose the specific STH. Trusted Auditors are stewards of sensitive client data. If an attacker had the ability to observe the activities of a Trusted Auditor (perhaps by being a log, or another auditor), they could perform the same attack - noting the disclosure of data from a client to the Trusted Auditor, and then correlating a later disclosure from the Trusted Auditor as coming from that client. Random ordering can be ensured by several mechanisms. A datastore can be shuffled, using a secure shuffling algorithm such as Fisher- Yates. Alternately, a series of random indexes into the data store can be selected (if a collision occurs, a new index is selected.) A cryptographyically secure random number generator must be used in either case. If shuffling is performed, the datastore must be marked 'dirty' upon item insertion, and at least one shuffle operation occurs on a dirty datastore before data is retrieved from it for use. 11.3.2. Flushing Attacks A flushing attack is an attempt by an adversary to flush a particular piece of data from a pool. In the CT Gossip ecosystem, an attacker may have performed an attack and left evidence of a compromised log on a client or server. They would be interested in flushing that data, i.e. tricking the target into gossiping or pollinating the incriminating evidence with only attacker-controlled clients or servers with the hope they trick the target into deleting it. Servers are most vulnerable to flushing attacks, as they release records to anonymous connections. An attacker can perform a Sybil attack - connecting to the server hundreds or thousands of times in an attempt to trigger repeated release of a record, and then deletion. For this reason, servers must be especially aggressive about retaining data for a longer period of time. Clients are vulnerable to flushing attacks targetting STHs, as these can be given to any cooperating server and an attacker can generally induce connections to random servers using javascript. It would be more difficult to perform a flushing attack against SCTs, as the target server must be authenticated (and an attacker impersonating an authentic server presents a recursive problem for the attacker). Nonetheless, flushing SCTs should not be ruled impossible. A Trusted Auditor may also be vulnerable to flushing attacks if it does not perform auditing operations itself. Flushing attacks are defended against using non-determinism and dummy messages. The goal is to ensure that an adversary does not know for certain if the data in question has been released or not, and if it has been deleted or not. [ TBD: At present, we do not have any support for dummy messages. Do we want to define a dummy message that clients and servers alike know to ignore? Will HTTP Compression leak the presence of >1 dummy messages? Is it sufficient to define a dummy message as _anything_ with an invalid siganture? This would negatively impact SCT Feedback servers that log all things just in case they're interesting. ] 11.3.3. The Deletion Algorithm No entity in CT Gossip is required to delete SCTs or STHs at any time, except to respect user's wishes such as private browsing mode or clearing history. However, requiring infinite storage space is not a desirable characteristic in a protocol, so deletion is expected. While deletion of SCTs and STHs will occur, proof fetching can ensure that any misbehavior from a log will still be detected, even after the direct evidence from the attack is deleted. Proof fetching ensures that if a log presents a split view for a client, they must maintain that split view in perpetuity. An inclusion proof from an SCT to an STH does not erase the evidence - the new STH is evidence itself. A consistency proof from that STH to a new one likewise - the new STH is every bit as incriminating as the first. (Client behavior in the situation where an SCT or STH cannot be resolved is suggested in Section 11.1.2.) Because of this property, we recommend that if a client is performing proof fetching, that they make every effort to not delete an SCT or STH until it has been successfully resolved to a new STH via a proof. When it is time to delete a record, it is important that the decision to do so not be done deterministicly. Introducing non-determinism in the decision is absolutely necessary to prevent an adversary from knowing with certainty that the record has been successfully flushed from a target. Therefore, we speak of making a record 'eligible for deletion' and then being processed by the 'deletion algorithm'. Making a record eligible for deletion simply means that it will have the deletion algorithm run. The deletion algorithm will use a probability based system and a secure random number generator to determine if the record will be deleted. Although the deletion algorithm is specifically designed to be non- deterministic, if the record has been resolved via proof to a new STH the record may be safely deleted, as long as the new STH is retained. The actual deletion algorithm may be [STATISTICS HERE]. [ Something as simple as 'Pick an integer securely between 1 and 10. If it's greater than 7, delete the record.' Or something more complicated. ] [ TODO Enumerating the problems of different types of mixes vs Cottrell Mix ] 11.3.3.1. Experimental Algorithms More complex algorithms could be inserted at any step. Three examples are illustrated: SCTs are not eligible to be submitted to an Auditor of Last Resort. Therefore, it is more important that they be resolved to STHs and reported via SCT feedback. If fetching an inclusion proof regularly fails for a particular SCT, one can require it be reported more times than normal via SCT Feedback before becoming eligible for deletion. Before an item is made eligible for deletion by a client, the client could aim to make it difficult for a point-in-time attacker to flush the pool by not making an item eligible for deletion until the client has moved networks (as seen by either the local IP address, or a report-back providing the client with its observed public IP address). The HTTPS client could also require reporting over a timespan, e.g. it must be reported at least N time, M weeks apart. This strategy could be employed always, or only when the client has disabled proof fetching and the Auditor of Last Resort, as those two mechanisms (when used together) will enable a client to report most attacks. 11.3.3.2. Concrete Recommendations The recommendations for behavior are: - If proof fetching is enabled, do not delete an SCT until it has had a proof resolving it to an STH. - If proof fetching continually fails for an SCT, do not make the item eligible for deletion of the SCT until it has been released, multiple times, via SCT Feedback. - If proof fetching continually fails for an STH, do not make the item eligible for deletion until it has been queued for release to an Auditor of Last Resort. - Do not dequeue entries to an Auditor of Last Resort if reporting fails. Instead keep the items queued until they have been successfully sent. - Use a probability based system, with a cryptographically secure random number generator, to determine if an item should be deleted. - Select items from the datastores by selecting random indexes into the datastore. Use a cryptographically secure random number generator. [ TBD: More? ] We present the following pseudocode as a concrete outline of our suggestion. 11.3.3.2.1. STH Data Structures The STH class contains data pertaining specifically to the STH itself. class STH { uint32 proof_attempts uint32 proof_failure_count uint32 num_reports_to_thirdparty datetime timestamp byte[] data } The broader STH store itself would contain all the STHs known by an entity participating in STH Pollination (either client or server). This simplistic view of the class does not take into account the complicated locking that would likely be required for a data structure being accessed by multiple threads. One thing to note about this pseudocode is that it aggressively removes STHs once they have been resolved to a newer STH (if proof fetching is configured). The only STHs in the store are ones that have never been resolved to a newer STH, either because proof fetching does not occur, has failed, or because the STH is considered too new to request a proof for. It seems less likely that servers will perform proof fetching. Therefore it would be recommended that the various constants in use be increased considerably to ensure STHs are pollinated more aggressively. class STHStore { STH[] sth_list // This function is run after receiving a set of STHs from // a third party in response to a pollination submission def insert(STH[] new_sths) { foreach(new in new_sths) { if(this.sth_list.contains(new)) continue this.sth_list.insert(new) } } // This function isunder no obligationcalled todo so. These requirements should be met, butpossibly delete thegeneral problem of aggregating multiple pieces of data, choosing when and how many to release,given STH // from the data store def delete_maybe(STH s) { //Perform statistical test andwhensee if I should delete this bundle } // This function is called toremove(certainly) delete the given STH // from the data store def delete_now(STH s) { this.sth_list.remove(s) } // When it isshared. This problem has been previously been considered intime to perform STH Pollination, thecaseHTTPS Client // calls this function to get a selection ofMix Networks and Remailers, including papers suchSTHs to send as[X], [Y], and [Z]. Certain common recommendations// feedback def get_pollination_selection() { if(len(this.sth_list) < MAX_STH_TO_GOSSIP) return this.sth_list else { indexes = set() modulus = len(this.sth_list) while(len(indexes) < MAX_STH_TO_GOSSIP) { r = randomInt() % modulus if(r not in indexes && now() - this.sth_list[i].timestamp < ONE_WEEK) indexes.insert(r) } return_selection = [] foreach(i in indexes) { return_selection.insert(this.sth_list[i]) } return return_selection } } } We also suggest a function that can bemade: o When choosing how many times to release data before expiring it from a cache, use a random number chosen from a distribution, rather thancalled periodically in the background, iterating through the STH store, performing afixed number.cleaning operation and queuing consistency proofs. Thisprevents an adversary from knowing with certainty thatfunction can live as a member functions of the STHStore class. def clean_list() { foreach(sth in this.sth_list) { if(now() - sth.timestamp > ONE_WEEK) { //STH is too old, we must remove ithasif(proof_fetching_enabled && auditor_of_last_resort_enabled && (sth.proof_failure_count / sth.proof_attempts) > MIN_PROOF_FAILURE_RATIO_CONSIDERED_SUSPICIOUS) { queue_sth_for_auditor_of_last_resort(sth) delete_maybe(sth) } else { delete_now(sth) } } else if(proof_fetching_enabled && now() - sth.timestamp > TWO_DAYS && now() - sth.timestamp > LOG_MMD) { sth.proof_attempts++ queue_consistency_proof(sth, consistency_proof_callback) } } } 11.3.3.2.2. STH Deletion Procedure The STH Deletion Procedure is run after successfullyflushedsubmitting acachelist of STHs to apotentially incriminating piece of data. o [TODO Enumeratingthird party during pollination. The following pseudocode would be included in theproblems of different typesSTHStore class, and called with the result ofmixes vs Cottrell Mix] o [TODO Integratingget_pollination_selection(), after theIP address intoSTHs have been (successfully) sent to the third party. // This function is called after successfully pollinating STHs // to a third party. It is passed the STHs sent to the third // party, which is the output of get_gossip_selection() def after_submit_to_thirdparty(STH[] sth_list) { foreach(sth in sth_list) { sth.num_reports_to_thirdparty++ if(proof_fetching_enabled) { if(now() - sth.timestamp > LOG_MMD) { sth.proof_attempts++ queue_consistency_proof(sth, consistency_proof_callback) } if(auditor_of_last_resort_enabled && sth.proof_failure_count > MIN_PROOF_ATTEMPTS_CONSIDERED_SUSPICIOUS && (sth.proof_failure_count / sth.proof_attempts) > MIN_PROOF_FAILURE_RATIO_CONSIDERED_SUSPICIOUS) { queue_sth_for_auditor_of_last_resort(sth) } } else { //proof fetching not enabled if(sth.num_reports_to_thirdparty > MIN_STH_REPORTS_TO_THIRDPARTY) { delete_maybe(sth) } } } } def consistency_proof_callback(consistency_proof, original_sth, error) { if(!error) { insert(consistency_proof.current_sth) delete_now(consistency_proof.original_sth) } else { original_sth.proof_failure_count++ } } 11.3.3.2.3. SCT Data Structures TBD TBD This section is not well abstracted to be used for both servers and clients. TKTK The SCT class contains data pertaining specifically to thealgorithm for releasing data] o [TODO Prefer aggregating multiple piece ofSCT itself. class SCT { uint32 proof_attempts uint32 proof_failure_count bool has_been_resolved_to_sth byte[] datainto a single STH when possible] o [TODO} TheimportanceSCT bundle will contain the trusted certificate chain the HTTPS client built (chaining to a trusted root certificate.) It also contains the list ofFlushing Attacks, and tying in network connection,associated SCTs, the exact domain it is applicable to, andtime interval] 10.2. Blocking Recommendations 10.2.1. Frustrating blocking When making gossip connectionsmetadata pertaining toHTTPS Servers or Trusted Auditors,how often itis desirablehas been reported tominimizetheplaintext metadatathird party. class SCTBundle { X509[] certificate_chain SCT[] sct_list string domain uint32 num_reports_to_thirdparty def equals(sct_bundle) { if(sct_bundle.domain != this.domain) return false if(sct_bundle.certificate_chain != this.certificate_chain) return false if(sct_bundle.sct_list != this.sct_list) return false return true } def approx_equals(sct_bundle) { if(sct_bundle.domain != this.domain) return false if(sct_bundle.certificate_chain != this.certificate_chain) return false return true } def insert_scts(sct[] sct_list) { this.sct_list.union(sct_list) this.num_reports_to_thirdparty = 0 } def has_been_fully_resolved_to_sths() { foreach(s in this.sct_list) { if(!s.has_been_resolved_to_sth) return false } return true } def max_proof_failure_count() { uint32 max = 0 foreach(s in this.sct_list) { if(s.proof_failure_count > max) max = proof_failure_count } return max } } We suppose a large data structure is used, such as a hashmap, indexed by theconnectiondomain name. For each domain, the structure will contain a data structure thatcan be used to identifyholds theconnectionSCTBundles seen for that domain, as well as encapsulating some logic relating to SCT Feedback for that particular domain. class SCTStore { string domain datetime last_contact_for_domain uint32 num_submissions_attempted uint32 num_submissions_succeeded SCTBundle[] observed_records // This function is called after recieving an SCTBundle. // For Clients, this is after agossipsuccessful connectionand therefore be of interesttoblock. Additionally, introducing some randomness into client behavior may be important - we assumea // HTTPS Server, calling this function with an SCTBundle // constructed from thatthe adversarycertificate chain and SCTs // For Servers, this isableafter receiving SCT Feedback def insert(SCTBundle b) { if(operator_is_server) { if(!passes_validity_checks(b)) return } foreach(e in this.observed_records) { if(e.equals(b)) return else if(e.approx_equals(b)) { e.insert_scts(b.sct_list) return } } this.observed_records.insert(b) } // When it is time toinspect the behavior ofperform SCT Feedback, the HTTPSclientClient // calls this function to get a selection of SCTBundles to send // as feedback def get_gossip_selection() { if(len(observed_records) > MAC_SCT_RECORDS_TO_GOSSIP) { indexes = set() modulus = len(observed_records) while(len(indexes) < MAX_SCT_RECORDS_TO_GOSSIP) { r = randomInt() % modulus if(r not in indexes) indexes.insert(r) } return_selection = [] foreach(i in indexes) { return_selection.insert(this.observed_records[i]) } return return_selection } else return this.observed_records } def delete_maybe(SCTBundle b) { //Perform statistical test andunderstand how it makes gossip connections. As an example,see if I should delete this bundle } def delete_now(SCTBundle b) { this.observed_records.remove(b) } def passes_validity_checks(SCTBundle b) { // This function performs the validity checks specified in // {{feedback-srvop}} } } We also suggest aclient, after establishing a TLS connection (and receiving an SCT, but not making it's own HTTPS request yet), immediately opens a second TLS connection forfunction that can be called periodically in thepurpose of gossipbackground, iterating through all SCTStore objects in the large hashmap (here called 'all_sct_stores') and removing old data. def clear_old_data() { foreach(storeEntry in all_sct_stores) { if(storeEntry.num_submissions_succeeded == 0 && storeEntry.num_submissions_attempted > MIN_SCT_ATTEMPTS_FOR_DOMAIN_TO_BE_IGNORED) { all_sct_stores.remove(storeEntry) } else if(storeEntry.num_submissions_succeeded > 0 && now() - storeEntry.last_contact_for_domain > TIME_UNTIL_OLD_SCTDATA_ERASED) { all_sct_stores.remove(storeEntry) } } } 11.3.3.2.4. SCT Deletion Procedure The SCT Deletion procedure is more complicated than theadversary can reliably block this second connectionrespective STH procedure. This is because servers may elect not toblock gossip without affecting normal browsing. Forparticipate in SCT Feedback, and thisreason it is recommendedmust be accounted for by being more conservative in sending SCT reports torunthem. The following pseudocode would be included in thegossip protocols over an existing connection toSCTStore class, and called with theserver, making useresult ofconnection multiplexing such as HTTP Keep-Alives or SPDY. Truncation isget_gossip_selection() after the SCT Feedback has been sent (successfully) to the server. We alsoa concern -if a client always establishes a TLS connection, makes a request, receives a response, and then always attempts a gossip communication immediately followingnote that the firstresponse - truncation will allowexperimental algorithm from above is included in the pseudocode as anattacker to block gossip reliably. 10.2.2. Respondingillustration. // This function is called after successfully providing SCT Feedback // topossible blocking [Not sure here. Maybe this section will get folded up intoa server. It is passed theabove. Or maybe it relatesfeedback sent to theescape valve. -tjr] 11.server, which // is the output of get_gossip_selection() def after_submit_to_thirdparty(SCTBundle[] submittedBundles) { foreach(bundle in submittedBundles) { bundle.num_reports_to_thirdparty++ if(proof_fetching_enabled) { if(!bundle.has_been_fully_resolved_to_sths()) { foreach(s in bundle.sct_list) { if(!s.has_been_resolved_to_sth) { s.proof_attempts++ queue_inclusion_proof(sct, inclusion_proof_callback) } } } else { if(run_ct_gossip_experiment_one) { if(bundle.num_reports_to_thirdparty > MIN_SCT_REPORTS_TO_THIRDPARTY && bundle.num_reports_to_thirdparty * 1.5 > bundle.max_proof_failure_count()) { maybe_delete(bundle) } } else { //Do not run experiment if(bundle.num_reports_to_thirdparty > MIN_SCT_REPORTS_TO_THIRDPARTY) { maybe_delete(bundle) } } } } else {//proof fetching not enabled if(bundle.num_reports_to_thirdparty > (MIN_SCT_REPORTS_TO_THIRDPARTY * NO_PROOF_FETCHING_REPORT_INCREASE_FACTOR)) { maybe_delete(bundle) } } } } // This function is a callback invoked after an inclusion proof // has been retrieved def inclusion_proof_callback(inclusion_proof, original_sct, error) { if(!error) { original_sct.has_been_resolved_to_sth = True insert_to_sth_datastore(inclusion_proof.new_sth) } else { original_sct.proof_failure_count++ } } 12. IANA considerations[TBD] 12.[ TBD ] 13. Contributors The authors would like to thank the following contributors for valuable suggestions: Al Cutter, Ben Laurie, Benjamin Kaduk, Josef Gustafsson, Karen Seo, Magnus Ahltorp, Steven Kent, Yan Zhu.13.14. ChangeLog13.1.14.1. Changes between ietf-01 and ietf-02 o Requiring full certificate chain in SCT Feedback. o Clarifications on what clients store for and send in SCT Feedback added. o SCT Feedback server operation updated to protect against DoS attacks on servers. o Pre-Loaded vs Locally Added Anchors explained. o Base for well-known URL's changed. o Remove all mentions of monitors - gossip deals with adutitors. o New sections added: Trusted Auditor protocol, attacks by actively malicious log, the Dual-CA compromise attack, policy recommendations, 14.2. Changes between ietf-00 and ietf-01 o Improve langugage and readability based on feedback from Stephen Kent. o STH Pollination Proof Fetching defined and indicated as optional. o 3-Method Ecosystem section added. o Cases with Logs ceasing operation handled. o Text on tracking via STH Interaction added. o Section with some early recommendations for mixing added. o Section detailing blocking connections, frustrating it, and the implications added.13.2.14.3. Changes between -01 and -02 o STH Pollination defined. o Trusted Auditor Relationship defined. o Overview section rewritten. o Data flow picture added. o Section on privacy considerations expanded.13.3.14.4. Changes between -00 and -01 o Add the SCT feedback mechanism: Clients send SCTs to originating web server which shares them with auditors. o Stop assuming that clients see STHs. o Don't use HTTP headers but instead .well-known URL's - avoid that battle. o Stop referring to trans-gossip and trans-gossip-transport-https - too complicated. o Remove all protocols but HTTPS in order to simplify - let's come back and add more later. o Add more reasoning about privacy. o Do specify data formats.14.15. References 15.1. Normative References[RFC-6962-BIS][RFC-6962-BIS-09] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency", October 2015, <https://datatracker.ietf.org/doc/draft-ietf-trans- rfc6962-bis/>. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014. 15.2. Informative References [draft-ietf-trans-threat-analysis-03] Kent, S., "Attack Model and Threat for Certificate Transparency", October 2015, <https://datatracker.ietf.org/doc/draft-ietf-trans-threat- analysis/>. Authors' Addresses Linus Nordberg NORDUnet Email: linus@nordu.net Daniel Kahn Gillmor ACLU Email: dkg@fifthhorseman.net Tom Ritter Email: tom@ritter.vg