miTLS and NSS servers emit different alerts when manipulating EncryptedExtensions

[oweisse-msft]

Items inside EncryptedExtensions are shuffled, and encrypted with the correct server handshake key. The miTLS client responds with plaintext-alert  bad_certificate, while NSS client doesn’t emit an alert (potential NSS issue) .    1. In case of miTLS server and miTLS client (emitting bad_certificate), the miTLS client response will be encrypted-alert of type   decryption_failed_RESERVED 2. In case of NSS server and miTLS client (emitting bad_certificate), the miTLS client response will be encrypted-alert of type   bad_record_mac (that sounds right, since the MAC doesn't fit the re-ordered message from the server). 3. In case of miTLS server and NSS client (which is not emitting an alert), FFI_mitls_accept_connect is completed successfully, even though the client's Finished has not been sent.

[beurdouche]

@oweisse-msft Does NSS close the connection instead of sending an alert or does it keep going ? 1 - Sending a 'RESERVED' value with TLS 1.3 doesn't seem good. 3 - Not good.

[BarryBo]

Can you follow up on this bug? Please check if it is still and issue, and if it'll be caught/fixed as part of the verification push?