> I don't understand why this complicated approach is needed. Why can't the > server provide an OOB > interface to look up sessions keys, or maybe export them proactively? The > proposed draft needs a > protocol like this anyway because SSWrapDH1 keys need to be distributed, and > periodic key > regeneration is needed because it is the only way to implement revocation of > access privileges > without revealing the existence of other authorized parties.
In my opinion, the proposed draft does not define a protocol because it expects that SSWrapDH1 keys will be distributed manually (I may be wrong with this, but that's what I understood as the draft does not specify any key exchange protocol between server and third-party). That's why I think that SSWrapDH1 keys will be very long-lived (administrators will hate having to manually distribute the new key in an hourly or even daily schedule), jeopardizing perfect forward secrecy for a long time. The problem I see with a "server to third party" OOB look up or export of the keys is that the client will not be notified of this export taking place and so will lose the chance to reject surveillance... _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
