I think that the discussion Victor started about the number of tickets you might want to supply being different for a resumed connection is a sensible one, but I would caution against servers making inferences, especially in light of a very clear signal from clients. Advice for client implementations might be wise, so that servers are less motivated to make these sorts of decisions.
Nits-wise, there are lots of lowercase instances of "may", which is fine, but most can be replaced with "can", except one that I think could be a "MAY": Clients may send this extension in ClientHello. Otherwise, I only skimmed this. If I get a chance, I might send more detailed editorial comments, but I didn't see any technical reason to hold this back from WGLC. On Sat, Sep 28, 2019, at 09:59, Christopher Wood wrote: > This version addresses some of the comments we received from Hubert a > while back. We think it's ready to go for WGLC, modulo whatever nits > folks find. :-) > > Best, > Chris (no hat) > > On Fri, Sep 27, 2019, at 4:47 PM, internet-dra...@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : TLS Ticket Requests > > Authors : Tommy Pauly > > David Schinazi > > Christopher A. Wood > > Filename : draft-ietf-tls-ticketrequests-02.txt > > Pages : 6 > > Date : 2019-09-27 > > > > Abstract: > > TLS session tickets enable stateless connection resumption for > > clients without server-side, per-client state. Servers vend an > > arbitrary number of session tickets to clients, at their discretion, > > upon connection establishment. Clients store and use tickets when > > resuming future connections. This document describes a mechanism by > > which clients may specify the desired number of tickets needed for > > future connections. This extension aims to provide a means for > > servers to determine the number of tickets to generate in order to > > reduce ticket waste, while simultaneously priming clients for future > > connection attempts. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-02 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
