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

[Daniel Margolis <[e-mail]>]

Yes, that was exactly my point. That's why I was saying this is really an
implementation detail (albeit one you'd want to call out); the only
fundamental protocol question at issue is whether we should consider valid
a policy that matches only the cert but not the hostname itself.

On Mon, May 7, 2018 at 5:05 AM Viktor Dukhovni <[e-mail]>
wrote:

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