> On Oct 9, 2019, at 9:04 PM, Martin Thomson <m...@lowentropy.net> 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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
