RE: Removing packet number gaps

"Lubashev, Igor" <ilubashe@akamai.com> Tue, 02 January 2018 02:15 UTC

Return-Path: <ilubashe@akamai.com>
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 DAF44126C89 for <quic@ietfa.amsl.com>; Mon, 1 Jan 2018 18:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 U4VyeygcNeCh for <quic@ietfa.amsl.com>; Mon, 1 Jan 2018 18:15:27 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 20243124234 for <quic@ietf.org>; Mon, 1 Jan 2018 18:15:27 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w022BtT8028804; Tue, 2 Jan 2018 02:15:24 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Yrzjs1GyAonq97WAedWfq+ibqowhVSlmjZ1WG66func=; b=ZQo5FEMocWSvFKPTRvXybM04g0S1tFa5Z5obkMuwkv+VQ2jBNZ7D8SEqxKh+5IQcX9h+ N7X68KaJF3T0f+VeaiH2gvdWxsfoXmei8Y9rK7/TO0ci+MSnDoPN1eVxReyO3iVs8bG8 GmhXZOB4rrGhaxLS6DV+Jjpd+GqNndXOlR2/1aPQeGcJV3r90Ks9qCw1gaQiR8i+YjFh as9ZWPKef5vxcyFa3b6L1tMmRGAbQi+zU5I6ZxQwUi3pp9QNr79DYf1s5g7lWhXaG0GZ sibXE+9kQY6VYl0XkJb8f/lE6q0pSu1L+Bl5nhgUsIpMUzLTAfUbz5hDBOa1ltpjorqg dA==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2f62x8x7f7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Jan 2018 02:15:24 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w022B4Qg021737; Mon, 1 Jan 2018 21:15:23 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2f670yr3g8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Jan 2018 21:15:23 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 1 Jan 2018 21:15:22 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 1 Jan 2018 21:15:22 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Martin Thomson <martin.thomson@gmail.com>, QUIC WG <quic@ietf.org>
Subject: RE: Removing packet number gaps
Thread-Topic: Removing packet number gaps
Thread-Index: AQHTg20GYycQfBTojkSomN6WJ1vUtaNf1wqQ
Date: Tue, 02 Jan 2018 02:15:22 +0000
Message-ID: <78d51955754d41f081561ffca6f23dee@usma1ex-dag1mb5.msg.corp.akamai.com>
References: <CABkgnnW89B+5Qo0u_+Wr5K0wCRZ3Wp-+CTWJbHRGGwD06hn-zw@mail.gmail.com>
In-Reply-To: <CABkgnnW89B+5Qo0u_+Wr5K0wCRZ3Wp-+CTWJbHRGGwD06hn-zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.35.58]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020030
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020030
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DUDSFOUYb3jpblsAub_u9roCKjc>
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:15:30 -0000

Could we use PLUS instead of XOR?  My understanding is that there is little cryptographic difference between XOR and PLUS, and it is nicer to have consecutive packet numbers on the wire...

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, January 01, 2018 8:57 PM
To: QUIC WG <quic@ietf.org>
Subject: Removing packet number gaps

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.