Skip to main content

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

Discuss


Yes

(Alexey Melnikov)

No Objection

(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)

Note: This ballot was opened for revision 07 and is now closed.

Warren Kumari
No Objection
Comment (2019-03-14 for -07) Not sent
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).
Eric Rescorla Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2019-02-21 for -07) Sent
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.
Adam Roach Former IESG member
Yes
Yes (2019-02-19 for -07) Sent
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.
Alexey Melnikov Former IESG member
Yes
Yes (for -07) Unknown

                            
Ben Campbell Former IESG member
Yes
Yes (2019-02-20 for -07) Sent
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?
Alissa Cooper Former IESG member
No Objection
No Objection (2019-02-21 for -07) Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-08-02) Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Not sent

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -07) Not sent