idnits 2.17.1 draft-ietf-uta-email-deep-04.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 17, 2016) is 2961 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 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Moore 3 Internet-Draft Network Heretics 4 Updates: 1939, 2595, 3464, 3501, 5068, C. Newman 5 6186, 6409 (if approved) Oracle 6 Intended status: Standards Track March 17, 2016 7 Expires: September 18, 2016 9 Deployable Enhanced Email Privacy (DEEP) 10 draft-ietf-uta-email-deep-04.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 18, 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 . . . . . . . . . . . . . . . . . 33 118 Appendix A. Design Considerations . . . . . . . . . . . . . . . . 34 119 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 120 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 39 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 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. One 151 approach to address that topic is described in [RFC7672]. 153 The recommendations in this memo do not replace the functionality of, 154 and are not intended as a substitute for, end-to-end encryption of 155 electronic mail. 157 This draft is subject to change. Implementation of this proposal is 158 not recommended at this time. Please discuss this proposal on the 159 ietf-uta mailing list. 161 2. Conventions and Terminology Used in This Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 This specification expresses syntax using the Augmented Backus-Naur 168 Form (ABNF) as described in [RFC5234], including the core rules in 169 Appendix B and rules from [RFC5322]. 171 In examples, "C:" and "S:" indicate lines sent by the client and 172 server respectively. If a single "C:" or "S:" label applies to 173 multiple lines, then the line breaks between those lines are for 174 editorial clarity only and are not part of the actual protocol 175 exchange. 177 3. Mail Account Confidentiality Assurance Level 179 A "mail account" refers to the network services an end user uses to 180 read, submit and manage email communications on the Internet. This 181 typically involves at least one mail access server (IMAP or POP) and 182 at least one SMTP submission server. An end users uses a mail user 183 agent (MUA) to access a mail account and most MUAs support one or 184 more mail accounts. This document uses the term "confidentiality 185 assurance level" to indicate the degree to which the network 186 connections between an MUA and a mail account have confidentiality 187 protection from both passive and active attackers on the network. 189 The configuration necessary for a mail account includes an email 190 address, connection information and authentication credentials for 191 network services. MUAs compliant with this specification MUST also 192 associate a confidentiality assurance level with each mail account. 193 MUAs MUST implement a high confidentiality assurance level as 194 described in the next section. 196 MUAs SHOULD continuously indicate to the user the confidentiality 197 assurance level of the account currently in use when reading, 198 submitting and managing mail (e.g., via a lock icon, background 199 colors and indications similar to those commonly used in web browsers 200 for a similar purpose) and SHOULD indicate the confidentiality 201 assurance level for each account whenever displaying a list of mail 202 accounts. Note that the displayed confidentiality assurance level 203 could be higher than the level set at account configuration but never 204 lower. If multiple active connections are associated with an account 205 or view, the indication should match the level provided by the least 206 confidential connection. 208 Account configuration occurs when an MUA is first used to access a 209 particular service, when a user wishes to access or submit mail 210 through servers in addition to those specified or found during first 211 use, or when a user explicitly requests to change account 212 configuration parameters such as server names, user names, passwords, 213 client certificates, etc. Account configuration can be entirely 214 manual (entering server names explicitly) or partially automated via 215 a mechanism such as DNS SRV records [RFC6186]. MUAs SHOULD use the 216 high confidentiality assurance level as the default for newly 217 configured accounts. 219 3.1. High Confidentiality Assurance 221 A mail account has a high confidentiality assurance when the 222 following conditions are met on all TCP server connections associated 223 with an account. This includes connections to POP, IMAP and SMTP 224 submission servers as well as any other associated protocols defined 225 now or in the future. Examples of protocols associated with a mail 226 account include managesieve [RFC5804] and MTQP [RFC3887]. 228 o TCP connections MUST attempt to negotiate TLS via either Implicit 229 TLS Section 4 or STARTTLS. 231 o MUAs MUST implement [I-D.ietf-uta-email-tls-certs] and PKIX 232 [RFC5280]. 234 o MUAs MAY implement DANE [RFC6698]. 236 o User agents MUST abort a TLS session if the TLS negotiation fails 237 or the server's certificate or identity fails to verify. A user 238 may reconfigure the account to lower the expected level of 239 confidentiality if he/she chooses. Reduction of expected account 240 confidentiality MUST NOT be done on a click-through basis. 242 The end user is part of the system that protects the user's 243 confidentiality and security. As a result, it's critical not to 244 present the end user with a simple action that reduces their 245 confidentiality in response to certificate validation failure. An 246 MUA which offers a user actions such as "connect anyway", "trust 247 certificate for future connections" or "lower confidentiality 248 assurance for this account" in response to certificate validation 249 failure is not providing a high confidentiality assurance as defined 250 in this section and thus does not comply with this document. 251 Examples of acceptable actions to offer would be "work offline", "try 252 again later", and "open service provider status web page". 254 3.2. No Confidentiality Assurance 256 MUAs MAY implement a no confidentiality assurance level for accounts. 257 At this level, the MUA MUST attempt to negotiate TLS, but MAY ignore 258 server certificate validation failures. MUAs MAY support use of 259 connections without TLS, but if they do they SHOULD attempt TLS first 260 if available and MUST implement code to reconnect without TLS if TLS 261 negotiation fails for reasons other than server certificate validity. 263 Note that if the TLS certificate is not successfully validated as 264 described in Section 3.1 or a version of SSL/TLS prior to TLS 1.0 is 265 used, the client MUST NOT present a high confidentiality indication 266 for the account or connection. 268 3.3. Other Confidentiality Assurance Levels 270 This specification is not intended to limit experimentation and 271 innovation with respect to user confidentiality. As a result more 272 confidentiality assurance levels are permitted. However, levels 273 below "no confidentiality assurance" described in the previous 274 section are discouraged and implementers are cautioned that end users 275 may be confused by too many confidentiality assurance levels. 277 4. Implicit TLS 279 Previous standards for use of email protocols with TLS used the 280 STARTTLS mechanism: [RFC2595], [RFC3207], and [RFC3501]. With 281 STARTTLS, the client establishes a clear text application session and 282 determines whether to issue a STARTTLS command based on server 283 capabilities and client configuration. If the client issues a 284 STARTTLS command, a TLS handshake follows that can upgrade the 285 connection. While this mechanism has been deployed, an alternate 286 mechanism where TLS is negotiated immediately at connection start on 287 a separate port (referred to in this document as "Implicit TLS") has 288 been deployed more successfully. To increase use of TLS, this 289 specification recommends use of implicit TLS by new POP, IMAP and 290 SMTP Submission software. 292 4.1. Implicit TLS for POP 294 When a TCP connection is established for the "pop3s" service (default 295 port 995), a TLS handshake begins immediately. Clients MUST 296 implement the certificate validation mechanism described in 297 [I-D.ietf-uta-email-tls-certs]. Once the TLS session is established, 298 POP3 [RFC1939] protocol messages are exchanged as TLS application 299 data for the remainder of the TCP connection. After the server sends 300 a +OK greeting, the server and client MUST enter AUTHORIZATION state, 301 even if client credentials were supplied during the TLS handshake. 303 See Section 9.1.1 for additional information on client certificate 304 authentication. See Section 11.3 for port registration information. 306 4.2. Implicit TLS for IMAP 308 When a TCP connection is established for the "imaps" service (default 309 port 993), a TLS handshake begins immediately. Clients MUST 310 implement the certificate validation mechanism described in [RFC3501] 311 and SHOULD implement the certificate validation mechanism described 312 in [I-D.ietf-uta-email-tls-certs]. Once the TLS session is 313 established, IMAP [RFC3501] protocol messages are exchanged as TLS 314 application data for the remainder of the TCP connection. If client 315 credentials were provided during the TLS handshake that the server 316 finds acceptable, the server MAY issue a PREAUTH greeting in which 317 case both the server and client enter AUTHENTICATED state. If the 318 server issues an OK greeting then both server and client enter NOT 319 AUTHENTICATED state. 321 See Section 9.1.1 for additional information on client certificate 322 authentication. See Section 11.4 for port registration information. 324 4.3. Implicit TLS for SMTP Submission 326 When a TCP connection is established for the "submissions" service 327 (default port 465), a TLS handshake begins immediately. Clients MUST 328 implement the certificate validation mechanism described in 329 [I-D.ietf-uta-email-tls-certs]. Once a TLS session is established, 330 message submission protocol data [RFC6409] is exchanged as TLS 331 application data for the remainder of the TCP connection. (Note: the 332 "submissions" service name is defined in section 10.3 of this 333 document, and follows the usual convention that the name of a service 334 layered on top of Implicit TLS consists of the name of the service as 335 used without TLS, with an "s" appended.) 337 The STARTTLS mechanism on port 587 is relatively widely deployed due 338 to the situation with port 465 (discussed in Section 11.5). This 339 differs from IMAP and POP services where implicit TLS is more widely 340 deployed on servers than STARTTLS. It is desirable to migrate core 341 protocols used by MUA software to implicit TLS over time for 342 consistency as well as the additional reasons discussed in 343 Appendix A. However, to maximize use of encryption for submission it 344 is desirable to support both mechanisms for Message Submission over 345 TLS for a transition period of several years. As a result, clients 346 and servers SHOULD implement both STARTTLS on port 587 and implicit 347 TLS on port 465 for this transition period. Note that there is no 348 significant difference between the security properties of STARTTLS on 349 port 587 and implicit TLS on port 465 if the implementations are 350 correct and both client and server are configured to require 351 successful negotiation of TLS prior to message submission (as 352 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. See Appendix B of 824 [I-D.ietf-uta-email-tls-certs] to see additional modifications to 825 IMAP certificate validation rules. 827 o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is 828 modified to revoke section 2.1 and replace it with the text from 829 the first three bullet items in this list. See Appendix B of 830 [I-D.ietf-uta-email-tls-certs] to see additional modifications to 831 RFC 2595 certificate validation rules. 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 tls11 latch if the server 901 advertises the tls11 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 services, separate from the SMTP MTA services used to process 971 incoming mail. Those submission services MUST be configured to 972 support Implicit TLS on port 465 and SHOULD support STARTTLS if port 973 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. See 989 [I-D.ietf-uta-email-tls-certs] for the recommendations and 990 requirements necessary to achieve this. 992 If a protocol server provides service for more than one mail domain, 993 it MAY use a separate IP address for each domain and/or a server 994 certificate that advertises multiple domains. This will generally be 995 necessary unless and until it is acceptable to impose the constraint 996 that the server and all clients support the Server Name Indication 997 extension to TLS [RFC6066]. For more discussion of this problem, see 998 section 5.1 of [I-D.ietf-uta-email-tls-certs]. 1000 10.4. Recommended DNS records for mail protocol servers 1002 This section discusses not only the DNS records that are recommended, 1003 but also implications of DNS records for server configuration and TLS 1004 server certificates. 1006 10.4.1. MX records 1008 It is recommended that MSPs advertise MX records for handling of 1009 inbound mail (instead of relying entirely on A or AAAA records), and 1010 that those MX records be signed using DNSSEC. This is mentioned here 1011 only for completeness, as handling of inbound mail is out of scope 1012 for this document. 1014 10.4.2. SRV records 1016 MSPs SHOULD advertise SRV records to aid MUAs in determination of 1017 proper configuration of servers, per the instructions in [RFC6186]. 1019 MSPs SHOULD advertise servers that support Implicit TLS in preference 1020 to those which support cleartext and/or STARTTLS operation. 1022 10.4.3. DNSSEC 1024 All DNS records advertised by an MSP as a means of aiding clients in 1025 communicating with the MSP's servers, SHOULD be signed using DNSSEC. 1027 10.4.4. TLSA records 1029 MSPs SHOULD advertise TLSA records to provide an additional trust 1030 anchor for public keys used in TLS server certificates. However, 1031 TLSA records MUST NOT be advertised unless they are signed using 1032 DNSSEC. 1034 10.5. MSP Server Monitoring 1036 MSPs SHOULD regularly and frequently monitor their various servers to 1037 make sure that: TLS server certificates remain valid and are not 1038 about to expire, TLSA records match the public keys advertised in 1039 server certificates, are signed using DNSSEC, server configurations 1040 are consistent with SRV advertisements, and DNSSEC signatures are 1041 valid and verifiable. Failure to detect expired certificates and DNS 1042 configuration errors in a timely fashion can result in significant 1043 loss of service for an MSP's users and a significant support burden 1044 for the MSP. 1046 10.6. Advertisement of DEEP status 1048 MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and 1049 an HTTPS URL that can be used to inform clients of service outages or 1050 problems impacting client confidentiality. Note that advertising 1051 tls-cert is a commitment to maintain and renew server certificates. 1053 10.7. Require TLS 1055 New servers and services SHOULD be configured to require TLS unless 1056 it's necessary to support legacy clients or existing client 1057 configurations. 1059 10.8. Changes to Internet Facing Servers 1061 When an MSP changes the Internet Facing Servers providing mail access 1062 and mail submission services, including SMTP-based spam/virus 1063 filters, it is generally necessary to support the same and/or a newer 1064 version of TLS and the same security tags that were previously 1065 advertised. 1067 11. IANA Considerations 1069 11.1. Security Tag Registry 1071 IANA shall create (has created) the registry "Email Security Tags". 1072 This registry is a single table and will use an expert review process 1073 [RFC5226]. Each registration will contain the following fields: 1075 Name: The name of the security tag. This follows the security-tag 1076 ABNF. 1078 Description: This describes the meaning of the security tag and the 1079 conditions under which the tag is latched. 1081 Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. 1083 Reference: Optional reference to specification. 1085 Submitter: The identify of the submitter or submitters. 1087 Change Controller: The identity of the change controller for the 1088 registration. This will be "IESG" in case of registrations in 1089 IETF-produced documents. 1091 The expert reviewer will verify the tag name follows the ABNF, and 1092 that the description field is clear, unambiguous, does not overlap 1093 existing deployed technology, does not create security problems and 1094 appropriately considers interoperability issues. Email security tags 1095 intended for LIMITED USE have a lower review bar (interoperability 1096 and overlap issues are less of a concern). The reviewer may approve 1097 a registration, reject for a stated reason or recommend the proposal 1098 have standards track review due to importance or difficult 1099 subtleties. 1101 Standards-track registrations may be updated if the relevant 1102 standards are updated as a consequence of that action. Non- 1103 standards-track entries may be updated by the listed change 1104 controller. The entry's name and submitter may not be changed. In 1105 exceptional cases, any aspect of any registered entity may be updated 1106 at the direction of the IESG (for example, to correct a conflict). 1108 11.2. Initial Set of Security Tags 1110 This document defines four initial security tags for the security tag 1111 registry as follows: 1113 Name: tls11 1115 Description: This indicates TLS version 1.1 [RFC4346] or later was 1116 negotiated successfully including negotiation of a strong 1117 encryption layer with a symmetric key of at least 128 bits. This 1118 tag indicates the server certificate was valid but does not 1119 indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE 1120 [RFC6698]). This tag is latched if the client sees this tag in 1121 the advertised server DEEP status provided after successfully 1122 negotiating TLS version 1.0 or later. 1124 Intended Usage: COMMON 1126 Reference: RFC XXXX (this document once published) 1128 Submitter: Authors of this document 1129 Change Controller: IESG 1131 Name: tls12 1133 Description: This indicates TLS version 1.2 [RFC5246] or later was 1134 negotiated successfully including negotiation of a strong 1135 encryption layer with a symmetric key of at least 128 bits. This 1136 tag indicates the server certificate was valid but does not 1137 indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE 1138 [RFC6698]). This tag is latched if the client sees this tag in 1139 the advertised server DEEP status provided after successfully 1140 negotiating TLS version 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) 1164 Submitter: Authors of this document 1166 Change Controller: IESG 1168 Name: tls-dane-tlsa 1170 Description: This tag indicates that TLS was successfully negotiated 1171 and the server certificate was successfully verified by the client 1172 using the procedures described in [RFC6698] and the server 1173 certificate identity was verified using the algorithm appropriate 1174 for the protocol (see Section 4). This tag is latched if the 1175 client sees this tag in the advertised server DEEP status after 1176 successfully negotiating TLS and verifying the certificate and 1177 server identity. 1179 Intended Usage: COMMON 1181 Reference: RFC XXXX (this document once published) 1183 Submitter: Authors of this document 1185 Change Controller: IESG 1187 11.3. POP3S Port Registration Update 1189 IANA is asked to update the registration of the TCP well-known port 1190 995 using the following template ([RFC6335]): 1192 Service Name: pop3s 1193 Transport Protocol: TCP 1194 Assignee: IETF 1195 Contact: IESG 1196 Description: POP3 over TLS protocol 1197 Reference: RFC XXXX (this document once published) 1199 Service Name: pop3s 1200 Transport Protocol: TCP 1201 Assignee: IETF 1202 Contact: IESG 1203 Description: POP3 over TLS protocol 1204 Reference: RFC XXXX (this document once published) 1206 11.4. IMAPS Port Registration Update 1208 IANA is asked to update the registration of the TCP well-known port 1209 993 using the following template ([RFC6335]): 1211 Service Name: imaps 1212 Transport Protocol: TCP 1213 Assignee: IETF 1214 Contact: IESG 1215 Description: IMAP over TLS protocol 1216 Reference: RFC XXXX (this document once published) 1218 Service Name: imaps 1219 Transport Protocol: TCP 1220 Assignee: IETF 1221 Contact: IESG 1222 Description: IMAP over TLS protocol 1223 Reference: RFC XXXX (this document once published) 1225 11.5. Submissions Port Registration 1227 IANA is asked to assign an alternate usage of port 465 in addition to 1228 the current assignment using the following template ([RFC6335]): 1230 Service Name: submissions 1231 Transport Protocol: TCP 1232 Assignee: IETF 1233 Contact: IESG 1234 Description: Message Submission over TLS protocol 1235 Reference: RFC XXXX (this document once published) 1237 Service Name: submissions 1238 Transport Protocol: TCP 1239 Assignee: IETF 1240 Contact: IESG 1241 Description: Message Submission over TLS protocol 1242 Reference: RFC XXXX (this document once published) 1244 This is a one time procedural exception to the rules in RFC 6335. 1245 This requires explicit IESG approval and does not set a precedent. 1246 Historically, port 465 was briefly registered as the "smtps" port. 1247 This registration made no sense as the SMTP transport MX 1248 infrastructure has no way to specify a port so port 25 is always 1249 used. As a result, the registration was revoked and was subsequently 1250 reassigned to a different service. In hindsight, the "smtps" 1251 registration should have been renamed or reserved rather than 1252 revoked. Unfortunately, some widely deployed mail software 1253 interpreted "smtps" as "submissions" [RFC6409] and used that port for 1254 email submission by default when an end-user requests security during 1255 account setup. If a new port is assigned for the submissions 1256 service, email software will either continue with unregistered use of 1257 port 465 (leaving the port registry inaccurate relative to de-facto 1258 practice and wasting a well-known port), or confusion between the de- 1259 facto and registered ports will cause harmful interoperability 1260 problems that will deter use of TLS for message submission. The 1261 authors believe both of these outcomes are less desirable than a wart 1262 in the registry documenting real-world usage of a port for two 1263 purposes. Although STARTTLS-on-port-587 has deployed, it has not 1264 replaced deployed use of implicit TLS submission on port 465. 1266 11.6. DEEP IMAP Capability 1268 This document adds the DEEP capability to the IMAP capabilities 1269 registry. This is described in Section 7.1. 1271 11.7. DEEP POP3 Capability 1273 This document adds the DEEP capability to the POP3 capabilities 1274 registry. 1276 CAPA Tag: DEEP 1278 Arguments: deep-status 1280 Added Commands: none 1282 Standard Commands affected: none 1284 Announced status / possible differences: both / may change after 1285 STLS 1287 Commands Valid in States: N/A 1289 Specification Reference: This document 1291 Discussion: See Section 7.2. 1293 11.8. DEEP SMTP EHLO Keyword 1295 This document adds the DEEP EHLO Keyword to the SMTP Service 1296 Extension registry. This is described in Section 7.3. 1298 11.9. SMTP Enhanced Status Code 1300 This document adds the following entry to the "SMTP Enhanced Status 1301 Codes" registry created by [RFC5248]. 1303 Code: X.7.TBD (IANA, please assign the next available number) 1305 Sample Text: Message Transport Failed due to missing required 1306 security. 1308 Associated Basic Status Code: 450, 454, 550, 554 1310 Description This code indicates an SMTP server was unable to forward 1311 a message to the next host necessary for delivery because it 1312 required a higher level of transport security or confidentiality 1313 than was available. The temporary form of this error is preferred 1314 in case the problem is caused by a temporary administrative error 1315 such as an expired server certificate. 1317 Reference This document 1319 Submitter C. Newman 1321 Change Controller IESG 1323 11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 1325 This document adds the following entry to the "Additional-registered- 1326 clauses" sub-registry of the "MAIL Parameters" registry, created by 1327 [RFC5321]: 1329 Clause Name: tls 1331 Description: Indicates the TLS cipher suite used for a transport 1332 connection. 1334 Syntax Summary: See tls-cipher ABNF Section 6 1336 Reference: This document. 1338 12. Security Considerations 1340 This entire document is about security considerations. In general, 1341 this is targeted to improve mail confidentiality and to mitigate 1342 threats external to the email system such as network-level snooping 1343 or interception; this is not intended to mitigate active attackers 1344 who have compromised service provider systems. 1346 It could be argued that sharing the name and version of the client 1347 software with the server has privacy implications. Although 1348 providing this information is not required, it is encouraged so that 1349 mail service providers can more effectively inform end-users running 1350 old clients that they need to upgrade to protect their security, or 1351 know which clients to use in a test deployment prior to upgrading a 1352 server to have higher security requirements. 1354 13. References 1356 13.1. Normative References 1358 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1359 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 1360 . 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1364 RFC2119, March 1997, 1365 . 1367 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 1368 Mechanism", RFC 2449, DOI 10.17487/RFC2449, November 1998, 1369 . 1371 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 1372 RFC2818, May 2000, 1373 . 1375 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, 1376 DOI 10.17487/RFC2971, October 2000, 1377 . 1379 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1380 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 1381 February 2002, . 1383 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1384 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1385 . 1387 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1388 for Delivery Status Notifications", RFC 3464, 1389 DOI 10.17487/RFC3464, January 2003, 1390 . 1392 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1393 Resource Identifier (URI): Generic Syntax", STD 66, 1394 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1395 . 1397 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol 1398 (POP3) Simple Authentication and Security Layer (SASL) 1399 Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034, 1400 July 2007, . 1402 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1403 Finch, "Email Submission Operations: Access and 1404 Accountability Requirements", BCP 134, RFC 5068, 1405 DOI 10.17487/RFC5068, November 2007, 1406 . 1408 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1409 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1410 RFC5234, January 2008, 1411 . 1413 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1414 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1415 RFC5246, August 2008, 1416 . 1418 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1419 Mail System Status Codes", BCP 138, RFC 5248, 1420 DOI 10.17487/RFC5248, June 2008, 1421 . 1423 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1424 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1425 DOI 10.17487/RFC5226, May 2008, 1426 . 1428 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1429 Housley, R., and W. Polk, "Internet X.509 Public Key 1430 Infrastructure Certificate and Certificate Revocation List 1431 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1432 . 1434 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1435 DOI 10.17487/RFC5321, October 2008, 1436 . 1438 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1439 DOI 10.17487/RFC5322, October 2008, 1440 . 1442 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1443 Submission/Access Services", RFC 6186, DOI 10.17487/ 1444 RFC6186, March 2011, 1445 . 1447 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1448 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 1449 . 1451 [I-D.ietf-uta-email-tls-certs] 1452 Melnikov, A., "Updated TLS Server Identity Check Procedure 1453 for Email Related Protocols", 1454 draft-ietf-uta-email-tls-certs-09 (work in progress), 1455 December 2015. 1457 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1458 "Recommendations for Secure Use of Transport Layer 1459 Security (TLS) and Datagram Transport Layer Security 1460 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 1461 May 2015, . 1463 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 1464 Opportunistic DNS-Based Authentication of Named Entities 1465 (DANE) Transport Layer Security (TLS)", RFC 7672, 1466 DOI 10.17487/RFC7672, October 2015, 1467 . 1469 13.2. Informative References 1471 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1472 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1473 . 1475 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1476 Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, 1477 . 1479 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 1480 Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, 1481 . 1483 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 1484 DOI 10.17487/RFC3887, September 2004, 1485 . 1487 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1488 (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/ 1489 RFC4346, April 2006, 1490 . 1492 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1493 Authentication and Security Layer (SASL)", RFC 4422, 1494 DOI 10.17487/RFC4422, June 2006, 1495 . 1497 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 1498 Extension for Authentication", RFC 4954, DOI 10.17487/ 1499 RFC4954, July 2007, 1500 . 1502 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1503 DOI 10.17487/RFC5598, July 2009, 1504 . 1506 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1507 "Salted Challenge Response Authentication Mechanism 1508 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 1509 DOI 10.17487/RFC5802, July 2010, 1510 . 1512 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 1513 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 1514 July 2010, . 1516 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1517 Extensions: Extension Definitions", RFC 6066, 1518 DOI 10.17487/RFC6066, January 2011, 1519 . 1521 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1522 Verification of Domain-Based Application Service Identity 1523 within Internet Public Key Infrastructure Using X.509 1524 (PKIX) Certificates in the Context of Transport Layer 1525 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, 1526 March 2011, . 1528 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1529 Cheshire, "Internet Assigned Numbers Authority (IANA) 1530 Procedures for the Management of the Service Name and 1531 Transport Protocol Port Number Registry", BCP 165, 1532 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1533 . 1535 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1536 of Named Entities (DANE) Transport Layer Security (TLS) 1537 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, 1538 August 2012, . 1540 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1541 Transport Security (HSTS)", RFC 6797, DOI 10.17487/ 1542 RFC6797, November 2012, 1543 . 1545 Appendix A. Design Considerations 1547 This section is not normative. 1549 The first version of this was written independently from 1550 draft-moore-email-tls-00.txt; subsequent versions merge ideas from 1551 both drafts. 1553 One author of this document was also the author of RFC 2595 that 1554 became the standard for TLS usage with POP and IMAP, and the other 1555 author was perhaps the first to propose that idea. In hindsight both 1556 authors now believe that that approach was a mistake. At this point 1557 the authors believe that while anything that makes it easier to 1558 deploy TLS is good, the desirable end state is that these protocols 1559 always use TLS, leaving no need for a separate port for cleartext 1560 operation except to support legacy clients while they continue to be 1561 used. The separate port model for TLS is inherently simpler to 1562 implement, debug and deploy. It also enables a "generic TLS load- 1563 balancer" that accepts secure client connections for arbitrary foo- 1564 over-TLS protocols and forwards them to a server that may or may not 1565 support TLS. Such load-balancers cause many problems because they 1566 violate the end-to-end principle and the server loses the ability to 1567 log security-relevant information about the client unless the 1568 protocol is designed to forward that information (as this 1569 specification does for the cipher suite). However, they can result 1570 in TLS deployment where it would not otherwise happen which is a 1571 sufficiently important goal that it overrides the problems. 1573 Although STARTTLS appears only slightly more complex than separate- 1574 port TLS, we again learned the lesson that complexity is the enemy of 1575 security in the form of the STARTTLS command injection vulnerability 1576 (CERT vulnerability ID #555316). Although there's nothing inherently 1577 wrong with STARTTLS, the fact it resulted in a common implementation 1578 error (made independently by multiple implementers) suggests it is a 1579 less secure architecture than Implicit TLS. 1581 Section 7 of RFC 2595 critiques the separate-port approach to TLS. 1582 The first bullet was a correct critique. There are proposals in the 1583 http community to address that, and use of SRV records as described 1584 in RFC 6186 resolves that critique for email. The second bullet is 1585 correct as well, but not very important because useful deployment of 1586 security layers other than TLS in email is small enough to be 1587 effectively irrelevant. The third bullet is incorrect because it 1588 misses the desirable option of "use and latch-on TLS if available". 1589 The fourth bullet may be correct, but is not a problem yet with 1590 current port consumption rates. The fundamental error was 1591 prioritizing a perceived better design based on a mostly valid 1592 critique over real-world deployability. But getting security and 1593 confidentiality facilities actually deployed is so important it 1594 should trump design purity considerations. 1596 Port 465 is presently used for two purposes: for submissions by a 1597 large number of clients and service providers and for the "urd" 1598 protocol by one vendor. Actually documenting this current state is 1599 controversial as discussed in the IANA considerations section. 1600 However, there is no good alternative. Registering a new port for 1601 submissions when port 465 is widely used for that purpose already 1602 will just create interoperability problems. Registering a port 1603 that's only used if advertised by an SRV record (RFC 6186) would not 1604 create interoperability problems but would require all client and 1605 server deployments and software to change significantly which is 1606 contrary to the goal of promoting more TLS use. Encouraging use of 1607 STARTTLS on port 587 would not create interoperability problems, but 1608 is unlikely to have impact on current undocumented use of port 465 1609 and makes the guidance in this document less consistent. The 1610 remaining option is to document the current state of the world and 1611 support future use of port 465 for submission as this increases 1612 consistency and ease-of-deployment for TLS email submission. 1614 Appendix B. Change Log 1616 Changes since draft-ietf-uta-email-deep-03: 1618 o Add more references to ietf-uta-email-tls-certs in implementation 1619 requirements section. 1621 o Replace primary reference to RFC 6125 with ietf-uta-email-tls- 1622 certs, so move RFC 6125 to informative list for this 1623 specification. 1625 Changes since draft-ietf-uta-email-deep-02: 1627 o Make reference to design considerations explicit rather than 1628 "elsewhere in this document". 1630 o Change provider requirement so SMTP submission services are 1631 separate from SMTP MTA services as opposed to the previous 1632 phrasing that required the servers be separate (which is too 1633 restrictive). 1635 o Update DANE SMTP reference 1637 Changes since draft-ietf-uta-email-deep-01: 1639 o Change text in tls11 and tls12 registrations to clarify 1640 certificate rules, including additional PKIX and DANE references. 1642 o Change from tls10 to tls11 (including reference) as the minimum. 1644 o Fix typo in example 5. 1646 o Remove open issues section; enough time has passed so not worth 1647 waiting for more input. 1649 Changes since draft-ietf-uta-email-deep-00: 1651 o Update and clarify abstract 1653 o use term confidentiality instead of privacy in most cases. 1655 o update open issues to request input for missing text. 1657 o move certificate pinning sub-section to account setup section and 1658 attempt to define it more precisely. 1660 o Add note about end-to-end encryption in AVAS section. 1662 o swap order of DNSSEC and TLSA sub-sections. 1664 o change meaning of 'tls10' and 'tls12' latches to require 1665 certificate validation. 1667 o Replace cipher suite advice with reference to RFC 7525. Change 1668 examples to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as cipher 1669 suite. 1671 o Add text to update IMAP, POP3 and Message Submission standards 1672 with newer TLS advice. 1674 o Add clearer text in introduction that this does not cover SMTP 1675 relay. 1677 o Update references to uta-tls-certs. 1679 o Add paragraph to Implicit TLS for SMTP Submission section 1680 recommending that STARTTLS also be implemented. 1682 Changes since draft-newman-email-deep-02: 1684 o Changed "privacy assurance" to "confidentiality assurance" 1686 o Changed "low privacy assurance" to "no confidentiality assurance" 1688 o Attempt to improve definition of confidentiality assurance level. 1690 o Add SHOULD indicate when MUA is showing list of mail accounts. 1692 o Add SHOULD NOT latch tls10, tls12 tags until TLS negotiated. 1694 o Removed sentence about deleting and re-creating the account in 1695 latch failure section. 1697 o Remove use of word "fallback" with respect to TLS version 1698 negotiation. 1700 o Added bullet about changes to Internet facing servers to MSP 1701 section. 1703 o minor wording improvements based on feedback 1705 Changes since -01: 1707 o Updated abstract, introduction and document structure to focus 1708 more on mail user agent privacy assurance. 1710 o Added email account privacy section, also moving section on 1711 account setup using SRV records to that section. 1713 o Finished writing IANA considerations section 1715 o Remove provisional concept and instead have server explicitly list 1716 security tags clients should latch. 1718 o Added note that rules for the submissions port follow the same 1719 rules as those for the submit port. 1721 o Reference and update advice in [RFC5068]. 1723 o Fixed typo in Client Certificate Authentication section. 1725 o Removed tls-pfs security latch and all mention of perfect forward 1726 secrecy as it was controversial. 1728 o Added reference to HSTS. 1730 Changes since -00: 1732 o Rewrote introduction to merge ideas from draft-moore-email-tls-00. 1734 o Added Implicit TLS section, Account configuration section and IANA 1735 port registration updates based on draft-moore-email-tls-00. 1737 o Add protocol details necessary to standardize implicit TLS for 1738 POP/IMAP/submission, using ideas from 1739 draft-melnikov-pop3-over-tls. 1741 o Reduce initial set of security tags based on feedback. 1743 o Add deep status concept to allow a window for software updates to 1744 be backed out before latches make that problematic, as well as to 1745 provide service providers with a mechanism they can use to assist 1746 customers in the event of a privacy failure. 1748 o Add DNS SRV section from draft-moore-email-tls-00. 1750 o Write most of the missing IANA considerations section. 1752 o Rewrite most of implementation requirements section based more on 1753 draft-moore-email-tls-00. Remove new cipher requirements for now 1754 because those may be dealt with elsewhere. 1756 Appendix C. Acknowledgements 1758 Thanks to Ned Freed for discussion of the initial latch concepts in 1759 this document. Thanks to Alexey Melnikov for 1760 draft-melnikov-pop3-over-tls-02, which was the basis of the POP3 1761 implicit TLS text. Thanks to Russ Housley, Alexey Melnikov and Dan 1762 Newman for review feedback. Thanks to Paul Hoffman for interesting 1763 feedback in initial conversations about this idea. 1765 Authors' Addresses 1767 Keith Moore 1768 Network Heretics 1769 PO Box 1934 1770 Knoxville, TN 37901 1771 US 1773 Email: moore@network-heretics.com 1775 Chris Newman 1776 Oracle 1777 440 E. Huntington Dr., Suite 400 1778 Arcadia, CA 91006 1779 US 1781 Email: chris.newman@oracle.com