idnits 2.17.1 draft-newman-email-deep-02.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 draft header indicates that this document updates RFC5068, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1939, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3464, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1939, updated by this document, for RFC5378 checks: 1995-05-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 2014) is 3542 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-02) exists of draft-melnikov-email-tls-certs-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.melnikov-email-tls-certs' == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-02 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Moore 3 Internet-Draft Network Heretics 4 Updates: 1939, 3464, 3501, 5068, C. Newman 5 6186 (if approved) Oracle 6 Intended status: Standards Track August 16, 2014 7 Expires: February 17, 2015 9 Deployable Enhanced Email Privacy (DEEP) 10 draft-newman-email-deep-02.txt 12 Abstract 14 This specification defines a set of requirements and facilities 15 designed to improve email privacy. This provides mechanisms intended 16 to increase use of already deployed Transport Layer Security (TLS) 17 technology, provide a model for mail user agents privacy assurance, 18 and enable mail service providers to advertise improved TLS privacy 19 facilities. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 17, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Conventions and Terminology Used in This Document . . . . . . 4 57 3. Mail Account Privacy Assurance Level . . . . . . . . . . . . . 5 58 3.1. High Privacy Assurance . . . . . . . . . . . . . . . . . 5 59 3.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 6 60 3.3. Low Privacy Assurance . . . . . . . . . . . . . . . . . . 6 61 3.4. Other Privacy Assurance Levels . . . . . . . . . . . . . 7 62 4. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . 7 64 4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 8 65 4.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . 8 66 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP . 8 67 5. Email Security Upgrading Using Security Latches . . . . . . . 9 68 5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 9 69 5.2. Initial Set of Email Security Tags . . . . . . . . . . . 10 70 5.3. Server DEEP Status . . . . . . . . . . . . . . . . . . . 10 71 5.4. Email Security Tag Latch Failures . . . . . . . . . . . . 11 72 6. Recording TLS Cipher Suite in Received Header . . . . . . . . 11 73 7. Extensions for DEEP Status and Reporting . . . . . . . . . . . 12 74 7.1. IMAP DEEP Extension . . . . . . . . . . . . . . . . . . . 12 75 7.2. POP DEEP Extension . . . . . . . . . . . . . . . . . . . 14 76 7.3. SMTP DEEP Extension . . . . . . . . . . . . . . . . . . . 15 77 7.4. SMTP Error Extension . . . . . . . . . . . . . . . . . . 16 78 8. Use of SRV records in Establishing Configuration . . . . . . . 16 79 9. Implementation Requirements . . . . . . . . . . . . . . . . . 17 80 9.1. All Implementations (Client and Server) . . . . . . . . . 17 81 9.1.1. Client Certificate Authentication . . . . . . . . . . 18 82 9.2. Mail Server Implementation Requirements . . . . . . . . . 18 83 9.3. Mail User Agent Implementation Requirements . . . . . . . 19 84 9.4. Non-configurable MUAs and nonstandard access protocols . 20 85 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and 86 Services . . . . . . . . . . . . . . . . . . . . . . . . 20 87 10. Mail Service Provider Requirements . . . . . . . . . . . . . . 20 88 10.1. Server Requirements . . . . . . . . . . . . . . . . . . . 20 89 10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 20 90 10.3. TLS Server Certificate Requirements . . . . . . . . . . . 21 91 10.4. Recommended DNS records for mail protocol servers . . . . 21 92 10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . . 21 93 10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . . 21 94 10.4.3. TLSA records . . . . . . . . . . . . . . . . . . . . . 22 95 10.4.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 22 97 10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . . 22 98 10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 22 99 10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . . 22 100 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 101 11.1. Security Tag Registry . . . . . . . . . . . . . . . . . . 22 102 11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 23 103 11.3. POP3S Port Registration Update . . . . . . . . . . . . . 25 104 11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 25 105 11.5. Submissions Port Registration . . . . . . . . . . . . . . 26 106 11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 27 107 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 27 108 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 27 109 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . . 27 110 11.10. MAIL Parameters Additional-registered-clauses 111 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 28 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 115 13.2. Informative References . . . . . . . . . . . . . . . . . 30 116 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 31 117 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 32 118 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 34 119 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 35 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 122 1. Introduction 124 Software that provides email service via Internet Message Access 125 Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] 126 and/or Simple Mail Transfer Protocol (SMTP) [RFC5321] usually has 127 Transport Layer Security (TLS) [RFC5246] support but often does not 128 use it in a way that maximizes end-user privacy. This specification 129 proposes changes to email software and deployments intended to 130 increase the use of TLS and record when that use occurs. 132 In brief, this memo now recommends that: 134 o MUAs associate a privacy assurance level with each mail account, 135 and the default privacy level requires use of TLS with certificate 136 validation for all TCP connections; 138 o TLS on a well-known port ("Implicit TLS") be supported for IMAP, 139 POP, and SMTP Submission [RFC6409] for all electronic mail user 140 agents (MUAs), servers, and service providers; 142 o MUAs and mail protocol servers cooperate (via mechanisms defined 143 in this specification) to upgrade security/privacy feature use and 144 record/indicate that usage appropriately. 146 Improved use of TLS with SMTP for message relaying is described in a 147 separate document [I-D.ietf-dane-smtp-with-dane]. 149 The recommendations in this memo do not replace the functionality of, 150 and are not intended as a substitute for, end-to-end encryption of 151 electronic mail. 153 This draft is subject to change. Implementation of this proposal is 154 not recommended at this time. Please discuss this proposal on the 155 ietf-uta mailing list. 157 2. Conventions and Terminology Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 This specification expresses syntax using the Augmented Backus-Naur 164 Form (ABNF) as described in [RFC5234], including the core rules in 165 Appendix B and rules from [RFC5322]. 167 In examples, "C:" and "S:" indicate lines sent by the client and 168 server respectively. If a single "C:" or "S:" label applies to 169 multiple lines, then the line breaks between those lines are for 170 editorial clarity only and are not part of the actual protocol 171 exchange. 173 3. Mail Account Privacy Assurance Level 175 The configuration necessary for a mail account includes an email 176 address, connection information and authentication credentials for at 177 least one mail access server (IMAP or POP) and at least one SMTP 178 submission server. A mail user agent (MUA) typically supports one or 179 more mail account configurations. MUAs compliant with this 180 specification MUST associate a privacy assurance level with each mail 181 account. MUAs MUST implement a high privacy level as described in 182 the next section. 184 MUAs SHOULD continuously indicate to the user the privacy for an 185 account's connections (e.g., via a lock icon, background colors and 186 indications similar to those commonly used in web browsers for this 187 purpose). Note that this could be higher than the level set at 188 account configuration but never lower. If multiple active 189 connections are associated with an account or view, the indication 190 should match the privacy level provided by the least private 191 connection. 193 Account configuration occurs when an MUA is first used to access a 194 particular service, when a user wishes to access or submit mail 195 through servers in addition to those specified or found during first 196 use, or when a user explicitly requests to change account 197 configuration parameters such as server names, user names, passwords, 198 client certificates, etc. Account configuration can be entirely 199 manual (entering server names explicitly) or partially automated via 200 a mechanism such as DNS SRV records [RFC6186]. MUAs SHOULD use the 201 high privacy assurance level as the default for newly configured 202 accounts. 204 3.1. High Privacy Assurance 206 A mail account has a high privacy assurance when the following 207 conditions are met on all TCP server connections associated with an 208 account. This includes connections to POP, IMAP and SMTP submission 209 servers as well as any other associated protocols defined now or in 210 the future. Examples of protocols associated with a mail account 211 include managesieve [RFC5804] and MTQP [RFC3887]. 213 o TCP connections MUST attempt to negotiate TLS via either Implicit 214 TLS Section 4 or STARTTLS. 216 o MUAs MUST implement [I-D.melnikov-email-tls-certs] and PKIX 217 [RFC5280]. 219 o MUAs MAY implement DANE [RFC6698]. 221 o User agents MUST abort a TLS session if the TLS negotiation fails 222 or the server's certificate or identity fails to verify. A user 223 may reconfigure the account to lower the expected level of privacy 224 if he/she chooses. Reduction of expected account privacy MUST NOT 225 be done on a click-through basis. 227 The end user is part of the system that protects the user's privacy 228 and security. As a result, it's critical not to present the end user 229 with a simple action that reduces their privacy in response to 230 certificate validation failure. An MUA which offers a user actions 231 such as "connect anyway", "trust certificate for future connections" 232 or "lower privacy assurance for this account" in response to 233 certificate validation failure is not providing a high privacy 234 assurance as defined in this section and thus does not comply with 235 this document. Examples of acceptable actions to offer would be 236 "work offline", "try again later", and "open service provider status 237 web page". 239 3.2. Certificate Pinning 241 MUAs MAY implement certificate pinning as part of account setup, but 242 MUST NOT offer this as an option in response to a failed certificate 243 validation for an existing account. Certificate pinning occurs when 244 the user agent saves a server certificate with the account settings 245 and trusts that certificate for subsequent connections to that 246 server. An MUA that allows certificate pinning MUST NOT allow a 247 certificate pinned for one account to validate connections for other 248 accounts. 250 A pinned certificate is subject to a man-in-the-middle attack at 251 account setup time, and lacks a mechanism to revoke or securely 252 refresh the certificate. Therefore use of a pinned certificate does 253 not provide a high privacy assurance and an MUA MUST NOT indicate a 254 high privacy level for an account or connection using a pinned 255 certificate. 257 3.3. Low Privacy Assurance 259 MUAs MAY implement a low privacy assurance level for accounts. At 260 this level, the MUA MUST attempt to negotiate TLS, but MAY ignore 261 server certificate validation failures. MUAs MAY support use of 262 connections without TLS, but if they do they SHOULD attempt TLS first 263 if available and MUST implement code to reconnect without TLS if TLS 264 negotiation fails for reasons other than certificate validity. 266 Note that if the TLS certificate is not successfully validated as 267 described in Section 3.1 or a version of SSL/TLS prior to TLS 1.0 is 268 used, the client MUST NOT present a high privacy indication for the 269 account or connection. 271 3.4. Other Privacy Assurance Levels 273 This specification is not intended to limit experimentation and 274 innovation with respect to user privacy. As a result more privacy 275 assurance levels are permitted. However, levels below the "low 276 privacy assurance" described in the previous section are discouraged 277 and implementers are cautioned that end users may be confused by too 278 many privacy levels. 280 4. Implicit TLS 282 Previous standards for use of email protocols with TLS used the 283 STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With 284 STARTTLS, the client establishes a clear text application session and 285 determines whether to issue a STARTTLS command based on server 286 capabilities and client configuration. If the client issues a 287 STARTTLS command, a TLS handshake follows that can upgrade the 288 connection. While this mechanism has deployed, an alternate 289 mechanism where TLS is negotiated immediately at connection start on 290 a separate port (referred to in this document as "Implicit TLS") has 291 deployed more successfully. To increase use of TLS, this 292 specification recommends use of implicit TLS by new POP, IMAP and 293 SMTP Submission software. 295 4.1. Implicit TLS for POP 297 When a TCP connection is established for the "pop3s" service (default 298 port 995), a TLS handshake begins immediately. Clients MUST 299 implement the certificate validation mechanism described in 300 [I-D.melnikov-email-tls-certs]. Once the TLS session is established, 301 POP3 [RFC1939] protocol messages are exchanged as TLS application 302 data for the remainder of the TCP connection. After the server sends 303 a +OK greeting, the server and client MUST enter AUTHORIZATION state, 304 even if client credentials were supplied during the TLS handshake. 306 See Section 9.1.1 for additional information on client certificate 307 authentication. See Section 11.3 for port registration information. 309 4.2. Implicit TLS for IMAP 311 When a TCP connection is established for the "imaps" service (default 312 port 993), a TLS handshake begins immediately. Clients MUST 313 implement the certificate validation mechanism described in [RFC3501] 314 and SHOULD implement the certificate validation mechanism described 315 in [I-D.melnikov-email-tls-certs]. Once the TLS session is 316 established, IMAP [RFC3501] protocol messages are exchanged as TLS 317 application data for the remainder of the TCP connection. If client 318 credentials were provided during the TLS handshake that the server 319 finds acceptable, the server MAY issue a PREAUTH greeting in which 320 case both the server and client enter AUTHENTICATED state. If the 321 server issues an OK greeting then both server and client enter NOT 322 AUTHENTICATED state. 324 See Section 9.1.1 for additional information on client certificate 325 authentication. See Section 11.4 for port registration information. 327 4.3. Implicit TLS for SMTP Submission 329 When a TCP connection is established for the "submissions" service 330 (default port 465), a TLS handshake begins immediately. Clients MUST 331 implement the certificate validation mechanism described in 332 [I-D.melnikov-email-tls-certs]. Once a TLS session is established, 333 message submission protocol data [RFC6409] is exchanged as TLS 334 application data for the remainder of the TCP connection. (Note: the 335 "submissions" service name is defined in section 10.3 of this 336 document, and follows the usual convention that the name of a service 337 layered on top of Implicit TLS consists of the name of the service as 338 used without TLS, with an "s" appended.) 340 Note that the submissions port provides access to a Mail Submission 341 Agent (MSA) as defined in [RFC6409] so requirements and 342 recommendations for MSAs in that document apply to the submissions 343 port, including the requirement to implement SMTP AUTH [RFC4954]. 345 See Section 9.1.1 for additional information on client certificate 346 authentication. See Section 11.5 for port registration information. 348 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP 350 When a client or server wishes to close the connection, it SHOULD 351 initiate the exchange of TLS close alerts before TCP connection 352 termination. The client MAY, after sending a TLS close alert, 353 gracefully close the TCP connection without waiting for a TLS 354 response from the server. 356 5. Email Security Upgrading Using Security Latches 358 Once an improved email security or privacy mechanism is deployed and 359 ready for general use, it is desirable to continue using it for all 360 future email service. For example, TLS is widely deployed in email 361 software, but use of TLS is often not required. At the time this is 362 written, deployed mail user agents (MUAs) [RFC5598] usually make a 363 determination if TLS is available when an account is first configured 364 and may require use of TLS with that account if and only if it was 365 initially available. If the service provider makes TLS available 366 after initial client configuration, many MUAs will not notice the 367 change. 369 Alternatively, a security feature may be purely opportunistic and 370 thus subject to downgrade attacks. For example, at the time this was 371 written, most TLS stacks that support TLS 1.2 will fallback to TLS 372 1.0 without alerting the client of the reduced security. Thus a 373 variety of active attacks could cause the loss of TLS 1.2 benefits. 374 Only if client policy is upgraded to require TLS 1.2 can the client 375 prevent all downgrade attacks. However, this sort of security policy 376 upgrade will be ignored by most users unless it is automated. 378 This section describes a mechanism, called "security latches", which 379 is designed to permit an MUA to recognize when a service provider has 380 committed to provide certain server security features, and that it's 381 safe for the client to change its configuration for that account to 382 require that such features be present in future sessions with that 383 server. When an MUA implements both privacy assurance levels and 384 security latches, then both the end-user and the service provider 385 independently have the ability to improve the end-user's privacy. 387 Note that security latches are a mechanism similar to HTTP Strict 388 Transport Security (HSTS) [RFC6797] but are extensible. 390 5.1. Email Security Tags 392 Each security latch is given a name known as an email security tag. 393 An email security tag is a short alphanumeric token that represents a 394 security facility that can be used by an IMAP, POP or SMTP Submission 395 session. When a server advertises a security tag it is making a 396 commitment to support that security facility indefinitely and 397 recommending that the client save that security tag with the account 398 configuration and require that security feature for future 399 connections to that server. When a security tag is saved by the 400 client in this way, it is then considered latched. For the "tls10" 401 and/or "tls12" tags, the client SHOULD refuse to connect to the 402 server unless the appropriate level of TLS is successfully 403 negotiated. If these tags are still advertised by the server after 404 negotiation, the client SHOULD latch these tags. Other security tags 405 are latched if they are advertised by the server, TLS is active and 406 the client successfully authenticates the server with the TLS 407 session. Once a security tag is latched, all subsequent connections 408 to that host require that security feature. For this privacy 409 protection to work as desired clients MUST NOT offer a click-through- 410 to-connect action when unable to achieve connection security matching 411 the latched security tags. 413 An identifier for a security tag has the following formal syntax: 415 security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_") 417 5.2. Initial Set of Email Security Tags 419 This section describes an initial set of email security tags. The 420 IANA Considerations Section 11 defines a registry so that more tags 421 can be defined in the future. The initial set of tags are defined in 422 Section 11.2 and include tls10, tls12, tls-cert and tls-dane-tlsa. 424 5.3. Server DEEP Status 426 Servers supporting this extension MUST advertise a DEEP status. This 427 status includes a list of security-tags the server administrator has 428 explicitly configured as recommended for use by end-users (the list 429 MAY be empty), an optional https Uniform Resource Locator (URL) 430 [RFC2818] that the client can save and subsequently resolve for the 431 user in the event of a security connection problem, and the DEEP 432 status can be extended by future updates to this specification. DEEP 433 status has the following formal syntax: 435 EXTCHAR = 0x20-21 / 0x23-2E / 0x30-3B / 0x3D-40 436 / 0x5B-60 / 0x7B-7E 437 ; printable characters excluding " \ < and ALPHA 439 deep-extend = EXTCHAR *(EXTCHAR / ALPHA / "<") 440 ; clients MUST ignore, for future extensibility 442 deep-status = [deep-tag *(SP deep-tag)] 444 deep-tag = deep-https / security-tag / deep-extend 446 deep-https = "<" ">" 448 The syntax for a Uniform Resource Identifier (URI) is defined in 449 [RFC3986]. Protocol extensions to advertise DEEP status are defined 450 in Section 7. 452 If the client successfully negotiates TLS and authenticates the 453 server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with 454 channel bindings [RFC5802]), then the client SHOULD record the 455 server's DEEP status information in the account configuration with 456 the server's hostname. Otherwise, the client SHOULD ignore the 457 server-provided DEEP status except for the "tls10" and "tls12" 458 security tags. 460 5.4. Email Security Tag Latch Failures 462 When a security tag latch has been set for connections from a client 463 to a server and the property identified by that tag is no longer 464 available, this results in a connection failure. An MUA SHOULD 465 inform the user of a potential threat to their privacy and offer to 466 resolve a previously-recorded DEEP status https URL if one is 467 available. An MUA might suggest deleting the account and re-creating 468 it as a cumbersome mechanism to reset the latches. MUAs are 469 discouraged from offering a lightweight option to reset or ignore 470 latches as this defeats the privacy benefit they provide to end 471 users. 473 6. Recording TLS Cipher Suite in Received Header 475 The ESMTPS transmission type [RFC3848] provides trace information 476 that can indicate TLS was used when transferring mail. However, TLS 477 usage by itself is not a guarantee of privacy or security. The TLS 478 cipher suite provides additional information about the level of 479 privacy or security made available for a connection. This defines a 480 new SMTP "tls" Received header additional-registered-clause that is 481 used to record the TLS cipher suite that was negotiated for the 482 connection. The value included in this additional clause SHOULD be 483 the registered cipher suite name (e.g., 484 TLS_DHE_RSA_WITH_AES_128_CBC_SHA) included in the TLS cipher suite 485 registry. In the event the implementation does not know the name of 486 the cipher suite (a situation that should be remedied promptly), a 487 four-digit hexadecimal cipher suite identifier MAY be used. The ABNF 488 for the field follows: 490 tls-cipher-clause = CFWS "tls" FWS tls-cipher 492 tls-cipher = tls-cipher-suite-name / tls-cipher-suite-hex 494 tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_") 495 ; as registered in IANA cipher suite registry 497 tls-cipher-hex = "0x" 4HEXDIG 499 7. Extensions for DEEP Status and Reporting 501 This memo defines optional mechanisms for use by MUAs to communicate 502 DEEP status to servers. One purpose of such mechanisms is to permit 503 servers to determine which and how many clients have latched security 504 facilities, and thus, to permit operators to be aware of potential 505 impact to their users should support for such facilities be changed. 506 For IMAP, the existing ID command is extended to provide this 507 capability. For SMTP Submission, a new CLIENT command is defined. 508 No similar mechanism is defined for POP in this version of the memo 509 to keep POP simpler, but one may be added in the future if deemed 510 necessary. 512 In addition, for each of IMAP, POP, and SMTP, a new DEEP capability 513 is defined so the client can access the DEEP status. 515 7.1. IMAP DEEP Extension 517 When an IMAP server advertises the DEEP capability, that indicates 518 the IMAP server implements IMAP4 ID [RFC2971] with additional field 519 values defined here. This is grouped with the ID command because 520 that is the existing IMAP mechanism for clients to report data for 521 server logging, and provides a way for the server to report the DEEP 522 status. 524 deep From server to client, the argument to this ID field is the 525 server DEEP status. Servers MUST provide this information in 526 response to an ID command. 528 latch From client to server, this is a space-separated list of 529 security tags the client has latched for this server. Servers MAY 530 record this information so administrators know the expected 531 privacy level of the client and can thus act to avoid security 532 latch failures (e.g., by renewing server certificates on time, 533 etc). 535 latch-fail From client to server, a space-separated list including 536 one or more security tag the client has latched that the client 537 was unable to achieve. This allows clients to report errors to 538 the server prior to terminating the connection to the server in 539 the event an acceptable privacy level is unavailable. 541 security-tags From client to server, this is a space-separated list 542 of security tags the client supports that are not latched. 544 tls Server-side IMAP proxies that accept TLS connections from 545 clients and connect in-the-clear over a fully private secure 546 network to the server SHOULD use this field to report the tls- 547 cipher (syntax as defined in Section 6) to the server. 549 IMAP clients SHOULD use the IMAP ID command to report latch failures 550 and determine the server DEEP status. Clients MAY use the ID command 551 to report other latch or security tag information. IMAP servers MUST 552 implement the ID command at least to report DEEP status to clients. 554 555 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 556 AUTH=SCRAM-SHA-1] hello 557 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" 558 "tls10 tls-cert" "security-tags" "tls12") 559 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 560 "") 561 S: a001 OK ID completed 563 Example 1 565 This example shows a client that successfully negotiated TLS version 566 1.0 or later and verified the server's certificate as required by 567 IMAP. The client supports TLS 1.2. However, even if the client 568 successfully negotiated TLS 1.2, it will not latch that security tag 569 automatically because the server did not advertise that tag. If the 570 client successfully validated the server certificate, it will latch 571 the provided URL. 573 574 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 575 AUTH=SCRAM-SHA-1] hello 576 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch-failure" 577 "tls-cert") 578 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 579 "tls10 ") 580 S: a001 OK ID completed 581 C: a002 LOGOUT 583 Example 2 585 This example shows a client that negotiated TLS, but was unable to 586 verify the server's certificate. The latch-failure informs the 587 server of this problem, at which point the client can disconnect. If 588 the client had previously latched a URI for privacy problems from 589 this server, it could offer to resolve that URI. However, the deep- 590 status in this exchange is ignored due to the latch failure. 592 594 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 595 AUTH=SCRAM-SHA-1] hello 596 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" 597 "tls10 tls-cert" "security-tags" "tls12" 598 "tls" "TLS_RSA_WITH_AES_128_CBC_SHA") 599 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 600 "tls10 tls-cert ") 601 S: a001 OK ID completed 603 Example 3 605 This example shows the connection from an IMAP proxy to a back-end 606 server. The client connected to the proxy and sent the ID command 607 shown in example 1, and the proxy has added the "tls" item to the ID 608 command so the back-end server can log the cipher suite that was used 609 on the connection from the client. 611 7.2. POP DEEP Extension 613 POP servers supporting this specification MUST implement the POP3 614 extension mechanism [RFC2449]. POP servers MUST advertise the DEEP 615 capability with an argument indicating the server's DEEP status. 617 618 S: +OK POP server ready 619 C: CAPA 620 S: +OK Capability list follows 621 S: TOP 622 S: SASL PLAIN SCRAM-SHA-1 623 S: RESP-CODES 624 S: PIPELINING 625 S: UIDL 626 S: DEEP tls10 tls12 627 S: . 629 Example 631 After verifying the TLS server certificate and issuing CAPA, the 632 client can latch any or all of the DEEP status. If the client 633 connects to this same server later and has a privacy failure, the 634 client can direct the user's browser to the previously-latched URI 635 where the service provider may provide advice to the end user. 637 7.3. SMTP DEEP Extension 639 SMTP Submission servers supporting this specification MUST implement 640 the DEEP SMTP extension. The name of this extension is DEEP. The 641 EHLO keyword value is DEEP and the deep-status ABNF is the syntax of 642 the EHLO keyword parameters. This does not add parameters to the 643 MAIL FROM or RCPT TO commands. This also adds a CLIENT command to 644 SMTP which is used to report client information to the server. The 645 formal syntax for the command follows: 647 deep-cmd = "CLIENT" 1*(SP deep-parameter) 649 deep-parameter = name / version / latch / latch-fail 650 / security-tags / tls / future-extension 652 name = "name=" esmtp-value 654 version = "version=" esmtp-value 656 latch = "latch=" security-tag *("," security-tag) 658 latch-fail = "latch-fail=" security-tag 659 *("," security-tag) 661 security-tags = "security-tags=" security-tag 662 *("," security-tag) 664 tls = "tls=" tls-cipher 666 future-extension = esmtp-param 668 esmtp-param = 670 esmtp-value = 672 The CLIENT command parameters listed here have the same meaning as 673 the parameters used in the IMAP DEEP extension (Section 7.1). The 674 server responds to the CLIENT command with a "250" if the command has 675 correct syntax and a "501" if the command has incorrect syntax. 677 678 S: 220 example.com Demo SMTP Submission Server 679 C: EHLO client.example.com 680 S: 250-example.com 681 S: 250-8BITMIME 682 S: 250-PIPELINING 683 S: 250-DSN 684 S: 250-AUTH PLAIN LOGIN 685 S: 250-DEEP tls10 tls-cert 686 S: 250-BURL imap 687 S: 250 SIZE 0 688 C: CLIENT name=demo_submit version=1.5 latch=tls10,tls-cert 689 security-tags=tls12 690 S: 250 OK 692 Example 694 7.4. SMTP Error Extension 696 Although this document focuses on SMTP Submission, it is possible to 697 use security latches for SMTP transport as well. When MTA transport 698 fails due to a security latch, the MTA MUST use the SMTP enhanced 699 status code X.7.TBD. The SMTP notary response [RFC3464] for a 700 security latch failure MUST include an additional "SMTP-Security- 701 Latch" recipient-specific header field that includes a space- 702 delimited list including one or more security latch that failed. The 703 ABNF for this new field follows: 705 CFWS = 707 FWS = 709 smtp-security-latch = "SMTP-Security-Latch:" CFWS 710 security-tag *(FWS security-tag) 712 8. Use of SRV records in Establishing Configuration 714 This section updates [RFC6186] by changing the preference rules and 715 adding a new SRV service label _submissions._tcp to refer to Message 716 Submission with implicit TLS. 718 User-configurable MUAs SHOULD support use of [RFC6186] for account 719 setup. However, when using configuration information obtained by 720 this method, MUAs SHOULD default to a high privacy assurance level, 721 unless the user has explicitly requested reduced privacy. This will 722 have the effect of causing the MUA to ignore advertised 723 configurations which do not support TLS, even when those advertised 724 configurations have a higher priority than other advertised 725 configurations. 727 When using [RFC6186] configuration information, Mail User Agents 728 SHOULD NOT automatically establish new configurations that do not 729 require TLS for all servers, unless there are no advertised 730 configurations using TLS. If such a configuration is chosen, prior 731 to attempting to authenticate to the server or use the server for 732 message submission, the MUA SHOULD warn the user that traffic to that 733 server will not be encrypted and that it will therefore likely be 734 intercepted by unauthorized parties. The specific wording is to be 735 determined by the implementation, but it should adequately capture 736 the sense of risk given the widespread incidence of mass surveillance 737 of email traffic. 739 When establishing a new configuration for connecting to an IMAP, POP, 740 or SMTP Submission server, an MUA SHOULD NOT blindly trust SRV 741 records unless they are signed by DNSSEC and have a valid signature. 742 Instead, the MUA SHOULD warn the user that the DNS-advertised 743 mechanism for connecting to the server is not authenticated, and 744 request the user to manually verify the connection details by 745 reference to his or her mail service provider's documentation. 747 Similarly, an MUA MUST NOT consult SRV records to determine which 748 servers to use on every connection attempt, unless those SRV records 749 are signed by DNSSEC and have a valid signature. However, an MUA MAY 750 consult SRV records from time to time to determine if an MSP's server 751 configuration has changed, and alert the user if it appears that this 752 has happened. This can also serve as a means to encourage users to 753 upgrade their configurations to require TLS if and when their MSPs 754 support it. 756 9. Implementation Requirements 758 This section details requirements for implementations of electronic 759 mail protocol clients and servers. A requirement for a client or 760 server implementation to support a particular feature is not the same 761 thing as a requirement that a client or server running a conforming 762 implementation be configured to use that feature. Requirements for 763 Mail Service Providers (MSPs) are distinct from requirements for 764 protocol implementations, and are listed in a separate section. 766 9.1. All Implementations (Client and Server) 768 These requirements apply to MUAs as well as POP, IMAP and SMTP 769 Submission servers. 771 o All implementations MUST be configurable to support implicit TLS 772 using the TLS 1.2 protocol or later [RFC5246] including support 773 for the mandatory-to-implement TLS 1.2 cipher suite 774 TLS_RSA_WITH_AES_128_CBC_SHA. 776 o IMAP implementations MUST support the IMAP4rev1 mandatory-to- 777 implement cipher suite TLS_RSA_WITH_RC4_128_MD5 for any 778 connections made or received via IMAP although this MAY be 779 disabled by default. 781 o All implementations MUST be configurable to require TLS before 782 performing any operation other than capability discovery and 783 STARTTLS. 785 9.1.1. Client Certificate Authentication 787 MUAs and mail servers MAY implement client certificate authentication 788 on the implicit TLS port. Servers MUST NOT request a client 789 certificate during the TLS handshake unless the server is configured 790 to accept some client certificates as sufficient for authentication 791 and the server has the ability to determine a mail server 792 authorization identity matching such certificates. How to make this 793 determination is presently implementation specific. Clients MUST NOT 794 provide a client certificate during the TLS handshake unless the 795 server requests one and the client has determined the certificate can 796 be safely used with that specific server, OR the client has been 797 explicitly configured by the user to use that particular certificate 798 with that server. How to make this determination is presently 799 implementation specific. If the server accepts the client's 800 certificate as sufficient for authorization, it MUST enable the SASL 801 EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH 802 greeting instead of enabling SASL EXTERNAL. A client supporting 803 client certificate authentication with implicit TLS MUST implement 804 the SASL EXTERNAL [RFC4422] mechanism using the appropriate 805 authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP 806 Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]). 808 9.2. Mail Server Implementation Requirements 810 These requirements apply to servers that implement POP, IMAP or SMTP 811 Submission. 813 o Servers MUST implement the DEEP extension described in Section 7 815 o IMAP and SMTP submission servers SHOULD implement and be 816 configurable to support STARTTLS. This enables discovery of new 817 TLS availability, and can increase usage of TLS by legacy clients. 819 o Servers MUST NOT advertise STARTTLS if it is unlikely to succeed 820 based on server configuration (e.g., there is no server 821 certificate installed). 823 o SMTP message submission servers that have negotiated TLS SHOULD 824 add a Received header field to the message including the tls 825 clause described in Section 6. 827 o Servers MUST be configurable to include the TLS cipher information 828 in any connection or user logging or auditing facility they 829 provide. 831 9.3. Mail User Agent Implementation Requirements 833 This section describes requirements on Mail User Agents (MUAs) using 834 IMAP, POP, and/or Submission protocols. Note: Requirements 835 pertaining to use of Submission servers are also applicable to use of 836 SMTP servers (e.g., port 25) for mail submission. 838 o User agents SHOULD indicate at configuration time, the expected 839 level of privacy based on appropriate security inputs such as 840 which security latches are pre-set, the number of trust anchors, 841 certificate validity, use of an extended validation certificate, 842 TLS version supported, and TLS cipher suites supported by both 843 server and client. 845 o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes 846 available for a protocol and set the tls10 latch if the server 847 advertises that latch. 849 o Whenever requested to establish any configuration that does not 850 require both TLS and server certificate verification to talk to a 851 server or account, an MUA SHOULD warn its user that his or her 852 mail traffic (including password, if applicable) will be exposed 853 to attackers, and give the user an opportunity to abort the 854 connection prior to transmission of any such password or traffic. 856 o MUAs SHOULD implement the "tls12" security latch (the TLS library 857 has to provide an API that controls permissible TLS versions and 858 communicates the negotiated TLS protocol version to the 859 application for this to be possible). 861 o See Section 3 for additional requirements. 863 9.4. Non-configurable MUAs and nonstandard access protocols 865 MUAs which are not configurable to use user-specified servers MUST 866 implement TLS or similarly other strong encryption mechanism when 867 communicating with their mail servers. This generally applies to 868 MUAs that are pre-configured to operate with one or more specific 869 services, whether or not supplied by the vendor of those services. 871 MUAs using protocols other than IMAP, POP, and Submission to 872 communicate with mail servers, MUST implement TLS or other similarly 873 robust encryption mechanism in conjunction with those protocols. 875 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 877 There are multiple ways to connect an Anti-Virus and/or Anti-Spam 878 (AVAS) service to a mail server. Some mechanisms, such as the de- 879 facto milter protocol do not impact DEEP. However, some services use 880 an SMTP relay proxy that intercepts mail at the application layer to 881 perform a scan and proxy to the real MTA. Deploying AVAS services in 882 this way can cause many problems [RFC2979] including direct 883 interference with DEEP and privacy reduction. An AVAS product or 884 service is considered DEEP compliant if all IMAP, POP and SMTP- 885 related software it includes is DEEP compliant and it advertises all 886 security latches that the actual MTA advertises. 888 10. Mail Service Provider Requirements 890 This section details requirements for providers of IMAP, POP, and/or 891 SMTP submission services, for providers who claim to conform to this 892 specification. 894 10.1. Server Requirements 896 Mail Service Providers MUST use server implementations that conform 897 to this specification. 899 10.2. MSPs MUST provide Submission Servers 901 This document updates the advice in [RFC5068] by making Implicit TLS 902 on port 465 the preferred submission port. 904 Mail Service Providers that accept mail submissions from end-users 905 using the Internet Protocol MUST provide one or more SMTP Submission 906 servers for this purpose, separate from the SMTP servers used to 907 process incoming mail. Those submission servers MUST be configured 908 to support Implicit TLS on port 465 and SHOULD support STARTTLS if 909 port 587 is used. 911 MSPs MAY also support submission of messages via one or more 912 designated SMTP servers to facilitate compatibility with legacy MUAs. 914 Discussion: SMTP servers used to accept incoming mail or to relay 915 mail are expected to accept mail in cleartext. This is incompatible 916 with the purpose of this memo which is to encourage encryption of 917 traffic between mail servers. There is no such requirement for mail 918 submission servers to accept mail in cleartext or without 919 authentication. For other reasons, use of separate SMTP submission 920 servers has been best practice for many years. 922 10.3. TLS Server Certificate Requirements 924 MSPs MUST maintain valid server certificates for all servers. Those 925 server certificates SHOULD present DNS-IDs and SRV-IDs conforming to 926 [RFC6125] and which will be recognized by MUAs meeting the 927 requirements of that specification. In addition, those server 928 certificates MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for 929 compatibility with existing MUAs. 931 If a protocol server provides service for more than one mail domain, 932 it MAY use a separate IP address for each domain and/or a server 933 certificates that advertises multiple domains. This will generally 934 be necessary unless and until it is acceptable to impose the 935 constraint that the server and all clients support the Server Name 936 Indication extension to TLS [RFC6066]. 938 10.4. Recommended DNS records for mail protocol servers 940 This section discusses not only the DNS records that are recommended, 941 but also implications of DNS records for server configuration and TLS 942 server certificates. 944 10.4.1. MX records 946 It is recommended that MSPs advertise MX records for handling of 947 inbound mail (instead of relying entirely on A or AAAA records), and 948 that those MX records be signed using DNSSEC. This is mentioned here 949 only for completeness, as handling of inbound mail is out of scope 950 for this document. 952 10.4.2. SRV records 954 MSPs SHOULD advertise SRV records to aid MUAs in determination of 955 proper configuration of servers, per the instructions in [RFC6186]. 957 MSPs SHOULD advertise servers that support Implicit TLS in preference 958 to those which support cleartext and/or STARTTLS operation. 960 10.4.3. TLSA records 962 MSPs SHOULD advertise TLSA records to provide an additional trust 963 anchor for public keys used in TLS server certificates. However, 964 TLSA records MUST NOT be advertised unless they are signed using 965 DNSSEC. 967 10.4.4. DNSSEC 969 All DNS records advertised by an MSP as a means of aiding clients in 970 communicating with the MSP's servers, SHOULD be signed using DNSSEC. 972 10.5. MSP Server Monitoring 974 MSPs SHOULD regularly and frequently monitor their various servers to 975 make sure that: TLS server certificates remain valid and are not 976 about to expire, TLSA records match the public keys advertised in 977 server certificates, are signed using DNSSEC, server configurations 978 are consistent with SRV advertisements, and DNSSEC signatures are 979 valid and verifiable. Failure to detect expired certificates and DNS 980 configuration errors in a timely fashion can result in significant 981 loss of service for an MSP's users and a significant support burden 982 for the MSP. 984 10.6. Advertisement of DEEP status 986 MSPs SHOULD advertise a DEEP status that includes tls10, tls-cert and 987 an HTTPS URL that can be used to inform clients of service outages or 988 problems impacting client privacy. Note that advertising tls-cert is 989 a commitment to maintain and renew server certificates. 991 10.7. Require TLS 993 New servers and services SHOULD be configured to require TLS unless 994 it's necessary to support legacy clients or existing client 995 configurations. 997 11. IANA Considerations 999 11.1. Security Tag Registry 1001 IANA shall create (has created) the registry "Email Security Tags". 1002 This registry is a single table and will use an expert review process 1003 [RFC5226]. Each registration will contain the following fields: 1005 Name: The name of the security tag. This follows the security-tag 1006 ABNF. 1008 Description: This describes the meaning of the security tag and the 1009 conditions under which the tag is latched. 1011 Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. 1013 Reference: Optional reference to specification. 1015 Submitter: The identify of the submitter or submitters. 1017 Change Controller: The identity of the change controller for the 1018 registration. This will be "IESG" in case of registrations in 1019 IETF-produced documents. 1021 The expert reviewer will verify the tag name follows the ABNF, and 1022 that the description field is clear, unambiguous, does not overlap 1023 existing deployed technology, does not create security or privacy 1024 problems and appropriately considers interoperability issues. Email 1025 security tags intended for LIMITED USE have a lower review bar 1026 (interoperability and overlap issues are less of a concern). The 1027 reviewer may approve a registration, reject for a stated reason or 1028 recommend the proposal have standards track review due to importance 1029 or difficult subtleties. 1031 Standards-track registrations may be updated if the relevant 1032 standards are updated as a consequence of that action. Non- 1033 standards-track entries may be updated by the listed change 1034 controller. The entry's name and submitter may not be changed. In 1035 exceptional cases, any aspect of any registered entity may be updated 1036 at the direction of the IESG (for example, to correct a conflict). 1038 11.2. Initial Set of Security Tags 1040 This document defines four initial security tags for the security tag 1041 registry as follows: 1043 Name: tls10 1045 Description: This indicates TLS version 1.0 [RFC2246] or later was 1046 negotiated successfully including negotiation of a strong 1047 encryption layer with a symmetric key of at least 128 bits. This 1048 tag does not indicate the server certificate was valid. This tag 1049 is latched if the client sees this tag in the advertised server 1050 DEEP status provided after successfully negotiating TLS version 1051 1.0 or later. 1053 Intended Usage: COMMON 1055 Reference: RFC XXXX (this document once published) 1057 Submitter: Authors of this document 1059 Change Controller: IESG 1061 Name: tls12 1063 Description: This indicates TLS version 1.2 [RFC5246] or later was 1064 negotiated successfully including negotiation of a strong 1065 encryption layer with a symmetric key of at least 128 bits. This 1066 tag does not indicate the server certificate was valid. This tag 1067 is latched if the client sees this tag in the advertised server 1068 DEEP status provided after successfully negotiating TLS version 1069 1.2 or later. 1071 Intended Usage: COMMON 1073 Reference: RFC XXXX (this document once published) 1075 Submitter: Authors of this document 1077 Change Controller: IESG 1079 Name: tls-cert 1081 Description: This tag indicates that TLS was successfully negotiated 1082 and the server certificate was successfully verified by the client 1083 using PKIX [RFC5280] and the server certificate identity was 1084 verified using the algorithm appropriate for the protocol (see 1085 Section 4). This tag is latched if the client sees this tag in 1086 the advertised server DEEP status after successfully negotiating 1087 TLS and verifying the certificate and server identity. 1089 Intended Usage: COMMON 1091 Reference: RFC XXXX (this document once published) 1093 Submitter: Authors of this document 1095 Change Controller: IESG 1096 Name: tls-dane-tlsa 1098 Description: This tag indicates that TLS was successfully negotiated 1099 and the server certificate was successfully verified by the client 1100 using the procedures described in [RFC6698] and the server 1101 certificate identity was verified using the algorithm appropriate 1102 for the protocol (see Section 4). This tag is latched if the 1103 client sees this tag in the advertised server DEEP status after 1104 successfully negotiating TLS and verifying the certificate and 1105 server identity. 1107 Intended Usage: COMMON 1109 Reference: RFC XXXX (this document once published) 1111 Submitter: Authors of this document 1113 Change Controller: IESG 1115 11.3. POP3S Port Registration Update 1117 IANA is asked to update the registration of the TCP well-known port 1118 995 using the following template ([RFC6335]): 1120 Service Name: pop3s 1121 Transport Protocol: TCP 1122 Assignee: IETF 1123 Contact: IESG 1124 Description: POP3 over TLS protocol 1125 Reference: RFC XXXX (this document once published) 1127 Service Name: pop3s 1128 Transport Protocol: TCP 1129 Assignee: IETF 1130 Contact: IESG 1131 Description: POP3 over TLS protocol 1132 Reference: RFC XXXX (this document once published) 1134 11.4. IMAPS Port Registration Update 1136 IANA is asked to update the registration of the TCP well-known port 1137 993 using the following template ([RFC6335]): 1139 Service Name: imaps 1140 Transport Protocol: TCP 1141 Assignee: IETF 1142 Contact: IESG 1143 Description: IMAP over TLS protocol 1144 Reference: RFC XXXX (this document once published) 1146 Service Name: imaps 1147 Transport Protocol: TCP 1148 Assignee: IETF 1149 Contact: IESG 1150 Description: IMAP over TLS protocol 1151 Reference: RFC XXXX (this document once published) 1153 11.5. Submissions Port Registration 1155 IANA is asked to assign an alternate usage of port 465 in addition to 1156 the current assignment using the following template ([RFC6335]): 1158 Service Name: submissions 1159 Transport Protocol: TCP 1160 Assignee: IETF 1161 Contact: IESG 1162 Description: Message Submission over TLS protocol 1163 Reference: RFC XXXX (this document once published) 1165 Service Name: submissions 1166 Transport Protocol: TCP 1167 Assignee: IETF 1168 Contact: IESG 1169 Description: Message Submission over TLS protocol 1170 Reference: RFC XXXX (this document once published) 1172 This is a one time procedural exception to the rules in RFC 6335. 1173 This requires explicit IESG approval and does not set a precedent. 1174 Historically, port 465 was briefly registered as the "smtps" port. 1175 This registration made no sense as the SMTP transport MX 1176 infrastructure has no way to specify a port so port 25 is always 1177 used. As a result, the registration was revoked and was subsequently 1178 reassigned to a different service. In hindsight, the "smtps" 1179 registration should have been renamed or reserved rather than 1180 revoked. Unfortunately, some widely deployed mail software 1181 interpreted "smtps" as "submissions" [RFC6409] and used that port for 1182 email submission by default when an end-user requests security during 1183 account setup. If a new port is assigned for the submissions 1184 service, email software will either continue with unregistered use of 1185 port 465 (leaving the port registry inaccurate relative to de-facto 1186 practice and wasting a well-known port), or confusion between the de- 1187 facto and registered ports will cause harmful interoperability 1188 problems that will deter use of TLS for message submission. The 1189 authors believe both of these outcomes are less desirable than a wart 1190 in the registry documenting real-world usage of a port for two 1191 purposes. Although STARTTLS-on-port-587 has deployed, it has not 1192 replaced deployed use of implicit TLS submission on port 465. 1194 11.6. DEEP IMAP Capability 1196 This document adds the DEEP capability to the IMAP capabilities 1197 registry. This is described in Section 7.1. 1199 11.7. DEEP POP3 Capability 1201 This document adds the DEEP capability to the POP3 capabilities 1202 registry. 1204 CAPA Tag: DEEP 1206 Arguments: deep-status 1208 Added Commands: none 1210 Standard Commands affected: none 1212 Announced status / possible differences: both / may change after 1213 STLS 1215 Commands Valid in States: N/A 1217 Specification Reference: This document 1219 Discussion: See Section 7.2. 1221 11.8. DEEP SMTP EHLO Keyword 1223 This document adds the DEEP EHLO Keyword to the SMTP Service 1224 Extension registry. This is described in Section 7.3. 1226 11.9. SMTP Enhanced Status Code 1228 This document adds the following entry to the "SMTP Enhanced Status 1229 Codes" registry created by [RFC5248]. 1231 Code: X.7.TBD (IANA, please assign the next available number) 1233 Sample Text: Message Transport Failed due to missing required 1234 security. 1236 Associated Basic Status Code: 450, 454, 550, 554 1237 Description This code indicates an SMTP server was unable to forward 1238 a message to the next host necessary for delivery because it 1239 required a higher level of transport security or privacy than was 1240 available. The temporary form of this error is preferred in case 1241 the problem is caused by a temporary administrative error such as 1242 an expired server certificate. 1244 Reference This document 1246 Submitter C. Newman 1248 Change Controller IESG 1250 11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 1252 This document adds the following entry to the "Additional-registered- 1253 clauses" sub-registry of the "MAIL Parameters" registry, created by 1254 [RFC5321]: 1256 Clause Name: tls 1258 Description: Indicates the TLS cipher suite used for a transport 1259 connection. 1261 Syntax Summary: See tls-cipher ABNF Section 6 1263 Reference: This document. 1265 12. Security Considerations 1267 This entire document is about security considerations. In general, 1268 this is targeted to improve mail privacy and to mitigate threats 1269 external to the email system such as network-level snooping or 1270 interception; this is not intended to mitigate active attackers who 1271 have compromised service provider systems. 1273 It could be argued that sharing the name and version of the client 1274 software with the server has privacy implications. Although 1275 providing this information is not required, it is encouraged so that 1276 mail service providers can more effectively inform end-users running 1277 old clients that they need to upgrade to protect their privacy, or 1278 know which clients to use in a test deployment prior to upgrading a 1279 server to have higher security requirements. 1281 13. References 1282 13.1. Normative References 1284 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1285 STD 53, RFC 1939, May 1996. 1287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1288 Requirement Levels", BCP 14, RFC 2119, March 1997. 1290 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 1291 Mechanism", RFC 2449, November 1998. 1293 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1295 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, 1296 October 2000. 1298 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1299 Transport Layer Security", RFC 3207, February 2002. 1301 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1302 4rev1", RFC 3501, March 2003. 1304 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1305 for Delivery Status Notifications", RFC 3464, 1306 January 2003. 1308 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1309 Resource Identifier (URI): Generic Syntax", STD 66, 1310 RFC 3986, January 2005. 1312 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol 1313 (POP3) Simple Authentication and Security Layer (SASL) 1314 Authentication Mechanism", RFC 5034, July 2007. 1316 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1317 Finch, "Email Submission Operations: Access and 1318 Accountability Requirements", BCP 134, RFC 5068, 1319 November 2007. 1321 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1322 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1324 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1325 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1327 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1328 Mail System Status Codes", BCP 138, RFC 5248, June 2008. 1330 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1331 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1332 May 2008. 1334 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1335 Housley, R., and W. Polk, "Internet X.509 Public Key 1336 Infrastructure Certificate and Certificate Revocation List 1337 (CRL) Profile", RFC 5280, May 2008. 1339 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1340 October 2008. 1342 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1343 October 2008. 1345 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1346 Verification of Domain-Based Application Service Identity 1347 within Internet Public Key Infrastructure Using X.509 1348 (PKIX) Certificates in the Context of Transport Layer 1349 Security (TLS)", RFC 6125, March 2011. 1351 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1352 Submission/Access Services", RFC 6186, March 2011. 1354 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1355 STD 72, RFC 6409, November 2011. 1357 [I-D.melnikov-email-tls-certs] 1358 Melnikov, A., "Updated TLS Server Identity Check Procedure 1359 for Email Related Protocols", 1360 draft-melnikov-email-tls-certs-01 (work in progress), 1361 October 2013. 1363 [I-D.ietf-dane-smtp-with-dane] 1364 Dukhovni, V. and W. Hardaker, "SMTP security via 1365 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02 1366 (work in progress), October 2013. 1368 13.2. Informative References 1370 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1371 RFC 2246, January 1999. 1373 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1374 RFC 2595, June 1999. 1376 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1377 Firewalls", RFC 2979, October 2000. 1379 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 1380 Registration", RFC 3848, July 2004. 1382 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 1383 September 2004. 1385 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1386 Security Layer (SASL)", RFC 4422, June 2006. 1388 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1389 for Authentication", RFC 4954, July 2007. 1391 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1392 July 2009. 1394 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1395 "Salted Challenge Response Authentication Mechanism 1396 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 1398 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 1399 Managing Sieve Scripts", RFC 5804, July 2010. 1401 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1402 Extension Definitions", RFC 6066, January 2011. 1404 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1405 Cheshire, "Internet Assigned Numbers Authority (IANA) 1406 Procedures for the Management of the Service Name and 1407 Transport Protocol Port Number Registry", BCP 165, 1408 RFC 6335, August 2011. 1410 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1411 of Named Entities (DANE) Transport Layer Security (TLS) 1412 Protocol: TLSA", RFC 6698, August 2012. 1414 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1415 Transport Security (HSTS)", RFC 6797, November 2012. 1417 Appendix A. Design Considerations 1419 This section is not normative. 1421 The first version of this was written independently from 1422 draft-moore-email-tls-00.txt; subsequent versions merge ideas from 1423 both drafts. 1425 One author of this document was also the author of RFC 2595 that 1426 became the standard for TLS usage with POP and IMAP, and the other 1427 author was perhaps the first to propose that idea. In hindsight both 1428 authors now believe that that approach was a mistake. At this point 1429 the authors believe that while anything that makes it easier to 1430 deploy TLS is good, the desirable end state is that these protocols 1431 always use TLS, leaving no need for a separate port for cleartext 1432 operation except to support legacy clients while they continue to be 1433 used. The separate port model for TLS is inherently simpler to 1434 implement, debug and deploy. It also enables a "generic TLS load- 1435 balancer" that accepts secure client connections for arbitrary foo- 1436 over-TLS protocols and forwards them to a server that may or may not 1437 support TLS. Such load-balancers cause many problems because they 1438 violate the end-to-end principle and the server loses the ability to 1439 log security-relevant information about the client unless the 1440 protocol is designed to forward that information (as this 1441 specification does for the cipher suite). However, they can result 1442 in TLS deployment where it would not otherwise happen which is a 1443 sufficiently important goal that it overrides the problems. 1445 Although STARTTLS appears only slightly more complex than separate- 1446 port TLS, we again learned the lesson that complexity is the enemy of 1447 security in the form of the STARTTLS command injection vulnerability 1448 (CERT vulnerability ID #555316). Although there's nothing inherently 1449 wrong with STARTTLS, the fact it resulted in a common implementation 1450 error (made independently by multiple implementers) suggests it is a 1451 less secure architecture than Implicit TLS. 1453 Section 7 of RFC 2595 critiques the separate-port approach to TLS. 1454 The first bullet was a correct critique. There are proposals in the 1455 http community to address that, and use of SRV records as described 1456 in RFC 6186 resolves that critique for email. The second bullet is 1457 correct as well, but not very important because useful deployment of 1458 security layers other than TLS in email is small enough to be 1459 effectively irrelevant. The third bullet is incorrect because it 1460 misses the desirable option of "use and latch-on TLS if available". 1461 The fourth bullet may be correct, but is not a problem yet with 1462 current port consumption rates. The fundamental error was 1463 prioritizing a perceived better design based on a mostly valid 1464 critique over real-world deployability. But getting security and 1465 privacy facilities actually deployed is so important it should trump 1466 design purity considerations. 1468 Appendix B. Open Issues 1470 There are many open issues with this document. Here is an attempt to 1471 enumerate some of them: 1473 o Port 465 is presently used for two purposes: for submissions by a 1474 large number of clients and service providers and for the "urd" 1475 protocol by one vendor. Actually documenting this current state 1476 is controversial as discussed in the IANA considerations section. 1477 However, there is no good alternative. Registering a new port for 1478 submissions when port 465 is widely used for that purpose already 1479 will just create interoperability problems. Registering a port 1480 that's only used if advertised by an SRV record (RFC 6186) would 1481 not create interoperability problems but would require all client 1482 and server deployments and software to change significantly which 1483 is contrary to the goal of promoting more TLS use. Encouraging 1484 use of STARTTLS on port 587 would not create interoperability 1485 problems, but is unlikely to have impact on current undocumented 1486 use of port 465 and makes the guidance in this document less 1487 consistent. 1489 o Discussion of pinning certificates is new and may be inadequate. 1490 Suggestions to improve the text are welcome. 1492 o This document should reference draft-ietf-uta-tls-bcp and possibly 1493 other guidance documents. Suggested text on where/how to 1494 reference this and possibly other TLS guidance (e.g., must 1495 staple). would be welcome. 1497 o One author believes that the security latch model is complementary 1498 with draft-ietf-dane-smtp-with-dane-02 but hasn't thought about 1499 the issues in depth. We welcome feedback on this point. 1501 o The three involved authors are willing to merge 1502 draft-melnikov-email-tls-certs into this document. However, this 1503 will take time so we are only willing to do so if there is rough 1504 consensus on the decision (so it's a one time action) and doing so 1505 will not significantly delay publication. 1507 o It might make sense to split this in two or more documents if it's 1508 getting too long to evaluate in one IETF last call. In 1509 particular, it might make sense to put implementation requirements 1510 and service provider requirements in separate documents. The 1511 authors prefer to edit one document for now and defer discussion 1512 of splitting the document until all technical issues are resolved. 1514 o The use of SRV records [RFC6186] for account setup or refresh is 1515 presently not secure from DNS active attacks unless DNSSEC is 1516 used. As this document is now focusing on MUA security/privacy, 1517 discussing how to do SRV record account setup or account refresh 1518 securely, probably using DANE, would be in scope for this 1519 document. It has been suggested that we add this. 1521 o This document does not cover use of TLS with SMTP relay. 1523 Appendix C. Change Log 1525 Changes since -01: 1527 o Updated abstract, introduction and document structure to focus 1528 more on mail user agent privacy assurance. 1530 o Added email account privacy section, also moving section on 1531 account setup using SRV records to that section. 1533 o Finished writing IANA considerations section 1535 o Remove provisional concept and instead have server explicitly list 1536 security tags clients should latch. 1538 o Added note that rules for the submissions port follow the same 1539 rules as those for the submit port. 1541 o Reference and update advice in [RFC5068]. 1543 o Fixed typo in Client Certificate Authentication section. 1545 o Removed tls-pfs security latch and all mention of perfect forward 1546 secrecy as it was controversial. 1548 o Added reference to HSTS. 1550 Changes since -00: 1552 o Rewrote introduction to merge ideas from draft-moore-email-tls-00. 1554 o Added Implicit TLS section, Account configuration section and IANA 1555 port registration updates based on draft-moore-email-tls-00. 1557 o Add protocol details necessary to standardize implicit TLS for 1558 POP/IMAP/submission, using ideas from 1559 draft-melnikov-pop3-over-tls. 1561 o Reduce initial set of security tags based on feedback. 1563 o Add deep status concept to allow a window for software updates to 1564 be backed out before latches make that problematic, as well as to 1565 provide service providers with a mechanism they can use to assist 1566 customers in the event of a privacy failure. 1568 o Add DNS SRV section from draft-moore-email-tls-00. 1570 o Write most of the missing IANA considerations section. 1572 o Rewrite most of implementation requirements section based more on 1573 draft-moore-email-tls-00. Remove new cipher requirements for now 1574 because those may be dealt with elsewhere. 1576 Appendix D. Acknowledgements 1578 Many thanks to Ned Freed for discussion of the initial latch concepts 1579 in this document. Thanks to Alexey Melnikov for 1580 draft-melnikov-pop3-over-tls-02, which was the basis of the POP3 1581 implicit TLS text. Thanks to Dan Newman and Alexey Melnikov for 1582 review feedback. Thanks to Paul Hoffman for interesting feedback in 1583 initial conversations about this idea. 1585 Authors' Addresses 1587 Keith Moore 1588 Network Heretics 1589 PO Box 1934 1590 Knoxville, TN 37901 1591 US 1593 Email: moore@network-heretics.com 1595 Chris Newman 1596 Oracle 1597 440 E. Huntington Dr., Suite 400 1598 Arcadia, CA 91006 1599 US 1601 Email: chris.newman@oracle.com