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.
