Yep. More so in DTLS when the alert might arrive after the client has seen the ServerHello. On Fri, May 11, 2018 at 12:59 AM R duToit <r@nerd.ninja> wrote:
> 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 < martin.thom...@gmail.com> wrote ---- > On Thu, May 10, 2018 at 1:48 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
