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 Thu, Apr 12, 2018 at 10:27:25AM +0100, Dave Cridland wrote:

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

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

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

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