Re: [TLS] Unifying tickets and sessions

["Richard Fussenegger, BSc" <[e-mail]>]

I was to vague in regards to implementation, sorry. Of course we only 
want a single key or rather one long blob of random data to manage. The 
idea of using a key length of at least the 'highest supported 
ciphers'[*] sounds very good to me and would honor the ciphers in use. 
By always using a 128 bit key (current OpenSSL implementation) higher 
ciphers are essentially downgraded.

[*] Better would be 'from all ciphers in use' otherwise one ends up with 
a (insert ridiculous high value here) bit key while only using 128 bit 
ciphers in the configuration. Dropping the key if a new stronger 
configuration is loaded seems like a good idea to me at this point. I'm 
looking at this from a performance perspective and glimpsing over to the 
fact that the cryptography community agrees that 128 bit security will 
be enough for the next 10 to 20 years.[2] I really can't tell if this 
would be problematic from an implementation point of view. I think that 
single hosts won't have a problem here and I guess that it wouldn't be 
for clusters as well. The cluster configuration should be in sync but it 
could become a problem if one node has a differing configuration (for 
whatever reason). What opinion/insights do you have on this?

Regards
Richard

[1] http://www.keylength.com/

On 10/21/2014 1:58 AM, Viktor Dukhovni wrote:
> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote:
>
>>> The RFC should clarify that the negotiated cipher **MUST** be honored
>>> when encrypting the state that will be sent to the client. [1]
> I am having trouble parsing the original suggestion above.
>
>> While I'm sympathetic with the goal, I'm afraid that will complicate
>> implementations more than necessary. How about requiring to use a key length at
>> least a high as the highest supported ciphersuite instead?
> Does it mean (as I think you're saying) that session tickets MUST
> be encrypted with the session's negotiated ciphersuite?  That seems
> rather unmanageable.  A single sufficiently strong key is likely
> far more realistic.
>
> With keys for clusters of servers rotated by code external to the
> TLS library, asking for a key for every algorith/size is impractical.
>