On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > ``` > > > Servers MUST NOT send more than 255 tickets to clients. > > > ``` > > > > > > per what? session? at a time? connection? > > > > This is all per session. We can state it explicitly in the next version. > > so this count needs to be kept as part of session and impacts connections > that > perform resumption?
Sorry, I meant connection: "Clients may indicate to servers their desired number of tickets for *a single connection* via the following "ticket_request" extension" This is a simple hint for servers. Nothing more. No state needs to be stored past connection establishment. > > > what's the expected behaviour with tickets and post-handshake > > > authentication? Are tickets sent after PHA also bound by this limit? > > > > As mentioned earlier, there is no effect, so we left it out. We're happy to > > accept text should you think it's needed. > > If the I-D states that servers should not send more tickets than the client > asked for, and then send exactly that amount, then they won't be able to send > new tickets after PHA and remain compliant. > > Yes, it's completely up to the server to decide if to send tickets after PHA > or not, and I'm not suggesting that the client should request for tickets in > one of its PHA messages, much less expect or require them, but sending > tickets > after PHA is reasonable and explicitly stated behaviour: > > RFC 8446 Section 4.6.1: > For instance, the server might send a new > ticket after post-handshake authentication in order to encapsulate > the additional client authentication state. > > so the I-D should explicitly state what's the expected behaviour in that case. > > IMHO, the extension should be used for the tickets sent right after the > handshake, it should not put an upper bound for the tickets that a server can > send in a single connection. For a very long lived connection (especially if > the connection uses KeyUpdate messages regularly), the initial tickets may > expire. Server may notice that and send a new group of tickets then. Since these hints are not mandatory to honor I don't think we need to describe this case. In particular, this is a valid case where ignoring the SHOULD is fine, in my opinion. If the draft required that servers MUST NOT send more tickets than what's requested, then yes, I think these details would be important. > > > > ``` > > > > > > Clients MUST NOT change the value of TicketRequestContents.count in > > > second ClientHello messages sent in response to a HelloRetryRequest. > > > > > > ``` > > > > > > 'A server MUST abort the connection with an "illegal_parameter" if the > > > value of the extension changed, it was added or removed in second > > > ClientHello.' ? > > I don't think this is necessary. > > given past discussions on this mailing list, I don't think this is entirely > obvious.... > > Then what about the addition or removal of extension being forbidden? Can we > add something like this?: > > ``` > The presence or absence of the extension MUST be maintained in second > ClientHello message when compared to first ClientHello in connection. > ``` That works for me. We can add it in the next version. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
