[quicwg/base-drafts] Client storage of tokens should be independent of other stored state (#3152)

Nick Harper <notifications@github.com> Fri, 25 October 2019 03:20 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AA2F21200EF for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 20:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Status: No, score=-3 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_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NiA3OuGIU3ic for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 20:20:28 -0700 (PDT)
Received: from o11.sgmail.github.com (o11.sgmail.github.com []) (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 EEC4B1200F3 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 20:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=lyTR1NQWTblfMF3cKkXMk9s4PPU=; b=ebTQdpaILYXLPADm JSt1k6vuZiCGLtU047n4ZuBv++Ml6kjHSSY534X8+iE2zEinkYbRz94mj5LgcSdM n0piOgZtozIjwWQi/TX7S3dWCbk8g+mEUTCR58kThQLU5rS3KKWCpNHWfkFUAWVM hpuLpbv7VXHBthF03H7xkoAlOt8=
Received: by filter1179p1las1.sendgrid.net with SMTP id filter1179p1las1-3333-5DB2673F-13 2019-10-25 03:08:47.674175837 +0000 UTC m=+619980.705061964
Received: from out-20.smtp.github.com (out-20.smtp.github.com []) by ismtpd0067p1mdw1.sendgrid.net (SG) with ESMTP id L1NmGN-CTnmArtFnnyCHzA for <quic-issues@ietf.org>; Fri, 25 Oct 2019 03:08:47.431 +0000 (UTC)
Date: Fri, 25 Oct 2019 03:08:47 +0000
From: Nick Harper <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6FLL6IVPE7PLG2QI53X6T4VEVBNHHB5CF55Y@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3152@github.com>
Subject: [quicwg/base-drafts] Client storage of tokens should be independent of other stored state (#3152)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db2673a881b_364f3f95a84cd95c748e"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3YAuwhqpmEhCFFxJWq0f5ReCzAkldNoo3oFq bQ4Fd5XJilqVGFA3EtnQpgmpv/V3KXTZ5PqEVwuFkIy/pX+UVbm/tclh9VNaI5ohkb7GPBwm2y0up4 SbXIte1rOEbzPdzqwm6XHvY3qfgi20sI9FKMWqFyP0EPAHDti4kcei4QgD1ugMJk3kP3XsqOhon7vm A=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/4EIbRQaqcd2_OM47ZMoLM44hkfQ>
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, 25 Oct 2019 03:20:31 -0000

For a 0-RTT resumption in H3, a client needs 4 pieces of state previously received from a server:
1) a NewSessionTicket
2) Transport Parameters
4) a token (from a NEW_TOKEN frame)

The last isn't strictly necessary, but without it the server is likely to burn a round trip with a Retry packet to prove the client controls the source address.

On a given connection, there is only one server SETTINGS and Transport Parameters, though there may be multiple NewSessionTickets and tokens.

The first 3 pieces of state are necessarily required to have come from the same connection. A NST (from any connection) is needed since without it resumption can't happen. Transport Parameters and SETTINGS must come from somewhere for 0-RTT to be useful; the obvious and currently specified place is the SETTINGS and Transport Parameters that were sent on the same connection the NST came from.

There's no such need that the 4th piece of state come from the same connection as the others. The token is used to prove that the client controls the address the packet is purportedly coming from. This can be done separately from any crypto state (in the NST), application state (SETTINGS), or the rest of the transport state (Transport Parameters).

For a client to store the state needed for 0-RTT resumption, one possible implementation is to create cache entries containing an NST, TP, and SETTINGS. It's easy to do that where the TP and SETTINGS get duplicated N times, assuming N NSTs were received on a connection. If M tokens were received on that connection, and tokens need to be added to those cache entries, either the M tokens need to be paired to the N NSTs somehow, or all M tokens are in all N cache entries. This introduces noticeable complexity to a client's session cache implementation to correlate unrelated things.

It should be clarified that the client doesn't need to associate the token with the rest of the state needed for 0-RTT. #3150 has suggested wording for that clarification.

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