On Wed, Jun 17, 2020 at 07:51:18PM -0400, Felipe Gasper via Exim-users wrote:
> > On Jun 17, 2020, at 6:22 PM, Phil Pennock via Exim-users <exim-users@???> wrote:
> >
> > because TLS1.3 mandates SNI.
>
> Phil, do you have a citation for this? I skimmed the RFC just now, and
> the only mandatory details about SNI that I see are in the context of
> session resumption.
>
> If TLS 1.3 indeed mandates SNI, then that’s relevant in other
> conversations I’m in and would love to be able to cite that.
It is MTI (mandatory-to-implement), which is not the same as
mandatory-to-use.
https://tools.ietf.org/html/rfc8446#section-9.2
...
Additionally, all implementations MUST support the 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.
However, its use is recommended:
https://tools.ietf.org/html/rfc8446#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.
My concern has always been that with opportunistic TLS, since we'll
ignore any certificate we get, sending SNI may be counterproductive, if
a server aborts the handshake for lack of an exact match for the
requested SNI. Presently it seems safer to send nothing than send a
possibly unsupported value. This could change if TLS 1.3 servers start
requiring an SNI name. I've not seen any reports that this is happening
with SMTP.
--
Viktor.
