Rekey within a session?

[kmcallister]

The question came up in #71 of whether a Mosh session should rekey every so often. Mosh would perform a key-exchange protocol such as Diffie-Hellman over the existing authenticated session, and then use the new AES key going forward. If a session key were compromised after the fact, say by stealing a laptop running Mosh, it would reveal only a small window of prior traffic. (Of course, there is no protection against active attackers who already have the session key and can tamper with the key exchange protocol).

This would complicate the crypto story substantially, and would require adding a public-key encryption library to Mosh. We can't use OpenSSL for license reasons, but there exist alternatives such as libgcrypt and PolarSSL.

A paranoid user can already rekey at any time simply by restarting the session (and using screen or tmux on the server side).

RFC 4344 provides recommendations on rekeying SSH.

• The first recommendation is to rekey after 2³² packets. SSH uses a 32-bit sequence number. After 2³² packets, there is the possibility of replay attacks, or of detecting identical plaintexts as a HMAC collision.

  Mosh uses a 63-bit sequence number, so this is not a practical concern — it would take us about 13,000 years to roll over sending minimal Ethernet frames on a 10 Gbps link.

• The second recommendation depends on the cipher block size; for AES it says to rekey after 2³² cipher blocks. This is designed to reduce the risk of birthday attacks against the block cipher. This recommendation depends on the block cipher mode and so deserves further scrutiny. We should look for any OCB-specific rekeying advice.

RFC 4253 recommends rekeying after one gigabyte of transmitted data or one hour of connection time, but does not provide a rationale.

[keithw]

http://tools.ietf.org/html/draft-krovetz-ocb-03 recommends rekeying after 2^48 blocks, or four petabytes. I could be inclined to just kill the mosh session at this point...

[kmcallister]

Okay, that sounds good to me. I've submitted a commit to do so, which closes this issue. We can re-open if we're interested in the forward secrecy question in the future.

[smemsh]

Original ticket said "We should look for any OCB-specific rekeying advice" and the 2012 spec referenced suggests 2^47 rekey interval. While that information is perhaps authoritative (I'm no cryptographer), rekeying more often than "effectively never" would still be a safer choice and remove the concern altogether.

An earlier 2002 paper (which admits to being a quick analysis) contains some possibly relevant info and theoretical collision attack on OCB: a standards comment paper by cryptanalyst Niels Ferguson, titled "Collision Attacks on OCB". This paper seems to say that a computation workload of only 2^80 is needed to discover a successful forgery for keys that change every 2^48 cipher blocks; I don't know what supercompute clusters are up to these days and if it's anything to care about, but pass the info along.

In MAC-authenticated cipher modes, we don't care much about weak digests with known collisions being used by the HMAC because of periodic rekeying; it doesn't matter so much, because there will not be a chance to discover the means to forge packets before a rekey. However, with long-lived sessions (such as mosh uses) and especially if raw-byte-stream support is added at some point, this seems like it might be something to consider. The paper's author is obviously upset by the licensing choice of OCB and is injecting his personal opinion, but the point he makes may still have merit: cryptanalysis of OCB has not been done by very many that can, due to the restrictive licensing terms. If some vulnerability is discovered eventually, the lack of rekey in mosh could be problematic.