On Sun, Apr 26, 2020 at 11:24:47AM +0100, Jeremy Harris wrote:
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?
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.
On Sun, Apr 26, 2020 at 10:29:34PM +0100, Jeremy Harris wrote:
On 26/04/2020 21:37, John Levine wrote:
Agreed, the extra overhead of HELO and STARTTLS is not important, and the
net is
already overoptimized for mail on port 25.
The consideration in the referenced draft was a security one, not an
efficiency one.
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp