SMTP Require TLS Option
draft-ietf-uta-smtp-require-tls-09

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

Comment (2019-08-02)
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 i_like_to_slather_myself_in_peanutbutter@unusualhobbies.org I might feel differently).

Mirja Kühlewind No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection