Ballot deferred by Alexey Melnikov on 2019-02-21.
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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.
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.
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.
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"
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?
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.
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.
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 email@example.com I might feel differently).