> On Oct 24, 2017, at 8:15 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
>
> One thing to be _very_ careful of is not to break SNI semantics. Which
> include "one name, which has to be correct".
Actually, it does not have to be correct. Postfix happily ignores
SNI and continues with the default certificate chain. Indeed that's
true for every MTA that's using OpenSSL, unless it takes special
care to degrade service by paying ttention to SNI and objecting to
unexpected names. By default the SNI signal from the client is
simply ignored. Once again, SMTP is NOT HTTP.
> SNI assumes the web model, where there is only one correct name the
> client wants to connect to.
No, it is just a hint to the server, that may help it to identify
the right chain. See
https://tools.ietf.org/html/rfc7672#section-8.1
Each SMTP server MUST present a certificate chain (see [RFC5246],
Section 7.4.2) that matches at least one of the TLSA records. The
server MAY rely on SNI to determine which certificate chain to
present to the client. Clients that don't send SNI information may
not see the expected certificate chain.
If the server's TLSA records match the server's default certificate
chain, the server need not support SNI. In either case, the server
need not include the SNI extension in its TLS HELLO, as simply
returning a matching certificate chain is sufficient. Servers
MUST NOT enforce the use of SNI by clients, as the client may be
using unauthenticated opportunistic TLS and may not expect any
particular certificate from the server. If the client sends no SNI
extension or sends an SNI extension for an unsupported domain, the
server MUST simply send some fallback certificate chain of its
choice. The reason for not enforcing strict matching of the
requested SNI hostname is that DANE TLS clients are typically willing
to accept multiple server names but can only send one name in the SNI
extension. The server's fallback certificate may match a different
name acceptable to the client, e.g., the original next-hop domain.
> In fact, the specification has a note that
> earlier drafts supported multiple names, but this was explicitly
> dropped as not useful.
Indeed only one hint can be sent, but it need to be an exact match.
> One way to do that with sending SNI would be:
>
> - Check received MX (and SRV?) records against the policy (including
> the possible implicit MX). Discard all that do not match. If no
> targets remain, raise temporary error.
> - Pick a mail exchanger from the remaining entries, look up its
> address, and connect with SNI being the target of the MX (or SRV?)
> record (without chasing CNAMEs).
This broken algorithm is precisely why I did not want to see MX
filtering in STS, and so we now only use the names for matching
not filtering. It neglects to perform loop elimination (removing
all MX hosts worse than the sending host itself when it is one
of the MX hosts for the destination) before discarding names that
don't match the policy.
> And since SNI is intended for "one name" standard certificate name
> validation scenario, this would also allow using the standard name
> validation instead of the wildcard-to-wildcard matching.
SNI is a means to signal the client's most preferred name to the
server. The server can use that name to identify an appropriate
chain, or it can just ignore it, and should respond with a
default chain if it inspects the name and find no specific chain
for that name. It is up to client to accept or reject the
certificate chain it ultimately receives from the server.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
