[Uta] Last Call: <draft-ietf-uta-mta-sts-15.txt> (SMTP MTA Strict Transport Security (MTA-STS)) to Proposed Standard

[The IESG]

The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP MTA Strict Transport Security
(MTA-STS)'
<draft-ietf-uta-mta-sts-15.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
***@ietf.org mailing lists by 2018-04-23. Exceptionally, comments may be
sent to ***@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a
mechanism enabling mail service providers to declare their ability to
receive Transport Layer Security (TLS) secure SMTP connections, and
to specify whether sending SMTP servers should refuse to deliver to
MX hosts that do not offer TLS with a trusted server certificate.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ballot/

The following IPR Declarations may be related to this I-D:

https://datatracker.ietf.org/ipr/2776/

[Dave Cridland]

Since this was mentioned to me at IETF 101, I managed to find the time to
look it up and review. Several design decisions have left me confused; most
notably the notion of a call-out to HTTPS in the first place. Much of the
document is unclear to me, despite having a background of both Internet
Mail and the application of PKI in application protocols, and it appears to
willfully ignore prior art in this area.

1) A History Lesson

First, some history: In XMPP-land, we faced a similar issue with
large-scale providers (most notably Google) not wishing to host or manage
the certificates for their customers, alongside an assertion that customers
would not wish to provide their private keys to their provider. Despite the
strong evidence to the contrary in the case of HTTPS, the community
nevertheless developed POSH (RFC 7711), and did so in a protocol-neutral
way. In POSH, an entity fetches a well-known document from an HTTPS server
in order to securely obtain information with which to validate a
certificate by means other than building a traditional chain etc.

Notably, this was against a backdrop of CAs which were not free, and
generally quite expensive - this has changed markedly over the years since,
and I should note that POSH's support for self-signed certificates is
probably no longer relevant.

However, it surprises me that the MTA-STS draft does not appear to note
this prior art at all, and this makes me wonder whether it was even on the
radar.

Importantly, POSH was never deployed very heavily - I can find only one
deployment (and "most users opt to just give us the cert"). This was in
part because of Google's withdrawal from standards-based IM, which
liberated the community from having to support a use-case only Google
really felt important, and also the rise of free CAs, which avoided the
cost issue associated with traditional PKIX.

For reference, the XMPP community has a high penetration of DANE records
(around 10% of the self-selected group who test their servers through
community tooling) and a very high penetration of CA-signed certificates
(mostly Let's Encrypt).

2) HTTPS Call-out

Given the policy is essentially trust-on-first-use, it's not clear to me
why much of the STS policy cannot be transferred within SMTP itself,
perhaps in response to the EHLO issued after STARTTLS completes. This is
good enough for HTTPS's STS variant, and feels intuitively simpler for MTAs
to implement.

3) DNSSEC or not?

The MTA-STS problem is reasonably well-defined in the document - SMTP
servers often do host numerous domains, and unfortunately operating one's
own server has become a rarity, so domains are concentrated on a few
servers. STARTTLS is, as the abstract notes, theoretically susceptible to a
downgrade attack - but this does require either active MITM or some fairly
tight hoops to jump through to actually exploit.

The draft then goes on to compare the solution to DANE, and notes that
DNSSEC is not required with MTA-STS - "at a cost of risking malicious
downgrade attacks". These would be performed by DNS spoofing, which has a
known history of occurring. In any case, what is distinctly unclear to me
is whether MTA-STS without DNSSEC is materially different from RFC 7672
without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my immediate
question is whether it might therefore be good enough for at least some
cases of DANE.

I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record is
sufficient to mandate TLS - hence my question is whether an insecure TLSA
record stipulating a particular trust anchor and/or valid certificate
(PKIX-TA and PKIX-EE) might be sufficient to meet the same security
requirements here.

4) Wildcard on Wildcard Action.

It is deeply unfortunate that MTA-STS mandates a name match based on
dNSName SANs only. I would have thought that emulating an SRV, and matching
a corresponding sRVName, would be more useful - and overall, the idea that
a new matching algorithm has been included so as to match an "mx pattern"
to a dNSName wildcard just feels like an exploit waiting to happen. It
would feel considerably safer to do one of:

a) Make matches operate the same way as DANE, by being based on hashes of
SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's
approach of a certificate hash).
b) Make matches operate the same way as RFC 6125 (unreferenced, I note).
c) Both/either of the above.

I assume the logic behind allowing a wildcard-to-wildcard match is to allow
a Google user to simply specify ".googlemail.com" and ".l.google.com" as
their MX identity patterns; however it feels as though Google could simply
use a known name within the certificate for all their receiving MTAs,
irrespective of the DNS records involved. This, of course, presupposes that
the administrator of the mail domain somehow does not know the precise
names of the MTAs used in their own DNS records.

I further assume the logic in mandating matches against dNSName SANs is
because these are readily available; however sRVName SANs, by restricting
their use to a particular service, have the advantage that customers giving
these to their service provider might be deemed more acceptable.

5) Terminology and Nomenclature.

It is well-known that naming things remains the hardest problem in
technology.

However, this draft appears to have taken bold strides in demonstrating
that coming up with new names for things needn't be so challenging.

Take §7.1, for example, which dictates that the SNI extension MUST contain
the "MX hostname" - this latter term does not appear anywhere else in the
document. I'm going to guess that it means the RHS of the MX record, as
defined in RFC 7672 (and informative reference), which is the same as RFC
7672. "MX host", which appears once in RFC 5321, also appears elsewhere in
this draft, including in §1.1, where it is in this definition:

o MTA-STS Policy: A commitment by the Policy Domain to support PKIX
[RFC5280] authenticated TLS for the specified MX hosts.

Impressively, by my reading, the commitment is for the Policy Domain to
support PKIX for all SMTP; and not just for specified hosts.

Using more common - and more uniform - terminology would be of huge
benefit: "Sending MTA", "Receiving MTA", and so on are well-known terms. If
a new term is needed, please do define it. If you mean to use terms from
other RFCs, these need to be Normative References and noted in the
Terminology section.

6) Reference Identifiers and derivation.

RFC 6125 provides a slew of terminology and best practise - from the same
UTA working group, as I recall. RFC 7672 also provides terminology and much
behaviour.

It feels as though this draft should at least attempt to use the same
terminology, and ideally the same behaviour, as RFC 7672 (and RFC 6125).

This is particularly noticeable in the difference between the reference
identifiers used within RFC 7672 (and used within the SNI discussed there)
compared with this draft, see for example this draft's §7.1, compared with
RFC 7672 §8.1

7) Trust Anchors

RFC 7672 suggests that MTAs cannot rely on a set of common trust anchors,
in Section 1.3.4. While I'm not actually convinced this is really the case,
I'm finding it odd that on the one hand, we have a consensus
standards-track document that makes this assertion, yet on the other this
draft makes - implicitly - the opposite assertion.

