Re: [TLS] Unifying tickets and sessions

[Richard Fussenegger <[e-mail]>]

This isn't getting anywhere here, I'll try again but only once.

On 10/22/2014 9:43 PM, Nico Williams wrote:
> On Wed, Oct 22, 2014 at 08:59:05PM +0200, Richard Fussenegger wrote:
>> [erm] That was not the original suggestion and 'negotiated cipher'
>> doesn't imply that the cipher was chosen by the client. It's merely
>> [...]
> It does imply that the client at least constrained the choice of cipher.
>
> This is unnecessary complexity.  I thought we were all for simplifying.

Negotiation -> TLS Handshake [1] -> ssl_prefer_server_ciphers=on [2]

The client will always create constraints because clients aren't 
supporting only the strongest ciphers and protocols. That's the reason 
why people configure more than one cipher and try to rescue SSL 3.0 from 
the POODLE.

> No: because I couldn't prove that it isn't AES-256, because the server
> couldn't prove that it is, because the only way to do so would be for
> the server to give me its ticket encryption key, which would defeat the
> purpose.
>
> Well, I tell a lie: the server could give the client the ticket
> encryption key for expired tickets issued to the same client.  But this
> means having a per-client set of keys, which means having some client ID
> to derive keys from, probably a public key that the client can
> demonstrate it has possession of the corresponding private key, and so
> on and so forth -- all much, much too complex.
>
> The client already has to trust the server for all sorts of things.
> Having to trust it to handle ticket encryption appropriately is not much
> more to ask, especially since any reasonable choice on the server's part
> is such a large optimization/win over not having session resumption that
> it's worth the risks of the complexity of session resumption (because
> the alternative is risking less deployment).

Uh … nope …

> So you want the server to say "fine, I'm using the XYZ cipher that you
> wanted", and now what changes?  The server can't prove that it did / the
> client can't prove that the server didn't.  What did we gain, besides
> more [in this case worth-less] complexity?

Uh … nope …

> One answer: someone could audit the server's compliance with this.  But
> who?!  Not the client.  Some authority perhaps, which then opens a can
> of worms.  And then what do we gain?  What about clients who end up
> getting weaker ticket encryption ciphers than the server's preference?
>
> Nico

Telling people to use appropriate keys during all involved steps is 
exactly what I propose and absolutely nothing of what you are alleging 
me of.

 > Key strength **MUST** be at least of equal strength for ticket/token 
encryption of the strongest supported cipher. Thus not downgrading any 
of the available ciphers that can be used for communication. [3]

I'm getting the uncomfortable feeling that all I've written so far was 
in Klingon …

Regards
Richard

[1] 
http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_HANDSHAKE 
"Negotiating a secure TLS tunnel is a complicated process, […]"
[2] 
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_prefer_server_ciphers
[3] The RFC shouldn't use the word 'negotiated' because it apparently 
isn't understood correctly.