Re: [TLS] Industry Concerns about TLS 1.3

Dan Brown <> Wed, 28 September 2016 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC28012B0D3 for <>; Wed, 28 Sep 2016 11:57:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.917
X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IswwbldrF1t2 for <>; Wed, 28 Sep 2016 11:57:52 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7924012B46D for <>; Wed, 28 Sep 2016 11:57:33 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Sep 2016 18:26:27 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0210.002; Wed, 28 Sep 2016 14:57:31 -0400
From: Dan Brown <>
To: 'Yoav Nir' <>
Thread-Topic: [TLS] Industry Concerns about TLS 1.3
Date: Wed, 28 Sep 2016 18:57:30 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-CA
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Sep 2016 18:57:54 -0000

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

From: Yoav Nir [] 
Sent: Wednesday, September 28, 2016 1:51 PM

>On 28 Sep 2016, at 7:16 PM, Dan Brown <> 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.