Hi Hubert, The reason I would prefer the client to enforce the count is that if a client has constraints - memory / bandwidth, he wants to make sure its preference is respected, and this independently of the evolution of how the hint will be interpreted in the future or depending on different implementations.
I understand the reasons for SHOULD. At least this should be documented. To address your first point, of course the specification applies to the server that support the extension. Your second concern is solved by limiting the NTS of KEX. The third point is addressed by the minimum of the (count, server_nbr). Note that I see count as a maximum. Overall I do not think this would add much complexity. The only complexity I see is when a server sends NTS at different time in the KEX. Yours, Daniel On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario <hka...@redhat.com> wrote: > On Thursday, 14 November 2019 17:19:55 CET, 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 > > <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. > > we discussed it on the list, and the reason for such phrasing is > multi-fold: > - the server doesn't have to implement this extension, as such, as per the > basic TLS 1.3 RFC, it can send arbitrary number of extensions to client, > so clients, to be RFC compliant, need to be able to process abritrary > number > tickets at arbitrary time after handshake finish > - making value in extension the exact number requested by client makes the > implementation much more complex: is that number per connection? per > session? what about post-handshake authentication? what about Session > Ticket > Encryption Key rollover? do we really want the client to abort the > connection > if server misbehaves and sends too many or too few tickets? > - while the client may think that it knows how many tickets it requires, > that > information may be out of date. If an HTTP server has been brought > down, > a > connection to a given SNI may lead to a redirection page - in such cases > there is no point in server sending tickets. > > so please, tell: what issue would be solved by making the count requested > by > client mandatory? > Because I see it only increasing complexity of implementation for no > benefit. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > 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
