Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Viktor Dukhovni <[e-mail]>]

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.