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. 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. " 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. 3) Does the server really need to send the number of tickets it is planning to send back to the client? In the draft you already indicate that the server may send fewer tickets than requested by the client. So, the number expressed by the client is an upper limit anyway. 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. 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? 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. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
