Subject: [TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt

From: Raja Ashok <[email-masked]>
Date: Fri, 20 Dec 2019 17:42:21 +0800

Hi All,

Requesting to go through this draft and provide your views on it.

Thanks & Regards,
Raja Ashok

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri 20 Dec, 2019, 7:03 AM
Subject: New Version Notification for
draft-rashok-tls-ticket-request-msg-00.txt
To: Raja Ashok <[email-masked]>

A new version of I-D, draft-rashok-tls-ticket-request-msg-00.txt
has been successfully submitted by Raja Ashok and posted to the
IETF repository.

Name:           draft-rashok-tls-ticket-request-msg
Revision:       00
Title:          TLS Ticket Request Message
Document date:  2019-12-20
Group:          Individual Submission
Pages:          4
URL:
https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-00.txt
Status:
https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/
Htmlized:
https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg

Abstract:
   TLS session ticket provides a stateless mechanism for server to
   resume connection with client.  As per TLS 1.3 [RFC8446], server
   always sends arbitary number of session ticket after handshake.  This
   document introduces a new message which is TicketRequest message, it
   can be send by client after handshake at any point of connection
   lifetime to retrieve session ticket.  The proposed mechanism in this
   document is only for TLS 1.3 and DTLS 1.3 and future versions.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Nick Harper <[email-masked]>
Date: Fri, 20 Dec 2019 13:59:49 -0800

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; if a client does need more tickets it can
get them from a new connection.

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.

On Fri, Dec 20, 2019 at 1:42 AM Raja Ashok <[email-masked]> wrote:

>    always sends arbitary number of session ticket after handshake..  This
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Raja Ashok <[email-masked]>
Date: Sat, 21 Dec 2019 23:53:26 +0800

> 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.

> 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