On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> I've read the draft, it looks quite useful and reasonable. It would
> be good to see this published.
>
> I have one idea (implemented in OpenSSL 1.1.1 on the server side)
> that may be worth mentioning in this context (and perhaps even the
> draft):
>
> - By default, OpenSSL TLS 1.3 servers only vend multiple (two)
> tickets on full handshakes. Resumed sessions issue just one
> ticket.
Thinking about this some more a related issue comes to mind. A
client with (what it believes to still be) a valid reusable ticket
may want to tell the server that does not *need* a new ticket, ...
But, this should not preclude the server from issuing an updated
ticket when the presented ticket has expired (necessitating a full
handshake) or will soon expire and should be replaced.
For example:
The Postfix SMTP server maintains a sliding window of two STEKs,
one for encrypting/decrypting new session tickets, and another
just for decrypting older tickets. A fresh STEK is created
once an hour (by default), and the current active STEK becomes
the old STEK.
When a client presents a ticket encrypting with the current
STEK, no replacement ticket is issued, but when a client presents
a ticket encrypted with the old STEK, a replacement ticket is
issued under the fresh STEK.
A server that has a similar STEK rotation approach should be able
to conditionally refresh a client's ticket that is stale, while
otherwise honouring the client's signal that it does not need
more tickets at present.
Therefore, there is I think a need for two separate "no new tickets
required" signals.
A. The client has no intention to perform (further?) resumptions,
No tickets at all required.
B. The client is happy to keep using the current ticket so long
as it is still fresh, but would like periodic refresh if the
ticket gets stale from the server's perspective.
i. If the presented ticket is expired or stale and a new
one is needed, the server is asked to return just one
ticket.
ii. If the ticket is fresh, return no tickets.
Therefore, it would be useful for the extension to distinguish
between these two use-cases, perhaps an optional flags field, with
use-case B indicated via one of the flag bits?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
