idnits 2.17.1 draft-iab-privsec-confidentiality-mitigations-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7624]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 228 has weird spacing: '...ization strat...' -- The document date (March 20, 2016) is 2931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'STRINT' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'WaPo-STARTTLS' is defined on line 525, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-edns-client-subnet-06 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5750 (Obsoleted by RFC 8550) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IAB T. Hardie, Ed. 3 Internet-Draft March 20, 2016 4 Intended status: Informational 5 Expires: September 19, 2016 7 Confidentiality in the Face of Pervasive Surveillance 8 draft-iab-privsec-confidentiality-mitigations-06 10 Abstract 12 The IAB has published [RFC7624] in response to several revelations of 13 pervasive attack on Internet communications. In this document we 14 survey the mitigations to those threats which are currently available 15 or which might plausibly be deployed. We discuss these primarily in 16 the context of Internet protocol design, focusing on robustness to 17 pervasive monitoring and avoidance of unwanted cross-mitigation 18 impacts. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 19, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Available Mitigations . . . . . . . . . . . . . . . . . . . . 3 56 4. Interplay among Mitigations . . . . . . . . . . . . . . . . . 8 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 7. Contributors {Contributors} . . . . . . . . . . . . . . . . . 9 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 1. Introduction 67 To ensure that the Internet can be trusted by users, it is necessary 68 for the Internet technical community to address the vulnerabilities 69 exploited in the attacks document in [RFC7258] and the threats 70 described in [RFC7624]. The goal of this document is to describe 71 more precisely the mitigations available for those threats and to lay 72 out the interactions among them should they be deployed in 73 combination. 75 2. Terminology 77 This document makes extensive use of standard security and privacy 78 terminology; see [RFC4949] and [RFC6973]. Terms used from [RFC6973] 79 include Eavesdropper, Observer, Initiator, Intermediary, Recipient, 80 Attack (in a privacy context), Correlation, Fingerprint, Traffic 81 Analysis, and Identifiability (and related terms). In addition, we 82 use a few terms that are specific to the attacks discussed in this 83 document. Note especially that "passive" and "active" below do not 84 refer to the effort used to mount the attack; a "passive attack" is 85 any attack that accesses a flow but does not modify it, while an 86 "active attack" is any attack that modifies a flow. Some passive 87 attacks involve active interception and modifications of devices, 88 rather than simple access to the medium. The introduced terms are: 90 Pervasive Attack: An attack on Internet communications that makes use 91 of access at a large number of points in the network, or otherwise 92 provides the attacker with access to a large amount of Internet 93 traffic; see [RFC7258]. 95 Passive Pervasive Attack: An eavesdropping attack undertaken by a 96 pervasive attacker, in which the packets in a traffic stream 97 between two endpoints are intercepted, but in which the attacker 98 does not modify the packets in the traffic stream between two 99 endpoints, modify the treatment of packets in the traffic stream 100 (e.g. delay, routing), or add or remove packets in the traffic 101 stream. Passive pervasive attacks are undetectable from the 102 endpoints. Equivalent to passive wiretapping as defined in 103 [RFC4949]; we use an alternate term here since the methods 104 employed are wider than those implied by the word "wiretapping", 105 including the active compromise of intermediate systems. 107 Active Pervasive Attack: An attack undertaken by a pervasive 108 attacker, which in addition to the elements of a passive pervasive 109 attack, also includes modification, addition, or removal of 110 packets in a traffic stream, or modification of treatment of 111 packets in the traffic stream. Active pervasive attacks provide 112 more capabilities to the attacker at the risk of possible 113 detection at the endpoints. Equivalent to active wiretapping as 114 defined in [RFC4949]. 116 Observation: Information collected directly from communications by an 117 eavesdropper or observer. For example, the knowledge that 118 sent a message to via SMTP 119 taken from the headers of an observed SMTP message would be an 120 observation. 122 Inference: Information derived from analysis of information collected 123 directly from communications by an eavesdropper or observer. For 124 example, the knowledge that a given web page was accessed by a 125 given IP address, by comparing the size in octets of measured 126 network flow records to fingerprints derived from known sizes of 127 linked resources on the web servers involved, would be an 128 inference. 130 Collaborator: An entity that is a legitimate participant in a 131 communication, and provides information about that communication 132 to an attacker. Collaborators may either deliberately or 133 unwittingly cooperate with the attacker, in the latter case 134 because the attacker has subverted the collaborator through 135 technical, social, or other means. 137 Key Exfiltration: The transmission of cryptographic keying material 138 for an encrypted communication from a collaborator, deliberately 139 or unwittingly, to an attacker. 141 Content Exfiltration: The transmission of the content of a 142 communication from a collaborator, deliberately or unwittingly, to 143 an attacker. 145 Data Minimization: With respect to protocol design, refers to the 146 practice of only exposing the minimum amount of data or metadata 147 necessary for the task supported by that protocol to the other 148 endpoint(s) and/or devices along the path. 150 3. Available Mitigations 151 Given the threat model laid out in [RFC7624], how should the Internet 152 technical community respond to pervasive attack? The cost and risk 153 considerations discussed in it provide a guide to responses. Namely, 154 responses to passive attack should close off avenues for those 155 attacks that are safe, scalable, and cheap, forcing the attacker to 156 mount attacks that expose it to higher cost and risk. Protocols and 157 security measures protecting against active attacks must also limit 158 the impact of compromise and malfeasance by avoiding systems which 159 grant universal credentials. 161 In this section, we discuss a collection of high-level approaches to 162 mitigating pervasive attacks. These approaches are not meant to be 163 exhaustive, but rather to provide general guidance to protocol 164 designers in creating protocols that are resistant to pervasive 165 attack. 167 Many of these are basic tools which already exist. As Edward Snowden 168 put it, "properly implemented strong crypto systems are one of the 169 few things you can rely on". The task for the Internet community is 170 to ensure that applications are able to use the strong crypto and 171 other mitigations already available- and that these are properly 172 implemented and commonly turned on. Some of this work will require 173 architectural changes to applications, e. g., in order to limit the 174 information that is exposed to servers. In many other cases, 175 however, the need is simply to make the best use we can of the 176 cryptographic tools we have. 178 +--------------------------+----------------------------------------+ 179 | Attack Class | High-level mitigations | 180 +--------------------------+----------------------------------------+ 181 | Passive observation | Encryption for confidentiality | 182 | | | 183 | Passive inference | Path differentiation | 184 | | | 185 | Active | Authentication, monitoring | 186 | | | 187 | Metadata Analysis | Data Minimization | 188 | | | 189 | Static key exfiltration | Encryption with per-session state | 190 | | (PFS) | 191 | | | 192 | Dynamic key exfiltration | Transparency, validation of end | 193 | | systems | 194 | | | 195 | Content exfiltration | Object encryption, distributed systems | 196 +--------------------------+----------------------------------------+ 197 The traditional mitigation to passive attack is to render content 198 unintelligible to the attacker by applying encryption, for example, 199 by using TLS or IPsec [RFC5246][RFC4301]. Even without 200 authentication, encryption will prevent a passive attacker from being 201 able to read the encrypted content. Exploiting unauthenticated 202 encryption requires an active attack (man in the middle); with 203 authentication, a key exfiltration attack is required. For 204 cryptographic systems providing forward secrecy, even exfiltration of 205 long-term keys will not compromise data captured under session keys 206 used before the exfiltration. 208 The additional capabilities of a pervasive passive attacker, however, 209 require some changes in how protocol designers evaluate what 210 information is encrypted. In addition to directly collecting 211 unencrypted data, a pervasive passive attacker can also make 212 inferences about the content of encrypted messages based on what is 213 observable. For example, if a user typically visits a particular set 214 of web sites, then a pervasive passive attacker observing all of the 215 user's behavior can track the user based on the hosts the user 216 communicates with, even if the user changes IP addresses, and even if 217 all of the connections are encrypted. 219 Thus, in designing protocols to be resistant to pervasive passive 220 attacks, protocol designers should consider what information is left 221 unencrypted in the protocol, and how that information might be 222 correlated with other traffic. Some of the data left unencrypted may 223 be considered "metadata" within the context of a single protocol, as 224 it provides adjunct information used for delivery or display, rather 225 than the data directly created or consumed by protocol users. This 226 does not mean it is not useful to attackers, however, and when this 227 metadata is not protected by encryption it may leak substantial 228 amounts of information. Data minimization strategies should thus be 229 applied to any data left unencrypted, whether it be payload or 230 metadata. Information that cannot be encrypted or omited should be 231 be dissociated from other information. For example, the TOR[TOR] 232 overlay routing network anonymizes IP addresses by using multi-hop 233 onion routing. 235 As with traditional, limited active attacks, a basic mitigation to 236 pervasive active attack is to enable the endpoints of a communication 237 to authenticate each other over the encrypted channel. However, 238 attackers that can mount pervasive active attacks can often subvert 239 the authorities on which authentication systems rely. Thus, in order 240 to make authentication systems more resilient to pervasive attack, it 241 is beneficial to monitor these authorities to detect misbehavior that 242 could enable active attack. For example, DANE and Certificate 243 Transparency both provide mechanisms for detecting when a CA has 244 issued a certificate for a domain name without the authorization of 245 the holder of that domain name [RFC6962][RFC6698]. Other systems may 246 use external notaries to detect certificate authority mismatch (e.g. 247 Convergence [Convergence]). 249 While encryption and authentication protect the security of 250 individual sessions, these sessions may still leak information, such 251 as IP addresses or server names, that a pervasive attacker can use to 252 correlate sessions and derive additional information about the 253 target. Thus, pervasive attack highlights the need for anonymization 254 technologies, which make correlation more difficult. Typical 255 approaches to anonymization against traffic analysis include: 257 o Aggregation: Routing sessions for many endpoints through a common 258 mid-point (e.g, an HTTP proxy). The midpoint appears as the 259 origin of the communication when traffic analysis is conducted 260 from points after it, so individual sources cannot be 261 distinguished. If traffic analysis is being conducted prior to 262 the mid-point, all flows appear to be destined to the same point, 263 which leaks very little information. Even when traffic analysis 264 is being performed both before and after the mid-point, 265 simultaneous connections may make it difficult to corelate the 266 traffic going into and out of the mid-point. For this to be 267 effective as a mitigation, traffic to the mid-point must be 268 encrypted and traffic from the mid-point should be. 270 o Onion routing: Routing a session through several mid-points, 271 rather than directly end-to-end, with encryption that guarantees 272 that each node can only see the previous and next hops. This 273 ensures that the source and destination of a communication are 274 never revealed simultaneously. Note, however, that onion routing 275 anonymity guarantees depend on an attacker being unable to control 276 many of the routing nodes [TorPaper]. 278 o Multi-path: Routing different sessions via different paths (even 279 if they originate from the same endpoint). This reduces the 280 probability that the same attacker will be able to collect many 281 sessions or associate them with the same individual. If, for 282 example, a device has both a cellular and 802.11 interface, 283 routing some traffic across the cellular network and other traffic 284 over the 802.11 interface means that traffic analysis conducted 285 only with one network will be incomplete. Even if conducted in 286 both, it may be more difficult for the attacker to associate the 287 traffic in each network with the other. For this to be effective 288 as a mitigation, signalling protocols which gather and transmit 289 data about multiple interfaces (such as SIP) must be encrypted to 290 avoid the information being used in cross-corelation. 292 An encrypted, authenticated session is safe from content-monitoring 293 attacks in which neither end collaborates with the attacker, but can 294 still be subverted by the endpoints. The most common ciphersuites 295 used for HTTPS today, for example, are based on using RSA encryption 296 in such a way that if an attacker has the private key, the attacker 297 can derive the session keys from passive observation of a session. 298 These ciphersuites are thus vulnerable to a static key exfiltration 299 attack - if the attacker obtains the server's private key once, then 300 they can decrypt all past and future sessions for that server. 302 Static key exfiltration attacks are prevented by including ephemeral, 303 per-session secret information in the keys used for a session. Most 304 IETF security protocols include modes of operation that have this 305 property. These modes are known in the literature under the heading 306 "perfect forward secrecy" (PFS) because even if an adversary has all 307 of the secrets for one session, the next session will use new, 308 different secrets and the attacker will not be able to decrypt it. 309 The Internet Key Exchange (IKE) protocol used by IPsec supports PFS 310 by default [RFC4306], and TLS supports PFS via the use of specific 311 ciphersuites [RFC5246]. 313 Dynamic key exfiltration cannot be prevented by protocol means. By 314 definition, any secrets that are used in the protocol will be 315 transmitted to the attacker and used to decrypt what the protocol 316 encrypts. Likewise, no technical means will stop a willing 317 collaborator from sharing keys with an attacker. However, this 318 attack model also covers "unwitting collaborators", whose technical 319 resources are collaborating with the attacker without their owners' 320 knowledge. This could happen, for example, if flaws are built into 321 products or if malware is injected later on. 323 Standards can also define protocols that provide greater or lesser 324 opportunity for dynamic key exfiltration. Collaborators engaging in 325 key exfiltration through a standard protocol will need to use covert 326 channels in the protocol to leak information that can be used by the 327 attacker to recover the key. Such use of covert channels has been 328 demonstrated for SSL, TLS, and SSH. Any protocol bits that can be 329 freely set by the collaborator can be used as a covert channel, 330 including, for example, TCP options or unencrypted traffic sent 331 before a STARTTLS message in SMTP or XMPP. Protocol designers should 332 consider what covert channels their protocols expose, and how those 333 channels can be exploited to exfiltrate key information. 335 Content exfiltration has some similarity to the dynamic exfiltration 336 case, in that nothing can prevent a collaborator from revealing what 337 they know, and the mitigations against becoming an unwitting 338 collaborator apply. In this case, however, applications can limit 339 what the collaborator is able to reveal. For example, the S/MIME and 340 PGP systems for secure email both deny intermediate servers access to 341 certain parts of the message [RFC5750][RFC2015]. Even if a server 342 were to provide an attacker with full access, the attacker would 343 still not be able to read the protected parts of the message. 345 Mechanisms like S/MIME and PGP are often referred to as "end-to- 346 end"security mechanisms, as opposed to "hop-by-hop" or "end-to- 347 middle" mechanisms like the use of SMTP over TLS. These two 348 different mechanisms address different types of attackers: Hop-by-hop 349 mechanisms protect from attackers on the wire (passive or active), 350 while end-to-end mechansims protect against attackers within 351 intermediate nodes as well as those on the wire. Even end-to-end 352 mechanisms are not complete protection in themselves, as intermediate 353 nodes can still access some metadata. For example: 355 o Two users messaging via Facebook over HTTPS are protected against 356 passive and active attackers in the network between the users and 357 Facebook. However, if Facebook is a collaborator in an 358 exfiltration attack, their communications can still be monitored. 359 They would need to encrypt their messages end-to-end in order to 360 protect themselves against this risk. 362 o Two users exchanging PGP-protected email have protected the 363 content of their exchange from network attackers and intermediate 364 servers, but the header information (e. g., To and From 365 addresses) is unnecessarily exposed to passive and active 366 attackers that can see communications among the mail agents 367 handling the email messages. These mail agents need to use hop- 368 by-hop encryption and traffic analysis mitigation to address this 369 risk. 371 Mechanisms such as S/MIME and PGP are also known as "object-based" 372 security mechanisms (as opposed to "communications security" 373 mechanisms), since they operate at the level of objects, rather than 374 communications sessions. Such secure object can be safely handled by 375 intermediaries in order to realize, for example, store and forward 376 messaging. In the examples above, the encrypted instant messages or 377 email messages would be the secure objects. Hop-to-hop security 378 mechanisms may be susceptible to downgrade attacks (e.g., STARTTLS- 379 secured SMTP has been downgraded by intermediate network nodes [WaPo- 380 STARTTLS]) in which case end-to-end mechanisms are advised. 382 The mitigations to the content exfiltration case regard participants 383 in the protocol as potential passive attackers themselves, and apply 384 the mitigations discussed above with regard to passive attack. 385 Information that is not necessary for these participants to fulfill 386 their role in the protocol can be encrypted, and other information 387 can be anonymized. 389 The tools that we currently have have not generally been designed 390 with mitigation in mind, so they may need elaboration or adjustment 391 to be completely suitable. The next section examines one common 392 reason for such adjustment: managing the integration of one 393 mitigation with the environment in which it is deployed. 395 4. Interplay among Mitigations 396 One of the key considerations in selecting mitigations is how to 397 manage the interplay among different mechanisms. Care must be taken 398 to avoid situations where a mitigation is rendered fruitless because 399 of a different mitigation which is working at a different time scale 400 or with a different aim. 402 As an example, there is work in progress in IEEE 802 to standardize 403 a method for the randomization of MAC Addresses. This work aims to 404 enable a mitigation in which the MAC address varies as the device 405 connects to different networks, or connects at different times. In 406 theory, the randomization will mitigate tracking by MAC address. 407 However, the randomization will be defeated if the adversary can link 408 the randomized MAC address to other identifiers such as the interface 409 identifier used in IPv6 addresses, the unique identifiers used in 410 DHCP or DHCPv6, or unique identifiers used in various link-local 411 discovery protocols. 413 For mitigations which rely on aggregation to separate the origin of 414 traffic from its destination, care must be taken that the protocol 415 mechanics do not expose origin IP through secondary means. [I-D 416 .ietf-dnsop-edns-client-subnet] for example, documents a method to 417 carry the IP address or subnet of a querying party through a 418 recursive resolver to an authoritative resolver. Even with a 419 truncated IP address, this mechanism increases the likelihood that a 420 pervasive monitor would be able to associate query traffic and 421 responses. If a client wished to ensure that its traffic did not 422 expose this data, it would need to require that its stub resolver 423 emit any privacy-sensitive queries with a source NETMASK set to 0, as 424 detailed in Section 5.1 of [I-D.ietf-dnsop-edns-client-subnet]. 425 Given that setting this only occasionally might also be used a signal 426 to observors, any client wishing to have any privacy sensitive 427 traffic would, in essence have to emit this for every query. While 428 this would succeed at providing the required privacy, given the 429 mechanism proposed, it would also mean no split-DNS adjustments in 430 response would be possible for the privacy sensitive client. 432 5. IANA Considerations 434 This memo makes no request of IANA. 436 6. Security Considerations 438 This memorandum describes a series of mitigations to the attacks 439 described in [RFC7258]. No such list could possibly be 440 comprehensive, nor is the attack therein described the only possible 441 attack. 443 7. Contributors {Contributors} 444 This document is derived in part from the work initially done on the 445 Perpass mailing list and at the STRINT workshop. Work from Brian 446 Trammell, Bruce Schneier, Christian Huitema, Cullen Jennings, Daniel 447 Borkmann, and Richard Barnes is incorporated here, as are ideas and 448 commentary from Jeff Hodges, Phillip Hallam-Baker, and Stephen 449 Farrell. 451 8. References 453 8.1. Normative References 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 459 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . 462 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 463 Morris, J., Hansen, M. and R. Smith, "Privacy 464 Considerations for Internet Protocols", RFC 6973, DOI 465 10.17487/RFC6973, July 2013, . 468 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 469 Attack", BCP 188, RFC 7258, May 2014. 471 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 472 Trammell, B., Huitema, C. and D. Borkmann, 473 "Confidentiality in the Face of Pervasive Surveillance: A 474 Threat Model and Problem Statement", RFC 7624, DOI 475 10.17487/RFC7624, August 2015, . 478 8.2. Informative References 480 [Convergence] 481 M Marlinspike, ., "Convergence Project", August 2011, 482 . 484 [I-D.ietf-dnsop-edns-client-subnet] 485 Contavalli, C., Gaast, W., tale, t. and W. Kumari, 486 "Client Subnet in DNS Queries", Internet-Draft draft-ietf- 487 dnsop-edns-client-subnet-06, December 2015. 489 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy 490 (PGP)", RFC 2015, October 1996. 492 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 493 Internet Protocol", RFC 4301, December 2005. 495 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 496 4306, December 2005. 498 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 499 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 501 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 502 Mail Extensions (S/MIME) Version 3.2 Certificate 503 Handling", RFC 5750, January 2010. 505 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 506 of Named Entities (DANE) Transport Layer Security (TLS) 507 Protocol: TLSA", RFC 6698, August 2012. 509 [RFC6962] Laurie, B., Langley, A. and E. Kasper, "Certificate 510 Transparency", RFC 6962, June 2013. 512 [STRINT] S Farrell, ., "Strint Workshop Report", April 2014, 513 . 516 [TOR] The Tor Project, "Tor", 2013, . 519 [TorPaper] 520 Dingledine, R., Mathewson, N. and P. Syverson, "Tor: The 521 Second-Generation Onion Router", 2004, . 525 [WaPo-STARTTLS] 526 Scola, N. and A. Soltani, "Mobile ISP Cricket was 527 thwarting encrypted emails, researchers find", 2014, 528 . 532 Author's Address 534 Ted Hardie, editor 536 Email: ted.ietf@gmail.com