> On 06 May 2016, at 12:01, Viktor Dukhovni <[email protected]> wrote: > > 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.
There is. It depends on how detailed reports are. If I see an appliance stripped STARTTLS commands, I may want to report this back to the receiving MTA and/or 3rd party monitoring services. Likewise if there're specific TLS or downgrade attacks performed that show up in logs, I may want to report this. I think this would be a very useful feature indeed and give some indication as to who and what fucks up paths on the internet at the moment. It'll likewise give indication as to misconfigured receiving MTAs. > 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, ...). I never said we're going to solve the "Great Firewall of China" problem with these standards. > 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. I agree we need to protect users messages but I completely disagree that the feedback mechanism should be unencrypted. See previous and this mail above. Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
