Re: [TLS] TLS 1.3 and TCP interactions

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 30 May 2020 01:12 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC033A12CD for <tls@ietfa.amsl.com>; Fri, 29 May 2020 18:12:50 -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 Aofrl2DHerj2 for <tls@ietfa.amsl.com>; Fri, 29 May 2020 18:12:49 -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 1AA593A12CC for <tls@ietf.org>; Fri, 29 May 2020 18:12:49 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2361C31A303; Fri, 29 May 2020 21:12:48 -0400 (EDT)
Date: Fri, 29 May 2020 21:12:48 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20200530011248.GJ48101@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <CAF8qwaBBKvcGMFRxxuVvfBo2Z96mqiEwLfG7H2ZQw0m5+TMnVg@mail.gmail.com> <36e4f801-f61f-4f7e-3a5f-2e68b5cf0f29@wizmail.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <36e4f801-f61f-4f7e-3a5f-2e68b5cf0f29@wizmail.org>
User-Agent: Mutt/1.12.2 (2019-09-21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/phodBinM97QBUoXvOcqyoDheRZ0>
Subject: Re: [TLS] TLS 1.3 and TCP interactions
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2020 01:12:51 -0000

On Fri, May 29, 2020 at 10:36:42PM +0100, Jeremy Harris wrote:

> > Note (4) and (5) happen in parallel. Ideally ??? would be a bad_certificate
> > alert, but it is sometimes a TCP reset. I’m not a TCP expert, but I believe
> > this is because the client writes data (“GET / ...”) the server never
> > consumes.

Fortunately, at least for SMTP, the issues David raises are not likely
to be seen because:

    - The protocol is not unidirectional, client and server take turns.

    - The server sends the first AppData (220 greeting), so the
      NewTicket message is read by the client, or any complaints
      about the client certificate...

However, if the server has something to send during the data transfer
phase (e.g. attempts to rekey the connection), then the client could
perhaps not be polling the server socket for incoming traffic, and
a deadlock may be possible.

Such mid-transfer traffic from the server is rather unlikely in
practice, so I don't think there are immediate concerns for Exim or
Postfix, but keeping an eye on the server socket for incoming data may
be prudent.  If a zero-length SSL_read() when the socket appears
readable takes care of any unexpected non-application-data, then
it should be fairly easy to incorporate into the I/O loop.

    - If the remote socket is readable, but you're trying to write
      and don't yet expect to read, do a zero-byte read, but since
      this may not drain the read queue of unexpected app-data,
      don't poll for read again unless the write side has made
      some progress.

    - If you have something to write, and the socket is writable, write it.

    - If you are expecting to read something, read a chunk of data,
      paying attention also to SSL_ERROR_WANT_WRITE.

At least in Postfix, the socket is non-blocking once TLS is enabled and
we're relying on SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE to provide
appropriate retry signals, and then wait for the corresponding
condition.

Handling out-of-turn app-data (mid-data-transfer server errors) requires
a bit more care, but the server is supposed to wait until the client
sends '.'.  Early SMTP error responses are unreliable even without TLS.

-- 
    Viktor.