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 relation to ServerHello, it should be in plaintext, and when it is in relation to EncryptedExtensions, Certificate, ..., or Finished message, it may be either in plaintext or encrypted with client_handshake_traffic_secret (of course, plaintext alerts are allowed only until the first record encrypted with handshake_traffic_secret keys) logic being, that the purpose of the alert is to tell the other side why the connection is being broken, no use of doing that if the other side (or even an admin using the server's SSLKEYLOGFILE) won't be able to read that message 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 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
