On Fri, Jan 01, 2016 at 01:54:00PM +0100, Henrick Wibell Hellström wrote: > I think it is a good idea to rekey AES-GCM after approximately 2^32 records, > give or take a few magnitudes. > > The question for me isn't whether AES-GCM requires frequent rekeying (it > does), but exactly how much complexity the rekeying mechanism would add, to > the protocol and to implementations.
There have been three basic proposed categories of key update schemes: 1) Ratchet keys through KDF, no new randomness. 2) Ratchet keys through KDF, with new randomness 3) Do new PK key exchange Also, if one doesn't want applications to have to be aware of rekeying, one can't introduce new flights ("fully asynchronous key update"). This would cause _severe_ constraints. Then there is strictly weaker constraint that one can't introduce "dead air", where the protocol can't make forward progress without waiting for response (the previous constraint is sufficient but not necressary to meet this). Firstly, 1) The current scheme is example of 1) without new flights. Basically, send a message to ratchet sender's keys. There is no symmetry-breaking between updates, so if k(i) = k(j), then k(i+n) = k(j + n) (such symmetry-breaking could be introduced by adding key number to KDF inputs). Also, I noted that the current scheme seems to break HKDF pairing: It tries to expand already expanded value (traffic secret). This violates pairing. Also, scheme like this could nicely work with DTLS: One could use epoch numbers to signal rekeying (but one would then take care not wrap epoch in way that could cause confusion). Then 2) Doing 2) without new flights would imply: - Two traffic keys, one for each direction. The low-level ciper keys derive from traffic key of respective direction. - Sending message to update keys would update only the traffic key in sending direction, regenerating low-level cipher keys and resetting the RSN in that direction. - Entropy from peer can't be explicitly be used. The best one could do here is to recommend mixing last received ratchet entropy from peer into own entropy to produce the random value to send when replying (when that happens). I don't think this is terribly more complicated than 1). But it is more complicated nevertheless. I don't see dropping the stronger full asynchronous constraint would simplify things, due to possibility of "crossed rekey" caused by finite "speed of light". Also, this would cause issues with DTLS: One would have to reliably transmit these rekeying messages, whereas previous DTLS are reliable only within handshake. Finally 3) Now the rekeying necressarily involves two messages. Doing this fully asynchronously seems just about impossible (updating one half- key at a time would hit "key caching" problem). Then it would be whole new logic for performing PK exchange. One can't reuse handshake because it would introduce thorny issues about tying to previous handshake and ensuring that state doesn't change in all sorts of unexpected ways. It also would need to somehow prevent crossing a key update. All in all, the complexity looks grealy greater than 1) or 2). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls