> On May 7, 2018, at 4:15 AM, Daniel Margolis <d...@af0.net> 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". :-)
> * 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?
> * 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.
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).
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
