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 5:20 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
>> 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. 
> 
> It makes a difference with a "testing" policy.  Should mail be sent via
> an MX host not listed in the policy, or should it be skipped?  With
> "testing" the mail should probably go out, with a report of the authentication
> failure (impossible success given unexpected MX name) sent per any "tlsrpt"
> policy.
> 
> So at least "testing" should probably use all the MX hosts.  Whether "enforce"
> does or does not is then a question of whether doing it differently for the
> two cases is a potential source of confusion/bugs, and prominent anti-loop
> warnings.
> 
> There are even some domains where connecting to the backup MX host *before*
> trying a connection to the primary will cause firewall rules to be dynamically
> added to block the client!

And yet, of course, we could essentially in all cases go through the motions
of considering *every* MX host, and even connect to each X host in turn as
needed, but still authenticate the peer based on a match between the
certificate and the MX hostname, with the additional constraint that the
MX hostname match the policy "mx" list.

  * In "testing" mode one would still actually connect even to MX hosts
    whose names don't match the cached policy.

  * In "enforce" mode, one could at the last moment optimize-out connections
    to hosts which are sure to fail authentication, because the MX hostname
    does not match the "mx" list.  This of course after loop eiimination, etc.

I think that's the point that Daniel was trying to make...

-- 
	Viktor.