Subject: [Uta] MTA-STS-03 review

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Mar 2017 01:04:45 -0400

[ I've pasted in the entire draft, and "quoted" it as though it
  were a post to trim an reply to. ]

>               SMTP MTA Strict Transport Security (MTA-STS)
>                        draft-ietf-uta-mta-sts-03
> 
> Abstract
> 
>    SMTP Mail Transfer Agent Strict Transport Security (SMTP STS) is a
>    mechanism enabling mail service providers to declare their ability to
>    receive TLS-secured connections and an expected validity of
>    certificates presented by their MX hosts, and to specify whether
>    sending SMTP servers should refuse to deliver to MX hosts that do not
>    offer TLS with a trusted server certificate.

In the abstract I think that "TLS-secured" already covers certificate
validity (which makes for a clumsy insertion into the text anyway).
Also instead of "TLS-secured connections" say "TLS-secure SMTP connections".

See https://www.rfc-editor.org/materials/abbrev.expansion.txt for the
list of common IETF acronyms, and which are sufficiently widely used
to not need to be expanded on first use.  Thus SMTP and ESMTP are fine
with expansion, but apparently we've not yet reached similar familiarity
with TLS. :-)

> 1.  Introduction
> 
>    The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
>    hosts to negotiate the use of a TLS channel for secure mail
>    transmission.

I would drop "secure" above, or replace it with "encrypted".

>    While such _opportunistic_ encryption protocols provide a high

While "_" may work as italics in MarkDown, you'll need to change all
these to RFC XML (where IIRC <i>...</i> may be supported, but don't
take my word for it, check).

More importantly, you've made quite a leap here from talking about
RFC 3207, which merely defines an SMTP extension mechanism, to assuming
that the reader knows how the extension is typically used.  It also
important to recall that opportunistic security (as defined in RFC7435)
subsumes both MTA best-effort unauthenticated encryption, and the new
opportunistically authenticated DANE and STS use-cases.  With DANE and
STS transmission is protected only when and as receiving system publishes
the requisite policy records.  DANE offers stronger downgrade protection,
at the cost of requiring DNSSEC to achieve that goal.

>    barrier against passive man-in-the-middle traffic interception,

therefore the "passive-only" protection is a feature of unauthenticated
opportunistic security, as practiced by most MTAs at present.

>    This document defines a mechanism for recipient domains to publish
>    policies specifying:
> 
>    o  whether MTAs sending mail to this domain can expect TLS support
> 
>    o  expected validity of server certificates presented by the domain's
>       MX hosts

It seems to me that STS does not provide any means to signal
unauthenticated TLS support.  And so, as in the abstract, the
above two bullets are really just one, "WebPKI TLS security".

> 1.1.  Terminology
> 
>    We also define the following terms for further use in this document:
> 
>    o  STS Policy: A committment by the Policy Domain to support PKIX
>       authenticated TLS for the specified MX hosts.

Which I think confirms my point about "authenticated TLS" as the
only available commitment.

>    o  Policy Domain: The domain for which an STS Policy is defined.
>       (For example, when sending mail to "[email-masked]", the policy
>       domain is "example.com".)

Perhaps this should mention that more generally this is the nexthop
domain for SMTP delivery, and when mail routing is preëmpted by
by explicit relays via local policy, the Policy domain is the
domain name of the explicit relay (prior to any MX lookups if
applicable).

>    o  Policy Authentication: Authentication of the STS policy retrieved
>       for a recipient domain by the sender.

This definition seems all too circular.  What does it actually mean?

> 2.  Related Technologies
> 
>    The DANE TLSA record [RFC7672] is similar, in that DANE is also
>    designed to upgrade opportunistic, unauthenticated encryption into
>    required, authenticated encryption.

