The server sending the alert at warning level while knowing that it is about to negotiate TLS 1.3 seems to be in violation of the statement that "All alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal," - that is probably more of an implementation issue.
The client's reaction to the warning alert is what is ambiguous. Some TLS 1.3 client implementations will ignore the alert, while others will choke. ---- On Thu, 10 May 2018 02:05:18 -0400 Martin Thomson <[email protected]> wrote ---- On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni <[email protected]> wrote: > I may be misreading the code, but it sure looks like the alert is only > sent if the application callback for the server name extension asks > OpenSSL to do that. The application can just decline the extension > and let the handshake continue with a default certificate... Is > the surprise that the alert is sent, or that it is a warning, or > something else? It's risking a failed connection. Though perhaps not that much more than providing the client with a certificate it might not like. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
