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

Reply via email to