Opportunistic DANE TLS upgrades unauthenticated encryption or even
cleartext delivery to downgrade-resistant authenticated TLS.  (Side
note, not for the draft, for actually non-opportunistic TLS see
Jim Fenton's REQUIRETLS proposal).  STS aims to do the same, but
without requiring TLS at the cost of losing some downgrade protection.

>  DANE requires DNSSEC [RFC4033]
>    for authentication; the mechanism described here instead relies on
>    certificate authorities (CAs) and does not require DNSSEC.  For a
>    thorough discussion of this trade-off, see the section _Security_
>    _Considerations_.

The Security Considerations section (once again this is not MarkDown)
will need to properly discuss the downgrade exposure of STS on first
contact, and this trade-off probably should be mentioned here up-front.

>    In addition, SMTP STS provides an optional report-only mode, enabling
>    soft deployments to detect policy failures.

It is easy to define a couple of new "certificate usage" code-points
for DANE that similarly signal "soft-fail" (with reporting).  Would
the group strongly support a draft along those lines?  I am not sure
that a merely "tamper-evident" operating mode is a good idea as a
persistent operating state, and I think that the ability to have
one or more (backup, i.e. worse preference) MX hosts without TLSA
records adequately addresses the need for incremental deployment.

> 3.  Policy Discovery
> 
>    To discover if a recipient domain implements MTA-STS, a sender need
>    only resolve a single TXT record.  To see if an updated policy is
>    available for a domain for which the sender has a previously cached
>    policy, the sender need only check the TXT record's version "id"
>    against the cached value.

Given earlier discussion on the list, while new "id" values can give
expedited signals to refresh the policy, it may be appropriate here,
(but perhaps later in the document as you see fit) to describe a
recommended approach to proactively refresh policies prior to their
pending expiration, this reduces the probability of "gaps" in policy
coverage if the remote HTTPS service is unavailable just as a policy
is expiring.

In practice (say in Postfix, if/when STS is implemented) I wouldn't
go looking through the cache for policies to refresh except when
delivering mail to the destination in question.  I don't want the
cache to become a roach motel for policies to destinations I never
again send mail to.  If communication with a destination ceases
completely, it is not unreasonable to let its STS policy simply
age out.  Google et. al. may of course choose indefinite data
retension (data retentiveness is Google's business), but for
SOHO and enterprise MTAs, the above may be more appropriate.

> 3.2.  MTA-STS Policies
> 
>    This JSON object contains the following key/value pairs:
> 
>    o  "version": (plain-text, required).  Currently only "STSv1" is
>       supported.
> 
>    o  "mode": (plain-text, required).  Either "enforce" or "report",
>       indicating the expected behavior of a sending MTA in the case of a
>       policy validation failure.
> 
>    o  "max_age": Max lifetime of the policy (plain-text non-negative
>       integer seconds, required).  Well-behaved clients SHOULD cache a
>       policy for up to this value from last policy fetch time.  To
>       mitigate the risks of attacks at policy refresh time, it is
>       expected that this value typically be in the range of weeks or
>       greater.

A more comprehensive mitigation for attacks "at policy refresh time"
would entail not just a long lifetime, but proactive refresh as mentioned
above.

>    o  "mx": MX patterns (list of plain-text MX match strings, required).
>       One or more patterns matching the expected MX for this domain.
>       For example, "["*.example.com", "*.example.net"]" indicates that
>       mail for this domain might be handled by any MX with a hostname at
>       "example.com" or "example.net".  Valid patterns can be either
>       hostname literals (e.g. "mx1.example.com") or wildcard matches, so
>       long as the wildcard occupies the full left-most label in the
>       pattern.  (Thus "*.example.com" is valid but "mx*.example.com" is
>       not.)

Here, as discussed on the list, serious consideration should be given
to changing the semantics from validating the MX hostname to specifying
the names allowed in the server's certificate.  This simplifies MX processing
(which remains unmodified) and merely changes the conditions under which an
MX host is considered suitably authenticated per the policy.

Which, for example, allows the MX hosts to share a single certificate
with the destination domain (and not the MX hostname) as its DNS SAN.
If the policy lists that (shared) name as what's expected in the certificate,
then authentication succeeds when the MX host's certificate matches one of
the allowed names.

It should be made clear that the names here are always in A-label form
and not U-label form (as they also are in DNS names in certificates).

Furthermore, I think that using "*.example.com" in what are essentially
(rfc6125) reference identifiers creates confusion with similar-looking, but
semantically distinct wildcard names in certificates.  My suggestion was
".example.com" for sub-domain matching, with the policy optionally specifying
whether only single-label prefixes are accepted, or whether in fact multi-label
prefixes are also valid.

>    An example JSON policy is as below:
> 
>                       {
>                         "version": "STSv1",
>                         "mode": "enforce",
>                         "mx": ["*.mail.example.com"],
>                         "max_age": 123456
>                       }

FWIW, I would have chosen something less fancy than JSON for
what is clearly a simple array of attribute/value pairs. ESMTP
already encodes such optional A/V pairs as space separated lists
of attr=value with xtext encoding as needed (it is not needed for
any plausible value of the above attributes).

We're not going to add a JSON decoder to the Postfix SMTP client,
but if this specification retains JSON, then the code that does
background policy retrieval will need to transform JSON into
something more friendly to traditional C-based MTA implementations.

> 4.  Policy Validation

Are we validating the policy or using the policy to authenticate
the MX host?  I think the name of this section is suboptimal.

>    When sending to an MX at a domain for which the sender has a valid
>    and non-expired SMTP MTA-STS policy, a sending MTA honoring SMTP STS
>    MUST validate:

s/validate/check/ or /ensure/.

>    1.  That the recipient MX matches the "mx" pattern from the recipient
>        domain's policy.

See above, perhaps "mx" becomes "san" and the check is deferred until
it is time to verify the host's certificate.

>    2.  That the recipient MX supports STARTTLS and offers a valid PKIX
>        based TLS certificate.

Here, it would be prudent to mention rfc6125, and be explicit about
the acceptable wildcard patterns in that certificate.  See, for example:

   https://tools.ietf.org/html/rfc7672#section-3.2.3

which limits certificate wildcards to the entire first label only.  I
would like to avoid supporting more general wildcards in new
specifications.

>    This section does not dictate the behavior of sending MTAs when
>    policies fail to validate; in particular, validation failures of
>    policies which specify "report" mode MUST NOT be interpreted as
>    delivery failures, as described in the section _Policy_
>    _Application_.

The first sentence is unfortunate, you are in fact specifying behaviour,
in the very next sentence.  It might be better to add a forward-reference
to a section that provides a detailed explanation and not start with a
disclaimer.

> 4.1.  MX Matching
> 
>    When delivering mail for the Policy Domain to a recipient MX host,
>    the sender validates the MX match against the "mx" pattern from the
>    applied policy.  The semantics for these patterns are those found in
>    section 6.4 of [RFC6125].

Assuming this text survives, replace:

 	validates the MX match against the "mx" pattern

with something like

	ensures that the MX host name is consistent with the "mx"
	property of the STS policy (only matching MX hosts are
	used in delivery attempts).

The reference to rfc6125 is rather unfortunate here, since it defines
semantics for presented identifiers, not reference identifiers.

> 4.2.  MX Certificate Validation
> 
>    The certificate presented by the receiving MX MUST be valid for the
>    MX hostname and chain to a root CA that is trusted by the sending
>    MTA.  The certificate MUST have a CN or SAN matching the MX hostname
>    (as described in [RFC6125]) and be non-expired.

Here, if the proposal to switch from "mx" to "san" is taken up, the
peer certificate is no longer restricted to authenticate the MX hostname,
rather, one its presented identifiers needs to match one of the reference
identifiers fro the "san" policy attribute.  Either way some discussion
is appropriate of how to perform matching when both the reference and
the presented identifiers are "wildcards".

> 5.  Policy Application

This is an appropriate target for the afore-mentioned forward-reference.

>    When sending to an MX at a domain for which the sender has a valid,
>    non-expired STS policy, a sending MTA honoring SMTP STS applies the
>    result of a policy validation one of two ways, depending on the value
>    of the policy "mode" field:
> 
>    1.  "report": In this mode, sending MTAs merely send a report (as
>        described in the TLSRPT specification (TODO: add ref)) indicating
>        policy application failures.
> 
>    2.  "enforce": In this mode, sending MTAs treat STS policy failures
>        as a mail delivery error, and MUST NOT deliver the message to
>        this host.

We should not confuse "delivery error" with "authentication failure".
When one MX host fails authentication, the next MX host should be
tried.  And, I think it should be mentioned that if all the MX
hosts (that the sender is willing to try) fail authentication, the
message should be deferred, not bounced.

>    When a message fails to deliver due to an "enforce" policy, a
>    compliant MTA MUST check for the presence of an updated policy at the
>    Policy Domain before permanently failing to deliver the message.
>    This allows implementing domains to update long-lived policies on the
>    fly.

This seems to suggest the contrary, i.e. that it might be appropriate
to bounce on policy failure when a more fresh policy still fails.
However certificate problems (expiration most typically) are transient,
and a receiving system operator should/may notice the problem before
outstanding messages expire and bounce.  So I would urge implementors
to queue, rather than bounce, on authentication failure.

> 5.1.  MX Preference

This section would go if a switch from "mx" to "san" takes place.

> 5.2.  Policy Application Control Flow
> 
>    An example control flow for a compliant sender consists of the
>    following steps:

Step 0:  If the sending MTA is DANE-capable, the destination is
DNSSEC signed, and one or more of the MX hosts have DANE TLSA
records, then DANE TLSA preempts STS (more downgrade-resistant,
works on first contact, ...).

This is another reason to avoid STS-based MX filtering, with DNSSEC
signed destinations the security of the MX records is sufficiently
established, and we need to be able to proceed with DANE MX by MX,
using STS policy only for MX hosts with no TLSA records.

>    1.  Check for a cached policy whose time-since-fetch has not exceeded
>        its "max_age".  If none exists, attempt to fetch a new policy.
>        (Optionally, sending MTAs may unconditionally check for a new
>        policy at this step.)

Is "attempt to fetch" well understood at this point?  The attempt only
happens if the DNS TXT record is in place...

>    2.  Filter candidate MXs against the current policy.

See "san" vs. "mx" issue above.  Also proceed with non-STS delivery
absent any policy.

>    3.  If no candidate MXs are valid and the policy mode is "enforce",
>        temporarily fail the message.  (Otherwise, generate a failure
>        report but deliver as though MTA STS were not implemented.)

Ditto.

>    4.  For each candidate MX, in order of MX priority, attempt to
>        deliver the message, enforcing STARTTLS and the MX host's PKIX
>        certificate validation.

Well, no so much enforcing as performing, authentication may be allowed
to fail in "report" mode.  And of course only if there is an STS policy
to use.

>    5.  Upon message retries, a message MAY be permanently failed
>        following first checking for the presence of a new policy (as
>        indicated by the "id" field in the "mta-sts" TXT record).

I think this is a mistake.  Please do not turn transient errors into
permanent failures.

> 6.1.  Policy Updates
> 
>    Updating the policy requires that the owner make changes in two
>    places: the "mta-sts" TXT record in the Policy Domain's DNS zone and
>    at the corresponding HTTPS endpoint.  In the case where the HTTPS
>    endpoint has been updated but the TXT record has not yet been,
>    senders will not know there is a new policy released and may thus
>    continue to use old, previously cached versions.  Recipients should
>    thus expect a policy will continue to be used by senders until both
>    the HTTPS and TXT endpoints are updated and the TXT record's TTL has
>    passed.

The lifetime could be longer.  Some MTAs may initiate *background* refresh
of unexpired policies after the DNS TXT record is found to have changed,
which may not happen until the first message to the destination is sent
after that change, and *that* message may well go out based on the already
cached policy while the refresh is in process.  If the policy no longer
matches reality, the message may be deferred, and would perhaps succeed
on retry with a more current policy.

So the TXT record will not guarantee refresh in any particular timeframe.
If no mail is sent to the destination, the policy may expire unused despite
the TXT record change.

> 8.  Security Considerations
> 
>    Since we use DNS TXT records for policy discovery, an attacker who is
>    able to block DNS responses can suppress the discovery of an STS
>    Policy, making the Policy Domain appear not to have an STS Policy.
>    The sender policy cache is designed to resist this attack.

Well, not "resist" so much as reduce the effectiveness, since it will
now only be effective on first contact, or perhaps when no mail is sent
to the destination for a long time and the cached policy expired.

>    We additionally consider the Denial of Service risk posed by an
>    attacker who can modify the DNS records for a victim domain.  Absent
>    SMTP STS, such an attacker can cause a sending MTA to cache invalid
>    MX records for a long TTL.  With SMTP STS, the attacker can
>    additionally advertise a new, long-"max_age" SMTP STS policy with
>    "mx" constraints that validate the malicious MX record, causing
>    senders to cache the policy and refuse to deliver messages once the
>    victim has resecured the MX records.

Many DNS resolvers have sensible upper-bounds on record TTLs.  It the
attacker can obtain a certificate for the victim domain, they may
indeed inject a long-lived policy, but the TXT record affords the
victim the opportunity of recovery.  This paragraph needs work.

Finally, some discussion is appropriate of the fact that given weaker
downgrade-resistance of STS viz. DANE, implementations that support
both should apply DANE first and STS only in its absence.  Indeed with
the MX RRset validated via DNSSEC the "mx" policy element is not really
needed to prevent MX record forgery, however that depends on the outcome
of the "mx" vs. "san" discussion.

There should probably be a recommendation that sending systems implement
DANE in addition to STS.  It is much easier to use a validating resolver
than to sign one's own domain, and so the barrier to option of outbound
DANE is significantly lower.  I'll have some additional implementation
news to report shortly...

> 10.1.  Example 1
> 
>    The owner of "example.com" wishes to begin using STS with a policy
>    that will solicit reports from receivers without affecting how the
>    messages are processed, in order to verify the identity of MXs that
>    handle mail for "example.com", confirm that TLS is correctly used,
>    and ensure that certificates presented by the recipient MX validate.
> 
>    STS policy indicator TXT RR:
> 
>         mta-sts.example.com.  IN TXT "v=STSv1; id=20160831085700Z;"
> 
>    STS Policy JSON served as the response body at [1]
> 
>               {
>                 "version": "STSv1",
>                 "mode": "report",
>                 "mx": ["mx1.example.com", "mx2.example.com"],
>                 "max_age": 123456
>               }

Note, the "max_age" here is barely over a day, which is not consistent with
the recommended policy lifetimes.  Even "report" policies should probably
have better downgrade protection through longer lifetimes (say a week or more).

> 11.  Appendix 2: Message delivery pseudocode
> 
>    Below is pseudocode demonstrating the logic of a complaint sending
>    MTA.  This implements the "two-pass" approach, first attempting
>    delivery with a newly fetched policy (if present) before falling back
>    to a cached policy (if present).

Should that be "complaint" or "compliant"? :-)  I would expect that
sane implementations will use cached policies first, and only both
refreshes based on TXT record changes or refresh timers, with updates
in the background.  Synchronous updates of policy at message delivery
time are exceedingly unappealing at least to me.

> func certMatches(connection, mx) {
>   // Return if the server certificate from "connection" matches the "mx" host.

This could use a detailed discussion of what "matches" means, or a
back-reference to a section that does.  Covering wildcard use in
either or both of the reference and presented identifiers, and
possible additional text if "mx" becomes "san".

> func getMxsForPolicy(domain, policy) {
>   // Sort the MXs by priority, filtering out those which are invalid according
>   // to "policy".
> }

[ "mx" vs. "san" ]

> func tryGetNewPolicy(domain) {
>   // Check for an MTA STS TXT record for "domain" in DNS, and return the
>   // indicated policy (or a local cache of the unvalidated policy).
> }

The DNS lookup may succeed, and the HTTPS lookup may tempfail, what
happens in that case?  What happens with an authenticated 404 HTTPS
response?  Let's avoid "unvalidated" here, or else avoid its use
in the context of "peer authentication".

> func cachePolicy(domain, policy) {
>   // Store "policy" as the cached policy for "domain".
> }

Along with the policy one should generally store the time
at which it was last retrieved, and the time of any unsuccessful
refresh attempts since then.  This supports both eventual 
expiration, and proactive refresh, with multiple retries, as
the policy approaches expiration.

> func tryMxAccordingTo(message, mx, policy) {
>   connection := connect(mx)
>   if !connection {
>     return false  // Can't connect to the MX so it's not an STS error.
>   }
>   status := !(tryStartTls(mx, &connection) && certMatches(connection, mx))
>   status = true

What's happening with "status" here?  I think the first assignment goes...

>   if !tryStartTls(mx, &connection) {
>     status = false
>     reportError(E_NO_VALID_TLS)
>   } else if certMatches(connection, mx) {

Missing negation?

>     status = false
>     reportError(E_CERT_MISMATCH)
>   }
>   if status || !isEnforce(policy) {
>     return tryDeliverMail(connection, message)

There are potential complications when an MX host
accepts a proper subset of the envelope recipients
and tempfails the rest, or fails for reasons unrelated
to policy, ... So a simple boolean here is not enough.
Delivery to backup MX hosts continues so long as
recipients that are neither delivered nor permanently
rejected remain.  STS policy failure is just one way
that (all the) recipients may remain unresolved.

>   }
>   return false
> }
> 
> func tryWithPolicy(message, domain, policy) {
>   mxes := getMxesForPolicy(domain, policy)
>   if mxs is empty {
>     reportError(E_NO_VALID_MXES)
>   }
>   for mx in mxes {
>     if tryMxAccordingTo(message, mx, policy) {
>       return true
>     }
>   }
>   return false
> }
> 
> func handleMessage(message) {
>   domain := ... // domain part after '@' from recipient
>   oldPolicy := tryGetCachedPolicy(domain)
>   newPolicy := tryGetNewPolicy(domain)

In practice, the cached policie's DNS id will be compared with
the current DNS value and if identical, no new policy will be
fetched.  If different, a new policy should be fetched, but
perhaps in the backround, with delivery continuing per the
cached policy.

>   if newPolicy {
>     cachePolicy(domain, newPolicy)
>     oldPolicy = newPolicy
>   }
>   if oldPolicy {
>     return tryWithPolicy(message, oldPolicy)
>   }
>   // There is no policy or there's a new policy that did not work.
>   // Try to deliver the message normally (i.e. without STS).
> }

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 22 Mar 2017 13:39:54 +0100

Thanks, Viktor!

Some comments inline, of course. ;)

> take my word for it, check).

