On Fri, May 4, 2018 at 7:41 AM, Viktor Dukhovni <[email protected]> wrote:
> [ Re-ordered for clarity. Hope the below adds some context. ] > > > On May 4, 2018, at 8:11 AM, Eric Rescorla <[email protected]> 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. > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
