On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <hka...@redhat.com> wrote: > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > I understand the meaning of count is the higher limit of ticket and the > > > > server can provides any tickets between 0 and count. If that is correct, > > > > this could be clearly stated and indication to chose an appropriated > > > > > > value > > > > > > > for each cases may be provided. > > > > > > > > I would rather see the count value as a hard line from the server with a > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > > see my previous comments: this ignores existence of post handshake > > > authentication, ticket lifetimes and KeyUpdate > > > > I think we agree on the problem which is it is hard to have a specific > > count as tickets may be sent at multiple time during the key exchange or > > the later during the session. If the "SHOULD" is addressing this aspect I > > believe that more text is needed.. From my perspective, what I proposed I > > imagined that count was related to the maximum number of ticket provided > > **each time the server is sending tickets**. The reason for having the same > > number is that the server does not know how the client will use these > > tickets and the client does not know precisely when the server sends the > > tickets. So at the end the number of tickets sent is likely to be n*count > > when n represents the number of times during the session tickets are > > provided. > > > > My understanding of the SHOULD is that it makes legitimate for a server to > > ignore the count value provided by the client. > > yes, it looks like we are in agreement > > Sounds like something that should be spelled out explicitly in the draft. > I.e. > it should talk about groups of tickets, not tickets in connection, and it > should definitely not specify the maximum number of tickets a server can send > in a connection.
Since it's meant as a hint, removing that clause (maximum number of tickets a server can send in a connection) is reasonable, and sounds like it should address the concerns here. (Assuming we also include text which says servers should obviously place a cap on what they send, as they do today.) Would you agree? I'm really trying to avoid this becoming overly complex, as it's a very small feature. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