(This is just some mistake in our markdown->xml transformation. Beats me,
but good catch.)

> domain name of the explicit relay (prior to any MX lookups if

We mention this explicitly in section 3.4.

> contact, and this trade-off probably should be mentioned here up-front.

We mention this (briefly) already, but maybe don't do it justice. In
particular, while we say that "[t]he sender policy cache is designed to
resist this attack," we don't call out explicitly the implied benefit of
longer max_ages and longer caching.

> records adequately addresses the need for incremental deployment.

Agreed. It's a difference from DANE (necessitated in part by the fact that
DANE policies are per-MX rather than, as with STS, per-domain, so DANE has
a different mechanism to allow incremental rollouts). I would not suggest
it's better or worse, but supporting soft failures in this matter seems the
easiest way to support testing a policy in the STS model, no?

> is expiring

Agreed.

> then authentication succeeds when the MX host's certificate matches one of

That's interesting. I think it's not actually that big a change--we just
get rid of the MX host filtering and instead just apply the logic to
validation.

Downsides:

1. Misconfigurations _may_ be less obvious without connecting to the SMTP
server. That is, today, you can spot some kinds of misconfigurations by
merely looking at the DNS (so for example my test tool here
http://sts.x.af0.net/ first looks at  DNS, and only then tries SMTP
connections).
2. As you say, it requires some changes to server certificate validation,
but not much.

