Re: [ietf-smtp] TLS1.3

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 06 May 2020 02:11 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 580B33A0CF4 for <ietf-smtp@ietfa.amsl.com>; Tue, 5 May 2020 19:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 hAfQn7tqOJVy for <ietf-smtp@ietfa.amsl.com>; Tue, 5 May 2020 19:11:40 -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 906153A0CD8 for <ietf-smtp@ietf.org>; Tue, 5 May 2020 19:11:39 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id C932E2A1534; Tue, 5 May 2020 22:11:37 -0400 (EDT)
Date: Tue, 5 May 2020 22:11:37 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <20200506021137.GL76674@straasha.imrryr.org>
Reply-To: ietf-smtp@ietf.org
References: <3aab7ca5-27f1-1ba6-565f-650b67124fe8@wizmail.org> <cone.1588197733.557070.108041.1004@monster.email-scan.com> <20200505135020.GH76674@straasha.imrryr.org> <cone.1588723433.721450.34142.1004@monster.email-scan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cone.1588723433.721450.34142.1004@monster.email-scan.com>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/hX8qFp0ogocVTWLnpZUrZMC8opE>
Subject: Re: [ietf-smtp] TLS1.3
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: Wed, 06 May 2020 02:11:43 -0000

On Tue, May 05, 2020 at 08:03:53PM -0400, Sam Varshavchik wrote:

> So after reading the following:
> 
> # When a certificate was set using the SSL_CTX_use_certificate(3) family of  
> # functions, it will be sent to the server. The TLS standard requires that  
> # only a certificate is sent, if it matches the list of acceptable CAs sent by  
> # the server. This constraint is violated by the default behavior of the  
> # OpenSSL library.
> 
> This appeared to me like a client that was configured with a certificate for  
> some other host, but sending it in error, here, and the server rejecting the  
> connection for that reason.

No that's not it.  And actually, OpenSSL is generally correct in using
the client certificate anyway.  The server may, e.g., not trust any CAs,
and verify client certs by fingerprint.  A client that is an MTA, and
not some user worried about privacy leaks has nothing to hide in
sendings the only certificate it is configured with.  The specification
assumes a narrow trust model that does not match reality.

> Problematic TLS implementation have been quite common, historically. For a  
> long time I was seeing frequently TLS-related misconfigurations with SMTP  
> servers. I lost count how many servers I saw advertising STARTTLS but  
> choking when taken up on their offer:
> 
> 220 poorly-configured-server.example.com ESMTP
> EHLO hythere
> 250-poorly-configured-server.example.com Ok.
> 250-STARTTLS
> 250-PIPELINING
> 250-8BITMIME
> 250-SIZE
> 250 DSN
> STARTTLS
> 450 Not now, maybe someday.

Indeed a minority are misconfigured in this manner.  When TLS is
optional (opportunistic and unauthenticated), Postfix will retry
in the clear when this happens, provided the message has been in the
queue for at least one retry interval.

> At one point I had to carefully implement an adaptive, transient TLS  
> blacklist: ignore the server's STARTTLS if you have a prior record of the  
> server failing to negotiate a TLS connection.

See above.

-- 
    Viktor.