[gnutls-devel] session ticket key rotation

[Daniel Kahn Gillmor]

On Tue 2016-11-15 01:47:03 +0900, Nikos Mavrogiannopoulos wrote:
> One question is whether we would like the key_pool_rotate to protect
> from parallel calls of the same function, or from calls with small
> time difference.

I think locking key_pool_rotate against itself doesn't sound like it
would be harmful, but i also don't see why it would matter.  in the
worst case, you just make it so that some sessions cannot be resumed,
which means that clients would fall back to slightly longer handshakes.

And if someone really wants to invalidate all existing session tickets
without destroying the ticket pool, i don't see why they shouldn't be
allowed to rapidly cycle the pool.

So i guess simpler seems better to me -- i don't see the need for locks.

> What about CPUs where writing to a memory location is not an atomic
> operation... i.e., if on line 22, some reader instead of getting the
> old or the new value of pool->current_key, gets some intermediate
> value? Are these of a concern?

So i can imagine, say, the first half of the RAM being from key N and
the second half of the RAM being from key N+1 for that slot.  In that
case, no existing tickets for that slot (which had been issued nearly a
full rotation cycle ago) would validate during that window.  but that's
fine, they're about to be invalidated anyway.  The bigger risk would be
if new tickets were issued during that case, but that wouldn't happen
because we update current_key *after* the key is updated.  So i still
don't see a problem.

Thanks for the thoughtful review!  let me know if you have any other
concerns or suggestions about the proposal.  If you think it's in decent
shape, should i open a gitlab ticket to track it?  I don't know if i can
get around to implementing it soon, alas, but i know it would be useful
for at least a couple implementations i'm concerned about.

Regards,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: </pipermail/attachments/20161115/948ef084/attachment.sig>