All that I have seen proposed in this regard is to have a draft that states:
1) This is a really bad idea in general 2) If you really have to do it then do it this way 2a) It is turned off by default 2b) It only permits the authorized MITM to intercept 2c) The user is repeatedly warned that MITM is taking place 2d) There is no way that any credentials or infrastructure created for authorized intercept can be used to support unauthorized intercept I would rather have a defined path for this than to see another iteration where the primary goal is to minimize the effort required for the IT staff deploying the system. On Thu, Feb 16, 2012 at 10:06 AM, Tom Ritter <[email protected]> wrote: > 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 -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
