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 <ietf-d...@dukhovni.org> wrote: > > > > On May 6, 2018, at 5:20 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> > 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. > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
