On Saturday, 19 January 2019 01:32:35 CET internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Layer Security WG > of the IETF. > > Title : TLS Ticket Requests > Authors : Tommy Pauly > David Schinazi > Christopher A. Wood > Filename : draft-ietf-tls-ticketrequests-00.txt > Pages : 6 > Date : 2019-01-18
> There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-00 The security section probably should note that large server self-imposed limit could be used for Denial of Service. "Servers MUST NOT send more than 255 tickets to clients." across the whole connection or directly after Finished? For long-lived connections that may be problematic, especially when connected with multiple post handshake authentication exchanges... What about ticket count after post handshake authentication? Should we allow the client to re-issue the extension in Certificate message? Should handling of "0" in extension be special? As in, if client is asking for 0 tickets (e.g. because it will not do resumption), "SHOULD" the server respect that and send no tickets? (while the min(srv_limit, clnt_request.count) will do that, I think it may be prudent to spell it out) Is the extension negotiated every time when resuming the session, or should it be saved as part of session data by server? What if client starts advertising it, drops it or changes value in the next ClientHello that offers resumption? I'm assuming that it cannot be changed by client in 2nd ClientHello when doing Hello Retry Request handshake. Shouldn't that be stated explicitly though? -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
