On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > Hi, > > The current version is clearer than the previous one. However, as I > understand the document, it still seems very asymmetric in the sense > that it does not provide the client the ability to enforce a number. I > believe more guidances/specifications are needed on how to interpret the > count value. Interpretation is usually based on implicit assumptions of > today's usages, and explicit signaling should, in my opinion, be preferred. In > other words, I believe that long term interop will benefit from these > additional specifications.
I disagree with this assessment. The document is clear on this: A supporting server MAY use TicketRequestContents.count when determining how many NewSessionTicket messages to send to a requesting client, and SHOULD place a limit on the number of tickets sent. The number of NewSessionTicket messages sent SHOULD be the minimum of the server's self-imposed limit and TicketRequestContents.count. As has been stated before, the count is a *hint* to the server, nothing more. > The problem stated in the introduction is that the server needs some > information from the client in order to generate the appropriated number > of tickets. In fact the client is likely to be the one that better knows > the number of tickets to be generated, but the current text does not > enable the client to enforce that number. Instead this is entirely left > to the server. As above, I think you're misunderstanding the point of this document. Ticket requests are hints to servers. > Typically, if a device does not want to have more than one ticket. It > should be able to indicate one and be sure it will only receive one > ticket. The current specification does not prevent multiple tickets to > be sent by the server. Right, nor should it. Again, that's not a goal. > The server can ignore the count value (MAY) even > though it is known to support the extension. This means that a server > could support the extension while still having a hard coded number of > tickets. In addition, (SHOULD) let the server determining the number of > tickets. > > Possible ways to address my concerns could be to limit the count value > to the number of tickets generated during the KEX, and a server MUST NOT > exceed the counter value. The text would need more guidance on how the > server SHOULD behave when emitting at different time in the KEX - after > the Finished message and after the post handshake authentication. I don't think any text changes are needed to address these comments. > The security consideration should in my opinion consider the fact that a > client over UDP/DTLS may use the count value as an amplification factor > to have the server flooding a target. The current text only seems to > consider the computation aspect, not the bandwidth. If that cannot > happen, it might be beneficial to add it. However, when a server sends > tickets right after the Finished, it seems to me that can be used as an > attack. I'm not convinced this is useful to add. The target here is the client (attacker) that requested tickets. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
