IETF Logo Mail Archive

Re: Getting to consensus on packet number encryption

"Brian Trammell (IETF)" <ietf@trammell.ch> Wed, 04 April 2018 14:43 UTC

Return-Path: <ietf@trammell.ch>
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 8353412D958 for <quic@ietfa.amsl.com>; Wed, 4 Apr 2018 07:43:06 -0700 (PDT)
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, RCVD_IN_DNSWL_LOW=-0.7] 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 hIELhm_A0r3Z for <quic@ietfa.amsl.com>; Wed, 4 Apr 2018 07:43:04 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3078212D94F for <quic@ietf.org>; Wed, 4 Apr 2018 07:43:04 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F2241340552; Wed, 4 Apr 2018 16:43:02 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.26146); Wed, 4 Apr 2018 16:43:02 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 4 Apr 2018 16:43:02 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50609752; Wed, 04 Apr 2018 16:43:02 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <79C7DEB4-ED9E-49A7-A8BE-875495DB86A6@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_BA28BDB4-0D4A-4B74-BFBA-ADC0D40CFEF1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Getting to consensus on packet number encryption
Date: Wed, 04 Apr 2018 16:43:01 +0200
In-Reply-To: <CAOdDvNocw6cP6=c+x5nsN_yNp7VWp-RcmUABmX+cxTTgWbHnsQ@mail.gmail.com>
Cc: Lars Eggert <lars@eggert.org>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>
To: Patrick McManus <pmcmanus@mozilla.com>
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> <CAOdDvNo9QS=CX5YUWK8Lxs_SYX4nEM7OWv2+zB=VGhOX6J-BEw@mail.gmail.com> <B5235224-6761-463C-B163-39A4466DD4D0@trammell.ch> <CAOdDvNocw6cP6=c+x5nsN_yNp7VWp-RcmUABmX+cxTTgWbHnsQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/E52KU5o28lKA6J3llqKsSemBgNQ>
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, 04 Apr 2018 14:43:06 -0000

Ah, ok. So intentional mobility, as opposed to unintentional rebinding... Thanks, got it. (Won't argue the philosophical question of whether that's multipath or not. :) )

Cheers,

Brian

> On 4 Apr 2018, at 16:40, Patrick McManus <pmcmanus@mozilla.com> wrote:
> 
> it is about linkability, but in v1 for mobility (which I wouldn't call multipath but ymmv).
> 
> 
> 
> On Wed, Apr 4, 2018 at 10:35 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> hi Patrick,
> 
> > On 4 Apr 2018, at 14:54, Patrick McManus <pmcmanus@mozilla.com> wrote:
> >
> > btw I think its wrong to characterize this as perf vs privacy - its cpu vs bandwidth, the privacy is a must have.
> 
> I agree with your characterization here, but I'm curious as to what aspect of privacy PN encryption guarantees. Is there something I'm missing beyond rendering linkability vastly more difficult for multipath flows with a single PN space?
> 
> Thanks, cheers,
> 
> Brian
> 
>

v2.23.0 | Report a Bug | By Email