Re: [TLS] Security review of TLS1.3 0-RTT

[Nico Williams <[e-mail]>]

On Wed, May 03, 2017 at 01:19:35PM -0700, Colm MacCárthaigh wrote:
> On Wed, May 3, 2017 at 12:35 PM, Nico Williams <[e-mail]>
> wrote:
> > No, please don't remove the obfuscated ticket age.  Either make it
> > encrypted or leave it as-is.
> 
> If it is to be encrypted, say AEAD'd, it needs to be encrypted under a key
> that the client and server share; because the client needs to modify the
> age before sending. Moving the age to its own message, post Client-Hello,
> could solve that - so it comes out of the ticket.

Naturally.  That's why we have ticket session keys.

> That scheme is a bit weird and circular: the server would have to "use" the
> ticket to derive a key that decrypts the age, to then decide if it should
> "really use" the ticket for 0-RTT data. That seems pretty convoluted to me
> - could be a fairly complicated security proof.

It's what Kerberos has been doing for decades.  RFC4120 (before that
RFC1510).

> > Type 2.1 - Ticket intended for 0-RTT, does include the ticket age (maybe
> > > not in the ticket itself, but somewhere in the handshake), can only be
> > used
> > > once.
> >
> > No.  Give advice.  Do not remove these features.
> 
> I think the can only be used once for 0-RTT needs to be firm. Otherwise
> 0-RTT mode is insecure.

I don't agree: the application may not care.

> > > Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to
> > > prevent self-encryption.
> >
> > I don't grok this.
> >
> 
> Self-encrypting tickets require STEKs and all of their problems. [...]

Can you elaborate?  (I don't follow TLS WG that closely.  I'm from
KITTEN WG.)

Nico
--