Re: Getting to consensus on packet number encryption

Kazuho Oku <kazuhooku@gmail.com> Wed, 18 April 2018 04:48 UTC

Return-Path: <kazuhooku@gmail.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 211D012421A for <quic@ietfa.amsl.com>; Tue, 17 Apr 2018 21:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yH8qYS02yoLy for <quic@ietfa.amsl.com>; Tue, 17 Apr 2018 21:48:21 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6F11201F8 for <quic@ietf.org>; Tue, 17 Apr 2018 21:48:21 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id g14so291110pfh.3 for <quic@ietf.org>; Tue, 17 Apr 2018 21:48:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l9uPp+I/oY+SmzJZrRy6weTJh6S9QVFPB7zWyn9EBvU=; b=u4nxeykdWEmyHWGGGpsYwwlV5Kebl1Kh9LQgrG2DGEpTjo1mvVI8qTpaQFZFbeYFRG SVc0/Pmiu/GVSrkCWRnRedmHls8t/hmAOHcWN9iHEl5BKEioJht/Xe3Qqemq2PpaIROK pcSJ2Rw4vuquDNIDsF7nQ5hPAAunB8y6+P23bmT2TGvwDxak8VOYE4rEg9Xm0YztO2R/ SPZNheAMf01blR/EzSrt8piHowXdXGwizQBu6GxTcXtgWewV3qJTnP5/PiIBI6D55Aky PknZsDGnx+1SnppLcplyKRBLilkMb4C65wBRR5Lmq7Mc+y45QoW24FWLT/xt7l41fMpv aFUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l9uPp+I/oY+SmzJZrRy6weTJh6S9QVFPB7zWyn9EBvU=; b=nZuJ8pRsryt35/wNOwgzAzQxw3WZsFS1UzqLVD1+oFZJGpPZ3J52Suf01sIfUJLMz2 1CZwIP7HcGIonkpoHWJiagVvXMjWolBU4L1rwsyM1QYuUCfbC4OEL0ZOs2L2yBmbj1tw uQsGN1OMftuwImFE/zPAg6XnknH9tcqLNazaZeBAJXqZ7Rjb5RSokxBw6BYAmievVilm IWQZ/9jmstE747B6tcvanNdVqyErWmgECQ28r2p6sKCbN/YMi8Ffif4vzg9pSLj391er cID5z08DXXLv7WYzfP1itIcyyaWnxVAtaKh3rMRdhXUYA54JfGb7rzm5WJnW2vlsP506 aRAg==
X-Gm-Message-State: ALQs6tA2qK6XVF1Jdc0vDpCU4Z8DgviGXByePJ6R+Kt+/IrwA1J+8+Oq yj1VMgHPOJniod1WEMKizgEOmJelVAc6B/IDXuFpYg==
X-Google-Smtp-Source: AIpwx4/n+MXcf95Jc8n1/N9djIUcUSytOSnd9HGX/2xBwmyhFgK099GazL43yiZ4duBgemCOdPZwnU+lHtm1oyhyTpg=
X-Received: by 10.167.128.207 with SMTP id a15mr602463pfn.116.1524026900568; Tue, 17 Apr 2018 21:48:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.130 with HTTP; Tue, 17 Apr 2018 21:48:19 -0700 (PDT)
In-Reply-To: <1412f856-5eaf-1c7a-266f-2b4d77355647@huitema.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net> <21C36B57-6AE2-40EF-9549-7196D7FA9B45@tik.ee.ethz.ch> <B176FC07-887D-4135-B01E-FE8B4986A5EE@mnot.net> <CAKcm_gOCeocLyrYpOS7Ud332xdz3xHSH0psPN8T6BGRjoL9ptQ@mail.gmail.com> <CY4PR21MB0630FA0EDD343396AD414641B6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <CAN1APde13JTzCvKFFvMd183Fka6QGD1kGBjsa9fcoLrYeA2hsA@mail.gmail.com> <CY4PR21MB0630C0FD4FBECBFEC3C863BBB6A40@CY4PR21MB0630.namprd21.prod.outlook.com> <047d2ff0-ff8b-64c9-8983-0ecabeb9fea5@huitema.net> <B0F49097-F77A-4831-B68B-4266AA880A86@tik.ee.ethz.ch> <74E2F5C2-66AD-4902-8A4A-E481CC0A015C@fb.com> <75050158-3812-44F1-A01E-D70EED7FDFD6@tik.ee.ethz.ch> <BY2PR15MB0775B4ACF7DB9124E89016F0CDB00@BY2PR15MB0775.namprd15.prod.outlook.com> <c8e60ba4-d6be-c4fc-5bac-d569a28fb4e8@huitema.net> <CANatvzx=1a+7FHbMVBzEMEY4cODL0N5gELt02dofvQDgz=LaAQ@mail.gmail.com> <1412f856-5eaf-1c7a-266f-2b4d77355647@huitema.net>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Wed, 18 Apr 2018 13:48:19 +0900
Message-ID: <CANatvzz56-VyKzdkd-wySTHYUTHFDDVw8_krKm=YwmmuXaD17w@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
To: Christian Huitema <huitema@huitema.net>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NBiIX3mkBwSwZ6MN2uiGYKs_oUY>
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: Wed, 18 Apr 2018 04:48:23 -0000