It would be useful to understand if circumstances have changed.

Dave.

[Viktor Dukhovni]

Post by Dave Cridland
For reference, the XMPP community has a high penetration of DANE records
(around 10% of the self-selected group who test their servers through
community tooling) and a very high penetration of CA-signed certificates
(mostly Let's Encrypt).

There's no comparable uptake of DANE in email and IMO there's little if
any prospect of that changing in the immediate future.

There are at least 205,000 domains whose MX hosts have TLSA records.
I expect around another 300k domains (hosted by a provider that's
in the process of adding support) in the next month or two. Among
the existing adopters are:

* web.de / gmx.de with millions of users
* comcast.net with millions of users
* posteo.de and mailbox.org with customers who want email security
* domeneshop.no and transip.nl hosting over ~150k customer domains.

Postfix and Exim have DANE support as do MailChannels and Halon.
Cisco just announced DANE support in the Beta of the next release
of SMTP for their SMTP gateway (formerly IronPort).

So if your "immediate future" horizon is ~6 months, then sure, adoption
will remain light on *that* timescale, but there's a good chance of much
broader support in 2019/2020, perhaps even by more of the same providers
behind STS.

[Viktor Dukhovni]

Post by Dave Cridland
2) HTTPS Call-out
Given the policy is essentially trust-on-first-use, it's not clear to me why much of the STS policy cannot be transferred within SMTP itself, perhaps in response to the EHLO issued after STARTTLS completes. This is good enough for HTTPS's STS variant, and feels intuitively simpler for MTAs to implement.

A key difficulty with using a receiving MTA (MX host) as a policy source for active-attack prevention (in the absence of DNSSEC) is that the MX RRset is not secured, so the policy thus obtained is not only subject to "stripping" on first contact (as is the case with STS as proposed) but also subject to tampering by an attacker who can cause a forged policy to be vended by a rogue MX host, and then keep that policy in place preventing connections to the real receiving MTAs.

A related issue is that when all the MX hosts are switched to an alternative provider, there's not a good way to learn of the policy change. None of the new MX hosts are trusted per the old policy, and the none of the old MX hosts are in the new MX RRset.

So unfortunately, a catch-22 prevents use of the MX hosts as oracles to authenticate themselves (lift themselves by their bootstraps).

Post by Dave Cridland
3) DNSSEC or not?
The draft then goes on to compare the solution to DANE, and notes that DNSSEC is not required with MTA-STS - "at a cost of risking malicious downgrade attacks". These would be performed by DNS spoofing, which has a known history of occurring. In any case, what is distinctly unclear to me is whether MTA-STS without DNSSEC is materially different from RFC 7672 without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my immediate question is whether it might therefore be good enough for at least some cases of DANE.
I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record is sufficient to mandate TLS - hence my question is whether an insecure TLSA record stipulating a particular trust anchor and/or valid certificate (PKIX-TA and PKIX-EE) might be sufficient to meet the same security requirements here.

Without DNSSEC the protocol is not noticeably different from just STARTTLS, which has been quite successful at protecting against passive monitoring (90% of traffic in/out of Gmail uses TLS per the transparency report site). For active attackers DNS forgery is in scope, at which point some way to guard against MX RRset tampering is needed. Hence DNSSEC for DANE in SMTP and the HTTPS call-out in this draft.

For the record, I'd still rather see the providers in question implement DANE, and this should be increasingly doable as they move their email servers to dedicated domains (e.g. in Google's case many new customers are on googleemail.com MX hosts, rather than the legacy aspmx.l.google.com et. al.). So I see STS as a transitional technology that buys time. I am not advocating STS, but I recognize that there's an operational reality that makes DANE difficult for the large providers at present.

Post by Dave Cridland
4) Wildcard on Wildcard Action.
It is deeply unfortunate that MTA-STS mandates a name match based on dNSName SANs only. I would have thought that emulating an SRV, and matching a corresponding sRVName, would be more useful - and overall, the idea that a new matching algorithm has been included so as to match an "mx pattern" to a dNSName wildcard just feels like an exploit waiting to happen.

I see little evidence that such certificates are about to become mainstream. Indeed SRV serves little purpose here, as the name being authenticated is that of the receiving MTA, which is in the provider's domain, so there's largely no need for "virtual hosting", and the MTAs are dedicated machines, that are not also Web servers, FTP servers, ...
So DNS-ID is just fine for the SMTP certificates.

The reason for MX patterns is to avoid the operational pain of having to always update one's MX RRset in two places (in DNS and on a web server). A domain with an MX RRset
of the form:

example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.

would be able to specify a stable MTA-STS policy of:

mx: .mail.example.com.

and later change the MX RRset to:

example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
example.com. IN MX 0 mx3.mail.example.com.
example.com. IN MX 0 mx4.mail.example.com.

without having to update the MTA-STS policy.

Post by Dave Cridland
a) Make matches operate the same way as DANE, by being based on hashes of SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's approach of a certificate hash).

That kind of pinning is not viable for long-term client caching.

Post by Dave Cridland
b) Make matches operate the same way as RFC 6125 (unreferenced, I note).'

That fails to deal with the issue of forcing every MX RRset update to require
MTA-STS policy updates.

Post by Dave Cridland
c) Both/either of the above.

See above.

Post by Dave Cridland
I assume the logic behind allowing a wildcard-to-wildcard match is to allow a Google user to simply specify ".googlemail.com" and ".l.google.com" as their MX identity patterns;

exactly, and not have to keep changing the MTA-STS policy when the specific host names change.

Post by Dave Cridland
however it feels as though Google could simply use a known name within the certificate for all their receiving MTAs, irrespective of the DNS records involved.

This is why the MTA-STS policy was changed (at my request IIRC) to be not a filter on the MTA names, but rather a filter on the content of their certificates. It allows for either a single name across all the certificates, or distinct certificates for each MTA (less likely a single point of failure) that don't share names (some CAs don't like multiple outstanding certificates for the same name) with a common "base name".

Post by Dave Cridland
This, of course, presupposes that the administrator of the mail domain somehow does not know the precise names of the MTAs used in their own DNS records.

See above.

Post by Dave Cridland
7) Trust Anchors
RFC 7672 suggests that MTAs cannot rely on a set of common trust anchors, in Section 1.3.4. While I'm not actually convinced this is really the case, I'm finding it odd that on the one hand, we have a consensus standards-track document that makes this assertion, yet on the other this draft makes - implicitly - the opposite assertion.
It would be useful to understand if circumstances have changed.

