On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > 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. > > sounds good > > > > > > 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. > > huh? I see the following in the draft-02: > > Servers MUST NOT > send more than 255 tickets to clients.
I was referring to the "SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the MUST NOT above should also be a SHOULD NOT. Thanks for your patience in working through the kinks! > > > -- > 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 > Attachments: > * signature.asc _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
