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

David Schinazi <> Wed, 30 October 2019 23:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57A0812001E for <>; Wed, 30 Oct 2019 16:38:09 -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 92O_Ct-zJnjb for <>; Wed, 30 Oct 2019 16:38:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E019120018 for <>; Wed, 30 Oct 2019 16:38:07 -0700 (PDT)
Date: Wed, 30 Oct 2019 16:38:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1572478686; bh=EA3Z6SgtuSBVD2+S1+3L70WdxEggRSB4bLkXcwQ17es=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ig+IbDwiLWTueiWyqOtnnM/L7qVjUbmV3YgLGr+F2QSdTELIyCwmXXMcO7QVJNHdg TjZovmBXZ6ztEcZD7VI8lJnqWMP81KyG+f2hFwzgE+qZGI+ekFHX+4MOzJVht4nlZy D2WqpQjfhtjN49EqsvRCurAAbHJAyc37Mt5A0s1c=
From: David Schinazi <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3166/>
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_5dba1ede80980_14493fcb3f4cd96c3324c"; 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: Wed, 30 Oct 2019 23:38:09 -0000

If I understand the latest text correctly, it's saying:
- NEW_TOKEN carries a lifetime
- if a server wants to use alternative salts, it MUST ensure that it has access to its decryption key for the lifetime of that token, otherwise handshake timeouts could occur

I don't think that'll work for our deployment. We're interested in deploying alternative salts, but our mechanism to share keys across our fleet of servers isn't infallible: it's possible that one server gets a new key before another server, and if a client hits these two servers in the wrong order, they could end up in a state where the server cannot decrypt the token. This is fine for the current uses of QUIC NEW_TOKENs and TLS session tickets, because both of those will resolve themselves in-band (via RETRY, or full handshake).

Therefore I really think we need a graceful mechanism to handle this, similar to what was added to ESNI. The question then becomes: can we design a fallback mechanism that isn't vulnerable to a simple downgrade attack.

Here's a straw-man:
- when the server sees an initial token (the one from NEW_TOKEN, not from retry) that it cannot decrypt, it sends a RETRY.
- the server takes the non-decryptable token it received from the client, and sends it encrypted inside the retry token in the server's RETRY 
- the client tries again, but this time with QUICv1 (no obfuscation) and the retry token, but we add a new transport parameter where the client sends the first token it used on this connection

This would allow the server to detect when someone messed with the token in flight, and would then close the connection. So it mitigates the downgrade attack I described [earlier](

This straw-man has many downsides, including:
- we're back to needing a checksum on the token
- an attacker can still see the SNI, but they can't do so without it being detected. This might be acceptable because the attacker can still force a downgrade to TLS/TCP today

Anyway, I'm not sure this straw-man is the way to go, but perhaps the idea of repeating tokens in transport parameters might be worth exploring to help detect this class of attack.

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