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

[Viktor Dukhovni <[e-mail]>]

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