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

[Daniel Margolis <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> > On May 6, 2018, at 12:55 PM, Daniel Margolis <[e-mail]>
> 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.
>
>