[ Re-ordered for clarity. Hope the below adds some context. ]
> On May 4, 2018, at 8:11 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
> Preemptive removal of non-matching MX hosts is liable (in sloppy
> implementations, and I expect enough to be sloppy) to cause routing
> loops, when a backup MX host, not after removing itself early from
> the list, fails to eliminate worse priority MX hosts.
>
> I don't understand this claim.
A sending MTA might be a non-primary MX host for a domain, that
is trying to reach a better (lower) preference MX host. If it
prunes the MX RRset based on the STS policy, *before* dropping
all worse (higher) preference MX hosts, it is liable to create
a mail routing loop, by not taking into account the fact it is
one of the MX hosts for the destination. Ideally the domain's
MX RRset should not contain any names not matched by the STS
policy, but reality is sometimes different.
If the meaning of the matching field were changed to be an
MX hostname pattern, rather than a presented-identifet (RFC6125)
pattern, then we'd need rather prominent warnings in the
text about routing loop avoidance.
>> So trying to make sure that you're reaching the MX host
>> you think you're reaching and not one of the others is
>> largely pointless and often a lost cause.
>
> But not everyone is configured this way.
Yes, some domains have distinct per-MX certificates. Even then,
an MiTM attacker can still restrict traffic to any MX host of
his/her choice, but if the name matching were more strict indeed
the sending MTA would then know *which* MX host this was more
reliably than otherwise.
>> See above. If the MX host has a certificate that matches the
>> client's SNI, it'll may return it, even if that's one of the other
>> MX hosts. If it does not return a matching certificate, the "attack"
>> fails.
>
> This might be true, but this kind of informal reasoning is notoriously
> prone to error. We have a general pattern for TLS certificate verification,
> which you are deviating from, and we then need to analyze in detail. I'm
> not seeing any good reason for that.
Historically, because MX lookups are unauthenticated DNS, trusting
the MX hostname was not a good option. So SMTP senders would validate
the next-hop domain, rather than the MX hostname. Correspondingly,
the certificates used by MX hosts would not necessarily match the
MX hostname, some matched only the (email) destination domain.
These were called UCC certificates by some.
Of course MTA-STS is new territory, and one might require suitable
new certificates for that, that always match the MX hostname. The
current draft is more forgiving.
>
>> It also
>> requires all sites to duplicate MX host updates from DNS into the
>> STS policy, disallowing the "low-maintenance" ".example.com" form.
>
> I don't see why this would be true. You publish .example.com and
> then you modify the MX requires at will. provided that they all end
> in .example.com.
Yes, that's true, provided the field remains a pattern. It would
invite the routing loop mis-optimization, not clear how effective
the text can be in the face of lazy implementors who just read some
TL;DR summary and implement without much thought. The presented-
identifier design is less prone to getting that wrong...
>> In short, I have not implemented and don't expect to implement CRL
>> support in Postfix.
>>
> You seem to be omitting the obvious answer: regular OCSP.
I did mention OCSP, I have problems with it:
* When OCSP lookups temp-fail, my impression is that most
clients generally continue processing. This obviates
the security benefits of OCSP. Otherwise the CA OCSP
server becomes a single point of failure I'd prefer
to avoid.
* One of goals of DANE and MTA-STS is to increase email
transport privacy. Leaking the (sender-domain,
recipient-domain) pairs to a new third party is in
conflict with that goal.
Hope that helps.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
