Subject: [Uta] REQUIRETLS update

From: Jim Fenton <[email-masked]>
Date: Tue, 6 Dec 2016 16:30:32 -0800

It has been a little while, so I thought it might be appropriate to give
the WG an update on the status of REQUIRETLS
(draft-fenton-smtp-require-tls-02).

There are now two prototype implementations:

- Exim implementation by Jeremy Harris (announced on UTA list on 2
September)

- MDaemon implementation by Arvel Hathcock

(I'm not counting John Levine's implementation he described in Buenos
Aires, because he seems to have missed quite a few MUSTs in the
specification.)

At this point, Jeremy and I are running test MTAs with the Exim
implementation and Arvel is running one with the MDaemon implementation.
A little interoperability testing has taken place.

What we have learned so far:

- Some ambiguity about when the REQUIRETLS extension should be
advertised. The draft had assumed that it would be advertised on any
EHLO response, even before STARTTLS had occurred. Jeremy points out that
the advertised extensions mean that the server is prepared to support
those facilities while in its current state, and STARTTLS needs to be
done in order to support REQUIRETLS. On the other hand, I thought it
useful to advertise REQUIRETLS all the time, since it allows a sending
MTA to determine whether it's supported before going to the trouble of
setting up TLS.

- Loss of DSNs if the sending MTA has a problem with its (incoming) TLS
certificate (or a self-signed cert), since the DSN is also sent with
REQUIRETLS. These DSNs currently get stuck in the system until they time
out. One approach (trying not to spill much metadata) might be to send
the non-delivery notice only to the postmaster, and include very little
information about the message -- perhaps just a message-id (which I
would hope to be opaque, but probably often isn't in practice).

- Lack of clarity on what the must-implement pieces of the spec are. I
expect that many implementations that don't currently do anything with
DANE (or potentially DNSSEC) might have quite a hurdle implementing the
DANE piece of REQUIRETLS, but still be interested in implementing CHAIN.
I'm in favor of making DANE a should-implement, but not a
must-implement. Others have suggested removing the certificate
verification option from the spec entirely, but I haven't seen much
consensus to do that.

I'm expecting to update the spec early next year to address these issues
and a few that were on the list earlier.

If anyone else has an implementation or is interested in running another
instance of the other ones, please let me know and we can trade
information on our test MTAs.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Dec 2016 02:19:07 +0000

> (draft-fenton-smtp-require-tls-02).

Is there any new thinking on supporting user signalling of TLS
opt-out?  (Urgent, but non-sensitive message needs to get through
despite DANE or STS policy that might otherwise hinder delivery
when some operational snafu breaks the promised security features).

I rather see opt-out as much more realistically useful than the
converse covered by REQUIRETLS.  And I do still strongly believe
that the same spec should cover both halves of this problem.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 7 Dec 2016 09:33:54 +0000

> that the same spec should cover both halves of this problem.

I disagree.  If that is a need, it should be a separate specification.
Otherwise we bikeshed REQUIRETLS to death.
-- 
Cheers,
  Jeremy

---

From: Tony Finch <[email-masked]>
Date: Wed, 7 Dec 2016 12:37:08 +0000

Jim Fenton <[email-masked]> wrote:
> EHLO response, even before STARTTLS had occurred.

Doesn't that open up a denial of service vulnerability, where an attacker
can make a client incorrectly think a server requires TLS.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: South or southwest 5 to 7, occasionally gale 8 at first. Very rough,
becoming rough. Fog patches. Moderate or good, occasionally very poor.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 7 Dec 2016 14:35:25 +0100 (CET)

> can make a client incorrectly think a server requires TLS.

Please note that REQUIRETLS is something that the client requests from the SMTP server, not vice versa.

/rolf

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Dec 2016 11:46:06 -0500

> On Dec 7, 2016, at 4:33 AM, Jeremy Harris <[email-masked]> wrote:
> 
> 

I don't see how extending the specification to cover both of the
complementary behaviours brings "bikeshedding" into the picture.

All that happens is that instead the submission phase options
extend from binary (default behaviour, or require TLS) to ternary,
(default behaviour, require TLS, or permit insecure), where the
last option delivers in the clear and/or without authentication,
when authenticated TLS would otherwise be indicated by DANE or
similar policy.

The receiving MTA would advertise a single ESMTP capability
(let's say "USETLS" rather than "REQUIRETLS") to support
both non-default behaviours.  The client would then send
either:

	MAIL FROM:<sender> USETLS=[MAY|MUST]

where "MUST" is the current "REQUIRETLS" proposal, and
"MAY" is the converse that makes TLS optional even in
the face of contrary security policy.

Administrators can disable either or both options, if
contrary to site policy, in which case the client's
message must be refused at either the "MAIL TO",
"RCPT FROM" or "DATA" commands with a suitable new
DSN status code.

Adding a second, essentially identical ESMTP capability
(flip side of per-message TLS policy), and writing a mostly
identical converse draft seems silly.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 7 Dec 2016 11:28:15 -0800

> that the same spec should cover both halves of this problem.
I haven't thought about this suggestion much further; I haven't heard
any further support for it.

As for usefulness, I tend to think of a (potentially) multi-hop
store-and-forward protocol like SMTP as being the wrong way to send an
urgent message in the first place. There are lots of operational snafus
that might break email entirely in such a way that this downgrade won't
recover from, so if someone has an urgent need to communicate, they need
to have an independent way to do it.

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Dec 2016 14:47:05 -0500

> On Dec 7, 2016, at 2:28 PM, Jim Fenton <[email-masked]> wrote:
> 

Users will disagree.  Email *is* used to send plenty of messages that
are moderately time-sensitive, and where the sender has no other means
to reach the other party.  Often the user has no particular desire for
confidentiality (does not mind "postcard" service) and would very much
rather have the message delivered sans TLS security than bounced.

Indeed the above use case is undoubtedly far more prevalent than the
occasional privacy-minded user who will only send when TLS is assured
at every hop.

We can attempt to pretend the use-case does not exist, but that'd be
disingenuous and would ignore real needs.

-- 
-- 
	Viktor.

---

From: Arvel Hathcock <[email-masked]>
Date: Fri, 9 Dec 2016 16:40:35 -0600

> Otherwise we bikeshed REQUIRETLS to death.

+1.  I'm for keeping this proposal as simple as possible.

Arvel

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 9 Dec 2016 18:39:01 -0500

> On Dec 9, 2016, at 5:40 PM, Arvel Hathcock <[email-masked]> wrote:
> 

The result would be substantial lack of orthogonality, with multiple
overlapping specifications, that would then be able to conflict with
each other.

What would (for example) be the result if a client requested both
the REQUIRETLS and a separate MAYTLS feature?

Adding the converse feature does not noticeably complicate this
draft, it merely makes it feature complete, and would provide
the feature that more users would actually want more of the
time.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2016 16:13:08 -0000

>the REQUIRETLS and a separate MAYTLS feature?

Given that mail servers will do whatever they wany with REQUIRETLS
suggestions, I wouldn't obsess about this.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Dec 2016 06:38:12 +0000

> suggestions, I wouldn't obsess about this.

I'm trying, without much success it seems, to explain why REQUIRETLS is
an incomplete take on the requirements for per-message TLS policy, and
why fragmenting the solution over multiple specificaitons would be a bad
idea.

I am not too worried about what MTAs will or won't do with per-message
REQUIRETLS, just pointing out non-orthogonal features which hint at the
need for a single spec.  I rather expect that the "require" side of the
per-message policy will see exceedingly little use.

-- 
	Viktor.

---

From: [email-masked]
Date: Sat, 10 Dec 2016 01:45:11 -0800 (PST)

> the feature that more users would actually want more of the

I'm in complete agreement with Viktor here. This is a case of complification
masquerading as simplicity.

				Ned

---

From: [email-masked]
Date: Sat, 10 Dec 2016 01:55:02 -0800 (PST)

> per-message policy will see exceedingly little use.

Yep. To the point where I cannot possibly justify implementing this proposal
unless it also includes the MAY option, which looks to me to be far more
useful.

				Ned

---

From: Jim Fenton <[email-masked]>
Date: Fri, 16 Dec 2016 14:53:13 -0800

> unless it also includes the MAY option, which looks to me to be far more

It seems that Viktor and I have differing views on the usefulness of
MAYTLS and REQUIRETLS. That said, I agree that it doesn't make sense to
have two mechanisms for this, so I will try to formulate a hybrid
mechanism for the next iteration of the draft.

However, I'm a little concerned that the MAYTLS part of this may
directly contradict the policy of the SMTP server. RFC 7671 section 4.1
says, "if usable secure TLSA records are published, authentication MUST
succeed." There would be a similar conflict for SMTP STS. Wouldn't it be
presumptuous for this specification to attempt to supersede those
requirements?

-Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 16 Dec 2016 18:31:49 -0500

> On Dec 16, 2016, at 5:53 PM, Jim Fenton <[email-masked]> wrote:
> 

Thanks.  With that out of the way, I can elaborate on some of the policy
details that need to be discussed as part of this.

> presumptuous for this specification to attempt to supersede those

Given that the protocol under discussion is per-message user-specified
policy, by default, it supercedes the policies learned from "strangers"
(namely the destination domain) via DANE, STS, ...  And so the new
specification can update RFC7672 to explain that per-message policy
from the user generally takes precedence.

That said, local policy can circumscribe what user policies are accepted,
and so an MTA can refuse to honour either MAY or REQUIRE or both.  In the
REQUIRE case, a conformant MTA or MSA must refuse the message.  The the
MAY case it could accept the message and hope that delivery will succeed
without a policy downgrade, or it could refuse the message immediately,
leaving the user the option of not setting an unsupported policy.

Since accepting means that the message may be delayed retrying the delivery
for some time, and notification of the delay may not always happen in a
timely fashion, it is tempting to say that the MTA should refuse MAY when
it does not allow MAY, but on the other hand, the mail could well go through
anyway, and the MTA may well have working/timely delay notices.  So one might
leave the choice of whether to refuse or do one's best without a downgrade to
local policy.

So the idea is to specify a communication channel from the user to the sending
MTA, and leave it up to local policy to decide which user (and/or receiver)
policies to support.

-- 
	Viktor.