On 10/13/2017 02:45 PM, Stephen Farrell wrote:
So the problems with that are numerous but include:- there can be >1 carol, (and maybe all the carols also need to "approve" of one another), if we were crazy enough to try do this we'd have at least: - corporate outbound snooper - data-centre snooper (if you buy those supposed use-cases) - government snooper(s) in places where they don't care about doing that openly ...port 80 would suddenly be quicker than 443 again;-(
And any authorized eavesdropper is not allowed to be able to infer if they are the only ones listening in.
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.
I don't buy the argument that there are too many session keys for proactive export. Obviously, you already have sufficient capacity to send these keys (or an equivalent) over the wire once, so sending another copy or two shouldn't be a problem.
Thanks, Florian _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