I don't consider #1 compelling. So this seems fairly reasonable to me, but
I will let others chime in.

I've been quite hesitant to entertain any "business logic" changes at this
point if we could avoid it, since we already have some code written, but
like I said, I don't think this is actually a very large change.

> and not U-label form (as they also are in DNS names in certificates).

This is specified in 3.2.

> whether only single-label prefixes are accepted, or whether in fact

Well, I think our matching is a subset of the matching defined in RFC6125
section 6.4.3. We could specify that we support the full policy; it seemed
worth a simplification (i.e. we don't support 'something*.domain.com', only
'*.domain.com') to make implementation easier, but at cost of a semantic
difference. If we get rid of the wildcard, I suppose it is indeed more
obvious that we're just doing only suffix matching. Was that your point?

> any plausible value of the above attributes).

I seem to recall that we started with simple key-value pairs and moved to
JSON because people variously seemed to think this was easier (since
parsing libraries are common). I would also consider the vague possibility
that in future iterations we wish to add fields.

De novo, I myself have no real opinion here, because certainly either work,
but of course I'm loath to make changes again. I'd appreciate more feedback
from more readers, though, as these style discussions are always a bit
subjective. I assume that for Postfix policy fetching is a background
process anyway, though, so it isn't (I would hope) too big an
implementation difference for you, right?

> would like to avoid supporting more general wildcards in new

We specify this in 4.1 (as you discovered below), but maybe that's too
late.

