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

Raja Ashok <rashok.ietf@gmail.com> Wed, 25 March 2020 09:30 UTC

Return-Path: <rashok.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 60FB83A0883 for <tls@ietfa.amsl.com>; Wed, 25 Mar 2020 02:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4oVQADgizHIE for <tls@ietfa.amsl.com>; Wed, 25 Mar 2020 02:30:49 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEDC3A0CCB for <tls@ietf.org>; Wed, 25 Mar 2020 02:30:49 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id q9so1544900iod.4 for <tls@ietf.org>; Wed, 25 Mar 2020 02:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=61gKJmwmlbUU9+j6hZI3YfSUthIqtUtvOepwsX6Sg10=; b=XkraQkdZcCVEd8Um0Ty1p52Taa2vOK3N2lVe8OAR99adFzFO3wP5/cOr9ODBkF0fqN VllocRnuYiuyMkgp2oLlQQ+O60lkS6BLnztYchsxDU7fFj+94hRnK8hYKYyTRGZnM1lv o+zlsUy00QN3C8ZaAq3O3W8/F2TjwEEaxamem1Hx410g+dmHW3jsGwm1hlNobHG21/V7 H5O2XNjE/+GtKrkQCvHh1k2IxZkDZAOz9YfBi7DbF8r6sBdpLx2JBTwgMfB+D6UnHw9t UCfJGtH7vUuUD8BBlWuy6cJMswoAzWKNt+otDyPRdB+ZEDVkQQ/x97jIUsNe6mjJp6He LgIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=61gKJmwmlbUU9+j6hZI3YfSUthIqtUtvOepwsX6Sg10=; b=D0sN9kW48p63+kNLvWdWONvk3vyuqrUUzhVrUolmyzRn9uvnGaSmt5WTp0nOr7xeUa D8DSGJ1kTMvszJnpomdaYJ5a21gBmpk1g1TEwvLqi0RqGJIrirQ4y2ovZy/1uprWitBp gL2Lhi8/BOW70kJzsPz8RLNRLSEhJIuD+pz7LTSuubyZDQipW01n0lTcuuG/Q+k5s+X4 OlBeRfysrPR5aEXCwc0Am7abP+RAQTCZtSUmqxIwlkKWAo5vD+v/ltIwJONg6/JgKgB5 WFI11NIicKRJduGrpXGFgv6Blt0irT6vgvypjDPOmTsg4X+2OzJvD0FzSQ3VpuKmGb66 IfLg==
X-Gm-Message-State: ANhLgQ39HlfSvgKHYlO7MquPR9057pBk/QwDRouL3ODGImkGbh2sHPT/ 7izPVKKGn+BinX659ej6nCM5XrCkHWvNsmTjitF/BpAZ
X-Google-Smtp-Source: ADFU+vsddp2cgYw0Qej008tsCrgD1T96wDi4PoD/mYR2d5RwYCJr5ej1a0vzYRjjEQkwFvvYFaPIS77nihkho/WOrwc=
X-Received: by 2002:a02:5489:: with SMTP id t131mr2087211jaa.134.1585128648489; Wed, 25 Mar 2020 02:30:48 -0700 (PDT)
MIME-Version: 1.0
References: <157679659723.15798.2398049069532848341.idtracker@ietfa.amsl.com> <CABZo9ZG2MRcbCZ8Dj_cgV0E9oA+TgyufKkoDfccjDP9unr4mXg@mail.gmail.com> <CACdeXiJ=NRMDFDw4xGskyfwvRgzvGHjp5RMbJDVEm1uBTnSEqg@mail.gmail.com> <CABZo9ZFphnWHn3NBisz8m7LLxvXmti1fvUch-bpQ2EJJ3vdipw@mail.gmail.com>
In-Reply-To: <CABZo9ZFphnWHn3NBisz8m7LLxvXmti1fvUch-bpQ2EJJ3vdipw@mail.gmail.com>
From: Raja Ashok <rashok.ietf@gmail.com>
Date: Wed, 25 Mar 2020 15:00:37 +0530
Message-ID: <CABZo9ZG0HWGn=9cSVt_ir5+xVT0OL4-zObUDz4WYh=BUi2YXUg@mail.gmail.com>
To: tls@ietf.org, Nick Harper <nharper@google.com>
Content-Type: multipart/alternative; boundary="000000000000043e9905a1aa869d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vmV0Q0LkVIyImOkeTqaYL8FN6Bk>
Subject: [TLS] Fwd: Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 09:30:52 -0000

Hi All,


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

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