idnits 2.17.1 draft-ietf-uta-email-deep-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 RFC6186, 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 (February 13, 2015) is 3357 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 (==), 9 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, 6186 C. Newman 5 (if approved) Oracle 6 Intended status: Standards Track February 13, 2015 7 Expires: August 17, 2015 9 Deployable Enhanced Email Privacy (DEEP) 10 draft-ietf-uta-email-deep-00.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 agent's confidentiality 18 assurance, and enable mail service providers to advertise improved 19 TLS privacy 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 August 17, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 2. Conventions and Terminology Used in This Document . . . . . . 4 57 3. Mail Account Confidentiality Assurance Level . . . . . . . . 4 58 3.1. High Confidentiality Assurance . . . . . . . . . . . . . 5 59 3.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 6 60 3.3. No Confidentiality Assurance . . . . . . . . . . . . . . 6 61 3.4. Other Confidentiality Assurance Levels . . . . . . . . . 6 62 4. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . 7 64 4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . 8 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 . . . . . . . . . . . . 10 72 6. Recording TLS Cipher Suite in Received Header . . . . . . . . 11 73 7. Extensions for DEEP Status and Reporting . . . . . . . . . . 11 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 96 10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . 22 97 10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 22 98 10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . 22 99 10.8. Changes to Internet Facing Servers . . . . . . . . . . . 22 100 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 101 11.1. Security Tag Registry . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . 26 107 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 26 108 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 27 109 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . 27 110 11.10. MAIL Parameters Additional-registered-clauses Sub- 111 Registry . . . . . . . . . . . . . . . . . . . . . . . . 27 112 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 115 13.2. Informative References . . . . . . . . . . . . . . . . . 30 116 Appendix A. Design Considerations . . . . . . . . . . . . . . . 31 117 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 32 118 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 33 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] and/ 126 or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually 127 has Transport Layer Security (TLS) [RFC5246] support but often does 128 not use it in a way that maximizes end-user confidentiality. This 129 specification proposes changes to email software and deployments 130 intended to increase the use of TLS and record when that use occurs. 132 In brief, this memo now recommends that: 134 o MUAs associate a confidentiality assurance level with each mail 135 account, and the default level requires use of TLS with 136 certificate 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 Confidentiality Assurance Level 175 A "mail account" refers to the network services an end user uses to 176 read, submit and manage email communications on the Internet. This 177 typically involves at least one mail access server (IMAP or POP) and 178 at least one SMTP submission server. An end users uses a mail user 179 agent (MUA) to access a mail account and most MUAs support one or 180 more mail accounts. This document uses the term "confidentiality 181 assurance level" to indicate the degree to which the network 182 connections between an MUA and a mail account have confidentiality 183 protection from both passive and active attackers on the network. 185 The configuration necessary for a mail account includes an email 186 address, connection information and authentication credentials for 187 network services. MUAs compliant with this specification MUST also 188 associate a confidentiality assurance level with each mail account. 189 MUAs MUST implement a high confidentiality assurance level as 190 described in the next section. 192 MUAs SHOULD continuously indicate to the user the confidentiality 193 assurance level of the account currently in use when reading, 194 submitting and managing mail (e.g., via a lock icon, background 195 colors and indications similar to those commonly used in web browsers 196 for a similar purpose) and SHOULD indicate the confidentiality 197 assurance level for each account whenever displaying a list of mail 198 accounts. Note that the displayed confidentiality assurance level 199 could be higher than the level set at account configuration but never 200 lower. If multiple active connections are associated with an account 201 or view, the indication should match the level provided by the least 202 confidential connection. 204 Account configuration occurs when an MUA is first used to access a 205 particular service, when a user wishes to access or submit mail 206 through servers in addition to those specified or found during first 207 use, or when a user explicitly requests to change account 208 configuration parameters such as server names, user names, passwords, 209 client certificates, etc. Account configuration can be entirely 210 manual (entering server names explicitly) or partially automated via 211 a mechanism such as DNS SRV records [RFC6186]. MUAs SHOULD use the 212 high confidentiality assurance level as the default for newly 213 configured accounts. 215 3.1. High Confidentiality Assurance 217 A mail account has a high confidentiality assurance when the 218 following conditions are met on all TCP server connections associated 219 with an account. This includes connections to POP, IMAP and SMTP 220 submission servers as well as any other associated protocols defined 221 now or in the future. Examples of protocols associated with a mail 222 account include managesieve [RFC5804] and MTQP [RFC3887]. 224 o TCP connections MUST attempt to negotiate TLS via either Implicit 225 TLS Section 4 or STARTTLS. 227 o MUAs MUST implement [I-D.melnikov-email-tls-certs] and PKIX 228 [RFC5280]. 230 o MUAs MAY implement DANE [RFC6698]. 232 o User agents MUST abort a TLS session if the TLS negotiation fails 233 or the server's certificate or identity fails to verify. A user 234 may reconfigure the account to lower the expected level of 235 confidentiality if he/she chooses. Reduction of expected account 236 confidentiality MUST NOT be done on a click-through basis. 238 The end user is part of the system that protects the user's privacy 239 and security. As a result, it's critical not to present the end user 240 with a simple action that reduces their privacy in response to 241 certificate validation failure. An MUA which offers a user actions 242 such as "connect anyway", "trust certificate for future connections" 243 or "lower confidentiality assurance for this account" in response to 244 certificate validation failure is not providing a high 245 confidentiality assurance as defined in this section and thus does 246 not comply with this document. Examples of acceptable actions to 247 offer would be "work offline", "try again later", and "open service 248 provider status web page". 250 3.2. Certificate Pinning 252 MUAs MAY implement certificate pinning as part of account setup, but 253 MUST NOT offer this as an option in response to a failed certificate 254 validation for an existing account. Certificate pinning occurs when 255 the user agent saves a server certificate with the account settings 256 and trusts that certificate for subsequent connections to that 257 server. An MUA that allows certificate pinning MUST NOT allow a 258 certificate pinned for one account to validate connections for other 259 accounts. 261 A pinned certificate is subject to a man-in-the-middle attack at 262 account setup time, and lacks a mechanism to revoke or securely 263 refresh the certificate. Therefore use of a pinned certificate does 264 not provide a high confidentiality assurance and an MUA MUST NOT 265 indicate a high level for an account or connection using a pinned 266 certificate. 268 3.3. No Confidentiality Assurance 270 MUAs MAY implement a no confidentiality assurance level for accounts. 271 At this level, the MUA MUST attempt to negotiate TLS, but MAY ignore 272 server certificate validation failures. MUAs MAY support use of 273 connections without TLS, but if they do they SHOULD attempt TLS first 274 if available and MUST implement code to reconnect without TLS if TLS 275 negotiation fails for reasons other than server certificate validity. 277 Note that if the TLS certificate is not successfully validated as 278 described in Section 3.1 or a version of SSL/TLS prior to TLS 1.0 is 279 used, the client MUST NOT present a high confidentiality indication 280 for the account or connection. 282 3.4. Other Confidentiality Assurance Levels 284 This specification is not intended to limit experimentation and 285 innovation with respect to user privacy. As a result more 286 confidentiality assurance levels are permitted. However, levels 287 below "no confidentiality assurance" described in the previous 288 section are discouraged and implementers are cautioned that end users 289 may be confused by too many confidentiality assurance levels. 291 4. Implicit TLS 293 Previous standards for use of email protocols with TLS used the 294 STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With 295 STARTTLS, the client establishes a clear text application session and 296 determines whether to issue a STARTTLS command based on server 297 capabilities and client configuration. If the client issues a 298 STARTTLS command, a TLS handshake follows that can upgrade the 299 connection. While this mechanism has been deployed, an alternate 300 mechanism where TLS is negotiated immediately at connection start on 301 a separate port (referred to in this document as "Implicit TLS") has 302 been deployed more successfully. To increase use of TLS, this 303 specification recommends use of implicit TLS by new POP, IMAP and 304 SMTP Submission software. 306 4.1. Implicit TLS for POP 308 When a TCP connection is established for the "pop3s" service (default 309 port 995), a TLS handshake begins immediately. Clients MUST 310 implement the certificate validation mechanism described in 311 [I-D.melnikov-email-tls-certs]. Once the TLS session is established, 312 POP3 [RFC1939] protocol messages are exchanged as TLS application 313 data for the remainder of the TCP connection. After the server sends 314 a +OK greeting, the server and client MUST enter AUTHORIZATION state, 315 even if client credentials were supplied during the TLS handshake. 317 See Section 9.1.1 for additional information on client certificate 318 authentication. See Section 11.3 for port registration information. 320 4.2. Implicit TLS for IMAP 322 When a TCP connection is established for the "imaps" service (default 323 port 993), a TLS handshake begins immediately. Clients MUST 324 implement the certificate validation mechanism described in [RFC3501] 325 and SHOULD implement the certificate validation mechanism described 326 in [I-D.melnikov-email-tls-certs]. Once the TLS session is 327 established, IMAP [RFC3501] protocol messages are exchanged as TLS 328 application data for the remainder of the TCP connection. If client 329 credentials were provided during the TLS handshake that the server 330 finds acceptable, the server MAY issue a PREAUTH greeting in which 331 case both the server and client enter AUTHENTICATED state. If the 332 server issues an OK greeting then both server and client enter NOT 333 AUTHENTICATED state. 335 See Section 9.1.1 for additional information on client certificate 336 authentication. See Section 11.4 for port registration information. 338 4.3. Implicit TLS for SMTP Submission 340 When a TCP connection is established for the "submissions" service 341 (default port 465), a TLS handshake begins immediately. Clients MUST 342 implement the certificate validation mechanism described in 343 [I-D.melnikov-email-tls-certs]. Once a TLS session is established, 344 message submission protocol data [RFC6409] is exchanged as TLS 345 application data for the remainder of the TCP connection. (Note: the 346 "submissions" service name is defined in section 10.3 of this 347 document, and follows the usual convention that the name of a service 348 layered on top of Implicit TLS consists of the name of the service as 349 used without TLS, with an "s" appended.) 351 Note that the submissions port provides access to a Mail Submission 352 Agent (MSA) as defined in [RFC6409] so requirements and 353 recommendations for MSAs in that document apply to the submissions 354 port, including the requirement to implement SMTP AUTH [RFC4954]. 356 See Section 9.1.1 for additional information on client certificate 357 authentication. See Section 11.5 for port registration information. 359 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP 361 When a client or server wishes to close the connection, it SHOULD 362 initiate the exchange of TLS close alerts before TCP connection 363 termination. The client MAY, after sending a TLS close alert, 364 gracefully close the TCP connection without waiting for a TLS 365 response from the server. 367 5. Email Security Upgrading Using Security Latches 369 Once an improved email security or privacy mechanism is deployed and 370 ready for general use, it is desirable to continue using it for all 371 future email service. For example, TLS is widely deployed in email 372 software, but use of TLS is often not required. At the time this is 373 written, deployed mail user agents (MUAs) [RFC5598] usually make a 374 determination if TLS is available when an account is first configured 375 and may require use of TLS with that account if and only if it was 376 initially available. If the service provider makes TLS available 377 after initial client configuration, many MUAs will not notice the 378 change. 380 Alternatively, a security feature may be purely opportunistic and 381 thus subject to downgrade attacks. For example, at the time this was 382 written, most TLS stacks that support TLS 1.2 will use an older TLS 383 version if the peer does not support TLS 1.2 and some do so without 384 alerting the client of the reduced security. Thus a variety of 385 active attacks could cause the loss of TLS 1.2 benefits. Only if 386 client policy is upgraded to require TLS 1.2 can the client prevent 387 all downgrade attacks. However, this sort of security policy upgrade 388 will be ignored by most users unless it is automated. 390 This section describes a mechanism, called "security latches", which 391 is designed to permit an MUA to recognize when a service provider has 392 committed to provide certain server security features, and that it's 393 safe for the client to change its configuration for that account to 394 require that such features be present in future sessions with that 395 server. When an MUA implements both confidentiality assurance levels 396 and security latches, then both the end-user and the service provider 397 independently have the ability to improve the end-user's privacy. 399 Note that security latches are a mechanism similar to HTTP Strict 400 Transport Security (HSTS) [RFC6797] but are extensible. 402 5.1. Email Security Tags 404 Each security latch is given a name known as an email security tag. 405 An email security tag is a short alphanumeric token that represents a 406 security facility that can be used by an IMAP, POP or SMTP Submission 407 session. When a server advertises a security tag it is making a 408 commitment to support that security facility indefinitely and 409 recommending that the client save that security tag with the account 410 configuration and require that security feature for future 411 connections to that server. When a security tag is saved by the 412 client in this way, it is then considered latched. For the "tls10" 413 and/or "tls12" tags, the client SHOULD refuse to connect to the 414 server unless the appropriate level of TLS is successfully 415 negotiated. The client SHOULD NOT latch these two tags until TLS has 416 been successfully negotiated as described in the tag definition. If 417 the tags are advertised within an appropriate TLS-protected 418 connection, the client SHOULD latch these tags. Other security tags 419 are latched if they are advertised by the server, TLS is active and 420 the client successfully authenticates the server with the TLS 421 session. Once a security tag is latched, all subsequent connections 422 to that host require that security feature. For this confidentiality 423 protection to work as desired clients MUST NOT offer a click-through- 424 to-connect action when unable to achieve connection security matching 425 the latched security tags. 427 An identifier for a security tag has the following formal syntax: 429 security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_") 431 5.2. Initial Set of Email Security Tags 433 This section describes an initial set of email security tags. The 434 IANA Considerations Section 11 defines a registry so that more tags 435 can be defined in the future. The initial set of tags are defined in 436 Section 11.2 and include tls10, tls12, tls-cert and tls-dane-tlsa. 438 5.3. Server DEEP Status 440 Servers supporting this extension MUST advertise a DEEP status. This 441 status includes a list of security-tags the server administrator has 442 explicitly configured as recommended for use by end-users (the list 443 MAY be empty), an optional https Uniform Resource Locator (URL) 444 [RFC2818] that the client can save and subsequently resolve for the 445 user in the event of a security connection problem, and the DEEP 446 status can be extended by future updates to this specification. DEEP 447 status has the following formal syntax: 449 EXTCHAR = 0x20-21 / 0x23-2E / 0x30-3B / 0x3D-40 450 / 0x5B-60 / 0x7B-7E 451 ; printable characters excluding " \ < and ALPHA 453 deep-extend = EXTCHAR *(EXTCHAR / ALPHA / "<") 454 ; clients MUST ignore, for future extensibility 456 deep-status = [deep-tag *(SP deep-tag)] 458 deep-tag = deep-https / security-tag / deep-extend 460 deep-https = "<" ">" 462 The syntax for a Uniform Resource Identifier (URI) is defined in 463 [RFC3986]. Protocol extensions to advertise DEEP status are defined 464 in Section 7. 466 If the client successfully negotiates TLS and authenticates the 467 server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with 468 channel bindings [RFC5802]), then the client SHOULD record the 469 server's DEEP status information in the account configuration with 470 the server's hostname. Otherwise, the client SHOULD ignore the 471 server-provided DEEP status except for the "tls10" and "tls12" 472 security tags. 474 5.4. Email Security Tag Latch Failures 476 When a security tag latch has been set for connections from a client 477 to a server and the property identified by that tag is no longer 478 available, this results in a connection failure. An MUA SHOULD 479 inform the user of a potential threat to their confidentiality and 480 offer to resolve a previously-recorded DEEP status https URL if one 481 is available. MUAs are discouraged from offering a lightweight 482 option to reset or ignore latches as this defeats the benefit they 483 provide to end users. 485 6. Recording TLS Cipher Suite in Received Header 487 The ESMTPS transmission type [RFC3848] provides trace information 488 that can indicate TLS was used when transferring mail. However, TLS 489 usage by itself is not a guarantee of confidentiality or security. 490 The TLS cipher suite provides additional information about the level 491 of security made available for a connection. This defines a new SMTP 492 "tls" Received header additional-registered-clause that is used to 493 record the TLS cipher suite that was negotiated for the connection. 494 The value included in this additional clause SHOULD be the registered 495 cipher suite name (e.g., TLS_DHE_RSA_WITH_AES_128_CBC_SHA) included 496 in the TLS cipher suite registry. In the event the implementation 497 does not know the name of the cipher suite (a situation that should 498 be remedied promptly), a four-digit hexadecimal cipher suite 499 identifier MAY be used. The ABNF for the field follows: 501 tls-cipher-clause = CFWS "tls" FWS tls-cipher 503 tls-cipher = tls-cipher-suite-name / tls-cipher-suite-hex 505 tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_") 506 ; as registered in IANA cipher suite registry 508 tls-cipher-hex = "0x" 4HEXDIG 510 7. Extensions for DEEP Status and Reporting 512 This memo defines optional mechanisms for use by MUAs to communicate 513 DEEP status to servers and for servers to advertise available 514 latches. One purpose of such mechanisms is to permit servers to 515 determine which and how many clients have latched security 516 facilities, and thus, to permit operators to be aware of potential 517 impact to their users should support for such facilities be changed. 518 For IMAP, the existing ID command is extended to provide this 519 capability. For SMTP Submission, a new CLIENT command is defined. 520 No similar mechanism is defined for POP in this version of the memo 521 to keep POP simpler, but one may be added in the future if deemed 522 necessary. 524 In addition, for each of IMAP, POP, and SMTP, a new DEEP capability 525 is defined so the client can access the server's DEEP status. 527 7.1. IMAP DEEP Extension 529 When an IMAP server advertises the DEEP capability, that indicates 530 the IMAP server implements IMAP4 ID [RFC2971] with additional field 531 values defined here. This is grouped with the ID command because 532 that is the existing IMAP mechanism for clients to report data for 533 server logging, and provides a way for the server to report the DEEP 534 status. 536 deep From server to client, the argument to this ID field is the 537 server DEEP status. Servers MUST provide this information in 538 response to an ID command. 540 latch From client to server, this is a space-separated list of 541 security tags the client has latched for this server. Servers MAY 542 record this information so administrators know the expected latch- 543 related security properties of the client and can thus act to 544 avoid security latch failures (e.g., by renewing server 545 certificates on time, etc). 547 latch-fail From client to server, a space-separated list including 548 one or more security tag the client has latched that the client 549 was unable to achieve. This allows clients to report errors to 550 the server prior to terminating the connection to the server in 551 the event an acceptable security level is unavailable. 553 security-tags From client to server, this is a space-separated list 554 of security tags the client supports that are not latched. 556 tls Server-side IMAP proxies that accept TLS connections from 557 clients and connect in-the-clear over a fully private secure 558 network to the server SHOULD use this field to report the tls- 559 cipher (syntax as defined in Section 6) to the server. 561 IMAP clients SHOULD use the IMAP ID command to report latch failures 562 and determine the server DEEP status. Clients MAY use the ID command 563 to report other latch or security tag information. IMAP servers MUST 564 implement the ID command at least to report DEEP status to clients. 566 567 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 568 AUTH=SCRAM-SHA-1] hello 569 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" 570 "tls10 tls-cert" "security-tags" "tls12") 571 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 572 "") 573 S: a001 OK ID completed 575 Example 1 577 This example shows a client that successfully negotiated TLS version 578 1.0 or later and verified the server's certificate as required by 579 IMAP. The client supports TLS 1.2. However, even if the client 580 successfully negotiated TLS 1.2, it will not latch that security tag 581 automatically because the server did not advertise that tag. If the 582 client successfully validated the server certificate, it will latch 583 the provided URL. 585 586 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 587 AUTH=SCRAM-SHA-1] hello 588 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch-failure" 589 "tls-cert") 590 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 591 "tls10 ") 592 S: a001 OK ID completed 593 C: a002 LOGOUT 595 Example 2 597 This example shows a client that negotiated TLS, but was unable to 598 verify the server's certificate. The latch-failure informs the 599 server of this problem, at which point the client can disconnect. If 600 the client had previously latched a URI for security problems from 601 this server, it could offer to resolve that URI. However, the deep- 602 status in this exchange is ignored due to the latch failure. 604 606 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 607 AUTH=SCRAM-SHA-1] hello 608 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" 609 "tls10 tls-cert" "security-tags" "tls12" 610 "tls" "TLS_RSA_WITH_AES_128_CBC_SHA") 611 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 612 "tls10 tls-cert ") 613 S: a001 OK ID completed 615 Example 3 617 This example shows the connection from an IMAP proxy to a back-end 618 server. The client connected to the proxy and sent the ID command 619 shown in example 1, and the proxy has added the "tls" item to the ID 620 command so the back-end server can log the cipher suite that was used 621 on the connection from the client. 623 7.2. POP DEEP Extension 625 POP servers supporting this specification MUST implement the POP3 626 extension mechanism [RFC2449]. POP servers MUST advertise the DEEP 627 capability with an argument indicating the server's DEEP status. 629 630 S: +OK POP server ready 631 C: CAPA 632 S: +OK Capability list follows 633 S: TOP 634 S: SASL PLAIN SCRAM-SHA-1 635 S: RESP-CODES 636 S: PIPELINING 637 S: UIDL 638 S: DEEP tls10 tls12 639 S: . 641 Example 4 643 After verifying the TLS server certificate and issuing CAPA, the 644 client can latch any or all of the DEEP status. If the client 645 connects to this same server later and has a security failure, the 646 client can direct the user's browser to the previously-latched URI 647 where the service provider may provide advice to the end user. 649 7.3. SMTP DEEP Extension 651 SMTP Submission servers supporting this specification MUST implement 652 the DEEP SMTP extension. The name of this extension is DEEP. The 653 EHLO keyword value is DEEP and the deep-status ABNF is the syntax of 654 the EHLO keyword parameters. This does not add parameters to the 655 MAIL FROM or RCPT TO commands. This also adds a CLIENT command to 656 SMTP which is used to report client information to the server. The 657 formal syntax for the command follows: 659 deep-cmd = "CLIENT" 1*(SP deep-parameter) 661 deep-parameter = name / version / latch / latch-fail 662 / security-tags / tls / future-extension 664 name = "name=" esmtp-value 666 version = "version=" esmtp-value 668 latch = "latch=" security-tag *("," security-tag) 670 latch-fail = "latch-fail=" security-tag 671 *("," security-tag) 673 security-tags = "security-tags=" security-tag 674 *("," security-tag) 676 tls = "tls=" tls-cipher 678 future-extension = esmtp-param 680 esmtp-param = 682 esmtp-value = 684 The CLIENT command parameters listed here have the same meaning as 685 the parameters used in the IMAP DEEP extension (Section 7.1). The 686 server responds to the CLIENT command with a "250" if the command has 687 correct syntax and a "501" if the command has incorrect syntax. 689 690 S: 220 example.com Demo SMTP Submission Server 691 C: EHLO client.example.com 692 S: 250-example.com 693 S: 250-8BITMIME 694 S: 250-PIPELINING 695 S: 250-DSN 696 S: 250-AUTH PLAIN LOGIN 697 S: 250-DEEP tls10 tls-cert 698 S: 250-BURL imap 699 S: 250 SIZE 0 700 C: CLIENT name=demo_submit version=1.5 latch=tls10,tls-cert 701 security-tags=tls12 702 S: 250 OK 704 Example 5 706 7.4. SMTP Error Extension 708 Although this document focuses on SMTP Submission, it is possible to 709 use security latches for SMTP transport as well. When MTA transport 710 fails due to a security latch, the MTA MUST use the SMTP enhanced 711 status code X.7.TBD (RFC Editor note: update this TBD). The SMTP 712 notary response [RFC3464] for a security latch failure MUST include 713 an additional "SMTP-Security-Latch" recipient-specific header field 714 that includes a space-delimited list including one or more security 715 latch that failed. The ABNF for this new field follows: 717 CFWS = 719 FWS = 721 smtp-security-latch = "SMTP-Security-Latch:" CFWS 722 security-tag *(FWS security-tag) 724 8. Use of SRV records in Establishing Configuration 726 This section updates [RFC6186] by changing the preference rules and 727 adding a new SRV service label _submissions._tcp to refer to Message 728 Submission with implicit TLS. 730 User-configurable MUAs SHOULD support use of [RFC6186] for account 731 setup. However, when using configuration information obtained by 732 this method, MUAs SHOULD default to a high confidentiality assurance 733 level, unless the user has explicitly requested reduced 734 confidentiality. This will have the effect of causing the MUA to 735 ignore advertised configurations that do not support TLS, even when 736 those advertised configurations have a higher priority than other 737 advertised configurations. 739 When using [RFC6186] configuration information, Mail User Agents 740 SHOULD NOT automatically establish new configurations that do not 741 require TLS for all servers, unless there are no advertised 742 configurations using TLS. If such a configuration is chosen, prior 743 to attempting to authenticate to the server or use the server for 744 message submission, the MUA SHOULD warn the user that traffic to that 745 server will not be encrypted and that it will therefore likely be 746 intercepted by unauthorized parties. The specific wording is to be 747 determined by the implementation, but it should adequately capture 748 the sense of risk given the widespread incidence of mass surveillance 749 of email traffic. 751 When establishing a new configuration for connecting to an IMAP, POP, 752 or SMTP Submission server, an MUA SHOULD NOT blindly trust SRV 753 records unless they are signed by DNSSEC and have a valid signature. 754 Instead, the MUA SHOULD warn the user that the DNS-advertised 755 mechanism for connecting to the server is not authenticated, and 756 request the user to manually verify the connection details by 757 reference to his or her mail service provider's documentation. 759 Similarly, an MUA MUST NOT consult SRV records to determine which 760 servers to use on every connection attempt, unless those SRV records 761 are signed by DNSSEC and have a valid signature. However, an MUA MAY 762 consult SRV records from time to time to determine if an MSP's server 763 configuration has changed, and alert the user if it appears that this 764 has happened. This can also serve as a means to encourage users to 765 upgrade their configurations to require TLS if and when their MSPs 766 support it. 768 9. Implementation Requirements 770 This section details requirements for implementations of electronic 771 mail protocol clients and servers. A requirement for a client or 772 server implementation to support a particular feature is not the same 773 thing as a requirement that a client or server running a conforming 774 implementation be configured to use that feature. Requirements for 775 Mail Service Providers (MSPs) are distinct from requirements for 776 protocol implementations, and are listed in a separate section. 778 9.1. All Implementations (Client and Server) 780 These requirements apply to MUAs as well as POP, IMAP and SMTP 781 Submission servers. 783 o All implementations MUST be configurable to support implicit TLS 784 using the TLS 1.2 protocol or later [RFC5246] including support 785 for the mandatory-to-implement TLS 1.2 cipher suite 786 TLS_RSA_WITH_AES_128_CBC_SHA. 788 o IMAP implementations MUST support the IMAP4rev1 mandatory-to- 789 implement cipher suite TLS_RSA_WITH_RC4_128_MD5 for any 790 connections made or received via IMAP although this MAY be 791 disabled by default. 793 o All implementations MUST be configurable to require TLS before 794 performing any operation other than capability discovery and 795 STARTTLS. 797 9.1.1. Client Certificate Authentication 799 MUAs and mail servers MAY implement client certificate authentication 800 on the implicit TLS port. Servers MUST NOT request a client 801 certificate during the TLS handshake unless the server is configured 802 to accept some client certificates as sufficient for authentication 803 and the server has the ability to determine a mail server 804 authorization identity matching such certificates. How to make this 805 determination is presently implementation specific. Clients MUST NOT 806 provide a client certificate during the TLS handshake unless the 807 server requests one and the client has determined the certificate can 808 be safely used with that specific server, OR the client has been 809 explicitly configured by the user to use that particular certificate 810 with that server. How to make this determination is presently 811 implementation specific. If the server accepts the client's 812 certificate as sufficient for authorization, it MUST enable the SASL 813 EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH 814 greeting instead of enabling SASL EXTERNAL. A client supporting 815 client certificate authentication with implicit TLS MUST implement 816 the SASL EXTERNAL [RFC4422] mechanism using the appropriate 817 authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP 818 Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]). 820 9.2. Mail Server Implementation Requirements 822 These requirements apply to servers that implement POP, IMAP or SMTP 823 Submission. 825 o Servers MUST implement the DEEP extension described in Section 7 827 o IMAP and SMTP submission servers SHOULD implement and be 828 configurable to support STARTTLS. This enables discovery of new 829 TLS availability, and can increase usage of TLS by legacy clients. 831 o Servers MUST NOT advertise STARTTLS if it is unlikely to succeed 832 based on server configuration (e.g., there is no server 833 certificate installed). 835 o SMTP message submission servers that have negotiated TLS SHOULD 836 add a Received header field to the message including the tls 837 clause described in Section 6. 839 o Servers MUST be configurable to include the TLS cipher information 840 in any connection or user logging or auditing facility they 841 provide. 843 9.3. Mail User Agent Implementation Requirements 845 This section describes requirements on Mail User Agents (MUAs) using 846 IMAP, POP, and/or Submission protocols. Note: Requirements 847 pertaining to use of Submission servers are also applicable to use of 848 SMTP servers (e.g., port 25) for mail submission. 850 o User agents SHOULD indicate to users at configuration time, the 851 expected level of confidentiality based on appropriate security 852 inputs such as which security latches are pre-set, the number of 853 trust anchors, certificate validity, use of an extended validation 854 certificate, TLS version supported, and TLS cipher suites 855 supported by both server and client. This indication SHOULD also 856 be present when editing or viewing account configuration. 858 o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes 859 available for a protocol and set the tls10 latch if the server 860 advertises the tls10 security tag after a successful TLS 861 negotiation. 863 o Whenever requested to establish any configuration that does not 864 require both TLS and server certificate verification to talk to a 865 server or account, an MUA SHOULD warn its user that his or her 866 mail traffic (including password, if applicable) will be exposed 867 to attackers, and give the user an opportunity to abort the 868 connection prior to transmission of any such password or traffic. 870 o MUAs SHOULD implement the "tls12" security latch (the TLS library 871 has to provide an API that controls permissible TLS versions and 872 communicates the negotiated TLS protocol version to the 873 application for this to be possible). 875 o See Section 3 for additional requirements. 877 9.4. Non-configurable MUAs and nonstandard access protocols 879 MUAs which are not configurable to use user-specified servers MUST 880 implement TLS or similarly other strong encryption mechanism when 881 communicating with their mail servers. This generally applies to 882 MUAs that are pre-configured to operate with one or more specific 883 services, whether or not supplied by the vendor of those services. 885 MUAs using protocols other than IMAP, POP, and Submission to 886 communicate with mail servers, MUST implement TLS or other similarly 887 robust encryption mechanism in conjunction with those protocols. 889 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 891 There are multiple ways to connect an Anti-Virus and/or Anti-Spam 892 (AVAS) service to a mail server. Some mechanisms, such as the de- 893 facto milter protocol do not impact DEEP. However, some services use 894 an SMTP relay proxy that intercepts mail at the application layer to 895 perform a scan and proxy to the real MTA. Deploying AVAS services in 896 this way can cause many problems [RFC2979] including direct 897 interference with DEEP and confidentiality or security reduction. An 898 AVAS product or service is considered DEEP compliant if all IMAP, POP 899 and SMTP-related software it includes is DEEP compliant and it 900 advertises and supports all security latches that the actual MTA 901 advertises. 903 10. Mail Service Provider Requirements 905 This section details requirements for providers of IMAP, POP, and/or 906 SMTP submission services, for providers who claim to conform to this 907 specification. 909 10.1. Server Requirements 911 Mail Service Providers MUST use server implementations that conform 912 to this specification. 914 10.2. MSPs MUST provide Submission Servers 916 This document updates the advice in [RFC5068] by making Implicit TLS 917 on port 465 the preferred submission port. 919 Mail Service Providers that accept mail submissions from end-users 920 using the Internet Protocol MUST provide one or more SMTP Submission 921 servers for this purpose, separate from the SMTP servers used to 922 process incoming mail. Those submission servers MUST be configured 923 to support Implicit TLS on port 465 and SHOULD support STARTTLS if 924 port 587 is used. 926 MSPs MAY also support submission of messages via one or more 927 designated SMTP servers to facilitate compatibility with legacy MUAs. 929 Discussion: SMTP servers used to accept incoming mail or to relay 930 mail are expected to accept mail in cleartext. This is incompatible 931 with the purpose of this memo which is to encourage encryption of 932 traffic between mail servers. There is no such requirement for mail 933 submission servers to accept mail in cleartext or without 934 authentication. For other reasons, use of separate SMTP submission 935 servers has been best practice for many years. 937 10.3. TLS Server Certificate Requirements 939 MSPs MUST maintain valid server certificates for all servers. Those 940 server certificates SHOULD present DNS-IDs and SRV-IDs conforming to 941 [RFC6125] and which will be recognized by MUAs meeting the 942 requirements of that specification. In addition, those server 943 certificates MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for 944 compatibility with existing MUAs. 946 If a protocol server provides service for more than one mail domain, 947 it MAY use a separate IP address for each domain and/or a server 948 certificate that advertises multiple domains. This will generally be 949 necessary unless and until it is acceptable to impose the constraint 950 that the server and all clients support the Server Name Indication 951 extension to TLS [RFC6066]. 953 10.4. Recommended DNS records for mail protocol servers 955 This section discusses not only the DNS records that are recommended, 956 but also implications of DNS records for server configuration and TLS 957 server certificates. 959 10.4.1. MX records 961 It is recommended that MSPs advertise MX records for handling of 962 inbound mail (instead of relying entirely on A or AAAA records), and 963 that those MX records be signed using DNSSEC. This is mentioned here 964 only for completeness, as handling of inbound mail is out of scope 965 for this document. 967 10.4.2. SRV records 969 MSPs SHOULD advertise SRV records to aid MUAs in determination of 970 proper configuration of servers, per the instructions in [RFC6186]. 972 MSPs SHOULD advertise servers that support Implicit TLS in preference 973 to those which support cleartext and/or STARTTLS operation. 975 10.4.3. TLSA records 977 MSPs SHOULD advertise TLSA records to provide an additional trust 978 anchor for public keys used in TLS server certificates. However, 979 TLSA records MUST NOT be advertised unless they are signed using 980 DNSSEC. 982 10.4.4. DNSSEC 984 All DNS records advertised by an MSP as a means of aiding clients in 985 communicating with the MSP's servers, SHOULD be signed using DNSSEC. 987 10.5. MSP Server Monitoring 989 MSPs SHOULD regularly and frequently monitor their various servers to 990 make sure that: TLS server certificates remain valid and are not 991 about to expire, TLSA records match the public keys advertised in 992 server certificates, are signed using DNSSEC, server configurations 993 are consistent with SRV advertisements, and DNSSEC signatures are 994 valid and verifiable. Failure to detect expired certificates and DNS 995 configuration errors in a timely fashion can result in significant 996 loss of service for an MSP's users and a significant support burden 997 for the MSP. 999 10.6. Advertisement of DEEP status 1001 MSPs SHOULD advertise a DEEP status that includes tls10, tls-cert and 1002 an HTTPS URL that can be used to inform clients of service outages or 1003 problems impacting client confidentiality. Note that advertising 1004 tls-cert is a commitment to maintain and renew server certificates. 1006 10.7. Require TLS 1008 New servers and services SHOULD be configured to require TLS unless 1009 it's necessary to support legacy clients or existing client 1010 configurations. 1012 10.8. Changes to Internet Facing Servers 1014 When an MSP changes the Internet Facing Servers providing mail access 1015 and mail submission services, including SMTP-based spam/virus 1016 filters, it is generally necessary to support the same and/or a newer 1017 version of TLS and the same security tags that were previously 1018 advertised. 1020 11. IANA Considerations 1022 11.1. Security Tag Registry 1024 IANA shall create (has created) the registry "Email Security Tags". 1025 This registry is a single table and will use an expert review process 1026 [RFC5226]. Each registration will contain the following fields: 1028 Name: The name of the security tag. This follows the security-tag 1029 ABNF. 1031 Description: This describes the meaning of the security tag and the 1032 conditions under which the tag is latched. 1034 Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. 1036 Reference: Optional reference to specification. 1038 Submitter: The identify of the submitter or submitters. 1040 Change Controller: The identity of the change controller for the 1041 registration. This will be "IESG" in case of registrations in 1042 IETF-produced documents. 1044 The expert reviewer will verify the tag name follows the ABNF, and 1045 that the description field is clear, unambiguous, does not overlap 1046 existing deployed technology, does not create security or privacy 1047 problems and appropriately considers interoperability issues. Email 1048 security tags intended for LIMITED USE have a lower review bar 1049 (interoperability and overlap issues are less of a concern). The 1050 reviewer may approve a registration, reject for a stated reason or 1051 recommend the proposal have standards track review due to importance 1052 or difficult subtleties. 1054 Standards-track registrations may be updated if the relevant 1055 standards are updated as a consequence of that action. Non- 1056 standards-track entries may be updated by the listed change 1057 controller. The entry's name and submitter may not be changed. In 1058 exceptional cases, any aspect of any registered entity may be updated 1059 at the direction of the IESG (for example, to correct a conflict). 1061 11.2. Initial Set of Security Tags 1063 This document defines four initial security tags for the security tag 1064 registry as follows: 1066 Name: tls10 1067 Description: This indicates TLS version 1.0 [RFC2246] or later was 1068 negotiated successfully including negotiation of a strong 1069 encryption layer with a symmetric key of at least 128 bits. This 1070 tag does not indicate the server certificate was valid. This tag 1071 is latched if the client sees this tag in the advertised server 1072 DEEP status provided after successfully negotiating TLS version 1073 1.0 or later. 1075 Intended Usage: COMMON 1077 Reference: RFC XXXX (this document once published) 1079 Submitter: Authors of this document 1081 Change Controller: IESG 1083 Name: tls12 1085 Description: This indicates TLS version 1.2 [RFC5246] or later was 1086 negotiated successfully including negotiation of a strong 1087 encryption layer with a symmetric key of at least 128 bits. This 1088 tag does not indicate the server certificate was valid. This tag 1089 is latched if the client sees this tag in the advertised server 1090 DEEP status provided after successfully negotiating TLS version 1091 1.2 or later. 1093 Intended Usage: COMMON 1095 Reference: RFC XXXX (this document once published) 1097 Submitter: Authors of this document 1099 Change Controller: IESG 1101 Name: tls-cert 1103 Description: This tag indicates that TLS was successfully negotiated 1104 and the server certificate was successfully verified by the client 1105 using PKIX [RFC5280] and the server certificate identity was 1106 verified using the algorithm appropriate for the protocol (see 1107 Section 4). This tag is latched if the client sees this tag in 1108 the advertised server DEEP status after successfully negotiating 1109 TLS and verifying the certificate and server identity. 1111 Intended Usage: COMMON 1113 Reference: RFC XXXX (this document once published) 1114 Submitter: Authors of this document 1116 Change Controller: IESG 1118 Name: tls-dane-tlsa 1120 Description: This tag indicates that TLS was successfully negotiated 1121 and the server certificate was successfully verified by the client 1122 using the procedures described in [RFC6698] and the server 1123 certificate identity was verified using the algorithm appropriate 1124 for the protocol (see Section 4). This tag is latched if the 1125 client sees this tag in the advertised server DEEP status after 1126 successfully negotiating TLS and verifying the certificate and 1127 server identity. 1129 Intended Usage: COMMON 1131 Reference: RFC XXXX (this document once published) 1133 Submitter: Authors of this document 1135 Change Controller: IESG 1137 11.3. POP3S Port Registration Update 1139 IANA is asked to update the registration of the TCP well-known port 1140 995 using the following template ([RFC6335]): 1142 Service Name: pop3s 1143 Transport Protocol: TCP 1144 Assignee: IETF 1145 Contact: IESG 1146 Description: POP3 over TLS protocol 1147 Reference: RFC XXXX (this document once published) 1148 Port Number: 995 1150 11.4. IMAPS Port Registration Update 1152 IANA is asked to update the registration of the TCP well-known port 1153 993 using the following template ([RFC6335]): 1155 Service Name: imaps 1156 Transport Protocol: TCP 1157 Assignee: IETF 1158 Contact: IESG 1159 Description: IMAP over TLS protocol 1160 Reference: RFC XXXX (this document once published) 1161 Port Number: 993 1163 11.5. Submissions Port Registration 1165 IANA is asked to assign an alternate usage of port 465 in addition to 1166 the current assignment using the following template ([RFC6335]): 1168 Service Name: submissions 1169 Transport Protocol: TCP 1170 Assignee: IETF 1171 Contact: IESG 1172 Description: Message Submission over TLS protocol 1173 Reference: RFC XXXX (this document once published) 1174 Port Number: 465 1176 This is a one time procedural exception to the rules in RFC 6335. 1177 This requires explicit IESG approval and does not set a precedent. 1178 Historically, port 465 was briefly registered as the "smtps" port. 1179 This registration made no sense as the SMTP transport MX 1180 infrastructure has no way to specify a port so port 25 is always 1181 used. As a result, the registration was revoked and was subsequently 1182 reassigned to a different service. In hindsight, the "smtps" 1183 registration should have been renamed or reserved rather than 1184 revoked. Unfortunately, some widely deployed mail software 1185 interpreted "smtps" as "submissions" [RFC6409] and used that port for 1186 email submission by default when an end-user requests security during 1187 account setup. If a new port is assigned for the submissions 1188 service, email software will either continue with unregistered use of 1189 port 465 (leaving the port registry inaccurate relative to de-facto 1190 practice and wasting a well-known port), or confusion between the de- 1191 facto and registered ports will cause harmful interoperability 1192 problems that will deter use of TLS for message submission. The 1193 authors believe both of these outcomes are less desirable than a wart 1194 in the registry documenting real-world usage of a port for two 1195 purposes. Although STARTTLS-on-port-587 has deployed, it has not 1196 replaced deployed use of implicit TLS submission on port 465. 1198 11.6. DEEP IMAP Capability 1200 This document adds the DEEP capability to the IMAP capabilities 1201 registry. This is described in Section 7.1. 1203 11.7. DEEP POP3 Capability 1205 This document adds the DEEP capability to the POP3 capabilities 1206 registry. 1208 CAPA Tag: DEEP 1210 Arguments: deep-status 1211 Added Commands: none 1213 Standard Commands affected: none 1215 Announced status / possible differences: both / may change after 1216 STLS 1218 Commands Valid in States: N/A 1220 Specification Reference: This document 1222 Discussion: See Section 7.2. 1224 11.8. DEEP SMTP EHLO Keyword 1226 This document adds the DEEP EHLO Keyword to the SMTP Service 1227 Extension registry. This is described in Section 7.3. 1229 11.9. SMTP Enhanced Status Code 1231 This document adds the following entry to the "SMTP Enhanced Status 1232 Codes" registry created by [RFC5248]. 1234 Code: X.7.TBD (IANA, please assign the next available number) 1236 Sample Text: Message Transport Failed due to missing required 1237 security. 1239 Associated Basic Status Code: 450, 454, 550, 554 1241 Description This code indicates an SMTP server was unable to forward 1242 a message to the next host necessary for delivery because it 1243 required a higher level of transport security or confidentiality 1244 than was available. The temporary form of this error is preferred 1245 in case the problem is caused by a temporary administrative error 1246 such as an expired server certificate. 1248 Reference This document 1250 Submitter C. Newman 1252 Change Controller IESG 1254 11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 1256 This document adds the following entry to the "Additional-registered- 1257 clauses" sub-registry of the "MAIL Parameters" registry, created by 1258 [RFC5321]: 1260 Clause Name: tls 1262 Description: Indicates the TLS cipher suite used for a transport 1263 connection. 1265 Syntax Summary: See tls-cipher ABNF Section 6 1267 Reference: This document. 1269 12. Security Considerations 1271 This entire document is about security considerations. In general, 1272 this is targeted to improve mail privacy and to mitigate threats 1273 external to the email system such as network-level snooping or 1274 interception; this is not intended to mitigate active attackers who 1275 have compromised service provider systems. 1277 It could be argued that sharing the name and version of the client 1278 software with the server has privacy implications. Although 1279 providing this information is not required, it is encouraged so that 1280 mail service providers can more effectively inform end-users running 1281 old clients that they need to upgrade to protect their security, or 1282 know which clients to use in a test deployment prior to upgrading a 1283 server to have higher security requirements. 1285 13. References 1287 13.1. Normative References 1289 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1290 STD 53, RFC 1939, May 1996. 1292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1293 Requirement Levels", BCP 14, RFC 2119, March 1997. 1295 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 1296 Mechanism", RFC 2449, November 1998. 1298 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1300 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, October 1301 2000. 1303 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1304 Transport Layer Security", RFC 3207, February 2002. 1306 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1307 4rev1", RFC 3501, March 2003. 1309 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1310 for Delivery Status Notifications", RFC 3464, January 1311 2003. 1313 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1314 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1315 3986, January 2005. 1317 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol 1318 (POP3) Simple Authentication and Security Layer (SASL) 1319 Authentication Mechanism", RFC 5034, July 2007. 1321 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1322 Finch, "Email Submission Operations: Access and 1323 Accountability Requirements", BCP 134, RFC 5068, November 1324 2007. 1326 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1327 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1329 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1330 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1332 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1333 Mail System Status Codes", BCP 138, RFC 5248, June 2008. 1335 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1336 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1337 May 2008. 1339 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1340 Housley, R., and W. Polk, "Internet X.509 Public Key 1341 Infrastructure Certificate and Certificate Revocation List 1342 (CRL) Profile", RFC 5280, May 2008. 1344 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1345 October 2008. 1347 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1348 October 2008. 1350 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1351 Verification of Domain-Based Application Service Identity 1352 within Internet Public Key Infrastructure Using X.509 1353 (PKIX) Certificates in the Context of Transport Layer 1354 Security (TLS)", RFC 6125, March 2011. 1356 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1357 Submission/Access Services", RFC 6186, March 2011. 1359 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1360 STD 72, RFC 6409, November 2011. 1362 [I-D.melnikov-email-tls-certs] 1363 Melnikov, A., "Updated TLS Server Identity Check Procedure 1364 for Email Related Protocols", draft-melnikov-email-tls- 1365 certs-01 (work in progress), October 2013. 1367 [I-D.ietf-dane-smtp-with-dane] 1368 Dukhovni, V. and W. Hardaker, "SMTP security via 1369 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02 1370 (work in progress), October 2013. 1372 13.2. Informative References 1374 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1375 RFC 2246, January 1999. 1377 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 1378 2595, June 1999. 1380 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1381 Firewalls", RFC 2979, October 2000. 1383 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 1384 Registration", RFC 3848, July 2004. 1386 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 1387 September 2004. 1389 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1390 Security Layer (SASL)", RFC 4422, June 2006. 1392 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1393 for Authentication", RFC 4954, July 2007. 1395 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 1396 2009. 1398 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1399 "Salted Challenge Response Authentication Mechanism 1400 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 1402 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 1403 Managing Sieve Scripts", RFC 5804, July 2010. 1405 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1406 Extension Definitions", RFC 6066, January 2011. 1408 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1409 Cheshire, "Internet Assigned Numbers Authority (IANA) 1410 Procedures for the Management of the Service Name and 1411 Transport Protocol Port Number Registry", BCP 165, RFC 1412 6335, August 2011. 1414 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1415 of Named Entities (DANE) Transport Layer Security (TLS) 1416 Protocol: TLSA", RFC 6698, August 2012. 1418 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1419 Transport Security (HSTS)", RFC 6797, November 2012. 1421 Appendix A. Design Considerations 1423 This section is not normative. 1425 The first version of this was written independently from draft-moore- 1426 email-tls-00.txt; subsequent versions merge ideas from both drafts. 1428 One author of this document was also the author of RFC 2595 that 1429 became the standard for TLS usage with POP and IMAP, and the other 1430 author was perhaps the first to propose that idea. In hindsight both 1431 authors now believe that that approach was a mistake. At this point 1432 the authors believe that while anything that makes it easier to 1433 deploy TLS is good, the desirable end state is that these protocols 1434 always use TLS, leaving no need for a separate port for cleartext 1435 operation except to support legacy clients while they continue to be 1436 used. The separate port model for TLS is inherently simpler to 1437 implement, debug and deploy. It also enables a "generic TLS load- 1438 balancer" that accepts secure client connections for arbitrary foo- 1439 over-TLS protocols and forwards them to a server that may or may not 1440 support TLS. Such load-balancers cause many problems because they 1441 violate the end-to-end principle and the server loses the ability to 1442 log security-relevant information about the client unless the 1443 protocol is designed to forward that information (as this 1444 specification does for the cipher suite). However, they can result 1445 in TLS deployment where it would not otherwise happen which is a 1446 sufficiently important goal that it overrides the problems. 1448 Although STARTTLS appears only slightly more complex than separate- 1449 port TLS, we again learned the lesson that complexity is the enemy of 1450 security in the form of the STARTTLS command injection vulnerability 1451 (CERT vulnerability ID #555316). Although there's nothing inherently 1452 wrong with STARTTLS, the fact it resulted in a common implementation 1453 error (made independently by multiple implementers) suggests it is a 1454 less secure architecture than Implicit TLS. 1456 Section 7 of RFC 2595 critiques the separate-port approach to TLS. 1457 The first bullet was a correct critique. There are proposals in the 1458 http community to address that, and use of SRV records as described 1459 in RFC 6186 resolves that critique for email. The second bullet is 1460 correct as well, but not very important because useful deployment of 1461 security layers other than TLS in email is small enough to be 1462 effectively irrelevant. The third bullet is incorrect because it 1463 misses the desirable option of "use and latch-on TLS if available". 1464 The fourth bullet may be correct, but is not a problem yet with 1465 current port consumption rates. The fundamental error was 1466 prioritizing a perceived better design based on a mostly valid 1467 critique over real-world deployability. But getting security and 1468 confidentiality facilities actually deployed is so important it 1469 should trump design purity considerations. 1471 Appendix B. Open Issues 1473 There are many open issues with this document. Here is an attempt to 1474 enumerate some of them: 1476 o Port 465 is presently used for two purposes: for submissions by a 1477 large number of clients and service providers and for the "urd" 1478 protocol by one vendor. Actually documenting this current state 1479 is controversial as discussed in the IANA considerations section. 1480 However, there is no good alternative. Registering a new port for 1481 submissions when port 465 is widely used for that purpose already 1482 will just create interoperability problems. Registering a port 1483 that's only used if advertised by an SRV record (RFC 6186) would 1484 not create interoperability problems but would require all client 1485 and server deployments and software to change significantly which 1486 is contrary to the goal of promoting more TLS use. Encouraging 1487 use of STARTTLS on port 587 would not create interoperability 1488 problems, but is unlikely to have impact on current undocumented 1489 use of port 465 and makes the guidance in this document less 1490 consistent. 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 two authors of this document and the author of draft-melnikov- 1502 email-tls-certs are willing to merge these two documents. 1503 However, it is undesirable to delay publication of either document 1504 so this will be done only if the latter document is not yet 1505 through IESG processing when this document is ready for the IESG. 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 draft-newman-email-deep-02: 1527 o Changed "privacy assurance" to "confidentiality assurance" 1529 o Changed "low privacy assurance" to "no confidentiality assurance" 1531 o Attempt to improve definition of confidentiality assurance level. 1533 o Add SHOULD indicate when MUA is showing list of mail accounts. 1535 o Add SHOULD NOT latch tls10, tls12 tags until TLS negotiated. 1537 o Removed sentence about deleting and re-creating the account in 1538 latch failure section. 1540 o Remove use of word "fallback" with respect to TLS version 1541 negotiation. 1543 o Added bullet about changes to Internet facing servers to MSP 1544 section. 1546 o minor wording improvements based on feedback 1548 Changes since -01: 1550 o Updated abstract, introduction and document structure to focus 1551 more on mail user agent privacy assurance. 1553 o Added email account privacy section, also moving section on 1554 account setup using SRV records to that section. 1556 o Finished writing IANA considerations section 1558 o Remove provisional concept and instead have server explicitly list 1559 security tags clients should latch. 1561 o Added note that rules for the submissions port follow the same 1562 rules as those for the submit port. 1564 o Reference and update advice in [RFC5068]. 1566 o Fixed typo in Client Certificate Authentication section. 1568 o Removed tls-pfs security latch and all mention of perfect forward 1569 secrecy as it was controversial. 1571 o Added reference to HSTS. 1573 Changes since -00: 1575 o Rewrote introduction to merge ideas from draft-moore-email-tls-00. 1577 o Added Implicit TLS section, Account configuration section and IANA 1578 port registration updates based on draft-moore-email-tls-00. 1580 o Add protocol details necessary to standardize implicit TLS for 1581 POP/IMAP/submission, using ideas from draft-melnikov-pop3-over- 1582 tls. 1584 o Reduce initial set of security tags based on feedback. 1586 o Add deep status concept to allow a window for software updates to 1587 be backed out before latches make that problematic, as well as to 1588 provide service providers with a mechanism they can use to assist 1589 customers in the event of a privacy failure. 1591 o Add DNS SRV section from draft-moore-email-tls-00. 1593 o Write most of the missing IANA considerations section. 1595 o Rewrite most of implementation requirements section based more on 1596 draft-moore-email-tls-00. Remove new cipher requirements for now 1597 because those may be dealt with elsewhere. 1599 Appendix D. Acknowledgements 1601 Many thanks to Ned Freed for discussion of the initial latch concepts 1602 in this document. Thanks to Alexey Melnikov for draft-melnikov-pop3- 1603 over-tls-02, which was the basis of the POP3 implicit TLS text. 1604 Thanks to Dan Newman and Alexey Melnikov for review feedback. Thanks 1605 to Paul Hoffman for interesting feedback in initial conversations 1606 about this idea. 1608 Authors' Addresses 1610 Keith Moore 1611 Network Heretics 1612 PO Box 1934 1613 Knoxville, TN 37901 1614 US 1616 Email: moore@network-heretics.com 1618 Chris Newman 1619 Oracle 1620 440 E. Huntington Dr., Suite 400 1621 Arcadia, CA 91006 1622 US 1624 Email: chris.newman@oracle.com