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