Subject: [Uta] Feedback and questions about MTA-STS rev10

From: Ivan Ristic <[email-masked]>
Date: Tue, 10 Oct 2017 22:03:29 +0100

I have some feedback and questions about MTA-STS revision 10.

- The specification introduces its own hostname matching algorithm that
allows common names. CNs are deprecated by Baseline Requirements; browsers
ignore them in presence of the SAN extension. However, the MTA-STS seems to
allow a match in CN _or_ SAN. This is inconsistent with how PKI is used
elsewhere; is there are good reason for it?

Also do note that RFC 6125, referenced by MTA-STS, states that CNs must be
ignored when a SAN is present.

I think dropping CNs altogether would bring this RFC in line with how PKI
is used elsewhere and reduce complexities and opportunities for security
issues without losing any functionality.

- The other thing I found unusual is that (unless I am reading it
incorrectly), certificate validation is done in a kind-of round-about way:
when connecting to an MX server, the certificate is considered valid if it
matches any MX pattern from the policy. This is very unusual and requires a
custom hostname matching algorithm.

Is there are reason not to implement the more straightforward approach:

1. Attempt delivery only to MX servers listed in the policy (here you can
use some pattern matching that's necessary to support wildcards).

2. When actually connecting to an MX server, validate the certificate as
any other TLS client would (i.e., that it matches the hostname to which
you're connecting).

The advantage of this approach is that this is what TLS client libraries
already implement. I am afraid that this custom approach is dangerous and
might contain hidden problems, but also that increases the amount of
potentially tricky code that needs to be written.

- As a final small point, in at least one place the spec gives a very vague
explanation of how certificates are verified: "The certificate presented by
the receiving MX MUST chain to a root CA that is trusted by the sending MTA
and be non-expired." I am afraid that this incomplete guidance might give
some people idea that it's not necessary to perform any other checks (such
as KU/EKU, pathlen, name constraints, check that the signature algorithms
are acceptable, and so on).

I suppose all my three comments can be rolled up into one: implement
certificate checking in MTA-STS as it's practiced elsewhere. It would make
the spec simpler, easier to understand, and more robust.

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Oct 2017 22:42:02 +0000

> issues without losing any functionality.

No objections to that, provided that CNs are in practice being
deprecated from HTTPS (which I would applaud).

> custom hostname matching algorithm.

See the list archives, this is deliberate.  The idea is to not
override MX selection, and to support sites with UCC certifcates
where the identity is the receiving domain name and not the MX
host.

> I am afraid that this custom approach is dangerous and

OpenSSL already supports matching the peer certificate against any
of a list of reference identifiers.  Perhaps other libraries will
add similar support.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 11 Oct 2017 11:33:09 +0200

Hey, Ivan,

Comments inline:

> deprecated from HTTPS (which I would applaud).

IIRC we talked about this before and concluded that we should keep the same
behavior as in 6215, i.e. CNs are accepted only if SANs are not
present--only I forgot to update the draft accordingly!

Because STS is intended to work with existing certs, it seems problematic
to me to force people who may already have a CN-only cert to go get a new
one--but you probably have a better idea than I do about how common that
actually would be, if I remember your research properly. Are people
generally already all migrated to SANs? Are we likely to have people who
have an existing cert that relies on CN matching?

> are acceptable, and so on).

Yes, the intent is, as you say, to check certs "as implemented elsewhere."
Do you have a suggested reference that's a more thorough specification for
all the things "elsewhere" entails? I think you're right that this is in
some places underspecified, but of course we don't want to be specifying
behavior de novo--I'd much rather defer to some common understanding of
what hoops you should jump through (hence the reference to 6215, at least,
but perhaps this is insufficient or we are not referencing it in the right
places).

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Oct 2017 10:24:14 -0400

> On Oct 11, 2017, at 5:33 AM, Daniel Margolis <[email-masked]> wrote:
> 
> Are people generally already all migrated to SANs? Are we likely to have people who have an existing cert that relies on CN matching?

