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

From: Dave Cridland <[email-masked]>
Date: Wed, 11 Apr 2018 12:38:38 +0100

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.

---

From: [email-masked]
Date: Wed, 11 Apr 2018 08:40:57 -0700 (PDT)

> probably no longer relevant.

And that, IMO, makes POSH in its entirety irrelevant to this effort - the
self-signed certificate support was it's one attractive feature and that
feature is no longer useful.

> this prior art at all, and this makes me wonder whether it was even on the

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.

> 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.  Second, the primary problem MTA-STS solves - added security against
active attacks on existing email infrastructure - is quite different than the
XMPP situation.

> community tooling) and a very high penetration of CA-signed certificates

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

> good enough for HTTPS's STS variant, and feels intuitively simpler for MTAs

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.

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.

> question is whether it might therefore be good enough for at least some

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.

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.

> (PKIX-TA and PKIX-EE) might be sufficient to meet the same security

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.

> would feel considerably safer to do one of:

Please explain how it would be more useful.

> 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.

> 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.

> 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.

> this draft, including in §1.1, where it is in this definition:

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.

> support PKIX for all SMTP; and not just for specified hosts.

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

> 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.

> If

> compared with this draft, see for example this draft's §7.1, compared with

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

> It would be useful to understand if circumstances have changed.

Of course circumstances have changed - it's now possible to obtain
free certificates from a widely if not universally trusted CA.

But this is also a case of reality setting in. The "too many CA" problem
is pretty small beer compared to the difficulty of deploying DANE.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Apr 2018 13:19:03 -0400

> On Apr 11, 2018, at 11:40 AM, [email-masked] wrote:
> 

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Apr 2018 14:20:31 -0400

> On Apr 11, 2018, at 7:38 AM, Dave Cridland <[email-masked]> wrote:
> 
> 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).

> 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.

> 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.

> 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).

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

> 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.

> c) Both/either of the above.

See 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;

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

> 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".

> 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.

> 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.
> 

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.

-- 
	Viktor.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 11 Apr 2018 23:52:34 +0100

On 11 April 2018 at 19:20, Viktor Dukhovni <[email-masked]> wrote:

> 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.

> 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).
>
> > 3) DNSSEC or not?
> >
> > 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
> 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.

> 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, ...
Again, I'd agree if we posit that MTA-STS is an end-state and not a
transitional one.

> 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:
>
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?

> > 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

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.

> > 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 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".
>
> > 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. :-)

> > 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
> 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

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.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2018 00:17:43 +0100

> I believe it has come up in previously discussions as well.

Good to know it's come up at least.

> unlikely.

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

> Second, the primary problem MTA-STS solves - added security against
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.

> experienced IT person, and I was able to do it for a test domain in about
I entirely agree that hosting a single document under HTTPS is trivial.

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

> 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.

> is
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.

> probably would not have bothered to implement MTA-STS had this been part
I suspect it's a lot easier than it sounds, actually. Otherwise I doubt I
could do it.

> section 3.3, second paragraph. section 4.1, first paragraph.
My error. I somehow missed that one.

> allow
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.

> 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".)

> Except those terms don't match up with anything that needs naming here
"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).

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

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.

---

From: [email-masked]
Date: Wed, 11 Apr 2018 16:49:54 -0700 (PDT)

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

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.

> 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.

> (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.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Apr 2018 21:35:56 -0400

> On Apr 11, 2018, at 11:40 AM, [email-masked] wrote:
> 

[ 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.
   
-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Apr 2018 22:23:10 -0400

> On Apr 11, 2018, at 6:52 PM, Dave Cridland <[email-masked]> wrote:
> 
> 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...
 
> 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.

-- 
	Viktor.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2018 10:17:05 +0100

> 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.

> > > > irrespective of the DNS records involved. This, of course,
> presupposes
> > > that
OK, as long as you understand this embeds a hack into PKIX.

> with the specified names. So I really don't understand what you're getting

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.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2018 10:27:25 +0100

> MiTM just forges the MX RRset, yielding new hosts for which no policy
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.

> >> 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 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.

> >> 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:
> >>
> > 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
> 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.

>   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.

> 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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 12 Apr 2018 16:24:29 +0000

> 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.

> the flow involved means sending MTAs need to find out the policy prior to

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.

> 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.

> 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.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 18 Apr 2018 15:37:39 +0000

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.)

On Thu, Apr 12, 2018 at 6:25 PM Viktor Dukhovni <[email-masked]>
wrote:

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