On Wed, May 3, 2017 at 11:29 AM, Nico Williams <n...@cryptonector.com> wrote:
> On Wed, May 03, 2017 at 12:10:12PM -0400, Viktor Dukhovni wrote: > > > On May 3, 2017, at 12:01 PM, Salz, Rich <rs...@akamai.com> wrote: > > > The protocol design should avoid setting traps for the unwary. > > > > No, that responsibility falls on libraries. STEKs are not a trap for the > > unweary. Libraries that support static session tickets by default can be > > viewed as such a trap. So the onus to fix this is on us (OpenSSL team) > > not the TLS protocol. > > A big +1 to this. > > I think it would terrible if we couldn't have resumption at all because > one common implementation mishandles old key deletion. > With the improvements in 1.3 all of this FS only pertains to 0-RTT data, not resumption in general. One solution would be to have two, or three sub-types of ticket exchanges: Type 1 - same as now, except remove the ticket age, generally intended for resumption. Can be used multiple times. 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. Type 2.2 - Same as 2.1, but required to be smaller than RPSK in size, to prevent self-encryption. Though honestly, I'm not even sure 2.2 is a great idea any more, maybe too much complexity, and we can just measure the size and enforce things that way. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls