Re: [TLS] TLS 1.3 and TCP interactions

Watson Ladd <> Fri, 29 May 2020 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C3E53A1116 for <>; Fri, 29 May 2020 15:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WOeRhlyDN5mg for <>; Fri, 29 May 2020 15:36:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F6753A1114 for <>; Fri, 29 May 2020 15:36:11 -0700 (PDT)
Received: by with SMTP id z18so1125662lji.12 for <>; Fri, 29 May 2020 15:36:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=53uWGcS+eq2/wyQ3385HgxZ09sdWPtvzrwXNDN93/pc=; b=ROQdoRpn2r5ilTnMHIL5e1ydMMyRgMy2knn6Z4lkOBSBPB/dn9LmU0CPcJbkN9cPVR zi3sF/kloaFzLO8hbeSJC9yKjU0flCRkjQcsP3F0cR3ewWU5NuprvhzIb4Kp48txWieZ 42TOJTrQpB/7iVcgyvFejrZun5sbWt9PqIjbIH+tmEm18EXmDSqeD/cpS3VQuZX2m+kk ZDcQkdZjkJDonPuiYxQLSsowWLFsC/ykxTwQZ1nOvbruWS1Xdxxjas23odkU6v3mJrt7 SDJid5ori4z/DilB/VrIEjnVKTWPI4BmFC1hw81enzVMMsdb5Z19HOmMH35SWWxFHnNX NyHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=53uWGcS+eq2/wyQ3385HgxZ09sdWPtvzrwXNDN93/pc=; b=TnePK8XWW9kgty1N9GljKg5B9TG3adut0uS+hHBPJQ5IndAbD/aXrREG90gj0PCKI6 WvvGyrnDToUrxz69eMIxgJSi0Yxoqigxu28DrqScW7xg51kr4TMw5/DBcrvDyOIgt3R1 lzaYHWKJd6HTeMuqZKG4Ts8MJRdag1EkUisnNfy052jVRAwhXWJybSkCQMimh4B+Un5e rRGqwLxEPAymVFy2RKBIENDhfPIQa4oGRxzMhXj2SrG5Nkdt7JGTksirVFEuWHuAqCjd miom4+iVobKUni/ihW+ElT6pFKCKq58AhgZTcCL+KPj6RdeyScgovUUyIQGveUC1piA9 85+g==
X-Gm-Message-State: AOAM532IfR5YtqfRrotWoy5vxNac+D+wjBv331ey2tuo2jax+IuddCdc 7lQTqXWy537CcHmh60zsT9WdjzNJbwhYFEVG2Ew=
X-Google-Smtp-Source: ABdhPJxfCAA4iBYobNNBP6LMd1AwQuHrdmjkgk6OJHJeT1OjsHtE0oAZE51lbDnoDxqMD0wSB6WFTWzeoNhRAj77OLQ=
X-Received: by 2002:a2e:95c5:: with SMTP id y5mr5257059ljh.229.1590791769908; Fri, 29 May 2020 15:36:09 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Fri, 29 May 2020 18:35:58 -0400
Message-ID: <>
To: David Benjamin <>
Cc: "<>" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 29 May 2020 22:36:13 -0000

On Fri, May 29, 2020 at 5:01 PM David Benjamin <> wrote:
> Hi all,
> As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some interesting interactions with TCP. We thought we’d document these and send a note here. In general, we've found that TLS implementations need to be wary of post-handshake messages and “unexpected” transport writes. This unfortunately also includes some server handshake alerts.
> First, some background on APIs for TLS libraries. TLS is often deployed “transparently” underneath a TCP-based protocol. HTTPS sandwiches TLS between HTTP and TCP, etc. By and large, reads and writes over TLS are one-to-one with reads and writes over TCP.
> TLS APIs and callers can subtly rely on this. Some libraries expose an interface like the POSIX sockets API, including non-blocking behavior. If the transport is blocked on I/O, this is surfaced as an error for the caller to retry later. Importantly, the library cannot drive transport I/O on its own. The caller must drive the operation to completion. Other APIs transform bytes and leave I/O to the application.. Any TCP writes triggered by TLS reads and vice versa are even more directly part of the API surface. In contrast, sometimes the TLS library can drive I/O itself. For example, a Go TLS implementation can do background work in a goroutine.

In my experience the issues are thorniest when dealing with blocking
sockets. Libraries using nonblocking sockets have to signal to the
application that they want IO to happen during the handshake, and can
use that same mechanism at later times, particularly for rekeying.
Libraries with blocking behavior are unfortunately in a difficult
position if they imitate a POSIX API and have no means to drive I/O.

One possible dirty trick is to set nonblocking on an owned socket and
translate the blocking call into a select or poll based loop that
issues both writes and reads until enough is read or written. Note
that the real corner case is unanticipated needs to read from the
socket: the library has control when it needs to write.