On 16 February 2012 00:24, Martin Rex <[email protected]> wrote: > What these MITM proxies are doing is _completely_and_thoroughly_ > subverting the entire purpose of the TLS protocol. They're doing > it not by exploiting weaknesses in the TLS protocol itself > (at least prior to rfc5746), but instead, by exploiting a long-standing > fatal design flaw in the security in the existing TLS X.509 PKI trust model. > > Those who want a protocol for encrypted communication that can be > arbitrarily MITMed should design themselves such a protocol. > Expecting the IETF to support continued exploitation of a serious > weakness in a security architecture that is the exact opposite of > its stated design goal is inappropriate for the IETF.
I think it's important to remember that whatever the TLS, DANE, and any other working groups come up with - there will be an army of people waiting to break the very first implementation, and they will do so. I will be one of them. No matter what Firefox and this working group come up with, I will break it locally, so I have a non-nagging TLS MITM. Even if I have to go in and modify the browser source code itself. Why? Because I test web apps! I need a MITM tool like Burp, Fiddler[0], or Mallory[1] to let me modify the traffic after it leaves the browser, before it leaves the machine, so I can test the inputs (form fields, headers, methods, and whatever else) the server accepts. That simple, that benign, that necessary, and yet entirely able to be re-purposed for evil. On 16 February 2012 08:01, Phillip Hallam-Baker <[email protected]> wrote: > Here we are all agreed that it is generally a bad thing for there to > be this particular hole. That is not the issue. The issue is whether > ignoring the fact that there are regulatory requirements for this > capability and not supporting them results in a better or a worse > outcome for users. > > So far the evidence suggests that refusal to consider them has > resulted in a worse outcome. I agree, but I don't really understand why everyone's arguing. It all seems to be tangent to the purpose of all the working groups I've seen, because ultimately, it's left at the discretion of the implementations. A:"We shouldn't enable MITM under any circumstances!" B:"Okay, do you want to outlaw local trust databases?" A:"No, that's implementation details." B:"Yea but.... that's how MITM works." or A:"We shouldn't talk about MITM in the protocol!" B:"Okay, but people are going to do it. Maybe we should have guidelines so users are notified?" A:"No!" C:"Isn't that up to the browser?" B:"Oh, yea." The only argument I could see worth debating is somehow _enabling_ MITM in the TLS protocol *itself*. And not only do I think that's a huuuge change, super-dangerous, I also think it's entirely unnecessary, because we already have a viable, working MITM solution: local trust stores. It seems to be a simple question: Will whatever "CA Solution/Improvement" we come up be expected to override local, user-set (or corporate IT-set) policy? If no, MITM will work - don't worry about it. If so, how do you expect to accomplish that, when I control everything on my machine?[2] -tom [0] Burp and Fiddler are proxies designed for fiddling with HTTP requests and responses [1] Mallory is designed to muck about with raw TCP packets [2] It *is* worth noting that the local policy engine/mechanism then becomes ripe for attack, and instead of compromising CAs, we'll see attacks that exploit bugs in it. But, we can deal with that. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
