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 <[email protected]>
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".
>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to