Subject: [Uta] RequireTLS: NO

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Mar 2018 18:59:59 +0000

https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is
relevant.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Mar 2018 15:17:18 -0400

> On Mar 22, 2018, at 2:59 PM, Martin Thomson <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is relevant. 

A reasonable guiding principle, but sometimes *availability* trumps security.
This is sufficiently often the case with email to make explicit preference for
delivery above all other concerns a necessary feature.

When a user gets a delay warning for their initial attempt to send a time-sensitive
message, it should be possible to resend the message with an explicit opt-out of
enhanced security protections (beyond unauthenticated opportunistic STARTTLS).

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 22 Mar 2018 19:59:01 +0000

> enhanced security protections (beyond unauthenticated opportunistic STARTTLS).

can't they opt-out by re-sending to their submission agent without the
REQUIRETLS SMTP command?  or is the fear that their submission agent
will invoke REQUIRETLS on the next hop without the user's permission?

fwiw, i think troubleshooting alone might be sufficient reason to
document the "RequireTLS: NO" message header, but i'm pretty unclear on
any sane UI/UX story for how a troubleshooter manages to introduce it --
it's pretty much expert feature territory (e.g. those of us who edit our
message headers by hand).

     --dkg

---

From: Jim Fenton <[email-masked]>
Date: Thu, 22 Mar 2018 16:43:21 -0700

> will invoke REQUIRETLS on the next hop without the user's permission?

REQUIRETLS is intended only to be asserted by the originator of the
message. I don't expect a subsequent hop to be asserting either the SMTP
option or the header field (although maybe I should make that
expectation explicit in the spec). Also note that the header field
("no") and the SMTP option ("yes") are mutually exclusive, because they
give conflicting instructions to the mail system.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Mar 2018 19:49:25 -0400

> On Mar 22, 2018, at 3:59 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

No, the user is opting out of a TLS security policy he did not request,
one published by the receiving domain via DANE or STS.  Clearly if you
don't want secure delivery, don't ask for it.

> message headers by hand).

When this becomes an RFC MUAs could add the feature.  Also MTAs running
milters or similar content processing could implement a content
transformation from:

	Subject: [insecure-delivery]: actual subject

to (easy with e.g. Postfix header_checks):

	Require-TLS: NO
	Subject: [insecure-delivery]: actual subject

or (not easy with header_checks, but hides the subject tag):

	Require-TLS: NO
	Subject: actual subject

-- 
	Viktor.

---

From: [email-masked]
Date: Thu, 22 Mar 2018 17:18:54 -0700 (PDT)

> REQUIRETLS SMTP command?

You're assuming that the only TLS-related failure case that could occur
is when REQUIRETLS is used. I can assure this is not the case. TLS failures
occur all the time, and as things stand we deal with them by falling back
to no-TLS transfer. In such cases we cannot tell whether it's an attacker
or a received-side problem.

MTA-STS changes this: It provides a way for receivers to state that they
want TLS used and senders should assume a problem is caused by an attacker.

The problem is they are still going to be screwups - in fact they are likely to
increase in number - and this combined with MTA-STS is going to be an issue.

>  or is the fear that their submission agent

The REQUIRETLS SMTP extension isn't even on my radar. My only interest in this
draft is that it provides a way for senders to say "screw privacy, I want my
message delivered".

> message headers by hand).

I would hope it's obvious that you don't present in a UI as having anything to
do with TLS, security layers, and other technical matters. A presentation along
the lines of "favor delivery over privacy" would seem to make at least some
sense.

				Ned

---

From: [email-masked]
Date: Thu, 22 Mar 2018 17:40:41 -0700 (PDT)

> 	Subject: actual subject

Also trivial to do with Sieve.

				Ned

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 23 Mar 2018 08:19:19 +0000

> or (not easy with header_checks, but hides the subject tag):

I think leaving [insecure-delivery] in the subject is a feature of
such a configuration, not a bug.  It conveys important information
about the delivery of the message.

Of course, someone could add the [insecure-delivery] to the
subject using an MTA that doesn't add Require-TLS, potentially
fooling someone, but I don't offhand see any serious security
consequences of being able to falsely claim your message
was delivered insecurely, when it wasn't.

-Tim

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 23 Mar 2018 09:26:25 +0000

> was delivered insecurely, when it wasn't.

If the message is DKIM signed at the origin, then tampering with the Subject
header field will be verboten under most signing practices which include the
Subject header.

--Kurt

---

From: Stan Kalisch <[email-masked]>
Date: Fri, 23 Mar 2018 09:25:04 -0400

Hi,

> On Mar 23, 2018, at 4:19 AM, Tim Hollebeek <[email-masked]> wrote:
> 

One can argue that can result in what is, in principle, a socially-engineered DoS.  (Call it something else if you'd like, but it isn't good.)

Thanks,
Stan

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 23 Mar 2018 10:05:27 -0400

> On Mar 23, 2018, at 5:26 AM, Kurt Andersen (b) <[email-masked]> wrote:
> 

Typically, both DKIM signing, and any automatic processing of subject tags
would happen (exclusively) in the origin MSA.  So that is not a problem.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 26 Mar 2018 10:15:39 -0700

> about the delivery of the message.

RequireTLS: NO only overrides policy mechanisms (DANE, MTA-STS) that may
be present. It does not cause delivery of the message to be insecure.
TLS may be negotiated with RequireTLS: NO, it just isn't required. It
just causes TLS to be negotiated very much like it is today (in the
absence of DANE and MTA-STS).

Header field munging is an ugly business, and (as an individual) I am
opposed to it, especially since this doesn't seem to be a very
compelling usage. As document editor, I haven't heard WG consensus to
include that in the REQUIRETLS draft, so I won't be adding that. Of
course, some operators might munge the Subject header field anyway, as
they do for other things.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 26 Mar 2018 13:31:44 -0400

> On Mar 26, 2018, at 1:15 PM, Jim Fenton <[email-masked]> wrote:
> 

Indeed I am not suggesting any standard for munging headers.  This would
be a site-local issue, to allow users to set "Require-TLS: NO" when using
an MUA that does not (yet?) support the proposed mechanism.

-- 
	Viktor.