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

[Dave Cridland <[e-mail]>]

On 12 April 2018 at 03:23, Viktor Dukhovni <[e-mail]> wrote:

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


> >> 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 agree; which is why I both suspect and hope these policy documents will
be generated by the providers.


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


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.

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