During interop testing with an open-source stack I ran into the following:
CH ---->
<---- SH,{EE,Cert,CV,Fin}
alert ---->
The alert was due to a decode error on CV, and the stack in question sent the
alert in a plaintext record.
The current draft specification has the following text in section 6:
"Like other messages, alert messages are encrypted as specified by the current
connection state."
.. and the following in section 5.1:
"Once record protection has started, TLSPlaintext records are protected"
I expected the alert above to be sent in a ciphertext record, but I can also
see the client sending plaintext alerts for ServerHello decode failures.
My conclusion is that the TLS 1.3 record layer on the server side should
support receiving both ciphertext and plaintext records after ServerHello has
been sent.
One way for the server to handle the scenario above is to defer using
client_handshake_traffic_secret until the first app_data record is received.
That idea falls flat when the client is also sending early data and the server
wants to ignore the early data using trial decrypt with
client_handshake_traffic_secret:
CH ---->
(ed) -----X (discard)
...---- SH
(ed) ----X (trial decrypt + discard)
<---...
alert ---->
Another way this could work is if the server allows one (and only one)
plaintext record (with ContentType = alert) from the client during the window
where it has sent the SH,{EE,Cert,CV,Fin} sequence and is waiting for the
client's first encrypted handshake message.
I would appreciate a recommendation in order to avoid future interop issues.
--Roelof
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
