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

[Viktor Dukhovni <[e-mail]>]

> 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.