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. The idea is not to allow the client to gratuitously inform the server that it is engaged in reuse while not attempting to reuse by requesting fresh tickets anyway. The idea is to attempt a reuse of the presented ticket, by havving the server not return anything back if it is still good. > 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. The ambiguity is harmless. If the server no longer accepts tickets the next reuse will elicit a full handshake, resulting a new ticketless session. The client's existing ticket will get flushed. > It is much clearer if there is a bidirectional signal about > negotiating ticket reuse. There an opportunity for a signal in the reverse direction, but not the one above. Rather, a useful reverse signal could be: I never accept a previously used ticket, do not attempt reuse. I would support that signal. > 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. My point (made above) is that the client signals are NOT orthogonal. Reuse implies 0 or 1 at the server's discretion. > 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. This scenario doesn't quite work. It can't reuse "some", it can only request to reuse (again after the current resumption) the one it is presenting. If that one is not reusable, the server issues a replacement, either way the client still has 4 usable tickets. > 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. Yes, that's because reuse does not need multiple tickets. Indeed long ago upthread we discussed the fact that multiple tickets should generally only happen on full handshakes (or at least infrequently, rather than on each resumption). Successful resumption should typically yield at most 1 ticket, otherwise the number of tickets indefinitely outpaces the number of connections. The text added to describe that issue is fairly minimal, it should ideally be expanded, but I am not going to make this a point of contention. But if indeed it makes sense to have the client signal how fresh tickets it wants to get should a full handshake rather resumption takes place, because: - While it prefers reuse, the server may not support it - The client not only supports reuse, but also supports a multi-slot ticket cache, and reuses tickets round-robin. then indeed one may envision a signal that indicates the number of tickets to send on full handshake (what this extension really should mean to servers), but otherwise perhaps reuse on resumption, or else a single unconditional ticket. For that to happen, the reuse signal would be a separate bit, but splitting the signal across two extensions makes for rather complicated server and client code to get this right. Therefore, if that's the way forward, then I'll take the high bit as a resumption indication, with the ticket count in the low seven bits. If you tweak the shape of the signal to work for you, I'll not be fussy. Let's just get something that solves the whole problem. -- Viktor. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls