Re: Packet number encryption

Christian Huitema <huitema@huitema.net> Thu, 08 February 2018 23:54 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 4B9F712711E for <quic@ietfa.amsl.com>; Thu, 8 Feb 2018 15:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Q4WDjiBUwJII for <quic@ietfa.amsl.com>; Thu, 8 Feb 2018 15:54:54 -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 55E41127011 for <quic@ietf.org>; Thu, 8 Feb 2018 15:54:54 -0800 (PST)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ejw1f-0008BL-Kn for quic@ietf.org; Fri, 09 Feb 2018 00:54:51 +0100
Received: from [10.5.2.18] (helo=xmail08.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 1ejw1A-0001FD-LQ for quic@ietf.org; Thu, 08 Feb 2018 18:54:44 -0500
Received: (qmail 16669 invoked from network); 8 Feb 2018 23:53:47 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 8 Feb 2018 23:53:47 -0000
To: quic@ietf.org
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <CAGD1bZauKbucs_5n7RQbK8H2HiyfiqpGVEcKreGA6umhMBSFgg@mail.gmail.com> <CABcZeBPNrc-9vANSH02r++p53s6gN4pVB8DMd80nUxOhKTp3dA@mail.gmail.com> <CAKcm_gMvHSBhpUvsQCCkV2_o+d_wchF3R3L6H8mp6nKNaaRmSw@mail.gmail.com> <CY4PR21MB0133CCAA6807469BA983D00BB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <CABkgnnW4xr_YzpsvCxaJJgcQdBTuX=Yv735_sdd4VoMfji8mbA@mail.gmail.com> <CY4PR21MB0133C759D4A08A4988B641B2B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <bdf88936-8edc-d56e-ee59-c9d597058edd@huitema.net> <CY4PR21MB01337C8A700E58B49D90B712B6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <CAOYVs2pi8-NVuS+crNMfjsP-n5upK3=5tPeQ8OSGpOvL6RTrjA@mail.gmail.com> <CY4PR21MB0133A1117B2733BBCF049C5FB6FC0@CY4PR21MB0133.namprd21.prod.outlook.com> <MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30@MWHPR08MB2432.namprd08.prod.outlook.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net>
Date: Thu, 08 Feb 2018 13:53:46 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30@MWHPR08MB2432.namprd08.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------7ABA0C44FA03DDADB6B4054E"
Content-Language: en-US
Subject: Re: Packet number encryption
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.28)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5o52OcSnHZJXsHmbfQFqnBYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fur0SniUZO2YupYKxd874kyB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RQ9KsNiMTLNuVe41G8phqGPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA/d90Ehtjr2Rr9EnHIEiQBkONoJfh+XjGSeeT90H/uIGA ixD6iqREQNDQmKfhrLECCDSE/o0T+R9dqKqbajE0/GbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWnDLQOyxbLULlVOPz78QcU/fFcHV2tQAVqGdj/zM7G/GArVPZLiHwNOHBLhYro6nu5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jjX66YPvEnpGtusePTahrnEetrQ>
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: Thu, 08 Feb 2018 23:54:57 -0000

On 2/8/2018 1:13 PM, Mike Bishop wrote:

> #2 won’t work.  The packet number is an input to the AEAD nonce, so
> you have to get to the packet number before you can decrypt the
> payload.  It can’t be based on anything internal to the encrypted packet.
>
>  
>
> In Martin’s proposal, it’s using a combination of the encrypted
> payload (which requires nothing to access) and some stored state on
> each endpoint, which requires only the Connection ID to look up.  You
> want the thing you XOR by to be constantly changing, or it becomes
> easier to look at sequences of obfuscated packet numbers and start
> drawing inferences about what the XOR value is.  If overhead is the
> primary concern, I think there are a couple approaches that might
> allow you to precompute values and amortize the cost of doing the
> encryption step.  (At the cost of keeping the table of precomputed
> values, of course.)
>
>  
>
> I still think Jana’s pushing in the right direction here:  Let’s agree
> on goals, and then see if we can craft a design that meets those
> goals.  I hear you saying that low overhead is a goal, which I think
> we can all agree on.  I also think I hear you saying that 1-1.5%
> overhead is too high, but it sounds like there’s less agreement on
> that.  You also raise an interesting point that some clients will care
> less about linkability because they will never intentionally migrate.
>

I think Victor said it best, "Obfuscation is just encryption done
poorly." Either we encrypt, or we don't. But there is no such thing as
an obfuscation middle-ground. Obfuscation would just be a speed bump,
easily broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent
linkability:

1) Martin's PR, in which the packet number is encrypted using sensible
crypto;

2) Or, leaving the packet number in the clear but using different
encryption contexts for each path, and using separate packet sequences
for each path.

The second option requires more computation when explicitly setting up a
new path. The connection ID would be used as part of the "salt" when
deriving connection contexts. The packet number on each path will start
at 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards
for each path/Connection-ID, and constraining ACK to be per/path, or
alternatively adding a PATH-ACK frame that indicates the path for which
packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus
per packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which
is more complex than option 1, but the cost will be amortized over the
duration of the path.

3) Option 2 requires more complex data structures and ACK management,
thus increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet
number effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric
encryption operation per packet, while making the code significantly
more complex, and at the cost of not protecting against PN ossification.
The way I see that, there is hardly any debate.

-- Christian Huitema