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

Raja Ashok <> Sat, 21 December 2019 15:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 563A4120020 for <>; Sat, 21 Dec 2019 07:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rp6wgDnaZPR7 for <>; Sat, 21 Dec 2019 07:53:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60434120018 for <>; Sat, 21 Dec 2019 07:53:38 -0800 (PST)
Received: by with SMTP id z12so10584338iln.11 for <>; Sat, 21 Dec 2019 07:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vQ0N5gc0xSm70HXhMlQsg8X6a9XkOhNKNLQxJWUucBQ=; b=eyhedYKc+vl8BefkhlpLkBXI/NMR/zLvTX+SJfSBehGath50g5dVze0yvzm1wi6E/J uMbi35vekCPUHsogShJFzcTEX5XXJ8wIz49dX8ehNiuH8ocyNCEHxQji0MpGaR/LSB3F 0H3u05Nmuqi0uyzXbXITs47A/hcw+lFV4WSXkphdZ+Y7943/ZXqM3qE+C7kNL7peolaS K8KZ+aWz4UbCHLIGUIFmXbx/6oRMJPsqDgHCAsqKecP3K7wqDvQ/FKv0FuGSu5B7jGHr h4E7tonX1sYPLP8p+CkexuqUoA6s5q13ZHzE0pOLP/DPgHUKvWDHD5f7bxnjoLy8hHpO rc3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vQ0N5gc0xSm70HXhMlQsg8X6a9XkOhNKNLQxJWUucBQ=; b=l4mKSEyTg6buhvH9W34SIkKFlFX6uTbujxhjr4DmSWOK2AWdpFr4GrndHgDYIgjpKa va14TVpUKpCw6/mqok0DnmlsZw0Q+FvSKGCl4JatAybV9aW527ZmImqfNavY2zztj1w8 hT+UkSefEu4k/Li7eiDQSgsY53YnokNBvc7FK/6cOoDksr/zl8o7DcZTniBXP7pGck0f +vwdUfGG12N+I53cJJxQ+irFAz346Rn1r/ogptfcFRIgKLELX45z53sXVoPYVqVE+62T M8mAgat0sGx0xYXr9M8uKm5POUfIj3VlB4fIz0hnQucscG8H95NV9wc7b27+HVB0yk/Q 8D4g==
X-Gm-Message-State: APjAAAV7rbIMM7c9zcNnUybusl/9P0dnmXJTDVX5Q2iqxcO5LJ6Q4cGs CAOvkDrpc13brBbfM7M1fwUMy2bQBbppajjGE6w=
X-Google-Smtp-Source: APXvYqwUP9QN96f6RL0TbOyprBOdbDiVJ8jejlPuVGCzSnchhzMO0nizWp/PYNb0nWJteov+zOYqKjnxQaeBdOMjTw0=
X-Received: by 2002:a92:5d8d:: with SMTP id e13mr1629225ilg.285.1576943617626; Sat, 21 Dec 2019 07:53:37 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Raja Ashok <>
Date: Sat, 21 Dec 2019 23:53:26 +0800
Message-ID: <>
To: Nick Harper <>
Content-Type: multipart/alternative; boundary="00000000000028d7ac059a38cc7c"
Archived-At: <>
Subject: Re: [TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Dec 2019 15:53:40 -0000

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

> 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