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

Martin Thomson <notifications@github.com> Wed, 30 October 2019 03:55 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6D120821 for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 20:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qme7KJL2yBbw for <quic-issues@ietfa.amsl.com>; Tue, 29 Oct 2019 20:55:54 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA16E120052 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 20:55:54 -0700 (PDT)
Received: from github-lowworker-2e54e43.va3-iad.github.net (github-lowworker-2e54e43.va3-iad.github.net [10.48.17.27]) by smtp.github.com (Postfix) with ESMTP id A9D078C10D0 for <quic-issues@ietf.org>; Tue, 29 Oct 2019 20:55:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572407753; bh=XEtY6pap5FD4Lfc5bGut2omb7/AIPwd7o+XqDLZeLdk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bo2uj4mAZ3Sf2LuPAmbdEHEhaZDgQS3KA5gMA6V76kG2bDtBBMgZpM59V4k+wKkLD 6nt9iJ1dd4QllORahS1unWePvbuHw4ImOTH0ucJP8TsxjCx55htcSSKBiZHG36q0ce Q10exQZoIs46OqSnxqUs7rMg0TThPbVI8O1YRCCI=
Date: Tue, 29 Oct 2019 20:55:53 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3SPHG2H5ATQ7GP5HF3YY6ETEVBNHHB5HRKFQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3166/review/308948794@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3166@github.com>
References: <quicwg/base-drafts/pull/3166@github.com>
Subject: Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db909c99a98e_155a3fe81fccd96c83220"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/yOqZUXwDCPVzAM7MvYf0jMTIiqs>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 03:55:57 -0000

martinthomson commented on this pull request.

I'm concerned about the lack of any sort of commitment here.

Let's say that I pack some entropy into my tokens.  Using that along with a static key that I have configured I can regenerate the 21 bytes I need to decode the Initial packet that I receive.  I advertise any version (maybe except for v1, but in practice you can provide a different salt for v1 off the NEW_TOKEN salt).  The same static key (in reality, something derived from it, my key hygiene isn't that poor) is used to remove protection from tokens.

That works, but only until I lose the key.  When that happens, I will start to receive packets with tokens that I can't parse.

But now I have a packet that I can't process, is that a version that I don't understand, or a packet that I can't decrypt?  The natural path here is toward the latter, because the server likely has a new key that is used to create new salts for all those versions.

This is a whole lot easier if we force the server to commit, because then the server has to manage the fallback case.  It makes this more brittle, in the sense that you need to make the static key more durable, but I think that it would be reasonable to expect a server to do that.  They probably have to manage session ticket keys in this way.

> @@ -2721,6 +2721,66 @@ between endpoints.  Application protocols SHOULD define rules for handling
 streams that are prematurely cancelled by either endpoint.
 
 
+# Alternative Initial Set {#alternative-initial}
+
+In order to avoid ossification of the cleartext and obfuscated fields of QUIC
+packets, a server can announce an alternative set of initial values to be used,
+which is comprised of:
+
+* Alternative version number; a 32-bit unsigned number that is to be presented
+  on wire in place of the version number specified in this document.  This value
+  MUST NOT be a reserved version ({{versions}}).
+
+* Packet type modifier; a two-bit value that is to be applied as a bit-wise
+  exclusive or (XOR) to the most significant bits of the Initial, Handshake,

We have two choices for the placement of these bits in the NEW_TOKEN.  0bXXTTXXXX or 0bXXXXXXTT.  The former might be easier to apply, the latter might be easier to explain.

> @@ -2721,6 +2721,66 @@ between endpoints.  Application protocols SHOULD define rules for handling
 streams that are prematurely cancelled by either endpoint.
 
 
+# Alternative Initial Set {#alternative-initial}
+
+In order to avoid ossification of the cleartext and obfuscated fields of QUIC
+packets, a server can announce an alternative set of initial values to be used,
+which is comprised of:
+
+* Alternative version number; a 32-bit unsigned number that is to be presented
+  on wire in place of the version number specified in this document.  This value
+  MUST NOT be a reserved version ({{versions}}).
+
+* Packet type modifier; a two-bit value that is to be applied as a bit-wise
+  exclusive or (XOR) to the most significant bits of the Initial, Handshake,
+  0-RTT, and Retry packets. This XOR is applied after the packets are encrypted
+  and before they are decrypted.

So... This isn't totally clear.  There are two "encryption" or "decryption" operations that might apply: the AEAD for packet protection and the masking for header protection.

I think that you mean to say that the value you feed into the AAD for packet protection is unmodified and this alteration only applies afterwards.

However, I would prefer it if were applied to the raw values so that the XOR is also authenticated by packet protection.  Then you have a clear order of operations for applying this information that matches the order of fields:

0. encode the packet
1. replace the version
2. mask the type (if long header)
3. apply packet and header protection using the new salt

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3166#pullrequestreview-308948794