idnits 2.17.1 draft-ietf-uta-email-deep-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The 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 (July 6, 2015) is 3210 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 2246 (Obsoleted by RFC 4346) 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 July 6, 2015 7 Expires: January 7, 2016 9 Deployable Enhanced Email Privacy (DEEP) 10 draft-ietf-uta-email-deep-01.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 January 7, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions and Terminology Used in This Document . . . . . . 4 58 3. Mail Account Confidentiality Assurance Level . . . . . . . . 4 59 3.1. High Confidentiality Assurance . . . . . . . . . . . . . 5 60 3.2. No Confidentiality Assurance . . . . . . . . . . . . . . 6 61 3.3. Other Confidentiality Assurance Levels . . . . . . . . . 6 62 4. Implicit TLS . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Implicit TLS for POP . . . . . . . . . . . . . . . . . . 7 64 4.2. Implicit TLS for IMAP . . . . . . . . . . . . . . . . . . 7 65 4.3. Implicit TLS for SMTP Submission . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 11 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. Account Setup Considerations . . . . . . . . . . . . . . . . 16 79 8.1. Use of SRV records in Establishing Configuration . . . . 16 80 8.2. Certificate Pinning . . . . . . . . . . . . . . . . . . . 17 81 9. Implementation Requirements . . . . . . . . . . . . . . . . . 18 82 9.1. All Implementations (Client and Server) . . . . . . . . . 18 83 9.1.1. Client Certificate Authentication . . . . . . . . . . 19 84 9.2. Mail Server Implementation Requirements . . . . . . . . . 19 85 9.3. Mail User Agent Implementation Requirements . . . . . . . 20 86 9.4. Non-configurable MUAs and nonstandard access protocols . 20 87 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and 88 Services . . . . . . . . . . . . . . . . . . . . . . . . 21 89 10. Mail Service Provider Requirements . . . . . . . . . . . . . 21 90 10.1. Server Requirements . . . . . . . . . . . . . . . . . . 21 91 10.2. MSPs MUST provide Submission Servers . . . . . . . . . . 21 92 10.3. TLS Server Certificate Requirements . . . . . . . . . . 22 93 10.4. Recommended DNS records for mail protocol servers . . . 22 94 10.4.1. MX records . . . . . . . . . . . . . . . . . . . . . 22 95 10.4.2. SRV records . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . 23 100 10.7. Require TLS . . . . . . . . . . . . . . . . . . . . . . 23 101 10.8. Changes to Internet Facing Servers . . . . . . . . . . . 23 102 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 103 11.1. Security Tag Registry . . . . . . . . . . . . . . . . . 24 104 11.2. Initial Set of Security Tags . . . . . . . . . . . . . . 24 105 11.3. POP3S Port Registration Update . . . . . . . . . . . . . 26 106 11.4. IMAPS Port Registration Update . . . . . . . . . . . . . 26 107 11.5. Submissions Port Registration . . . . . . . . . . . . . 27 108 11.6. DEEP IMAP Capability . . . . . . . . . . . . . . . . . . 27 109 11.7. DEEP POP3 Capability . . . . . . . . . . . . . . . . . . 27 110 11.8. DEEP SMTP EHLO Keyword . . . . . . . . . . . . . . . . . 28 111 11.9. SMTP Enhanced Status Code . . . . . . . . . . . . . . . 28 112 11.10. MAIL Parameters Additional-registered-clauses Sub- 113 Registry . . . . . . . . . . . . . . . . . . . . . . . . 28 114 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 115 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 116 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 117 13.2. Informative References . . . . . . . . . . . . . . . . . 31 118 Appendix A. Design Considerations . . . . . . . . . . . . . . . 32 119 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 33 120 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 34 121 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 36 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 124 1. Introduction 126 Software that provides email service via Internet Message Access 127 Protocol (IMAP) [RFC3501], Post Office Protocol (POP) [RFC1939] and/ 128 or Simple Mail Transfer Protocol (SMTP) Submission [RFC6409] usually 129 has Transport Layer Security (TLS) [RFC5246] support but often does 130 not use it in a way that maximizes end-user confidentiality. This 131 specification proposes changes to email software and deployments 132 intended to increase the use of TLS and 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 "tls10" 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 these two tags until TLS has 420 been successfully negotiated as described in the tag definition. If 421 the tags are advertised within an appropriate TLS-protected 422 connection, the client SHOULD latch these tags. Other security tags 423 are latched if they are advertised by the server, TLS is active and 424 the client successfully authenticates the server with the TLS 425 session. Once a security tag is latched, all subsequent connections 426 to that host require that security feature. For this confidentiality 427 protection to work as desired clients MUST NOT offer a click-through- 428 to-connect action when unable to achieve connection security matching 429 the latched security tags. 431 An identifier for a security tag has the following formal syntax: 433 security-tag = ALPHA *63(ALPHA / DIGIT / "-" / "_") 435 5.2. Initial Set of Email Security Tags 437 This section describes an initial set of email security tags. The 438 IANA Considerations Section 11 defines a registry so that more tags 439 can be defined in the future. The initial set of tags are defined in 440 Section 11.2 and include tls10, tls12, tls-cert and tls-dane-tlsa. 442 5.3. Server DEEP Status 444 Servers supporting this extension MUST advertise a DEEP status. This 445 status includes a list of security-tags the server administrator has 446 explicitly configured as recommended for use by end-users (the list 447 MAY be empty), an optional https Uniform Resource Locator (URL) 448 [RFC2818] that the client can save and subsequently resolve for the 449 user in the event of a security connection problem, and the DEEP 450 status can be extended by future updates to this specification. DEEP 451 status has the following formal syntax: 453 EXTCHAR = 0x20-21 / 0x23-2E / 0x30-3B / 0x3D-40 454 / 0x5B-60 / 0x7B-7E 455 ; printable characters excluding " \ < and ALPHA 457 deep-extend = EXTCHAR *(EXTCHAR / ALPHA / "<") 458 ; clients MUST ignore, for future extensibility 460 deep-status = [deep-tag *(SP deep-tag)] 462 deep-tag = deep-https / security-tag / deep-extend 464 deep-https = "<" ">" 466 The syntax for a Uniform Resource Identifier (URI) is defined in 467 [RFC3986]. Protocol extensions to advertise DEEP status are defined 468 in Section 7. 470 If the client successfully negotiates TLS and authenticates the 471 server (e.g., via tls-cert, tls-dane-tlsa or SCRAM-SHA1-PLUS with 472 channel bindings [RFC5802]), then the client SHOULD record the 473 server's DEEP status information in the account configuration with 474 the server's hostname. Otherwise, the client SHOULD ignore the 475 server-provided DEEP status except for the "tls10" and "tls12" 476 security tags. 478 5.4. Email Security Tag Latch Failures 480 When a security tag latch has been set for connections from a client 481 to a server and the property identified by that tag is no longer 482 available, this results in a connection failure. An MUA SHOULD 483 inform the user of a potential threat to their confidentiality and 484 offer to resolve a previously-recorded DEEP status https URL if one 485 is available. MUAs are discouraged from offering a lightweight 486 option to reset or ignore latches as this defeats the benefit they 487 provide to end users. 489 6. Recording TLS Cipher Suite in Received Header 491 The ESMTPS transmission type [RFC3848] provides trace information 492 that can indicate TLS was used when transferring mail. However, TLS 493 usage by itself is not a guarantee of confidentiality or security. 494 The TLS cipher suite provides additional information about the level 495 of security made available for a connection. This defines a new SMTP 496 "tls" Received header additional-registered-clause that is used to 497 record the TLS cipher suite that was negotiated for the connection. 498 The value included in this additional clause SHOULD be the registered 499 cipher suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) 500 included in the TLS cipher suite registry. In the event the 501 implementation does not know the name of the cipher suite (a 502 situation that should be remedied promptly), a four-digit hexadecimal 503 cipher suite identifier MAY be used. The ABNF for the field follows: 505 tls-cipher-clause = CFWS "tls" FWS tls-cipher 507 tls-cipher = tls-cipher-suite-name / tls-cipher-suite-hex 509 tls-cipher-name = ALPHA *(ALPHA / DIGIT / "_") 510 ; as registered in IANA cipher suite registry 512 tls-cipher-hex = "0x" 4HEXDIG 514 7. Extensions for DEEP Status and Reporting 516 This memo defines optional mechanisms for use by MUAs to communicate 517 DEEP status to servers and for servers to advertise available 518 latches. One purpose of such mechanisms is to permit servers to 519 determine which and how many clients have latched security 520 facilities, and thus, to permit operators to be aware of potential 521 impact to their users should support for such facilities be changed. 522 For IMAP, the existing ID command is extended to provide this 523 capability. For SMTP Submission, a new CLIENT command is defined. 524 No similar mechanism is defined for POP in this version of the memo 525 to keep POP simpler, but one may be added in the future if deemed 526 necessary. 528 In addition, for each of IMAP, POP, and SMTP, a new DEEP capability 529 is defined so the client can access the server's DEEP status. 531 7.1. IMAP DEEP Extension 533 When an IMAP server advertises the DEEP capability, that indicates 534 the IMAP server implements IMAP4 ID [RFC2971] with additional field 535 values defined here. This is grouped with the ID command because 536 that is the existing IMAP mechanism for clients to report data for 537 server logging, and provides a way for the server to report the DEEP 538 status. 540 deep From server to client, the argument to this ID field is the 541 server DEEP status. Servers MUST provide this information in 542 response to an ID command. 544 latch From client to server, this is a space-separated list of 545 security tags the client has latched for this server. Servers MAY 546 record this information so administrators know the expected latch- 547 related security properties of the client and can thus act to 548 avoid security latch failures (e.g., by renewing server 549 certificates on time, etc). 551 latch-fail From client to server, a space-separated list including 552 one or more security tag the client has latched that the client 553 was unable to achieve. This allows clients to report errors to 554 the server prior to terminating the connection to the server in 555 the event an acceptable security level is unavailable. 557 security-tags From client to server, this is a space-separated list 558 of security tags the client supports that are not latched. 560 tls Server-side IMAP proxies that accept TLS connections from 561 clients and connect in-the-clear over a fully private secure 562 network to the server SHOULD use this field to report the tls- 563 cipher (syntax as defined in Section 6) to the server. 565 IMAP clients SHOULD use the IMAP ID command to report latch failures 566 and determine the server DEEP status. Clients MAY use the ID command 567 to report other latch or security tag information. IMAP servers MUST 568 implement the ID command at least to report DEEP status to clients. 570 571 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 572 AUTH=SCRAM-SHA-1] hello 573 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" 574 "tls10 tls-cert" "security-tags" "tls12") 575 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 576 "") 577 S: a001 OK ID completed 579 Example 1 581 This example shows a client that successfully negotiated TLS version 582 1.0 or later and verified the server's certificate as required by 583 IMAP. The client supports TLS 1.2. However, even if the client 584 successfully negotiated TLS 1.2, it will not latch that security tag 585 automatically because the server did not advertise that tag. If the 586 client successfully validated the server certificate, it will latch 587 the provided URL. 589 590 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 591 AUTH=SCRAM-SHA-1] hello 592 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch-failure" 593 "tls-cert") 594 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 595 "tls10 ") 596 S: a001 OK ID completed 597 C: a002 LOGOUT 599 Example 2 601 This example shows a client that negotiated TLS, but was unable to 602 verify the server's certificate. The latch-failure informs the 603 server of this problem, at which point the client can disconnect. If 604 the client had previously latched a URI for security problems from 605 this server, it could offer to resolve that URI. However, the deep- 606 status in this exchange is ignored due to the latch failure. 608 610 S: * OK [CAPABILITY IMAP4rev1 DEEP ID AUTH=PLAIN 611 AUTH=SCRAM-SHA-1] hello 612 C: a001 ID ("name" "Demo Mail" "version" "1.5" "latch" 613 "tls10 tls-cert" "security-tags" "tls12" 614 "tls" "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256") 615 S: * ID ("name" "Demo Server" "version" "1.7" "deep-status" 616 "tls10 tls-cert ") 617 S: a001 OK ID completed 619 Example 3 621 This example shows the connection from an IMAP proxy to a back-end 622 server. The client connected to the proxy and sent the ID command 623 shown in example 1, and the proxy has added the "tls" item to the ID 624 command so the back-end server can log the cipher suite that was used 625 on the connection from the client. 627 7.2. POP DEEP Extension 629 POP servers supporting this specification MUST implement the POP3 630 extension mechanism [RFC2449]. POP servers MUST advertise the DEEP 631 capability with an argument indicating the server's DEEP status. 633 634 S: +OK POP server ready 635 C: CAPA 636 S: +OK Capability list follows 637 S: TOP 638 S: SASL PLAIN SCRAM-SHA-1 639 S: RESP-CODES 640 S: PIPELINING 641 S: UIDL 642 S: DEEP tls10 tls12 643 S: . 645 Example 4 647 After verifying the TLS server certificate and issuing CAPA, the 648 client can latch any or all of the DEEP status. If the client 649 connects to this same server later and has a security failure, the 650 client can direct the user's browser to the previously-latched URI 651 where the service provider may provide advice to the end user. 653 7.3. SMTP DEEP Extension 655 SMTP Submission servers supporting this specification MUST implement 656 the DEEP SMTP extension. The name of this extension is DEEP. The 657 EHLO keyword value is DEEP and the deep-status ABNF is the syntax of 658 the EHLO keyword parameters. This does not add parameters to the 659 MAIL FROM or RCPT TO commands. This also adds a CLIENT command to 660 SMTP which is used to report client information to the server. The 661 formal syntax for the command follows: 663 deep-cmd = "CLIENT" 1*(SP deep-parameter) 665 deep-parameter = name / version / latch / latch-fail 666 / security-tags / tls / future-extension 668 name = "name=" esmtp-value 670 version = "version=" esmtp-value 672 latch = "latch=" security-tag *("," security-tag) 674 latch-fail = "latch-fail=" security-tag 675 *("," security-tag) 677 security-tags = "security-tags=" security-tag 678 *("," security-tag) 680 tls = "tls=" tls-cipher 682 future-extension = esmtp-param 684 esmtp-param = 686 esmtp-value = 688 The CLIENT command parameters listed here have the same meaning as 689 the parameters used in the IMAP DEEP extension (Section 7.1). The 690 server responds to the CLIENT command with a "250" if the command has 691 correct syntax and a "501" if the command has incorrect syntax. 693 694 S: 220 example.com Demo SMTP Submission Server 695 C: EHLO client.example.com 696 S: 250-example.com 697 S: 250-8BITMIME 698 S: 250-PIPELINING 699 S: 250-DSN 700 S: 250-AUTH PLAIN LOGIN 701 S: 250-DEEP g tls-cert 702 S: 250-BURL imap 703 S: 250 SIZE 0 704 C: CLIENT name=demo_submit version=1.5 latch=tls10,tls-cert 705 security-tags=tls12 706 S: 250 OK 708 Example 5 710 7.4. SMTP Error Extension 712 Although this document focuses on SMTP Submission, it is possible to 713 use security latches for SMTP transport as well. When MTA transport 714 fails due to a security latch, the MTA MUST use the SMTP enhanced 715 status code X.7.TBD (RFC Editor note: update this TBD). The SMTP 716 notary response [RFC3464] for a security latch failure MUST include 717 an additional "SMTP-Security-Latch" recipient-specific header field 718 that includes a space-delimited list including one or more security 719 latch that failed. The ABNF for this new field follows: 721 CFWS = 723 FWS = 725 smtp-security-latch = "SMTP-Security-Latch:" CFWS 726 security-tag *(FWS security-tag) 728 8. Account Setup Considerations 730 8.1. Use of SRV records in Establishing Configuration 732 This section updates [RFC6186] by changing the preference rules and 733 adding a new SRV service label _submissions._tcp to refer to Message 734 Submission with implicit TLS. 736 User-configurable MUAs SHOULD support use of [RFC6186] for account 737 setup. However, when using configuration information obtained by 738 this method, MUAs SHOULD default to a high confidentiality assurance 739 level, unless the user has explicitly requested reduced 740 confidentiality. This will have the effect of causing the MUA to 741 ignore advertised configurations that do not support TLS, even when 742 those advertised configurations have a higher priority than other 743 advertised configurations. 745 When using [RFC6186] configuration information, Mail User Agents 746 SHOULD NOT automatically establish new configurations that do not 747 require TLS for all servers, unless there are no advertised 748 configurations using TLS. If such a configuration is chosen, prior 749 to attempting to authenticate to the server or use the server for 750 message submission, the MUA SHOULD warn the user that traffic to that 751 server will not be encrypted and that it will therefore likely be 752 intercepted by unauthorized parties. The specific wording is to be 753 determined by the implementation, but it should adequately capture 754 the sense of risk given the widespread incidence of mass surveillance 755 of email traffic. 757 When establishing a new configuration for connecting to an IMAP, POP, 758 or SMTP Submission server, an MUA SHOULD NOT blindly trust SRV 759 records unless they are signed by DNSSEC and have a valid signature. 760 Instead, the MUA SHOULD warn the user that the DNS-advertised 761 mechanism for connecting to the server is not authenticated, and 762 request the user to manually verify the connection details by 763 reference to his or her mail service provider's documentation. 765 Similarly, an MUA MUST NOT consult SRV records to determine which 766 servers to use on every connection attempt, unless those SRV records 767 are signed by DNSSEC and have a valid signature. However, an MUA MAY 768 consult SRV records from time to time to determine if an MSP's server 769 configuration has changed, and alert the user if it appears that this 770 has happened. This can also serve as a means to encourage users to 771 upgrade their configurations to require TLS if and when their MSPs 772 support it. 774 8.2. Certificate Pinning 776 During account setup, the MUA will identify servers that provide 777 account services such as mail access and mail submission (the 778 previous section describes one way to do this). The certificates for 779 these servers are verified using the rules described in 780 [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. In the event the 781 certificate does not validate due to an expired certificate, lack of 782 appropriate chain of trust or lack of identifier match, the MUA MAY 783 create a persistent binding between that certificate and the saved 784 host name for the server. This is called certificate pinning. 785 Certificate pinning is only appropriate during account setup and MUST 786 NOT be offered in response to a failed certificate validation for an 787 existing account. An MUA that allows certificate pinning MUST NOT 788 allow a certificate pinned for one account to validate connections 789 for other accounts. 791 A pinned certificate is subject to a man-in-the-middle attack at 792 account setup time, and lacks a mechanism to revoke or securely 793 refresh the certificate. Therefore use of a pinned certificate does 794 not provide a high confidentiality assurance and an MUA MUST NOT 795 indicate a high level for an account or connection using a pinned 796 certificate. Additional advice on certificate pinning is present in 797 [RFC6125]. 799 9. Implementation Requirements 801 This section details requirements for implementations of electronic 802 mail protocol clients and servers. A requirement for a client or 803 server implementation to support a particular feature is not the same 804 thing as a requirement that a client or server running a conforming 805 implementation be configured to use that feature. Requirements for 806 Mail Service Providers (MSPs) are distinct from requirements for 807 protocol implementations, and are listed in a separate section. 809 9.1. All Implementations (Client and Server) 811 These requirements apply to MUAs as well as POP, IMAP and SMTP 812 Submission servers. 814 o All implementations MUST be configurable to support implicit TLS 815 using the TLS 1.2 protocol or later [RFC5246]. 817 o All implementations MUST implement the recommended cipher suites 818 described in [RFC7525] or a future BCP or standards track revision 819 of that document. 821 o All implementations MUST be configurable to require TLS before 822 performing any operation other than capability discovery and 823 STARTTLS. 825 o The IMAP specification [RFC3501] is hereby modified to revoke the 826 second paragraph of section 11.1 and replace it with the text from 827 the first three bullet items in this list. 829 o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is 830 modified to revoke section 2.1 and replace it with the text from 831 the first three bullet items in this list. 833 o The standard for Message Submission [RFC6409] is updated to add 834 the first three bullet items above to section 4.3 as well as to 835 require implementation of the TLS server identity check as 836 described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. 838 9.1.1. Client Certificate Authentication 840 MUAs and mail servers MAY implement client certificate authentication 841 on the implicit TLS port. Servers MUST NOT request a client 842 certificate during the TLS handshake unless the server is configured 843 to accept some client certificates as sufficient for authentication 844 and the server has the ability to determine a mail server 845 authorization identity matching such certificates. How to make this 846 determination is presently implementation specific. Clients MUST NOT 847 provide a client certificate during the TLS handshake unless the 848 server requests one and the client has determined the certificate can 849 be safely used with that specific server, OR the client has been 850 explicitly configured by the user to use that particular certificate 851 with that server. How to make this determination is presently 852 implementation specific. If the server accepts the client's 853 certificate as sufficient for authorization, it MUST enable the SASL 854 EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH 855 greeting instead of enabling SASL EXTERNAL. A client supporting 856 client certificate authentication with implicit TLS MUST implement 857 the SASL EXTERNAL [RFC4422] mechanism using the appropriate 858 authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP 859 Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]). 861 9.2. Mail Server Implementation Requirements 863 These requirements apply to servers that implement POP, IMAP or SMTP 864 Submission. 866 o Servers MUST implement the DEEP extension described in Section 7 868 o IMAP and SMTP submission servers SHOULD implement and be 869 configurable to support STARTTLS. This enables discovery of new 870 TLS availability, and can increase usage of TLS by legacy clients. 872 o Servers MUST NOT advertise STARTTLS if it is unlikely to succeed 873 based on server configuration (e.g., there is no server 874 certificate installed). 876 o SMTP message submission servers that have negotiated TLS SHOULD 877 add a Received header field to the message including the tls 878 clause described in Section 6. 880 o Servers MUST be configurable to include the TLS cipher information 881 in any connection or user logging or auditing facility they 882 provide. 884 9.3. Mail User Agent Implementation Requirements 886 This section describes requirements on Mail User Agents (MUAs) using 887 IMAP, POP, and/or Submission protocols. Note: Requirements 888 pertaining to use of Submission servers are also applicable to use of 889 SMTP servers (e.g., port 25) for mail submission. 891 o User agents SHOULD indicate to users at configuration time, the 892 expected level of confidentiality based on appropriate security 893 inputs such as which security latches are pre-set, the number of 894 trust anchors, certificate validity, use of an extended validation 895 certificate, TLS version supported, and TLS cipher suites 896 supported by both server and client. This indication SHOULD also 897 be present when editing or viewing account configuration. 899 o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes 900 available for a protocol and set the tls10 latch if the server 901 advertises the tls10 security tag after a successful TLS 902 negotiation. 904 o Whenever requested to establish any configuration that does not 905 require both TLS and server certificate verification to talk to a 906 server or account, an MUA SHOULD warn its user that his or her 907 mail traffic (including password, if applicable) will be exposed 908 to attackers, and give the user an opportunity to abort the 909 connection prior to transmission of any such password or traffic. 911 o MUAs SHOULD implement the "tls12" security latch (the TLS library 912 has to provide an API that controls permissible TLS versions and 913 communicates the negotiated TLS protocol version to the 914 application for this to be possible). 916 o See Section 3 for additional requirements. 918 9.4. Non-configurable MUAs and nonstandard access protocols 920 MUAs which are not configurable to use user-specified servers MUST 921 implement TLS or similarly other strong encryption mechanism when 922 communicating with their mail servers. This generally applies to 923 MUAs that are pre-configured to operate with one or more specific 924 services, whether or not supplied by the vendor of those services. 926 MUAs using protocols other than IMAP, POP, and Submission to 927 communicate with mail servers, MUST implement TLS or other similarly 928 robust encryption mechanism in conjunction with those protocols. 930 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 932 There are multiple ways to connect an Anti-Virus and/or Anti-Spam 933 (AVAS) service to a mail server. Some mechanisms, such as the de- 934 facto milter protocol do not impact DEEP. However, some services use 935 an SMTP relay proxy that intercepts mail at the application layer to 936 perform a scan and proxy or forward to another MTA. Deploying AVAS 937 services in this way can cause many problems [RFC2979] including 938 direct interference with DEEP and confidentiality or security 939 reduction. An AVAS product or service is considered DEEP compliant 940 if all IMAP, POP and SMTP-related software it includes is DEEP 941 compliant and it advertises and supports all security latches that 942 the actual servers advertise. 944 Note that end-to-end email encryption prevents AVAS software and 945 services from using email content as part of a spam or virus 946 assessment. Furthermore, while DEEP high confidentiality assurance 947 can prevent a man-in-the-middle from introducing spam or virus 948 content between the MUA and Submission server, it does not prevent 949 other forms of client or account compromise so use of AVAS services 950 for submitted email remains necessary. 952 10. Mail Service Provider Requirements 954 This section details requirements for providers of IMAP, POP, and/or 955 SMTP submission services, for providers who claim to conform to this 956 specification. 958 10.1. Server Requirements 960 Mail Service Providers MUST use server implementations that conform 961 to this specification. 963 10.2. MSPs MUST provide Submission Servers 965 This document updates the advice in [RFC5068] by making Implicit TLS 966 on port 465 the preferred submission port. 968 Mail Service Providers that accept mail submissions from end-users 969 using the Internet Protocol MUST provide one or more SMTP Submission 970 servers for this purpose, separate from the SMTP servers used to 971 process incoming mail. Those submission servers MUST be configured 972 to support Implicit TLS on port 465 and SHOULD support STARTTLS if 973 port 587 is used. 975 MSPs MAY also support submission of messages via one or more 976 designated SMTP servers to facilitate compatibility with legacy MUAs. 978 Discussion: SMTP servers used to accept incoming mail or to relay 979 mail are expected to accept mail in cleartext. This is incompatible 980 with the purpose of this memo which is to encourage encryption of 981 traffic between mail servers. There is no such requirement for mail 982 submission servers to accept mail in cleartext or without 983 authentication. For other reasons, use of separate SMTP submission 984 servers has been best practice for many years. 986 10.3. TLS Server Certificate Requirements 988 MSPs MUST maintain valid server certificates for all servers. Those 989 server certificates SHOULD present DNS-IDs and SRV-IDs conforming to 990 [RFC6125] and which will be recognized by MUAs meeting the 991 requirements of that specification. In addition, those server 992 certificates MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for 993 compatibility with existing MUAs. 995 If a protocol server provides service for more than one mail domain, 996 it MAY use a separate IP address for each domain and/or a server 997 certificate that advertises multiple domains. This will generally be 998 necessary unless and until it is acceptable to impose the constraint 999 that the server and all clients support the Server Name Indication 1000 extension to TLS [RFC6066]. 1002 10.4. Recommended DNS records for mail protocol servers 1004 This section discusses not only the DNS records that are recommended, 1005 but also implications of DNS records for server configuration and TLS 1006 server certificates. 1008 10.4.1. MX records 1010 It is recommended that MSPs advertise MX records for handling of 1011 inbound mail (instead of relying entirely on A or AAAA records), and 1012 that those MX records be signed using DNSSEC. This is mentioned here 1013 only for completeness, as handling of inbound mail is out of scope 1014 for this document. 1016 10.4.2. SRV records 1018 MSPs SHOULD advertise SRV records to aid MUAs in determination of 1019 proper configuration of servers, per the instructions in [RFC6186]. 1021 MSPs SHOULD advertise servers that support Implicit TLS in preference 1022 to those which support cleartext and/or STARTTLS operation. 1024 10.4.3. DNSSEC 1026 All DNS records advertised by an MSP as a means of aiding clients in 1027 communicating with the MSP's servers, SHOULD be signed using DNSSEC. 1029 10.4.4. TLSA records 1031 MSPs SHOULD advertise TLSA records to provide an additional trust 1032 anchor for public keys used in TLS server certificates. However, 1033 TLSA records MUST NOT be advertised unless they are signed using 1034 DNSSEC. 1036 10.5. MSP Server Monitoring 1038 MSPs SHOULD regularly and frequently monitor their various servers to 1039 make sure that: TLS server certificates remain valid and are not 1040 about to expire, TLSA records match the public keys advertised in 1041 server certificates, are signed using DNSSEC, server configurations 1042 are consistent with SRV advertisements, and DNSSEC signatures are 1043 valid and verifiable. Failure to detect expired certificates and DNS 1044 configuration errors in a timely fashion can result in significant 1045 loss of service for an MSP's users and a significant support burden 1046 for the MSP. 1048 10.6. Advertisement of DEEP status 1050 MSPs SHOULD advertise a DEEP status that includes tls10, tls-cert and 1051 an HTTPS URL that can be used to inform clients of service outages or 1052 problems impacting client confidentiality. Note that advertising 1053 tls-cert is a commitment to maintain and renew server certificates. 1055 10.7. Require TLS 1057 New servers and services SHOULD be configured to require TLS unless 1058 it's necessary to support legacy clients or existing client 1059 configurations. 1061 10.8. Changes to Internet Facing Servers 1063 When an MSP changes the Internet Facing Servers providing mail access 1064 and mail submission services, including SMTP-based spam/virus 1065 filters, it is generally necessary to support the same and/or a newer 1066 version of TLS and the same security tags that were previously 1067 advertised. 1069 11. IANA Considerations 1071 11.1. Security Tag Registry 1073 IANA shall create (has created) the registry "Email Security Tags". 1074 This registry is a single table and will use an expert review process 1075 [RFC5226]. Each registration will contain the following fields: 1077 Name: The name of the security tag. This follows the security-tag 1078 ABNF. 1080 Description: This describes the meaning of the security tag and the 1081 conditions under which the tag is latched. 1083 Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. 1085 Reference: Optional reference to specification. 1087 Submitter: The identify of the submitter or submitters. 1089 Change Controller: The identity of the change controller for the 1090 registration. This will be "IESG" in case of registrations in 1091 IETF-produced documents. 1093 The expert reviewer will verify the tag name follows the ABNF, and 1094 that the description field is clear, unambiguous, does not overlap 1095 existing deployed technology, does not create security problems and 1096 appropriately considers interoperability issues. Email security tags 1097 intended for LIMITED USE have a lower review bar (interoperability 1098 and overlap issues are less of a concern). The reviewer may approve 1099 a registration, reject for a stated reason or recommend the proposal 1100 have standards track review due to importance or difficult 1101 subtleties. 1103 Standards-track registrations may be updated if the relevant 1104 standards are updated as a consequence of that action. Non- 1105 standards-track entries may be updated by the listed change 1106 controller. The entry's name and submitter may not be changed. In 1107 exceptional cases, any aspect of any registered entity may be updated 1108 at the direction of the IESG (for example, to correct a conflict). 1110 11.2. Initial Set of Security Tags 1112 This document defines four initial security tags for the security tag 1113 registry as follows: 1115 Name: tls10 1116 Description: This indicates TLS version 1.0 [RFC2246] or later was 1117 negotiated successfully including negotiation of a strong 1118 encryption layer with a symmetric key of at least 128 bits. This 1119 tag does not indicate the server certificate was valid. This tag 1120 is latched if the client sees this tag in the advertised server 1121 DEEP status provided after successfully negotiating TLS version 1122 1.0 or later. 1124 Intended Usage: COMMON 1126 Reference: RFC XXXX (this document once published) 1128 Submitter: Authors of this document 1130 Change Controller: IESG 1132 Name: tls12 1134 Description: This indicates TLS version 1.2 [RFC5246] or later was 1135 negotiated successfully including negotiation of a strong 1136 encryption layer with a symmetric key of at least 128 bits. This 1137 tag does not indicate the server certificate was valid. This tag 1138 is latched if the client sees this tag in the advertised server 1139 DEEP status provided after successfully negotiating TLS version 1140 1.2 or later. 1142 Intended Usage: COMMON 1144 Reference: RFC XXXX (this document once published) 1146 Submitter: Authors of this document 1148 Change Controller: IESG 1150 Name: tls-cert 1152 Description: This tag indicates that TLS was successfully negotiated 1153 and the server certificate was successfully verified by the client 1154 using PKIX [RFC5280] and the server certificate identity was 1155 verified using the algorithm appropriate for the protocol (see 1156 Section 4). This tag is latched if the client sees this tag in 1157 the advertised server DEEP status after successfully negotiating 1158 TLS and verifying the certificate and server identity. 1160 Intended Usage: COMMON 1162 Reference: RFC XXXX (this document once published) 1163 Submitter: Authors of this document 1165 Change Controller: IESG 1167 Name: tls-dane-tlsa 1169 Description: This tag indicates that TLS was successfully negotiated 1170 and the server certificate was successfully verified by the client 1171 using the procedures described in [RFC6698] and the server 1172 certificate identity was verified using the algorithm appropriate 1173 for the protocol (see Section 4). This tag is latched if the 1174 client sees this tag in the advertised server DEEP status after 1175 successfully negotiating TLS and verifying the certificate and 1176 server identity. 1178 Intended Usage: COMMON 1180 Reference: RFC XXXX (this document once published) 1182 Submitter: Authors of this document 1184 Change Controller: IESG 1186 11.3. POP3S Port Registration Update 1188 IANA is asked to update the registration of the TCP well-known port 1189 995 using the following template ([RFC6335]): 1191 Service Name: pop3s 1192 Transport Protocol: TCP 1193 Assignee: IETF 1194 Contact: IESG 1195 Description: POP3 over TLS protocol 1196 Reference: RFC XXXX (this document once published) 1197 Port Number: 995 1199 11.4. IMAPS Port Registration Update 1201 IANA is asked to update the registration of the TCP well-known port 1202 993 using the following template ([RFC6335]): 1204 Service Name: imaps 1205 Transport Protocol: TCP 1206 Assignee: IETF 1207 Contact: IESG 1208 Description: IMAP over TLS protocol 1209 Reference: RFC XXXX (this document once published) 1210 Port Number: 993 1212 11.5. Submissions Port Registration 1214 IANA is asked to assign an alternate usage of port 465 in addition to 1215 the current assignment using the following template ([RFC6335]): 1217 Service Name: submissions 1218 Transport Protocol: TCP 1219 Assignee: IETF 1220 Contact: IESG 1221 Description: Message Submission over TLS protocol 1222 Reference: RFC XXXX (this document once published) 1223 Port Number: 465 1225 This is a one time procedural exception to the rules in RFC 6335. 1226 This requires explicit IESG approval and does not set a precedent. 1227 Historically, port 465 was briefly registered as the "smtps" port. 1228 This registration made no sense as the SMTP transport MX 1229 infrastructure has no way to specify a port so port 25 is always 1230 used. As a result, the registration was revoked and was subsequently 1231 reassigned to a different service. In hindsight, the "smtps" 1232 registration should have been renamed or reserved rather than 1233 revoked. Unfortunately, some widely deployed mail software 1234 interpreted "smtps" as "submissions" [RFC6409] and used that port for 1235 email submission by default when an end-user requests security during 1236 account setup. If a new port is assigned for the submissions 1237 service, email software will either continue with unregistered use of 1238 port 465 (leaving the port registry inaccurate relative to de-facto 1239 practice and wasting a well-known port), or confusion between the de- 1240 facto and registered ports will cause harmful interoperability 1241 problems that will deter use of TLS for message submission. The 1242 authors believe both of these outcomes are less desirable than a wart 1243 in the registry documenting real-world usage of a port for two 1244 purposes. Although STARTTLS-on-port-587 has deployed, it has not 1245 replaced deployed use of implicit TLS submission on port 465. 1247 11.6. DEEP IMAP Capability 1249 This document adds the DEEP capability to the IMAP capabilities 1250 registry. This is described in Section 7.1. 1252 11.7. DEEP POP3 Capability 1254 This document adds the DEEP capability to the POP3 capabilities 1255 registry. 1257 CAPA Tag: DEEP 1259 Arguments: deep-status 1260 Added Commands: none 1262 Standard Commands affected: none 1264 Announced status / possible differences: both / may change after 1265 STLS 1267 Commands Valid in States: N/A 1269 Specification Reference: This document 1271 Discussion: See Section 7.2. 1273 11.8. DEEP SMTP EHLO Keyword 1275 This document adds the DEEP EHLO Keyword to the SMTP Service 1276 Extension registry. This is described in Section 7.3. 1278 11.9. SMTP Enhanced Status Code 1280 This document adds the following entry to the "SMTP Enhanced Status 1281 Codes" registry created by [RFC5248]. 1283 Code: X.7.TBD (IANA, please assign the next available number) 1285 Sample Text: Message Transport Failed due to missing required 1286 security. 1288 Associated Basic Status Code: 450, 454, 550, 554 1290 Description This code indicates an SMTP server was unable to forward 1291 a message to the next host necessary for delivery because it 1292 required a higher level of transport security or confidentiality 1293 than was available. The temporary form of this error is preferred 1294 in case the problem is caused by a temporary administrative error 1295 such as an expired server certificate. 1297 Reference This document 1299 Submitter C. Newman 1301 Change Controller IESG 1303 11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 1305 This document adds the following entry to the "Additional-registered- 1306 clauses" sub-registry of the "MAIL Parameters" registry, created by 1307 [RFC5321]: 1309 Clause Name: tls 1311 Description: Indicates the TLS cipher suite used for a transport 1312 connection. 1314 Syntax Summary: See tls-cipher ABNF Section 6 1316 Reference: This document. 1318 12. Security Considerations 1320 This entire document is about security considerations. In general, 1321 this is targeted to improve mail confidentiality and to mitigate 1322 threats external to the email system such as network-level snooping 1323 or interception; this is not intended to mitigate active attackers 1324 who have compromised service provider systems. 1326 It could be argued that sharing the name and version of the client 1327 software with the server has privacy implications. Although 1328 providing this information is not required, it is encouraged so that 1329 mail service providers can more effectively inform end-users running 1330 old clients that they need to upgrade to protect their security, or 1331 know which clients to use in a test deployment prior to upgrading a 1332 server to have higher security requirements. 1334 13. References 1336 13.1. Normative References 1338 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1339 STD 53, RFC 1939, May 1996. 1341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1342 Requirement Levels", BCP 14, RFC 2119, March 1997. 1344 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 1345 Mechanism", RFC 2449, November 1998. 1347 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1349 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, October 1350 2000. 1352 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1353 Transport Layer Security", RFC 3207, February 2002. 1355 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1356 4rev1", RFC 3501, March 2003. 1358 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1359 for Delivery Status Notifications", RFC 3464, January 1360 2003. 1362 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1363 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1364 3986, January 2005. 1366 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol 1367 (POP3) Simple Authentication and Security Layer (SASL) 1368 Authentication Mechanism", RFC 5034, July 2007. 1370 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1371 Finch, "Email Submission Operations: Access and 1372 Accountability Requirements", BCP 134, RFC 5068, November 1373 2007. 1375 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1376 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1378 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1379 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1381 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1382 Mail System Status Codes", BCP 138, RFC 5248, June 2008. 1384 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1385 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1386 May 2008. 1388 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1389 Housley, R., and W. Polk, "Internet X.509 Public Key 1390 Infrastructure Certificate and Certificate Revocation List 1391 (CRL) Profile", RFC 5280, May 2008. 1393 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1394 October 2008. 1396 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1397 October 2008. 1399 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1400 Verification of Domain-Based Application Service Identity 1401 within Internet Public Key Infrastructure Using X.509 1402 (PKIX) Certificates in the Context of Transport Layer 1403 Security (TLS)", RFC 6125, March 2011. 1405 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1406 Submission/Access Services", RFC 6186, March 2011. 1408 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1409 STD 72, RFC 6409, November 2011. 1411 [I-D.ietf-uta-email-tls-certs] 1412 Melnikov, A., "Updated TLS Server Identity Check Procedure 1413 for Email Related Protocols", draft-ietf-uta-email-tls- 1414 certs-03 (work in progress), June 2015. 1416 [I-D.ietf-dane-smtp-with-dane] 1417 Dukhovni, V. and W. Hardaker, "SMTP security via 1418 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-02 1419 (work in progress), October 2013. 1421 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1422 "Recommendations for Secure Use of Transport Layer 1423 Security (TLS) and Datagram Transport Layer Security 1424 (DTLS)", BCP 195, RFC 7525, May 2015. 1426 13.2. Informative References 1428 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1429 RFC 2246, January 1999. 1431 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 1432 2595, June 1999. 1434 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1435 Firewalls", RFC 2979, October 2000. 1437 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 1438 Registration", RFC 3848, July 2004. 1440 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 1441 September 2004. 1443 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1444 Security Layer (SASL)", RFC 4422, June 2006. 1446 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1447 for Authentication", RFC 4954, July 2007. 1449 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 1450 2009. 1452 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1453 "Salted Challenge Response Authentication Mechanism 1454 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 1456 [RFC5804] Melnikov, A. and T. Martin, "A Protocol for Remotely 1457 Managing Sieve Scripts", RFC 5804, July 2010. 1459 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1460 Extension Definitions", RFC 6066, January 2011. 1462 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1463 Cheshire, "Internet Assigned Numbers Authority (IANA) 1464 Procedures for the Management of the Service Name and 1465 Transport Protocol Port Number Registry", BCP 165, RFC 1466 6335, August 2011. 1468 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1469 of Named Entities (DANE) Transport Layer Security (TLS) 1470 Protocol: TLSA", RFC 6698, August 2012. 1472 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1473 Transport Security (HSTS)", RFC 6797, November 2012. 1475 Appendix A. Design Considerations 1477 This section is not normative. 1479 The first version of this was written independently from draft-moore- 1480 email-tls-00.txt; subsequent versions merge ideas from both drafts. 1482 One author of this document was also the author of RFC 2595 that 1483 became the standard for TLS usage with POP and IMAP, and the other 1484 author was perhaps the first to propose that idea. In hindsight both 1485 authors now believe that that approach was a mistake. At this point 1486 the authors believe that while anything that makes it easier to 1487 deploy TLS is good, the desirable end state is that these protocols 1488 always use TLS, leaving no need for a separate port for cleartext 1489 operation except to support legacy clients while they continue to be 1490 used. The separate port model for TLS is inherently simpler to 1491 implement, debug and deploy. It also enables a "generic TLS load- 1492 balancer" that accepts secure client connections for arbitrary foo- 1493 over-TLS protocols and forwards them to a server that may or may not 1494 support TLS. Such load-balancers cause many problems because they 1495 violate the end-to-end principle and the server loses the ability to 1496 log security-relevant information about the client unless the 1497 protocol is designed to forward that information (as this 1498 specification does for the cipher suite). However, they can result 1499 in TLS deployment where it would not otherwise happen which is a 1500 sufficiently important goal that it overrides the problems. 1502 Although STARTTLS appears only slightly more complex than separate- 1503 port TLS, we again learned the lesson that complexity is the enemy of 1504 security in the form of the STARTTLS command injection vulnerability 1505 (CERT vulnerability ID #555316). Although there's nothing inherently 1506 wrong with STARTTLS, the fact it resulted in a common implementation 1507 error (made independently by multiple implementers) suggests it is a 1508 less secure architecture than Implicit TLS. 1510 Section 7 of RFC 2595 critiques the separate-port approach to TLS. 1511 The first bullet was a correct critique. There are proposals in the 1512 http community to address that, and use of SRV records as described 1513 in RFC 6186 resolves that critique for email. The second bullet is 1514 correct as well, but not very important because useful deployment of 1515 security layers other than TLS in email is small enough to be 1516 effectively irrelevant. The third bullet is incorrect because it 1517 misses the desirable option of "use and latch-on TLS if available". 1518 The fourth bullet may be correct, but is not a problem yet with 1519 current port consumption rates. The fundamental error was 1520 prioritizing a perceived better design based on a mostly valid 1521 critique over real-world deployability. But getting security and 1522 confidentiality facilities actually deployed is so important it 1523 should trump design purity considerations. 1525 Appendix B. Open Issues 1527 There are many open issues with this document. Here is an attempt to 1528 enumerate some of them: 1530 o Port 465 is presently used for two purposes: for submissions by a 1531 large number of clients and service providers and for the "urd" 1532 protocol by one vendor. Actually documenting this current state 1533 is controversial as discussed in the IANA considerations section. 1534 However, there is no good alternative. Registering a new port for 1535 submissions when port 465 is widely used for that purpose already 1536 will just create interoperability problems. Registering a port 1537 that's only used if advertised by an SRV record (RFC 6186) would 1538 not create interoperability problems but would require all client 1539 and server deployments and software to change significantly which 1540 is contrary to the goal of promoting more TLS use. Encouraging 1541 use of STARTTLS on port 587 would not create interoperability 1542 problems, but is unlikely to have impact on current undocumented 1543 use of port 465 and makes the guidance in this document less 1544 consistent. 1546 o One author believes that the security latch model is complementary 1547 with draft-ietf-dane-smtp-with-dane-02 but hasn't thought about 1548 the issues in depth. We welcome feedback on this point. 1550 o The two authors of this document and the author of draft-melnikov- 1551 email-tls-certs are willing to merge these two documents. 1552 However, it is undesirable to delay publication of either document 1553 so this will be done only if the latter document is not yet 1554 through IESG processing when this document is ready for the IESG. 1556 o It might make sense to split this in two or more documents if it's 1557 getting too long to evaluate in one IETF last call. In 1558 particular, it might make sense to put implementation requirements 1559 and service provider requirements in separate documents. The 1560 authors prefer to edit one document for now and defer discussion 1561 of splitting the document until all technical issues are resolved. 1563 o The use of SRV records [RFC6186] for account setup or refresh is 1564 presently not secure from DNS active attacks unless DNSSEC is 1565 used. If someone wishes to provide suggested text describing how 1566 to use DANE in this process, the WG can consider adding that text 1567 to this document. Absent suggested text, the editor intends to 1568 leave this issue alone. 1570 Appendix C. Change Log 1572 Changes since draft-ietf-uta-email-deep-00: 1574 o Update and clarify abstract 1576 o use term confidentiality instead of privacy in most cases. 1578 o update open issues to request input for missing text. 1580 o move certificate pinning sub-section to account setup section and 1581 attempt to define it more precisely. 1583 o Add note about end-to-end encryption in AVAS section. 1585 o swap order of DNSSEC and TLSA sub-sections. 1587 o change meaning of 'tls10' and 'tls12' latches to require 1588 certificate validation. 1590 o Replace cipher suite advice with reference to RFC 7525. Change 1591 examples to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as cipher 1592 suite. 1594 o Add text to update IMAP, POP3 and Message Submission standards 1595 with newer TLS advice. 1597 o Add clearer text in introduction that this does not cover SMTP 1598 relay. 1600 o Update references to uta-tls-certs. 1602 o Add paragraph to Implicit TLS for SMTP Submission section 1603 recommending that STARTTLS also be implemented. 1605 Changes since draft-newman-email-deep-02: 1607 o Changed "privacy assurance" to "confidentiality assurance" 1609 o Changed "low privacy assurance" to "no confidentiality assurance" 1611 o Attempt to improve definition of confidentiality assurance level. 1613 o Add SHOULD indicate when MUA is showing list of mail accounts. 1615 o Add SHOULD NOT latch tls10, tls12 tags until TLS negotiated. 1617 o Removed sentence about deleting and re-creating the account in 1618 latch failure section. 1620 o Remove use of word "fallback" with respect to TLS version 1621 negotiation. 1623 o Added bullet about changes to Internet facing servers to MSP 1624 section. 1626 o minor wording improvements based on feedback 1628 Changes since -01: 1630 o Updated abstract, introduction and document structure to focus 1631 more on mail user agent privacy assurance. 1633 o Added email account privacy section, also moving section on 1634 account setup using SRV records to that section. 1636 o Finished writing IANA considerations section 1638 o Remove provisional concept and instead have server explicitly list 1639 security tags clients should latch. 1641 o Added note that rules for the submissions port follow the same 1642 rules as those for the submit port. 1644 o Reference and update advice in [RFC5068]. 1646 o Fixed typo in Client Certificate Authentication section. 1648 o Removed tls-pfs security latch and all mention of perfect forward 1649 secrecy as it was controversial. 1651 o Added reference to HSTS. 1653 Changes since -00: 1655 o Rewrote introduction to merge ideas from draft-moore-email-tls-00. 1657 o Added Implicit TLS section, Account configuration section and IANA 1658 port registration updates based on draft-moore-email-tls-00. 1660 o Add protocol details necessary to standardize implicit TLS for 1661 POP/IMAP/submission, using ideas from draft-melnikov-pop3-over- 1662 tls. 1664 o Reduce initial set of security tags based on feedback. 1666 o Add deep status concept to allow a window for software updates to 1667 be backed out before latches make that problematic, as well as to 1668 provide service providers with a mechanism they can use to assist 1669 customers in the event of a privacy failure. 1671 o Add DNS SRV section from draft-moore-email-tls-00. 1673 o Write most of the missing IANA considerations section. 1675 o Rewrite most of implementation requirements section based more on 1676 draft-moore-email-tls-00. Remove new cipher requirements for now 1677 because those may be dealt with elsewhere. 1679 Appendix D. Acknowledgements 1681 Thanks to Ned Freed for discussion of the initial latch concepts in 1682 this document. Thanks to Alexey Melnikov for draft-melnikov-pop3- 1683 over-tls-02, which was the basis of the POP3 implicit TLS text. 1684 Thanks to Russ Housley, Alexey Melnikov and Dan Newman for review 1685 feedback. Thanks to Paul Hoffman for interesting feedback in initial 1686 conversations about this idea. 1688 Authors' Addresses 1690 Keith Moore 1691 Network Heretics 1692 PO Box 1934 1693 Knoxville, TN 37901 1694 US 1696 Email: moore@network-heretics.com 1698 Chris Newman 1699 Oracle 1700 440 E. Huntington Dr., Suite 400 1701 Arcadia, CA 91006 1702 US 1704 Email: chris.newman@oracle.com