SMTP Require TLS Option
draft-ietf-uta-smtp-require-tls-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-11-26
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-11-18
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-10-02
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-08-26
|
09 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Victor Kuarsingh was marked no-response |
2019-08-06
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-08-06
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-08-06
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-08-05
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-08-05
|
09 | (System) | IANA Action state changed to In Progress |
2019-08-05
|
09 | (System) | RFC Editor state changed to EDIT |
2019-08-05
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-08-05
|
09 | (System) | Announcement was received by RFC Editor |
2019-08-05
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-08-05
|
09 | Cindy Morgan | IESG has approved the document |
2019-08-05
|
09 | Cindy Morgan | Closed "Approve" ballot |
2019-08-05
|
09 | Cindy Morgan | Ballot approval text was generated |
2019-08-05
|
09 | Alexey Melnikov | All DISCUSSes were cleared and this is now ready to be approved. There is one incorrect substitution in the document that I corrected with an … All DISCUSSes were cleared and this is now ready to be approved. There is one incorrect substitution in the document that I corrected with an RFC Editor note. |
2019-08-05
|
09 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from IESG Evaluation - Defer::AD Followup |
2019-08-05
|
09 | Alexey Melnikov | RFC Editor Note was changed |
2019-08-05
|
09 | Alexey Melnikov | RFC Editor Note for ballot was generated |
2019-08-05
|
09 | Alexey Melnikov | RFC Editor Note for ballot was generated |
2019-08-02
|
09 | Benjamin Kaduk | [Ballot comment] Thank you for resolving my Discuss points! I do think the added text in Section 4.2.1 about DNS-ID/CN-ID should probably be clarified that … |
2019-08-02
|
09 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-08-02
|
09 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-09.txt |
2019-08-02
|
09 | (System) | New version approved |
2019-08-02
|
09 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2019-08-02
|
09 | Jim Fenton | Uploaded new revision |
2019-07-17
|
08 | Benjamin Kaduk | [Ballot discuss] I'm glad that we were able to come to consensus to rename the header field to "TLS-Required"; that addresses a key concern of … [Ballot discuss] I'm glad that we were able to come to consensus to rename the header field to "TLS-Required"; that addresses a key concern of mine. I also appreciate the addition of the "Policy Conflicts" section that portrays a fairly clear picture of the interaction between this mechanism, DANE, and MTA-STS. I still wish that we were able to bring the technologies into greater alignment and not need to convey the sense that standards-track mechanisms are in conflict with each other, but cannot justify blocking publication based solely on that desire. In this space, though, I do request an additional wording tweak in Appendix A.2, which currently states "The TLS-Required header field is used when the sender of the message wants to override the default policy of the recipient domain to require TLS." which uses the "override" terminology without couching it as a request. Can we reword to include "request" here as well? The following paragraph (unchanged from my ballot on -07) received only minimal discussion so far: I'm also concerned about the apparent new burden placed on senders in Section 4.3 to actively decide whether every outgoing message requires end-to-end TLS protection or is safe to forward without TLS ("when TLS is to be required, [...]. When TLS is not to be required, [...]"), where both "[...]" require new behavior not present in a client that does not implement this specification. To some extent this is an editorial matter of how the new mechanisms are portrayed, but I don't see much in this document to justify the stance that the default "don't care" option should be removed (for clients that implement this specification at all). It seems that we are in agreement that it's okay to have a "don't care" option, which is indicated by not using the extension at all. That said, I still think that the specific text of Section 4.3 conveys an impression that there is a requirement to actively decide, with the language about "has the authority to decide whether to require TLS", "when TLS is to be required", "when TLS is not to be required", and "in either case, the decision [...] MAY be done based on [...]". Perhaps I'm just misreading the text, but I haven't seen any signals to that effect yet. I'd suggest (but am open to further refinement" changing to "has the option to decide whether to require TLS" and "if one of these cases is selected, the decision [...]" as a way to clarify the language used. [discussion of "de facto part of the core SMTP spec" removed, on indications that this is not the intent] We had some good discussion about the three potential cases for authenticating the TLS connection: (1) Dane per RFC 7672 (2) MTA-STS per RFC 8461 (3) DNSSEC-validated MX records + WebPKI authentication of the MX hosts I think a little more specificity is needed for the (3) case; we do say to use the RFC 6125 procedures but still need to specify (e.g.) that the DNS-ID name type is used and (IIRC) that the hostname resulting from the MX lookup is used as the DNS-ID to be validated. |
2019-07-17
|
08 | Benjamin Kaduk | [Ballot comment] [original comment section unchanged; contents likely to be stale] Section 2 o The certificate presented by the SMTP server MUST either verify … [Ballot comment] [original comment section unchanged; contents likely to be stale] Section 2 o The certificate presented by the SMTP server MUST either verify successfully in a trust chain leading to a certificate trusted by the SMTP client or it MUST verify successfully using DANE as specified in RFC 7672 [RFC7672]. For trust chains, the choice of trusted (root) certificates is at the discretion of the SMTP client. I don't see how this requirement restricts the presented end-entity certificate so as to eliminate the attacks that exploit "the lack of server authentication by the client". What does certificate have to name in order to be trusted by the client? Section 4.1 Upon receipt of the REQUIRETLS option on a MAIL FROM command during the receipt of a message for which the return-path is not empty (indicating a bounce message), an SMTP server MUST tag that message as needing REQUIRETLS handling. What processing should happen when REQUIRETLS is received and the return-path *is* empty? If the REQUIRETLS MAIL FROM parameter is specified, the RequireTLS header field MUST be ignored but MAY be included in onward relay of the message. How could this scenario arise? (Why is it not a user error to attempt to use both -- isn't one requiring TLS and the other disclaiming its use, making them mutually incompatible?) Section 4.2.1 2. If the server lookup is accomplished via the recipient domain's MX record (the usual case) and is not accompanied by a valid DNSSEC signature, the client MUST also validate the SMTP server name using MTA-STS as described in RFC 8461 [RFC8461] Section 4.1. What happens if this validation fails? Perhaps the below text "If any of the above fails" could include "(including MTA-STS validation)" for extra clarity. 3. Open an SMTP session with the peer SMTP server using the EHLO verb. 4. Establish a TLS-protected SMTP session with its peer SMTP server and authenticate the server's certificate as specified in [RFC6125] or [RFC7672] as applicable. "STARTTLS" does not appear in here anywhere. Separately, is this combination of steps going to preclude any setups that (e.g., via preconfiguration) go straight to TLS with no STARTTLS negotiation? What name is used as input to certificate validation (for the 6125 branch)? Is Appendix B.4 therein supposed to be normative? (The Appendix B header indicates that the content is non-normative.) Section 4.2.2 Some SMTP servers may be configured to require STARTTLS connections as a matter of policy and not accept messages in the absence of STARTTLS. A non-delivery notification MUST be returned to the sender if message relay fails due to an inability to negotiate STARTTLS when required by the server. This is an "inability to negotiate" combined with a rejection of non-STARTTLS, right? Section 5 The path from the origination of an error bounce message back to the MAIL FROM address may not share the same REQUIRETLS support as the forward path. Therefore, users requiring TLS are advised to make sure that they are capable of receiving mail using REQUIRETLS as nit: "requiring TLS for outgoing mail"? If a REQUIRETLS message is bounced, the server MUST behave as if RET=HDRS was present as described in [RFC3461]. If both RET=FULL and REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS If the MAY is not taken, will the next hop be obligated to detect that this is a bounce and apply the preceding MUSTs? If not, perhaps this also should be a MUST? bounce message uses an empty MAIL FROM return-path as required by [RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message to be discarded even if the next-hop relay does not advertise REQUIRETLS. Perhaps an internal cross-reference up to Section 4.2.1 is in order? Senders of messages requiring TLS are advised to consider the possibility that bounce messages will be lost as a result of REQUIRETLS return path failure, and that some information could be leaked if a bounce message is not able to be transmitted with REQUIRETLS. It's not really clear how actionable this is. If you have a message that you want to send, you're either going to send it or not send it. What would you change about the message based on whether or not you could get a bounce, or whether or not the bounce would leak the message contents? Section 6 Mailing lists, upon receipt of a message, originate new messages to list addresses. This is distinct from an aliasing operation that redirects the original message, in some cases to multiple recipients. I'm not entirely sure how universally acknowledged this claim is; at MIT, we have lots of "mailing lists" implemented via the central Moira management database, but the actual implementation on the mailhubs is more like the aliasing operation described in the second sentence. Is there a need to make this distinction in order to support the following points, or could they stand on their own without this? The requirement to preserve the REQUIRETLS tag therefore does not necessarily extend to mailing lists, although the inclusion of the RequireTLS header field MAY cause messages sent to mailing lists to inherit this characteristic. [...] Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS header field have very different characteristics? I don't understand which one "this characteristic" is supposed to refer to. Mailing list operators MAY apply REQUIRETLS requirements in incoming messages to the resulting messages they originate. If this is done, they SHOULD also apply these requirements to administrative traffic, such as messages to moderators requesting approval of messages. Maybe note that such administrative traffic can include message contents intended for the list? Section 8.2 clear, where they can be intercepted. REQUIRETLS detects the failure of STARTTLS and declines to send the message rather than send it insecurely. nit: I'd say that REQUIRETLS requires the detection and declining, rather than doing so itself. REQUIRETLS requires successful certificate validation before sending the message. (As mentioned above, we need greater clarity about what the validation specifically entails.) REQUIRETLS requires that the recipient domain's MX record lookup be validated either using DNSSEC or via a published MTA-STS policy that specifies the acceptable SMTP server hostname(s) for the recipient domain. Are we then required to use those server hostname(s) in the certificate validation portion of the TLS connection? Section A.1 In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ please consider using IPv6 examples. |
2019-07-17
|
08 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-04-22
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-22
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-04-22
|
08 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-08.txt |
2019-04-22
|
08 | (System) | New version approved |
2019-04-22
|
08 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2019-04-22
|
08 | Jim Fenton | Uploaded new revision |
2019-03-18
|
07 | Valery Smyslov | Added to session: IETF-104: uta Tue-0900 |
2019-03-14
|
07 | Benjamin Kaduk | [Ballot discuss] I'm pretty sad to see that the "RequireTLS: no" header field has the name "require TLS" and the opposite semantics. It seems like … [Ballot discuss] I'm pretty sad to see that the "RequireTLS: no" header field has the name "require TLS" and the opposite semantics. It seems like the positvie signal that we are trying to indicate is "Ignore TLS" or "TLS optional" or similar; why does the header field need to be named "Require TLS" -- isn't that confusing to users, as opposed to, say, "TLS-Required"? While I understand that there can be cases where it is desired to ignore recipient-domain indications to use TLS, such as to report problems with the TLS capabilities of those domains, I have strong qualms about describing this protocol as an "override" for DANE and MTA-STS, or that such recipient-domain signals should be "ignored". In effect, by attempting to do so, this document is fundamentally modifying the protocol semantics for (SMTP) DANE and MTA-STS, something that can only properly be done by clearly calling out the behavior change and an Updates: relationship with the documents whose semantics are being modified (i.e., the DANE and MTA-STS specifications). Alternately, it could also be reasonable to remove claims of "override" or "ignore" and to leave the semantics of the header field as being that the sender requests one behavior, and the MTA can balance the requests of the sender and recipient at their own discretion. This is still not a great option, though, as it would seem to put multiple IETF proposed standards at odds with each other. I'm also concerned about the apparent new burden placed on senders in Section 4.3 to actively decide whether every outgoing message requires end-to-end TLS protection or is safe to forward without TLS ("when TLS is to be required, [...]. When TLS is not to be required, [...]"), where both "[...]" require new behavior not present in a client that does not implement this specification. To some extent this is an editorial matter of how the new mechanisms are portrayed, but I don't see much in this document to justify the stance that the default "don't care" option should be removed (for clients that implement this specification at all). [discussion of "de facto part of the core SMTP spec" removed, on indications that this is not the intent] I'm also unsure exactly how tightly nailed down the (non-DANE) TLS certificate validation process is supposed to be as a result of this document; more in the COMMENT section. It seems that without some form of strict certificate (host)name validation, this mechanism does not actually mitigate the lack of server authentication by the client that's described as a goal. That is, while the referenced DANE procedures for validating a TLS connection for SMTP are pretty clear and exhaustive, the non-DANE case does not seem to have thorough instructions for how to validate the TLS connection, whether in this document or an external reference. I'd also like to discuss whether it's safe to require that the tag and header be mutually exclusive. (As per the COMMENT section,) I don't have a great picture on what scenarios could cause that to arise, how common they are, and what the impact would be for strict enforcement, but there doesn't seem to be much reason to actively allow conflicting indications, even when we say which one takes precedence. |
2019-03-14
|
07 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2019-03-14
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer |
2019-03-14
|
07 | Warren Kumari | [Ballot comment] Apologies if this has been answered elsewhere, but as someone who send mail to mailing lists, I'm trying to figure out what: "REQUIRETLS … [Ballot comment] Apologies if this has been answered elsewhere, but as someone who send mail to mailing lists, I'm trying to figure out what: "REQUIRETLS users SHOULD be made aware of this limitation so that they use caution when sending to mailing lists and do not assume that REQUIRETLS applies to messages from the list operator to list members." actually means to me, and who is supposed to be making me aware of this. (actually, all my mail to lists goes to public lists, and so I personally don't care, but if I submitted mail to i_like_to_slather_myself_in_peanutbutter@unusualhobbies.org I might feel differently). |
2019-03-14
|
07 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-03-05
|
07 | Alexey Melnikov | Telechat date has been changed to 2019-03-14 from 2019-03-07 |
2019-02-22
|
07 | Yaron Sheffer | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Yaron Sheffer. Sent review to list. |
2019-02-21
|
07 | Eric Rescorla | [Ballot discuss] I support Benjamin's DISCUSS. To elaborate on one point a bit: it seems to me that it's harmful to security to allow the … [Ballot discuss] I support Benjamin's DISCUSS. To elaborate on one point a bit: it seems to me that it's harmful to security to allow the sender to unilaterally override the recipient's preferences that something be encrypted. To forestall one argument, yes, the sender knows the contents of the message, but the recipient knows their own circumstances, and they may be at particular risk The choices of key lengths and algorithms change over time, so a specific requirement is not presented here. This is not a verifiable conformance requirement. You either need to not have a 8174 SHOULD here, or actually specify what "meaningfully secure" means. |
2019-02-21
|
07 | Eric Rescorla | [Ballot comment] email by giving the originator of a message an expectation that it will be transmitted in an encrypted form "over the … [Ballot comment] email by giving the originator of a message an expectation that it will be transmitted in an encrypted form "over the wire". When used, REQUIRETLS changes the traditional behavior of email transmission, This does not seem to accurately describe "RequireTLS: NO" |
2019-02-21
|
07 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2019-02-21
|
07 | Alexey Melnikov | Telechat date has been changed to 2019-03-07 from 2019-02-21 |
2019-02-21
|
07 | Alexey Melnikov | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
2019-02-21
|
07 | Alissa Cooper | [Ballot comment] I support Benjamin's first three DISCUSS points. I feel like there are some fairly significant UI implications of adding this option to the … [Ballot comment] I support Benjamin's first three DISCUSS points. I feel like there are some fairly significant UI implications of adding this option to the mix of other tools for transport-level encryption support, given that this is supposed to operate on a message-by-message basis. Can you explain how this is expected to work? I have this concern generally but also in relation to this: "REQUIRETLS users SHOULD be made aware of this limitation so that they use caution when sending to mailing lists and do not assume that REQUIRETLS applies to messages from the list operator to list members." I can't figure out how this requirement is expected to be met in practice. |
2019-02-21
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-02-20
|
07 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-02-20
|
07 | Benjamin Kaduk | [Ballot discuss] I'm pretty sad to see that the "RequireTLS: no" header field has the name "require TLS" and the opposite semantics. It seems like … [Ballot discuss] I'm pretty sad to see that the "RequireTLS: no" header field has the name "require TLS" and the opposite semantics. It seems like the positvie signal that we are trying to indicate is "Ignore TLS" or "TLS optional" or similar; why does the header field need to be named "Require TLS" -- isn't that confusing to users? While I understand that there can be cases where it is desired to ignore recipient-domain indications to use TLS, such as to report problems with the TLS capabilities of those domains, I have strong qualms about describing this protocol as an "override" for DANE and MTA-STS, or that such recipient-domain signals should be "ignored". In effect, by attempting to do so, this document is fundamentally modifying the protocol semantics for (SMTP) DANE and MTA-STS, something that can only properly be done by clearly calling out the behavior change and an Updates: relationship with the documents whose semantics are being modified. Alternately, it could also be reasonable to remove claims of "override" or "ignore" and to leave the semantics of the header field as being that the sender requests one behavior, and the MTA can balance the requests of the sender and recipient at their own discretion. This is still not a great option, though, as it would seem to put multiple IETF proposed standards at odds with each other. I'm also concerned about the apparent new burden placed on senders to actively decide whether every outgoing message requires end-to-end TLS protection or is safe to forward without TLS, especially in light of the apparent goal (see next paragraph) of quickly achieving (near-)universal deployment. There doesn't seem to be much in this document to justify the stance that the default "don't care" option should be removed. The "must chain forward to final delivery" property for the REQUIRETLS option seems to present some incremental deployment difficulties, in that it will be nigh-impossible to successfully deliver such a message until there is fairly significant deployment coverage. E.g., if any major email hosting provider does not implement, then it will forever remain a niche technology. What indication to we have that this technology can succeed as specified? If we anticipate it becoming a part of the de facto core, mandatory, SMTP feature set, should we not indicate that by an Updates: relationship? I'm also unsure exactly how tightly nailed down the (non-DANE) TLS certificate validation process is supposed to be as a result of this document; more in the COMMENT section. It seems that without some form of strict certificate (host)name validation, this mechanism does not actually mitigate the lack of server authentication by the client that's described as a goal. I'd also like to discuss whether it's safe to require that the tag and header be mutually exclusive. (As per the COMMENT section,) I don't have a great picture on what scenarios could cause that to arise, how common they are, and what the impact would be for strict enforcement. |
2019-02-20
|
07 | Benjamin Kaduk | [Ballot comment] Section 2 o The certificate presented by the SMTP server MUST either verify successfully in a trust chain leading … [Ballot comment] Section 2 o The certificate presented by the SMTP server MUST either verify successfully in a trust chain leading to a certificate trusted by the SMTP client or it MUST verify successfully using DANE as specified in RFC 7672 [RFC7672]. For trust chains, the choice of trusted (root) certificates is at the discretion of the SMTP client. I don't see how this requirement restricts the presented end-entity certificate so as to eliminate the attacks that exploit "the lack of server authentication by the client". What does certificate have to name in order to be trusted by the client? Section 4.1 Upon receipt of the REQUIRETLS option on a MAIL FROM command during the receipt of a message for which the return-path is not empty (indicating a bounce message), an SMTP server MUST tag that message as needing REQUIRETLS handling. What processing should happen when REQUIRETLS is received and the return-path *is* empty? If the REQUIRETLS MAIL FROM parameter is specified, the RequireTLS header field MUST be ignored but MAY be included in onward relay of the message. How could this scenario arise? (Why is it not a user error to attempt to use both -- isn't one requiring TLS and the other disclaiming its use, making them mutually incompatible?) Section 4.2.1 2. If the server lookup is accomplished via the recipient domain's MX record (the usual case) and is not accompanied by a valid DNSSEC signature, the client MUST also validate the SMTP server name using MTA-STS as described in RFC 8461 [RFC8461] Section 4.1. What happens if this validation fails? Perhaps the below text "If any of the above fails" could include "(including MTA-STS validation)" for extra clarity. 3. Open an SMTP session with the peer SMTP server using the EHLO verb. 4. Establish a TLS-protected SMTP session with its peer SMTP server and authenticate the server's certificate as specified in [RFC6125] or [RFC7672] as applicable. "STARTTLS" does not appear in here anywhere. Separately, is this combination of steps going to preclude any setups that (e.g., via preconfiguration) go straight to TLS with no STARTTLS negotiation? What name is used as input to certificate validation (for the 6125 branch)? Is Appendix B.4 therein supposed to be normative? (The Appendix B header indicates that the content is non-normative.) Section 4.2.2 Some SMTP servers may be configured to require STARTTLS connections as a matter of policy and not accept messages in the absence of STARTTLS. A non-delivery notification MUST be returned to the sender if message relay fails due to an inability to negotiate STARTTLS when required by the server. This is an "inability to negotiate" combined with a rejection of non-STARTTLS, right? Section 5 The path from the origination of an error bounce message back to the MAIL FROM address may not share the same REQUIRETLS support as the forward path. Therefore, users requiring TLS are advised to make sure that they are capable of receiving mail using REQUIRETLS as nit: "requiring TLS for outgoing mail"? If a REQUIRETLS message is bounced, the server MUST behave as if RET=HDRS was present as described in [RFC3461]. If both RET=FULL and REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS If the MAY is not taken, will the next hop be obligated to detect that this is a bounce and apply the preceding MUSTs? If not, perhaps this also should be a MUST? bounce message uses an empty MAIL FROM return-path as required by [RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message to be discarded even if the next-hop relay does not advertise REQUIRETLS. Perhaps an internal cross-reference up to Section 4.2.1 is in order? Senders of messages requiring TLS are advised to consider the possibility that bounce messages will be lost as a result of REQUIRETLS return path failure, and that some information could be leaked if a bounce message is not able to be transmitted with REQUIRETLS. It's not really clear how actionable this is. If you have a message that you want to send, you're either going to send it or not send it. What would you change about the message based on whether or not you could get a bounce, or whether or not the bounce would leak the message contents? Section 6 Mailing lists, upon receipt of a message, originate new messages to list addresses. This is distinct from an aliasing operation that redirects the original message, in some cases to multiple recipients. I'm not entirely sure how universally acknowledged this claim is; at MIT, we have lots of "mailing lists" implemented via the central Moira management database, but the actual implementation on the mailhubs is more like the aliasing operation described in the second sentence. Is there a need to make this distinction in order to support the following points, or could they stand on their own without this? The requirement to preserve the REQUIRETLS tag therefore does not necessarily extend to mailing lists, although the inclusion of the RequireTLS header field MAY cause messages sent to mailing lists to inherit this characteristic. [...] Maybe I'm confused, but doesn't the REQUIRETLS tag and the RequireTLS header field have very different characteristics? I don't understand which one "this characteristic" is supposed to refer to. Mailing list operators MAY apply REQUIRETLS requirements in incoming messages to the resulting messages they originate. If this is done, they SHOULD also apply these requirements to administrative traffic, such as messages to moderators requesting approval of messages. Maybe note that such administrative traffic can include message contents intended for the list? Section 8.2 clear, where they can be intercepted. REQUIRETLS detects the failure of STARTTLS and declines to send the message rather than send it insecurely. nit: I'd say that REQUIRETLS requires the detection and declining, rather than doing so itself. REQUIRETLS requires successful certificate validation before sending the message. (As mentioned above, we need greater clarity about what the validation specifically entails.) REQUIRETLS requires that the recipient domain's MX record lookup be validated either using DNSSEC or via a published MTA-STS policy that specifies the acceptable SMTP server hostname(s) for the recipient domain. Are we then required to use those server hostname(s) in the certificate validation portion of the TLS connection? Section A.1 In light of https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ please consider using IPv6 examples. |
2019-02-20
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-02-20
|
07 | Ben Campbell | [Ballot comment] Thanks for this. I am balloting "yes", but I have a couple of questions. (The first would border on a DISCUSS, but I … [Ballot comment] Thanks for this. I am balloting "yes", but I have a couple of questions. (The first would border on a DISCUSS, but I suspect I am reading something wrong): - I am confused about the handling of bounce messages. §4.1 says the following: "Upon receipt of the REQUIRETLS option on a MAIL FROM command during the receipt of a message for which the return-path is not empty (indicating a bounce message), an SMTP server MUST tag that message as needing REQUIRETLS handling." ... which seems to exempt bounce messages from REQUIRETLS tagging. But §5 says: "Non-delivery ("bounce") messages usually contain important metadata about the message to which they refer, including the original message header. They therefore MUST be protected in the same manner as the original message. All non-delivery messages resulting from messages with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS error or some other, MUST also specify the REQUIRETLS SMTP option unless redacted as described below." ... which seems to require bounce messages to _not_ be exempt from tagging. What am I missing? §6: "REQUIRETLS users SHOULD be made aware of this limitation so that they use caution when sending to mailing lists and do not assume that REQUIRETLS applies to messages from the list operator to list members." Does this mean a user agent needs to know if a message destination is a list so that it can make the user aware? |
2019-02-20
|
07 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2019-02-20
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-02-20
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-02-20
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-02-19
|
07 | Adam Roach | [Ballot comment] Thanks for the work everyone did on this specification. I'm happy to see the state-of-the-art for email security continuing to move forward. I … [Ballot comment] Thanks for the work everyone did on this specification. I'm happy to see the state-of-the-art for email security continuing to move forward. I noticed one minor inconsistency in the document that you probably want to address. §2 specifies: > 1. The textual name of the extension is "Require TLS". While §7 indicates: > Textual name: RequireTLS I belive you'll want to rationalize the presence/absence of a space between these two sections. |
2019-02-19
|
07 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-02-19
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-02-19
|
07 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-02-19
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-02-19
|
07 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-02-12
|
07 | Amy Vezza | Placed on agenda for telechat - 2019-02-21 |
2019-02-12
|
07 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-02-12
|
07 | Alexey Melnikov | Ballot has been issued |
2019-02-12
|
07 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2019-02-12
|
07 | Alexey Melnikov | Created "Approve" ballot |
2019-02-12
|
07 | Alexey Melnikov | Ballot writeup was changed |
2019-02-08
|
07 | Peter Yee | Request for Last Call review by GENART Completed: Ready. Reviewer: Peter Yee. Sent review to list. |
2019-02-08
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-02-07
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-02-07
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-uta-smtp-require-tls-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-uta-smtp-require-tls-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the SMTP Service Extensions registry on the MAIL Parameters registry page located at: https://www.iana.org/assignments/mail-parameters/ a single, new keyword is to be registered as follows: EHLO Keyword: REQUIRETLS Description: REQUIRETLS parameter on MAIL Reference: [ RFC-to-be ] Note: Second, in the Enumerated Status Codes registry on the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry page located at: https://www.iana.org/assignments/smtp-enhanced-status-codes/ a single, new code will be registered as follows: Code: [ TBD-at-Registration ] Sample Text: REQUIRETLS support required Associated basic status code: 530 Description: This indicates that the message was notable to be forwarded because it was received with a REQUIRETLS requirement and none of the SMTP servers to which the message should be forwarded provide this support Reference: [ RFC-to-be ] Submitter: J. Fenton Change Controller: IESG As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, in the Permanent Message Header Field Names registry on the Message Headers registry page located at: https://www.iana.org/assignments/message-headers/ a single, new registration is to be made as follows: Header Field Name: RequireTLS Template: Protocol: mail Status: standard Reference: [ RFC-to-be ] As this also requests a registration in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-02-05
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2019-02-05
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2019-01-31
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2019-01-31
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2019-01-31
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2019-01-31
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2019-01-25
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-01-25
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-02-08): From: The IESG To: IETF-Announce CC: uta-chairs@ietf.org, valery@smyslov.net, draft-ietf-uta-smtp-require-tls@ietf.org, uta@ietf.org, Valery … The following Last Call announcement was sent out (ends 2019-02-08): From: The IESG To: IETF-Announce CC: uta-chairs@ietf.org, valery@smyslov.net, draft-ietf-uta-smtp-require-tls@ietf.org, uta@ietf.org, Valery Smyslov , alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (SMTP Require TLS Option) to Proposed Standard The IESG has received a request from the Using TLS in Applications WG (uta) to consider the following document: - 'SMTP Require TLS Option' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and message header field, RequireTLS. If the REQUIRETLS option or RequireTLS message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed, or by requesting that recipient-side policy mechanisms such as MTA-STS and DANE be ignored when relaying a message for which security is unimportant. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-01-25
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-01-25
|
07 | Alexey Melnikov | Last call was requested |
2019-01-25
|
07 | Alexey Melnikov | Last call announcement was generated |
2019-01-25
|
07 | Alexey Melnikov | Ballot approval text was generated |
2019-01-25
|
07 | Alexey Melnikov | Ballot writeup was generated |
2019-01-25
|
07 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-01-22
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-22
|
07 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-07.txt |
2019-01-22
|
07 | (System) | New version approved |
2019-01-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2019-01-22
|
07 | Jim Fenton | Uploaded new revision |
2019-01-09
|
06 | Alexey Melnikov | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-12-06
|
06 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2018-12-05
|
06 | Valery Smyslov | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard as indicated on the title page header and in the datatracker. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and message header field, RequireTLS. If the REQUIRETLS option or RequireTLS message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed, or by requesting that recipient-side policy mechanisms such as MTA-STS and DANE be ignored when relaying a message for which security is unimportant. Working Group Summary The WG consensus for adoption this draft was clear. The draft was well discussed in the WG and has undergone significant changes during this discussion. At some point there was a strong consideration to split the draft into two, separating SMTP service extension and mail header field, but the final consensus was that it's better to define them in a single document. Document Quality There are at least two implementations of the early version of the draft. A few major vendors and operators express an interest in this technology and have indicated that they evaluate a possibility to implement (or use) it. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Valery Smyslov (shepherd) Alexey Melnikov (AD) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document and found it ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The document was a subject of several reviews by experienced WG members. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been filed that reference this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits were found by idnits tool. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None are applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). A new item "RequireTLS" is added to the "SMTP Service Extensions" registry. Another new item "RequireTLS" is added to the "Permanent Message Header Field Names" registry. In addition a new status code is defined in the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes" registry. The requirements for all three registries are fulfilled. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries are defined. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No automated checks are applicable. |
2018-12-05
|
06 | Valery Smyslov | Responsible AD changed to Alexey Melnikov |
2018-12-05
|
06 | Valery Smyslov | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-12-05
|
06 | Valery Smyslov | IESG state changed to Publication Requested |
2018-12-05
|
06 | Valery Smyslov | IESG process started in state Publication Requested |
2018-12-05
|
06 | Valery Smyslov | Changed consensus to Yes from Unknown |
2018-12-05
|
06 | Valery Smyslov | Intended Status changed to Proposed Standard from None |
2018-12-05
|
06 | Valery Smyslov | Changed document writeup |
2018-12-04
|
06 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-06.txt |
2018-12-04
|
06 | (System) | New version approved |
2018-12-04
|
06 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2018-12-04
|
06 | Jim Fenton | Uploaded new revision |
2018-11-21
|
05 | Valery Smyslov | Tag Revised I-D Needed - Issue raised by WG cleared. |
2018-11-20
|
05 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-05.txt |
2018-11-20
|
05 | (System) | New version approved |
2018-11-20
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2018-11-20
|
05 | Jim Fenton | Uploaded new revision |
2018-11-05
|
04 | Valery Smyslov | Tag Revised I-D Needed - Issue raised by WG set. |
2018-11-05
|
04 | Valery Smyslov | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-09-26
|
04 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-04.txt |
2018-09-26
|
04 | (System) | New version approved |
2018-09-26
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2018-09-26
|
04 | Jim Fenton | Uploaded new revision |
2018-08-27
|
03 | Valery Smyslov | Notification list changed to Valery Smyslov <valery@smyslov.net> |
2018-08-27
|
03 | Valery Smyslov | Document shepherd changed to Valery Smyslov |
2018-07-20
|
03 | Valery Smyslov | IETF WG state changed to In WG Last Call from WG Document |
2018-06-22
|
03 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-03.txt |
2018-06-22
|
03 | (System) | New version approved |
2018-06-22
|
03 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2018-06-22
|
03 | Jim Fenton | Uploaded new revision |
2018-04-06
|
02 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-02.txt |
2018-04-06
|
02 | (System) | New version approved |
2018-04-06
|
02 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2018-04-06
|
02 | Jim Fenton | Uploaded new revision |
2018-03-20
|
01 | Valery Smyslov | Added to session: IETF-101: uta Thu-1810 |
2018-01-16
|
01 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-01.txt |
2018-01-16
|
01 | (System) | New version approved |
2018-01-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jim Fenton |
2018-01-16
|
01 | Jim Fenton | Uploaded new revision |
2017-09-05
|
00 | Leif Johansson | This document now replaces draft-fenton-smtp-require-tls instead of None |
2017-09-05
|
00 | Jim Fenton | New version available: draft-ietf-uta-smtp-require-tls-00.txt |
2017-09-05
|
00 | (System) | WG -00 approved |
2017-08-07
|
00 | Jim Fenton | Set submitter to "Jim Fenton ", replaces to draft-fenton-smtp-require-tls and sent approval email to group chairs: uta-chairs@ietf.org |
2017-08-07
|
00 | Jim Fenton | Uploaded new revision |