Re: Getting to consensus on packet number encryption

Martin Thomson <martin.thomson@gmail.com> Mon, 30 April 2018 03:46 UTC

Return-Path: <martin.thomson@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 C36CB12D86F for <quic@ietfa.amsl.com>; Sun, 29 Apr 2018 20:46:34 -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 5L3ZqRJSOc3Q for <quic@ietfa.amsl.com>; Sun, 29 Apr 2018 20:46:32 -0700 (PDT)
Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 27B9B129C6D for <quic@ietf.org>; Sun, 29 Apr 2018 20:46:32 -0700 (PDT)
Received: by mail-ot0-x234.google.com with SMTP id w4-v6so8116055ote.12 for <quic@ietf.org>; Sun, 29 Apr 2018 20:46:32 -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:content-transfer-encoding; bh=tbZaES9RtVJ9fJT0m/QwvpeJ/4zLaW97tGtIqpJS6EA=; b=jlD5L8dPUilFFdo3J2QNM9RpZJYym7/jZYgQJ/Q1OnMEuRNUpKLcuGRL9Yh2W/bQMM ukSC1rR2mrgzeFLVhWw+S/fVQ8cZNoIsWcGQ22oG/uAWDWofGKR2zk4COPr2xqCmrPli twnIJp/ujdNsQWKdJduxoXsKKeAwDDaiax3CRERNiK90dYhnrgOh9RNRfXbT+DmsEjwp C2H20pOQD3LpKkGMY9I0xqL8EYDRMWnnoAeBhV/s6Ts8Xt+1nkPqaGYxANkBQm/kct9X 6zP+NIdPvEBwnqAvfNg+ADWfFBRZQen4Xs2cnv//aKRsErW9+q4CUz8yUYtohNS8j3kf hzMg==
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:content-transfer-encoding; bh=tbZaES9RtVJ9fJT0m/QwvpeJ/4zLaW97tGtIqpJS6EA=; b=nZQW7V5FWr4ygWjQk4K38qWVJwVQ1JTXo3DSS9CXNeXz5A6K1FVLBEJ/puSIBPZWWJ FOip3a6lJesNGj4xN7OqkT5mLWEQCjALCgOr8zhGJLM0zH2rhfAWp0ClhoOs6+ko2V75 kVEX8d7i1CcVrtDZfEWgNpVlnJKO6GfWAOTMnlv2c4yCTvTR9SDbQ0NiGrlpR2/udMlm V+/cMj4u3v9Cvac3QHgygOeQarVz+qQcIUXpLFWBHLHpByMSOpUCQkrPVXoH2KFeeJCa lsihrNDuDAi6gYyS96cckrMcRoiF0EhW1tfCXzXcd1oMgopA4k92NWGlOD7p4fX60ar7 DY1g==
X-Gm-Message-State: ALQs6tBWyve3LF2w0IseTFSt7J8A4BTMSc5j5m3SAB6F9wLpfJTxVBOa 8ApwKTZ5Kvp94mIgQluPxQD91Xgd7R+6XQhB1sg=
X-Google-Smtp-Source: AB8JxZqjINax3bz7cIJVchZIHuUFUO/fWd7pb4sOfepA3EibhZhm6grUw9rfO6jSbflUhawr3mQODkv48ZurLkpO7FU=
X-Received: by 2002:a9d:524d:: with SMTP id q13-v6mr7661327otg.241.1525059991329; Sun, 29 Apr 2018 20:46:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:29ce:0:0:0:0:0 with HTTP; Sun, 29 Apr 2018 20:46:30 -0700 (PDT)
In-Reply-To: <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>
References: <7fd34142-2e14-e383-1f65-bc3ca657576c@huitema.net> <F9FCC213-62B9-437C-ADF9-1277E6090317@gmail.com> <CABcZeBM3PfPkqVxPMcWM-Noyk=M2eCFWZw2Eq-XytbHM=0T9Uw@mail.gmail.com> <CAN1APdfjuvd1eBWCYedsbpi1mx9_+Xa6VvZ3aq_Bhhc+HN67ug@mail.gmail.com> <CABcZeBMtQBwsAF85i=xHmWN3PuGRkJEci+_PjS3LDXi7NgHyYg@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CCEFD@ORSMSX111.amr.corp.intel.com> <CABcZeBNfPsJtLErBn1=iGKuLjJMo=jEB5OLxDuU7FxjJv=+b=A@mail.gmail.com> <1F436ED13A22A246A59CA374CBC543998B5CDAD4@ORSMSX111.amr.corp.intel.com> <BBB8D1DE-25F8-4F3D-B274-C317848DE872@akamai.com> <CAN1APdd=47b2eXkvMg+Q_+P254xo4vo-Tu-YQu6XoUGMByO_eQ@mail.gmail.com> <CAKcm_gMpz4MpdmrHLtC8MvTf5uO9LjD915jM-i2LfpKY384O2w@mail.gmail.com> <HE1PR0702MB3611A67E764EE1C7D1644FAD84AD0@HE1PR0702MB3611.eurprd07.prod.outlook.com> <d8e35569-e939-4064-9ec4-2cccfba2f341@huitema.net> <CACpbDccqKoF-Y1poHMN2cLOK9GOuvtMTPsF-QEen3b30kUo9bg@mail.gmail.com> <CAKcm_gNffwpraF-H2LQBF33vUhYFx0bi_UXJ3N14k4Xj4NmWUw@mail.gmail.com> <40C1F6FE-2B2C-469F-8F98-66329703ED50@mnot.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 30 Apr 2018 13:46:30 +1000
Message-ID: <CABkgnnWayVcejHc7_DbCjCPiXNx0=45bH7ns=oaHPgB9Mr9rNQ@mail.gmail.com>
Subject: Re: Getting to consensus on packet number encryption
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7BH01VNkzeQ_3GjpY-8O79GPudQ>
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: Mon, 30 Apr 2018 03:46:35 -0000

