> IIUC, with the draft-rehired proposal, the client > can in any case not be told - the TLS protocol > extensions are mere politeness and the client does > not get to know what snooper(s) are involved, nor > can the client influence the snooping keys. Once, > any infrastructure for this was deployed, I think > it'd be used without telling clients for sure. (And > we would be fully complicit in helping that happen, > if the WG adopted this stuff, because we know that > such abuses would be inevitable.)
Not really. The draft relies on the server sending a non-encrypted extension containing critical information (the session keys encrypted using a shared key between server and third party). The third party is expected to intercept this non-encrypted extension and decrypt it using Ke in order to obtain the session keys. Without this information the third party is unable to fully decrypt the TLS connection. If the extension is not sent, the client does not realize there is a third party, but the third party does not have the session keys either, and the server has to provide them in a different way (for instance, using an OOB lookup as Florian suggested). In any case, it's not the same scenario as the draft proposes (the keys are shared in a different way) and can happen with or without this draft being accepted. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
