Re: [therightkey] Basically, it's about keeping the CAs honest

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Feb 16, 2012 at 1:17 PM, Daniel Kahn Gillmor
<[e-mail]> wrote:
> On 02/16/2012 11:18 AM, Phillip Hallam-Baker wrote:
>> 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
>
> eh?  it seems you're proposing a new mechanism, when Tom just pointed
> out that the existing mechanism (endpoint-controlled trust policy)
> already works for nearly every case.  (the exceptions being client-side
> certs, and the hassle for IT staff of having to configure trust stores
> on each client)
>
>> 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.
>
> IT staff already have a simple way to do this: embed a MITM-enabling
> root authority (or comparable mechanism) in the client's trust policy.

It is a solution to the IT depts problem but there isn't transparency
for the user. The user is not told that they are being MITM'd.

Further, if DANE was deployed or any of the proposals made here was
deployed they would stop the MITM enabling root authority from
working. So we are proposing to break the escape hole you are
proposing they use.

Now breaking that escape hole might be a good thing. But we should
certainly think about the consequences and it should be a deliberate
decision to break it and not provide an alternative.

> Who exactly is trying to "minimize the effort required for the IT staff"
> to deploy a MITM?

BlueCoat did.


> I can't believe that on a list titled "the right key" the majority of
> the debate seems to be around whether we want a spec that enables
> transparent MITMing or a spec that enables user-visible MITMing.  Which
> part of "the right key" does any sort of MITM fit into?

One of the requirements that drives this work is that people did this
in the past and did it in a very bad way. So we need to either tell
them not to do it again or work out a safe way for them to do it.


> The main argument seems to be "people need to do this for legal reasons"
> -- well, ok, let's have someone with a legal requirement for
> eavesdropping/monitoring step forward and propose an external,
> session-key-sharing mechanism that is *separate* from TLS.  Then IT
> staff can deploy such a system on the clients they're required to monitor.

And how does that work?

Saying that 'it should be separate' does not absolve you from
proposing how it would work. If you are putting a proposal on the
table then it needs to be either 'don't do it at all' or 'this is how
to do it', I can't see how 'let someone else do it' helps us.




-- 
Website: http://hallambaker.com/