> We (Chrome) definitely want this (sending cookies in 0-RTT requests), and > are doing this today with QUIC (which we can't wait to TLS 1.3-ify).
I see. So, it is quite likely that the most common usage of TLS 1.3 would send sensitive data in 0-RTT. It is unfortunate that the forward secrecy of this data is determined solely by mechanisms (e.g. tickets, client-side caches) and policies (e.g. ticket encryption key rollover time) that are outside the scope of TLS. I wonder if it would be better to give more guidance to implementations to better manage these mechanisms. For example, servers that use ticket only for 1-RTT resumption can set the ticket expiry and ticket encryption key rollover time as they do for TLS 1.2. However, servers that support tickets for 0-RTT must use a much shorter expiry/rollover period to reduce the forward secrecy window. How short should this window be in practice? Note that choosing the expiry/rollover period also determines the replay window, and it is less obvious whether the two windows should be the same. E.g. we may be happy with a 1-hour forward secrecy window, but only a 10-minute replay window? Best, Karthik
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
