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 <n...@cryptonector.com> > 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 -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
