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

[Daniel Kahn Gillmor <[e-mail]>]

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.

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

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?

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.

If someone has a legal requirement to not only snoop but to alter
traffic in flight beyond just terminating a session (i find this
implausible, but what do i know), this can also be proposed as a
separate mechanism, outside of TLS, or as a TLS extension.  I don't see
how it's appropriate for this list, though.

Can we get back to discussing how to get the actual "right key" for the
network peer?

	--dkg