Re: Removing packet number gaps

Christian Huitema <huitema@huitema.net> Tue, 02 January 2018 02:13 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561881242EA for <quic@ietfa.amsl.com>; Mon, 1 Jan 2018 18:13:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zFItRSoeQkOL for <quic@ietfa.amsl.com>; Mon, 1 Jan 2018 18:13:16 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A1C124234 for <quic@ietf.org>; Mon, 1 Jan 2018 18:13:16 -0800 (PST)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eWC4m-0003mb-Gf for quic@ietf.org; Tue, 02 Jan 2018 03:13:13 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eWC4j-0005qo-HK for quic@ietf.org; Mon, 01 Jan 2018 21:13:11 -0500
Received: (qmail 838 invoked from network); 2 Jan 2018 02:13:07 -0000
Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 2 Jan 2018 02:13:07 -0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15C153)
In-Reply-To: <CABkgnnW89B+5Qo0u_+Wr5K0wCRZ3Wp-+CTWJbHRGGwD06hn-zw@mail.gmail.com>
Date: Mon, 01 Jan 2018 18:13:03 -0800
Cc: QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <16F84894-C3D9-4342-83EB-616759E739BD@huitema.net>
References: <CABkgnnW89B+5Qo0u_+Wr5K0wCRZ3Wp-+CTWJbHRGGwD06hn-zw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Removing packet number gaps
X-Originating-IP: 168.144.250.190
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.24)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5gP9yNhAIum9djc75Dnrb6wXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fviwdKnRFViULLhLsmA3fZmB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CjFWgoBUVwntDlC94eiuSMB7gpDNdnenm6TrtCAMOwt1x6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGGzfvfqbdVzWjqC7Wi9Hpea9ribYaFEt5OQzwoifSBR/1 1x8phGMqCLJRaypsRWHLJ1qvkkW9+eJtkgnkYIgKzFz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBCPpTKZiPZvKq7DOUCmAqiB3h1vgDbEdmhrg3iVBpdRYXfz7Ut3+jmMYKlY7u0PndGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7umUd3nGVf615qGjeNS-oRCObHQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2018 02:13:18 -0000

For clarification: are you proposing to make the encryption key and IV dependent on the connection ID, or just the packet number mask?

Also, are you proposing applying the mask before encoding the packet header on 1, 2, 4 or 8 bytes, or after that?

-- Christian Huitema 

> On Jan 1, 2018, at 5:57 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
> There are number of problems with packet number gaps that I think we
> need to address.  Most are minor.  For instance, the initial packet
> number is not close to zero, which inflates the size of ACK frames
> from the very beginning of a connection.
> 
> However, Christian just identified one that I think makes this more
> important to address: when using a new connection ID, the gap is the
> same size on both client and server.  This makes flows linkable.  The
> gaps between the last packet on the old flow and the first packet on
> the new flow can be calculated in both directions.  Flows can be
> linked by finding flows where client-to-server packets have the same
> (or very close) gaps as server-to-client packets.
> 
> With a few small tweaks to the current design, I think that we get a
> much better solution.  Here is what I propose:
> 
> Firstly, packet numbers start at zero and always increase
> monotonically, with no gaps.  A side benefit of this is that the first
> ACK frame will have a small encoding for largest_acknowledged (1 octet
> rather than 8 in most cases).
> 
> Packet numbers are never encoded directly onto the wire, they are
> XORed with a masking value.  This value will change for different
> packet protection keys, and for different connection IDs.  Client and
> server will use different values so that gaps are hard to detect.
> 
> Thus, we will have a third key derivation:
> 
>   key = QHKDF-Expand(S, "key", key_length)
>   iv  = QHKDF-Expand(S, "iv", iv_length)
>   pnmask = QHKDF-Expand(S, "pnmask", 4)
> 
> To make this work seamlessly, I'm proposing a tweak to QHKDF-Expand
> that includes the connection ID.  For that, the "Context" field that
> we currently do not use seems like a good choice.
> 
> This will mean changes to the other uses of QHKDF-Expand:
> 
> * the handshake secret can be changed to be a fixed rather than a
> derived value, so that we don't need to use the function (connection
> ID will be added during expansion into the separate keys)
> 
> * during a key update, a zero-length or fixed connection ID will need
> to be used so that there is no confusion about which connection ID was
> in use at the time the update was made (editorially, I'm not certain
> how to manage this one, I might just go back to using
> HKDF-Expand-Label directly for that)
> 
> Finally, we need to be very clear that even if the connection ID is
> omitted, those packets still use the implied connection ID in key
> derivation.  We will probably want to recommend that endpoints include
> a connection ID if they intend to support NEW_CONNECTION_ID or any of
> the related functions, at least around the time when a connection ID
> change is in place or the recipient of their packets could have
> difficulty picking the right keys.  This is already a problem of
> course, but this change would make it worse.
>