On Wed, Apr 26, 2017 at 03:01:40AM +0000, Roelof Du Toit wrote:
> 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.
Yes, that's the way the library I'm writing does it: The first
record received after ServerHello is sent can be cleartext alert for
the case where client chokes on ServerHello, or it can be encrypted
record.
It does not support 0-RTT (insufficient understanding of the actual
security properties, need to design API properly).
One can easily tell unencrypted alert and encrypted record from
envelope type (unencrypted alert has 21, encrypted alert or client
returning handshake is 23).
> 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:
If you ever receive envelope-type-21 record, you know that the
connection has failed. All those are fatal errors.
The difference is really the error (illegal record type vs.
received alert).
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
