Subject: [Uta] RequireTLS: Revised text on message origination

From: Jim Fenton <[email-masked]>
Date: Fri, 12 Apr 2019 12:44:04 -0700

One of the significant discussions at the Prague meeting (and originally
resulting from IESG comments) was that the Section 6, "Mailing list
considerations" was incomplete because it didn't consider other causes
of origination such as Sieve and vacation programs. So I have drafted an
alternative Section 6, below. Please review and comment. (Thanks Barry
L. for reviewing first draft).

6. Reorigination considerations

In a number of situations, an agent for the addressee of a message
originates a new message as a result of an incoming message. These
situations include, but are not limited to, mailing lists (including
administrative traffic such as message approval requests), Sieve [RFC
5228], "vacation" responders, and other filters to which incoming
messages may be piped. These newly originated messages may essentially
be copies of the incoming message, such as with a forwarding service
or a mailing list expander.  In other cases, such as with a vacation
message or a delivery notification, they will be different but might
contain parts of the original message or other information for which
the original message sender wants to influence the requirement to use
TLS transmission.

Agents that reoriginate messages should apply REQUIRETLS requirements
in incoming messages (both requiring TLS transmission and requesting
that TLS not be required) to the reoriginated messages to the extent
feasible.  A limitation to this might be that for a message requiring
TLS, redistribution to multiple addresses while retaining the TLS
requirement could result in the message not being delivered to some of
the intended recipients.

User-side reorigination (such as use of Sieve rules on a user agent)
typically does not have access to the SMTP details, and therefore may
not be aware of the REQUIRETLS requirement on a delivered message.
Operators of user-side agents that expect sensitive traffic should
consider this possibility, and if operationally feasible (when
forwarding to a specific, known address; when appropriate
configuration options are available) should apply REQUIRETLS whenever
feasible to messages that do not contain the "TLS-Required: No" header
field.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 15 Apr 2019 23:06:46 +0200

Hi, Jim,

On 12-04-19 21:44, Jim Fenton wrote:
>
> One of the significant discussions at the Prague meeting (and 
> originally resulting from IESG comments) was that the Section 6, 
> "Mailing list considerations" was incomplete because it didn't 
> consider other causes of origination such as Sieve and vacation 
> programs. So I have drafted an alternative Section 6, below. Please 
> review and comment. (Thanks Barry L. for reviewing first draft).
>
> or a mailing list expander.

I wonder whether it's not better to refer to c.q. use the terminology as 
defined by RFC5598. Something like:

In a number of situations, a mediator originates a new message as a result of an incoming message. See [RFC5598] chapter 5 for a non-exhaustive list of examples of mediators. These newly originated messages may essentially
be copies of the incoming message.

> In other cases, such as with a vacation

I think this section clearly shows the limited guarantees that 
REQUIRETLS can provide. It may give the sender a false sense of 
safety/security. How is an implementor supposed to implement this spec 
conveying all nuances of the rich e-mail eco-system to the user? How can 
we expect an average user to understand the warning that's in the 
Security Considerations section? Suppose a MUA implementor implements 
this spec by giving the user a nice button labelled 'when recipient does 
not support encryption, return the message and do not deliver' (this 
won't fit on a button anyway ;-)). The user may find this meets his/her 
privacy requirements, presses this REQUIRETLS button and sends the mail. 
There are plenty of scenarios where the expectation of the end user is 
not met:

  * the recipients mail system returns an out-of-office message,
    including the decrypted contents of the message;
  * some intermediate MTA sends a forensic DMARC report including the
    decrypted contents of the message;
  * anywhere along the chain of MTA's someone eavesdrop on the message;
  * a mailing list, which in the remainder of your text for chapter 6,
    does not apply REQUIRETLS to the messages it distributes;
  * et cetera

> that TLS not be required)

This is rather confusing. I assume you mean:

... incoming messages (requiring TLS transmission) and requesting that 
TLS not be required to the reoriginated messages ...?

>   to the reoriginated messages to the extent
> configuration options are available) should

SHOULD instead of should?

> apply REQUIRETLS whenever

Operators of these user-side agents are often the end users themselves. 
I don't think anyone can expect from the average user that constructs a 
sieve filter (e.g. using a form in a webmail client) that he/she will 
honor the REQUIRETLS settings of the original message (the more because 
they won't have this REQUIRETLS information available, as you describe).

Apart from this, I find this sentence difficult to read, maybe you'd 
better split up this sentence in shorter parts?

/rolf

---

From: Jim Fenton <[email-masked]>
Date: Wed, 17 Apr 2019 12:08:12 -0700

Hi Rolf,

On 4/15/19 2:06 PM, Rolf E. Sonneveld wrote:
> I wonder whether it's not better to refer to c.q. use the terminology
> as defined by RFC5598. Something like:
>

I like "mediator" and the reference to RFC 5598 rather than "agent". I
think I'd like to keep the examples rather than refer everyone to 5598
to see what is meant by a mediator.

[aside: RFC 5598 doesn't seem to have up-to-date information about
mailing list mediators. Specifically, it says that they leave the From
address alone, which is frequently not the case with "DMARC-friendly"
mailing lists.]

> conveying all nuances of the rich e-mail eco-system to the user? How
> can we expect an average user to understand the warning that's in the
> this spec by giving the user a nice button labelled 'when recipient
> does not support encryption, return the message and do not deliver'
> (this won't fit on a button anyway ;-)). The user may find this meets
> his/her privacy requirements, presses this REQUIRETLS button and sends
> the mail. There are plenty of scenarios where the expectation of the
> end user is not met:
>

Most implementations of REQUIRETLS are relay MTAs that have no
connection with the user at all. An MUA that provides a nice button
should tell the user clearly what that means and not oversell the
capability. I'm not a UX designer but I have seen ways to give more
information on a feature when it is first used or until the user clicks
a "don't show me this any more" thing.

But, of the users that even know that email is only sometimes encrypted
in transit, how many know that any verification of the certificate is
probably ignored? That middleboxes can interfere with TLS negotiation to
cause messages to be sent in the clear so that they can be intercepted?
Yes, REQUIRETLS doesn't address every situation, but it greatly limits
the scope of this problem. The intent of this section is to inform
implementors of the limitations so that they can educate their users and
not oversell it.

> TLS not be required to the reoriginated messages ...?

Not quite. I'm saying that agents (now mediators) should reoriginate
messages with the same REQUIRETLS characteristics -- both applying the
REQUIRETLS SMTP option if it was on the incoming message, and the use of
the TLS-Required header field if the originator's intent is to not
require the use of TLS for the message.

> SHOULD instead of should?

It's an action by the operator, not the protocol, so the non-normative
"should" was used.

> Operators of these user-side agents are often the end users
> themselves. I don't think anyone can expect from the average user that
> constructs a sieve filter (e.g. using a form in a webmail client) that
> he/she will honor the REQUIRETLS settings of the original message (the
> more because they won't have this REQUIRETLS information available, as
> you describe).
>

I'll try to break it up into more manageable pieces, yes.

Thanks for your review.

-Jim