Re: [ietf-smtp] TLS1.3

Sam Varshavchik <mrsam@courier-mta.com> Wed, 29 April 2020 22:02 UTC

Return-Path: <mrsam@courier-mta.com>
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 C02A33A07F0 for <ietf-smtp@ietfa.amsl.com>; Wed, 29 Apr 2020 15:02:44 -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 SyvW4ITimg9a for <ietf-smtp@ietfa.amsl.com>; Wed, 29 Apr 2020 15:02:42 -0700 (PDT)
Received: from mailx.courier-mta.com (mailx.courier-mta.com [68.166.206.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21563A0770 for <ietf-smtp@ietf.org>; Wed, 29 Apr 2020 15:02:15 -0700 (PDT)
Received: from monster.email-scan.com (monster.email-scan.com [::ffff:192.168.0.2]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by www.courier-mta.com with UTF8ESMTPS id 00000000002C0012.000000005EA9F966.0000E761; Wed, 29 Apr 2020 18:02:14 -0400
Received: from monster.email-scan.com (localhost [127.0.0.1]) (IDENT: uid 1004) by monster.email-scan.com with UTF8ESMTP id 000000000005E9BB.000000005EA9F965.0001EC7F; Wed, 29 Apr 2020 18:02:13 -0400
References: <3aab7ca5-27f1-1ba6-565f-650b67124fe8@wizmail.org>
Message-ID: <cone.1588197733.557070.108041.1004@monster.email-scan.com>
X-Mailer: http://www.courier-mta.org/cone/
From: Sam Varshavchik <mrsam@courier-mta.com>
To: ietf-smtp@ietf.org
Date: Wed, 29 Apr 2020 18:02:13 -0400
Mime-Version: 1.0
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg
Content-Type: multipart/signed; boundary="=_monster.email-scan.com-108041-1588197733-0002"; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/5qBESG7SIMNtjn4OH1f2iRq82J8>
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, 29 Apr 2020 22:02:45 -0000

Jeremy Harris writes:

> For amusement, I see this week failing attempts to send messages
> from what should be a reasonably large operator, using TLS1.3 ...
> and failing to handle a client-cert request in the handshake.
>
> It emits a fatal "unexpected message" alert.  Turn off the
> client-cert request, and it works fine.
>
> Name withheld to protect the guilty.

I wouldn't necessarily blame the operator. It's almost a sure bet that  
they're using OpenSSL, and this developer's opinion is that OpenSSL is one  
of the worst, most confusing, and the most poorly documented API libraries  
in existence.

It just so happens I'm in the middle of sort of like a modern version of  
playing chess by mail. You know: you and your partner halfway across the  
world have identical chessboards set up, and you have a turn-based game, by  
postal mail, going on. I recall reading about those things, a long time ago.  
Except that this is more like an interactive, turn-based debugging session,  
rather than a chess match. After a few days' worth of back-and-forth, things  
have reached the stage where it's been determined that the OpenSSL library  
is reporting an error code that its own documentation describes thusly:

      SSL_ERROR_SYSCALL
          Some non-recoverable, fatal I/O error occurred. The OpenSSL error
          queue may contain more information on the error. For socket I/O on
          Unix systems, consult errno for details.

And, immediately after that, the code in question does "consult errno", and  
finds that it's zero. No error has occured, according to the operating  
system.

Who to believe? And what exactly is someone supposed to do, with the SSL  
connection, at this point?

Random Googling around found a few similar, but not identical, reports of  
various other OpenSSL API functions randomly changing their behavior,  
depending on the negotiated version of TLS, to the confusion of the  
application code that expects existing behavior from them.

All my new code uses GnuTLS. The GnuTLS API is very logical, and very easily  
adaptable to either C or C++ code. Its very clear who owns what resource,  
unlike OpenSSL, where object ownership is rather …fluid, so for years  
various apps turn out to be trying to use various library objects after  
they're freed, or they leak memory, etc…