Re: [TLS] Alert after sending ServerHello

[[e-mail] (Martin Rex)]

Ilari Liusvaara wrote:
>> 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.
>  
>> 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.

Up to TLSv1.2 there was no confusion about whether a TLS record
was encrypted or not: everything before "ChangeCipherSpec" is cleartext,
everything thereafter is encrypted.

Easy and straightforward solution would be to add the (meta-)information
whether the Contents of a TLSv1.3 record are encrypted or not into the
outer ContentType field, i.e. define an additional "encrypted Alert"
content type and ensure that Alerts ContentTypes are always visible
in the traditional TLS record header (rather than the bogus/futile
attempt to hide this information).

Having to do heuristics on something that can be easily deterministically
tagged as one or the other, seems a little odd.

-Martin