OK, going back to the OP to close the loop on a few things.

I have updated PR #1079 to rebase it on top of the addition of a
packet length field.  As far as I'm concerned, this is now ready.  We
might later consider a few things, like varint packet numbers and
removal of the sequence number from NEW_CONNECTION_ID, but those are
separate refinements.

I'm glad to see that there is a plausible implementation of this in
hardware that isn't inordinately expensive.  I appreciate that this
complicates offload in some cases, but I still believe this to be the
best design we have right now in terms of all the competing factors
we've considered (and we've probably covered every angle now; more
than once).

My assessment is that we should merge this.  Chairs, is this your assessment?

On Wed, Apr 4, 2018 at 2:58 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Hi everyone,
>
> The editors have told your chairs that this issue is starting to block progress on other aspects of QUIC. Coming to consensus on it soon (i.e., before Stockholm, if possible) would be good.
>
> It looks like this thread has come to a natural pause. Reading through it, I think we agree there are some unpleasant tradeoffs here, but so far we have only one concrete proposal -- PR#1079.
>
> My AU$.05 - While we're chartered to produce a protocol that's encrypted as much as operational concerns allow, and that privacy is a natural extension of that (especially in light of RFC7258 and RFC6973), there is no *requirement* that we produce a protocol that is able to be accelerated by hardware.
>
> That being the case, I think we need to ask ourselves if we believe that inclusion of PR#1079 will significantly inhibit deployment of the protocol. Based on the discussion so far, that doesn't seem to be the case, but I'd be interested to hear what others think.
>
> If we can get to consensus to incorporate the PR, and folks come back later with a more hardware-friendly replacement that doesn't change the Invariants or increase linkability, I suspect the WG will be amenable to that.
>
> What do folks think?
>
> Cheers,
>
>
>> On 29 Mar 2018, at 11:39 am, Ian Swett <ianswett=40google.com@dmarc.ietf.org> wrote:
>>
>> Thanks for the nice summary Jana.
>>
>> As much as I'd love to have easier crypto HW acceleration, I've ended up arriving at the same conclusion.  I don't want to bite off the work to do proper multipath in QUIC v1, which I think is the only other reasonable option of those Christian outlined.
>>
>> If someone comes up with a way to transform packet number to make it non-linkable, but doesn't have the downside of making hardware offload difficult, then I'm open to it.  But we've been talking about this for 2 months without any notable improvements over Martin's PR.
>>
>> Given we never talk about any issue only once in QUIC, I'm sure this will come up again, but for the time being I think #1079 is the best option we have.
>>
>>
>>
>> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <jri.ietf@gmail.com> wrote:
>> A few quick thoughts as I catch up on this thread.
>>
>> I spent some time last week working through a design using multiple PN spaces, and it is quite doable. I suspect we'll head towards multiple PN spaces as we consider multipath in the future. That said, there is complexity (as Christian notes). This complexity may be warranted when doing multipath in v2 or later, but I'm not convinced that this is necessary as a design primitive for QUICv1.
>>
>> We may want to creatively use the PN bits in v2, say to encode a path ID and a PN, for multipath. We want to retain flexibility in these bits going into v2. We've used encryption to ensure that we don't lose flexibility elsewhere in the header, and it follows that we should use PNE to retain flexibility in these bits as well. (Simplicity of design is the other value in using PNE, since handling migration linkability is non-trivial without it.)
>>
>> This leaves the question of HW acceleration being at loggerheads with the design in PR #1079. First, I expect that the primary benefit of acceleration will be in DC environments. Yes, there are some gains to be had in serving the public Internet as well, but I'm unconvinced that this is the driving use case for hardware acceleration. I understand that others may disagree with me here.
>>
>> AFAIK, QUIC has not been used in DC environments yet. I expect there are other things in the protocol that we'd want to change as we gain experience deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is not only appropriate, I would recommend it. This allows for rapid iterations internally, and the experience can drive subsequent changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.
>>
>> So, in short, I think we should go ahead with PR# 1079. This ensures that future versions are guaranteed the flexibility to change the PN bits for better support of HW acceleration or multipath or what-have-you.
>>
>> - jana
>>
>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <huitema@huitema.net> wrote:
>>
>> On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:
>>> Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture it seems to imply a large range of server, desktop and mobile chips all have a CPU instruction set available to do AES acceleration and other similar operations (other instruction sets are also available).
>>>
>>> If we are considering the AES instructions then it looks like it is (or at least will be in the near future) a sizeable proportion of the public internet have it to be used.
>>>
>>
>> Certainly, but that's not the current debate. PR #1079 is fully compatible with use of the AES instructions. The issue of the debate is that the mechanism in PR #1079 required double buffering, first encrypt the payload, then use the result of the encryption to encrypt the PN. This is not an issue in a software implementation that can readily access all bytes of the packet from memory, but it may be an issue in some hardware implementations that are designed to do just one pass over the data.
>>
>>
>> -- Christian Huitema
>>
>>
>>
>
> --
> Mark Nottingham   https://www.mnot.net/
>