As Martin noted, this seems to be a pretty simple idea, but am curious if others feel that way.
Curious about the choice on the limit of 255 identifiers versus something smaller. If the max ticket age is one week that could theoretically be almost 5 years of tickets right? spt PS - Thanks for not code squatting ;) > On Apr 12, 2018, at 23:15, Chris Wood <caw...@apple.com> wrote: > > Hi everyone, > > Below is a pointer to a new I-D describing an approach for clients to request > session tickets via a new post-handshake message. This is useful for > applications that perform parallel connection establishment and racing, e.g., > via Happy Eyeballs. It should also help reduce ticket waste. More uses and > details are given in the document. > > We would very much appreciate feedback on the mechanism utility and design. > > Best, > Chris > > Begin forwarded message: > >> From: internet-dra...@ietf.org >> Date: April 12, 2018 at 8:07:35 PM PDT >> To: David Schinazi <dschin...@apple.com>, Christopher Wood >> <caw...@apple.com>, Tommy Pauly <tpa...@apple.com>, "Christopher A. Wood" >> <caw...@apple.com> >> Subject: New Version Notification for draft-wood-tls-ticketrequests-00.txt >> >> >> A new version of I-D, draft-wood-tls-ticketrequests-00.txt >> has been successfully submitted by Christopher A. Wood and posted to the >> IETF repository. >> >> Name: draft-wood-tls-ticketrequests >> Revision: 00 >> Title: TLS Ticket Requests >> Document date: 2018-04-12 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf..org/internet-drafts/draft-wood-tls-ticketrequests-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ >> Htmlized: https://tools.ietf.org/html/draft-wood-tls-ticketrequests-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests >> >> >> Abstract: >> TLS session tickets enable stateless connection resumption for >> clients without server-side per-client state. Servers vend session >> tickets to clients, at their discretion, upon connection >> establishment. Clients store and use tickets when resuming future >> connections. Moreover, clients should use tickets at most once for >> session resumption, especially if such keying material protects early >> application data. Single-use tickets bound the number of parallel >> connections a client may initiate by the number of tickets received >> from a given server. To address this limitation, this document >> describes a mechanism by which clients may request tickets as needed >> during a connection. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
