> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: > >> If you did need a sentinel to indicate that you wanted to try to reuse >> a ticket (which you can always try if you want), it would make more >> sense to just make that sentinel be 255, etc, rather than creating two >> sentinels. > > Sure, if you want to swap my 0 <-> 255, that'd be fine by me, then > 0--254 are "natural", and 255 means "only as needed". If that's what it > takes to reach a compromise, I'm on board. > >> The ticket reuse signaling that is proposed really is orthogonal to the >> *count* of tickets. > > Except that it really isn't. Reuse means: 0 tickets or 1 ticket when > the one presented is or soon will become unusable. There's no way to > decouple that from the ticket count.
I don’t see why one should limit the number of tickets that can be requested to only 1 in a case in which a client wants ticket reuse, since the entire point of this extension message is to allow requesting multiple. I understand that there may be some scenarios in which a client requests multiple on the initial handshake, and then wants only one more after that, but that’s not necessarily the case. For example, I connect once, and request 4 tickets so I can do happy eyeballs attempts (one for v4 and v6 on each Wi-Fi and Cell, say). When I try to connect later, I end up using all four of those tickets on attempts, but only one succeeds. Now I want 4 more, but only have one connection. If you wanted to have your ticket reuse signaling in this case, you’d want to express “either give me 4 new tickets, or let me know I can reuse the previous four”, in which case overloading values in the number of tickets is indeed reducing the expressivity of the mechanism. Tommy > > > -- > Viktor. > > _______________________________________________ > 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
