Subject: [Uta] Last Call: <draft-ietf-uta-smtp-require-tls-07.txt> (SMTP Require TLS Option) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 25 Jan 2019 07:00:36 -0800

The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP Require TLS Option'
  <draft-ietf-uta-smtp-require-tls-07.txt> 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
[email-masked] mailing lists by 2019-02-08. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 25 Jan 2019 22:58:25 +0100

Hi,

> https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/ballot/

I just quickly reviewed this document. I notice that this extension also 
applies to LMTP. Now, I wonder what should happen when Sieve [RFC 5228] 
is involved there, particularly when actions like "redirect", "reject", 
"vacation" [RFC 5230] and "notify" [RFC 5435] [RFC 5436] are involved. 
Do the security requirements get forwarded though Sieve for the outgoing 
SMTP messages? What happens when "notify" sends a notification using a 
protocol other than SMTP (e.g. XMPP [RFC 5437])?

Also, Sieve has a couple of extensions called "envelope-dsn" and 
"redirect-dsn" [RFC 6009] that would be affected by these changes. First 
of all, I'd assume the "RET" field will get an additional value 
possibility. But, are there also semantic changes?

Regards,

Stephan.

---

From: Russ Housley <[email-masked]>
Date: Sat, 26 Jan 2019 10:27:59 -0500

I have no problem with the protocol itself, but I do not understand how this specification can not have a reference to TLS.

Russ

> On Jan 25, 2019, at 10:00 AM, The IESG <[email-masked]> wrote:
> 
>

---

From: Jim Fenton <[email-masked]>
Date: Sat, 26 Jan 2019 21:13:52 -0800

Thanks for the review, Stephan.

On 1/25/19 1:58 PM, Stephan Bosch wrote:
>
> I just quickly reviewed this document. I notice that this extension
> also applies to LMTP. Now, I wonder what should happen when Sieve [RFC
> 5228] is involved there, particularly when actions like "redirect",
> "reject", "vacation" [RFC 5230] and "notify" [RFC 5435] [RFC 5436] are
> involved. Do the security requirements get forwarded though Sieve for
> the outgoing SMTP messages? What happens when "notify" sends a
> notification using a protocol other than SMTP (e.g. XMPP [RFC 5437])?
>
> "redirect-dsn" [RFC 6009] that would be affected by these changes.
> First of all, I'd assume the "RET" field will get an additional value
The draft discusses situations where intermediaries (relays) might
generate bounce messages and the like, but doesn't deal with what are
effectively reply messages back to the originator of the message.
Hopefully the originator knows that a reply might be generated by the
recipient, by the sieve mechanisms you describe but also by things like
the vacation autoresponder, tools built into products like Exchange, and
for that matter, manual replies by the recipient of the message. These
are separate messages, and I was hoping that was understood. But we
could add a comment recommending the use of MTA-STS or DANE policies to
try to make sure that replies are covered as well, if not.

I'm afraid I don't understand the relationship of all this with LMTP.
Can you clarify?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sat, 26 Jan 2019 21:18:07 -0800

Hi Russ,

> I have no problem with the protocol itself, but I do not understand how this specification can not have a reference to TLS.

It does have at least a couple of indirect references to TLS, through
STARTTLS (RFC 3207) and BCP 195. An informative reference to TLS could
be added, but I'm not sure it adds much -- this is operating at a level
of abstraction above that.

-Jim

---

From: Stephan Bosch <[email-masked]>
Date: Sun, 27 Jan 2019 11:32:13 +0100

> try to make sure that replies are covered as well, if not.

Note that replies aren't the only thing Sieve can do. The mentioned 
"redirect" action is forwarding the same message to a different 
recipient, much like an MTA can do directly. Rules in this RFC state 
that REQUIRETLS must be forwarded to the next hop in that case, so does 
that apply to Sieve as well? The notify action creates a notification 
message based on the incoming message and sends it elsewhere, which also 
is not a reply (and can be something other than email). What happens there?

> I'm afraid I don't understand the relationship of all this with LMTP.

There isn't much of a relationship. LMTP is where Sieve is usually 
executed (can also be used at MTA level). The fact that REQUIRETLS gets 
propagated all the way to LMTP means that such Sieve interpreters can be 
made to do something with that parameter. I'd imagine that at least the 
"redirect" action would have the same requirements as an MTA forwarding 
the message directly (without first passing through LMTP and Sieve).

All this is of course up for discussion and that is why I bring this up. 
You do discuss mailing lists, but statements about Sieve (or similar 
mail filtering for that matter) are omitted.

Regards,

Stephan.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 27 Jan 2019 19:25:23 -0800

On 1/27/19 2:32 AM, Stephan Bosch wrote:
> that REQUIRETLS must be forwarded to the next hop in that case, so 
> does that apply to Sieve as well? The notify action creates a 
> notification message based on the incoming message and sends it 
> elsewhere, which also is not a reply (and can be something other than 
> email). What happens there?

Nothing particularly happens; once the message has reached its 
destination, any number of things can happen to it. Some of these are 
automatic like Sieve (and yes, it can forward the message elsewhere, 
even via a different medium, and not just reply to the sender) and some 
are manual (the recipient takes some action, not necessarily via email, 
as a result of receiving the message). The anticipated use case for this 
is one where the sender is sending a message to a recipient that will 
treat it with some sensitivity. For example, a reporter in a foreign 
jurisdiction that is sending something to their editor. We would expect 
that editor not to do something that compromises such reports.

If you think more discussion of this, that can be added (with the 
concurrence of the WG, of course).

> executed (can also be used at MTA level). The fact that REQUIRETLS 
> gets propagated all the way to LMTP means that such Sieve interpreters 
> can be made to do something with that parameter. I'd imagine that at 
> least the "redirect" action would have the same requirements as an MTA 
> forwarding the message directly (without first passing through LMTP 
> and Sieve).
Thank you.
>
> All this is of course up for discussion and that is why I bring this 
> up. You do discuss mailing lists, but statements about Sieve (or 
> similar mail filtering for that matter) are omitted.

I agree that the discussion of mailing lists but not other mechanisms 
like Sieve is perhaps incomplete by being too specific. Perhaps a more 
general discussion of what can happen at the recipient address is needed.

-Jim