> On 2 Jan 2017, at 20:59, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: >> >> . >> >> Since I think the utility of this falls off as a reciprocal, I'll try >> making a concrete suggestion for a time limit: 10 seconds. > > I like this number, because that’s the number I chose when I implemented ECDH > caching in Check Point’s TLS library. It makes key generation rare enough > that it makes no difference for server load in any normal hardware, and > frequent enough that if you destroy the keys after they are last used then > attackers have a very narrow window of opportunity to get your keys. > Especially if they need to get a warrant. IoT may be abnormal hardware in > that regard. > > Still, if we want to accommodate the banking industry (or whatever part of it > we’ve talked to in Seoul), then they need to be able to tell based on a > timestamp which private key was used for that handshake. With 60 seconds key > changes are rare enough that there are at most two possibilities which I > think is manageable. With 10 seconds clock skew can ruin your system. But I > realize I’m bike shedding here. > > Yoav, > > Why do you need a precise clock here? If you're going to retrospectively > decrypt, you > are going to need a list of all the private keys, so why can't you just index > that by the > public key in the handshake?
I’m assuming that the server generates private keys and saves them to a file along with the time period that they were used, and another machine in a different part of the network records traffic. It’s not so much that the clocks need to be accurate, as that they need to be synchronized, and there will still be some misalignment because of (variable) latency. I guess we are making guesses about systems that haven’t been written yet. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
