On Fri, May 06, 2016 at 10:39:57AM +0700, Aaron Zauner wrote:
> > The MITM attacker already knows he was attempting to intercept the
> > traffic.
>
> The MITM does, the receiving party may not.
You need to keep in mind that in the vast majority of cases
authentication errors will be operational errors (self-DoS) on
receiving systems, and the task at hand is to minimize the frequency
and duration of outages, so that security is used and not just
disabled as unusable. Maximalist approaches are highly counter-productive
here.
If there is an MITM, we don't need confidentiality of the report
that there is an MITM. While we'd like the report to get through
to the right party in that case, sadly that's not possible, but
reports do get through to the majority of peers where the issue is
an operational SNAFU on one end or the other.
> Just as Opportunistic TLS: "MAYTLS" MAY indeed pave the way for downgrade
> attacks, or am I missing something?
There's no downgrade attack opportunity here, the signal would be
carried in the message content from the sender who's relaying the
message (originally the user's MUA).
Perhaps it would be wise to agree on the purpose and requirements
for reporting before we debate reporting "solutions"?
As I see it, the top 20 goals of forward path authentication failure
reporting are:
1. Notify the receiving system they've partly messed up,
as some of their MX hosts fail authentication.
2. Notify the receiving system they've still partly messed up,
and you've independent evidence they've messed from various
3rd party test sites that confirm your observations.
3. Notify the receiving system they've royally messed up,
and all their MX hosts are failing authentication.
4. Notify the receiving system they've still royally messed
up, and you're going to soon bounce all their back to the
senders.
...
20. Keep the receiving party appraised of possible MiTM attacks,
via post-event statistical reporting.
Yes, the above is deliberately provocative, to jolt folks out of
their comfort zones and to think about the real goals and out of
those relevant requirements.
The key requirement as I see is *timely* delivery of focused *alerts*
to operators who can fix the problem, ideally before it affects
the delivery of email, while the issue is still localized to just
a proper subset of the MX hosts.
Sites enabling DANE, STS, ... need to commit to superior operational
practices (reliable automation, monitoring, ...) and in many cases
to risk reduction by, for example, avoiding using a single wildcard
certificate for all their MX hosts that can DoS them all when it
expires. Staggering MX host certificate rotation, so if if goes
wrong, only a subset of the MX hosts is affected, ...
Sites that don't have the operational discipline to do this right
are best off staying with opportunistic TLS and publishing neither
DANE nor STS policies. DoSing themselves periodically, and causing
pain for senders trying to do the right thing helps no one.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
