Subject: Re: [ietf-smtp] starttls-everywhere

From: Phil Pennock <[email-masked]>
Date: Mon, 1 Apr 2019 14:55:51 -0400

On 2019-03-31 at 22:14 +0200, [email-masked] wrote:
> in my mind that is not a good way forward,
> I thnk it will break up email as an internet service.
> I would much rather go the upwards compatible path,
> like we did for smtp/esmtp which I think has been very succcsful. 
> 
> The esmtp transition has been so successful because we designed 
> it to be so, and nobody was hurt. Transition to starttls has been very successful
> also because it was designed to be smooth. Please don't break email!

Nothing breaks except that which is _supposed_ to break.

Sometimes, things are supposed to break, in the place and manner
designed to do so safely.  This is solid engineering: make sure that
when breakage happens, it happens safely, with minimal knock-on
consequences.  "Never break" is the same as "never repaired".

In this case: if domain A has a policy saying "you should always be able
to use TLS to talk to me", and the operators of domain B know that
they're not on heavily broken Internet and that they should be able to
use TLS to talk to anyone else, as long as those people have advertised
the existence of TLS, then opportunistic TLS is a win and the system
described here only interferes with mail delivery when a
Man-in-the-Middle attacker is stripping out STARTTLS.  Exactly the
scenario where continuing in plaintext is breakage.  The operators of
domain B should be able to decide that yes, they want mail to not flow
to something pretending to be domain A in those circumstances.  Their
systems, their rules.

To keep this on-topic for standards work: over in Exim land: we natively
support DANE; I have a strong objection to MTA-STS; STARTTLS-Everywhere
is something which folks can configure their installs to manage,
although we might need feature work to make "constrained list of
allowable MX hosts" easier to configure ... if we wanted to do go out of
our way to encourage STARTTLS-Everywhere.

STARTTLS-Everywhere is at the level of "distribution of hosts.txt files"
and not really scalable, but ... it probably works well enough and is
suitable for toys.  Anyone serious about privacy and integrity should be
deploying DNSSEC and then publishing TLSA records.

-Phil

---

From: Hector Santos <[email-masked]>
Date: Tue, 02 Apr 2019 11:37:12 -0400

> consequences.  "Never break" is the same as "never repaired".

I think we basically need to keep with the long time support for 
Public Port 25 legacy SMTP operations. It has been a blessing (high 
growth, high connectivity) and curse (the unsolicited spam, the 
potential clear text insecurity).

We can do non-public port enhancements with 587 and 465.  587 offers a 
higher level of enforcement per local/private network policies and 465 
offers implicit TLS on SMTP (SMTPS).

But let's not mess with or break public port 25 legacy SMTP 
operations.  I don't think there is a payoff there for most systems at 
most levels.

-- 
HLS