Re: [TLS] Industry Concerns about TLS 1.3

Dan Brown <> Wed, 28 September 2016 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F71812B220 for <>; Wed, 28 Sep 2016 09:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.916
X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QoFQ4suDHX2d for <>; Wed, 28 Sep 2016 09:16:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8020912B204 for <>; Wed, 28 Sep 2016 09:16:23 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Sep 2016 15:46:40 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0210.002; Wed, 28 Sep 2016 12:16:21 -0400
From: Dan Brown <>
To: Hovav Shacham <>, "" <>
Thread-Topic: [TLS] Industry Concerns about TLS 1.3
Date: Wed, 28 Sep 2016 16:16:20 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US, en-CA
Content-Language: en-US
x-mimectl: Produced By Microsoft Exchange V14.3.123.2
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF50102182DXMB116CNCrimnet_"
MIME-Version: 1.0
Archived-At: <>
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 16:16:42 -0000

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, as Hovav Shacham mentions, it seems possible that Bob can try to escrow ephemeral keys instead, by logging them (or their ultimate source, e.g. OS RNG), or by deriving them from say HMAC-DRBG, with prediction-resistance turned off, and just logging the DRBG seed (far out of reach of Bud, etc.).  This is still only a cat-out-of-bag solution, and also jeopardizes forward-secrecy.

Does TLS 1.3 already have a countermeasure to something like that?

If not, then maybe a future TLS 1.4, could go a step further to boost forward-secrecy, in partially thwarting Bob from escrowing himself (as outlined above).  For example:

the gist of which, as I recall, is deriving ephemeral keys from both a randomness source and the plaintext to be sent.  If the plaintext has enough entropy (and Bob does not keep a copy), then even escrowed keys are not enough to recover the plaintext.

In my limited understanding, this would be infeasible in the TLS setting, because it seems to require during a TLS handshake, collecting entropy from the message queue to derive keys, which might be violation of network layering, etc.  (there's no way for a TLS implementation, to know what's in the message pipeline).  I also doubt that most TLS server would have plaintexts with enough secret entropy waiting in the pipeline before the handshake.  But, again, I could be wrong: maybe TLS 1.3 is doing this in its 0-RTT mode (I haven't followed the details enough to know).

Finally, a historical note: ANSI X9.63 was developed in the late 90's within X9, a committee ostensibly of the financial services industry. ANSI X9.63 specifies some forward-secure forms key agreement. I don't recall any objections to forward-secrecy being raised (but maybe because these forward-secure key agreement were optional, or not just not being adopted.)

Best regards,


From: TLS [] on behalf of Hovav Shacham []
Sent: Sunday, September 25, 2016 9:19 PM
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael <<>> wrote:

Again, let me restate,  I don't think anyone is saying that we MUST have RSA.    But, we, as the clients of the IETF TLS protocol, would like to work with you to assure we have workable, manageable  and affordable solutions,  that meets our needs as well as the needs of others.

I think TLS 1.3 as it is might actually be compatible with your requirements.  The technology you need, Dual EC, was developed by the US Government and has already been standardized by ANSI X9.  Here's a whitepaper on how it would work:

There are some organizations that would no doubt be happy to lend their expertise, including RSA-the-company.