Re: [TLS] Unifying tickets and sessions

[Nico Williams <[e-mail]>]

On Wed, Oct 22, 2014 at 08:59:05PM +0200, Richard Fussenegger wrote:
> On 10/22/2014 8:46 PM, Nico Williams wrote:
> >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
> [...]

It does imply that the client at least constrained the choice of cipher.

This is unnecessary complexity.  I thought we were all for simplifying.

> 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

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

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

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?

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