Re: [TLS] draft-ietf-tls-ticketrequests-05

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 01, 2020 at 04:52:18PM +0000, Hannes Tschofenig wrote:
> Hi Tommy, Hi David, Hi Chris,
> 
> I read through the draft and have a few questions.
> 
> 1) Is it really necessary for the client to use two values to
> differentiate the tickets it wants with a new session and with
> resumption. It feels a bit over-designed. I would just have one
> value and that alone would be super useful already.

Consider a client that does:

- Parallel connections
- Does not reuse tickets

Such client needs enough tickets to cover the multiple connections
in case of fresh handshake (might be 5-10 or so), but only needs to
replace the tickets for current connection (1 or 2) in case of
resumption. So any single value will result in oversupply or
undersupply.

> 2) This sentence confuses me:
> "
>    Servers SHOULD NOT send more tickets than requested for the handshake
>    type selected by the server (resumption or full handshake).
>    Moreover, servers SHOULD place a limit on the number of tickets they
>    are willing to send, whether for full handshakes or resumptions, to
>    save resources.
> "
> 
> Shouldn't the sentence say:
> "
>    Servers SHOULD NOT send more tickets than requested for the handshake
>    type (resumption or full handshake) indicated by the client.
> "

The server might not want to actually honor request to send 255 tickets.
Even if ticket minting is a fast operation, 255 of them might take non-
trivial time (and bandwidth).

> Even then, I believe the sentence should actually say MUST NOT instead
> of SHOULD NOT. If the client is already taking the effort to indicate
> that it does not want more than a certain number of tickets then it
> might have a reason. I am thinking about the case where the client
> indicates that it does not want any tickets then it would be strange
> for the server expressing support for the extension and still send
> tickets.

If the client signals 0 tickets for handshake and 0 tickets for
resumption, then reasonable interpretation is that client does not
support resumption at all, and it is waste of resources to send it
any tickets.

But how should server interpret client saying it wants 1 ticket for
full handshake and 0 tickets for resumption? A reasonable interpretation
is that client does support tickets and is is willing to reuse tickets.
So if the server is not willing to reuse tickets, the most reasonable
action is to send 1 ticket to the client on resumption (if server is
willing to reuse tickets, the most reasonable act is not send any
tickets on resumption).

Basically, there can be good reasons to send more tickets than
requested. Just that most of the time, sending more tickets will lead
to oversupply.

> 4) I believe it would make sense to define a ticket flag for the
> case where the client does not want to receive any tickets.

The sensible way to indicate that is to send (0,0) as requested
ticket count.

> 5) If a client sends the ClientTicketRequest extension during the
> full handshake is there an expectation that it sends it again in
> the resumption exchange? Would you assume that the server memorizes
> how many tickets the client wanted across the resumption handshakes?
> For example, in the full handshake I use the extension and indicate
> that I want 5 tickets. I get two tickets from the server. Then, I
> run a resumption handshake without transmitting the extension. Is
> the server expected to remember to still send 3 more tickets till
> the quota is exhausted?

I expect each connection to have its own ticket request counts.

In general, it is unsafe to cache extension values across connections
in session. Sure, one probably can not cause anything bad with this
extension, but with things like server_name, very bad stuff can happen
if those are not taken from connection handshake.


> 6) The topic of when to send the tickets is something you mention
> in the document and it is indeed an issue. Have you thought about
> allowing the client to signal to the server when to send the
> tickets? Even making a distinction between "send me all tickets in
> a batch" and "send one after the other with some reasonable time in
> between" would be helpful.

What usecases would there be in spreading tickets in time?


-Ilari