> On 28 Sep 2016, at 7:16 PM, Dan Brown <danibr...@blackberry.com> wrote:
>
> As I understand the concern, the worry is that Bud is compromising Bob's
> (TLS) server, to somehow send Bob's plaintext to the wrong place.
>
> The proposed (existing?) strategy has Bob compromising his own
> forward-secrecy to stop Bud, but only after the cat is out of the bag. This
> seems a high price (no forward-secrecy) to pay for little gain
> (cat-out-of-bag).
>
> It seems wiser for Bob to somehow monitor or log what is being done with his
> own plaintexts at his own server. I know little about existing products to do
> this, but from my theoretical perspective, it ought to be easier than
> compromising forward-secrecy (logging ciphertexts).
>
> If proper plaintext monitoring or logging is somehow too costly, then yes...
I don’t really understand under what circumstances logging, monitoring or
storing the plaintext is not feasible, while storing the ciphertext is. Because
if you don’t store the ciphertext, then keeping static or ephemeral keys around
doesn’t buy you much. It’s true that current server products don’t log or
store the plaintext, but they could easily be modified to do that. There are
extensions to browsers that store the plaintext if you want.
Maybe if the good folks at the Bluffdale facility are willing to let you
download their copy of your captured ciphertexts, then it makes sense to store
only ephemeral or static keys. Otherwise it seems cheaper to store the
plaintext than to store both ciphertext and keys.
Yoav
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