My DANE survey database has a copy of the certificate of every MX host
found to have TLSA records (~172k domains, or 4.5k MX hosts).  If we
surmise that SMTP certificates of domains adopting DANE are at all
representative of domains likely to adopt STS, then the below table
may be indicative.  After skipping self-signed certs, and CAs that
have issued 3 certificates or fewer (likely all private) the table
lists:

*  "IP#": The number observed MX host depth 0 certificates observed
   issued by the CA (counted by number of IP addresses with that
   certificate, so multi-homed hosts or hosts with the same
   certificate "inflate" the count).  The rows are sorted by decreasing
   "IP#".

*  "S": 1 for certificates with a SAN extension, 0 without.

*  The issuer CA DN.

Out of 2982 observed certificates behind the rows in the table only
4 have no SAN.  The exceptions are:

 * 4 issued by "C=NL, ST=Noord-Brabant, L=Raamsdonksveer, O=WebMeneer.NL, OU=CERTS, CN=bOnK/emailAddress=<...>"

Don't know whether that's a public CA or not.

That said, neither RFC7162 nor RFC6698 proscribes matching CNs, so STS
would be setting a new precedent.  In 7672 we have:

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

which says that CN-ID is only to be used when no DNS-ID SANS are present.

-- 
	Viktor.

 IP# S Issuer
---- - ------
2299 1 C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
 211 1 C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Domain Validation Secure Server CA
  50 1 C=IL, O=StartCom Ltd., OU=StartCom Certification Authority, CN=StartCom Class 1 DV Server CA
  50 1 C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2
  33 1 O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root
  23 1 C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
  23 1 C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO RSA Organization Validation Secure Server CA
  19 1 C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA - G2
  18 1 C=IL, O=StartCom Ltd., OU=StartCom Certification Authority, CN=StartCom Class 3 OV Server CA
  17 1 C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL CA 3
  17 1 C=CN, O=WoSign CA Limited, CN=WoSign CA Free SSL Certificate G2
  16 1 C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA - G3
  13 1 C=IL, O=StartCom Ltd., OU=StartCom Certification Authority, CN=StartCom Class 2 IV Server CA
  12 1 O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddress=[email-masked]
  10 1 C=US, O=Symantec Corporation, OU=Symantec Trust Network, OU=Domain Validated SSL, CN=Symantec Basic DV SSL CA - G2
  10 1 C=US, O=GeoTrust Inc., CN=GeoTrust SHA256 SSL CA
   9 1 C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
   9 1 C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL CA - G2
   9 1 C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 Secure Server CA - G4
   9 1 C=BM, O=QuoVadis Limited, CN=QuoVadis Global SSL ICA G2
   8 1 C=NL, O=KPN B.V., CN=KPN PKIoverheid Organisatie CA - G2
   8 1 C=BE, O=GlobalSign nv-sa, CN=AlphaSSL CA - SHA256 - G2
   7 1 C=US, O=thawte, Inc., OU=Domain Validated SSL, CN=thawte DV SSL SHA256 CA
   7 1 C=US, O=GeoTrust Inc., OU=Domain Validated SSL, CN=GeoTrust DV SSL SHA256 CA - G2
   7 1 C=ES, O=StartCom CA, OU=StartCom Certification Authority, CN=StartCom BR SSL ICA
   6 1 C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., OU=http://certs.starfieldtech.com/repository/, CN=Starfield Secure Certificate Authority - G2
   6 1 C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
   6 1 C=RU, ST=SPB, L=Saint-Petersburg, O=IVSOR Corporation, OU=Internet Services, CN=IVSOR Corporation Root CA for Internet Services
   6 1 C=DE, ST=Bayern, L=Erlangen, O=Universitaet Erlangen-Nuernberg, OU=RRZE, CN=FAU-CA/emailAddress=[email-masked]
   6 1 C=DE, O=T-Systems International GmbH, OU=T-Systems Trust Center, ST=Nordrhein Westfalen/postalCode=57250, L=Netphen/street=Untere Industriestr. 20, CN=TeleSec ServerPass DE-2
   5 1 C=US, O=thawte, Inc., CN=thawte SSL CA - G2
   5 1 C=US, O=GeoTrust Inc., CN=GeoTrust SSL CA - G3
   5 1 C=US, O=GeoTrust Inc., CN=GeoTrust EV SSL CA - G4
   5 1 C=FI, O=IKI, OU=kivinen, CN=Tero Kivinen 2016 CA Key
   5 1 C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Global Issuing CA
   5 1 C=BE, O=GlobalSign nv-sa, CN=GlobalSign Domain Validation CA - SHA256 - G2
   4 1 C=US, ST=TX, L=Houston, O=cPanel, Inc., CN=cPanel, Inc. Certification Authority
   4 1 C=GB, ST=West Yorkshire, L=Clayton West, O=Homeunix, OU=Plugs and Sockets, CN=Homeunix_CA/emailAddress=[email-masked]
   4 1 C=FI, O=IKI, OU=Mail, CN=Mail 2013 CA
   4 1 C=DE, O=Regionales Hochschulrechenzentrum Kaiserslautern, CN=RHRK-CA - G02/emailAddress=[email-masked]
   4 1 C=DE, O=PKI-1-Verwaltung, OU=Bund, CN=CA IVBB Deutsche Telekom AG 12
   4 1 C=DE, O=Max-Planck-Gesellschaft, CN=MPG CA/emailAddress=[email-masked]
   4 0 C=NL, ST=Noord-Brabant, L=Raamsdonksveer, O=WebMeneer.NL, OU=CERTS, CN=bOnK/emailAddress=[email-masked]