> to a section that provides a detailed explanation and not start with a

Heh. Thanks. ;)

> semantics for presented identifiers, not reference identifiers.

If this field is used to validate the server certificate (and not the MX
hostnames) as you suggested above, that would entail validating the
presented identifier, which I think resolves your comment.

> the presented identifiers are "wildcards".

Ah, good point--this is a bit of additional complexity implied by your
suggested change.

One option would be to merely disallow wildcards in the "mx" (or "san")
field. Assuming people do not have full (non-wildcarded) hostnames in their
server certificates, this should work fine. (IOW, for Google, we would
change "*.aspmx.l.google.com" to "mail.google.com" or some other suitable
name.) Upside: easy to use existing validation code to check (e.g.
https://golang.org/src/crypto/tls/common.go?s=12153:20652#L426). Downside:
I guess this would be cumbersome if someone for some reason has a fully
specified hostname as the CN/SAN in their server cert.

Another: Specify our own matching rules for wildcards on both identifiers.
It's not really that complicated, but I don't favor making people write
this and possibly make mistakes.

> to queue, rather than bounce, on authentication failure.

Rather, the point of this was to encourage implemenors to _not_ bounce
until at least updating the policy once, not to encourage them to bounce
_after_ such an update. So I think we agree, but the wording may be
suboptimal.

> using STS policy only for MX hosts with no TLSA records.

With the suggested change to use STS only to validate the server
certificates and not to do MX filtering, this is obviated, no? I don't
really favor specifying whether senders should do an AND or an OR in
applying DANE and STS when both are present, and with that change it no
longer implies any incompatibilities in MX selection.

> I think this is a mistake.  Please do not turn transient errors into

See above; the intent is not to specify that this should be a perm-fail,
but rather that one should not perm-fail without first checking for a new
policy. I agree on the wording, however.

> news to report shortly...

I'm good with putting that here (unlike my objection above); it seems
appropriate to note the tradeoffs in Security Considerations in some form.

> have better downgrade protection through longer lifetimes (say a week or

I think that max_age was chosen because of the sequential nature of the
numbers and not its value. ;) But point taken.

> time are exceedingly unappealing at least to me.

It's presented as such here only for ease of following the logic, not to
suggest that one should prefer a synchronous fetch.

> possible additional text if "mx" becomes "san".

As discussed above, I'm not a huge fan of doing
wildcards-on-both-sides...but let's conclude on that discussion first.

> What's happening with "status" here?  I think the first assignment goes...

Man, who wrote this code? ;)

> that (all the) recipients may remain unresolved.

Well, the goal is not to implement a complete SMTP server here in
pseudocode. ;)

For clarity I'd probably keep that elided, unless you think it introduces
confusion.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Mar 2017 15:18:30 -0400

> On Mar 22, 2017, at 8:39 AM, Daniel Margolis <[email-masked]> wrote:
> 

I think that the *terminology* section needs a reasonably complete
defintion, or at least a forward-reference.

> particular, while we say that "[t]he sender policy cache is designed
> to resist this attack," we don't call out explicitly the implied benefit
> of longer max_ages and longer caching.

And I think don't give sufficient coverage to MiTM exposure on
first-contact.

> Agreed. It's a difference from DANE (necessitated in part by the fact
> that DANE policies are per-MX rather than, as with STS, per-domain,
> so DANE has a different mechanism to allow incremental rollouts). I
> would not suggest it's better or worse, but supporting soft failures
> in this matter seems the easiest way to support testing a policy in
> the STS model, no?

Well, my question is whether the group wants to see additional
"certificate usage" code-points in DANE to support "report"
mode, not a suggestion to change the STS specification...  The
STS "report" mode is roughly all one can do, though of course
a more complex policy could express per-MX "enforce" bits, but
I think that would be a mistake for STS.

So if anyone has definite views on adding "soft fail" for DANE TLSA,
please speak up!
 
> get rid of the MX host filtering and instead just apply the logic to

Correct.
 
> difference. If we get rid of the wildcard, I suppose it is indeed more obvious
> that we're just doing only suffix matching. Was that your point?

Observe that with the current "mx" constraints these are compared only
with the literal MX host names, which are in turn (as literals) compared
with the certificate.  So the literal MX hostname is on the one-hand
compared against the STS policy (with potential wildcards) and on the other
hand the server certificate (with potential wildcards).

If there's a switch to "san", the comparison of "san" is directly against the
certificate, which introduces the possibility of wildcard-to-wildcard
comparison.

Thus, my point is that there are two type of names with potential
wildcards in this context.  There are DNS SAN entries in certificates
(presented identifiers) whose semantics are (partly) defined in RFC6125.
RFC6125 leaves room for application-specific behaviour with respect to CN-ID
and exactly which kinds of wild-cards, if any, are supported.  Then
there are also "reference identifiers" which RFC6125 does not envision
as anything other than plain literals.

This draft casually treats "mx" constraints as though they were presented
identifiers from the certificate certificate, and I think this could lead
to user confusion, but this could be explained by noting that both kinds
of patterns are compared against the MX hostname, and are then subject
to similar interpretation.

If however, the design is switched to "san" constraints, then there
should be more care to distinguish "reference identifiers" from
"presented identifiers".

We tried to avoid confusion in Postfix by using ".example.com" as the
wildcard form for reference identifiers.  So in the "san" design there
would need to be some discussion of how to match reference identifiers
against presented identifiers when the reference identifier is a wildcard
form and the presented identifier may also be a wildcard form.

>> what is clearly a simple array of attribute/value pairs.
> 
> I seem to recall that we started with simple key-value pairs and
> moved to JSON because people variously seemed to think this was
> easier (since parsing libraries are common). I would also consider
> the vague possibility that in future iterations we wish to add
> fields.

Which a good reason to have name/value pairs rather than a simple
ordered list of values with per-index semantics, but perhaps the
instinct to choose JSON is over-engineering, and forces MTAs to
include novel (to the MTA SMTP stack) technologies.  A much
simpler (and already common in MTAs) encoding would certainly
suffice.  I realize it is late in the evolution of the spec, but
perhaps there is still time to reconsider.

