On 08/08/18 12:13, Hubert Kario wrote:
> On Tuesday, 7 August 2018 10:35:40 CEST Matt Caswell wrote:
>> If a client has sent early_data and later encounters an error before it
>> has sent the end of early data message, should the alert be sent in
>> plaintext, or encrypted using the client_early_traffic secret? The error
>> could occur before or after the client knows whether the server has
>> accepted its early_data.
>
> I'd say that if the alert is in relation to early_data, it should be
> encrypted
> with client_early_traffic keys (internal_error, user_canceled), if it is in
The problem with this is that if the server does not accept the early
data then it won't be able to read the alert. From the server's
perspective the client will just abort with no alert sent.
> that being said, very strict reading of the draft-28 would indicate that
> alerts shouldn't be encrypted at all with the client_early_traffic keys:
>
> 0-RTT messages sent in the first flight have the same (encrypted)
> content types as messages of the same type sent in other flights
> (handshake and application_data) but are protected under different
> keys.
>
> (the "alert" type is not listed)
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58
>
This was my interpretation too (thanks). What I've (now) implemented in
OpenSSL is that all alerts from the client are in plaintext until the
client_handshake_traffic_secret is in place, and then encrypted from
then on.
On the server side we tolerate encrypted (with client_early_traffic key
or client_handshake_traffic_secret key as appropriate for the context)
or unencrypted alerts until we've actually seen a handshake message from
the client encrypted with the client_handshake_traffic_secret. From then
on, only encrypted alerts are accepted.
Matt
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
