On 2018-04-17 at 18:20 -0400, Viktor Dukhovni via Exim-dev wrote:
> 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 send it:
>
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2
Interesting; when I look at draft revision 26, it shows that there are
no newer revisions up at the top, so that's what I've been going on.
IETF tooling breakage (perhaps some bad caching).
Nonetheless, looking now at revision 28:
---------------------8< draft-ietf-tls-tls13-28 >8----------------------
9.2. Mandatory-to-Implement Extensions
In the absence of an application profile standard specifying
otherwise, a TLS-compliant application MUST implement the following
TLS extensions:
[...]
- Server Name Indication ("server_name"; Section 3 of [RFC6066])
[...]
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.
---------------------8< draft-ietf-tls-tls13-28 >8----------------------
That's saying that unless we jump through hoops to formally define the
Application Profile for SMTP to MX (and deal with the cranks coming out
of the woodwork to protest anything which doesn't match an idealized
world) TLS SNI must be implemented and explicitly grants servers
permission to require it.
I agree the spec shows we can argue it's not required, but the spec also
allows recipients to argue that it is required.
This came up because, today, Google's servers are responding to TLS1.3
connections which don't send SNI with a self-signed certificate which
has DN:
OU=No SNI provided; please fix your client., CN=invalid2.invalid
So Google are telling sending systems that they're broken and need to be
fixed. I saw that string in my MTA logs and went investigating.
-Phil
