Whoah. Long thread. For the record, I believe it's trivial to implement the hostname filtering without applying it to the MX selection loop (and I think I've made this observation before): if an invalid certificate is (as it must be) detected after connecting to the chosen MX candidate (and thus cannot be used to "prefilter" the candidate list), then, similarly, one can merely reject MX candidates after selecting them (i.e. without modifying the loop/candidate logic) and simulate the same control flow. That said, I always read Viktor's argument as being that by making this a check against the presented certificate it ensures implementers do not modify the candidate selection logic.
I also always felt a bit ambivalent about this entire discussion, insofar as we are trying to design so that implementers of validating MTAs--of which there aren't all that many--don't make mistakes. Both designs run a risk of hypothetical mistakes, either in the wildcard-to-wildcard matching or in the MX loop traversal. But neither mistake is applicable to system administrators, but only to the much rarer set of MTA authors. This doesn't mean we shouldn't consider it, of course, and I think the concerns voiced are valid--but it still seems significant to me to keep that in mind. I think that actually lends itself to documentary fixes--i.e., calling out the risks and potential mis-implementations in either strategy for uncareful readers. On Fri, May 4, 2018 at 6:13 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > > On May 4, 2018, at 11:45 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > >> 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. > > For the record, I'm concerned about implementation pitfalls, > not misconfiguration. A domain where not all the MX hosts > are not listed in the STS policy is "normal" is not > misconfigured per-se, STS-aware clients would send only > via the secure MX hosts, other clients may use the full > set. This is not a recommended configuration, but it > should work, provided at least one best-preference MX host > is listed. > > The basic idea is that STS is there to secure mail routing, > not trump it. As much as possible mail routing should continue > to be based on the MX host names. An MX host not listed in the > policy might never-the-less possess a certificate matching the > policy (if the policy specifies presented-id patterns rather than > MX host patterns). > > Which is not to say that alternative designs can't work, they'd > emphasize doing TLS "by-the-book" over doing SMTP "by-the-book". > My instinct is to do SMTP "by the book", the goal here is to deliver > email, securely when possible. > > This protocol is an opportunistic upgrade from cleartext to > unauthenticated TLS to authenticated TLS when STS policy is > located and/or cached, some caution may be appropriate to not > over-optimize for security at the expense of operational > robustness. Especially in the email space, fragile security > gets turned off, RFC7435 and all that... > > One related observation (thanks for the hard questions that lead > to the insight), perhaps worth mentioning in Security Considerations, > is that with MTA-STS an attacker who can forge MX records or address > RRsets of MX hosts can cause mail to bounce when the sender finds no > A/AAAA records for any of the MX hosts. The reverse path may not be > STS protected, and the bounce may return to the sender in the clear. > > An implementation that naively filters the MX RRset first, > before eliminating MX hosts at the same or worse preference > than the sending host is buggy, and I think this bug is quite > likely. These days few read a complete document cover to cover, > we tend read the bits we think we need. Information overload and > all that. > > So the warning about MX loops would likely be needed in > multiple places in the document to make MX patterns safer > for implementors with a typical attention span. > > If the authors, IESG, the WG participants reading this, ... > decide to go back to MX host patterns at this point, I > won't stand in the way, I would just ask for prominent > warnings about MX RRset truncation at the sending host's > own preference (when found in the original MX RRset, forged > or not) and above happening BEFORE any policy filtering of > the MX RRset. > > -- > Viktor. > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