---

From: Hanno Böck <[email-masked]>
Date: Wed, 11 Oct 2017 23:31:42 +0300

On Wed, 11 Oct 2017 11:33:09 +0200
Daniel Margolis <[email-masked]> wrote:

> Because STS is intended to work with existing certs, it seems
> problematic to me to force people who may already have a CN-only cert
> to go get a new one--but you probably have a better idea than I do
> about how common that actually would be, if I remember your research
> properly. Are people generally already all migrated to SANs? Are we
> likely to have people who have an existing cert that relies on CN
> matching?

Chrome recently disabled CN support and only uses SAN. The Baseline
Requirements require certificates to have a SAN value and calls CN
deprecated [1].

Thus at least within the WebPKI:
1. If someone uses certificates with a CN and no SAN then they won't
work in the most popular browser.
2. They violate the rules and should be revoked anyway.

[1]
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.8-redlined.pdf

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [email-masked]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

---

From: Ivan Ristic <[email-masked]>
Date: Thu, 12 Oct 2017 08:54:37 +0100

On Wed, Oct 11, 2017 at 10:33 AM, Daniel Margolis <[email-masked]>
wrote:

> IIRC we talked about this before and concluded that we should keep the
> same behavior as in 6215, i.e. CNs are accepted only if SANs are not

Viktor and Hanno already said what I would have. I think just deferring to
6125 is a safe choice, certainly other relevant RFCs already do. For
example, the HSTS RFC does.

> but perhaps this is insufficient or we are not referencing it in the right

I was afraid you might ask that. Frankly, I don't think there's a good one
source, perhaps this is one area where a fresh RFC to provide a summary of
best practices.

Below is the language from the HSTS RFC; I was actually surprised at how
vague it is:

"8.4.  Errors in Secure Transport Establishment

   When connecting to a Known HSTS Host, the UA MUST terminate the
   connection (see also Section 12 ("User Agent Implementation Advice"))
   if there are any errors, whether "warning" or "fatal" or any other
   error level, with the underlying secure transport.  For example, this
   includes any errors found in certificate validity checking that UAs
   employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
   via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
   as via TLS server identity checking [RFC6125]."

I think something similar to this is fine, perhaps just emphasising that a
publicly-trusted certificate is required. Yes, that's vague, but I think it
will be understood. (And see below for a further comment about that.)

