Re: [quicwg/base-drafts] Binding settings into session tickets (#2790)

Nick Harper <notifications@github.com> Thu, 01 August 2019 18:19 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 116BD120147 for <quic-issues@ietfa.amsl.com>; Thu, 1 Aug 2019 11:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 AIKoxeXgOILl for <quic-issues@ietfa.amsl.com>; Thu, 1 Aug 2019 11:19:54 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A7D12013E for <quic-issues@ietf.org>; Thu, 1 Aug 2019 11:19:54 -0700 (PDT)
Date: Thu, 01 Aug 2019 11:19:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1564683593; bh=Kgow9eKsQ0MRnSTOIpkk7GDukJSGQmuGZ6jKXTUDgHQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pgQ7CGhCQ3KuhF2zd/bv7/WnruWUDwN840T0U/4i1N7kn9vPBjKUlajHgHGr/DzXv ksU2eVQHwBdKNc8iIAHqDB6b1FPxAGUEfpLtu7b42REz1y9wDB4YicHhrWqP79WvH9 tqeqgumK6kmMrjrENbWjeYhX3sVpLtD37nFQJ2Hw=
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK636B5QGNA344Z25ZV3KBP4TEVBNHHBWLNEKI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2790/517402067@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2790@github.com>
References: <quicwg/base-drafts/issues/2790@github.com>
Subject: Re: [quicwg/base-drafts] Binding settings into session tickets (#2790)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d432d4929c89_41f03fc8ab4cd96c325e8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nharper
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/msE709Imc7am2RPIUkaI1gxrvbc>
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: Thu, 01 Aug 2019 18:19:56 -0000

I don't think the clients should be choosing whether to remember SETTINGS with tickets.

Imagine the following connections (Cn), on which NewSessionTickets (NSTn) and SETTINGS (Sn) are received in these orders:

C1: NST1, S1
C2: S2, NST2
C3: S3

NST(n) is used to do 0-RTT resumption for C(n+1), and early data is accepted by the server in all cases. The server has correctly remembered the settings that applied to the previous connection to reuse in the new connection.

If the client remembers the tickets without the corresponding settings frames, then when it opens C2, the client will assume the default SETTINGS for early data, and then use S2 for the rest of the connection. Meanwhile, the server assumed S1 for the early data, and S1+S2 for the rest of the connection. In C2, the client sees S2 before NST2, so it saves its current SETTINGS state (which is S2) with the NST. Now, when the client opens C3, it uses S2 for early data, and S2+S3 for the rest of the connection. The server's perspective of settings for C3 is that S1+S2 applies for early data, and S1+S2+S3 applies for the rest of the connection.

If the SETTINGS frame is only optionally bound to tickets, then the client and server will have differing perspectives of which settings apply to a connection. Worse, this view will continue to diverge when tickets are issued and used on resumed connections, because the SETTINGS frame received on a 0-RTT resumed connection is a delta.

The right answer is that the first (and only) SETTINGS frame is bound to tickets. This means that a ticket received before a SETTINGS frame MUST wait for the SETTINGS frame, and also means the server MUST send a SETTINGS frame (if it is going to send NSTs).

-- 
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/2790#issuecomment-517402067