> On May 8, 2018, at 12:05 PM, Daniel Margolis <dmargo...@google.com> wrote:
>
> 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).
Agreed.
>> 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.
>>
>> 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.
I also don't quite understand why domain owners are reluctant to put
all the indirection in the MX record itself, rather than have that as
yet another name for the underlying host. I've not had much luck
convincing them otherwise. In the end, MTA-STS does not have to cater
to this particular constituency, tt's a tradeoff. If they want MTA-STS,
and the spec is changed, they'll have to ensure that the MX hostname
appears in the certificate.
The current spec does not exclude the domains where the MX host's
certificate uses some other name than appears in the MX RR, and
makes it unnecessary to carefully explain the loop elimination
requirements. The downside is somewhat certificate name matching
rules.
>> 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.
Right, but if the spec is changed to specify mx hostname (rather than
certificate) constraints, this would need to be called out explicitly.
>> Here'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? :)
Yes, the risk is small, and the target domain is already in a state of
sin (misconfigured).
> 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).
We can call that out if/when the in-band document is written.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
