Re: [TLS] Unifying tickets and sessions

[Hubert Kario <[e-mail]>]

On Thursday 23 October 2014 01:22:27 Manuel Pégourié-Gonnard wrote:
> On 22/10/2014 20:46, Nico Williams wrote:
> > On Mon, Oct 20, 2014 at 6:58 PM, Viktor Dukhovni <[e-mail]> 
wrote:
> >> On Mon, Oct 20, 2014 at 11:39:31PM +0200, Manuel P?gouri?-Gonnard wrote:
> >>> 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?
> > 
> > This is just as silly.  The server should choose what cipher to use, full
> > stop.
> I'm afraid you didn't understand what I was actually trying to suggest, but
> my sentence was ambiguous: my suggestion was that the server choose what
> cipher to use, by looking at what ciphersuites it is prepared to negotiate,
> and then picking the most secure symetric cipher from this list (or one of
> those with maximal key size).
> 
> Eg, if a server is only going to negotiate 128-bit suites because it thinks
> it's enough and doesn't want to waste cycles on more than that, then
> encrypting the tickets with a 128-bit key is fine. If it is prepared to
> negotiate 256-bit suite with some clients, it should encrypt the tickets
> with a 256-bit key.

While it may negotiate AES-256 (because it wants to interoperate with clients 
that are configured to not to present weaker ciphers), doesn't mean that it as 
a whole is configured to the 256 bit level of security.

With TLS1.2 it may sign the (EC)DHE parameters using SHA-1, it may use RSA key 
exchange using only 2048 bit keys, it may be just a local proxy server that is 
hard coded to connect using AES-128 with the backed servers over open 
Internet.

Yes, server should encrypt the tickets with as strong algorithm as its most 
secure cipher, but there are many situations where it's not necessary. "MUST" 
is certainly not applicable.

-- 
Regards,
Hubert Kario