Re: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)
Martin Thomson <notifications@github.com> Fri, 25 October 2019 02:33 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 7513712008D for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 19:33:46 -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 Ypw10Di6GBKU for <quic-issues@ietfa.amsl.com>; Thu, 24 Oct 2019 19:33:44 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B161200A3 for <quic-issues@ietf.org>; Thu, 24 Oct 2019 19:33:44 -0700 (PDT)
Date: Thu, 24 Oct 2019 19:33:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571970823; bh=RPUhlzuViizRpxIL/TX2J0aCs7tWZNkW3BJHY9p3CUs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lrgNg/ik84ab4kCoUikpqRmBY/NkjXKSejnT8wz4oqpxqxvF/Zthvka862G6N+pqU iV1th3iy54A6HqJGlu5EDZTe5gEDqe7cR12A0YK3+JSZoz2VqgmreCxtf5DhGQUnaN CKvQ8o+p0DE6e8M2+xX/pldx4VeG7IrzNV2ylOM0=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2BCIDZM5QAESXMMNV3X6IYPEVBNHHB5B4MBE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3150/review/306953063@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3150@github.com>
References: <quicwg/base-drafts/pull/3150@github.com>
Subject: Re: [quicwg/base-drafts] Clarify the state a client stores with a token (#3150)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db25f07b24bc_e2d3fa5e1ecd9681196d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/hsrQ7CN0n58l-3RN83gzaES0DJI>
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 02:33:47 -0000
martinthomson commented on this pull request. This is placing a constraint on the server that I think is reasonable, but I want to test it out. If I handed out a session ticket for 0-RTT, but I wouldn't accept 0-RTT without a token, would it be reasonable for me to put additional information about 0-RTT in the token? This PR would seem to prevent that by allowing a client to switch 0-RTT tickets and tokens from two connections. @kazuho previously suggested that quicly might put some 0-RTT-related information in the token. As long as the cross-checking between token and ticket validation exists, the client doing a mix and match with incompatible tickets and tokens won't have any disastrous consequences. But it could lead to the server rejecting 0-RTT, which isn't great. Of course, the information in the token might be generic enough to match with the ticket: for instance, if it identifies "0-RTT configuration X" and the server still understands that configuration, then the information could be interchangeable and therefore usable. I'd like two things here: 1. an expression of the problem statement in the form of an issue, and 2. input from @kazuho. > @@ -1746,7 +1747,8 @@ validate a client address. Tokens are not integrated into the cryptographic handshake and so they are not authenticated. For instance, a client might be able to reuse a token. To avoid attacks that exploit this property, a server So that I don't forget: A client might not be prevented from reusing a token. > @@ -1746,7 +1747,8 @@ validate a client address. Tokens are not integrated into the cryptographic handshake and so they are not authenticated. For instance, a client might be able to reuse a token. To avoid attacks that exploit this property, a server can limit its use of tokens to only the information needed to validate client -addresses. +addresses. A server MUST NOT require the client to correlate any additional +information with a token (e.g. a NewSessionTicket). ```suggestion Clients MAY use tokens obtained from the this version of QUIC with any connection attempt for the same version. Clients do not need to consider other properties of the connection that is being attempted when selecting a token, including the choice of possible application protocols, session tickets, or other connection properties. ``` I don't think that this is a testable "MUST NOT". It's more or less axiomatic. A server can't prevent clients from attempting to use tokens. -- 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/pull/3150#pullrequestreview-306953063
- [quicwg/base-drafts] Clarify the state a client s… Nick Harper
- Re: [quicwg/base-drafts] Clarify the state a clie… ianswett
- Re: [quicwg/base-drafts] Clarify the state a clie… Nick Harper
- Re: [quicwg/base-drafts] Clarify the state a clie… ianswett
- Re: [quicwg/base-drafts] Clarify the state a clie… David Schinazi
- Re: [quicwg/base-drafts] Clarify the state a clie… Marten Seemann
- Re: [quicwg/base-drafts] Clarify the state a clie… Martin Thomson
- Re: [quicwg/base-drafts] Clarify the state a clie… Nick Harper
- Re: [quicwg/base-drafts] Clarify the state a clie… Nick Harper
- Re: [quicwg/base-drafts] Clarify the state a clie… ianswett
- Re: [quicwg/base-drafts] Clarify the state a clie… Martin Thomson
- Re: [quicwg/base-drafts] Clarify the state a clie… Nick Harper
- Re: [quicwg/base-drafts] Clarify the state a clie… Jana Iyengar
- Re: [quicwg/base-drafts] Clarify the state a clie… Kazuho Oku
- Re: [quicwg/base-drafts] Clarify the state a clie… Mike Bishop
- Re: [quicwg/base-drafts] Clarify the state a clie… Jana Iyengar