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

David Schinazi <> Tue, 29 October 2019 23:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18339120119 for <>; Tue, 29 Oct 2019 16:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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] 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 CL0D4rbQ1MGT for <>; Tue, 29 Oct 2019 16:04:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E594D120128 for <>; Tue, 29 Oct 2019 16:04:09 -0700 (PDT)
Date: Tue, 29 Oct 2019 16:04:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572390249; bh=Yr5SKUGpG/0v5rtTM0m5kgFbUb6JG9HrHo1Wdyv1tRY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iaymNjqJMmDo1amcgyJ+tEUO3a2Os58GewDddEu6ICNGjH1SnqYWE3aTcjBvituMl KDSNMUN1OLI8yTOWSZqAlqgIcYmP8UZWM4xR0HKYzIRnpJgpGpmfMJzz3EbLrxevea 9sAumf0fcvzakcIvcM0LEokbuOuFr2flUgu+WNVU=
From: David Schinazi <>
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_5db8c5692b3fa_400f3f9f9d8cd96814977a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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, 29 Oct 2019 23:04:12 -0000

DavidSchinazi commented on this pull request.

> +NEW_TOKEN frame, the server generates the alternative initial salt by calling a
+pseudo-random function, embeds that initial salt into the token which is then
+encrypted, and sends a NEW_TOKEN frame that comprises of the generated token and
+the alternative initial set.
+When the client reconnects to the server by using the provided token and the
+alternative initial set, the server first checks if the version number field of
+the incoming packet contains one of the alternative version numbers it
+advertises, then if that is the case, applies the corresponding packet type
+modifier to recover the correct packet type.  If the recovered packet type is an
+Initial packet and that packet contains a NEW_TOKEN token, the server decrypts
+the embedded token and recovers the alternative initial salt, uses that to
+decrypt the payload of the Initial packet.
+When the server is incapable of determining the alternative initial salt, it can
+send a Version Negotiation packet that instructs the client to use the default

Let's assume the presence of an on-path attacker that can drop, forge and rewrite packets. This attacker is interested in parsing the SNI and ALPN. The attacker lets the client's first QUICv1 connection through, and the client gets a token with alternate version and salts, under the cover of encryption. Some time later, the client wants to open a second connection and sends an obfuscated initial with the new version and salt. The attacker can pretty easily figure out that the first packet is an Initial even with the 2bit XOR. The attacker modifies some bits in the token, and recomputes the checksum then sends the modified packet to the server, leaving the version intact. The server verifies the checksum then fails to decrypt the token. The server sends VN. The client then retries with QUICv1 using its original token. The attacker performs the same modification on that token, and recomputes the checksum and initial auth tag, then sends the packet to the server. The server will again fail to decrypt the token, it sends a retry, the client tries again with the retry token, which the attacker leaves alone, and the connection successfully establishes with QUICv1. The **attacker has successfully forced a downgrade** to QUICv1 and was able to extract SNI and ALPN.

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