Hi,
On 10-11-2017 14:47, Brotman, Alexander wrote:
These two drafts were uploaded last night, and we'd like any
feedback. [..] We look forward to hearing from the group. Thank you.
I have feedback on the current draft from the perspective of smaller
e-mail providers.
MTA-STS competes with DANE TLSA for the achievement of similar security
goals of e-mail providers. As such, e-mail providers will be faced with
the choice of which protocols to support and enable: DANE TLSA, MTA-STS
or both. E-mail providers will be limited by their vendors (i.e.
implementors) in their freedom of choice. Implementors partially choose
support based on the guidance in this (later) spec.
I have quoted the relevant parts of the draft that treat considerations
for such choices below:
2. Related Technologies
The DANE TLSA record [RFC7672] is similar, [..]; the mechanism
described here instead relies on certificate authorities (CAs) and
does not require DNSSEC, at a cost of risking malicious downgrades.
For a thorough discussion of this trade-off, see Section 9, "Security
Considerations".
Section 9 _does_ include the security considerations relating to
downgrades. It _does not_ make explicit the considerations for choice,
which is what I expected to find after reading this paragraph. On the
other hand, these are partly, and /implicitly/ covered two paragraphs
later in Section 2:
The primary motivation of MTA-STS is to provide a mechanism for
domains to upgrade their transport security even when deploying
DNSSEC is undesirable or impractical. However, MTA-STS is designed
not to interfere with DANE deployments when the two overlap; in
particular, senders who implement MTA-STS validation MUST NOT allow
"valid" or "report-only" MTA-STS validation to override a failing
DANE validation.
This paragraph seems to imply that DANE TLSA takes priority over
MTA-STS. This assumption is never explicitly stated in the document.
I would argue to explicitly include guidance on the choice implementors
face. This is important in a world where it is likely that large
receivers will only support MTA-STS due to their preference not to
implement DNSSEC. The tendency to go along with large organisations
should be offset by being crystal clear about the differences between
DANE TLSA and MTA-STS with respect to their ability to meet stated
security goals.
To this end, I would propose adding: "and are therefor RECOMMENDED to
perform this validation prior to MTA-STS validation. To avoid risking
malicious downgrades, receivers that deploy DNSSEC are RECOMMENDED to
maintain DANE TLSA records for MX hosts."
Relevant inspiration for this proposal came from earlier conversation
between Jim Fenton and Viktor Dukhovni quoted below. For brevity, I have
not included the "local policy" angle", but this may well be worth doing.
best regards, Maarten
On 12-11-2017 19:48, Viktor Dukhovni wrote:
On Nov 12, 2017, at 6:01 AM, Jim Fenton <[email protected]>
wrote: >> - Section 4 "enforce" prohibits delivering when things fail
mta-sts, but Section 2 says, "MTA-STS is designed not to interfere
with DANE deployments where the two overlap". Doesn't this
requirement constitute that sort of interference? >
I would read that as "STS is entirely out of scope when DANE policy
is in effect". Of course sending machines get to decide whether DANE
policy is in effect or not, by choosing to enable DANE or STS in the
first place, and potentially choose one or the other explicitly for
some domains.
Thus, for example, while DANE policy is generally driven by the
remote domain's publishing of TLSA records, a sending Postfix MTA can
be configured to *require* DANE for some set of destinations, in
which case delivery will only happen when the destinations publish
("secure" DNSSEC) DANE TLSA records, and not otherwise.
Similarly, a sending system might *require* STS for some set of
destinations, and refuse to send in the absence of a cached policy.
So, the way I would read and implement this would be to prefer DANE
over STS barring local policy that prefers one over the other for
some destinations or perhaps suppressed both.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