Certainly there've been many changes in the last ~4 years since
RFC7672 was under development, and now a single CA (Let's Encrypt)
dominates the landscape. Out of a total of 6773 IP endpoints
with DANE-verified certificate chains, the top 10 issuers of the
EE certificate are:

3958 Issuer CommonName = Let's Encrypt Authority X3
534 Issuer CommonName = COMODO RSA Domain Validation Secure Server CA
419 Issuer CommonName = AlphaSSL CA - SHA256 - G2
109 Issuer CommonName = COMODO RSA Organization Validation Secure Server CA
73 Issuer CommonName = DigiCert SHA2 Secure Server CA
64 Issuer CommonName = Gandi Standard SSL CA 2
62 Issuer CommonName = RapidSSL SHA256 CA
61 Issuer CommonName = RapidSSL SHA256 CA - G2
51 Issuer CommonName = CAcert Class 3 Root
48 Issuer CommonName = Thawte TLS RSA CA G1

and so to some extent not that many CAs need to be trusted to verify the majority of remote SMTP servers, my concern in 7672 was and remains that there's no way to
exclude any of the CAs in the usual CA bundles (which bundle is authoritative?
Mozilla's?) from being fully trusted for all domains.

On the one hand, one wants to be able to send email to any destination around
the globe, and can't predict which CA some remote domain will prefer. On the
other hand one might not want to fully trust each and every CA for the world
at large. MTAs don't have an interactive user to "click OK" when authentication
fails due to missing or stale trust anchors. So my goal in 7672 was to avoid
relying on a globally coherent set of trust anchors.

If MTA-STS is primarily implemented by its sponsoring large providers, then
this is mostly a non-issue, as they're unlikely to use certificates from
"exotic" CAs that are not nearly-universally trusted. If STS-adoption
spreads like wildfire to lots of self-hosting domains around the globe,
then the CA bundle issue might become relevant.

[Dave Cridland]

Post by Dave Cridland

Post by Dave Cridland
2) HTTPS Call-out
Given the policy is essentially trust-on-first-use, it's not clear to me

why much of the STS policy cannot be transferred within SMTP itself,
perhaps in response to the EHLO issued after STARTTLS completes. This is
good enough for HTTPS's STS variant, and feels intuitively simpler for MTAs
to implement.
A key difficulty with using a receiving MTA (MX host) as a policy source
for active-attack prevention (in the absence of DNSSEC) is that the MX
RRset is not secured, so the policy thus obtained is not only subject to
"stripping" on first contact (as is the case with STS as proposed) but also
subject to tampering by an attacker who can cause a forged policy to be
vended by a rogue MX host, and then keep that policy in place preventing
connections to the real receiving MTAs.

Well, one assumes that an MTA gives out the policy for the MTA, not the
domain, but otherwise I take your points. I don't think that we'd end up in
a place markedly different, with the exception that it'd be MTA policy
rather than domain policy.

Post by Dave Cridland
A related issue is that when all the MX hosts are switched to an
alternative provider, there's not a good way to learn of the policy
change. None of the new MX hosts are trusted per the old policy, and the
none of the old MX hosts are in the new MX RRset.
So unfortunately, a catch-22 prevents use of the MX hosts as oracles to
authenticate themselves (lift themselves by their bootstraps).

Post by Dave Cridland
3) DNSSEC or not?
The draft then goes on to compare the solution to DANE, and notes that

DNSSEC is not required with MTA-STS - "at a cost of risking malicious
downgrade attacks". These would be performed by DNS spoofing, which has a
known history of occurring. In any case, what is distinctly unclear to me
is whether MTA-STS without DNSSEC is materially different from RFC 7672
without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my immediate
question is whether it might therefore be good enough for at least some
cases of DANE.

Post by Dave Cridland
I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record

is sufficient to mandate TLS - hence my question is whether an insecure
TLSA record stipulating a particular trust anchor and/or valid certificate
(PKIX-TA and PKIX-EE) might be sufficient to meet the same security
requirements here.
Without DNSSEC the protocol is not noticeably different from just
STARTTLS, which has been quite successful at protecting against passive
monitoring (90% of traffic in/out of Gmail uses TLS per the transparency
report site). For active attackers DNS forgery is in scope, at which point
some way to guard against MX RRset tampering is needed. Hence DNSSEC for
DANE in SMTP and the HTTPS call-out in this draft.
For the record, I'd still rather see the providers in question implement
DANE, and this should be increasingly doable as they move their email
servers to dedicated domains (e.g. in Google's case many new customers are
on googleemail.com MX hosts, rather than the legacy aspmx.l.google.com
et. al.). So I see STS as a transitional technology that buys time. I am
not advocating STS, but I recognize that there's an operational reality
that makes DANE difficult for the large providers at present.

I can sympathise with that, but MTA-STS is not built as a transitional
technology.

Post by Dave Cridland

Post by Dave Cridland
4) Wildcard on Wildcard Action.
It is deeply unfortunate that MTA-STS mandates a name match based on

dNSName SANs only. I would have thought that emulating an SRV, and matching
a corresponding sRVName, would be more useful - and overall, the idea that
a new matching algorithm has been included so as to match an "mx pattern"
to a dNSName wildcard just feels like an exploit waiting to happen.
I see little evidence that such certificates are about to become
mainstream. Indeed SRV serves little purpose here, as the name being
authenticated is that of the receiving MTA, which is in the provider's
domain, so there's largely no need for "virtual hosting", and the MTAs are
dedicated machines, that are not also Web servers, FTP servers, ...
So DNS-ID is just fine for the SMTP certificates.

Again, I'd agree if we posit that MTA-STS is an end-state and not a
transitional one.

Post by Dave Cridland
The reason for MX patterns is to avoid the operational pain of having to
always update one's MX RRset in two places (in DNS and on a web server). A
domain with an MX RRset
example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
mx: .mail.example.com.
example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
example.com. IN MX 0 mx3.mail.example.com.
example.com. IN MX 0 mx4.mail.example.com.
without having to update the MTA-STS policy.

If we assume that the MTA-STS document will always be created manually. But
the only POSH-supporting provider I could find generates the POSH JSON
document for their customers; it's trivial for a provider to do.

I genuinely feel that matching a pattern against another pattern is
introducing an unnecessary complexity into a security protocol.

In any case, if the MX RRset changes in that way, an administrator has to
check each certificate to see what the dNSNames are anyway, surely?

Post by Dave Cridland

Post by Dave Cridland
a) Make matches operate the same way as DANE, by being based on hashes

of SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's
approach of a certificate hash).
That kind of pinning is not viable for long-term client caching.

Post by Dave Cridland
b) Make matches operate the same way as RFC 6125 (unreferenced, I note).'

That fails to deal with the issue of forcing every MX RRset update to require
MTA-STS policy updates.

As above; while the policy might not need changing, and administrator has
to validate each and every host within the MX RRset to check the
certificates (particularly fun when multiple hosts masquerade under the
same name or address).

Hence much of the policy has to be sourced from the provider (as it is
today with POSH) and therefore how many "mx" keys there are and what needs
changing is largely irrelevant.

Post by Dave Cridland

Post by Dave Cridland
c) Both/either of the above.

See above.

Post by Dave Cridland
I assume the logic behind allowing a wildcard-to-wildcard match is to

