Subject: [ietf-smtp] MTA-MTA SMTP and TLS-on-connect

From: Jeremy Harris <[email-masked]>
Date: Sun, 26 Apr 2020 11:24:47 +0100

Hi,

Noting that https://tools.ietf.org/html/draft-sheffer-uta-rfc7525bis-00
section 3.2 says that TLS-on-connect SHOULD be preferred over STARTTLS
(my rephrasing) - and that while T-o-c is reasonably common for MSA-MTA
but not for MTA-MTA -

should we think about technical means to facilitate the latter?

Eg:
- a new well-known port (vs. TCP/25)
- a DNS SRV label extending RFC 6816, to advertise a port
  with the facility    (NB: RFC 8314 defines a "submissions" label)
- some clever means for autodetect on a single port
- an extension to DANE (RFC 7671) to bundle the port with the
  cert-association
-- 
Cheers,
  Jeremy

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Apr 2020 07:17:41 -0700 (PDT)

> should we think about technical means to facilitate the latter?

Absolutely not. Relaying mail is complicated enough already; adding another
port and DNS lookup to the mix and all the associated failure modes consistutes
a huge cost with no real benefit.

				Ned

> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2020 16:37:19 -0400

>a huge cost with no real benefit.

Agreed, the extra overhead of HELO and STARTTLS is not important, and the net is
already overoptimized for mail on port 25.

I am reasonably sure that if we didn't already have port 465 in
addition to 587, nobody would invent it.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 26 Apr 2020 22:29:34 +0100

> already overoptimized for mail on port 25.

The consideration in the referenced draft was a security one, not an
efficiency one.
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2020 17:59:59 -0400

>should we think about technical means to facilitate the latter?

No.  The authors appear to be unfamiliar with the way that STARTTLS
works in practice.

In particular, if the goal is to ensure that all of the mail to a
domain is sent over an encrypted connection, we have MTA-STS.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Apr 2020 18:17:59 -0400

On Sun, Apr 26, 2020 at 11:24:47AM +0100, Jeremy Harris wrote:

> but not for MTA-MTA

I'll also side with the "no" camp.  For example, a server can politely
tell an unwanted client (bad IP reputation, or blacklisted HELO name) to
go away, before engaging in a TLS handshake.  Also, cleartext HELO would
be useful if I ever get around to specifying DANE for client auth, since
the server could then know where to look for the client's DANE TLSA RRs.

The server could, for example advertise support for client DANE auth,
and the client could respond with an invitation to retrieve its DANE
TLSA RRs.  The TLS handshake then proceeds with the server soliciting
a client cert and able to authenticate it.

There's flexibility in the indirection through an initial cleartext
handshake.  This could of course also be negotiated through TLS
extensions, but my run-ins with the browser monoculture of the TLSWG
leaves me most unenthusiastic about trying to get it done there.

> The consideration in the referenced draft was a security one, not an

The security issue is largely a hypothetical, the cleartext service
makes it possible to not use TLS, but that remains the case even if we
provide TLS-only on a different port.

If one wants to push senders to using TLS, that can be done by gradually
degrading the non-TLS service.  Random 4XX for "MAIL FROM:" outside TLS,
with probability rising over the next decade might do the trick.

Google's inbound stats show TLS use for SMTP at ~90%:

    https://transparencyreport.google.com/safer-email/overview?encrypt_in=start:1385856000000;end:1587945599999;series:inbound&lu=encrypt_region_table&encrypt_out=start:1385856000000;end:1587945599999;series:outbound&encrypt_region_table=region:001;encryption_level:RED

Getting the last 10% over the hump will take some time...

I don't know what's been happening with their outbound traffic recently,
the weekend dips in TLS use have gotten much deeper since Sep 2019.  The
inbound side shows no comparable anomalies.

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2020 18:20:58 -0400

>should we think about technical means to facilitate the latter?

Turns out the STARTTLS language was in RFC 7525 and we missed it.

If this draft goes anywhere, I think we should tell them to fix it and
say that STARTTLS and TLS-on-connect are equivalent if the path with
STARTTLS requires its use, which I think reflects reality.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Apr 2020 15:46:37 -0700 (PDT)

> STARTTLS requires its use, which I think reflects reality.

Agreed. The converse should also be mentioned: There's no advantage to
TLS-on-connect if failure means falling back to an unencrypted port.

All of which is a roundabout way of saying there's actually no security
justification for TLS-on-connect for SMTP, RFC 7525 notwithstanding.

				Ned