idnits 2.17.1 draft-ietf-uta-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 RFC2595, 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 (March 10, 2016) is 2968 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 (-09) exists of draft-ietf-uta-email-tls-certs-03 == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-02 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 6 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, 2595, 3464, 3501, 5068, C. Newman 5 6186, 6409 (if approved) Oracle 6 Intended status: Standards Track March 10, 2016 7 Expires: September 11, 2016 9 Deployable Enhanced Email Privacy (DEEP) 10 draft-ietf-uta-email-deep-02.txt 12 Abstract 14 This specification defines a set of requirements and facilities 15 designed to improve email confidentiality between a mail user agent 16 (MUA) and a mail submission or mail access server. This provides 17 mechanisms intended to increase use of already deployed Transport 18 Layer Security (TLS) technology, provide a model for mail user 19 agent's confidentiality assurance, and enable mail service providers 20 to advertise improved TLS confidentiality facilities. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 11, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions and Terminology Used in This Document . . . . . . 4 58 3. Mail Account Confidentiality Assurance Level . . . . . . . . . 5 59 3.1. High Confidentiality Assurance . . . . . . . . . . . . . 6 60 3.2. No Confidentiality Assurance . . . . . . . . . . . . . . 6 61 3.3. Other Confidentiality Assurance Levels . . . . . . . . . 7 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 . 9 67 5. Email Security Upgrading Using Security Latches . . . . . . . 9 68 5.1. Email Security Tags . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . 17 78 8. Account Setup Considerations . . . . . . . . . . . . . . . . . 17 79 8.1. Use of SRV records in Establishing Configuration . . . . 17 80 8.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 18 81 9. Implementation Requirements . . . . . . . . . . . . . . . . . 18 82 9.1. All Implementations (Client and Server) . . . . . . . . . 19 83 9.1.1. Client Certificate Authentication . . . . . . . . . . 19 84 9.2. Mail Server Implementation Requirements . . . . . . . . . 20 85 9.3. Mail User Agent Implementation Requirements . . . . . . . 20 86 9.4. Non-configurable MUAs and nonstandard access protocols . 21 87 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and 88 Services . . . . . . . . . . . . . . . . . . . . . . . . 21 89 10. Mail Service Provider Requirements . . . . . . . . . . . . . . 22 90 10.1. Server Requirements . . . . . . . . . . . . . . . . . . . 22 91 10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 22 92 10.3. TLS Server Certificate Requirements . . . . . . . . . . . 22 93 10.4. Recommended DNS records for mail protocol servers . . . . 23 94 10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . . 23 95 10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . . 23 96 10.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 23 97 10.4.4. TLSA records . . . . . . . . . . . . . . . . . . . . . 23 98 10.5. MSP Server Monitoring . . . . . . . . . . . . . . . . . . 23 99 10.6. Advertisement of DEEP status . . . . . . . . . . . . . . 24 100 10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . . 24 101 10.8. Changes to Internet Facing Servers . . . . . . . . . . . 24 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 103 11.1. Security Tag Registry . . . . . . . . . . . . . . . . . . 24 104 11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 25 105 11.3. POP3S Port Registration Update . . . . . . . . . . . . . 27 106 11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 27 107 11.5. Submissions Port Registration . . . . . . . . . . . . . . 28 108 11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 28 109 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 29 110 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 29 111 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . . 29 112 11.10. MAIL Parameters Additional-registered-clauses 113 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . 30 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 30 115 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 117 13.2. Informative References . . . . . . . . . . . . . . . . . 32 118 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 33 119 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 120 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 37 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 123 1. Introduction 125 Software that provides email service via Internet Message Access 126 Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] 127 and/or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] 128 usually has Transport Layer Security (TLS) [RFC5246] support but 129 often does not use it in a way that maximizes end-user 130 confidentiality. This specification proposes changes to email 131 software and deployments intended to increase the use of TLS and 132 record when that use occurs. 134 In brief, this memo now recommends that: 136 o MUAs associate a confidentiality assurance level with each mail 137 account, and the default level requires use of TLS with 138 certificate validation for all TCP connections; 140 o TLS on a well-known port ("Implicit TLS") be supported for IMAP, 141 POP, and SMTP Submission [RFC6409] for all electronic mail user 142 agents (MUAs), servers, and service providers; 144 o MUAs and mail protocol servers cooperate (via mechanisms defined 145 in this specification) to upgrade security feature use and record/ 146 indicate that usage appropriately. 148 This does not address use of TLS with SMTP for message relay (where 149 Message Submission [RFC6409] does not apply). Improved use of TLS 150 with SMTP for message relay requires a different approach. Future 151 work may address that topic and one approach is described in 152 [I-D.ietf-dane-smtp-with-dane]. 154 The recommendations in this memo do not replace the functionality of, 155 and are not intended as a substitute for, end-to-end encryption of 156 electronic mail. 158 This draft is subject to change. Implementation of this proposal is 159 not recommended at this time. Please discuss this proposal on the 160 ietf-uta mailing list. 162 2. Conventions and Terminology Used in This Document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 This specification expresses syntax using the Augmented Backus-Naur 169 Form (ABNF) as described in [RFC5234], including the core rules in 170 Appendix B and rules from [RFC5322]. 172 In examples, "C:" and "S:" indicate lines sent by the client and 173 server respectively. If a single "C:" or "S:" label applies to 174 multiple lines, then the line breaks between those lines are for 175 editorial clarity only and are not part of the actual protocol 176 exchange. 178 3. Mail Account Confidentiality Assurance Level 180 A "mail account" refers to the network services an end user uses to 181 read, submit and manage email communications on the Internet. This 182 typically involves at least one mail access server (IMAP or POP) and 183 at least one SMTP submission server. An end users uses a mail user 184 agent (MUA) to access a mail account and most MUAs support one or 185 more mail accounts. This document uses the term "confidentiality 186 assurance level" to indicate the degree to which the network 187 connections between an MUA and a mail account have confidentiality 188 protection from both passive and active attackers on the network. 190 The configuration necessary for a mail account includes an email 191 address, connection information and authentication credentials for 192 network services. MUAs compliant with this specification MUST also 193 associate a confidentiality assurance level with each mail account. 194 MUAs MUST implement a high confidentiality assurance level as 195 described in the next section. 197 MUAs SHOULD continuously indicate to the user the confidentiality 198 assurance level of the account currently in use when reading, 199 submitting and managing mail (e.g., via a lock icon, background 200 colors and indications similar to those commonly used in web browsers 201 for a similar purpose) and SHOULD indicate the confidentiality 202 assurance level for each account whenever displaying a list of mail 203 accounts. Note that the displayed confidentiality assurance level 204 could be higher than the level set at account configuration but never 205 lower. If multiple active connections are associated with an account 206 or view, the indication should match the level provided by the least 207 confidential connection. 209 Account configuration occurs when an MUA is first used to access a 210 particular service, when a user wishes to access or submit mail 211 through servers in addition to those specified or found during first 212 use, or when a user explicitly requests to change account 213 configuration parameters such as server names, user names, passwords, 214 client certificates, etc. Account configuration can be entirely 215 manual (entering server names explicitly) or partially automated via 216 a mechanism such as DNS SRV records [RFC6186]. MUAs SHOULD use the 217 high confidentiality assurance level as the default for newly 218 configured accounts. 220 3.1. High Confidentiality Assurance 222 A mail account has a high confidentiality assurance when the 223 following conditions are met on all TCP server connections associated 224 with an account. This includes connections to POP, IMAP and SMTP 225 submission servers as well as any other associated protocols defined 226 now or in the future. Examples of protocols associated with a mail 227 account include managesieve [RFC5804] and MTQP [RFC3887]. 229 o TCP connections MUST attempt to negotiate TLS via either Implicit 230 TLS Section 4 or STARTTLS. 232 o MUAs MUST implement [I-D.ietf-uta-email-tls-certs] and PKIX 233 [RFC5280]. 235 o MUAs MAY implement DANE [RFC6698]. 237 o User agents MUST abort a TLS session if the TLS negotiation fails 238 or the server's certificate or identity fails to verify. A user 239 may reconfigure the account to lower the expected level of 240 confidentiality if he/she chooses. Reduction of expected account 241 confidentiality MUST NOT be done on a click-through basis. 243 The end user is part of the system that protects the user's 244 confidentiality and security. As a result, it's critical not to 245 present the end user with a simple action that reduces their 246 confidentiality in response to certificate validation failure. An 247 MUA which offers a user actions such as "connect anyway", "trust 248 certificate for future connections" or "lower confidentiality 249 assurance for this account" in response to certificate validation 250 failure is not providing a high confidentiality assurance as defined 251 in this section and thus does not comply with this document. 252 Examples of acceptable actions to offer would be "work offline", "try 253 again later", and "open service provider status web page". 255 3.2. No Confidentiality Assurance 257 MUAs MAY implement a no confidentiality assurance level for accounts. 258 At this level, the MUA MUST attempt to negotiate TLS, but MAY ignore 259 server certificate validation failures. MUAs MAY support use of 260 connections without TLS, but if they do they SHOULD attempt TLS first 261 if available and MUST implement code to reconnect without TLS if TLS 262 negotiation fails for reasons other than server certificate validity. 264 Note that if the TLS certificate is not successfully validated as 265 described in Section 3.1 or a version of SSL/TLS prior to TLS 1.0 is 266 used, the client MUST NOT present a high confidentiality indication 267 for the account or connection. 269 3.3. Other Confidentiality Assurance Levels 271 This specification is not intended to limit experimentation and 272 innovation with respect to user confidentiality. As a result more 273 confidentiality assurance levels are permitted. However, levels 274 below "no confidentiality assurance" described in the previous 275 section are discouraged and implementers are cautioned that end users 276 may be confused by too many confidentiality assurance levels. 278 4. Implicit TLS 280 Previous standards for use of email protocols with TLS used the 281 STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With 282 STARTTLS, the client establishes a clear text application session and 283 determines whether to issue a STARTTLS command based on server 284 capabilities and client configuration. If the client issues a 285 STARTTLS command, a TLS handshake follows that can upgrade the 286 connection. While this mechanism has been deployed, an alternate 287 mechanism where TLS is negotiated immediately at connection start on 288 a separate port (referred to in this document as "Implicit TLS") has 289 been deployed more successfully. To increase use of TLS, this 290 specification recommends use of implicit TLS by new POP, IMAP and 291 SMTP Submission software. 293 4.1. Implicit TLS for POP 295 When a TCP connection is established for the "pop3s" service (default 296 port 995), a TLS handshake begins immediately. Clients MUST 297 implement the certificate validation mechanism described in 298 [I-D.ietf-uta-email-tls-certs]. Once the TLS session is established, 299 POP3 [RFC1939] protocol messages are exchanged as TLS application 300 data for the remainder of the TCP connection. After the server sends 301 a +OK greeting, the server and client MUST enter AUTHORIZATION state, 302 even if client credentials were supplied during the TLS handshake. 304 See Section 9.1.1 for additional information on client certificate 305 authentication. See Section 11.3 for port registration information. 307 4.2. Implicit TLS for IMAP 309 When a TCP connection is established for the "imaps" service (default 310 port 993), a TLS handshake begins immediately. Clients MUST 311 implement the certificate validation mechanism described in [RFC3501] 312 and SHOULD implement the certificate validation mechanism described 313 in [I-D.ietf-uta-email-tls-certs]. Once the TLS session is 314 established, IMAP [RFC3501] protocol messages are exchanged as TLS 315 application data for the remainder of the TCP connection. If client 316 credentials were provided during the TLS handshake that the server 317 finds acceptable, the server MAY issue a PREAUTH greeting in which 318 case both the server and client enter AUTHENTICATED state. If the 319 server issues an OK greeting then both server and client enter NOT 320 AUTHENTICATED state. 322 See Section 9.1.1 for additional information on client certificate 323 authentication. See Section 11.4 for port registration information. 325 4.3. Implicit TLS for SMTP Submission 327 When a TCP connection is established for the "submissions" service 328 (default port 465), a TLS handshake begins immediately. Clients MUST 329 implement the certificate validation mechanism described in 330 [I-D.ietf-uta-email-tls-certs]. Once a TLS session is established, 331 message submission protocol data [RFC6409] is exchanged as TLS 332 application data for the remainder of the TCP connection. (Note: the 333 "submissions" service name is defined in section 10.3 of this 334 document, and follows the usual convention that the name of a service 335 layered on top of Implicit TLS consists of the name of the service as 336 used without TLS, with an "s" appended.) 338 The STARTTLS mechanism on port 587 is relatively widely deployed due 339 to the situation with port 465 (discussed in Section 11.5). This 340 differs from IMAP and POP services where implicit TLS is more widely 341 deployed on servers than STARTTLS. It is desirable to migrate MUA 342 software to implicit TLS over time for consistency as well as the 343 reasons discussed elsewhere in this document. However, to maximize 344 use of encryption for submission it is desirable to support both 345 mechanisms for Message Submission over TLS for a transition period of 346 several years. As a result, clients and servers SHOULD implement 347 both STARTTLS on port 587 and implicit TLS on port 465 for this 348 transition period. Note that there is no significant difference 349 between the security properties of STARTTLS on port 587 and implicit 350 TLS on port 465 if the implementations are correct and both client 351 and server are configured to require successful negotiation of TLS 352 prior to message submission (as required in Section 9.1). 354 Note that the submissions port provides access to a Mail Submission 355 Agent (MSA) as defined in [RFC6409] so requirements and 356 recommendations for MSAs in that document apply to the submissions 357 port, including the requirement to implement SMTP AUTH [RFC4954]. 359 See Section 9.1.1 for additional information on client certificate 360 authentication. See Section 11.5 for port registration information. 362 4.4. Implicit TLS Connection Closure for POP, IMAP and SMTP 364 When a client or server wishes to close the connection, it SHOULD 365 initiate the exchange of TLS close alerts before TCP connection 366 termination. The client MAY, after sending a TLS close alert, 367 gracefully close the TCP connection without waiting for a TLS 368 response from the server. 370 5. Email Security Upgrading Using Security Latches 372 Once an improved email security mechanism is deployed and ready for 373 general use, it is desirable to continue using it for all future 374 email service. For example, TLS is widely deployed in email 375 software, but use of TLS is often not required. At the time this is 376 written, deployed mail user agents (MUAs) [RFC5598] usually make a 377 determination if TLS is available when an account is first configured 378 and may require use of TLS with that account if and only if it was 379 initially available. If the service provider makes TLS available 380 after initial client configuration, many MUAs will not notice the 381 change. 383 Alternatively, a security feature may be purely opportunistic and 384 thus subject to downgrade attacks. For example, at the time this was 385 written, most TLS stacks that support TLS 1.2 will use an older TLS 386 version if the peer does not support TLS 1.2 and some do so without 387 alerting the client of the reduced security. Thus a variety of 388 active attacks could cause the loss of TLS 1.2 benefits. Only if 389 client policy is upgraded to require TLS 1.2 can the client prevent 390 all downgrade attacks. However, this sort of security policy upgrade 391 will be ignored by most users unless it is automated. 393 This section describes a mechanism, called "security latches", which 394 is designed to permit an MUA to recognize when a service provider has 395 committed to provide certain server security features, and that it's 396 safe for the client to change its configuration for that account to 397 require that such features be present in future sessions with that 398 server. When an MUA implements both confidentiality assurance levels 399 and security latches, then both the end-user and the service provider 400 independently have the ability to improve the end-user's 401 confidentiality. 403 Note that security latches are a mechanism similar to HTTP Strict 404 Transport Security (HSTS) [RFC6797] but are extensible. 406 5.1. Email Security Tags 408 Each security latch is given a name known as an email security tag. 409 An email security tag is a short alphanumeric token that represents a 410 security facility that can be used by an IMAP, POP or SMTP Submission 411 session. When a server advertises a security tag it is making a 412 commitment to support that security facility indefinitely and 413 recommending that the client save that security tag with the account 414 configuration and require that security feature for future 415 connections to that server. When a security tag is saved by the 416 client in this way, it is then considered latched. For the "tls11" 417 and/or "tls12" tags, the client SHOULD refuse to connect to the 418 server unless the appropriate level of TLS is successfully 419 negotiated. The client SHOULD NOT latch tags unless they are 420 advertised by the server, TLS is active and the client successfully 421 authenticates the server with the TLS session. Once a security tag 422 is latched, all subsequent connections to that host require that 423 security feature. For this confidentiality protection to work as 424 desired clients MUST NOT offer a click-through-to-connect action when 425 unable to achieve connection security matching the latched security 426 tags. 428 An identifier for a security tag has the following formal syntax: 430 security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_") 432 5.2. Initial Set of Email Security Tags 434 This section describes an initial set of email security tags. The 435 IANA Considerations Section 11 defines a registry so that more tags 436 can be defined in the future. The initial set of tags are defined in 437 Section 11.2 and include tls11, tls12, tls-cert and tls-dane-tlsa. 439 5.3. Server DEEP Status 441 Servers supporting this extension MUST advertise a DEEP status. This 442 status includes a list of security-tags the server administrator has 443 explicitly configured as recommended for use by end-users (the list 444 MAY be empty), an optional https Uniform Resource Locator (URL) 445 [RFC2818] that the client can save and subsequently resolve for the 446 user in the event of a security connection problem, and the DEEP 447 status can be extended by future updates to this specification. DEEP 448 status has the following formal syntax: 450 EXTCHAR = 0x20-21 / 0x23-2E / 0x30-3B / 0x3D-40 451 / 0x5B-60 / 0x7B-7E 452 ; printable characters excluding " \ < and ALPHA 454 deep-extend = EXTCHAR *(EXTCHAR / ALPHA / "<") 455 ; clients MUST ignore, for future extensibility 457 deep-status = [deep-tag *(SP deep-tag)] 459 deep-tag = deep-https / security-tag / deep-extend 461 deep-https = "<" ">" 463 The syntax for a Uniform Resource Identifier (URI) is defined in 464 [RFC3986]. Protocol extensions to advertise DEEP status are defined 465 in Section 7. 467 If the client successfully negotiates TLS and authenticates the 468 server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with 469 channel bindings [RFC5802]), then the client SHOULD record the 470 server's DEEP status information in the account configuration with 471 the server's hostname. Otherwise, the client SHOULD ignore the 472 server-provided DEEP status. 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_ECDHE_RSA_WITH_AES_128_GCM_SHA256) 496 included in the TLS cipher suite registry. In the event the 497 implementation does not know the name of the cipher suite (a 498 situation that should be remedied promptly), a four-digit hexadecimal 499 cipher suite 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 "tls11 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 "tls11 ") 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 "tls11 tls-cert" "security-tags" "tls12" 610 "tls" "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256") 611 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 612 "tls11 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 tls11 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 tls12 tls-cert 698 S: 250-BURL imap 699 S: 250 SIZE 0 700 C: CLIENT name=demo_submit version=1.5 latch=tls11,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. Account Setup Considerations 726 8.1. Use of SRV records in Establishing Configuration 728 This section updates [RFC6186] by changing the preference rules and 729 adding a new SRV service label _submissions._tcp to refer to Message 730 Submission with implicit TLS. 732 User-configurable MUAs SHOULD support use of [RFC6186] for account 733 setup. However, when using configuration information obtained by 734 this method, MUAs SHOULD default to a high confidentiality assurance 735 level, unless the user has explicitly requested reduced 736 confidentiality. This will have the effect of causing the MUA to 737 ignore advertised configurations that do not support TLS, even when 738 those advertised configurations have a higher priority than other 739 advertised configurations. 741 When using [RFC6186] configuration information, Mail User Agents 742 SHOULD NOT automatically establish new configurations that do not 743 require TLS for all servers, unless there are no advertised 744 configurations using TLS. If such a configuration is chosen, prior 745 to attempting to authenticate to the server or use the server for 746 message submission, the MUA SHOULD warn the user that traffic to that 747 server will not be encrypted and that it will therefore likely be 748 intercepted by unauthorized parties. The specific wording is to be 749 determined by the implementation, but it should adequately capture 750 the sense of risk given the widespread incidence of mass surveillance 751 of email traffic. 753 When establishing a new configuration for connecting to an IMAP, POP, 754 or SMTP Submission server, an MUA SHOULD NOT blindly trust SRV 755 records unless they are signed by DNSSEC and have a valid signature. 756 Instead, the MUA SHOULD warn the user that the DNS-advertised 757 mechanism for connecting to the server is not authenticated, and 758 request the user to manually verify the connection details by 759 reference to his or her mail service provider's documentation. 761 Similarly, an MUA MUST NOT consult SRV records to determine which 762 servers to use on every connection attempt, unless those SRV records 763 are signed by DNSSEC and have a valid signature. However, an MUA MAY 764 consult SRV records from time to time to determine if an MSP's server 765 configuration has changed, and alert the user if it appears that this 766 has happened. This can also serve as a means to encourage users to 767 upgrade their configurations to require TLS if and when their MSPs 768 support it. 770 8.2. Certificate Pinning 772 During account setup, the MUA will identify servers that provide 773 account services such as mail access and mail submission (the 774 previous section describes one way to do this). The certificates for 775 these servers are verified using the rules described in 776 [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. In the event the 777 certificate does not validate due to an expired certificate, lack of 778 appropriate chain of trust or lack of identifier match, the MUA MAY 779 create a persistent binding between that certificate and the saved 780 host name for the server. This is called certificate pinning. 781 Certificate pinning is only appropriate during account setup and MUST 782 NOT be offered in response to a failed certificate validation for an 783 existing account. An MUA that allows certificate pinning MUST NOT 784 allow a certificate pinned for one account to validate connections 785 for other accounts. 787 A pinned certificate is subject to a man-in-the-middle attack at 788 account setup time, and lacks a mechanism to revoke or securely 789 refresh the certificate. Therefore use of a pinned certificate does 790 not provide a high confidentiality assurance and an MUA MUST NOT 791 indicate a high level for an account or connection using a pinned 792 certificate. Additional advice on certificate pinning is present in 793 [RFC6125]. 795 9. Implementation Requirements 797 This section details requirements for implementations of electronic 798 mail protocol clients and servers. A requirement for a client or 799 server implementation to support a particular feature is not the same 800 thing as a requirement that a client or server running a conforming 801 implementation be configured to use that feature. Requirements for 802 Mail Service Providers (MSPs) are distinct from requirements for 803 protocol implementations, and are listed in a separate section. 805 9.1. All Implementations (Client and Server) 807 These requirements apply to MUAs as well as POP, IMAP and SMTP 808 Submission servers. 810 o All implementations MUST be configurable to support implicit TLS 811 using the TLS 1.2 protocol or later [RFC5246]. 813 o All implementations MUST implement the recommended cipher suites 814 described in [RFC7525] or a future BCP or standards track revision 815 of that document. 817 o All implementations MUST be configurable to require TLS before 818 performing any operation other than capability discovery and 819 STARTTLS. 821 o The IMAP specification [RFC3501] is hereby modified to revoke the 822 second paragraph of section 11.1 and replace it with the text from 823 the first three bullet items in this list. 825 o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is 826 modified to revoke section 2.1 and replace it with the text from 827 the first three bullet items in this list. 829 o The standard for Message Submission [RFC6409] is updated to add 830 the first three bullet items above to section 4.3 as well as to 831 require implementation of the TLS server identity check as 832 described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. 834 9.1.1. Client Certificate Authentication 836 MUAs and mail servers MAY implement client certificate authentication 837 on the implicit TLS port. Servers MUST NOT request a client 838 certificate during the TLS handshake unless the server is configured 839 to accept some client certificates as sufficient for authentication 840 and the server has the ability to determine a mail server 841 authorization identity matching such certificates. How to make this 842 determination is presently implementation specific. Clients MUST NOT 843 provide a client certificate during the TLS handshake unless the 844 server requests one and the client has determined the certificate can 845 be safely used with that specific server, OR the client has been 846 explicitly configured by the user to use that particular certificate 847 with that server. How to make this determination is presently 848 implementation specific. If the server accepts the client's 849 certificate as sufficient for authorization, it MUST enable the SASL 850 EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH 851 greeting instead of enabling SASL EXTERNAL. A client supporting 852 client certificate authentication with implicit TLS MUST implement 853 the SASL EXTERNAL [RFC4422] mechanism using the appropriate 854 authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP 855 Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]). 857 9.2. Mail Server Implementation Requirements 859 These requirements apply to servers that implement POP, IMAP or SMTP 860 Submission. 862 o Servers MUST implement the DEEP extension described in Section 7 864 o IMAP and SMTP submission servers SHOULD implement and be 865 configurable to support STARTTLS. This enables discovery of new 866 TLS availability, and can increase usage of TLS by legacy clients. 868 o Servers MUST NOT advertise STARTTLS if it is unlikely to succeed 869 based on server configuration (e.g., there is no server 870 certificate installed). 872 o SMTP message submission servers that have negotiated TLS SHOULD 873 add a Received header field to the message including the tls 874 clause described in Section 6. 876 o Servers MUST be configurable to include the TLS cipher information 877 in any connection or user logging or auditing facility they 878 provide. 880 9.3. Mail User Agent Implementation Requirements 882 This section describes requirements on Mail User Agents (MUAs) using 883 IMAP, POP, and/or Submission protocols. Note: Requirements 884 pertaining to use of Submission servers are also applicable to use of 885 SMTP servers (e.g., port 25) for mail submission. 887 o User agents SHOULD indicate to users at configuration time, the 888 expected level of confidentiality based on appropriate security 889 inputs such as which security latches are pre-set, the number of 890 trust anchors, certificate validity, use of an extended validation 891 certificate, TLS version supported, and TLS cipher suites 892 supported by both server and client. This indication SHOULD also 893 be present when editing or viewing account configuration. 895 o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes 896 available for a protocol and set the tls11 latch if the server 897 advertises the tls11 security tag after a successful TLS 898 negotiation. 900 o Whenever requested to establish any configuration that does not 901 require both TLS and server certificate verification to talk to a 902 server or account, an MUA SHOULD warn its user that his or her 903 mail traffic (including password, if applicable) will be exposed 904 to attackers, and give the user an opportunity to abort the 905 connection prior to transmission of any such password or traffic. 907 o MUAs SHOULD implement the "tls12" security latch (the TLS library 908 has to provide an API that controls permissible TLS versions and 909 communicates the negotiated TLS protocol version to the 910 application for this to be possible). 912 o See Section 3 for additional requirements. 914 9.4. Non-configurable MUAs and nonstandard access protocols 916 MUAs which are not configurable to use user-specified servers MUST 917 implement TLS or similarly other strong encryption mechanism when 918 communicating with their mail servers. This generally applies to 919 MUAs that are pre-configured to operate with one or more specific 920 services, whether or not supplied by the vendor of those services. 922 MUAs using protocols other than IMAP, POP, and Submission to 923 communicate with mail servers, MUST implement TLS or other similarly 924 robust encryption mechanism in conjunction with those protocols. 926 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 928 There are multiple ways to connect an Anti-Virus and/or Anti-Spam 929 (AVAS) service to a mail server. Some mechanisms, such as the de- 930 facto milter protocol do not impact DEEP. However, some services use 931 an SMTP relay proxy that intercepts mail at the application layer to 932 perform a scan and proxy or forward to another MTA. Deploying AVAS 933 services in this way can cause many problems [RFC2979] including 934 direct interference with DEEP and confidentiality or security 935 reduction. An AVAS product or service is considered DEEP compliant 936 if all IMAP, POP and SMTP-related software it includes is DEEP 937 compliant and it advertises and supports all security latches that 938 the actual servers advertise. 940 Note that end-to-end email encryption prevents AVAS software and 941 services from using email content as part of a spam or virus 942 assessment. Furthermore, while DEEP high confidentiality assurance 943 can prevent a man-in-the-middle from introducing spam or virus 944 content between the MUA and Submission server, it does not prevent 945 other forms of client or account compromise so use of AVAS services 946 for submitted email remains necessary. 948 10. Mail Service Provider Requirements 950 This section details requirements for providers of IMAP, POP, and/or 951 SMTP submission services, for providers who claim to conform to this 952 specification. 954 10.1. Server Requirements 956 Mail Service Providers MUST use server implementations that conform 957 to this specification. 959 10.2. MSPs MUST provide Submission Servers 961 This document updates the advice in [RFC5068] by making Implicit TLS 962 on port 465 the preferred submission port. 964 Mail Service Providers that accept mail submissions from end-users 965 using the Internet Protocol MUST provide one or more SMTP Submission 966 servers for this purpose, separate from the SMTP servers used to 967 process incoming mail. Those submission servers MUST be configured 968 to support Implicit TLS on port 465 and SHOULD support STARTTLS if 969 port 587 is used. 971 MSPs MAY also support submission of messages via one or more 972 designated SMTP servers to facilitate compatibility with legacy MUAs. 974 Discussion: SMTP servers used to accept incoming mail or to relay 975 mail are expected to accept mail in cleartext. This is incompatible 976 with the purpose of this memo which is to encourage encryption of 977 traffic between mail servers. There is no such requirement for mail 978 submission servers to accept mail in cleartext or without 979 authentication. For other reasons, use of separate SMTP submission 980 servers has been best practice for many years. 982 10.3. TLS Server Certificate Requirements 984 MSPs MUST maintain valid server certificates for all servers. Those 985 server certificates SHOULD present DNS-IDs and SRV-IDs conforming to 986 [RFC6125] and which will be recognized by MUAs meeting the 987 requirements of that specification. In addition, those server 988 certificates MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for 989 compatibility with existing MUAs. 991 If a protocol server provides service for more than one mail domain, 992 it MAY use a separate IP address for each domain and/or a server 993 certificate that advertises multiple domains. This will generally be 994 necessary unless and until it is acceptable to impose the constraint 995 that the server and all clients support the Server Name Indication 996 extension to TLS [RFC6066]. 998 10.4. Recommended DNS records for mail protocol servers 1000 This section discusses not only the DNS records that are recommended, 1001 but also implications of DNS records for server configuration and TLS 1002 server certificates. 1004 10.4.1. MX records 1006 It is recommended that MSPs advertise MX records for handling of 1007 inbound mail (instead of relying entirely on A or AAAA records), and 1008 that those MX records be signed using DNSSEC. This is mentioned here 1009 only for completeness, as handling of inbound mail is out of scope 1010 for this document. 1012 10.4.2. SRV records 1014 MSPs SHOULD advertise SRV records to aid MUAs in determination of 1015 proper configuration of servers, per the instructions in [RFC6186]. 1017 MSPs SHOULD advertise servers that support Implicit TLS in preference 1018 to those which support cleartext and/or STARTTLS operation. 1020 10.4.3. DNSSEC 1022 All DNS records advertised by an MSP as a means of aiding clients in 1023 communicating with the MSP's servers, SHOULD be signed using DNSSEC. 1025 10.4.4. TLSA records 1027 MSPs SHOULD advertise TLSA records to provide an additional trust 1028 anchor for public keys used in TLS server certificates. However, 1029 TLSA records MUST NOT be advertised unless they are signed using 1030 DNSSEC. 1032 10.5. MSP Server Monitoring 1034 MSPs SHOULD regularly and frequently monitor their various servers to 1035 make sure that: TLS server certificates remain valid and are not 1036 about to expire, TLSA records match the public keys advertised in 1037 server certificates, are signed using DNSSEC, server configurations 1038 are consistent with SRV advertisements, and DNSSEC signatures are 1039 valid and verifiable. Failure to detect expired certificates and DNS 1040 configuration errors in a timely fashion can result in significant 1041 loss of service for an MSP's users and a significant support burden 1042 for the MSP. 1044 10.6. Advertisement of DEEP status 1046 MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and 1047 an HTTPS URL that can be used to inform clients of service outages or 1048 problems impacting client confidentiality. Note that advertising 1049 tls-cert is a commitment to maintain and renew server certificates. 1051 10.7. Require TLS 1053 New servers and services SHOULD be configured to require TLS unless 1054 it's necessary to support legacy clients or existing client 1055 configurations. 1057 10.8. Changes to Internet Facing Servers 1059 When an MSP changes the Internet Facing Servers providing mail access 1060 and mail submission services, including SMTP-based spam/virus 1061 filters, it is generally necessary to support the same and/or a newer 1062 version of TLS and the same security tags that were previously 1063 advertised. 1065 11. IANA Considerations 1067 11.1. Security Tag Registry 1069 IANA shall create (has created) the registry "Email Security Tags". 1070 This registry is a single table and will use an expert review process 1071 [RFC5226]. Each registration will contain the following fields: 1073 Name: The name of the security tag. This follows the security-tag 1074 ABNF. 1076 Description: This describes the meaning of the security tag and the 1077 conditions under which the tag is latched. 1079 Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. 1081 Reference: Optional reference to specification. 1083 Submitter: The identify of the submitter or submitters. 1085 Change Controller: The identity of the change controller for the 1086 registration. This will be "IESG" in case of registrations in 1087 IETF-produced documents. 1089 The expert reviewer will verify the tag name follows the ABNF, and 1090 that the description field is clear, unambiguous, does not overlap 1091 existing deployed technology, does not create security problems and 1092 appropriately considers interoperability issues. Email security tags 1093 intended for LIMITED USE have a lower review bar (interoperability 1094 and overlap issues are less of a concern). The reviewer may approve 1095 a registration, reject for a stated reason or recommend the proposal 1096 have standards track review due to importance or difficult 1097 subtleties. 1099 Standards-track registrations may be updated if the relevant 1100 standards are updated as a consequence of that action. Non- 1101 standards-track entries may be updated by the listed change 1102 controller. The entry's name and submitter may not be changed. In 1103 exceptional cases, any aspect of any registered entity may be updated 1104 at the direction of the IESG (for example, to correct a conflict). 1106 11.2. Initial Set of Security Tags 1108 This document defines four initial security tags for the security tag 1109 registry as follows: 1111 Name: tls11 1113 Description: This indicates TLS version 1.1 [RFC4346] or later was 1114 negotiated successfully including negotiation of a strong 1115 encryption layer with a symmetric key of at least 128 bits. This 1116 tag indicates the server certificate was valid but does not 1117 indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE 1118 [RFC6698]). This tag is latched if the client sees this tag in 1119 the advertised server DEEP status provided after successfully 1120 negotiating TLS version 1.0 or later. 1122 Intended Usage: COMMON 1124 Reference: RFC XXXX (this document once published) 1126 Submitter: Authors of this document 1127 Change Controller: IESG 1129 Name: tls12 1131 Description: This indicates TLS version 1.2 [RFC5246] or later was 1132 negotiated successfully including negotiation of a strong 1133 encryption layer with a symmetric key of at least 128 bits. This 1134 tag indicates the server certificate was valid but does not 1135 indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE 1136 [RFC6698]). This tag is latched if the client sees this tag in 1137 the advertised server DEEP status provided after successfully 1138 negotiating TLS version 1.2 or later. 1140 Intended Usage: COMMON 1142 Reference: RFC XXXX (this document once published) 1144 Submitter: Authors of this document 1146 Change Controller: IESG 1148 Name: tls-cert 1150 Description: This tag indicates that TLS was successfully negotiated 1151 and the server certificate was successfully verified by the client 1152 using PKIX [RFC5280] and the server certificate identity was 1153 verified using the algorithm appropriate for the protocol (see 1154 Section 4). This tag is latched if the client sees this tag in 1155 the advertised server DEEP status after successfully negotiating 1156 TLS and verifying the certificate and server identity. 1158 Intended Usage: COMMON 1160 Reference: RFC XXXX (this document once published) 1162 Submitter: Authors of this document 1164 Change Controller: IESG 1166 Name: tls-dane-tlsa 1168 Description: This tag indicates that TLS was successfully negotiated 1169 and the server certificate was successfully verified by the client 1170 using the procedures described in [RFC6698] and the server 1171 certificate identity was verified using the algorithm appropriate 1172 for the protocol (see Section 4). This tag is latched if the 1173 client sees this tag in the advertised server DEEP status after 1174 successfully negotiating TLS and verifying the certificate and 1175 server identity. 1177 Intended Usage: COMMON 1179 Reference: RFC XXXX (this document once published) 1181 Submitter: Authors of this document 1183 Change Controller: IESG 1185 11.3. POP3S Port Registration Update 1187 IANA is asked to update the registration of the TCP well-known port 1188 995 using the following template ([RFC6335]): 1190 Service Name: pop3s 1191 Transport Protocol: TCP 1192 Assignee: IETF 1193 Contact: IESG 1194 Description: POP3 over TLS protocol 1195 Reference: RFC XXXX (this document once published) 1197 Service Name: pop3s 1198 Transport Protocol: TCP 1199 Assignee: IETF 1200 Contact: IESG 1201 Description: POP3 over TLS protocol 1202 Reference: RFC XXXX (this document once published) 1204 11.4. IMAPS Port Registration Update 1206 IANA is asked to update the registration of the TCP well-known port 1207 993 using the following template ([RFC6335]): 1209 Service Name: imaps 1210 Transport Protocol: TCP 1211 Assignee: IETF 1212 Contact: IESG 1213 Description: IMAP over TLS protocol 1214 Reference: RFC XXXX (this document once published) 1216 Service Name: imaps 1217 Transport Protocol: TCP 1218 Assignee: IETF 1219 Contact: IESG 1220 Description: IMAP over TLS protocol 1221 Reference: RFC XXXX (this document once published) 1223 11.5. Submissions Port Registration 1225 IANA is asked to assign an alternate usage of port 465 in addition to 1226 the current assignment using the following template ([RFC6335]): 1228 Service Name: submissions 1229 Transport Protocol: TCP 1230 Assignee: IETF 1231 Contact: IESG 1232 Description: Message Submission over TLS protocol 1233 Reference: RFC XXXX (this document once published) 1235 Service Name: submissions 1236 Transport Protocol: TCP 1237 Assignee: IETF 1238 Contact: IESG 1239 Description: Message Submission over TLS protocol 1240 Reference: RFC XXXX (this document once published) 1242 This is a one time procedural exception to the rules in RFC 6335. 1243 This requires explicit IESG approval and does not set a precedent. 1244 Historically, port 465 was briefly registered as the "smtps" port. 1245 This registration made no sense as the SMTP transport MX 1246 infrastructure has no way to specify a port so port 25 is always 1247 used. As a result, the registration was revoked and was subsequently 1248 reassigned to a different service. In hindsight, the "smtps" 1249 registration should have been renamed or reserved rather than 1250 revoked. Unfortunately, some widely deployed mail software 1251 interpreted "smtps" as "submissions" [RFC6409] and used that port for 1252 email submission by default when an end-user requests security during 1253 account setup. If a new port is assigned for the submissions 1254 service, email software will either continue with unregistered use of 1255 port 465 (leaving the port registry inaccurate relative to de-facto 1256 practice and wasting a well-known port), or confusion between the de- 1257 facto and registered ports will cause harmful interoperability 1258 problems that will deter use of TLS for message submission. The 1259 authors believe both of these outcomes are less desirable than a wart 1260 in the registry documenting real-world usage of a port for two 1261 purposes. Although STARTTLS-on-port-587 has deployed, it has not 1262 replaced deployed use of implicit TLS submission on port 465. 1264 11.6. DEEP IMAP Capability 1266 This document adds the DEEP capability to the IMAP capabilities 1267 registry. This is described in Section 7.1. 1269 11.7. DEEP POP3 Capability 1271 This document adds the DEEP capability to the POP3 capabilities 1272 registry. 1274 CAPA Tag: DEEP 1276 Arguments: deep-status 1278 Added Commands: none 1280 Standard Commands affected: none 1282 Announced status / possible differences: both / may change after 1283 STLS 1285 Commands Valid in States: N/A 1287 Specification Reference: This document 1289 Discussion: See Section 7.2. 1291 11.8. DEEP SMTP EHLO Keyword 1293 This document adds the DEEP EHLO Keyword to the SMTP Service 1294 Extension registry. This is described in Section 7.3. 1296 11.9. SMTP Enhanced Status Code 1298 This document adds the following entry to the "SMTP Enhanced Status 1299 Codes" registry created by [RFC5248]. 1301 Code: X.7.TBD (IANA, please assign the next available number) 1303 Sample Text: Message Transport Failed due to missing required 1304 security. 1306 Associated Basic Status Code: 450, 454, 550, 554 1308 Description This code indicates an SMTP server was unable to forward 1309 a message to the next host necessary for delivery because it 1310 required a higher level of transport security or confidentiality 1311 than was available. The temporary form of this error is preferred 1312 in case the problem is caused by a temporary administrative error 1313 such as an expired server certificate. 1315 Reference This document 1317 Submitter C. Newman 1319 Change Controller IESG 1321 11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 1323 This document adds the following entry to the "Additional-registered- 1324 clauses" sub-registry of the "MAIL Parameters" registry, created by 1325 [RFC5321]: 1327 Clause Name: tls 1329 Description: Indicates the TLS cipher suite used for a transport 1330 connection. 1332 Syntax Summary: See tls-cipher ABNF Section 6 1334 Reference: This document. 1336 12. Security Considerations 1338 This entire document is about security considerations. In general, 1339 this is targeted to improve mail confidentiality and to mitigate 1340 threats external to the email system such as network-level snooping 1341 or interception; this is not intended to mitigate active attackers 1342 who have compromised service provider systems. 1344 It could be argued that sharing the name and version of the client 1345 software with the server has privacy implications. Although 1346 providing this information is not required, it is encouraged so that 1347 mail service providers can more effectively inform end-users running 1348 old clients that they need to upgrade to protect their security, or 1349 know which clients to use in a test deployment prior to upgrading a 1350 server to have higher security requirements. 1352 13. References 1354 13.1. Normative References 1356 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1357 STD 53, RFC 1939, May 1996. 1359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1360 Requirement Levels", BCP 14, RFC 2119, March 1997. 1362 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 1363 Mechanism", RFC 2449, November 1998. 1365 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1367 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, 1368 October 2000. 1370 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1371 Transport Layer Security", RFC 3207, February 2002. 1373 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1374 4rev1", RFC 3501, March 2003. 1376 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1377 for Delivery Status Notifications", RFC 3464, 1378 January 2003. 1380 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1381 Resource Identifier (URI): Generic Syntax", STD 66, 1382 RFC 3986, January 2005. 1384 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol 1385 (POP3) Simple Authentication and Security Layer (SASL) 1386 Authentication Mechanism", RFC 5034, July 2007. 1388 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1389 Finch, "Email Submission Operations: Access and 1390 Accountability Requirements", BCP 134, RFC 5068, 1391 November 2007. 1393 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1394 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1396 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1397 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1399 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1400 Mail System Status Codes", BCP 138, RFC 5248, June 2008. 1402 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1403 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1404 May 2008. 1406 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1407 Housley, R., and W. Polk, "Internet X.509 Public Key 1408 Infrastructure Certificate and Certificate Revocation List 1409 (CRL) Profile", RFC 5280, May 2008. 1411 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1412 October 2008. 1414 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1415 October 2008. 1417 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1418 Verification of Domain-Based Application Service Identity 1419 within Internet Public Key Infrastructure Using X.509 1420 (PKIX) Certificates in the Context of Transport Layer 1421 Security (TLS)", RFC 6125, March 2011. 1423 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1424 Submission/Access Services", RFC 6186, March 2011. 1426 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1427 STD 72, RFC 6409, November 2011. 1429 [I-D.ietf-uta-email-tls-certs] 1430 Melnikov, A., "Updated TLS Server Identity Check Procedure 1431 for Email Related Protocols", 1432 draft-ietf-uta-email-tls-certs-03 (work in progress), 1433 June 2015. 1435 [I-D.ietf-dane-smtp-with-dane] 1436 Dukhovni, V. and W. Hardaker, "SMTP security via 1437 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02 1438 (work in progress), October 2013. 1440 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1441 "Recommendations for Secure Use of Transport Layer 1442 Security (TLS) and Datagram Transport Layer Security 1443 (DTLS)", BCP 195, RFC 7525, May 2015. 1445 13.2. Informative References 1447 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1448 RFC 2595, June 1999. 1450 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1451 Firewalls", RFC 2979, October 2000. 1453 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 1454 Registration", RFC 3848, July 2004. 1456 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 1457 September 2004. 1459 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1460 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1462 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1463 Security Layer (SASL)", RFC 4422, June 2006. 1465 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1466 for Authentication", RFC 4954, July 2007. 1468 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1469 July 2009. 1471 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1472 "Salted Challenge Response Authentication Mechanism 1473 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 1475 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 1476 Managing Sieve Scripts", RFC 5804, July 2010. 1478 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1479 Extension Definitions", RFC 6066, January 2011. 1481 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1482 Cheshire, "Internet Assigned Numbers Authority (IANA) 1483 Procedures for the Management of the Service Name and 1484 Transport Protocol Port Number Registry", BCP 165, 1485 RFC 6335, August 2011. 1487 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1488 of Named Entities (DANE) Transport Layer Security (TLS) 1489 Protocol: TLSA", RFC 6698, August 2012. 1491 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1492 Transport Security (HSTS)", RFC 6797, November 2012. 1494 Appendix A. Design Considerations 1496 This section is not normative. 1498 The first version of this was written independently from 1499 draft-moore-email-tls-00.txt; subsequent versions merge ideas from 1500 both drafts. 1502 One author of this document was also the author of RFC 2595 that 1503 became the standard for TLS usage with POP and IMAP, and the other 1504 author was perhaps the first to propose that idea. In hindsight both 1505 authors now believe that that approach was a mistake. At this point 1506 the authors believe that while anything that makes it easier to 1507 deploy TLS is good, the desirable end state is that these protocols 1508 always use TLS, leaving no need for a separate port for cleartext 1509 operation except to support legacy clients while they continue to be 1510 used. The separate port model for TLS is inherently simpler to 1511 implement, debug and deploy. It also enables a "generic TLS load- 1512 balancer" that accepts secure client connections for arbitrary foo- 1513 over-TLS protocols and forwards them to a server that may or may not 1514 support TLS. Such load-balancers cause many problems because they 1515 violate the end-to-end principle and the server loses the ability to 1516 log security-relevant information about the client unless the 1517 protocol is designed to forward that information (as this 1518 specification does for the cipher suite). However, they can result 1519 in TLS deployment where it would not otherwise happen which is a 1520 sufficiently important goal that it overrides the problems. 1522 Although STARTTLS appears only slightly more complex than separate- 1523 port TLS, we again learned the lesson that complexity is the enemy of 1524 security in the form of the STARTTLS command injection vulnerability 1525 (CERT vulnerability ID #555316). Although there's nothing inherently 1526 wrong with STARTTLS, the fact it resulted in a common implementation 1527 error (made independently by multiple implementers) suggests it is a 1528 less secure architecture than Implicit TLS. 1530 Section 7 of RFC 2595 critiques the separate-port approach to TLS. 1531 The first bullet was a correct critique. There are proposals in the 1532 http community to address that, and use of SRV records as described 1533 in RFC 6186 resolves that critique for email. The second bullet is 1534 correct as well, but not very important because useful deployment of 1535 security layers other than TLS in email is small enough to be 1536 effectively irrelevant. The third bullet is incorrect because it 1537 misses the desirable option of "use and latch-on TLS if available". 1538 The fourth bullet may be correct, but is not a problem yet with 1539 current port consumption rates. The fundamental error was 1540 prioritizing a perceived better design based on a mostly valid 1541 critique over real-world deployability. But getting security and 1542 confidentiality facilities actually deployed is so important it 1543 should trump design purity considerations. 1545 Port 465 is presently used for two purposes: for submissions by a 1546 large number of clients and service providers and for the "urd" 1547 protocol by one vendor. Actually documenting this current state is 1548 controversial as discussed in the IANA considerations section. 1549 However, there is no good alternative. Registering a new port for 1550 submissions when port 465 is widely used for that purpose already 1551 will just create interoperability problems. Registering a port 1552 that's only used if advertised by an SRV record (RFC 6186) would not 1553 create interoperability problems but would require all client and 1554 server deployments and software to change significantly which is 1555 contrary to the goal of promoting more TLS use. Encouraging use of 1556 STARTTLS on port 587 would not create interoperability problems, but 1557 is unlikely to have impact on current undocumented use of port 465 1558 and makes the guidance in this document less consistent. The 1559 remaining option is to document the current state of the world and 1560 support future use of port 465 for submission as this increases 1561 consistency and ease-of-deployment for TLS email submission. 1563 Appendix B. Change Log 1565 Changes since draft-ietf-uta-email-deep-01: 1567 o Change text in tls11 and tls12 registrations to clarify 1568 certificate rules, including additional PKIX and DANE references. 1570 o Change from tls10 to tls11 (including reference) as the minimum. 1572 o Fix typo in example 5. 1574 o Remove open issues section; enough time has passed so not worth 1575 waiting for more input. 1577 Changes since draft-ietf-uta-email-deep-00: 1579 o Update and clarify abstract 1581 o use term confidentiality instead of privacy in most cases. 1583 o update open issues to request input for missing text. 1585 o move certificate pinning sub-section to account setup section and 1586 attempt to define it more precisely. 1588 o Add note about end-to-end encryption in AVAS section. 1590 o swap order of DNSSEC and TLSA sub-sections. 1592 o change meaning of 'tls10' and 'tls12' latches to require 1593 certificate validation. 1595 o Replace cipher suite advice with reference to RFC 7525. Change 1596 examples to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as cipher 1597 suite. 1599 o Add text to update IMAP, POP3 and Message Submission standards 1600 with newer TLS advice. 1602 o Add clearer text in introduction that this does not cover SMTP 1603 relay. 1605 o Update references to uta-tls-certs. 1607 o Add paragraph to Implicit TLS for SMTP Submission section 1608 recommending that STARTTLS also be implemented. 1610 Changes since draft-newman-email-deep-02: 1612 o Changed "privacy assurance" to "confidentiality assurance" 1614 o Changed "low privacy assurance" to "no confidentiality assurance" 1616 o Attempt to improve definition of confidentiality assurance level. 1618 o Add SHOULD indicate when MUA is showing list of mail accounts. 1620 o Add SHOULD NOT latch tls10, tls12 tags until TLS negotiated. 1622 o Removed sentence about deleting and re-creating the account in 1623 latch failure section. 1625 o Remove use of word "fallback" with respect to TLS version 1626 negotiation. 1628 o Added bullet about changes to Internet facing servers to MSP 1629 section. 1631 o minor wording improvements based on feedback 1633 Changes since -01: 1635 o Updated abstract, introduction and document structure to focus 1636 more on mail user agent privacy assurance. 1638 o Added email account privacy section, also moving section on 1639 account setup using SRV records to that section. 1641 o Finished writing IANA considerations section 1643 o Remove provisional concept and instead have server explicitly list 1644 security tags clients should latch. 1646 o Added note that rules for the submissions port follow the same 1647 rules as those for the submit port. 1649 o Reference and update advice in [RFC5068]. 1651 o Fixed typo in Client Certificate Authentication section. 1653 o Removed tls-pfs security latch and all mention of perfect forward 1654 secrecy as it was controversial. 1656 o Added reference to HSTS. 1658 Changes since -00: 1660 o Rewrote introduction to merge ideas from draft-moore-email-tls-00. 1662 o Added Implicit TLS section, Account configuration section and IANA 1663 port registration updates based on draft-moore-email-tls-00. 1665 o Add protocol details necessary to standardize implicit TLS for 1666 POP/IMAP/submission, using ideas from 1667 draft-melnikov-pop3-over-tls. 1669 o Reduce initial set of security tags based on feedback. 1671 o Add deep status concept to allow a window for software updates to 1672 be backed out before latches make that problematic, as well as to 1673 provide service providers with a mechanism they can use to assist 1674 customers in the event of a privacy failure. 1676 o Add DNS SRV section from draft-moore-email-tls-00. 1678 o Write most of the missing IANA considerations section. 1680 o Rewrite most of implementation requirements section based more on 1681 draft-moore-email-tls-00. Remove new cipher requirements for now 1682 because those may be dealt with elsewhere. 1684 Appendix C. Acknowledgements 1686 Thanks to Ned Freed for discussion of the initial latch concepts in 1687 this document. Thanks to Alexey Melnikov for 1688 draft-melnikov-pop3-over-tls-02, which was the basis of the POP3 1689 implicit TLS text. Thanks to Russ Housley, Alexey Melnikov and Dan 1690 Newman for review feedback. Thanks to Paul Hoffman for interesting 1691 feedback in initial conversations about this idea. 1693 Authors' Addresses 1695 Keith Moore 1696 Network Heretics 1697 PO Box 1934 1698 Knoxville, TN 37901 1699 US 1701 Email: moore@network-heretics.com 1703 Chris Newman 1704 Oracle 1705 440 E. Huntington Dr., Suite 400 1706 Arcadia, CA 91006 1707 US 1709 Email: chris.newman@oracle.com