> On Nov 19, 2019, at 5:20 PM, Daniel Migault > <daniel.migault=40ericsson....@dmarc.ietf.org> wrote: > > Hi, > > Just to followup the discussion. I support Viktor,'s proposal as it provides > the ability to the client to specify what it wants rather than let the server > guess. What I am wondering is whether we are catching all possible client > "policies" or whether we should consider some additional reserved values. > Typically I do not see case where 200 tickets may be requested, so we may > have some place for reserved bits if needed. > > I see my comment of how tickets are generated as complementary. > > Yours, > Daniel > > > > On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni <ietf-d...@dukhovni..org > <mailto:ietf-d...@dukhovni.org>> wrote: > On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote: > > > > That also works, effectively treat 0xff as "-1", but all other > > > values as non-negative, with 0 a request for re-use. An isomorphic > > > encoding, but without the "-1". > > > > [Jeremy had a more eloquent description of the vague sketch of an idea that > > I had in my head] > > Jeremy's "isomorphic" encoding works fine for me, and is likely less > confusing. > So, FWIW, it has my support. Fleshing it out a bit more, I am proposing: > > - 0xff => send no tickets > > - 0x00 => reuse requested: > + send no tickets if presented ticket is accepted and reusable > + send one ticket if presented ticket is accepted, but is not reusable > (expired, or reuse is not allowed). > + Also send one ticket if session could not be resumed and a full > handshake was performed. Clients that reuse tickets don't need a > separate one for each session, so one per full handshake should > suffice. > > - 0x01-0xfe => client wants single-use tickets: > + send up to that many tickets on full handshake, > + however, generally send just 1 ticket on resumption, or when > replacing tickets during long-lived connections. This helps to > reduce chronic ticket "oversupply".
Having a recommendation to generally just send one ticket doesn't address the motivating use case for the document, which is Happy Eyeballs (connection racing). Having multiple tickets is required in a steady state, so we shouldn't recommend against that. Any client that wants to only do the reuse case can just not use this extension. Thanks, Tommy > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <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
