Re: [TLS] TLS 1.3 and TCP interactions

[David Benjamin <[e-mail]>]

On Fri, May 29, 2020 at 5:36 PM Jeremy Harris <[e-mail]> wrote:

> On 29/05/2020 21:59, David Benjamin wrote:
> > Moreover, in a client-speaks-first protocol, the error now comes after
> the
> > client has already sent its request. This is not only a behavior change
> but
> > makes it unreliable over TCP. TCP sees:
> >
> >
> >    1.
> >
> >    Client: write(ClientHello);
> >    2.
> >
> >    Server: read(ClientHello); write(ServerHello..Finished);
> >    3.
> >
> >    Client: read(ServerHello..Finished); write(Certificate..Finished);
> >    4.
> >
> >    Server: read(Certificate..Finished); write(bad_certificate); close();
>
> Rather than close(), the server should shutdown(SHUT_WR)
>
> >    5.
> >
> >    Client: write(“GET / ...”); read(???);
> >
> >
> > 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.
>
> ... because, having solely notified that it will send no more, the
> server is free to continue to read from the socket.
>

The server's application logic has no reason to continue to read from the
socket. This behavior typically comes from layers above the stack. From the
server's perspective, the TLS library just said the handshake failed. It
required a valid client certificate during the handshake, and the client
did not produce one. This is fatal to the connection, so the server has no
reason to keep it around and no application data to read or write.

The issue is that we've tweaked the I/O patterns in TLS 1.3 such that the
resulting overall behavior interacts badly with TCP. The server could
shutdown(SHUT_WR) and intentionally hold on to the socket and drain data,
in order to get the alert through. That's one of the options I described:

> It seems the only fix is for the server to keep the connection alive for
some time after the failure, maybe draining some bytes from the
application, with some limit before giving up and resetting if the client
seems to be writing a lot of data without ever reading. This would need to
be quite up the stack. We have not implemented this.

This, however, has DoS implications for the server and is a very different
API shape from many current TLS libraries.

David