On Sat, Nov 16, 2019 at 02:38:55AM -0800, Benjamin Kaduk wrote:
> > The -03 draft added a sentence suggesting that clients should ask for
> > just
> > one ticket on resumption, but I would like to suggest that this logic
> > belongs in the server.
>
> We should probably be emphasizing that *all* policy belongs on the server, and
> we are just defining a signal for the client to convey some information as
> input
> to the server's decision. In that mindset I'm not sure that the "subtract
> one"
> signal is the most satisfying design (though I concede that it is probably the
> most efficient encoding).
Do you have an alternative suggestion? I am indeed optimizing for a minimally
invasive change that keeps the encoding simple/efficient, at the cost of some
indirection between intended signal and its representation. As with most
things, there are trade-offs here.
We could indeed have a separate flags field, or separate counts for various
conditions:
- # to issue on full handshake
- # to issue on STEK rollover
- # to issue if server supports/does-not-support reuse
- ...
But ultimately I think it boils down to whether the client:
- can keep reusing an existing session with the ticket it already has
- needs a single new ticket to keep reusing that session
- is establishing a new session (full handshake) and wants to
use parallel connections, so may want multiple fresh tickets.
Likely the simplest mechanism that handles the above is enough, and I think the
"-1" suggestion plus a server cap at 1 ticket on resumption, pretty much
handles all three cases.
Perhaps I'm missing some important cases, and if so, it would be good to flush
those out and understand their trade-offs.
--
Viktor.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