allow a Google user to simply specify ".googlemail.com" and ".l.google.com"
as their MX identity patterns;
exactly, and not have to keep changing the MTA-STS policy when the
specific host names change.

Post by Dave Cridland
however it feels as though Google could simply use a known name within

the certificate for all their receiving MTAs, irrespective of the DNS
records involved.
This is why the MTA-STS policy was changed (at my request IIRC) to be not
a filter on the MTA names, but rather a filter on the content of their
certificates. It allows for either a single name across all the
certificates, or distinct certificates for each MTA (less likely a single
point of failure) that don't share names (some CAs don't like multiple
outstanding certificates for the same name) with a common "base name".

Post by Dave Cridland
This, of course, presupposes that the administrator of the mail domain

somehow does not know the precise names of the MTAs used in their own DNS
records.
See above.

See above. :-)

Post by Dave Cridland

Post by Dave Cridland
7) Trust Anchors
RFC 7672 suggests that MTAs cannot rely on a set of common trust

anchors, in Section 1.3.4. While I'm not actually convinced this is really
the case, I'm finding it odd that on the one hand, we have a consensus
standards-track document that makes this assertion, yet on the other this
draft makes - implicitly - the opposite assertion.

Post by Dave Cridland
It would be useful to understand if circumstances have changed.

Certainly there've been many changes in the last ~4 years since
RFC7672 was under development, and now a single CA (Let's Encrypt)
dominates the landscape. Out of a total of 6773 IP endpoints
with DANE-verified certificate chains, the top 10 issuers of the
3958 Issuer CommonName = Let's Encrypt Authority X3
534 Issuer CommonName = COMODO RSA Domain Validation Secure Server CA
419 Issuer CommonName = AlphaSSL CA - SHA256 - G2
109 Issuer CommonName = COMODO RSA Organization Validation Secure Server CA
73 Issuer CommonName = DigiCert SHA2 Secure Server CA
64 Issuer CommonName = Gandi Standard SSL CA 2
62 Issuer CommonName = RapidSSL SHA256 CA
61 Issuer CommonName = RapidSSL SHA256 CA - G2
51 Issuer CommonName = CAcert Class 3 Root
48 Issuer CommonName = Thawte TLS RSA CA G1
and so to some extent not that many CAs need to be trusted to verify the
majority of remote SMTP servers, my concern in 7672 was and remains that
there's no way to
exclude any of the CAs in the usual CA bundles (which bundle is authoritative?
Mozilla's?) from being fully trusted for all domains.

The current trust anchors are, indeed, Microsoft, Google, and Mozilla.
Google even run their own global CRL.

Thanks for this information, though, it's very useful.

Post by Dave Cridland
On the one hand, one wants to be able to send email to any destination around
the globe, and can't predict which CA some remote domain will prefer. On the
other hand one might not want to fully trust each and every CA for the world
at large. MTAs don't have an interactive user to "click OK" when authentication
fails due to missing or stale trust anchors. So my goal in 7672 was to avoid
relying on a globally coherent set of trust anchors.
If MTA-STS is primarily implemented by its sponsoring large providers, then
this is mostly a non-issue, as they're unlikely to use certificates from
"exotic" CAs that are not nearly-universally trusted. If STS-adoption
spreads like wildfire to lots of self-hosting domains around the globe,
then the CA bundle issue might become relevant.
--
Viktor.

[Viktor Dukhovni]

Well, one assumes that an MTA gives out the policy for the MTA, not the domain, but otherwise I take your points. I don't think that we'd end up in a place markedly different, with the exception that it'd be MTA policy rather than domain policy.

Unfortunately, per-MTA rather than per-domain policy entirely loses all
protection against active attacks when the MX RRset is not secure. The
MiTM just forges the MX RRset, yielding new hosts for which no policy
is stored.

For the record, I'd still rather see the providers in question implement DANE, and this should be increasingly doable as they move their email servers to dedicated domains (e.g. in Google's case many new customers are on googleemail.comMX hosts, rather than the legacy aspmx.l.google.com et. al.). So I see STS as a transitional technology that buys time. I am not advocating STS, but I recognize that there's an operational reality that makes DANE difficult for the large providers at present.

I can sympathise with that, but MTA-STS is not built as a transitional technology.

Time will tell. Either approach may yet fail to gain much traction.
So, yes, we can't assume that MTA-STS is transitional, that's mostly how
I like to think of it...

The reason for MX patterns is to avoid the operational pain of having to always update one's MX RRset in two places (in DNS and on a web server). A domain with an MX RRset
example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
mx: .mail.example.com.
example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
example.com. IN MX 0 mx3.mail.example.com.
example.com. IN MX 0 mx4.mail.example.com.
without having to update the MTA-STS policy.

If we assume that the MTA-STS document will always be created manually. But the only POSH-supporting provider I could find generates the POSH JSON document for their customers; it's trivial for a provider to do.

There will be all kinds of implementations, and all kinds of ways for operators to mess up their deployment. Making it easier to not mess up has a very high priority from my perspective. Overly brittle security gets turned off.

I genuinely feel that matching a pattern against another pattern is introducing an unnecessary complexity into a security protocol.

This is not difficult, OpenSSL has supported this type of peername
matching for some time, with the API simplified in 1.1.0:

https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_hostflags.html
https://www.openssl.org/docs/man1.1.0/ssl/SSL_add1_host.html

For MTA-STS one would call:

/* XXX: make sure policy has at least one reference id ("mx" value) */

SSL_set_verify(ssl, SSL_VERIFY_PEER, NULL /* callback */);
SSL_set_hostflags(ssl,
X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS |
X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS);

for (i = 0; i < reference_id_count; ++i) {
int ok;

if (i == 0)
ok = SSL_set1_host(ssl, reference_id[i]);
else
ok = SSL_add1_host(ssl, reference_id[i]);

if (!ok) { /* handle error */ }
}

/*
* XXX: Perform SSL_connect() handshake and handle errors here
* If unverified handshakes are allowed to continue, then the
* the verify resolt below may not be X509_V_OK...
*/

if (SSL_get_verify_result(ssl) == X509_V_OK) {
const char *peername = SSL_get0_peername(ssl);

if (peername != NULL) {
/* Name checks were in scope and matched the peername */
/* This should always be the case with MTA-STS */
}
} else {
/* Handle unverified peer */
}

In any case, if the MX RRset changes in that way, an administrator has to check each certificate to see what the dNSNames are anyway, surely?

Only if they don't already know that what's in the policy. If their design has a fuzzy MTA-STS policy of ".mail.example.com" and their operational practice is to always name MX hosts "mx<N>.mail.example.com" for some value of <N>, then they don't need to check anything when adding or removing MX hosts.

[Dave Cridland]

Post by Dave Cridland

Post by Dave Cridland
Well, one assumes that an MTA gives out the policy for the MTA, not the

domain, but otherwise I take your points. I don't think that we'd end up in
a place markedly different, with the exception that it'd be MTA policy
rather than domain policy.
Unfortunately, per-MTA rather than per-domain policy entirely loses all
protection against active attacks when the MX RRset is not secure. The
MiTM just forges the MX RRset, yielding new hosts for which no policy
is stored.

I can see I'm in the rough here, but I'm still unconvinced there's any real
difference between forging the MX RRset or forging the TXT record.

FWIW, POSH acted after the certificate had failed to validate by other
means, and performed a direct HTTPS call without querying DNS, so didn't
have this shortfall, while acting as a pure fallback.

Post by Dave Cridland

Post by Dave Cridland

Post by Viktor Dukhovni
For the record, I'd still rather see the providers in question

implement DANE, and this should be increasingly doable as they move their
email servers to dedicated domains (e.g. in Google's case many new
customers are on googleemail.comMX hosts, rather than the legacy
aspmx.l.google.com et. al.). So I see STS as a transitional technology
that buys time. I am not advocating STS, but I recognize that there's an
operational reality that makes DANE difficult for the large providers at
present.

Post by Dave Cridland
I can sympathise with that, but MTA-STS is not built as a transitional

technology.
Time will tell. Either approach may yet fail to gain much traction.
So, yes, we can't assume that MTA-STS is transitional, that's mostly how
I like to think of it...

I think the two are subtly incompatible at the moment in some cases, and
the flow involved means sending MTAs need to find out the policy prior to
connecting.

Post by Dave Cridland

Post by Dave Cridland

Post by Viktor Dukhovni
The reason for MX patterns is to avoid the operational pain of having

to always update one's MX RRset in two places (in DNS and on a web
server). A domain with an MX RRset

