> On May 4, 2018, at 11:45 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> 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.
>
> Well, in general when STS is misconfigured you can have problems.
> I don't see that this case is sufficiently important to go away from
> standard TLS semantics.
For the record, I'm concerned about implementation pitfalls,
not misconfiguration. A domain where not all the MX hosts
are not listed in the STS policy is "normal" is not
misconfigured per-se, STS-aware clients would send only
via the secure MX hosts, other clients may use the full
set. This is not a recommended configuration, but it
should work, provided at least one best-preference MX host
is listed.
The basic idea is that STS is there to secure mail routing,
not trump it. As much as possible mail routing should continue
to be based on the MX host names. An MX host not listed in the
policy might never-the-less possess a certificate matching the
policy (if the policy specifies presented-id patterns rather than
MX host patterns).
Which is not to say that alternative designs can't work, they'd
emphasize doing TLS "by-the-book" over doing SMTP "by-the-book".
My instinct is to do SMTP "by the book", the goal here is to deliver
email, securely when possible.
This protocol is an opportunistic upgrade from cleartext to
unauthenticated TLS to authenticated TLS when STS policy is
located and/or cached, some caution may be appropriate to not
over-optimize for security at the expense of operational
robustness. Especially in the email space, fragile security
gets turned off, RFC7435 and all that...
One related observation (thanks for the hard questions that lead
to the insight), perhaps worth mentioning in Security Considerations,
is that with MTA-STS an attacker who can forge MX records or address
RRsets of MX hosts can cause mail to bounce when the sender finds no
A/AAAA records for any of the MX hosts. The reverse path may not be
STS protected, and the bounce may return to the sender in the clear.
An implementation that naively filters the MX RRset first,
before eliminating MX hosts at the same or worse preference
than the sending host is buggy, and I think this bug is quite
likely. These days few read a complete document cover to cover,
we tend read the bits we think we need. Information overload and
all that.
So the warning about MX loops would likely be needed in
multiple places in the document to make MX patterns safer
for implementors with a typical attention span.
If the authors, IESG, the WG participants reading this, ...
decide to go back to MX host patterns at this point, I
won't stand in the way, I would just ask for prominent
warnings about MX RRset truncation at the sending host's
own preference (when found in the original MX RRset, forged
or not) and above happening BEFORE any policy filtering of
the MX RRset.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
