Here's something that came to my mind while reading draft-ietf-uta-mta-sts-03.
Let's suppose the sending MTA finds the MTA-STS TXT record, which states
the receiving domain has an MTA-STS policy. The draft says "To discover
if a recipient domain implements MTA-STS, a sender need only resolve a
single TXT record". But what happens when the sending MTA can't fetch
the actual policy via HTTPS?
Now the sending MTA knows MTA-STS should be in place, but can't know
what the list of expected MX is. It has to decide what to do.
- If it refuses to send the message, and the (unreachable) policy states
that it is in "report" mode, this can be considered a denial of
service.
- If instead it falls back to deliver the message to any available MX,
either encrypted or in plain text, or even acts as if the domain had
not stated it had an MTA-STS policy at all; and the (unreachable)
policy states that it is in "enforce" mode, then effectively this
was degraded to opportunistic.
Making the HTTPS endpoint unreachable is just a DDoS attack away. This
would expose all first-contact sending MTAs to this conundrum. I think
there is a need to clearly state what must be done in such a situation.
For example we could add to Section 3.3:
"If a MTA-STS TXT record is found but no policy can be fetched from the
HTTPS endpoint, and there is no previous cached policy, then senders
MUST assume the recipient domain does not implement MTA-STS."
While this does not really improve the situation, it makes clear for the
implementor of the receiving side that this is effectively equivalent to
opportunistic encryption and allows for countermeasures to be considered.
The reason for the "no previous cached policy" part is to provide for
the first-contact scenario, but there is another one: what if instead
the sender has previously seen a policy for the domain, but now it's
expired (because of max_age or new id in the TXT record) and it can't
fetch a new one?
I propose that we let the domain owner decide, by stating it in the
at a time when it was reachable. We could add a "fallback_mode" property
to the policy object, with possible values: "block", "keep_expired",
"opportunistic" (names are provisional and for illustration only).
This property would define what the sending MTA is to do when it must
fetch a new policy but can't:
- "block" would state confidentiality is still favored over
availability, therefore since the new expected MX list is not
known (and might be missing compromised servers), messages must
be discarded or retried at a later time when the endpoint might
be available again;
- "keep_expired" would keep applying the cached policy, which would
not be discarded until it's possible to fetch a new one. I see this
as useful because to me it's often the case that an expired policy
would be more useful than no policy at all.
- "opportunistic" would say that, in this non-normal scenario,
availability is to be favored over availability, so the sender
should discard the expired policy and act like in the previously
explained first-contact scenario.
The last one of course would mean that it's possible to force a fall
back to plaintext by making the HTTPS endpoint unavailable until a
policy expires, but the domain owner would have chosen this explicitly
and has to understand that.
--
Federico
________________________________
Iscriviti alla nostra newsletter per rimanere aggiornato su digital ed email
marketing! http://www.magnews.it/newsletter/
The information in this email is confidential and may be legally privileged. If
you are not the intended recipient please notify the sender immediately and
destroy this email. Any unauthorized, direct or indirect, disclosure, copying,
storage, distribution or other use is strictly forbidden.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
