Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

On 10/22/2014 8:46 PM, 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:
>>>> 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?
[erm] That was not the original suggestion and 'negotiated cipher' 
doesn't imply that the cipher was chosen by the client. It's merely a 
fact that the server and the client have to negotiate a cipher before 
they can establish an encrypted communication channel. It doesn't matter 
how they do that, but at some point they'll negotiate a cipher (or no 
connection is established at all).

If the two of us agree upon using AES-256, wouldn't you be a little bit 
disappointed if I send you an encrypted ticket of that stuff we agreed 
upon to encrypt with AES-256 that is actually encrypted with AES-128? 
You wouldn't notice, because you can't read the ticket and trust that I 
honor our negotiations (after all, we were communication through a 
AES-256 secured channel which we negotiated, didn't we).

Well—fact is—today web servers are doing exactly that with tickets and 
that's why some people have problems with them and that's what I was 
referring to in my very first mail (quoted 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?
> This is just as silly.  The server should choose what cipher to use, full stop.
It does.

>> 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.
I already agreed upon the single key solution.


>> 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
> --
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
That's impractical for administrators that aren't running dedicated key 
generation servers within their own data center.

Actually everything Viktor Dukhovni said is perfectly correct and Nico I 
think you may have misunderstood a few things here.

Regards
Richard