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

[Daniel Margolis <[e-mail]>]

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 <[e-mail]>
wrote:

> 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.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>