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: http://eprint.iacr.org/2014/876 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, Dan ________________________________ From: TLS [tls-boun...@ietf.org] on behalf of Hovav Shacham [ho...@cs.ucsd.edu] Sent: Sunday, September 25, 2016 9:19 PM To: tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Sun, Sep 25, 2016 at 2:20 PM, Ackermann, Michael <mackerm...@bcbsm.com<mailto:mackerm...@bcbsm.com>> 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: http://dualec.org/DualECTLS.pdf There are some organizations that would no doubt be happy to lend their expertise, including RSA-the-company. -hs.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
