Re: [TLS] TLS 1.3 and TCP interactions

Ilari Liusvaara <> Sat, 30 May 2020 07:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 981713A07BA for <>; Sat, 30 May 2020 00:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t6ZlyK4Z8koX for <>; Sat, 30 May 2020 00:41:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09C863A07B9 for <>; Sat, 30 May 2020 00:41:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EC0DCA2C; Sat, 30 May 2020 10:41:07 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id LllnWZK1cmKz; Sat, 30 May 2020 10:41:07 +0300 (EEST)
Received: from LK-Perkele-VII ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 480487A; Sat, 30 May 2020 10:41:05 +0300 (EEST)
Date: Sat, 30 May 2020 10:41:04 +0300
From: Ilari Liusvaara <>
To: David Benjamin <>
Cc: "<>" <>
Message-ID: <20200530074104.GA1510695@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] TLS 1.3 and TCP interactions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 May 2020 07:41:14 -0000

On Fri, May 29, 2020 at 04:59:57PM -0400, David Benjamin wrote:
> Half-RTT data
> We haven’t done much with half-RTT data outside of 0-RTT connections, but
> half-RTT may risk similar issues. Half-RTT data in a client certificate
> connection is sent before the server learns the client identity. That means
> the connection is writable before all its properties are established, which
> is an awkward API.
> One might think to avoid this state by configuring half-RTT data ahead of
> time for the library to write during the handshake, immediately after
> ServerHello..Finished. A half-RTT HTTP/2 SETTINGS frame doesn’t need a
> streaming API, and this avoids exposing the incomplete state to the caller.

There are other issues with half-RTT HTTP/2 SETTINGS as well. I had a
HTTP/2 implementation that used to send HTTP/2 SETTINGS as half-RTT if
there was no client certificate[1]. I later changed it to not use
half-RTT for HTTP/2 because some TLS clients puked with
unexpected_message alert if one sent SETTINGS in half-RTT[2]. I do not
know which clients did that[3].

[1] Not doing that with client certificate was caused by API issues
with the handoff. The TLS library native API would have allowed sending
data in half-RTT even with client certificate pending (unlike say false
start, which is the TLS implementation just prohibits).

[2] The unexpected_message actually came after the handshake
completed (the client did send correct Finished MAC). 

(Fixing the issue was quite nasty shotgun debugging, and it took
long time to verify issue was fixed, as normally there would only be
one or two failures per day.)

[3] Some terse user reports I heard reported things like the site
not working in Firefox on Windows host, but working in Firefox on
Linux VM on that host and site not working in Chrome (or Chromium?)
but working in Firefox on the same system.

(I did get one user report that the problem was fixed about a
week after I did the change that fixed it.)