Re: [TLS] Unifying tickets and sessions

[Nico Williams <[e-mail]>]

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:
>> > 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.

Even parsed as the context implies, there's problems: a) the client
can't verify that the ticket is encrypted in any given cipher, b) why
on Earth should the server let the client choose what cipher is used
for the Ticket?, c) given (a), what is to be gained by any party from
the server using the client's desired cipher for encrypting the
ticket?

>> 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.

> 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.

Yes.

> With keys for clusters of servers rotated by code external to the
> TLS library, asking for a key for every algorith/size is impractical.

One would derive keys for all ciphers from a single cluster master
key.  Nonetheless, it's just plain silly to let the client/connection
dictate how to encrypt the ticket -- that's the server's prerogative.

Nico
--