On Wed, May 3, 2017 at 12:35 PM, Nico Williams <[email protected]> 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. 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. > 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. > > 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. A client could say "Don't send me a STEK-based ticket", and this can be enforced by requiring those tickets to be smaller than the RPSK in size. The client at least knows that the ticket couldn't possibly have been self-encrypted. Though obviously it says nothing about how good a job the server is doing of keeping the keys secret. -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
