Hi Chris, Thanks for the responses, please see my comments inline.
Yours, Daniel On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <c...@heapingbits.net> wrote: > 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. > > That is my point, in my opinion a hint is under specified. > > 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. > > On the contrary, I think I understood it correctly. > > 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. > The target is the spoofed source IP address. > > Best, > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
