idnits 2.17.1 draft-hallambaker-prismproof-dep-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 288: '... * A user MUST be able to force ...' RFC 2119 keyword, line 578: '... * A user MUST be able to config...' RFC 2119 keyword, line 579: '...but the encryption provided MAY not be...' RFC 2119 keyword, line 582: '... * A user MUST be able to send e...' RFC 2119 keyword, line 583: '... platform but MAY not be able to se...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'PHB2008' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'I-D.hallambaker-omnibroker' is defined on line 885, but no explicit reference was found in the text == Unused Reference: 'RFC2986' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'RFC3207' is defined on line 927, but no explicit reference was found in the text == Unused Reference: 'RFC2440' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC1421' is defined on line 939, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PHB2008' == Outdated reference: A later version (-08) exists of draft-hallambaker-omnibroker-06 == Outdated reference: A later version (-08) exists of draft-hallambaker-wsconnect-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'MS-ASCNTC' ** Downref: Normative reference to an Informational RFC: RFC 2986 -- Possible downref: Normative reference to a draft: ref. 'I-D.evans-palmer-key-pinning' ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track October 27, 2014 4 Expires: April 30, 2015 6 PRISM-Proof Email Deployment Requirements 7 draft-hallambaker-prismproof-dep-01 9 Abstract 11 This document describes previous efforts and their deployment legacy 12 and the requirements for a successful email security infrastructure. 13 A gap analysis is performed and the tasks divided into problems that 14 are generally considered solved albeit possibly requiring improved 15 execution and problems that may be regarded as research. 17 This division of the problem space into 'execution' and 'research' 18 portions allows different groups of developers to address each 19 independently and avoid unnecessary duplication of effort. A testbed 20 for development and early adopter deployment that achieves this 21 separation is described. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Earlier and Existing work . . . . . . . . . . . . . . . . 3 57 2. Requirements for Email Security . . . . . . . . . . . . . . . 5 58 2.1. Commercial Use . . . . . . . . . . . . . . . . . . . . . 6 59 2.2. Usability . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3. Availability . . . . . . . . . . . . . . . . . . . . . . 7 61 2.4. Confidentiality and Access . . . . . . . . . . . . . . . 7 62 2.5. Integrity and Authenticity . . . . . . . . . . . . . . . 9 63 2.6. Key Publication, Discovery, and Identity . . . . . . . . 9 64 2.7. Administrative Privileges . . . . . . . . . . . . . . . . 10 65 3. Common Testbed . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.1. Dividing the problem space between execution and research 11 67 3.2. Problem Simplification . . . . . . . . . . . . . . . . . 12 68 3.3. Transport . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.4. Data Formats . . . . . . . . . . . . . . . . . . . . . . 14 70 3.4.1. Email Security Policy Extensions . . . . . . . . . . 14 71 3.5. Key Generation and Disclosure . . . . . . . . . . . . . 15 72 3.5.1. Key and Endorsement Publication . . . . . . . . . . 16 73 3.6. Key Discovery and Validation . . . . . . . . . . . . . . 16 74 3.6.1. Omnibroker . . . . . . . . . . . . . . . . . . . . . 17 75 3.6.2. Exchange Contact Synchronization . . . . . . . . . . 17 76 4. Deployment Vehicles . . . . . . . . . . . . . . . . . . . . . 17 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 7.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 Establishing a ubiquitous infrastructure for end-to-end 87 confidentiality, integrity and authenticity of email has been an 88 unrealized goal of IETF security efforts for over two decades. This 89 document examines the deployment legacy of these previous email 90 security efforts with a view to identifying which parts may be 91 adopted in a new email security scheme with only minor modification 92 to improve execution and which limitations or deficiencies are better 93 considered research. 95 This analysis results in a proposal for an email security research 96 testbed which separates the parts of the infrastructure that 97 researchers can adopt in their current form without modification from 98 areas in which innovation is needed. It is hoped that dividing the 99 problem in this fashion will enable the most effective use of 100 developer resources permitting a developer with expertise in 101 developing extensions for one email user agent to support all the 102 research proposals based on the testbed and to a allow researchers 103 using the testbed to support all the clients that have been enabled. 105 Recent events have renewed interest in email privacy and may present 106 a fresh opportunity to deploy a comprehensive email security 107 infrastructure. But even if the threat of a PRISM-class attack 108 provides the necessary momentum to restart development efforts, any 109 infrastructure developed must address the full range of email 110 security concerns if it is to become ubiquitous. 112 1.1. Earlier and Existing work 114 The IETF has attempted to produce an email security scheme on six 115 previous occasions: 117 Privacy Enhanced Mail (PEM) [~RFC1421] 118 PEM provided an email encryption and signature capability but 119 was not compatible with MIME message extensions that users 120 found to be more important and deployment of PEM depended on 121 establishing a PKI based on a trust model that is now 122 understood to be unfeasible. 124 S/MIME [!RFC5751] 125 S/MIME has achieved ubiquitous deployment in dedicated email 126 user agents but is not currently supported in Web Mail 127 products. Use of S/MIME requires a PKIX [!RFC5280] certificate 128 issued by a CA, a step that has proved too difficult for the 129 typical user and introduces a frequently criticized potential 130 point of failure. 132 OpenPGP [~RFC2440] 133 OpenPGPhas achieved ubiquitous mindshare but almost no widely 134 used email user agent offers native support. OpenPGP supports 135 the same capabilities as S/MIME but uses a Web of Trust 136 approach to key validation which eliminates the need for CAs 137 but introduces scaling and usability limitations. 139 DKIM [!RFC6376] 140 DKIM provides only a means to authenticate a message to a 141 sending domain and does not offer the ability to authenticate 142 the user who sent the message or provide confidentiality 143 capabilities. 145 STARTTLS [!RFC3207] 146 STARTTLS is an SMTP extension that enables the use of Transport 147 Layer Security [!RFC5246]. While STARTTLS is supported by many 148 if not most modern mail servers, these deployments only provide 149 protection against a passive attack as the client does not 150 typically validate the credentials of the server receiving the 151 mail and the lack of a policy mechanism permits a man in the 152 middle to achieve a downgrade attack. 154 DANE [!RFC6698] 155 DANE provides a mechanism which is in principle capable of 156 being used to advise mail senders that a mail server offers the 157 STARTTLS extension and validating the certificate to be used 158 based on DNSSEC [!RFC4033]. 160 Of these efforts, only S/MIME, DKIM and STARTTLS have achieved 161 ubiquitous deployment to date while only OpenPGP has achieved 162 ubiquity in mindshare. The resulting stalemate has lasted over a 163 decade. 165 Attempting to revisit work previously attempted that has failed 166 requires us to ask whether it is necessary to re-invent the wheel and 167 whether a new attempt has better prospects for success. In order to 168 answer such objections we must understand the reasons for the earlier 169 failures. 171 The Internet has two 'killer applications'; email, and the Web. The 172 Web has succeeded in establishing a comprehensive security 173 infrastructure while email has failed. 175 The chief security infrastructure of the World Wide Web is SSL/TLS 176 and the WebPKI. This security infrastructure presented a clear and 177 immediate benefit to parties deploying SSL security, in particular 178 the ability to use the Web for an important purpose not possible 179 otherwise (the ability to accept credit cards). Secure email has a 180 similar potential to enable the use of email for purposes not 181 currently possible. For example the ability to remit electronic 182 invoices and other transactional data in machine readable formats. 184 Another key element in the success of SSL/TLS is the ease of 185 deployment (and to a lesser extent, development). To enable 186 'security' on a Web site, the system manager needs to do nothing more 187 than obtain and install an X.509/PKIX certificate. 189 Finally, and perhaps most importantly, SSL/TLS places no burden on 190 the end user. The end user need take no action whatsoever (although 191 to be secure the end user should take notice of the security 192 indicators provided). In contrast, use of S/MIME requires that each 193 user obtain a certificate and renew it at regular intervals, 194 typically a year. This is a significant burden on the end user. 195 Sending an encrypted message requires the user first obtain the 196 certificate of the intended recipient, a process that is hardly 197 simple. Use of PGP requires the user to understand and navigate the 198 Web of Trust. 200 One factor that made developing a security infrastructure for the Web 201 considerably easier than developing an infrastructure for email is 202 that efforts to add cryptography began within a few months of the 203 first public release of the Web. Email was an established 204 infrastructure before the (public) invention of public key 205 cryptography and efforts to retrofit cryptography had to work within 206 the constraints of what had already become a complex legacy 207 infrastructure. 209 Another factor that makes email security a more difficult problem 210 than Web security is that the basic unit of interaction in email is 211 the individual user while Web security is provided at the level of 212 the site. 214 2. Requirements for Email Security 216 A comprehensive email security infrastructure must meet a wide range 217 of requirements, not all of which may be compatible. In the 218 enterprise, the confidentiality provided by strong encryption may 219 conflict with a security policy that requires all inbound email be 220 scanned for potential malware. 222 At the time PGP and S/MIME were developed it was common to refer to 223 'Internet users'. Today the Internet has over 2.4 billion users and 224 virtually every literate person in the developed world is an Internet 225 user. It makes no more sense to refer to 'Internet users' as a 226 distinct class of people as it would to refer to 'telephone users' or 227 'electricity users'. 229 A security infrastructure that can support a population that size 230 must work as easily and reliably as the telephone and electricity 231 infrastructures do. A security infrastructure that requires users 232 think is not going to succeed. 234 A common mistake made in considering requirements is that prospects 235 for deployment are improved by reducing requirements to the bare 236 minimum. While this approach may reduce development costs it also 237 reduces functionality and the potential value to adopters. Worse 238 still is the approach in which the design team performs triage on the 239 set of requirements before beginning the design work. While it is 240 acceptable, possibly even inevitable that a design will not meet 241 every requirement raised in the design process, parties considering 242 adoption should know which requirements a design does not meet. 244 The discovery of PRISM-class attacks requires all aspects of a 245 protocol to become transparent including the design process. If a 246 legitimate requirement is raised during the development process it 247 must be listed in the requirements document even if the final design 248 does not address it. 250 2.1. Commercial Use 252 One of the main reasons that SSL has succeeded despite the cost of 253 using the WebPKI and OpenPGP has failed to become ubiquitous despite 254 being free for use is that SSL presented a valuable commercial 255 opportunity while OpenPGP did not. 257 The Internet has over 2.4 billion users and any infrastructure 258 supporting such a userbase will inevitably incur maintenance costs. 259 Even if those costs are a fraction of a cent per user, the aggregate 260 cost is millions of dollars. In practice the inevitable need for some 261 level of instruction and customer service means that the costs are 262 likely to be rather higher. 264 2.2. Usability 266 The least effective security control is the one that is never used. 267 An email security infrastructure can only become ubiquitous if using 268 email securely requires no more effort than using it insecurely does. 270 Usability studies are difficult to perform well, security usability 271 studies are even harder. A typical usability study is focused on the 272 question most important to the manufacturer of a product: How to make 273 a sale. Such studies are usually focused on the type of short term 274 interactions a potential customer makes while deciding whether to buy 275 rather than long term use. In particular there is a tendency to 276 'solve' a usability problem by hiding information from the user if it 277 might cause concern. 279 * Installing an configuring security should take no more effort 280 than configuring a mail application does today. 282 * Sending a mail message should require no more knowledge of the 283 recipient than their email address. 285 * Mail should be secure by default, there should be no need to 286 click a button to sign or encrypt the message. 288 * A user MUST be able to force use of encryption when necessary 289 at the message, recipient and domain level. 291 * The MUA must provide the user with sufficient information to 292 perform their tasks securely and provide additional explanation 293 when necessary. 295 2.3. Availability 297 Email has become an essential facility for most people in the modern 298 world. Secure email is of no use to them if they cannot rely on being 299 able to access their email or email archives. 301 [[Multiple-Devices] 302 Users must be able to access their secure mail from any of the 303 devices they currently read mail including mobile devices and 304 multiple desktop computers. 306 [[Archive] 307 Users must be certain that they will not lose access to their 308 email messages or archives. 310 [[Policy] 311 Users must be able to tell email senders which encrypted 312 formats they are capable of accepting and whether they prefer 313 email to be encrypted by default or not. 315 2.4. Confidentiality and Access 317 Earlier attempts to provide email security were developed at a time 318 when the Internet was a community of people. The modern Internet is 319 both a community of users and also the communication medium that 320 supports the vast majority of commercial and government activities. 322 Commercial and government use of the Internet have confidentiality 323 needs that are distinct from the needs of private individuals. In 324 particular an employee of a government or commercial entity my be 325 acting in a personal or an official capacity. 327 * An enterprise needs access to all email messages sent to their 328 employees and contractors in their official capacity. 330 * An enterprise may be subject to regulations that require all 331 communications made in certain environments be recorded, 332 archived and made available for later inspection. 334 * An enterprise may need to balance their need for 335 confidentiality against their other security objectives. In 336 particular efforts to block spam and malware. 338 * An email sender should know whether the message they are 339 sending is confidential to the identified individual or to the 340 domain name holder. 342 These concerns give rise to the following requirements: 344 [[Enterprise-Access] 346 A domain name holder must be able to control the use of 347 encryption enhancements in mail sent to their domain. 349 [[Sender-Notification] 350 An email sender must know whether the message they are sending 351 is confidential to the identified individual or to the domain 352 name holder. 354 Confidentiality is not a binary quality. An email sent by 355 alice@example.com to bob@example.net may be encrypted as follows: 357 * TLS security between Alice's MUA and the example.com outbound 358 mail server. 360 * TLS security between the example.com outbound mail server and 361 the example.net inbound server. 363 * TLS security between the example.net inbound server and Bob's 364 MUA. 366 * Message layer security under a public encryption key of 367 bob@example.net 369 * Message layer security under a public encryption key of 370 example.net 372 TLS security only protects the confidentiality of messages during 373 transport and is thus only a sufficient confidentiality control if we 374 can be confident that transport security will be used on each of the 375 three occasions the messages travel across the Internet and that the 376 message will be acceptably secure when queued at the outbound server 377 waiting for dispatch, on the inbound server at example.net and on any 378 MUAs that Bob might be using that download and store a copy of the 379 message. 381 Message layer security provides a more comprehensive confidentiality 382 guarantee for the message contents but cannot provide protection for 383 the routing information (aka meta-data) necessary to route the 384 information over the public network. In the case of S/MIME and PGP, 385 the confidentiality is further compromised by the odd decision to 386 transmit message subject lines as plaintext. 388 Rather than considering TLS and Message Layer security to be 389 competing alternatives, we should acknowledge the fact that both 390 approaches are valuable and that we should encourage the use of both. 392 2.5. Integrity and Authenticity 394 While the desire for confidentiality has been the traditional driver 395 for Internet email security efforts (e.g. Pretty Good Privacy), it is 396 far more likely that a user will suffer harm or economic loss as a 397 result of an authenticity attack. 399 This morning I have three messages that have evaded my spam filter 400 that are telling me that I need to reset my username and password. 401 All three are fraudulent but appear identical in virtually every 402 respect to the genuine messages that the purported senders have sent 403 in the past. 405 Establishing a usable infrastructure for establishing the 406 authenticity of email messages is as important and necessary as 407 establishing a usable confidentiality infrastructure. 409 2.6. Key Publication, Discovery, and Identity 411 The Internet email system is based on the principle that all a user 412 needs to send a message to another is to have an email sending 413 account and to know the email address of the intended recipient. Any 414 secure email infrastructure must recognize that same constraint. 416 Accordingly mechanisms are required that can: 418 [[Publication] 419 Enable Alice, the authorized holder of example.com to generate 420 a public keypair and publish the public portion thereof for use 421 by email senders. 423 [[Discovery] 424 Map an email address (e.g. alice@example.com) to a certificate 425 purportedly belonging to the holder of account 426 alice@example.com. 428 [[Identity] 429 Establish whether the certificate purportedly belonging to 430 alice@example.com does in fact belong to the party the sender 431 intends. 433 Identity is and is likely to remain an ongoing research topic because 434 it is this aspect of PKI that represents the interface between the 435 online and offline worlds. All the rest of the cryptography and 436 infrastructure is merely protocol and math. Identity cannot be 437 reduced to mere math because it involves people and names. 439 Identity is not an objective truth and it is highly unlikely that 440 research will arrive at a single definitive approach that is suited 441 to all purposes and all times. Rather than deciding between the PKIX 442 CA approach and the OpenPGP Web of Trust we sypport the use of both 443 or a system that is capable of supporting both. 445 Identity has multiple dimensions. Even the simple system described 446 gives rise to multiple identity requirements reflecting the different 447 dimensions of trust: 449 [[Account-Identity] 450 The encryption key to use to encrypt email sent to 451 alice@example.com 453 [[Personal-Identity] 454 The encryption key to use to encrypt email sent to Alice 456 [[Organizational-Identity] 457 The encryption key to use to encrypt email sent to Alice 458 working at Example Inc, the owner of example.com. 460 2.7. Administrative Privileges 462 One of the major lessons learned in the successful deployment of the 463 World Wide Web in comparison to its rivals was the importance of 464 allowing Web users to post pictures of their cats. 466 Unlike rival systems such as Hyper-G, setting up a Web client or 467 server needed no system administration privilege or purchase order. 468 Any user granted ordinary UNIX or VMS user privileges could set up a 469 client or server. One unexpected consequence of this difference was 470 that systems like Hyper-G were bought for a specific purpose and use 471 for frivolous purposes such as pictures of cats was strongly 472 discouraged. The Web in contrast, was a free for all. The only 473 barrier to putting information on the Web was the willingness of 474 someone to publish. As a result the fact that prior to the launch of 475 Netscape Navigator in late 1994, Hyper-G had a far nicer, slicker 476 client was irrelevant. The Web won the standards war in part because 477 it won the content war: The Web had pictures of cute cats and Hyper-G 478 did not. 480 For email security to succeed in deployment, users must be able to 481 publish a key without first obtaining permission from their system 482 administration. But this is a matter of convenience, not right. 484 The holder of a DNS domain name also has the right to control how 485 their domain is used. If example.com is a bank, the bank has a 486 security interest in telling potential relying parties to only trust 487 credentials duly authorized by the bank itself. If bank employees 488 find this to be inconvenient, they can use a different domain or 489 register their own. 491 [[User-Autonomy] 492 It must be possible for Alice, the authorized holder of 493 alice@example.com to publish a public key for her account 494 without action by the domain administrator. 496 [[DNS-Control] 497 A DNS domain name owner must have the ability to control the 498 credentials issued for their domain should they choose to do 499 so. 501 3. Common Testbed 503 Previous efforts to develop an Internet email security infrastructure 504 have left unsolved problems but what is more important is the much 505 larger number of problems that may be fairly regarded as solved 506 whether in actual running code or through obvious extensions. To 507 deploy an secure email infrastructure that resists PRISM-class attack 508 we should build on what works whetever that is adequate for our 509 purpose and only revisit design decisions where unmet requirements 510 demonstrate that further work is required. 512 One factor that complicates this pragmatic approach is the schism 513 between S/MIME and OpenPGP which in addition to specifying two 514 different trust management approaches, also specify two message 515 formats, two key signing formats and two of everything else that 516 might be required. In these cases the existence of deployed code is 517 considered the deciding factor. 519 In particular adopting the S/MIME message and key formats as the base 520 to work from makes it possible to build a system that allows many 521 users to receive encrypted email using existing clients without 522 modification. Working from the OpenPGP message formats does not. 523 Therefore the S/MIME message formats are preferred over the OpenPGP 524 formats but this particular design decision does not preclude the use 525 of OpenPGP style 'Web of Trust' key validation. 527 3.1. Dividing the problem space between execution and research 529 The Testbed is designed to partition the solution space for secure 530 email into two parts; 'execution' and 'research' so that development 531 work can proceed independently on each part. 533 The interface between the two parts of the solution space is to be 534 addressed by a Web Service protocol. Current best practice and the 535 need to support a wide range of platforms including scripting 536 environments strongly favors the adoption of a JSON/REST style 537 syntax. 539 The Omnibroker Web Service is designed to meet this need in the 540 context of TLS and the protocol has been designed to support 541 discovery of peer-to-peer connections but has not yet been tested. 543 Omnibroker is built from two components, the JSON Service Connect 544 (JCX) Protocol [I-D.hallambaker-wsconnect] which establishes and 545 manages a secure authenticated connection between the client and 546 service and the Omnibroker Query Protocol [I-D.hallambaker- 547 omnibroker] which answers queries. 549 JCX is designed to provide a general facility that can be used in any 550 Web Service and should be applicable without specific modification to 551 address email. The query protocol is in theory designed to support 552 establishing peer-to-peer connections but this has not been tested 553 and the asynchronous nature of email may result in additional 554 requirements being discovered. 556 3.2. Problem Simplification 558 Since email is currently insecure by default, a testbed that offers 559 less than perfect end-to-end security is still a significant 560 improvement. The email infrastructure has taken four decades to 561 evolve to its current state. It will take some time to carry the 562 legacy infrastructure to the desired state of security. In the near 563 term it is much more important that an email user be able to exchange 564 email with users of experimental trust infrastructures than achieve 565 the end to end benefits they may be designed to offer. 567 One of the reasons that the Web succeeded while Ted Nelson's Xanadu 568 failed is that the Web cut the right corners. HTTP does not offer the 569 referential transparency or the integrated search that Nelson 570 insisted was essential. But excluding those from HTTP made the 571 problem of deploying network hypertext tractable and third parties 572 offered tools and services to fill the gaps as soon as it became 573 clear that the Web was approaching critical mass. 575 To make the problem tractable, the following simplifications are 576 allowed: 578 * A user MUST be able to configure any email client so that they 579 can read encrypted email but the encryption provided MAY not be 580 end to end. 582 * A user MUST be able to send encrypted email from at least one 583 platform but MAY not be able to send encrypted email from every 584 platform. 586 * A user MUST be able to sent encrypted email to any party that 587 publishes a public key but MAY not be able to fully or even 588 partially validate the encryption key used. 590 * No extensions to the email client user interface are required. 592 * The problem of email authentication is not addressed in the 593 testbed as improved authentication requires considerable 594 modification of the client user interface. For a comprehensive 595 description of the changes I believe to be necessary, see my 596 book The dotCrime Manifesto [!PHB2008]. 598 * Discovery and validation of trust chains MAY be performed 599 partially or wholly in the cloud rather than end-to-end. 601 Accepting these simplifications for short term expediency does not 602 require them to be accepted as permanent concessions. I expect it to 603 be possible to eliminate each of the simplifications except for the 604 last as the testbed approaches a critical mass of users. 606 Performing trust chain discovery and validation end-to-end instead of 607 end-to-end is a very different proposition. Performing trust chain 608 discovery in particular is a task that is already delegated to a 609 cloud based service in many moderately complex trust topologies as 610 the success of SCVP demonstrates [RFC5055]. 612 It might well prove to be the case that it is also desirable for at 613 least some trust chain validation steps to be performed in the cloud 614 by a service rather than at the relying application. Insisting that 615 every trust chain validation step be performed end-to-end limits the 616 scope of validation steps that can be applied using the techniques 617 supported by and the data available to the client. 619 3.3. Transport 621 Transport security and message security serve distinct purposes and a 622 comprehensive email security infrastructure should provide both forms 623 of security on each and every message sent. 625 * SMTP, SUBMIT and IMAP traffic should always use TLS transport. 627 * Clients should support the use of a strong authentication 628 mechanism that does not disclose the authentication secret to 629 any party, including the purported service to which the client 630 is authenticating. 632 * Clients should be capable of validating the TLS Certificates 633 presented by the service. 635 The last criteria is not currently supported by existing 636 infrastructure. DANE [RFC6698] proposes one mechanism for validating 637 the certificates using the DNSSEC trust hierarchy [RFC4033]. But this 638 is only one mechanism and one that in its current form limits the 639 verifier to a single root of trust. 641 MUAs should be capable of pinning TLS certificates presented by 642 SUBMIT and IMAP services [I-D.evans-palmer-key-pinning] and 643 instructing the outbound mail server to only forward a message over a 644 TLS secured channel. These precautions enable a MUA that has received 645 security policy information for the intended target mail server to 646 relay it to the outbound server which may not have access to that 647 source. 649 3.4. Data Formats 651 Secured mail is exchanged in S/MIME formats [RFC5751] so as to take 652 advantage of the deployed base of S/MIME clients. 654 The choice of S/MIME as the message format naturally leads to the use 655 of X.509v3/PKIX as the certificate format but not necessarily 656 according to the PKIX trust model. 658 When OpenPGP and PEM were being developed, few software libraries 659 were available to support parsing and validation of X.509v3 660 certificates. Today these resources are commonplace and supported in 661 virtually every major code development platform. Certificate 662 generation tools, while somewhat less common are also freely 663 available. 665 3.4.1. Email Security Policy Extensions 667 The following X.509v3 extension may be included in an end-entity 668 certificate to describe the encrypted email security policy of the 669 corresponding address. 671 [[Details TBD, the extension must allow the party identified to 672 specify policies such as the following] 674 * Transport Security Policy: Required / Always offered / 675 Sometimes offered / Unknown 677 * Account Message Encryption Policy: Always / Sometimes / Never 679 * Domain Message Encryption Policy: Always / Sometimes / Never 681 * Message Signature Policy: Always / Sometimes / Never 683 * Domain Message Signature Policy: Always / Sometimes / Never 685 While the policy language could in principle include key pinning it 686 is contrary to the PKIX architecture to incorporate information that 687 constrains the use of one end-entity certificate in a different end- 688 entity certificate. 690 3.5. Key Generation and Disclosure 692 One of the key weaknesses in the currently deployed S/MIME 693 infrastructure is that most S/MIME clients rely on a Web browser to 694 generate keys. This is unsatisfactory in many ways: 696 * The process is not transparent. It is not clear to the user 697 that their public/private keypair is being generated by the Web 698 browser that they are using rather than by the CA that issues 699 the certificate. 701 * The key generation mechanism is potentially vulnerable to 702 weaknesses in the random number generation routine used and may 703 even be compromised by a covert channel attack (kleptography). 705 * Only the PKIX trust model is supported. 707 * The certificate will only be published to a directory if the CA 708 performs the operation. 710 * The user is left to configure their MUA(s) themselves, a 711 process that frequently requires them to interact with a user 712 interface that is frequently illogical and obscure. 714 To address these shortcomings I propose that key generation and MUA 715 configuration be the task of a new type of application, a key 716 generation / MUA configuration tool supporting the following 717 functions: 719 * Allows the user/domain to specify their email encryption policy 720 (always, sometimes, never) 722 * Generates public/private key pairs [[Stretch] Generate private 723 keys in a format that precludes/minimizes covert channel. 724 Supports use of an archival service with appropriate safeguards 725 to protect confidentiality of the private key (e.g. key 726 shares). 728 * Recovers a private key from archival format 730 * Registers the public key with disclosure service: Generate a 731 Certificate Signing Request (CSR) [!RFC2986]. Generate a Self- 732 Signed certificate 734 * Configures a MUAs installed on the machine to make use of the 735 private keypair in accordance with the specified policy. 737 The functions of the key generation / MUA configuration tool could be 738 integrated into an MUA but this is neither necessary nor necessarily 739 desirable. Configuration of the user's security context should be an 740 occasional event rather than one requiring frequent attention or even 741 one that demands attention at regular intervals. 743 An MUA can assist the developers of such tools by publishing 744 specifications that describe how to configure the application or by 745 adopting standardized interfaces for exchange of the information (for 746 example through the Windows registry or configuration files in well 747 known locations on UNIX based machines). 749 While implementing the proposed features requires a new specification 750 and new code, the work required is well understood and the design 751 choices are limited to issues of syntax rather than substance. 752 Accordingly, this portion of the testbed is considered to fall under 753 the heading of execution rather than research. A detailed 754 specification and sample code is in development. 756 3.5.1. Key and Endorsement Publication 758 In order to support Key Validation, some form of key endorsement 759 infrastructure is required. The structure of endorsement 760 infrastructure itself is research problem and MAY involve endorsement 761 by specialist trust providers (i.e. Certificate Authorities), peer- 762 to-peer endorsement by end entities (i.e. Web of Trust) and 763 notarization (i.e. Certificate Transparency). 765 A standardized interface is required to separate the email client 766 from the endorsement infrastructure. Such an interface MUST be 767 capable of supporting existing key endorsement infrastructures (hence 768 the need to generate a Certificate Signing Request) and MUST be 769 capable of supporting the new infrastructures resulting from new 770 research. 772 This interface is currently undefined. An additional JSON/REST based 773 Web Service is required. 775 3.6. Key Discovery and Validation 777 Key Discovery and Validation represent the research component of the 778 email security problem. Previous experience suggests that rather than 779 searching for 'the' solution to this problem we should seek out 780 multiple solutions and ask which solutions are best suited for which 781 purpose. The trust infrastructure that is suitable for protecting the 782 confidentiality of communications between designers of network 783 security protocols is not necessarily best suited for protecting the 784 confidentiality and authenticity of email exchanges with a bank. It 785 is even possible that different approaches to trust infrastructure 786 may be best suited to different customers of the same bank. 788 To separate the research part of the problem from the execution part, 789 the email client queries a Web Service each time an email message is 790 sent to determine whether cryptographic enhancements should be 791 applied and if so which ones. 793 3.6.1. Omnibroker 795 The Omnibroker protocol is a JSON/REST style query protocol that is 796 designed to answer questions of the form 'How should client X best 797 connect to service Y'. 799 [TBD describe the exact means of applying Omnibroker to ask how to 800 send an email to a recipient and answers that indicate use cases such 801 as, send in plaintext, send encrypted under encryption Key X.] 803 3.6.2. Exchange Contact Synchronization 805 Microsoft Outlook provides a mechanism for discovery of email contact 806 data using a proprietary but documented protocol [MS-ASCNTC]. 808 This might prove useful as a mechanism for supporting legacy clients 809 that support S/MIME but do not provide an interface to a standards 810 based certificate discovery mechanism. Though being based on the 811 user's contact list, the mechanism only covers email sent to an 812 address that is already in the contact list when the message is sent 813 and synchronization of the contacts list may only take place on an 814 infrequent basis with the result being cached rather than causing a 815 fresh query to be made for each email message sent. 817 One option for using this feature would be to write a proxy to 818 intercept interactions between the client and the Exchange server, 819 adding entries for certificates that are found to be missing. A 820 possibly better approach would be to scan the user's exchange 821 contacts list on a regular basis and attempt to discover and add a 822 certificate for each entry lacking one. 824 4. Deployment Vehicles 826 Making use of the testbed, whether for experimental or production 827 purposes requires that it be integrated into some form of deployment 828 vehicle. Three types of deployment vehicle are considered: 830 * Native functionality in a mail client 832 * A mail client plug-in 834 * A proxy service. 836 Native functionality is clearly preferred over the use of a plug-in 837 or proxy but requires the most development effort. Native 838 functionality offers the opportunity to extend the user interface to 839 offer features such as the option to require encryption for specific 840 messages, users or groups of users. 842 Many mail clients offer a plug-in capability that provides almost the 843 same degree of flexibility as native code. But plug-ins are 844 justifiably considered an unwelcome hazard in most Enterprise 845 computing environments and increasingly so in consumer environments 846 as well. However robust the design of the plug-in framework, the 847 plug-in and host application must inevitably follow divergent 848 development paths. Each update to the host application may affect the 849 plug-in as may any other plug-in that is installed. 851 Writing a plug-in typically requires a detailed knowledge of the mail 852 client and plug-in architecture that is only sometimes revealed in 853 accessible documentation. 855 Use of a proxy service is probably the simplest deployment vehicle 856 but is limited by the user interface functionality supported by the 857 existing clients and the protocols by which the client interacts with 858 the proxy. 860 Many email clients already support decryption of encrypted mail once 861 the necessary decryption key is installed on the machine. It may be 862 sufficient therefore to proxy the outbound email sent via SMTP/SUBMIT 863 and perform opportunistic encryption if a corresponding encryption 864 certificate can be found and the recipient prefers all email to be 865 encrypted. 867 5. Security Considerations 869 I am sure there are some. 871 6. Acknowledgments 873 Thanks to the many people who have encouraged me in this work and in 874 particular the members of the IETF PERPASS list and the Cryptography 875 mailing list. Future versions of the draft will have a more complete 876 list. 878 7. References 880 7.1. Normative References 882 [PHB2008] Hallam_Baker, P, "The dotCrime Manifesto: How to Stop 883 Internet Crime", Semptember 2013. 885 [I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol", 886 Internet-Draft draft-hallambaker-omnibroker-06, 8 July 887 2013. 889 [I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect 890 (JCX) Protocol", Internet-Draft draft-hallambaker- 891 wsconnect-04, 8 July 2013. 893 [MS-ASCNTC] , "[Reference Not Found!]". 895 [RFC2986] ,Nystrom, M.,Kaliski, B., "PKCS #10: Certification Request 896 Syntax Specification Version 1.7", RFC 2986, November 897 2000. 899 [I-D.evans-palmer-key-pinning] Evans, C,Palmer, C, "Public Key 900 Pinning Extension for HTTP", Internet-Draft draft-evans- 901 palmer-key-pinning-00, 14 November 2011. 903 [RFC4033] Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S., 904 "DNS Security Introduction and Requirements", RFC 4033, 905 March 2005. 907 [RFC6376] Crocker, D.,Hansen, T.,Kucherawy, M., "DomainKeys 908 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 909 September 2011. 911 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 912 R.,Polk, W., "Internet X.509 Public Key Infrastructure 913 Certificate and Certificate Revocation List (CRL) 914 Profile", RFC 5280, May 2008. 916 [RFC5751] Ramsdell, B.,Turner, S., "Secure/Multipurpose Internet 917 Mail Extensions (S/MIME) Version 3.2 Message 918 Specification", RFC 5751, January 2010. 920 [RFC6698] Hoffman, P.,Schlyter, J., "The DNS_Based Authentication of 921 Named Entities (DANE) Transport Layer Security (TLS) 922 Protocol: TLSA", RFC 6698, August 2012. 924 [RFC5246] Dierks, T.,Rescorla, E., "The Transport Layer Security 925 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 927 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 928 Transport Layer Security", RFC 3207, February 2002. 930 7.2. Informative References 932 [RFC5055] Freeman, T.,Housley, R.,Malpani, A.,Cooper, D.,Polk, W., 933 "Server_Based Certificate Validation Protocol (SCVP)", RFC 934 5055, December 2007. 936 [RFC2440] Callas, J.,Donnerhacke, L.,Finney, H.,Thayer, R., "OpenPGP 937 Message Format", RFC 2440, November 1998. 939 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 940 Mail: Part I: Message Encryption and Authentication 941 Procedures", RFC 1421, February 1993. 943 Author's Address 945 Phillip Hallam-Baker 946 Comodo Group Inc. 948 philliph@comodo.com