Hi, If tickets are sent right after the server Finished, before the the client Finished, these are only triggered by the clientHello - at least this is my understanding.
Yours, Daniel On Thu, Nov 14, 2019 at 11:25 AM Christopher Wood <[email protected]> wrote: > > > On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote: > > Hi Chris, > > > > Thanks for the responses, please see my comments inline. > > > > Yours, > > Daniel > > > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <[email protected]> > 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. > > I acknowledge your opinion, but as I think I've made clear, I don't agree. > Sorry! > > > > > 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. > > That would imply the attacker is able to complete a connection with this > spoofed address, no? > > > > Best, > > > Chris > > > > > > _______________________________________________ > > > TLS mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