This is not critical, I'd likely have the transformation from
JSON to something more natural happen in the software that imports
data into the policy cache, so that the cache is more MTA friendly.
Even if policy processing is out of the main MTA executable (Postfix
is not monolithic like Sendmail or Exim) there is still a new JSON
library dependency on the MTA package as a whole, and MTAs are part
of base-system images for various operating system distributions
(Postfix is part of "base" in NetBSD for example).  So I really
do think that JSON should be reconsidered.

> We specify this in 4.1 (as you discovered below), but maybe that's too late.

Repetition is good, not everyone reads each RFC from cover to cover.
Try to make each section as self-contained as reasonably possible,
or provide references to other relevant content where applicable.
 
> If this field is used to validate the server certificate (and not
> the MX hostnames) as you suggested above, that would entail validating
> the presented identifier, which I think resolves your comment.

So this draft should probably align with RFC7672 in permitting only
full-label wildcards (*.example.com) and not partial-label wildcards
(such as mail*.example.com) in presented identifiers of servers that
publish STS policy.  Separately, you should define the allowed wildcard
forms for ("mx" or "san") and perhaps even consider allowing multi-label
matches for those (another policy field?).  Some domains have MX hosts
like:

	mx01.<site1>.example.com
	mx02.<site1>.example.com
	mx01.<site2>.example.com
	...

and might not want to "freeze" all the sites in the policy.  They
may be content with ".example.com" covering more than one label.

> Ah, good point--this is a bit of additional complexity implied by your

As explained above, if there's a switch to "san", the comparison of "san"
values is directly against the certificate, which introduces the possibility
of wildcard-to-wildcard comparison.

> field.

That's probably too restrictive.  If anything, I'd be more supportive
in disallowing wildcards in the certificate!  Certificate wildcards
encourage poor practices (all eggs in one basket when the shared
certificate fails, all the MX hosts fail, and wildcard certs
enable redirection attacks between services that share the same
certificate and application protocol, say HTTP).

> Another: Specify our own matching rules for wildcards on both
> identifiers. It's not really that complicated, but I don't favor
> making people write this and possibly make mistakes.

[ FWIW, already implemented in Postfix,
  http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match ]

> _after_ such an update. So I think we agree, but the wording may be

Yes, please clarify.

> certificates and not to do MX filtering, this is obviated, no? I
> don't really favor specifying whether senders should do an AND or
> an OR in applying DANE and STS when both are present, and with
> that change it no longer implies any incompatibilities in MX selection.

Well, this text goes away, and the decision moves down to the TLS
handshake step, when deciding whether the host is adequately
authenticated.  I would argue that an STS policy of "report"
should not preempt a non-soft-fail DANE policy.

Note that DANE has one, perhaps non-obvious, "feature" in this space.
When TLSA records are present, but are all "unusable", authentication
is not enforced, but STARTTLS is still required.  Thus, while the STS
"report" mode also tolerates cleartext transmission, DANE TLSA with
"unusable" TLSA records does not.  Here too, I would not like to see
STS "report" downgrade DANE to cleartext when both are published.

Perhaps this draft need not be fully prescriptive about how the
two mechanisms interact, but raising the issue is warranted, so
that implementors make sensible decisions, and/or provide users
with appropriate controls.

> I think that max_age was chosen because of the sequential nature of
> the numbers and not its value. ;) But point taken.

Add another digit or two, and you're set.  An appealing looking number
would be 90 days or 7776000 seconds.

>> Should that be "complaint" or "compliant"? :-)

I hope you'll fix the typo.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 22 Mar 2017 20:50:26 +0100

To be clear, I didn't reply to comments I thought were minor or needed no
response. So I do agree on fixing the typo. ;)

> to similar interpretation.

Right. I think it's _fairly_ simple as-is, since you're only ever matching
against a hostname. More on this below.

> do think that JSON should be reconsidered.

Point taken. In our implementation it's all rapidly converted to
protobuffers, anyway.

But I'd appreciate feedback from the wider peanut gallery here, too.
Parsing key/value pairs isn't hard, but do people prefer that (is there a
standard parser?) versus taking a dependency on an existing JSON lib? Beats
me--happy to hear from n>1 on it, though of course your voice is heavily
weighted, Viktor. ;)

> may be content with ".example.com" covering more than one label.

Right, as-is we did in fact specify only full-label and only left-most. I
am unconvinced there are many cases where someone has "mx$n.$
siten.example.com" and cannot be content with "*.example.com"--if that's
insufficient for them (because the example.com zone contains untrusted
hosts), perhaps the MXs should be at  "mail.example.com"; at risk of
inducing necessary DNS changes, it seems worth it to preserve simplicity in
the tricky matching rules.

>   http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match ]

Yes, so you effectively limit it to wildcards in the leftmost label (if
any). Which seems likely to work for anyone, and the matching is fairly
easy.

Yet it still means that instead of being able to merely validate against a
hostname as in the Go API I linked to, implementors have to write _some_
heretofore nonexistent matching logic. If we restrict it to RFC 7672's
section 3.2.3 logic, it's equivalent to the per-MX logic we already
specified (I think), so no harder for implementors (as long as their TLS
library exposes that, which it ought to). Anything more complex seems like
it could lead to bugs.

> STS "report" downgrade DANE to cleartext when both are published.

I think that would be a buggy implementation! It doesn't make sense to me
that someone who implements both would treat it as an OR, especially if STS
is in "report" mode. So it's fair to call this out, certainly, but I think
the concern is (hopefully) unwarranted--the point of STS is most decidedly
not to override any existing TLSA records, nor would that make any sense.

> with appropriate controls.

I'm happy to suggest people not allow STS to override DANE.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 22 Mar 2017 20:28:34 +0000

On 22/03/17 19:50, Daniel Margolis wrote:
> standard parser?) versus taking a dependency on an existing JSON lib?

>From the Exim developer's point of view, I much prefer name/value pairs
since we have existing code doing that.  We don't have any JSON and
having to add some would be one more barrier against implementing STS.
-- 
Cheers,
  Jeremy

---

From: Daniel Margolis <[email-masked]>
Date: Fri, 24 Mar 2017 18:00:23 +0100

> If no mail is sent to the destination, the policy may expire unused despite

I'm no longer sure what this section was meant to convey.

If I switch my policy from policy A to policy B at time t1, anyone may
nonetheless continue to use policy A up until t1 + max_age_A, but no
longer, regardless of when they fetched it. Policies *must not* be used
longer than max_age past the last time they were actually being served.

