Hi Daniel, Please see inline below.
On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > Hi, > > Please find some comments on the draft. > > In the introduction, I believe both limitations may be merged into one > limitation which is the number of ticket is a server only decision. The > purpose of the extension is the client providing information so the > server can pick the appropriated number. I'd prefer we didn't merge them, though admittedly I don't feel strongly about this one way or the other. > I find "choose" and "hard-coded" a bit contradicting. If the server > uses a hard coded value for the number of tickets, then I would > understand the limitation as the server being unable to chose a value > per client or per connection. This seems to me an implementation > limitation and so maybe out of scope of the extension. If it is able to > choose that number, the limitation is that it is a server only > decision. Indeed. I think this is fairly clear from the draft. How would you suggest this be clarified? > I understand the meaning of count is the higher limit of ticket and the > server can provides any tickets between 0 and count. If that is > correct, this could be clearly stated and indication to chose an > appropriated value for each cases may be provided. The document states this: A supporting server MAY vend TicketRequestContents.count NewSessionTicket messages to a requesting client, and SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. Is this not sufficient clear? If not, how can it be improved? > I would rather see the count value as a hard line from the server with > a MUST NOT instead of a SHOULD NOT statement. As this is merely a hint from the client, I don't think this is necessary. > My reading of 8446 is that NewSessionTicket messages can be sent at > multiple time during or after the handshake. If that is correct, it > seems to me quite complex to track the number of tickets that had been > sent. Typically, if I have to send them at different time how much > would I send at each flight. I would rather consider the min(count, > server_limit) as the number of tickets in any batch of NewSessionTicket > messages. We may also ask the client to only keep the latest batch of > tickets and delete the others previously sent tickets. This behavior is orthogonal to the intent of the hint. Imagine, for example, clients sent no hint and servers decided to do what you describe above. The same issues would still exist (tracking some count sent on the server, deciding which tickets to use on the client, etc.). Thus, I don't think this would add much value. > > The ability to request 255 tickets with one byte can be seen as an > amplification vector, especially when a server sends directly the > tickets after its Finished message. I believe that additional text in > the security consideration could be added. The text lists this: Servers SHOULD place a limit on the number of tickets they are willing to vend to clients. Though we can add a parenthetical to indicate that failure to do so may result in doing more work that intended. Thanks for the feedback! Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