Post by Dave Cridland

Post by Viktor Dukhovni
example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
mx: .mail.example.com.
example.com. IN MX 0 mx1.mail.example.com.
example.com. IN MX 0 mx2.mail.example.com.
example.com. IN MX 0 mx3.mail.example.com.
example.com. IN MX 0 mx4.mail.example.com.
without having to update the MTA-STS policy.

If we assume that the MTA-STS document will always be created manually.

But the only POSH-supporting provider I could find generates the POSH JSON
document for their customers; it's trivial for a provider to do.
There will be all kinds of implementations, and all kinds of ways for
operators to mess up their deployment. Making it easier to not mess up has
a very high priority from my perspective. Overly brittle security gets
turned off.

I agree; which is why I both suspect and hope these policy documents will
be generated by the providers.

Post by Dave Cridland

Post by Dave Cridland
I genuinely feel that matching a pattern against another pattern is

introducing an unnecessary complexity into a security protocol.
This is not difficult, OpenSSL has supported this type of peername
https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_hostflags.html
https://www.openssl.org/docs/man1.1.0/ssl/SSL_add1_host.html

Well, I never knew that this API supported wildcard matching against
wildcards.

I still think this is wrong, but it's wrongness that's been implemented
already so I'll assume it's too late to fix.

Post by Dave Cridland
In any case, if the MX RRset changes in that way, an administrator has to
check each certificate to see what the dNSNames are anyway, surely?
Only if they don't already know that what's in the policy. If their
design has a fuzzy MTA-STS policy of ".mail.example.com" and their
operational practice is to always name MX hosts "mx<N>.mail.example.com"
for some value of <N>, then they don't need to check anything when adding
or removing MX hosts.

Well, yes, but the clearest way for the provider to communicate that policy
is just to provide the policy file, as I say, in which case it makes no
odds.

But if this is already in OpenSSL, then I suppose it's a moot point.

Dave.

[Viktor Dukhovni]

Post by Dave Cridland

Post by Viktor Dukhovni
Unfortunately, per-MTA rather than per-domain policy entirely loses all
protection against active attacks when the MX RRset is not secure. The
MiTM just forges the MX RRset, yielding new hosts for which no policy
is stored.

I can see I'm in the rough here, but I'm still unconvinced there's any real
difference between forging the MX RRset or forging the TXT record.

Forging the TXT record is a downgrade attack (only) on *first*
contact. After a policy is cached and so long as it remains
unexpired and gets refreshed periodically, forging the TXT record
is no longer effective. Where-as, in the absence of DNSSEC, per-MX
policy is subject to MX RRset forgery for each and every delivery.

Post by Dave Cridland

Post by Viktor Dukhovni
Time will tell. Either approach may yet fail to gain much traction.
So, yes, we can't assume that MTA-STS is transitional, that's mostly how
I like to think of it...

I think the two are subtly incompatible at the moment in some cases, and
the flow involved means sending MTAs need to find out the policy prior to
connecting.

