You are allowed to out NSS. We know that it's not ideal.
I wrote that code and it's unencrypted for what I think is a good
reason (others very much disagree). In part, it has to do with 0-RTT.
In 0-RTT, we want to ensure that the client is able to continue
sending 0-RTT until the entire server flight is received. Thus, we
don't change out the keys until we receive and process the server
Finished. The same code is used in 1-RTT. I think that we have a bug
in that the alerts are 0-RTT encrypted; it might be better to send
them in the clear as well.
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.
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.
On 26 April 2017 at 13:01, Roelof Du Toit <roelof_dut...@symantec.com> 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.
>
>
>
> 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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
