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 there a 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.
Thanks & Regards,
Raja Ashok
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
