Hi, Please find some comments on the draft.
In the introduction, I believe both limitations may be merged into one limitation which is the number of ticket is a server only decision. The purpose of the extension is the client providing information so the server can pick the appropriated number. I find "choose" and "hard-coded" a bit contradicting. If the server uses a hard coded value for the number of tickets, then I would understand the limitation as the server being unable to chose a value per client or per connection. This seems to me an implementation limitation and so maybe out of scope of the extension. If it is able to choose that number, the limitation is that it is a server only decision. 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. My reading of 8446 is that NewSessionTicket messages can be sent at multiple time during or after the handshake. If that is correct, it seems to me quite complex to track the number of tickets that had been sent. Typically, if I have to send them at different time how much would I send at each flight. I would rather consider the min(count, server_limit) as the number of tickets in any batch of NewSessionTicket messages. We may also ask the client to only keep the latest batch of tickets and delete the others previously sent tickets. The ability to request 255 tickets with one byte can be seen as an amplification vector, especially when a server sends directly the tickets after its Finished message. I believe that additional text in the security consideration could be added. Yours, Daniel On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <c...@heapingbits.net> wrote: > > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
