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

Christian Huitema <notifications@github.com> Fri, 13 September 2019 04:28 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317651200E0 for <quic-issues@ietfa.amsl.com>; Thu, 12 Sep 2019 21:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.899
X-Spam-Level:
X-Spam-Status: No, score=-7.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRX8qQDQ_6ch for <quic-issues@ietfa.amsl.com>; Thu, 12 Sep 2019 21:28:30 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3227D120088 for <quic-issues@ietf.org>; Thu, 12 Sep 2019 21:28:30 -0700 (PDT)
Received: from github-lowworker-943b171.ac4-iad.github.net (github-lowworker-943b171.ac4-iad.github.net [10.52.22.59]) by smtp.github.com (Postfix) with ESMTP id 843F61C0A87 for <quic-issues@ietf.org>; Thu, 12 Sep 2019 21:28:29 -0700 (PDT)
Date: Thu, 12 Sep 2019 21:28:29 -0700
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2MEVYDLM33XMS2OPV3RBNX3EVBNHHB2ZES4M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3028@github.com>
Subject: [quicwg/base-drafts] Requiring per application data in session ticket seems wrong (#3028)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d7b1aed75f8f_661e3fb265acd968783af"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/nYn1giktk6BWVIsbsBjLkkhWRMM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 04:28:32 -0000

In the new section 5.4. of the transport draft, "Required Operations on Connections", we see a requirement that _When implementing the server role, applications need to be able to:_

o  ...

o  _if Early Data is supported, retrieve application-controlled data from the client's resumption ticket and enable rejecting Early Data based on that information._

I read the corresponding text in the HTTP draft, and I understand that the idea is to remember the HTTP Settings when resuming an HTTP connection. That's fine, but it seems to assume that tickets are tied to a specific ALPN. Otherwise, if a server supports several applications over the same port, then the clients need to keep track of the ALPN used when the ticket was received.

There is no such requirement in TLS 1.3 proper. In Section 4.6.1. of RFC 8446, "New Session Ticket Message", we can read that _Clients MUST only resume if the new SNI value is valid for the server certificate presented in the original session and SHOULD only resume if the SNI value matches the one used in the original session._ Notice that there is no mention of the ALPN. We can thus expect the ticket store to be indexed by SNI, plus also some consideration about certificate explained later in the text.

There are of course lots of reason for a server to support multiple ALPN over a single port. For example, the server might support H3 and H3.1. Or it might want to provide access over port 443 for DNS over QUIC, IMAP over QUIC or other such applications. With TLS 1.3, they can do that, demux on the ALPN, and 0-RTT will work fine. But if we make the session tickets application specific, that won't work.

Which is why I think the idea of putting HTTP settings in the session ticket is ill conceived.






-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3028