The DNS TTL doesn't really come into it. I think we added this section to
try to clarify a different case (not relating to max_age): when publishing
a new policy (B), people may continue to use A *and not try to get B even
on failure* for the duration of the TTL (because checking the TXT record
will not indicate that there is in fact a new policy).

So I will clarify that part.

On Wed, Mar 22, 2017 at 6:04 AM, Viktor Dukhovni <[email-masked]>
wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: David Illsley <[email-masked]>
Date: Sun, 26 Mar 2017 20:56:36 +0100

On Wed, Mar 22, 2017 at 12:39 PM, Daniel Margolis <[email-masked]>
wrote:
<snip>

> I will let others chime in.
FWIW, I'm nervous about the idea of introducing non-standard server cert
validation. It's not that complex, but certainly unexpected to people with
experience deploying HTTPS. It also looks like some of the rationale is to
enable reuse of website keys/certs, which while valid probably isn't
desirable because of the risks of reusing the same keys for multiple
purposes/with multiple software configurations (as was demonstrated in the
DROWN paper https://drownattack.com/)

On Wed, Mar 22, 2017 at 12:39 PM, Daniel Margolis <[email-masked]>
wrote:

> worth a simplification (i.e. we don't support 'something*.domain.com',
> only '*.domain.com') to make implementation easier, but at cost of a
> semantic difference. If we get rid of the wildcard, I suppose it is indeed
> more obvious that we're just doing only suffix matching. Was that your
> point?
>
>
> De novo, I myself have no real opinion here, because certainly either
> work, but of course I'm loath to make changes again. I'd appreciate more
> feedback from more readers, though, as these style discussions are always a
> bit subjective. I assume that for Postfix policy fetching is a background
> https://golang.org/src/crypto/tls/common.go?s=12153:20652#L426).
> Downside: I guess this would be cumbersome if someone for some reason has a
> fully specified hostname as the CN/SAN in their server cert.
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Mar 2017 16:38:05 -0400

> On Mar 26, 2017, at 3:56 PM, David Illsley <[email-masked]> wrote:
> 
>> That's interesting. I think it's not actually that big a change--we just get rid of the MX host filtering and instead just apply the logic to validation. 
>> 
>> Downsides:
>> 
>> 1. Misconfigurations _may_ be less obvious without connecting to
>> the SMTP server. That is, today, you can spot some kinds of
>> misconfigurations by merely looking at the DNS (so for example
>> my test tool here http://sts.x.af0.net/ first looks at  DNS, and
>> only then tries SMTP connections).
>> 
>> 2. As you say, it requires some changes to server certificate
>> validation, but not much. 
>> 
>> I don't consider #1 compelling. So this seems fairly reasonable
>> to me, but I will let others chime in.
> 
> FWIW, I'm nervous about the idea of introducing non-standard
> server cert validation. It's not that complex, but certainly
> unexpected to people with experience deploying HTTPS.

Well, TLS for MTA-to-MTA SMTP *is* very different from TLS
for HTTPS.  Reasoning by analogy with HTTPS often leads to
incorrect conclusions.  So, from my perspective, looking more
obviously different from HTTPS is a feature. :-)

> It also looks like some of the rationale is to enable reuse of
> website keys/certs,

No, not *reuse*, rather compatibility with pre-STS practice.
Because MX records are untrusted absent DNSSEC, there is an
existing practice to employ the recipient domain, rather than
the MX hostname, as the DNS name in the certificate.  This
is one with "UCC" certificates.

I'm one of the early instigators of this practice.  I introduced
it with Postfix "secure" TLS policy, and later recommended it to
Microsoft for implementation in Exchange 2007.

   http://www.postfix.org/postconf.5.html#smtp_tls_security_level
   http://www.postfix.org/TLS_README.html#client_tls_limits
   https://technet.microsoft.com/en-us/library/bb266978(v=exchg.80).aspx

So the idea is not "sharing", but compatibility with existing practice,
as some domains may employ both STS and explicit TLS peering with
business partners.  The main motivation for the proposal is to get
out of the way of MX host selection and constrain just certificate
matching.

> which while valid probably isn't desirable because of the risks of
> reusing the same keys for multiple purposes/with multiple software
> configurations (as was demonstrated in the DROWN paper
> https://drownattack.com/

Ironic you mention DROWN:

    DROWN: Breaking TLS using SSLv2

    Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky,
    Nadia Heninger, Maik Dankel, Jens Steube5, Luke Valenta,
    David Adrian, J. Alex Halderman, Viktor Dukhovni[7],
    Emilia Käsper, Shaanan Cohney, Susanne Engels,
    Christof Paar and Yuval Shavitt

    [7] Two Sigma/OpenSSL

For the record, I do not recommend sharing a single
certificate among multiple MX hosts, or between email
and other services.  In addition to DROWN, (which really
helped drive SSLv2 support out of the ecosystem).

The primary reason to avoid sharing certificates among MX
hosts is to avoid a single point of failure.  Operational
errors in shared certificate/key rotation tend to break
all the MX hosts at once.  The operational issue dwarfs
DROWN in its significance.

-- 
	Viktor.

---

From: Alberto Bertogli <[email-masked]>
Date: Sun, 26 Mar 2017 21:52:18 +0100

Hi!  Not sure if it's worth much, but my 0.7 cents inline :)

> get rid of the MX host filtering and instead just apply the logic to

This would make certificate validation differ from the way it's commonly
done, where the check is against the name used to connect to the server.

I think that would be a mistake.

Certificates are already non trivial to deploy and check, and making
validation work in an unusual way introduces complexity in coding in
some cases, (maybe not for postfix, of course, but most high level
libraries such as Python's or Go's make this more difficult) in a very
sensitive and delicate area.

It also makes deployment and checks more complex, as wildcard
certificates and mentions in the policy don't work in a somewhat
unexpected way (I don't think most folks expect wildcards to be matched
via string comparison).

If it's the filtering that is too much additional complexity, an
alternative would be to consider the "mx" field in the policy as an
alternative source for the mail servers list (no wildcards allowed in
that case, obviously).

This has, I think, the same security benefits of the list for filtering,
and may be easy to use in some cases. Deployment wise, it's probably not
as simple as the filtering, but not terribly more complex, and is easy
to understand and automate.

I'm not terribly convinced about it, but it could be an alternative to
filtering if it's an issue.

> subjective.

There are lots of advantages of using JSON for this. It is well defined,
standard and there are lots of well tested and widely used
implementations.

It is used widely, it's familiar to many people, and its shortcomings
(which are not few, admittedly) are well understood and documented.

It support rich types (such as lists), and common libraries already
handle difficult situations like non-ascii content, long integers,
multi-line strings, malformed/malicious input, etc.

Defining an ad-hoc key-value pair format may seem simpler in the short
term, but I think it's not worth it, as many things will have to be
decided an carefully designed (e.g. multi-line lists). Then parsers have
to be implemented with support for a variety of things, and care for
malicious input which is usually not trivial.

Thanks!
		Alberto

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Mar 2017 21:01:36 -0400

> On Mar 26, 2017, at 4:52 PM, Alberto Bertogli <[email-masked]> wrote:
> 

Sure JSON is used widely in all kinds of software, but NOT in MTAs,
and STS is for MTAs.

> multi-line strings, malformed/malicious input, etc.

Sure in Perl, Python, Go, ... but Sendmail, Qmail, Postfix and Exim
are in C, and already have code to handle ESMTP attr=value lists, and
don't currently use JSON.  The extra features of JSON you mention are
not needed for this specification, and over-engineering to use JSON
is IMHO not useful.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 27 Mar 2017 22:55:06 +0200

re MXs:

Right, I think a nonstandard MX list is actually worse than the disease it
cures. ;) But you are right to point out that there are multiple approaches
that confer similar security advantages.