Since DANE is downgrade resistant, and more resistant to mis-issuance
than DV certs, and MTAs don't require or care about EV, when usable
DANE TLSA records are found for the receiving SMTP server ("MX
host"), a sending MTA that supports both should go with DANE, and
not do STS (subject to local policy). When no usable DANE TLSA
records are found, any STS policy in scope for the domain should
be used.

Post by Dave Cridland

Post by Viktor Dukhovni
There will be all kinds of implementations, and all kinds of ways for
operators to mess up their deployment. Making it easier to not mess up has
a very high priority from my perspective. Overly brittle security gets
turned off.

I agree; which is why I both suspect and hope these policy documents will
be generated by the providers.

You keep assuming there's a third-party provider. Many domains
operate their own email servers, and these may have less sophisticated
operational practices. A fixed policy document is less fragile.

A domain owner can specify their reference identifiers by parent
domain if they so choose. For some this may be less prone to
operational tradeoff at a small trade-off in security. Recall that
STS is an optional upgrade from opportunistic unauthenticated
STARTTLS, and will only gain traction if operationally reliable.

I expect that STS adoption beyond the large providers will be slow,
and that making it a bit easier is worth it. Domains that don't
need the wildcard feature can specify all their MX hosts explicitly
in the policy.

Post by Dave Cridland

Post by Viktor Dukhovni
https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_hostflags.html
https://www.openssl.org/docs/man1.1.0/ssl/SSL_add1_host.html

Well, I never knew that this API supported wildcard matching against
wildcards.
I still think this is wrong, but it's wrongness that's been implemented
already so I'll assume it's too late to fix.

<off-topic, follow-ups off-list?>

IMHO there's nothing to fix, the use of sub-domain reference
identifiers is entirely optional. If the application provides
an explicit hostname to match (no leading ".") then it is
matched verbatim.

If an application *chooses* to ask OpenSSL to match a sub-domain,
".mail.example.com" or similar, then it is matched as documented
(what you call wildcard against wildcard). Most applications
don't and won't ask for sub-domain reference identifiers. An
application that implements STS over OpenSSL would ask for
those when that's what is in the STS policy.

</off-topic>

[Daniel Margolis]

Apologies for the slow reply here. (I was on vacation.)

Ned: thanks for the clear summary. I'll start working on those issues.

Dave: thanks also for the direct feedback. To be honest, though, after all
this discussion, I'm somewhat struggling to sort out what's actionable from
what isn't, as I suspect you can understand. I'll try to read through and
come up with a priority list of compatible changes, but I may miss
things--if there are changes (to the text, versus the entire approach)
which you want to call out as priorities, I would very much appreciate any
help.

(Regarding the point about in-protocol vs HTTPS callouts, Viktor already
addressed this thoroughly, but to restate somewhat differently, we operate
with the following constraints: 1. we have to secure the domain, not the
host (since securing only the host does not achieve anything even after
first-contact in preventing downgrades) and 2. we want to allow *authenticated
migration off of an implementing service* (i.e. to allow recipient domains
to move from a hosting service that supports STS to one that does not, and
to prove to implementing senders that that move is OK with them). The
combination of those two constraints imply out-of-band policy exchange, I
believe.)

Post by Viktor Dukhovni

Post by Dave Cridland

Post by Viktor Dukhovni
Unfortunately, per-MTA rather than per-domain policy entirely loses all
protection against active attacks when the MX RRset is not secure. The
MiTM just forges the MX RRset, yielding new hosts for which no policy
is stored.

I can see I'm in the rough here, but I'm still unconvinced there's any

real

Post by Dave Cridland
difference between forging the MX RRset or forging the TXT record.

Forging the TXT record is a downgrade attack (only) on *first*
contact. After a policy is cached and so long as it remains
unexpired and gets refreshed periodically, forging the TXT record
is no longer effective. Where-as, in the absence of DNSSEC, per-MX
policy is subject to MX RRset forgery for each and every delivery.

Post by Dave Cridland

Post by Viktor Dukhovni
Time will tell. Either approach may yet fail to gain much traction.
So, yes, we can't assume that MTA-STS is transitional, that's mostly

how

Post by Dave Cridland

Post by Viktor Dukhovni
I like to think of it...

I think the two are subtly incompatible at the moment in some cases, and
the flow involved means sending MTAs need to find out the policy prior to
connecting.

Since DANE is downgrade resistant, and more resistant to mis-issuance
than DV certs, and MTAs don't require or care about EV, when usable
DANE TLSA records are found for the receiving SMTP server ("MX
host"), a sending MTA that supports both should go with DANE, and
not do STS (subject to local policy). When no usable DANE TLSA
records are found, any STS policy in scope for the domain should
be used.

Post by Dave Cridland

Post by Viktor Dukhovni
There will be all kinds of implementations, and all kinds of ways for
operators to mess up their deployment. Making it easier to not mess

up has

Post by Dave Cridland

Post by Viktor Dukhovni
a very high priority from my perspective. Overly brittle security gets
turned off.

I agree; which is why I both suspect and hope these policy documents will
be generated by the providers.

You keep assuming there's a third-party provider. Many domains
operate their own email servers, and these may have less sophisticated
operational practices. A fixed policy document is less fragile.
A domain owner can specify their reference identifiers by parent
domain if they so choose. For some this may be less prone to
operational tradeoff at a small trade-off in security. Recall that
STS is an optional upgrade from opportunistic unauthenticated
STARTTLS, and will only gain traction if operationally reliable.
I expect that STS adoption beyond the large providers will be slow,
and that making it a bit easier is worth it. Domains that don't
need the wildcard feature can specify all their MX hosts explicitly
in the policy.

Post by Dave Cridland

Post by Viktor Dukhovni
https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_hostflags.html
https://www.openssl.org/docs/man1.1.0/ssl/SSL_add1_host.html

Well, I never knew that this API supported wildcard matching against
wildcards.
I still think this is wrong, but it's wrongness that's been implemented
already so I'll assume it's too late to fix.

<off-topic, follow-ups off-list?>
IMHO there's nothing to fix, the use of sub-domain reference
identifiers is entirely optional. If the application provides
an explicit hostname to match (no leading ".") then it is
matched verbatim.
If an application *chooses* to ask OpenSSL to match a sub-domain,
".mail.example.com" or similar, then it is matched as documented
(what you call wildcard against wildcard). Most applications
don't and won't ask for sub-domain reference identifiers. An
application that implements STS over OpenSSL would ask for
those when that's what is in the STS policy.
</off-topic>
--
Viktor.
_______________________________________________
Uta mailing list
https://www.ietf.org/mailman/listinfo/uta

[Dave Cridland]

Post by Dave Cridland
However, it surprises me that the MTA-STS draft does not appear to note
this prior art at all, and this makes me wonder whether it was even on

the

Post by Dave Cridland
radar.

The relevance of POSH was discussed as recently as March on the UTA list.
I believe it has come up in previously discussions as well.

Good to know it's come up at least.

Post by Dave Cridland
Importantly, POSH was never deployed very heavily - I can find only one
deployment (and "most users opt to just give us the cert"). This was in
part because of Google's withdrawal from standards-based IM, which
liberated the community from having to support a use-case only Google
really felt important, and also the rise of free CAs, which avoided the
cost issue associated with traditional PKIX.

The situation here is very different. First, Google is one of the players
behind this proposal and their withdrawl from standards-based email
seems...
unlikely.

As far as SMTP is concerned, at least, I'd agree.

Second, the primary problem MTA-STS solves - added security against
active attacks on existing email infrastructure - is quite different than
the
XMPP situation.

I'm not entirely sure that statement is accurate. The exact same list of
requirements is what drove POSH in my memory - an inability to authenticate
the certificates used in many cases and a (perceived) unwillingness to
share private keys, alongside a difficulty in certificate management when
hosting many domains.

Yes, XMPP has the advantage of less cruft and a simpler deployment model,
but I think that's largely irrelevant.

Post by Dave Cridland
2) HTTPS Call-out
Given the policy is essentially trust-on-first-use, it's not clear to me
why much of the STS policy cannot be transferred within SMTP itself,
perhaps in response to the EHLO issued after STARTTLS completes. This is
good enough for HTTPS's STS variant, and feels intuitively simpler for

MTAs

Post by Dave Cridland
to implement.

I'm afraid you have this exactly backwards. Even if the SMTP server
approach
provided comparable security - and it doesn't - deploying a new SMTP
extension
is quite difficult; we have an abundance of fully worked examples
demonstrating
this point. Whereas throwing up an A record, certificate, and server that
serves out a single document is trivially easy. These days I don't rank as
an
experienced IT person, and I was able to do it for a test domain in about
20
minutes.

I entirely agree that hosting a single document under HTTPS is trivial.

This is not to say that there aren't issues implementing MTA-STS. There are
significant issues, but they are all on the client side. Adding an HTTP
client
to your SMTP client significantly increases attack surface, so much so
that I'm
not willing to do it, and other folks have said they aren't willing to
either.
The approach I'm using is to build an MTA-STS query server with integrated
caching support. I have one mostly coded, and while I haven't worked
through
all the caching and timeout issues yet, I have not found any significant
implementation obstacles.

This workload is what I consider to be the antithesis of "intuitively
simpler".

Post by Dave Cridland
3) DNSSEC or not?
The MTA-STS problem is reasonably well-defined in the document - SMTP
servers often do host numerous domains, and unfortunately operating one's
own server has become a rarity, so domains are concentrated on a few
servers. STARTTLS is, as the abstract notes, theoretically susceptible

