> On Oct 17, 2017, at 6:05 AM, Daniel Margolis <[email protected]> wrote:
>
> In any event, what is there to clarify? STS doesn't change the behavior of
> the MTA with respect to SNI at all, after all; we merely impose constraints
> on what certificates must be presented irrespective of SNI. What's the
> interaction here to clarify?
Before DANE or STS certificate verification failure is ignored, so
no SNI need be sent. Thus, for example, with unauthenticated
opportunistic TLS Postfix does not send SNI, and even enables
and prefers anon-(EC)DH ciphersuites, which send no certificates
at all (sadly, these go away with TLS 1.3).
With DANE, when TLSA records are published, and authentication
failure skips the MX host (deferring mail when no other MX hosts
remain), because the published TLSA record could be associated
with a non-default certificate chain, SNI is required to be
sent and must be the "TLSA base domain"[1].
With STS, there is now a choice:
1. Require the default certificate to match a/the MX
hostname from the policy (is the matching staying
the same or is it changing back based on recent
feedback?) and client transmission of SNI is optional
(perhaps even discouraged).
2. Require STS clients to send the MX hostname as the
SNI domain, in case the remote MTA has multiple TLS
personalities. [2]
By far the majority of domains do not use vanity MX hostnames,
so option 1 is a plausible constraint on would-be STS domains,
they'd have to stop using aliases, and use the same MX hostname
as all the other customers of the provider.
If however, we want to be cautious and assume that such vanity
names are there for good reason, and that providers should be
combine STS with SNI-mediated virtual-MX hosting, then SNI
will need to *always* be sent by STS clients, or else the
STS policy will need to specify a new attribute that signals
when SNI is required.
--
Viktor.
[1] The TLSA qname sans "_25._tcp" prefix, which is either the
full MX hostname CNAME expansion or the raw MX hostname, whichever
is both lies in a DNSSEC signed zone and has TLSA records. See
https://tools.ietf.org/html/rfc7672#section-2.2.3
[2] The Exim SMTP server supports SNI, and IIRC I'd seen at least
one domain use it, but this is not easily discovered in my survey
database as I don't presently make separate non-SNI connections
to each host so there is no record of whether SNI was needed to
elicit the correct certificate.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
