Subject: [Uta] REQUIRETLS vs. headers

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Nov 2017 18:49:33 -0500

1. I agree that REQUIRETLS=NO needs a header so it can be
   tunnelled via an "agnostic" MTA.

2. However, even REQUIRETLS=YES needs a header, because:

   a. Within an MTA a message may make multiple internal
      hops, for example processing via a loopback SMTP
      proxy that does virus scanning, or forwarding via
      a spam-scanning appliance that is statically configured
      to always do TLS both upstream and downstream, but does
      not support REQUIRETLS=YES explicitly.

   b. Messages may get filtered via procmail and the like
      and then forwarded, and again the delivery channel
      has no means to preserve REQUIRETLS=YES except via a
      header.

3. Therefore, REQUIRETLS will need a header for both YES and
   NO, but the YES case will also want to see a "REQUIRETLS"
   in the EHLO response of a remote MTA, so it can commit to
   honouring the extension.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 17 Nov 2017 01:02:30 -0800

>       has no means to preserve REQUIRETLS=YES except via a

Let me think about the procmail->forward case a bit. Is that considered
forwarding of the same message or origination of a new one (same
question for mailing lists)?

We could define a header field that is consulted when a message is
originated (transitions from something else to SMTP) to set the
REQUIRETLS option for that first hop. I would want it to be clear that
for all other hops, the REQUIRETLS option on MAIL FROM is what gets used.
>    in the EHLO response of a remote MTA, so it can commit to
Having the NO option only be a header field simplifies things. It was
making a mess of negotiation of the REQUIRETLS SMTP extension having
REQUIRETLS=NO not actually require REQUIRETLS to be negotiated. But I
still see these as two separate features, REQUIRETLS and
IgnoreTLSPolicy. I can picture that there would be implementations of
IgnoreTLSPolicy that might not include REQUIRETLS and vice versa. That's
why I see them as separate documents.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Nov 2017 04:40:14 -0500

> On Nov 17, 2017, at 4:02 AM, Jim Fenton <[email-masked]> wrote:
> 

Typical (or at least common) use of procmail and similar tools is
forwarding some or all mail to another system where the user will
actually access the email, so if TLS is be used at each hop from
sender's MUA to the intended recipient's mailbox, it needs to be
enable to tunnel through the occasional non-SMTP hop, or a secure
SMTP hop that does not (explicitly) support REQUIRETLS.

For example, at my place of work we have SMTP spam-filtering
appliances that receive all mail over TLS, scan it, and re-inject
non-spam back into the mailstream via authenticated TLS.  However,
they don't support REQUIRETLS, so the ESMTP signal will be lost
in transit through these devices.  However a header will make
it through, and the mail can then continue on its way with TLS
enforced again downstream.

> for all other hops, the REQUIRETLS option on MAIL FROM is what gets used.

Yes, the ESMTP handshake will be required on all SMTP hops, except
for any where local configuration statically asserts that the nexthop
preserves REQUIRETLS passively (via the header as above, because
once email leaves the REQUIRETLS-agnostic handler, it re-enters
the mail stream in a way that revives REQUIRETLS from the header).

This may mean that mailing list software will need to strip
REQUIRETLS, this can be done by stripping the header at the
MTA before giving it to the list manager.

Users resending unencapsulated messages (mutt's "bounce" feature,
or Mail.app's "Redirect") may (bug or feature?) then also trigger
REQUIRETLS when the message is resent.  One way to deal with that
is to look at "Resent-Require-TLS:" rather than "Require-TLS:"
when a message has "Resent-From:" or "Resent-To:" headers.

One might similarly look for "List-Require-TLS:" when a message
has "List-*" headers.  So this requires a bit more care.

> REQUIRETLS=NO not actually require REQUIRETLS to be negotiated.

Naturally.

> But I still see these as two separate features, REQUIRETLS and

The possibility of partial support does not make a strong case for
separate specification, folks have implemented parts of specifications
before.  The overlaps of the designs, is more compelling.

Furthermore, the "NO" case will be by far the more frequently used
feature.  If we want STS and DANE to not be crippled by service
providers with downgrade resistant enforcement on by default, we
need to give users an opt-out mechanism.  There'll be enough
operational errors to require occasional work-arounds by senders.

-- 
	Viktor.