SMTP Require TLS Option
Note: This ballot was opened for revision 07 and is now closed.
(Eric Rescorla) Discuss
Discuss (2019-02-21 for -07)
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.
Comment (2019-02-21 for -07)
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"
(Ben Campbell) Yes
Comment (2019-02-20 for -07)
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?
(Alexey Melnikov) Yes
(Adam Roach) Yes
Comment (2019-02-19 for -07)
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.
(Ignas Bagdonas) No Objection
Deborah Brungard No Objection
Alissa Cooper No Objection
Comment (2019-02-21 for -07)
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.
(Spencer Dawkins) No Objection
Benjamin Kaduk (was Discuss) No Objection
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 it only applies to the RFC 6125 procedures and not the RFC 7672 ones.
(Suresh Krishnan) No Objection
Warren Kumari No Objection
Comment (2019-03-14 for -07)
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 firstname.lastname@example.org I might feel differently).