To the matching point, I share the concern about people having to write
their own cert matching code, but I think there are a few arguments for it:

1. I believe if we restrict wildcards to the "full" leftmost label (i.e. *.
example.com is valid, but mail*.example.com or mail.*.example.com are not)
and we do the same in the certs (which RFC6125 seems to allow us to
define), wildcard matching is a simple "x ends with y or y ends with x"
comparison, so is in fact trivial to implement.

2. It seems (and I suspect this was part of Viktor's motivation) to match
nicely with https://tools.ietf.org/html/rfc7672#section-3.2.2, which if I
read it correctly leaves the door open to a certificate matching the
nexthop domain rather than the MX hostname; by requiring MX hostname
matches in STS we would break that behavior.

I think #2 is a pretty compelling point.

(FWIW, the more I think of it, Viktor, the less compelling I find the other
point about MX candidate traversal being unchanged, since I'm not sure it's
really a huge difference to say "this host doesn't match the MX pattern;
try the next candidate" as opposed to "this host's certificate doesn't
match the MX pattern..." It seems like both cases are quite similar, though
maybe in some implementations the code structure implies one to be easier
than the other?)

re JSON:

I think when you've reached the point that JSON-vs-key-value-pairs is the
main point of contention it's probably not a *bad* sign. ;)

I had the same feeling as Albert about using something with pre-existing
library support, which was really the main argument for JSON--and I think
since we've already implied a dependency on some HTTPS lib an additional
JSON lib seems not *too* serious. At the same time, it's true that
Postfix's typical deployments may often be likely to be concerned about
each additional library dependency, which is less on my mind here at Google.

This seems mostly like an issue of aesthetics (which is not to say it's
unimportant, but it seems less fundamental than the design questions we've
discussed in the past). If there aren't really strong objections I'd
probably keep JSON since we already have both code and published policies
in that format, but if there are strong objections, I think it's a trivial
matter for the early adopters to change.

---

From: Alberto Bertogli <[email-masked]>
Date: Thu, 30 Mar 2017 11:55:56 +0100

> comparison, so is in fact trivial to implement.

Agreed, but it still carries some hidden complexity.

For example, how does this interact with SNI? e.g what name would the
client pick to give to the server in the TLS negotiation?

> matches in STS we would break that behavior.

Yes, my reading from that reference is that the nexthop domain can be
used to match as well.

> I think #2 is a pretty compelling point.

It is definitely a point, but I'm not sure it's that compelling (sorry
Viktor!).

There's, AFAIK, no very clear and well defined way to do certificate
matching for MTA-to-MTA TLS connections, and this RFC is a chance to fix
that.

For better or worse, HTTPS is the most widely deployed TLS usage in the
world, and has gone through years of all kinds of production exposure.
The certificates are validated has been thoroughly reviewed and is well
documented and understood.

Differring from that, and adding complexity to how SMTP does TLS
validation based on a particular section of RFC 7672 which, as far as I
know (and please correct me if I'm wrong) is not widely deployed and
hasn't got nearly as much production exposure, seems to me to be risky,
and is IMHO not worth it.

Bringing SMTP certificate validation in line with how HTTPS does it
would not only simplify (some) implementations, but make deployments
easier, reduce the cognitive load and learning curve for folks running
their own servers, and benefit from all the existing analysis and also
the future improvements in the area (e.g. certificate revocation,
certificate transparency improvements, etc.).

Very few existing deployments would be affected, as I don't think many
are relying on using [DANE+certificate for the next hop but not the MX
name].

Note, in case it's not clear, that I'm not advocating for the removal of
the MX list from the policy, but to keep it as in the current draft
(i.e. use it as a filter mechanism, and then do TLS validation on the
resulting MX name).

All this said, I don't want to drag my point along or interfere with the
normal flow of things. I much appreciate your thoughtful replies, and if
you don't find my arguments convicing, I understand :)

Thanks a lot!
		Alberto

PS: As an example of a related RFC that is AFAIK not widely deployed,
and which I think most popular deployments violate, is RFC 7817 "Updated
TLS Server Identity Check Procedure for Email-Related Protocols".

It applies to POP3, IMAP and SMTP submission (excludes MTA-to-MTA), and
specifies that servers must have certificates not only for the host name
used to access them (e.g. imap.example.net) but also to the top level
domain used for email addresses (example.net in this case):
https://tools.ietf.org/html/rfc7817#section-6

Neither gmail.com, yahoo.com, live.com or outlook.com imap, pop3 or smtp
submission do this (but in fairness, hotmail.com does).

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Mar 2017 10:16:08 -0400

> On Mar 30, 2017, at 6:55 AM, Alberto Bertogli <[email-masked]> wrote:
> 

Always the MX hostname.  The server is however free to return its
default certificate.  While SNI makes some sense for multi-tenant
submission servers, it is of little use in MX hosting, where the
simplest hosting approach is to use the same MX hostname in the
MX records of all the tenant domains.

-- 
	Viktor.