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.
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. 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. 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. 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. Yours, Daniel On Tue, Nov 5, 2019 at 8:32 PM Martin Thomson <m...@lowentropy.net> wrote: > There was a lengthy discussion after the last time this was discussed. > Can I request that an editor (or a chair) summarize that discussion and the > resulting actions (if any)? I was involved in that discussion, but I don't > see any changes from that. I'm totally OK with publication as-is, but I > want to make sure that nothing got dropped. > > p.s., it might make sense to include some advisory text on prioritization > of tickets vs. application data. I can see a naive implementation of this > seriously degrading application performance. For instance, it doesn't take > that many tickets to fill an early TCP congestion window. > > p.p.s., yes, if you keep issuing last calls, I will keep finding new > things. > > On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote: > > All, > > > > This is the working group last call for the "TLS Ticket Requests" draft > > available at > > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/. > > Please review the document and send your comments to the list by 2359 > > UTC on 19 November 2019. > > > > Note the the GH repo for this draft can be found at: > > https://github.com/tlswg/draft-ietf-tls-ticketrequest > > > > Thanks - J&S > > _______________________________________________ > > 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 > -- Daniel Migault Ericsson
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
