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

Marten Seemann <> Mon, 03 June 2019 08:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D78C41201C3 for <>; Mon, 3 Jun 2019 01:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.806
X-Spam-Status: No, score=-6.806 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_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, 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 9xZFfg6gnkIM for <>; Mon, 3 Jun 2019 01:40:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 316091201BE for <>; Mon, 3 Jun 2019 01:40:38 -0700 (PDT)
Date: Mon, 03 Jun 2019 01:40:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1559551236; bh=kvp+i/5ZZKq6qIUr089iO4Ec8MEbvlHTyUX+KVQ5zAI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IOvxnbx19D9kf05Sa2mp8RXpSHCQ7IrSQMTxDRv/htwq5+FSzpKse9dCEGHCS4qle GcuaPToq8nEBQ1krX0JbzmF9NDzhkBwTsuQbBJH/nllOLxH53ddGsyBYgFpja49QNe 32y7ZtomJQnXao6axesGEHghpAPLg8Orhv0dB41I=
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_5cf4dd04221e8_475e3ff5860cd968135721d"; 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: Mon, 03 Jun 2019 08:40:41 -0000

When establishing a new connection, how a token was obtained doesn't play any role. Endpoints can distribute tokens by any way they want. NEW_TOKEN frames are just one way to do so, but tokens might as well be distributed out-of-band.

We made a lot of effort to make QUIC as symmetric as possible. The only exceptions are the 0-RTT feature of the handshake (we inherited this from TLS), and connection migration (which would cause a lot of corner cases). I don't understand why the NEW_TOKEN mechanism fits any of these criteria. Conceptionally, if at all, it seems to be less complexity to allow this frame in both directions.

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