idnits 2.17.1 draft-crocker-strint-workshop-messaging-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 16, 2014) is 3752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TLS' is defined on line 403, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Informational P. Resnick 5 Expires: July 20, 2014 Qualcomm Technologies, Inc. 6 January 16, 2014 8 STRINT Workshop Position Paper: Levels of Opportunistic Privacy 9 Protection for Messaging-Oriented Architectures 10 draft-crocker-strint-workshop-messaging-00 12 Abstract 14 Given a concern for pervasive monitoring, messaging information 15 needing protection includes primary payload, descriptive meta-data, 16 and traffic-related analysis. Complete protection against pervasive 17 monitoring (PM), for traffic through complex handling sequences, has 18 not yet been achieved reliably in real-world operation. 19 Consequently, it is reasonable to consider a range of mechanisms, for 20 protecting differing amounts of information and against monitoring of 21 different kinds. Although channel-based encryption can be helpful, 22 it is not sufficient. This paper considers pursuing different levels 23 of end-to-end protection, referencing examples of component 24 mechanisms that already have encouraging field experience. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 20, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 1. Background 60 Concern for pervasive monitoring motivates the deployment of strong 61 mechanisms that will protect against intrusive disclosure of 62 information. Information needing protection can be primary payload, 63 descriptive meta-data, or traffic-related analysis. Most Internet 64 services operate according to a relatively simple, two-party client/ 65 server model, with the server holding primary data and performing 66 primary actions, and the user having a direct relationship with the 67 service being provided. For these arrangements, concerns over 68 privacy violations tend to focus on wiretapping of the data transfer 69 mechanism and on server compromise. 71 In contrast messaging architectures, such as for email [MAILARCH], 72 can be highly distributed, with any number of application-level 73 store-and-forward intermediaries. This can produce complex sequences 74 through many independent administrative authorities, possibly unknown 75 to either the user or the recipient. Because multi-hop store-and- 76 forward messaging can involve several systems not under the 77 administrative control of either end of the messaging transaction, 78 compromise of any of the intermediate systems can expose messages to 79 monitoring past the first, or before the last, hop. Therefore end- 80 to-end encryption is still highly desirable. Key distribution and 81 validation is one of the greatest impediments to deployment. 83 Current multi-hop store-and-forward messaging on the Internet uses 84 primarily two security technologies: 86 1. Channel encryption between the submitter and its submission 87 server and final recipient and its receiving server, 88 respectively, that encryption generally relying on CAs for 89 authentication; and 91 2. End-to-end content encryption that relies on pre-authenticated 92 certificates available to the end-points. 94 The former is used, but does not provide sufficient protection 95 against certain kinds of pervasive monitoring, and the latter is 96 rarely used because of deployment and use barriers. More 97 opportunistic mechanisms might have a higher likelihood of 98 deployment, with minimal effect on services, and therefore should be 99 attempted. Further if these opportunistic mechanisms do gain 100 success, they can be used for further minimization of some forms of 101 abuse. 103 Complete protection against pervasive monitoring (PM), for traffic 104 through complex handling sequences, has not yet been achieved 105 reliably in real-world operation. Consequently, it is reasonable to 106 consider a range of mechanisms, for protecting differing amounts of 107 information and against monitoring of different kinds. The premises 108 are that one or more of these might prove more effective than others 109 and that some protection is better than none. 111 Given the scale and urgency of community need for this protection, 112 mechanisms should be based on established technologies, where 113 possible. While innovation is needed, it should be kept as modest as 114 possible. So the major challenge should be system design, rather 115 than component invention, where possible and practical. 117 There are four types of data to be considered for protection in a 118 distributed messaging architecture: 120 o Message Content 122 o Header Content 124 o Envelope meta-data 126 o Handling meta-data 128 Message content is considered the primary payload; for email this is 129 the body of the message. However messaging often contains additional 130 content in a header, such as the names and addresses of authors and 131 recipient, content summary, such as a Subject field, date of posting, 132 and so on. Envelope meta-data is the information used by the transit 133 service, including recipient and return addresses. Handling 134 information is created during transit, such as for recording 135 processing tags by intermediaries. The placement of these bits of 136 information can vary, so that distinguishing among them can sometimes 137 be confusing. As an example email relay handling meta-data is placed 138 into the message header. 140 Almost all efforts to protect messages have focused on the primary 141 message content, with two well-known capabilities being standardized. 142 [OPENPGP][SMIME] However after twenty-five years of these efforts to 143 protect messages that are in transit, nearly all such traffic is 144 still sent in the clear. 146 In the absence of a success scenario for end-to-end payload privacy 147 protection, it is not possible to be certain which barriers are 148 critical, nor how to overcome them. In current discussions, the 149 primary culprits are believed to be key administration and end user 150 interface design and performance complexity. Both are deemed to 151 require too much human effort, and a common view is to essentially 152 remove humans from needing to configure their services or choose to 153 use them. 155 Channel encryption is low-hanging fruit when it comes to messaging 156 security, though it only offers minimal protections against pervasive 157 monitoring in its current use. Right now, messaging-related channel 158 encryption is almost exclusively used between end clients and their 159 directly-associated servers, mostly for purposes of protecting the 160 login credentials from monitoring. It does result in clear message 161 contents also being protected from snooping on the channel between 162 the end client and server, and it protects envelope information 163 (which is not otherwise protected by end-to-end content encryption.) 164 However this protection only operates for the first and last message 165 hops and leaves intermediate hops unprotected. So the addition of 166 channel security at every hop is still desirable. Authentication can 167 be recorded in the envelope if it takes place, presumably in a way 168 that allows the recipient to confirm that the authentication took 169 place, but authentication is not necessary for a large increase in 170 security. For intermediate hops opportunistic encryption would be a 171 significant improvement and would be deemed sufficient for most 172 cases. The intermediate servers can simply do key exchange in-band. 174 2. Incremental End-to-End Protection 176 Channel encryption can not protect against some of the PM activities 177 that have been documented. So the more challenging concern is 178 protection against collaborating or compromised intermediate nodes 179 and even source and destination servers. Ideally protection 180 therefore must be end-to-end, defined in terms of the author's and 181 recipient's independent user agents. The difficulty of achieving 182 this is exacerbated by the degree of existing Internet messaging 183 activity that has all user agent behavior on, or controlled by, end- 184 system web servers, rather than by independent software that is 185 solely under the control of the author or recipient. Hence the best 186 end-to-end protection that will be achievable for many users is 187 between originating server and receiving server. 189 This highlights the need for incremental mechanisms that provide 190 increasing protection. Greater user independence should be able to 191 permit greater user protection. Another benefit of this incremental 192 approach is that it is likely to provide some useful protection while 193 still permitting exposure information necessary to legitimate 194 management. Of course, balancing between protecting against 195 problematic monitoring and facilitating legitimate monitoring 196 (management) requires agreement on the trade-offs and explicit 197 choices amongst them. The discussion and agreement remain an open 198 and challenging task. 200 An observation about focusing on PM protection is that use of 201 encryption for that purpose does not necessarily carry the usual, 202 accompanying requirement for strong authentication of one or both 203 principals in the interaction. In the extreme, this might mean that 204 typical man-in-the-middle scenarios are not a concern, but it also 205 can mean that authentication related to an agent -- rather than to 206 the user -- is sufficient. 208 This well might permit opportunistic privacy protection without 209 direct user involvement, possibly with unauthenticated encryption and 210 no human configuration, and for authentication to take place as a 211 separate piece of user interface when that is desirable. To the 212 extent that human involvement is needed for the basic setup, it might 213 be limited to service administrators, rather than end users. The 214 obvious appeal of this is that there are orders of magnitude fewer 215 administrators than there are users, and administrators typically 216 have far more technical skill. 218 Key discovery is the most significant challenge during operation of a 219 protection mechanism. A promising approach that already has some 220 field experience achieves key distribution through the [DNS]. The 221 core requirement, of course, is determining what domain name to 222 query. The most obvious choice in a messaging service is the domain 223 name of the recipient's address. Enhancing this to permit DNS 224 queries on an entire email address would be the refinement to 225 attempt. 227 A DNS-based mechanism would facilitate query, but would not deal with 228 key administration. Although there is activity in this space, easy 229 key generation remain an open issue for the Internet. However note 230 that by making the critical actors for this service be operators, the 231 scale of this challenge is dramatically smaller than if end users 232 need to be involved. 234 Given a basic key-discovery ability, the question then is what to 235 encrypt? Simply encrypting a message body is appealing, but leaves 236 exposed all of the message header, as well as associated handling and 237 envelope information. This is where the "levels" reference in the 238 paper's title comes in. Additional mechanisms or services can 239 protect increasing amounts of message-related information. However, 240 a pragmatic basis for choosing different levels is likely to prove 241 challenging, since users cannot be relied on to make such decision. 242 Still it will be worth pursuing an activity to describe the choices. 243 Essentially, they are: 245 o Content 247 o Content + Header 249 o Content + Header + Envelope 251 For email, one challenge in encrypting the message header is that the 252 header is modified in transit. A plausible approach is to 253 encapsulate the original message as a [MIME] attachment, so that the 254 visible message header is only a form of envelope. 256 In order to obscure the origin/receiver envelope information, the 257 message in transit needs to use different envelope data. Given that 258 the information is essential to message transit, this will require an 259 overlay relay service, designed to hide actual author/recipient 260 information. It is worth considering enhancements, to integrate it 261 more seamlessly for well-motivated users. 263 3. Exemplars to Demonstrate Feasibility 265 Although it is easy to offer appealing design ideas, estimating their 266 real-world feasibility and utility can be challenging. This paper is 267 not intended to formulate detailed solutions, but it does need to 268 provide some basis for comfort with the basic approaches it suggests. 269 The discussion in this section is therefore intended to provide some 270 substance, to that end. 272 Rather than consider whether a detail discussed in this section is 273 good or bad, or whether one approach is better or worse than another, 274 the reader is encouraged merely to review the examples in terms of 275 existing deployment experience and the likely pragmatics of 276 incremental engineering and operations that is described. While it 277 is likely that superior designs can be specified, the requirement now 278 is to develop a reasonable degree of comfort that the basic 279 approaches are plausible. 281 3.1. Administrators vs. Users 283 There is considerable field experience with the difference between 284 the administrative skills of professional operators, versus end- 285 users. With respect to key administration, specific examples include 286 [DNSSEC] and [DKIM]. The experience shows that key administration 287 tends to be daunting even for professionals, but is infeasible for 288 most end users. 290 A related point is the greater deployment and use success that is 291 likely when providing protection between servers rather than between 292 end-users. An exemplar of this approach being successful for a 293 security mechanism is [DKIM] as compared against the problematic 294 deployment histories of [OPENPGP] and [SMIME]. However the obvious 295 concern is that the end-users must rely on the safety of their server 296 operations. 298 3.2. Key Discovery 300 Key discovery through the DNS already has several examples, including 301 [DNSSEC], [DANE] and [DKIM]. In the aggregate they demonstrate that 302 this basic approach is operationally reasonable. 304 3.3. Per-User Keys 306 The history of per-user key administration is particularly 307 disheartening. To the extent that key discovery via domain names has 308 established a strong proof of concept, it is appealing to consider 309 extending it to the granularity of complete email addresses. 310 Although there have been some attempts at doing this, they gained no 311 large-scale traction. 313 Historically, there has been a basic incompatibility between email 314 address encoding and domain name encoding. A domain name is an 315 undifferentiated sequence, whereas an email address is structured 316 into two, semantically-distinct parts (separated by the "@" sign.) A 317 recent, popular enhancement to DNS naming is the use of an 318 underscore-based node name, such as [SRVDNS] for information that 319 does not need to be treated as a hostname. The application of this 320 enhancement could produce a query name in the style of: 322 Mailbox._at.example.net 324 Hence, key query would be for a domain name, where the name might be 325 a hostname or might be an encoded email address. Although this would 326 be a new mechanism, it entails no enhancement to infrastructure 327 services and it re-uses a well-established and reasonably inexpensive 328 form of DNS-based mechanism. 330 3.4. Message Encapsulation 332 Protecting the message header means that it needs to be hidden during 333 transit, in spite of the header's being modified in transit, for 334 email. One approach to solving this is to encapsulate the entire 335 message as a MIME attachment; the visible header therefore would only 336 contain handling information. This model of encapsulation only 337 requires adoption by author (or originating server) and recipient (or 338 receiving server) and is transparent to the message-handling 339 infrastructure. Architecturally, it is identical with the way MIME 340 was propagated, in the 1990s, so it's viability has been well 341 demonstrated. Also, encapsulating an entire message as an attachment 342 has already been enabled through [BSMTP]. 344 3.5. Protecting Envelope Meta-Data 346 If envelope data is to be hidden during transit, it must be 347 encapsulated in a message with different envelope data, and processed 348 by special, trusted relays that hide addressing and transit 349 information, and ensure that none is associated with the message when 350 it is finally delivered. This is in the spirit of [TOR]. 352 4. Security Considerations 354 Everything in this draft related to security, and especially to 355 confidentiality in the service of privacy protection. 357 5. IANA Considerations 359 There are no IANA considerations for this draft. 361 Note to RFC Editor: Please remove the entire IANA Considerations 362 section, prior to publication 364 6. References - Informative 366 [BSMTP] Freed, N., Newman, D., Hoy, M., and , "The Batch SMTP 367 Media Type", RFC 2442, November 1998. 369 [DANE] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 370 of Named Entities (DANE) Transport Layer Security (TLS) 371 Protocol: TLSA", RFC 6698, August 2012. 373 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 374 Identified Mail (DKIM) Signatures", RFC 6376, September 375 2011. 377 [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. 378 Rose, "DNS Security Introduction and Requirements", RFC 379 4033, March 2005. 381 [DNS] Mockapetris, P., "Domain names - concepts and facilities", 382 STD 13, RFC 1034, November 1987. 384 [MAILARCH] 385 Crocker, D., "Internet Mail Architecture", RFC 5598, July 386 2009. 388 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 389 Extensions (MIME) Part One: Format of Internet Message 390 Bodies", RFC 2045, November 1996. 392 [OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 393 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 395 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 396 Mail Extensions (S/MIME) Version 3.2 Message 397 Specification", RFC 5751, January 2010. 399 [SRVDNS] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 400 specifying the location of services (DNS SRV)", RFC 2782, 401 February 2000. 403 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 404 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 406 [TOR] "TOR Project", WEB https://www.torproject.org/, . 408 Authors' Addresses 410 Dave Crocker 411 Brandenburg InternetWorking 412 675 Spruce Drive 413 Sunnyvale, CA 94086 414 USA 416 Phone: +1.408.246.8253 417 Email: dcrocker@bbiw.net 419 Pete Resnick 420 Qualcomm Technologies, Inc. 421 5775 Morehouse Drive 422 San Diego, CA 92121 423 US 425 Phone: +1 858 6511 4478 426 Email: presnick@qti.qualcomm.com