Re: [quicwg/base-drafts] Clarify that unlinkability is required for NEW_TOKEN tokens. Changes … (#2647)

Martin Thomson <notifications@github.com> Wed, 24 April 2019 06:40 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 07FE712002E for <quic-issues@ietfa.amsl.com>; Tue, 23 Apr 2019 23:40:11 -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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 zYfh9SUB4-qq for <quic-issues@ietfa.amsl.com>; Tue, 23 Apr 2019 23:40:09 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6446C120150 for <quic-issues@ietf.org>; Tue, 23 Apr 2019 23:40:09 -0700 (PDT)
Date: Tue, 23 Apr 2019 23:40:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556088007; bh=8JbtyVRn43VyOPygoxQ8vZJiYBxaZ03mlzaRdlYjVM8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GUC2L5UlQz4Px1w3NK6HPpx28V9OOczEYsd3rBVnkqreQnVHjvLRabhEiZmvlreR8 NL6rgQtHqZxj9UojeTyzaP9cY+/ZCU02e5VXXqrhewQ7DeNz2sfT+VY0PNdQlG5dhd gAhIIeh4y/On/rAHM5Vri29auttffF+vAXkDWzwA=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2ETECA67ECMO5D3GV2ZU3UPEVBNHHBUBA3UE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2647/review/229921565@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2647@github.com>
References: <quicwg/base-drafts/pull/2647@github.com>
Subject: =?UTF-8?Q?Re:_[quicwg/base-drafts]_Clarify_that_unlinkability_is?= =?UTF-8?Q?_required_for_NEW=5FTOKEN_tokens._Changes_=E2=80=A6_=28#2647=29?=
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cc004c7e700f_172e3fe9794cd964138085"; 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/hX8n0MusnJo2RYOahQBU1S8vpBE>
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: Wed, 24 Apr 2019 06:40:11 -0000

martinthomson commented on this pull request.



>  A token SHOULD be constructed for the server to easily distinguish it from
 tokens that are sent in Retry packets as they are carried in the same field.
+The token SHOULD NOT expose linkability; i.e., information that lets observers
+correlate the connection that is using the token and the one that issued the
+token.
+
+Unlike the token that is created for a Retry packet, there might be some time
+between when the token is created and when the token is subsequently used.
+Thus, a token SHOULD have an expiration time, which could be either an explicit
+expiration time or an issued timestamp that can be used to dynamically calculate
+the expiration time.  A server can retain the expiration time in the server-side
+store, or embed the encrypted value in the token.  It is unlikely that the
+client port number is the same on two different connections; validating the port
+is therefore unlikely to be successful.

Yes, but the point is that you can't generally rely on it being the same between two connections.  I'm sure that those in those special circumstances will know to ignore this.

-- 
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/2647#discussion_r277973408