Re: [TLS] Alert after sending ServerHello

[Martin Thomson <[e-mail]>]

On 26 April 2017 at 17:19, Ilari Liusvaara <[e-mail]> wrote:
> AFAIK, the only situations where client can abort sending 0-RTT data
> is noticing lack of server EarlyData extension (so server isn't
> listening anyway), or if the entiere handshake is aborted.. Doing it
> in other situations leads to subtle race conditions.

NSS stops sending 0-RTT as soon as it processes EncryptedExtensions.
It also stops if it receives a HelloRetryRequest.  In both cases you
know that the server is trial decrypting and so it will correctly
handle more 0-RTT data, but there is no point sending more if you know
that it is junk.

>> In effect, we assume that the entire flight is processed atomically
>> and generate errors based on that.  Only when the entire flight is
>> processed cleanly do we install keys and respond.
>
> My implementation processes message-by-message. So it installs the
> client handshake keys after ServerHello.

NSS processes message-by-message, but the we just delay installing the
client handshake keys.  This allows us to get the most out of 0-RTT,
but has this small downside.

>> This is a pain for us, we don't have the code that Ilari talks about,
>> so some of our tests end up hitting decode errors on the server, but
>> it's been manageable thus far.
>
> The code I was talking about was handling the special case that the
> server might receive either encrypted or unencrypted alert in response
> to its flight. And the difference it makes is just what error is
> declared as abort reason.

Yeah, it's totally manageable, but there are a few small warts in the
tests (which match the sent alert on one side with the received alert
on the other side in the normal case).