The mandatory to implement language in the TLS 1.3 spec does not mean "mandatory to use", in particular, while servers must tolerate the extension, clients are not obligated to sen d it:
https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2 - The "server_name" [RFC6066] and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. SHOULD is of course a strong incentive, but it is not a MUST, and, if no SNI can be reasonably inferred, and particularly if not authenticating the peer, the SNI can be left out. Time will tell whether there are more servers that screw up by aborting when receiving an SNI for which they don't have an exactly matching certificate, or by mandating SNI with TLS 1.3 despite serving a mostly opportunistic protocol! While the TLS 1.3 protocol does allow servers to insist on SNI: Additionally, all implementations MUST support use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert. Such insistence will quickly run into interop issues with opportunistic TLS from e.g. Postfix, where SNI will not be sent by default. I expect that MTAs (as opposed to perhaps MSAs) will not require SNI. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
