Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)

Marten Seemann <> Fri, 31 May 2019 06:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E27C1200E3 for <>; Thu, 30 May 2019 23:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.605
X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id adwVRAp5caJv for <>; Thu, 30 May 2019 23:55:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F0A312003F for <>; Thu, 30 May 2019 23:55:12 -0700 (PDT)
Date: Thu, 30 May 2019 23:55:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1559285711; bh=2ecnheIsUE8cgLun+kvCrgl+qSg+fwlbE07AsyDJ4UU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dhejBv+H1/AlnccL4G8bV/CaNFiCGYHBMrVxj1uPMViFkPriPjb94IaD/cSWEL6a2 EZrxLQxKM3nGaDu0m4fME2X2b84ZJtkju9JGbyGb7Sh2Bwzl5zzPrksqyXgsjzpOPN lxaO2lkwdFiwm72k21cqwHBesMEt9tU8ZU1B94Gc=
From: Marten Seemann <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2760/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cf0cfceeb39a_31423f9da22cd95c142626"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 May 2019 06:55:14 -0000

> While I can understand the desire, I am wary of the complexity that it might introduce. I am not sure if we could consider (and continue to consider) the use-case during the development and the maintenance of the protocol.

I don't think there's a lot of complexity here. The token is literally just an opaque blob which is transferred on one connection and reused on another connection. All the complexity of issuing, encrypting, validating and using the tokens is born by the implementations, and if p2p isn't your use case, you don't need to do anything.

> The only case you'd benefit a round trip from using a NEW_TOKEN token is when you can do 0-RTT. However, 0-RTT can only be used when a connection in the same direction has been established before. 

There are two benefits here, that apply even if you don't do 0-RTT:

1. You save one round-trip for address validation.
2. You can encode additional information into the token. For example, an implementation could encode the RTT of the old connection into the token, and use that as an initial estimate when establishing a new connection.

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