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@exim.org> 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/