Re: [TLS] Unifying tickets and sessions

[Viktor Dukhovni <[e-mail]>]

On Wed, Oct 22, 2014 at 10:27:32AM -0400, David Leon Gil wrote:

> There are, obviously, two things a server should be able to use for a
> unified session id/ticket:
> 
>  - An opaque identifier
>  - Encrypted session state using a construction like RFC 5077's.
> 
> Right now, RFC 5077 recommends: AES-128 with a 128-bit key and
> HMAC-SHA256 with a 256-bit key.
> 
> Or, uselessly high 256-bit security against active attackers, and
> uselessly low 128-bit security strength against global passive
> adversaries.
> 
> There should be a recommended session ticket construction at a 256 bit
> security strength for privacy to replace RFC 5077 s.4's.

The same construction works just fine with AES-256-CBC, so it is
merely a matter of updating the draft to recommend AES-256-CBC for
the encryption.  (I've updated the Postfix default ticket cipher
to AES-256-CBC as planned for the next release).

Mind you, I would not call AES-128-CBC "uselessly low".  Assume
classical attacks, and suppose circuitry running at 1W power-draw
with 2^16 parallel AES units, each of which does 2^32 AES-128
encryptions per second.  The total energy requirement for an AES-128
brute force attack is then:

	(2^128 / 2^16 / 2^32) J = 2^80 J

If this is powered by a sizeable ~4 GW (2^32 W) power plant, it
will take 2^48 seconds to generate the requisite energy.  With
somewhat less than 2^25 seconds per year, we're looking at ~2^23
or ~8 million years of output from such a plant.

If we assume attacks that reduce AES from 128 to 120 bits, that
number comes down to a "mere" 2^15 or 32K years of 4GW power.  The
energy cost is prohibitive, and we've not taken into account the
costs of storage if this is to be a pre-computation for a space-time
trade-off to attack multiple encrypted payloads.

And all this ignores the fact that AES is rarely used in ECB mode
with the same fixed plaintext encrypted by all parties under varying
keys.  The use of random IVs or similar "whitening" makes
pre-computation substantially less effective.

-- 
	Viktor.