Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)

Martin Thomson <> Wed, 01 April 2020 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE4C03A0064 for <>; Tue, 31 Mar 2020 19:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 EgIR3kUlLSl9 for <>; Tue, 31 Mar 2020 19:38:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2ABB3A0060 for <>; Tue, 31 Mar 2020 19:38:38 -0700 (PDT)
Date: Tue, 31 Mar 2020 19:38:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585708717; bh=bNjCXtYtdSAqOK1HOTfytWDqwjuZyRgs9j/15beNT2k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Dg32OSoaExcyLRWzP5SfGqpnEGOKhnacjfGb+qJtNUMNgjIyrEKEw+56JafQ2PoRn xihgf0idmMKB/gfOQVf4FHnbn1ea6FSxAPGxO5qMUgTV0KbGCdVPFiqzQyjeVFnOmn Zvtik8N4mQlKZh51jE9Tf3ErSfUiv3E9ZwSzNrI4=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3560/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e83fead9e429_3633fceeaacd96c488129"; 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
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: Wed, 01 Apr 2020 02:38:41 -0000

So I see a number of ways forward here:

1. Do nothing.  Leave this ambiguous and potentially special.

2. Make the fields in preferred_address exactly equivalent to a NEW_CONNECTION_ID with a sequence number of 1.  But allow the connection ID to be zero-length.  A zero-length connection ID provides a new stateless reset token that is bound to the new address.  (This is a weird option that would go against previous decisions to eliminate special handling for this connection ID, but I include it for the sake of completeness.)

3. As 2, except that the new stateless reset token has connection-wide scope such that either of the provided tokens can be used.  This is more consistent with established principles.

4. Prohibit the use of zero-length connection IDs in preferred_address.  That is, you can't use preferred_address without a connection ID.  That is, preferred_address effectively is a new server address plus a NEW_CONNECTION_ID frame.

5. Something else.

>From my perspective, I rank these as 4 > 3  >> 1 > 2.  But that is largely based on my bias against zero-length connection IDs (as much as it seems like that might be good for privacy, I think that privacy is better served by the use of connection IDs).  If people intend to use preferred_address to migrate to a connection-specific address, then I'm OK with 3; we already have #3563 to cover the privacy hole that arises from that.

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