> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni <[email protected]> wrote: > > On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote: > >>> Sorry, no idea what that above means. And is it simpler than the >>> proposal under discussion (which got some fine-tuning in early >>> feedback)? >> >> So one proposal in above is we treat 0 tickets as "ensure I have a valid >> ticket, either this one or a new one" and all other numbers are straight >> asks for that many tickets. > > This is indeed simpler, but it removes the ability to ask for zero > tickets, which I think was one of the intended use-cases (that's what > the 255 is for). > >> The other proposal is N means "ensure I have N valid tickets, including the >> one I used on this connection". I find both cleaner then the 0 and 255 swap. > > The problem here is now reuse is implicit, and the only way for a client > to ensure that it gets a fresh ticket, is by asking for 2. > > So I now see where you're coming from, and it was worth a try at > simplification, but I don't think it works out. The reasons for > two sentinels is that in fact are three separate cases. > > 1. Client wants no tickets > 2. Client wants to try to reuse an existing ticket > 3. Client wants n > 0 fresh tickets. > > I don't see how to handle 1 and 2 cleanly without two sentinels.
I think Watson’s point (which I fully agree with) is that sending the value “0” already means “the client wants no tickets”. The document already explains this usage. Thus, you don’t need a sentinel value to express that case—is what the value of N already intuitively means. 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. The ticket reuse signaling that is proposed really is orthogonal to the *count* of tickets. When requesting a number of tickets, there is a signal in one direction from the client about how many tickets it wants; and the server signals back by issuing some number of tickets. There isn’t much ambiguity. On the other hand, the proposed sentinel value indicates “I’d like to reuse tickets if I can”, but without any additional signaling from the server about the support of ticket reuse, a server response containing no tickets is ambiguous—maybe it means ticket reuse is fine; maybe it means the server isn’t giving out any more tickets and won’t allow resumption. It is much clearer if there is a bidirectional signal about negotiating ticket reuse. Beyond that, it seems odd to mark a Boolean sent by the client to ask for ticket reuse in an integer that counts numbers of tickets. It’s not that one value (255) is precious, but it means that these orthogonal concepts can no longer be communicated separately. Let’s imagine a client that had received 4 tickets the first time around, on request, and then wanted to either reuse some of them or ask for 2 more. Keeping the ticket request just a number and having a separate message for the reuse Boolean allows that. Allocating a sentinel means that a request for reuse to a server that doesn’t support reuse now loses the ability to request a particular number of tickets. Thanks, Tommy > > -- > 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