to a

Post by Dave Cridland
downgrade attack - but this does require either active MITM or some

fairly

Post by Dave Cridland
tight hoops to jump through to actually exploit.
The draft then goes on to compare the solution to DANE, and notes that
DNSSEC is not required with MTA-STS - "at a cost of risking malicious
downgrade attacks". These would be performed by DNS spoofing, which has a
known history of occurring. In any case, what is distinctly unclear to me
is whether MTA-STS without DNSSEC is materially different from RFC 7672
without DNSSEC; if unsecured DNS is "good enough" for MTA-STS, my

immediate

Post by Dave Cridland
question is whether it might therefore be good enough for at least some
cases of DANE.

I haven't implemented the SMTP client integration part of this yet so I
may be
speaking out of turn, but I've mapped it out and it appears to be
reasonably
straightforward.
I've also looked at implementing DANE, and IMO it's a major PITA to
implement,
so much so that it would take substantial customer interest to make me do
it -
interest that has not materialized.

For what it's worth, I implemented DANE in XMPP, including securely
deriving reference identifiers - making it slightly more complex than RFC
7672 in the end due to XMPP authenticating both ends of an S2S stream - in
a couple of days. I didn't find it even a minor PITA to implement.

And that's without even considering the difficulty of getting people to
deploy
funky DNS records. Like it or not, these days throwing up a single-purpose
HTTPS server is dead easy. And keep in mind that someone using a hosted
email
solution need only deploy a single CNAME record pointing at the hosted
solution's MTA-STS server. That's about as simple as it gets.

Post by Dave Cridland
I'd note that in RFC 7672, the presence of a (DNSSEC-secure) TLSA record

is

Post by Dave Cridland
sufficient to mandate TLS - hence my question is whether an insecure TLSA
record stipulating a particular trust anchor and/or valid certificate
(PKIX-TA and PKIX-EE) might be sufficient to meet the same security
requirements here.

Frankly, I don't care if it does or not. DANE is currently a nonstarter in
my
book, whereas while I dislike various aspects of this proposal, the
reality is
it's far easier to implement.

Well, we agree it's simpler on the receiving side at least, but that's only
because SMTP doesn't try authenticating the sending MTA.

Post by Dave Cridland
4) Wildcard on Wildcard Action.
It is deeply unfortunate that MTA-STS mandates a name match based on
dNSName SANs only. I would have thought that emulating an SRV, and

matching

Post by Dave Cridland
a corresponding sRVName, would be more useful - and overall, the idea

that

Post by Dave Cridland
a new matching algorithm has been included so as to match an "mx pattern"
to a dNSName wildcard just feels like an exploit waiting to happen. It

Please explain how it would be more useful.

Post by Dave Cridland
a) Make matches operate the same way as DANE, by being based on hashes of
SubjectPublicKeyInfo and/or the complete certificate. (Similar to POSH's
approach of a certificate hash).

That drags in some (but not all) of the implementation isssues with DANE. I
probably would not have bothered to implement MTA-STS had this been part
of it.

I suspect it's a lot easier than it sounds, actually. Otherwise I doubt I
could do it.

Post by Dave Cridland
b) Make matches operate the same way as RFC 6125 (unreferenced, I note)..

Not sure what you mean about references: Section 3.2, fourth bullet point,
section 3.3, second paragraph. section 4.1, first paragraph.

My error. I somehow missed that one.

Post by Dave Cridland
c) Both/either of the above.
I assume the logic behind allowing a wildcard-to-wildcard match is to

allow

Post by Dave Cridland
a Google user to simply specify ".googlemail.com" and ".l.google.com" as
their MX identity patterns; however it feels as though Google could

simply

Post by Dave Cridland
use a known name within the certificate for all their receiving MTAs,
irrespective of the DNS records involved. This, of course, presupposes

that

Post by Dave Cridland
the administrator of the mail domain somehow does not know the precise
names of the MTAs used in their own DNS records.
I further assume the logic in mandating matches against dNSName SANs is
because these are readily available; however sRVName SANs, by restricting
their use to a particular service, have the advantage that customers

giving

Post by Dave Cridland
these to their service provider might be deemed more acceptable.

A comparable effect can be achieved by using a subdomain root reserved for
email server use.
So it's a choice between an easily implemented naming convention and a
bunch
of PKIX esoterica. This does not strike me as a difficult choice.

Well, being *able* to use sRVName would be nice at least. The specification
as written prevents it, which seems unfortunate.

Being able to use dNSName is a given, of course. For one thing, it already
has support directly in OpenSSL's API - unless you're matching one wildcard
against another of course, when you have to do it yourself.

Post by Dave Cridland
5) Terminology and Nomenclature.
It is well-known that naming things remains the hardest problem in
technology.
However, this draft appears to have taken bold strides in demonstrating
that coming up with new names for things needn't be so challenging.
Take §7.1, for example, which dictates that the SNI extension MUST

contain

Post by Dave Cridland
the "MX hostname" - this latter term does not appear anywhere else in the
document. I'm going to guess that it means the RHS of the MX record, as
defined in RFC 7672 (and informative reference), which is the same as RFC
7672. "MX host", which appears once in RFC 5321, also appears elsewhere

in
I missed the "MX hostname" thing and agree it should be fixed. I also agree
that "MX host" is misleading and should be replaced, but I could not come
up with a useful replacement and so didn't suggest making that change in
my review.

Post by Dave Cridland
o MTA-STS Policy: A commitment by the Policy Domain to support PKIX
[RFC5280] authenticated TLS for the specified MX hosts.
Impressively, by my reading, the commitment is for the Policy Domain to
support PKIX for all SMTP; and not just for specified hosts.

Of course that's the commitment. How could it be otherwise?

Then that needs rephrasing, because I didn't see any "Of course" about it.

A commitment by the Policy Domain to support PKIX [RFC 5280] authenticated
TLS, using reference identifiers as listed.

(I'm trying to guess what was meant by "for the specified MX hosts".)

Post by Dave Cridland
Using more common - and more uniform - terminology would be of huge
benefit: "Sending MTA", "Receiving MTA", and so on are well-known terms..

Except those terms don't match up with anything that needs naming here
AFAICT.

"Sending MTA" is used a fair amount (15 times). But they're sending to a
"receiving MX" (4.1), or a "SMTP server" (curiously, some "SMTP servers"
are sending email, though).

Post by Dave Cridland
If
a new term is needed, please do define it. If you mean to use terms from
other RFCs, these need to be Normative References and noted in the
Terminology section.
6) Reference Identifiers and derivation.
RFC 6125 provides a slew of terminology and best practise - from the same
UTA working group, as I recall. RFC 7672 also provides terminology and