Hi Christian,

Thank you for updating the wiki page. And the comparison table is awesome.

Looking at that, (it might be unsurprising but) my two cents go to
merging #1079 and continue to consider a hardware-friendly variant as
an extension (until it turns out to be unnecessary).

The reasons I prefer #1079 are:
 * it is easy to implement in software
 * efficient on wire
 * computational overhead is negligible
 * crypto is secure and agile to changes
 * majority of the implementors seem to be happy with the approach

On the PR I see a proposal of a hardware friendly variant (that
modifies AES-GCM). All of us might end up happy with a single scheme.

If some of us (especially those interested in hardware crypto offload)
are unhappy with the solution, we can consider having a negotiated
extension of QUIC that uses a different scheme.

For that variant, my preference goes to the one using nonce due to the
following reasons:
 * it requires the least change from #1079 in terms of key scheduling
 * it would have the broadest range of hardware support

The latter point is from my assumption that most if not all of devices
that have AES-GCM support are capable of accepting an explicit nonce,
while some if not many of them might be incapable of doing some 32-bit
or 64-bit crypto for decrypting PN.

2018-04-18 3:58 GMT+09:00 Christian Huitema <huitema@huitema.net>:
>
>
> On 4/16/2018 11:15 PM, Kazuho Oku wrote:
>> Hi Christian,
>>
>> Thank you for writing the wonderful summary.
>>
>> Reading it, I think that I now see two issues with the alternative
>> approaches that use a weaker cipher (i..e. alternative PN encryption,
>> 64bit encrypted PN).
>>
>> > We can argue that the algorithm does not have to be as robust as
>> AES.. The main requirement is to prevent real time analysis of
>> sequence numbers by middle-boxes. This is achieved as long as the
>> encryption key cannot be retrieved in a short time by the
>> middle-boxes. If they could do that, we would be once again on the
>> path to ossification. XOR and simple obfuscation probably don't meet
>> that goal, but IPCrypt probably does, and a more robust algorithm
>> certainly would.
>>
>> As you state, it is true that preventing real time analysis is
>> important. But are we sure that we do not need to consider offline
>> attacks? I would be interested in arguing about the other requirement
>> than ossification: privacy.
>>
>> A pervasive monitor might collect CIDs and encrypted PNs that were
>> being used, and then use the encrypted PNs as a source to correlate
>> CIDs to reconstruct a QUIC connection. Are we sure that a weak cipher
>> does not leak such trace?
>
> Yes, you are right. The argument about tolerating weak algorithms only
> applies if we have another solution to prevent linkability, such as
> different sequence numbers and encryption keys for each Connection ID.
> So it comes with a high cost in term of software complexity.
>
>
>>
>> Considering that, I think that the alternative approaches should have
>> per-CID PN encryption keys, even though I am not sure if there are no
>> other privacy-related issues.
> Yes.
>>
>> The other issue is about crypto agility. #1179 has agility in sense
>> that the corresponding CTR mode is used for encrypting the PN. OTOH,
>> the two alternatives using a simple cipher are not agile. So we might
>> need to define two types of simpler ciphers for PN encryption, if
>> consider that privacy issues (like the one above) might arise in the
>> future.
> Yes.  I updated the Wiki page to reflect your comments.
>
> -- Christian Huitema



-- 
Kazuho Oku