Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Viktor Dukhovni <[e-mail]>]

> On Oct 9, 2019, at 9:04 PM, Martin Thomson <[e-mail]> wrote:
> 
> I think that the discussion Victor started about the number of tickets you might want to supply being different for a resumed connection is a sensible one, but I would caution against servers making inferences, especially in light of a very clear signal from clients.  Advice for client implementations might be wise, so that servers are less motivated to make these sorts of decisions.

THanks for the above.  I share much the sentiment.  There's
just one thing I see no way to do, without a somewhat more
nuanced interaction between client and server.

  * The client has a what it believes to be a valid ticket
    and is willing to re-use it, and would prefer to avoid
    the cost of replacing it on each resumption.

  * The server is happy to allow re-use of still valid
    tickets by clients, but needs to know whether the
    client wants a new ticket (because it never re-uses).

  * The server would like to vend a new ticket only when the
    old one needs to be refreshed (ticket lifetime or STEK
    rotation).

In the context of the draft as-is, such a client and server
have a time arriving at a mutually compatible configuration.

  1. If the client requests zero tickets, the server might
     decide the client never wants tickets.  Perhaps here,
     we could say that if the client in fact presented a
     resumption PSK, then it should get zero tickets most of
     the time, but 1 if the ticket needs to be replaced.

     [ This may not quite work right if the presented resumption
       PSK turned out to already be expired and a full handshake
       took place.  In that case the server may not retain any
       knowledge of the original resumption attempt by the time
       the handshake is complete. And for PSKs that fail to
       decrypt, it may not be possible to know whether the PSK
       even was a ticket-based resumption attempt or not. ]

  2. If the client requests one ticket, the server can't
     distinguish between clients that want 1-to-1 replacement,
     because they implement single-use, and those that only want
     one if needed.

  3. When a client gets a new ticket, it has no idea whether the
     original one is still valid, and so must discard the old and
     switch to the new.  So servers that vend a new ticket each
     time force clients to constantly update their ticket store,
     which is sometimes problematic.

Therefore, I am trying to see whether there's a bit of wiggle-room
here for better coordination between server and client.

The simplest I've been able to come up with is to make 0 mean
send no tickets, and 1 mean send 1 as needed, and for n >= 2,
mean send n-1 unconditionally.  But perhaps some else has a
more elegant design that addresses the above?

-- 
	Viktor.