much

Post by Dave Cridland
behaviour.
It feels as though this draft should at least attempt to use the same
terminology, and ideally the same behaviour, as RFC 7672 (and RFC 6125)..
This is particularly noticeable in the difference between the reference
identifiers used within RFC 7672 (and used within the SNI discussed

there)

Post by Dave Cridland
compared with this draft, see for example this draft's §7.1, compared

with

Post by Dave Cridland
RFC 7672 §8.1

I haven't gone through the sections on SNI yet so I'm not going to
comment on this.

The main difference (from memory now) is that RFC 7672 uses a "TLSA base
name", which is either the "MX hostname" before or after following CNAMEs.

Dave.

[Dave Cridland]

Post by Dave Cridland
This workload is what I consider to be the antithesis of "intuitively
simpler".

And once again I'm afraid what your intution is telling you is exactly the
opposite of my experience. For me implementing this using a separate query
server actually makes things much easier, not harder, in part because I'm
not
constrained to code things in C/C++, which is what the SMTP client is
coded in.
You might want to sit down and try mocking this up in, say, node.js. It may
change your mind about the approach.
And the client part is going to be maybe 50 lines of C code. Code of a sort
I've written many, many, many times before. Hardly difficult.

That's all well and good, but people are saying that DANE is simple enough
to implement too.

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
c) Both/either of the above.
I assume the logic behind allowing a wildcard-to-wildcard match is to

allow

Post by Dave Cridland
a Google user to simply specify ".googlemail.com" and ".l.google.com"

as

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
their MX identity patterns; however it feels as though Google could

simply

Post by Dave Cridland
use a known name within the certificate for all their receiving MTAs,
irrespective of the DNS records involved. This, of course,

presupposes

Post by Dave Cridland

Post by Dave Cridland
that

Post by Dave Cridland
the administrator of the mail domain somehow does not know the

precise

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
names of the MTAs used in their own DNS records.
I further assume the logic in mandating matches against dNSName SANs

is

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
because these are readily available; however sRVName SANs, by

restricting

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
their use to a particular service, have the advantage that customers

giving

Post by Dave Cridland
these to their service provider might be deemed more acceptable.

A comparable effect can be achieved by using a subdomain root reserved

for

Post by Dave Cridland

Post by Dave Cridland
email server use.
So it's a choice between an easily implemented naming convention and a
bunch
of PKIX esoterica. This does not strike me as a difficult choice.

Well, being *able* to use sRVName would be nice at least. The

specification

Post by Dave Cridland
as written prevents it, which seems unfortunate.

I have to say I like the simplicity of the current specification, and I
don't
want to see added complexity in this regard without a compelling reason for
adding it.

OK, as long as you understand this embeds a hack into PKIX.

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
o MTA-STS Policy: A commitment by the Policy Domain to support

PKIX

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
[RFC5280] authenticated TLS for the specified MX hosts.
Impressively, by my reading, the commitment is for the Policy Domain

to

Post by Dave Cridland

Post by Dave Cridland

Post by Dave Cridland
support PKIX for all SMTP; and not just for specified hosts.

Of course that's the commitment. How could it be otherwise?

Then that needs rephrasing, because I didn't see any "Of course" about

it.

Post by Dave Cridland
A commitment by the Policy Domain to support PKIX [RFC 5280]

authenticated

Post by Dave Cridland
TLS, using reference identifiers as listed.
(I'm trying to guess what was meant by "for the specified MX hosts".)

The entire point of the mechanism is to say that the policy domain supports
and wants SSL/TLS transfers and that the servers have validated certs
with the specified names. So I really don't understand what you're getting
at here.

It says "MX host", which, as near as I can guess, is used elsewhere to mean
a host used as a Mail Exchanger, and not either of the "MX Hostname" or the
"Reference Identifier".

Dave.

[Viktor Dukhovni]

I've also looked at implementing DANE, and IMO it's a major PITA to implement,
so much so that it would take substantial customer interest to make me do it -
interest that has not materialized.

[ Not really on topic for this LC, so follow-ups off-list if there are further
questions to either Ned or me. ]

If your TLS library is OpenSSL 1.1.0 or later, then DANE support is included,
all you need to do is locate and retrieve any associated usable TLSA records,
and OpenSSL will verify the peer chain against those. Since MTAs already have
DNS-specific code for MX records, ... also doing TLSA lookups is fairly simple.

Manpage with code sample at:

https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_dane_enable.html

At which point DANE boils down to, per "MX host":

* Obtain address (A/AAAA) records for hostname via DNS
* If the address records are insecure and traversed a CNAME
perform CNAME query to obtain security status of original name
* If all (address and any CNAME) are insecure, no DANE
* If address records at are secure post CNAME expansion, check
for secure TLSA RRs at _25._tcp + expanded hostname. If found,
use those.
* If none found, or only original name is secure check for
TLSA RRs at _25._tcp + original hostname. If found use
those, else no DANE.

If TLSA lookups error out (not NXDOMAIN but SERVFAIL, timeout, ...)
then skip the host and try next MX or defer.

There's no HTTPS callout, no persistent cache, no downgrade on first
contact. No periodic preemptive policy refresh (to avoid downgrade
near expiration), no expedited policy refresh on authentication
failure, ... A correct STS implementation has rather a lot of
delicate persistent state. And the SMTP client needs to not only
do policy lookups against its cache, but also trigger policy
refresh on connection failure, and policy confirmation on initial
success. It is also not 100% clear whether a policy which
initially fails on the first MX host tried, but succeeds on the
second is a valid policy to cache. I think the intent is that it
is, but clearly the domain's configuration is degraded, so it is
a bit of a judgement call.

The policy cache needs to avoid retrying too often on failure to
reach the HTTPS server, returning the status quo rather than
timing out the lookup at each delivery. So there's short-term
state about recent failed attempts, as well as long-term state
for cached policies, ... So no shortage of moving parts.

Each of DANE and STS has its implementation challenges. It
rather depends on one's comfort zone. The DANE footprint in
Exim is quite small, not counting the contributed general-purpose
library for X.509 ala DANE that predates support for same in
OpenSSL 1.1.0, and works with OpenSSL 1.0.0 or later.

In Postfix the DANE code is larger, because that library
was originally developed as part of Postfix, and because we
also used the DANE code to re-implement the pre-existing
support for "fingerprint" based peer authentication, and
support TLS session resumption, which has to ensure that
resumed sessions match the destination policy.

So if Exim is a guide to implementation complexity for
DANE, the DANE story looks pretty good. The amount of
DANE-specific Exim code is quite modest.