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

[Daniel Margolis <[e-mail]>]

Comments inline. I think the main point here is 1) I don't know if there
are good reasons for allowing the cases we allow now that I don't know
about and 2) regardless, I don't want to revisit anything unless it's going
to be revisited for the last time, so I want some guidance from chairs here
on how to finalize a resolution on this (one way or another).

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

>
>
> > On May 7, 2018, at 4:15 AM, Daniel Margolis <[e-mail]> wrote:
> >
> > 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.
>
> Yes, it boils down to whether we're willing to support MX hosts with
> certificates that match something other than the MX host name as
> seen in the MX RRset.  Operational practices would have to change
> to require the exact MX hostname.  For example:
>
>   tac-coburg.com. IN MX 10 mx-fhco-smart.rrze.uni-erlangen.de.
>   mx-fhco-smart.rrze.uni-erlangen.de[131.188.11.23]
>     name = mx-fhco-1.rrze.uni-erlangen.de
>     name = mx-fhco-2.rrze.uni-erlangen.de
>     name = mx-fhco-3.rrze.uni-erlangen.de
>     name = mx-rz-1.rrze.uni-erlangen.de
>     name = mx-rz-2.rrze.uni-erlangen.de
>     name = mx-rz-3.rrze.uni-erlangen.de
>     name = mx-rz.rrze.uni-erlangen.de
>     name = mx-sub-1.rrze.uni-erlangen.de
>     name = mx-sub-2.rrze.uni-erlangen.de
>     name = mx-sub-3.rrze.uni-erlangen.de
>     name = mx-uker-1.rrze.uni-erlangen.de
>     name = mx-uker-2.rrze.uni-erlangen.de
>     name = mx-uker-3.rrze.uni-erlangen.de
>     depth = 0
>       Issuer CommonName = FAU-CA
>       Issuer Organization = Universitaet Erlangen-Nuernberg
>       notBefore = 2014-09-29T10:16:00Z
>       notAfter = 2019-07-09T23:59:00Z
>       Subject CommonName = mx-rz.rrze.uni-erlangen.de
>       Subject Organization = Universitaet Erlangen-Nuernberg
>
> Out of 4238 MX hosts with working DANE TLSA records, 233 have certificates
> in which none of the names match the MX hostname.  They could of course
> change their practices or not adopt MTA-STS, but they seem to have their
> reasons for the names used and can be unwilling to change.  One Russian
> user whom I tried to convince to avoid aliases in the MX record quoted
> Lenin (to suggest that my perspective fails to take his circumstances
> into account):
>
>   "Узок круг этих революционеров. Страшно далеки они от народа"
>
> Which translates roughly as "Narrow is the circle of these revolutionaries.
> They are too far removed from the people". :-)
>

Hah!

Maybe. I don't have enough insight into what other providers do, to be
honest. I don't see good reasons for this, given the indirection allowed by
MX records and the ready availability of verified certificates, but maybe
I'm just missing something.


>
> >   * In "testing" mode one would still actually connect even to MX hosts
> >     whose names don't match the cached policy.
>
> If the draft is updated to change the matching rules, this issue would
> need to be addressed, what should be the treatment of non-matching MX
> hostnames in "testing" mode?
>

As you describe, the sender should connect and consider this a "test"
failure (i.e. reportable via TLSRPT if implemented). As such, there may be
differences in behavior--failures which in enforced policies would result
in a different MX being selected, but which in test mode result in delivery
proceeding--but that's basically the same behavior as in the current spec,
I think.


>
> >   * 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.
>
> Here, there's a very small, but non-zero risk of running into dynamic
> firewall rules by skipping a better priority MX host.  Some domains have
> backup MX hosts whose primary purpose is to detect out-of-order connections
> from botnets and the like, and access to the primary is blocked when a
> client connects to the secondary first.  The domain would of course need
> to be misconfigured to not list the primary in the MTA-STS policy.
>

Yeah, I don't consider that too worrisome, since it would only happen if
someone does something weird and then forgets the weird thing they did when
they also break their STS policy, right? :)


> If we ever do a spec for in-band reporting of authentication failure, that
> would be another reason to make the connection anyway, and just signal that
> the MX host is failing to match policy, before moving on to the next MX
> host (or deferring the message).
>

Agreed.


>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>