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

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 26 April 2020 22:18 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6819A3A0A3E for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 15:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.413
X-Spam-Level:
X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7g0PzA-oXOP for <ietf-smtp@ietfa.amsl.com>; Sun, 26 Apr 2020 15:18:07 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5795F3A0A2F for <ietf-smtp@ietf.org>; Sun, 26 Apr 2020 15:18:01 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id DA9B6549D8; Sun, 26 Apr 2020 18:17:59 -0400 (EDT)
Date: Sun, 26 Apr 2020 18:17:59 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <20200426221759.GB41308@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b4a612c6-1073-c162-190a-f522ded19277@wizmail.org> <8d3d7446-db7d-ac04-2a36-258643254630@wizmail.org>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/g8-E5lrZMKjMgJ8YHhWgvse61FQ>
Subject: Re: [ietf-smtp] MTA-MTA SMTP and TLS-on-connect
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2020 22:18:12 -0000

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.