Re: [quicwg/base-drafts] Confirm Retire Prior To via Acknowledgement (#3548)

Mike Bishop <> Tue, 31 March 2020 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6B5C3A2719 for <>; Tue, 31 Mar 2020 12:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.082
X-Spam-Status: No, score=0.082 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_24=1.282, 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 8fAo3kSpkrgd for <>; Tue, 31 Mar 2020 12:07:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F95E3A275B for <>; Tue, 31 Mar 2020 12:05:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1133EA1F1F for <>; Tue, 31 Mar 2020 12:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585681527; bh=xtvmpPKBJFjpbVseA8IbQkJ3F8s0dceiW90nv1sW65k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pSa7iJXVRhwzUn9sVEml5u9QptEHr6DCZTD3PhxAZ5+V0QxS2HzssP4Wqr+ui1QFC pN+9KjGIBrP8c2bOw3HnPGKhr0BrpJ0hb7cyLEtCeVhQaRJDdFXyMEXDC84lwIEwXe ouZF+VU/VMijB93TCVE2LJa/YfThPIvoWB2zxMlg=
Date: Tue, 31 Mar 2020 12:05:27 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3548/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Confirm Retire Prior To via Acknowledgement (#3548)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e839477cfc_768e3f9a546cd9682316e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Tue, 31 Mar 2020 19:07:10 -0000

> Instead, I'd suggest keying off use of a CID issued after the Retire Prior To as indication that the RPT was received.
> In that world, I think the model is: a receiver of Retire Prior To doesn't need to use RCID to explicitly retire prior CIDs and instead as soon as it starts using a CID issued after the Retire Prior To, it's assumed all the prior CIDs have been retired. Given there's already a MUST about no longer using the new CID immediately, this doesn't seem that problematic.

The complication is that RPT doesn't have to immediately get rid of all old CIDs and start fresh; that's just one scenario.  Consider the load-balancer key rotation case:

- CIDs contain a bit to indicate if they're from key phase 0 or key phase 1.
- I've issued you CIDs under phase 0 and phase 1; your active CIDs include a mix
- I'm about to rotate key 0, so all the outstanding phase 0 keys need to get scrapped
- I send you NCID(<a CID from the new phase 0>, RPT=<your newest phase 0 CID>).
- There's no need for you to skip the phase 1 CIDs and start using your shiny new phase 0 key, but if you don't, I can't know for sure that you've dropped the old-phase-0 keys.

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