On Wed, Jun 17, 2020 at 08:47:08PM -0400, Felipe Gasper wrote:
> > On Jun 17, 2020, at 8:17 PM, Viktor Dukhovni via Exim-users <exim-users@???> wrote:
> >
> > 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.
>
> The recommendation is contextual to cases “when applicable”. This is
> significant because in applications where the server ignores the
> extension it’s arguably counterproductive to send it since it
> discloses the hostname that the client intends to hit. Thus it seems
> that if the server ignores the extension, it’s better NOT to send
> it--at least until encrypted SNI becomes practical.
SMTP is not HTTPS, the client sends EHLO in the clear, after receiving
the server's greeting in the clear. And there's not a lot of "virtual
hosting". Just shared MX RRs, but the server name is pretty much never
a secret. So the privacy argument for not sending SNI is very weak to
non-existent. My concern has always been just about uncessary ways to
lose (i.e. have the TLS handshake fail).
For now, the risk is likely higher of having failure due an unexpected
SNI value, than of failure for lack of SNI. If that changes, we'll have
to adapt accordingly.
--
Viktor.
