Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)

Kazuho Oku <> Thu, 31 October 2019 09:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F23512021C for <>; Thu, 31 Oct 2019 02:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 q_XSXWt9RzWi for <>; Thu, 31 Oct 2019 02:11:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A06291200E5 for <>; Thu, 31 Oct 2019 02:11:01 -0700 (PDT)
Date: Thu, 31 Oct 2019 02:11:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572513060; bh=W2/Jjq7wWq81RuaOsMJwUijC5Nz95Vuosp3qVc+OMXM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IVsQcO+vY1c5nMLidr6r0pt5LbA/JZQ2YUUTpssYhNdnGrBPNlLQ/jbbh/LKef4Rx bMZwpzsrtTnqL12pNRy4hYfSMwXxHB9QEiuFTHsYBIiQXi7ZpODZKEfHIcTayX9uns +QZPYT9tl1qfPaEYOUOh7kg41nFcxFzKjAUshJxs=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3166/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dbaa5249e6c8_4aa63fe47cecd95c965498"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Thu, 31 Oct 2019 09:11:03 -0000

kazuho commented on this pull request.

> +* When sending a Retry in response to an Initial packet carrying an alternative
+  version number, the server embeds the NEW_TOKEN token found in the Initial
+  packet within the retry token it issues.  Once the server receives a response
+  from the client carrying that retry token and the path is validated, it
+  decrypts the NEW_TOKEN token embedded in the retry token to recover the
+  alternative initial salt that is to be used for unprotecting the packet
+  payload.
+Instead of associating a new alternative initial salt to every NEW_TOKEN token,
+a server might map a fixed salt to each of the alternative version numbers it
+issues.  Such design is not recommended, as an active attacker might build a
+list of known alternative version numbers and their initial salts and use that
+list to decrypt the payload of Initial packets using those alternative version
+numbers.  But still, having a set of version numbers and initial salts used
+concurrently is considered better than just using the default values of QUIC in
+terms of preventing ossification.

> It would be better if the client could be certain that it does indeed sent private information on the wire.

At the moment, we never provide that certainty. The only way to provide that is to send a public key in the NEW_TOKEN frame and do a DH to determine the initial salt.

We can do that, but that's essentially about porting ESNI to QUIC. My assumption has so far been that such an effort would require time, and it would be better to do that as a separet draft (e.g.,

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