Re: [TLS] TLSv1.3 Cookies

[Matt Caswell <[e-mail]>]

On 13 September 2017 at 16:09, Ilari Liusvaara <[e-mail]> wrote:
> On Wed, Sep 13, 2017 at 03:53:46PM +0100, Matt Caswell wrote:
>> I am looking at trying to implement the TLSv1.3 stateless cookie
>> mechanism (in order to be able to support QUIC stateless retries).
>>
>> I am not clear how cookies are supposed to interact with early_data.
>> Consider the scenario where a server is operating statelessly. Because
>> there is no state each ClientHello looks like the first one it ever
>> saw. The server only knows that a particular ClientHello is actually a
>> ClientHello2 following an HRR because of the state held in the cookie.
>
> Looking at the definitions of Cookie and EarlyData extensions, those
> two are mutually exclusive. That is, there can be three kinds of
> ClientHello messages:
>
> 1) Contains neither Cookie nor EarlyData.
> 2) Contains an EarlyData, but not Cookie.
> 3) Contains a Cookie, but not EarlyData.
>
> (This exclusivity arises because Cookie can only be present in a retry,
> but EarlyData is stripped out for retry).
>
>> What happens when a client attempts to send early data to such a
>> server? The server will process the ClientHello and determine that
>> there is no cookie, sends back an HRR and then forgets all of its
>> state and waits for the next ClientHello. However what it actually
>> gets next is early_data. It does not know that that early data
>> followed an earlier ClientHello (because it is stateless) so it does
>> not know to skip the records. It just looks like illegal records so,
>> presumably, it will respond with an alert.
>
> Yes, if one receives a ClientHello with both Cookie and EarlyData, one
> can reply with a fatal alert, because that is not supposed to happen.

That isn't quite the scenario I was talking about. Rather your case
(2) above in a server which is operating statelessly, i.e. the client
has attempted to send early_data but has not provided a valid cookie
yet. The early_data when it arrives will look like bad packets, even
though (from the client perspective) it was valid to send them.

It kind of suggests that stateless operation is incompatible with
early_data, i.e. a server should not advertise early_data support in
its tickets if it is going to operate statelessly (because stateless
operation implies an HRR which implies no early_data). There is still
an edge case where a server's configuration has changed (i.e. it used
to operate statefully but now operates statelessly) - in that case a
client might have a valid ticket advertising early_data support which
the server will choke on when it actually receives that early_data.

>
> There is worse edge case with client key share tho: If a ClientHello
> that contains a Cookie does not contain suitable key share, that is an
> irrecoverable error, and the only thing server can do is to send a
> fatal alert (and hope the client somehow retries the connection setup).

Well, yes - if it contains a cookie then there must have been an HRR -
so this is a legitimate fatal error.

Matt