On Fri, May 06, 2016 at 10:55:02AM +0700, Aaron Zauner wrote:
> > On 06 May 2016, at 10:49, Aaron Zauner <[email protected]> wrote:
> >
> >> On 06 May 2016, at 02:40, Viktor Dukhovni <[email protected]> wrote:
> >>
> >> The most timely reporting mechanism may be neither HTTPS nor a
> >> separate email report, but an ESMTP extension that can signal
> >> authentication errors as they occur. (Since STS supports a
> >> non-enforcement 'trial' mode, and reporting was in large measure
> >> intended to support that, the client would be continuing to use
> >> the server in any case).
> >
> > I like this idea. But again; I think the extension shouldn't send feedback
> > if there isn't already a secure channel in place (e.g. MITM already
> > occurring).
There's no way to know whether MiTM is present, or the other side
has messed up. The vast majority of the time it's the latter.
Senders behind persistent nation-wide MiTM firewalls can't benefit
from DANE or STS, if they want secure channels to the outside, they
must find other means. DANE and STS can reduce the incidence of,
effectiveness of and incentives to mount transient attacks (BGP
hijack, ...).
They can also substantially simplify regulatory compliance if peers
in certain industries standardize on support for DANE and/or STS
as a means of mutual signalling of downgrade-resistant secure
transport capabilities.
> ..so in that case for an attacker that's trivially DoS'able as
> well. Which would require a fallback mechanism like HTTPS + WebPKI
> again, I suppose (unless you go opportunistic all the way of course,
> which is, what I assume you propose).
You're still erroneously looking to *secure* the alerting mechanism
from MiTM attacks, and missing the point that what's important is
a *timely* alerting mechanism, which keeps operational errors down
to a tolerable frequency and duration, as a consequence of which
security might actually stand a chance of getting deployed!
We need to MiTM protect the actual messages users are sending, not
the error alerts that are needed to keep them flowing.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
