Re: [exim] MTA-STS and Server Name Indication (SNI) on mail …

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Viktor Dukhovni
Fecha:  
A: exim-users
Asunto: Re: [exim] MTA-STS and Server Name Indication (SNI) on mail servers
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.