Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

[Viktor Dukhovni <[e-mail]>]

On Mon, Feb 27, 2017 at 01:46:16PM -0800, Jim Fenton wrote:

> > I don't believe I can speak to this with authority, but I feel
> > somewhat comfortable excluding an /ever-present/ active MITM from our
> > threat model. It's certainly trivial to defeat initial policy
> > discovery, but an attacker must do this all the time. It's feasible,
> > but there's some probability of discovery, of course.
> 
> It's not that the attack has to be ever-present, it's that client MTAs
> that don't have a cached policy for the recipient domain will be showing
> up all the time, and will need to retrieve the policy. To the extent
> that they don't get the TXT record on the first try, they will infer
> that there is no policy, and will continue to do so while the negative
> response is cached by their responder (minimum TTL, typically only a few
> minutes, but the SOA in the NXDOMAIN response could also be spoofed to
> make this much longer). This waters down the effectiveness of MTA STS.

This is a fundamental limitation of STS.  STS cannot protect first
contact.  There is no reasonable way to design around this.  If
you want downgrade resistance, deploy DANE.

> > The "mx" constraint isn't really about the hostnames (though of course
> > it is applied to them); it's about the subject of the server
> > certificates presented by the MX. A different (albeit, I think,
> > needlessly confusing!) design could allow for the MX hostnames to be
> > arbitrary and not match the "mx" constraint in any way; all that
> > matters is the certificate name, for exactly the reason you give.
> 
> Fair enough -- the certificate name addresses the A/AAAA issue.

Indeed constraining the names in the certificate is exactly how
mandatory TLS policy works in Postfix.  We don't filter the MX
hostnames, rather the destination policy can filter the acceptable
certificate names regardless of the MX hostname.

    http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match

Filtering the MX hostnames is an indirect way of solving the same
underlying problem.  Perhaps "mx" should be renamed to "san" and
MX host selection then completely decouples from the security
policy.  When the connection is to a host whose certificate is not
suitable, the client hangs up and tries another MX host (up to
whatever limits on the number of such attempts are applicable).

Since this simplifies the protocol, and reduces the code changes
needed in MTAs, it is worth considering.

> > As you probably remember, we did try to have an "either/or" kind of
> > arrangement in the initial draft. It was a lot of extra complexity, I
> > think, for little gain--MTA-STS with DANE certificate validation is
> > sort of pointless, since DANE implies DNSSEC, which implies MX records
> > are themselves signed.
> 
> So what takes precedence: if there is a DANE policy, is MTA-STS ignored?

A sane client that supports DANE should prefer DANE when TLSA
records are published by the destination.  This is based on the
stronger downgrade resistance of DANE and no requirement for
long-term local storage.  Policy lookups have costs, and once a
DANE policy is found, it is simplest to not even bother looking
for STS policy.

Clients that want to eke out as much security as possible might
support both, and use DANE when possible and otherwise STS when
possible.

> >     "When a message fails to deliver...": How does the check for the
> >     updated policy occur, by looking for an updated TXT record or by
> >     re-retrieving the HTTPS policy?
> >
> > By looking for an updated TXT record, as per section 3--but your
> > question suggests we should clarify this. ;)
> 
> Yes, but Viktor's observation on the other thread (that TXT record
> lookups are cheap) applies here so maybe just start all the flows with a
> TXT record lookup.

I am sticking with that position.

-- 
	Viktor.