idnits 2.17.1 draft-ietf-uta-email-deep-03.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 11, 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 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-09) exists of draft-ietf-uta-email-tls-certs-03 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Moore 3 Internet-Draft Network Heretics 4 Updates: 1939, 2595, 3464, 3501, 5068, C. Newman 5 6186, 6409 (if approved) Oracle 6 Intended status: Standards Track March 11, 2016 7 Expires: September 12, 2016 9 Deployable Enhanced Email Privacy (DEEP) 10 draft-ietf-uta-email-deep-03.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 12, 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. 825 o The standard for use of TLS with IMAP, POP3 and ACAP [RFC2595] is 826 modified to revoke section 2.1 and replace it with the text from 827 the first three bullet items in this list. 829 o The standard for Message Submission [RFC6409] is updated to add 830 the first three bullet items above to section 4.3 as well as to 831 require implementation of the TLS server identity check as 832 described in [I-D.ietf-uta-email-tls-certs] and PKIX [RFC5280]. 834 9.1.1. Client Certificate Authentication 836 MUAs and mail servers MAY implement client certificate authentication 837 on the implicit TLS port. Servers MUST NOT request a client 838 certificate during the TLS handshake unless the server is configured 839 to accept some client certificates as sufficient for authentication 840 and the server has the ability to determine a mail server 841 authorization identity matching such certificates. How to make this 842 determination is presently implementation specific. Clients MUST NOT 843 provide a client certificate during the TLS handshake unless the 844 server requests one and the client has determined the certificate can 845 be safely used with that specific server, OR the client has been 846 explicitly configured by the user to use that particular certificate 847 with that server. How to make this determination is presently 848 implementation specific. If the server accepts the client's 849 certificate as sufficient for authorization, it MUST enable the SASL 850 EXTERNAL [RFC4422] mechanism. An IMAPS server MAY issue a PREAUTH 851 greeting instead of enabling SASL EXTERNAL. A client supporting 852 client certificate authentication with implicit TLS MUST implement 853 the SASL EXTERNAL [RFC4422] mechanism using the appropriate 854 authentication command (AUTH for POP3 [RFC5034], AUTH for SMTP 855 Submission [RFC4954], AUTHENTICATE for IMAP [RFC3501]). 857 9.2. Mail Server Implementation Requirements 859 These requirements apply to servers that implement POP, IMAP or SMTP 860 Submission. 862 o Servers MUST implement the DEEP extension described in Section 7 864 o IMAP and SMTP submission servers SHOULD implement and be 865 configurable to support STARTTLS. This enables discovery of new 866 TLS availability, and can increase usage of TLS by legacy clients. 868 o Servers MUST NOT advertise STARTTLS if it is unlikely to succeed 869 based on server configuration (e.g., there is no server 870 certificate installed). 872 o SMTP message submission servers that have negotiated TLS SHOULD 873 add a Received header field to the message including the tls 874 clause described in Section 6. 876 o Servers MUST be configurable to include the TLS cipher information 877 in any connection or user logging or auditing facility they 878 provide. 880 9.3. Mail User Agent Implementation Requirements 882 This section describes requirements on Mail User Agents (MUAs) using 883 IMAP, POP, and/or Submission protocols. Note: Requirements 884 pertaining to use of Submission servers are also applicable to use of 885 SMTP servers (e.g., port 25) for mail submission. 887 o User agents SHOULD indicate to users at configuration time, the 888 expected level of confidentiality based on appropriate security 889 inputs such as which security latches are pre-set, the number of 890 trust anchors, certificate validity, use of an extended validation 891 certificate, TLS version supported, and TLS cipher suites 892 supported by both server and client. This indication SHOULD also 893 be present when editing or viewing account configuration. 895 o MUAs SHOULD detect when STARTTLS and/or implicit TLS becomes 896 available for a protocol and set the tls11 latch if the server 897 advertises the tls11 security tag after a successful TLS 898 negotiation. 900 o Whenever requested to establish any configuration that does not 901 require both TLS and server certificate verification to talk to a 902 server or account, an MUA SHOULD warn its user that his or her 903 mail traffic (including password, if applicable) will be exposed 904 to attackers, and give the user an opportunity to abort the 905 connection prior to transmission of any such password or traffic. 907 o MUAs SHOULD implement the "tls12" security latch (the TLS library 908 has to provide an API that controls permissible TLS versions and 909 communicates the negotiated TLS protocol version to the 910 application for this to be possible). 912 o See Section 3 for additional requirements. 914 9.4. Non-configurable MUAs and nonstandard access protocols 916 MUAs which are not configurable to use user-specified servers MUST 917 implement TLS or similarly other strong encryption mechanism when 918 communicating with their mail servers. This generally applies to 919 MUAs that are pre-configured to operate with one or more specific 920 services, whether or not supplied by the vendor of those services. 922 MUAs using protocols other than IMAP, POP, and Submission to 923 communicate with mail servers, MUST implement TLS or other similarly 924 robust encryption mechanism in conjunction with those protocols. 926 9.5. DEEP Compliance for Anti-Virus/Anti-Spam Software and Services 928 There are multiple ways to connect an Anti-Virus and/or Anti-Spam 929 (AVAS) service to a mail server. Some mechanisms, such as the de- 930 facto milter protocol do not impact DEEP. However, some services use 931 an SMTP relay proxy that intercepts mail at the application layer to 932 perform a scan and proxy or forward to another MTA. Deploying AVAS 933 services in this way can cause many problems [RFC2979] including 934 direct interference with DEEP and confidentiality or security 935 reduction. An AVAS product or service is considered DEEP compliant 936 if all IMAP, POP and SMTP-related software it includes is DEEP 937 compliant and it advertises and supports all security latches that 938 the actual servers advertise. 940 Note that end-to-end email encryption prevents AVAS software and 941 services from using email content as part of a spam or virus 942 assessment. Furthermore, while DEEP high confidentiality assurance 943 can prevent a man-in-the-middle from introducing spam or virus 944 content between the MUA and Submission server, it does not prevent 945 other forms of client or account compromise so use of AVAS services 946 for submitted email remains necessary. 948 10. Mail Service Provider Requirements 950 This section details requirements for providers of IMAP, POP, and/or 951 SMTP submission services, for providers who claim to conform to this 952 specification. 954 10.1. Server Requirements 956 Mail Service Providers MUST use server implementations that conform 957 to this specification. 959 10.2. MSPs MUST provide Submission Servers 961 This document updates the advice in [RFC5068] by making Implicit TLS 962 on port 465 the preferred submission port. 964 Mail Service Providers that accept mail submissions from end-users 965 using the Internet Protocol MUST provide one or more SMTP Submission 966 services, separate from the SMTP MTA services used to process 967 incoming mail. Those submission services MUST be configured to 968 support Implicit TLS on port 465 and SHOULD support STARTTLS if port 969 587 is used. 971 MSPs MAY also support submission of messages via one or more 972 designated SMTP servers to facilitate compatibility with legacy MUAs. 974 Discussion: SMTP servers used to accept incoming mail or to relay 975 mail are expected to accept mail in cleartext. This is incompatible 976 with the purpose of this memo which is to encourage encryption of 977 traffic between mail servers. There is no such requirement for mail 978 submission servers to accept mail in cleartext or without 979 authentication. For other reasons, use of separate SMTP submission 980 servers has been best practice for many years. 982 10.3. TLS Server Certificate Requirements 984 MSPs MUST maintain valid server certificates for all servers. Those 985 server certificates SHOULD present DNS-IDs and SRV-IDs conforming to 986 [RFC6125] and which will be recognized by MUAs meeting the 987 requirements of that specification. In addition, those server 988 certificates MAY provide other DNS-IDs, SRV-IDs, or CN-IDs needed for 989 compatibility with existing MUAs. 991 If a protocol server provides service for more than one mail domain, 992 it MAY use a separate IP address for each domain and/or a server 993 certificate that advertises multiple domains. This will generally be 994 necessary unless and until it is acceptable to impose the constraint 995 that the server and all clients support the Server Name Indication 996 extension to TLS [RFC6066]. 998 10.4. Recommended DNS records for mail protocol servers 1000 This section discusses not only the DNS records that are recommended, 1001 but also implications of DNS records for server configuration and TLS 1002 server certificates. 1004 10.4.1. MX records 1006 It is recommended that MSPs advertise MX records for handling of 1007 inbound mail (instead of relying entirely on A or AAAA records), and 1008 that those MX records be signed using DNSSEC. This is mentioned here 1009 only for completeness, as handling of inbound mail is out of scope 1010 for this document. 1012 10.4.2. SRV records 1014 MSPs SHOULD advertise SRV records to aid MUAs in determination of 1015 proper configuration of servers, per the instructions in [RFC6186]. 1017 MSPs SHOULD advertise servers that support Implicit TLS in preference 1018 to those which support cleartext and/or STARTTLS operation. 1020 10.4.3. DNSSEC 1022 All DNS records advertised by an MSP as a means of aiding clients in 1023 communicating with the MSP's servers, SHOULD be signed using DNSSEC. 1025 10.4.4. TLSA records 1027 MSPs SHOULD advertise TLSA records to provide an additional trust 1028 anchor for public keys used in TLS server certificates. However, 1029 TLSA records MUST NOT be advertised unless they are signed using 1030 DNSSEC. 1032 10.5. MSP Server Monitoring 1034 MSPs SHOULD regularly and frequently monitor their various servers to 1035 make sure that: TLS server certificates remain valid and are not 1036 about to expire, TLSA records match the public keys advertised in 1037 server certificates, are signed using DNSSEC, server configurations 1038 are consistent with SRV advertisements, and DNSSEC signatures are 1039 valid and verifiable. Failure to detect expired certificates and DNS 1040 configuration errors in a timely fashion can result in significant 1041 loss of service for an MSP's users and a significant support burden 1042 for the MSP. 1044 10.6. Advertisement of DEEP status 1046 MSPs SHOULD advertise a DEEP status that includes tls11, tls-cert and 1047 an HTTPS URL that can be used to inform clients of service outages or 1048 problems impacting client confidentiality. Note that advertising 1049 tls-cert is a commitment to maintain and renew server certificates. 1051 10.7. Require TLS 1053 New servers and services SHOULD be configured to require TLS unless 1054 it's necessary to support legacy clients or existing client 1055 configurations. 1057 10.8. Changes to Internet Facing Servers 1059 When an MSP changes the Internet Facing Servers providing mail access 1060 and mail submission services, including SMTP-based spam/virus 1061 filters, it is generally necessary to support the same and/or a newer 1062 version of TLS and the same security tags that were previously 1063 advertised. 1065 11. IANA Considerations 1067 11.1. Security Tag Registry 1069 IANA shall create (has created) the registry "Email Security Tags". 1070 This registry is a single table and will use an expert review process 1071 [RFC5226]. Each registration will contain the following fields: 1073 Name: The name of the security tag. This follows the security-tag 1074 ABNF. 1076 Description: This describes the meaning of the security tag and the 1077 conditions under which the tag is latched. 1079 Intended Usage: One of COMMON, LIMITED USE or OBSOLETE. 1081 Reference: Optional reference to specification. 1083 Submitter: The identify of the submitter or submitters. 1085 Change Controller: The identity of the change controller for the 1086 registration. This will be "IESG" in case of registrations in 1087 IETF-produced documents. 1089 The expert reviewer will verify the tag name follows the ABNF, and 1090 that the description field is clear, unambiguous, does not overlap 1091 existing deployed technology, does not create security problems and 1092 appropriately considers interoperability issues. Email security tags 1093 intended for LIMITED USE have a lower review bar (interoperability 1094 and overlap issues are less of a concern). The reviewer may approve 1095 a registration, reject for a stated reason or recommend the proposal 1096 have standards track review due to importance or difficult 1097 subtleties. 1099 Standards-track registrations may be updated if the relevant 1100 standards are updated as a consequence of that action. Non- 1101 standards-track entries may be updated by the listed change 1102 controller. The entry's name and submitter may not be changed. In 1103 exceptional cases, any aspect of any registered entity may be updated 1104 at the direction of the IESG (for example, to correct a conflict). 1106 11.2. Initial Set of Security Tags 1108 This document defines four initial security tags for the security tag 1109 registry as follows: 1111 Name: tls11 1113 Description: This indicates TLS version 1.1 [RFC4346] or later was 1114 negotiated successfully including negotiation of a strong 1115 encryption layer with a symmetric key of at least 128 bits. This 1116 tag indicates the server certificate was valid but does not 1117 indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE 1118 [RFC6698]). This tag is latched if the client sees this tag in 1119 the advertised server DEEP status provided after successfully 1120 negotiating TLS version 1.0 or later. 1122 Intended Usage: COMMON 1124 Reference: RFC XXXX (this document once published) 1126 Submitter: Authors of this document 1127 Change Controller: IESG 1129 Name: tls12 1131 Description: This indicates TLS version 1.2 [RFC5246] or later was 1132 negotiated successfully including negotiation of a strong 1133 encryption layer with a symmetric key of at least 128 bits. This 1134 tag indicates the server certificate was valid but does not 1135 indicate the validation mechanism (e.g., PKIX [RFC5280] or DANE 1136 [RFC6698]). This tag is latched if the client sees this tag in 1137 the advertised server DEEP status provided after successfully 1138 negotiating TLS version 1.2 or later. 1140 Intended Usage: COMMON 1142 Reference: RFC XXXX (this document once published) 1144 Submitter: Authors of this document 1146 Change Controller: IESG 1148 Name: tls-cert 1150 Description: This tag indicates that TLS was successfully negotiated 1151 and the server certificate was successfully verified by the client 1152 using PKIX [RFC5280] and the server certificate identity was 1153 verified using the algorithm appropriate for the protocol (see 1154 Section 4). This tag is latched if the client sees this tag in 1155 the advertised server DEEP status after successfully negotiating 1156 TLS and verifying the certificate and server identity. 1158 Intended Usage: COMMON 1160 Reference: RFC XXXX (this document once published) 1162 Submitter: Authors of this document 1164 Change Controller: IESG 1166 Name: tls-dane-tlsa 1168 Description: This tag indicates that TLS was successfully negotiated 1169 and the server certificate was successfully verified by the client 1170 using the procedures described in [RFC6698] and the server 1171 certificate identity was verified using the algorithm appropriate 1172 for the protocol (see Section 4). This tag is latched if the 1173 client sees this tag in the advertised server DEEP status after 1174 successfully negotiating TLS and verifying the certificate and 1175 server identity. 1177 Intended Usage: COMMON 1179 Reference: RFC XXXX (this document once published) 1181 Submitter: Authors of this document 1183 Change Controller: IESG 1185 11.3. POP3S Port Registration Update 1187 IANA is asked to update the registration of the TCP well-known port 1188 995 using the following template ([RFC6335]): 1190 Service Name: pop3s 1191 Transport Protocol: TCP 1192 Assignee: IETF 1193 Contact: IESG 1194 Description: POP3 over TLS protocol 1195 Reference: RFC XXXX (this document once published) 1197 Service Name: pop3s 1198 Transport Protocol: TCP 1199 Assignee: IETF 1200 Contact: IESG 1201 Description: POP3 over TLS protocol 1202 Reference: RFC XXXX (this document once published) 1204 11.4. IMAPS Port Registration Update 1206 IANA is asked to update the registration of the TCP well-known port 1207 993 using the following template ([RFC6335]): 1209 Service Name: imaps 1210 Transport Protocol: TCP 1211 Assignee: IETF 1212 Contact: IESG 1213 Description: IMAP over TLS protocol 1214 Reference: RFC XXXX (this document once published) 1216 Service Name: imaps 1217 Transport Protocol: TCP 1218 Assignee: IETF 1219 Contact: IESG 1220 Description: IMAP over TLS protocol 1221 Reference: RFC XXXX (this document once published) 1223 11.5. Submissions Port Registration 1225 IANA is asked to assign an alternate usage of port 465 in addition to 1226 the current assignment using the following template ([RFC6335]): 1228 Service Name: submissions 1229 Transport Protocol: TCP 1230 Assignee: IETF 1231 Contact: IESG 1232 Description: Message Submission over TLS protocol 1233 Reference: RFC XXXX (this document once published) 1235 Service Name: submissions 1236 Transport Protocol: TCP 1237 Assignee: IETF 1238 Contact: IESG 1239 Description: Message Submission over TLS protocol 1240 Reference: RFC XXXX (this document once published) 1242 This is a one time procedural exception to the rules in RFC 6335. 1243 This requires explicit IESG approval and does not set a precedent. 1244 Historically, port 465 was briefly registered as the "smtps" port. 1245 This registration made no sense as the SMTP transport MX 1246 infrastructure has no way to specify a port so port 25 is always 1247 used. As a result, the registration was revoked and was subsequently 1248 reassigned to a different service. In hindsight, the "smtps" 1249 registration should have been renamed or reserved rather than 1250 revoked. Unfortunately, some widely deployed mail software 1251 interpreted "smtps" as "submissions" [RFC6409] and used that port for 1252 email submission by default when an end-user requests security during 1253 account setup. If a new port is assigned for the submissions 1254 service, email software will either continue with unregistered use of 1255 port 465 (leaving the port registry inaccurate relative to de-facto 1256 practice and wasting a well-known port), or confusion between the de- 1257 facto and registered ports will cause harmful interoperability 1258 problems that will deter use of TLS for message submission. The 1259 authors believe both of these outcomes are less desirable than a wart 1260 in the registry documenting real-world usage of a port for two 1261 purposes. Although STARTTLS-on-port-587 has deployed, it has not 1262 replaced deployed use of implicit TLS submission on port 465. 1264 11.6. DEEP IMAP Capability 1266 This document adds the DEEP capability to the IMAP capabilities 1267 registry. This is described in Section 7.1. 1269 11.7. DEEP POP3 Capability 1271 This document adds the DEEP capability to the POP3 capabilities 1272 registry. 1274 CAPA Tag: DEEP 1276 Arguments: deep-status 1278 Added Commands: none 1280 Standard Commands affected: none 1282 Announced status / possible differences: both / may change after 1283 STLS 1285 Commands Valid in States: N/A 1287 Specification Reference: This document 1289 Discussion: See Section 7.2. 1291 11.8. DEEP SMTP EHLO Keyword 1293 This document adds the DEEP EHLO Keyword to the SMTP Service 1294 Extension registry. This is described in Section 7.3. 1296 11.9. SMTP Enhanced Status Code 1298 This document adds the following entry to the "SMTP Enhanced Status 1299 Codes" registry created by [RFC5248]. 1301 Code: X.7.TBD (IANA, please assign the next available number) 1303 Sample Text: Message Transport Failed due to missing required 1304 security. 1306 Associated Basic Status Code: 450, 454, 550, 554 1308 Description This code indicates an SMTP server was unable to forward 1309 a message to the next host necessary for delivery because it 1310 required a higher level of transport security or confidentiality 1311 than was available. The temporary form of this error is preferred 1312 in case the problem is caused by a temporary administrative error 1313 such as an expired server certificate. 1315 Reference This document 1317 Submitter C. Newman 1319 Change Controller IESG 1321 11.10. MAIL Parameters Additional-registered-clauses Sub-Registry 1323 This document adds the following entry to the "Additional-registered- 1324 clauses" sub-registry of the "MAIL Parameters" registry, created by 1325 [RFC5321]: 1327 Clause Name: tls 1329 Description: Indicates the TLS cipher suite used for a transport 1330 connection. 1332 Syntax Summary: See tls-cipher ABNF Section 6 1334 Reference: This document. 1336 12. Security Considerations 1338 This entire document is about security considerations. In general, 1339 this is targeted to improve mail confidentiality and to mitigate 1340 threats external to the email system such as network-level snooping 1341 or interception; this is not intended to mitigate active attackers 1342 who have compromised service provider systems. 1344 It could be argued that sharing the name and version of the client 1345 software with the server has privacy implications. Although 1346 providing this information is not required, it is encouraged so that 1347 mail service providers can more effectively inform end-users running 1348 old clients that they need to upgrade to protect their security, or 1349 know which clients to use in a test deployment prior to upgrading a 1350 server to have higher security requirements. 1352 13. References 1354 13.1. Normative References 1356 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 1357 STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, 1358 . 1360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1361 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1362 RFC2119, March 1997, 1363 . 1365 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 1366 Mechanism", RFC 2449, DOI 10.17487/RFC2449, November 1998, 1367 . 1369 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 1370 RFC2818, May 2000, 1371 . 1373 [RFC2971] Showalter, T., "IMAP4 ID extension", RFC 2971, 1374 DOI 10.17487/RFC2971, October 2000, 1375 . 1377 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1378 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 1379 February 2002, . 1381 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1382 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 1383 . 1385 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 1386 for Delivery Status Notifications", RFC 3464, 1387 DOI 10.17487/RFC3464, January 2003, 1388 . 1390 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1391 Resource Identifier (URI): Generic Syntax", STD 66, 1392 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1393 . 1395 [RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office Protocol 1396 (POP3) Simple Authentication and Security Layer (SASL) 1397 Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034, 1398 July 2007, . 1400 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 1401 Finch, "Email Submission Operations: Access and 1402 Accountability Requirements", BCP 134, RFC 5068, 1403 DOI 10.17487/RFC5068, November 2007, 1404 . 1406 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1407 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 1408 RFC5234, January 2008, 1409 . 1411 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1412 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1413 RFC5246, August 2008, 1414 . 1416 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 1417 Mail System Status Codes", BCP 138, RFC 5248, 1418 DOI 10.17487/RFC5248, June 2008, 1419 . 1421 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1422 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1423 DOI 10.17487/RFC5226, May 2008, 1424 . 1426 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1427 Housley, R., and W. Polk, "Internet X.509 Public Key 1428 Infrastructure Certificate and Certificate Revocation List 1429 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1430 . 1432 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1433 DOI 10.17487/RFC5321, October 2008, 1434 . 1436 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1437 DOI 10.17487/RFC5322, October 2008, 1438 . 1440 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1441 Verification of Domain-Based Application Service Identity 1442 within Internet Public Key Infrastructure Using X.509 1443 (PKIX) Certificates in the Context of Transport Layer 1444 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, 1445 March 2011, . 1447 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 1448 Submission/Access Services", RFC 6186, DOI 10.17487/ 1449 RFC6186, March 2011, 1450 . 1452 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1453 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 1454 . 1456 [I-D.ietf-uta-email-tls-certs] 1457 Melnikov, A., "Updated TLS Server Identity Check Procedure 1458 for Email Related Protocols", 1459 draft-ietf-uta-email-tls-certs-03 (work in progress), 1460 June 2015. 1462 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1463 "Recommendations for Secure Use of Transport Layer 1464 Security (TLS) and Datagram Transport Layer Security 1465 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, 1466 May 2015, . 1468 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via 1469 Opportunistic DNS-Based Authentication of Named Entities 1470 (DANE) Transport Layer Security (TLS)", RFC 7672, 1471 DOI 10.17487/RFC7672, October 2015, 1472 . 1474 13.2. Informative References 1476 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 1477 RFC 2595, DOI 10.17487/RFC2595, June 1999, 1478 . 1480 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1481 Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, 1482 . 1484 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 1485 Registration", RFC 3848, DOI 10.17487/RFC3848, July 2004, 1486 . 1488 [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, 1489 DOI 10.17487/RFC3887, September 2004, 1490 . 1492 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1493 (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/ 1494 RFC4346, April 2006, 1495 . 1497 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 1498 Authentication and Security Layer (SASL)", RFC 4422, 1499 DOI 10.17487/RFC4422, June 2006, 1500 . 1502 [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service 1503 Extension for Authentication", RFC 4954, DOI 10.17487/ 1504 RFC4954, July 2007, 1505 . 1507 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1508 DOI 10.17487/RFC5598, July 2009, 1509 . 1511 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1512 "Salted Challenge Response Authentication Mechanism 1513 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, 1514 DOI 10.17487/RFC5802, July 2010, 1515 . 1517 [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely 1518 Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, 1519 July 2010, . 1521 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1522 Extensions: Extension Definitions", RFC 6066, 1523 DOI 10.17487/RFC6066, January 2011, 1524 . 1526 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1527 Cheshire, "Internet Assigned Numbers Authority (IANA) 1528 Procedures for the Management of the Service Name and 1529 Transport Protocol Port Number Registry", BCP 165, 1530 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1531 . 1533 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1534 of Named Entities (DANE) Transport Layer Security (TLS) 1535 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, 1536 August 2012, . 1538 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 1539 Transport Security (HSTS)", RFC 6797, DOI 10.17487/ 1540 RFC6797, November 2012, 1541 . 1543 Appendix A. Design Considerations 1545 This section is not normative. 1547 The first version of this was written independently from 1548 draft-moore-email-tls-00.txt; subsequent versions merge ideas from 1549 both drafts. 1551 One author of this document was also the author of RFC 2595 that 1552 became the standard for TLS usage with POP and IMAP, and the other 1553 author was perhaps the first to propose that idea. In hindsight both 1554 authors now believe that that approach was a mistake. At this point 1555 the authors believe that while anything that makes it easier to 1556 deploy TLS is good, the desirable end state is that these protocols 1557 always use TLS, leaving no need for a separate port for cleartext 1558 operation except to support legacy clients while they continue to be 1559 used. The separate port model for TLS is inherently simpler to 1560 implement, debug and deploy. It also enables a "generic TLS load- 1561 balancer" that accepts secure client connections for arbitrary foo- 1562 over-TLS protocols and forwards them to a server that may or may not 1563 support TLS. Such load-balancers cause many problems because they 1564 violate the end-to-end principle and the server loses the ability to 1565 log security-relevant information about the client unless the 1566 protocol is designed to forward that information (as this 1567 specification does for the cipher suite). However, they can result 1568 in TLS deployment where it would not otherwise happen which is a 1569 sufficiently important goal that it overrides the problems. 1571 Although STARTTLS appears only slightly more complex than separate- 1572 port TLS, we again learned the lesson that complexity is the enemy of 1573 security in the form of the STARTTLS command injection vulnerability 1574 (CERT vulnerability ID #555316). Although there's nothing inherently 1575 wrong with STARTTLS, the fact it resulted in a common implementation 1576 error (made independently by multiple implementers) suggests it is a 1577 less secure architecture than Implicit TLS. 1579 Section 7 of RFC 2595 critiques the separate-port approach to TLS. 1580 The first bullet was a correct critique. There are proposals in the 1581 http community to address that, and use of SRV records as described 1582 in RFC 6186 resolves that critique for email. The second bullet is 1583 correct as well, but not very important because useful deployment of 1584 security layers other than TLS in email is small enough to be 1585 effectively irrelevant. The third bullet is incorrect because it 1586 misses the desirable option of "use and latch-on TLS if available". 1587 The fourth bullet may be correct, but is not a problem yet with 1588 current port consumption rates. The fundamental error was 1589 prioritizing a perceived better design based on a mostly valid 1590 critique over real-world deployability. But getting security and 1591 confidentiality facilities actually deployed is so important it 1592 should trump design purity considerations. 1594 Port 465 is presently used for two purposes: for submissions by a 1595 large number of clients and service providers and for the "urd" 1596 protocol by one vendor. Actually documenting this current state is 1597 controversial as discussed in the IANA considerations section. 1598 However, there is no good alternative. Registering a new port for 1599 submissions when port 465 is widely used for that purpose already 1600 will just create interoperability problems. Registering a port 1601 that's only used if advertised by an SRV record (RFC 6186) would not 1602 create interoperability problems but would require all client and 1603 server deployments and software to change significantly which is 1604 contrary to the goal of promoting more TLS use. Encouraging use of 1605 STARTTLS on port 587 would not create interoperability problems, but 1606 is unlikely to have impact on current undocumented use of port 465 1607 and makes the guidance in this document less consistent. The 1608 remaining option is to document the current state of the world and 1609 support future use of port 465 for submission as this increases 1610 consistency and ease-of-deployment for TLS email submission. 1612 Appendix B. Change Log 1614 Changes since draft-ietf-uta-email-deep-02: 1616 o Make reference to design considerations explicit rather than 1617 "elsewhere in this document". 1619 o Change provider requirement so SMTP submission services are 1620 separate from SMTP MTA services as opposed to the previous 1621 phrasing that required the servers be separate (which is too 1622 restrictive). 1624 o Update DANE SMTP reference 1626 Changes since draft-ietf-uta-email-deep-01: 1628 o Change text in tls11 and tls12 registrations to clarify 1629 certificate rules, including additional PKIX and DANE references. 1631 o Change from tls10 to tls11 (including reference) as the minimum. 1633 o Fix typo in example 5. 1635 o Remove open issues section; enough time has passed so not worth 1636 waiting for more input. 1638 Changes since draft-ietf-uta-email-deep-00: 1640 o Update and clarify abstract 1642 o use term confidentiality instead of privacy in most cases. 1644 o update open issues to request input for missing text. 1646 o move certificate pinning sub-section to account setup section and 1647 attempt to define it more precisely. 1649 o Add note about end-to-end encryption in AVAS section. 1651 o swap order of DNSSEC and TLSA sub-sections. 1653 o change meaning of 'tls10' and 'tls12' latches to require 1654 certificate validation. 1656 o Replace cipher suite advice with reference to RFC 7525. Change 1657 examples to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as cipher 1658 suite. 1660 o Add text to update IMAP, POP3 and Message Submission standards 1661 with newer TLS advice. 1663 o Add clearer text in introduction that this does not cover SMTP 1664 relay. 1666 o Update references to uta-tls-certs. 1668 o Add paragraph to Implicit TLS for SMTP Submission section 1669 recommending that STARTTLS also be implemented. 1671 Changes since draft-newman-email-deep-02: 1673 o Changed "privacy assurance" to "confidentiality assurance" 1675 o Changed "low privacy assurance" to "no confidentiality assurance" 1677 o Attempt to improve definition of confidentiality assurance level. 1679 o Add SHOULD indicate when MUA is showing list of mail accounts. 1681 o Add SHOULD NOT latch tls10, tls12 tags until TLS negotiated. 1683 o Removed sentence about deleting and re-creating the account in 1684 latch failure section. 1686 o Remove use of word "fallback" with respect to TLS version 1687 negotiation. 1689 o Added bullet about changes to Internet facing servers to MSP 1690 section. 1692 o minor wording improvements based on feedback 1693 Changes since -01: 1695 o Updated abstract, introduction and document structure to focus 1696 more on mail user agent privacy assurance. 1698 o Added email account privacy section, also moving section on 1699 account setup using SRV records to that section. 1701 o Finished writing IANA considerations section 1703 o Remove provisional concept and instead have server explicitly list 1704 security tags clients should latch. 1706 o Added note that rules for the submissions port follow the same 1707 rules as those for the submit port. 1709 o Reference and update advice in [RFC5068]. 1711 o Fixed typo in Client Certificate Authentication section. 1713 o Removed tls-pfs security latch and all mention of perfect forward 1714 secrecy as it was controversial. 1716 o Added reference to HSTS. 1718 Changes since -00: 1720 o Rewrote introduction to merge ideas from draft-moore-email-tls-00. 1722 o Added Implicit TLS section, Account configuration section and IANA 1723 port registration updates based on draft-moore-email-tls-00. 1725 o Add protocol details necessary to standardize implicit TLS for 1726 POP/IMAP/submission, using ideas from 1727 draft-melnikov-pop3-over-tls. 1729 o Reduce initial set of security tags based on feedback. 1731 o Add deep status concept to allow a window for software updates to 1732 be backed out before latches make that problematic, as well as to 1733 provide service providers with a mechanism they can use to assist 1734 customers in the event of a privacy failure. 1736 o Add DNS SRV section from draft-moore-email-tls-00. 1738 o Write most of the missing IANA considerations section. 1740 o Rewrite most of implementation requirements section based more on 1741 draft-moore-email-tls-00. Remove new cipher requirements for now 1742 because those may be dealt with elsewhere. 1744 Appendix C. Acknowledgements 1746 Thanks to Ned Freed for discussion of the initial latch concepts in 1747 this document. Thanks to Alexey Melnikov for 1748 draft-melnikov-pop3-over-tls-02, which was the basis of the POP3 1749 implicit TLS text. Thanks to Russ Housley, Alexey Melnikov and Dan 1750 Newman for review feedback. Thanks to Paul Hoffman for interesting 1751 feedback in initial conversations about this idea. 1753 Authors' Addresses 1755 Keith Moore 1756 Network Heretics 1757 PO Box 1934 1758 Knoxville, TN 37901 1759 US 1761 Email: moore@network-heretics.com 1763 Chris Newman 1764 Oracle 1765 440 E. Huntington Dr., Suite 400 1766 Arcadia, CA 91006 1767 US 1769 Email: chris.newman@oracle.com