Re: [quicwg/base-drafts] Requiring per application data in session ticket seems wrong (#3028)

Christian Huitema <> Fri, 13 September 2019 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D973120110 for <>; Fri, 13 Sep 2019 10:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.495
X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rQfPY_LoATgv for <>; Fri, 13 Sep 2019 10:47:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 777811200F9 for <>; Fri, 13 Sep 2019 10:47:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7CC871C0A7A for <>; Fri, 13 Sep 2019 10:47:35 -0700 (PDT)
Date: Fri, 13 Sep 2019 10:47:35 -0700
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3028/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Requiring per application data in session ticket seems wrong (#3028)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d7bd6376e3bd_7a083fca3c2cd96884013"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Sep 2019 17:47:38 -0000

I am not too worried about the server side. Servers that support multiple applications can put adequate information in the token, such as for example a server release number that points to the initial condition for multiple protocols. But I am concerned about clearly spelling out the client-side requirements, and I would rather see two parallel requirements: remember the initial conditions per ALPN+SNI, and remember the ticket per SNI.

Note that we want fast rotation of tickets for privacy reasons -- use tickets at most once if possible. That works better if we don't add rigidity, such as "only reuse tickets per SNI+ALPN". 

I think that resuming across multiple ALPN is a valid scenario. Kazuho points out that it may not be well supported in TLS 1.3, but we don't want to further ossify the lack of support.

Of course, none of that matters if we run all application protocols over HTTP.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: