I don't believe that *pre-filtering *the MX candidate list is the only way to do it. You could leave the loop as-is and just refuse to connect to (i.e. treat as a transient connection failure) any candidate which fails the policy validation. So this is an implementation question; modifying loop pre-filtering is probably riskier than what we might call "connection early termination", but both are compliant with the protocol.
The real difference between the two options is not, I think, this implementation question, but that the current protocol technically allows some valid configurations that are invalid in the MX-based alternative--namely, the case where the certificate does not match the MX hostname. That turns out to be fairly common (per https://conferences.sigcomm.org/imc/2015/papers/p27.pdf), though, frankly, I do not know that there's a good reason for admins to deliberately configure a system in such a matter and, as a result, I don't believe there's a strong argument for us preserving that flexibility. I guess the tl;dr as far as I'm concerned is that I think either way really can be done safely, that it's mostly a documentation issue, but I am generally hesitant to change things now if we don't have to. On Sun, May 6, 2018 at 8:41 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > > On May 6, 2018, at 12:55 PM, Daniel Margolis <dmargo...@google.com> > wrote: > > > > 2. Why is the "mx" pattern matched against the SANs and not the MX > records themselves? As Viktor noted and I commented briefly in passing, we > debated this a *lot* before. One point here is that this is only visible to > MTA implementors; sysadmins who mistakenly believe the "mx" field should > match the DNS records (which should themselves match the servers' > certificates) will end up making their configurations valid per the actual > specification. In other words, "match the policy against the SAN" matches a > superset of conditions which are valid in the alternative ("match the > policy against the MX records and match those records against the > certificate"). Personally I would consider this edit to have been a > compromise--it was not and is still not my first choice--but, given it is > the status quo, I am fairly loath to change it. > > > > On these points--especially #2--I continue to defer to the guidance of > the chairs on how best to resolve such issues. > > After having to revisit this in response to the DISCUSS, I can > crystalize the issue in terms of the following dichotomy: > > * Does MTA-STS secure the connections to the endpoints indicated > by a domain's MX RRset, without preempting MX-based SMTP routing? > > or > > * Does MTA-STS secure the MX RRset, possibly filtering it to at > at most a set of names cached in the policy, with great care > to first take care of loop elimination. > > My sense is that the first option (current text) is a less invasive > change in SMTP, it changes only how the peer is authenticated. > > For example, it "testing" mode, one probably SHOULD NOT trim the MX > RRset based on a "testing" policy. Or one might support multiple > authentication mechanisms for the peer MX (say key fingerprint as > a fallback of MTA-STS fails). > > There are more implications to filtering the RRset then just > the presented-id matching... > > -- > Viktor. > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
