Hi All, https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-00
I am keen on improving this specification, so requesting all to provide feedback on this. Thanks & Regards, Raja Ashok This seems to be solving a very similar problem to > draft-ietf-tls-ticketrequests (which I see you reference in your draft). I > see two cases where this mechanism might be useful compared to the > ticket_request extension, but I'm skeptical those are useful use cases. > > The first case is if partway through a connection a client decides it > wants more tickets from the server. With the ticket_request extension, a > client can only specify at the beginning of a connection how many tickets > it wants, whereas with this TicketRequest message the client can ask for > more later. I can't think of a use case where a client would need more > tickets from this specific connection; > Consider a Video Streaming Application, which holds a TLS (HTTPS) connection to URI of lower resolution video (and audio). Based on dynamic improvement on bandwidth it might switch to higher resolution video content, which inturn might have different URIs for video and audio. At this point TLS client needs to open another TLS connection. So if TicketRequest msg support is there, at this scenario it can get ticket on the fly. Getting more amount of session ticket after handshake delays application data processing as well as some ticket might not be used. Like this lot of scenarios are there for a TLS client to choose how many tickets are needed on the fly. Basically TicketRequest msg gives 2 benefits to application - Avoid wastage of ticket - Improves application data processing by postponing session ticket msg issuance. > if a client does need more tickets it can get them from a new connection. > Consider a TLSv1.3 client opens a fresh Connection, and retrieves one ticket immediately after handshake. Now it opens 2nd connection (resumed) with ticket_request extension count as zero, by assuming not needed. But later if it needs to open one more connection based on dynamic need, then there is no way to get ticket without TicketRequest msg. > > The other case is one you mentioned in the draft: delaying sending tickets > to prioritize sending application data. There's no requirement that a > server send NewSessionTicket messages immediately after the handshake. A > server could prioritize sending application data over sending tickets and > delay sending tickets for some period of time. > As per my understanding RFC8446 says a TLSv1.3 server should send session ticket immediately after handshake. Even if it can delay, it will be very difficult to identify how long it should delay sending session ticket by prioritizing application data.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
