Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-mta-sts-17: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Fri, May 4, 2018 at 7:41 AM, Viktor Dukhovni <[e-mail]>
wrote:

> [ Re-ordered for clarity.  Hope the below adds some context. ]
>
> > On May 4, 2018, at 8:11 AM, Eric Rescorla <[e-mail]> wrote:
> >
> > Preemptive removal of non-matching MX hosts is liable (in sloppy
> > implementations, and I expect enough to be sloppy) to cause routing
> > loops, when a backup MX host, not after removing itself early from
> > the list, fails to eliminate worse priority MX hosts.
> >
> > I don't understand this claim.
>
> A sending MTA might be a non-primary MX host for a domain, that
> is trying to reach a better (lower) preference MX host.  If it
> prunes the MX RRset based on the STS policy, *before* dropping
> all worse (higher) preference MX hosts, it is liable to create
> a mail routing loop, by not taking into account the fact it is
> one of the MX hosts for the destination.  Ideally the domain's
> MX RRset should not contain any names not matched by the STS
> policy, but reality is sometimes different.
>
> If the meaning of the matching field were changed to be an
> MX hostname pattern, rather than a presented-identifet (RFC6125)
> pattern, then we'd need rather prominent warnings in the
> text about routing loop avoidance.
>

Well, in general when STS is misconfigured you can have problems.
I don't see that this case is sufficiently important to go away from
standard TLS semantics.


>> In short, I have not implemented and don't expect to implement CRL
> >> support in Postfix.
> >>
> > You seem to be omitting the obvious answer: regular OCSP.
>
> I did mention OCSP, I have problems with it:
>
>  * When OCSP lookups temp-fail, my impression is that most
>    clients generally continue processing.  This obviates
>    the security benefits of OCSP.  Otherwise the CA OCSP
>    server becomes a single point of failure I'd prefer
>    to avoid.
>
>  * One of goals of DANE and MTA-STS is to increase email
>    transport privacy.  Leaking the (sender-domain,
>    recipient-domain) pairs to a new third party is in
>    conflict with that goal.
>

OSCP stapling (w/o must-staple) significantly decreases the privacy
load here without introducing brittleness. And of course there are
other mechanisms, such as CRLsets.

-Ekr


> Hope that helps.
>
> --
>         Viktor.
>
>