Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Florian Weimer <[e-mail]>]

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