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

["Rolf E. Sonneveld" <[e-mail]>]

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).
>
> 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.

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
> 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.

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


>
> Agents that reoriginate messages should apply REQUIRETLS requirements
> in incoming messages (both requiring TLS transmission and requesting
> 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
> 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

SHOULD instead of should?

> apply REQUIRETLS whenever
> feasible to messages that do not contain the "TLS-Required: No" header
> field.

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