As an unrelated thought, have you considered standardising on the root
store? I admit not thinking a lot about it, but it's tempting. Given that
there is currently little proper certificate validation in SMTP, I suspect
that many clients and servers use stores that are not up to date. Saying
something like "you must use Mozilla's root store and you must update it at
least once a day/week/month", would preempt a great number of problems in
practice IMO. Of course, politics might get in the way, and attaching to
any one store is dangerous, but at least Mozilla have been doing a good
job, historically.

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

-- 
Ivan

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Oct 2017 10:05:06 +0200

> I think something similar to this is fine, perhaps just emphasising that
> a publicly-trusted certificate is required. Yes, that's vague, but I
> think it will be understood. (And see below for a further comment about
> that.)
> 
> store? I admit not thinking a lot about it, but it's tempting. Given
> that there is currently little proper certificate validation in SMTP, I
> suspect that many clients and servers use stores that are not up to
> date. Saying something like "you must use Mozilla's root store and you
> must update it at least once a day/week/month", would preempt a great
> number of problems in practice IMO. Of course, politics might get in the
> way, and attaching to any one store is dangerous, but at least Mozilla
> have been doing a good job, historically.
Speaking as an individual I don't think its appropriate to reference
mozillas (or anyone else's) trust management process unless it is open
and subject to similar open governance as the IETFs process is.

Instead why not say something like this:

MTAs implementing this specification SHOULD rely on common techniques
for keeping a set of trust anchors relevant for the use in validating
TLS connections for HTTP updated and current.

possibly combining something like that with those lines from HSTS

	Cheers Leif

---

From: Ivan Ristic <[email-masked]>
Date: Thu, 12 Oct 2017 09:39:38 +0100

On Tue, Oct 10, 2017 at 11:42 PM, Viktor Dukhovni <[email-masked]>
wrote:

> ...

Well, you don't have to override the MX selection. Select whichever MX you
want and then, just prior to connecting to it over TLS, verify that the
hostname matches one of the patterns provided. Treat it as authentication
failure if it doesn't. I think this is simpler, faster in case of failure,
and also allows you to use standard TLS hostname verification.

There's nothing in this approach that would prevent you from using UCC/SAN
certificates or SNI.

Is there a specific scenario that would work with the current wording and
not with my more-standard approach?

-- 
Ivan

---

From: Daniel Margolis <[email-masked]>
Date: Thu, 12 Oct 2017 13:21:53 +0200

The MX-selection-vs-validation discussion (and change; note that in draft
03 and prior it worked the way you suggest) was in this thread:
https://www.ietf.org/mail-archive/web/uta/current/msg01914.html.

I agree that the modifying-MX-selection-loop is mostly a red herring, since
you can do as you suggest and simply choose the host in question as though
you would connect to it and then treat the bad hostname (regardless of the
certificate) as an authentication failure; in effect, you need not modify
MX selection at all. I noted as much here:
https://www.ietf.org/mail-archive/web/uta/current/msg01950.html.

I believe Viktor's point (which he repeated here:
https://www.ietf.org/mail-archive/web/uta/current/msg01921.html) is that
it's common practice to have MX hosts whose certificates do not match the
hostname *at all*. This is the primary argument for having a policy that
constraints certificate identities rather than hostnames. We also discussed
the relative cost of custom matching in that thread. Empirically, per
http://conferences.sigcomm.org/imc/2015/papers/p27.pdf,  "However, only
0.6% of domains present trusted certificates that match their domain name,
while *34.2% present trusted certificates that match their MX server*."

---

From: Ivan Ristic <[email-masked]>
Date: Fri, 13 Oct 2017 16:30:01 +0100

On Thu, Oct 12, 2017 at 12:21 PM, Daniel Margolis <[email-masked]>
wrote:

> I agree that the modifying-MX-selection-loop is mostly a red herring,
> since you can do as you suggest and simply choose the host in question as
> though you would connect to it and then treat the bad hostname (regardless
> of the certificate) as an authentication failure; in effect, you need not
> modify MX selection at all. I noted as much here: https://www.ietf.org/
> mail-archive/web/uta/current/msg01950.html.
>
> I believe Viktor's point (which he repeated here: https://www.ietf.org/
> mail-archive/web/uta/current/msg01921.html) is that it's common practice
> to have MX hosts whose certificates do not match the hostname *at all*.
> This is the primary argument for having a policy that constraints
> certificate identities rather than hostnames. We also discussed the
> relative cost of custom matching in that thread. Empirically, per

