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
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey
