Re: [TLS] Industry Concerns about TLS 1.3

[Dan Brown <[e-mail]>]

Please keep aiming for forward-secrecy. (Just in case my wording has been unclear.)

From: Yoav Nir [mailto:[e-mail]] 
Sent: Wednesday, September 28, 2016 1:51 PM

>On 28 Sep 2016, at 7:16 PM, Dan Brown <mailto:[e-mail]> wrote:
 
>> 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. 

I don't understand either.  (That's what I meant by "ought to be easier", sorry for my convoluted phrasing if I was unclear).    

I did not fully understand the earlier parts of this thread, but I thought some were arguing that ciphertext logging was more feasible than plaintext logging.  So, I used "somehow" to qualify this as only a remote possibility in the rest of my email (concerning hypotheticals).  

>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.

Good point, and pretty much my reasoning.

A speculation about costs of storing plaintexts versus ciphertexts: Bob may want to configure his server not to store personal information, e.g. unencrypted plaintexts about his honest customers (Alice).  Of course, it should be sort-of-okay if Bob encrypts and store them at this server (or some other safer location).  But then, Bob might notice the TLS is already encrypting the plaintexts, so he may reason that it is okay to leverage that cost by just capturing those ciphertexts and store them, rather than encrypting them again (now with two different keys).  It's slightly safer, but slightly more costly, for Bob to re-encrypt the plaintexts, because TLS ciphertexts might leave Bob's control (so forward secrecy is very important), whereas the re-encrypted ones can be kept in Bob's control (making them slightly less available to a forward-secrecy-type adversary).  

Finally, Bob monitoring his plaintexts, to stop Bud before he does the bad stuff, might be more costly than storing or logging data, because it involves intelligent processing of sensitive information.  An ounce of prevention is worth a pound of cure; the extra cost of monitoring may be worth it.  Furthermore, if good plaintext monitoring is possible, then Bob need not store ciphertexts or escrowed keys at all, which is worthwhile too, as Alice and Bob then can have better forward secrecy.