Personally, I think SMTP server certificates should match only their own
names. If virtual SMTP hosting is desired, it can be done either with one
certificate and multiple hostnames, or via SNI and individual certificates.
In practice, probably a combination of both. For example, one certificate
could be shared among several hostnames that belong to the same
organisation.

People are not just going to enable MTA-STS with their existing
certificates. They're going to read someone's deployment guide, maybe
glance at the RFC, go through the motions, check with a testing tool (I
plan to write one), and deploy.

The simplest deployment use-case (e.g., one that I expect to be using for
my business) is that I use MTA-STS to "approve" the use of third-party MX
servers for my email. The third party only needs to ensure they have valid
certificates for their own hostnames, nothing else. In this case, virtual
hosting would be just extreme vanity, because who looks at MX servers'
names? :)

I understand that there is a lot of mess out there, but a new RFC is a
perfect (and practically only) opportunity to improve things, and that's
what I am arguing for.

On Thu, Oct 12, 2017 at 10:39 AM, Ivan Ristic <[email-masked]> wrote:
>
>> On Tue, Oct 10, 2017 at 11:42 PM, Viktor Dukhovni <[email-masked]
>> > wrote:
>>
>>> ...
>> Well, you don't have to override the MX selection. Select whichever MX
>> you want and then, just prior to connecting to it over TLS, verify that the
>> There's nothing in this approach that would prevent you from using
>> UCC/SAN certificates or SNI.
>>

-- 
Ivan

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 13 Oct 2017 23:34:02 +0000

> certificate and multiple hostnames, or via SNI and individual certificates.

Prior to DANE and STS, the *only* way to avoid MiTM attacks on SMTP
via MX lookup forgery was to authenticate the nexthop (typically
recipient) domain, *rather than* the MX hostname.  See:

    http://www.postfix.org/TLS_README.html#client_tls_limits
    http://www.postfix.org/TLS_README.html#client_tls_levels
    http://www.postfix.org/TLS_README.html#client_tls_secure

Validating the destination domain has a been a Postfix TLS security
mechanism since ~2006 and subsequently in Microsoft Exchange since
~2007.  Thus there are (a minority) of domains whose certificates
are designed to work under that security model.

> plan to write one), and deploy.

Perhaps so, and then to support multiple flavours of client auth
they'd need certificates that list both the domain and the MX
hostname as DNS-ID subject altnames.

> hosting would be just extreme vanity, because who looks at MX servers'

And indeed the current STS draft in no way precludes that.  It does
however, also support domains that list the domain and not the MX
hostname in their certificates.

> perfect (and practically only) opportunity to improve things, and that's

I should note that certificates designed to work with pre-DANE/STS
security requirements are not a "mess".

You're arguing to leave those behind, and/or at least always list
the MX hostname.  This reversal could be done, at the cost of
placing more strict requirements on the server certificates.

This would require adding language that stresses that all MX
hostnames obtained from DNS (whether they match the STS policy or
not) MUST be taken into account when an MTA performs routing loop
elimination for domains for which its own name (or some implementations
names that resolve to one or more of its own network addresses) is
one of the designated MX hosts.

Any skipping of MX hosts that don't match the STS policy can ONLY
take place after all MX hosts with a preference equal or worse
(larger) than the sending MTAs have been removed from the list.

In other words, STS would filter only connection initiation, not
MX loop elimination.

-- 
	Viktor.