Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> Tue, 05 November 2019 20:34 UTC

Return-Path: <mirja.kuehlewind@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB95A120B73; Tue, 5 Nov 2019 12:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zdzM--RtiT9t; Tue, 5 Nov 2019 12:34:54 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20066.outbound.protection.outlook.com [40.107.2.66]) (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 BFBAF120B80; Tue, 5 Nov 2019 12:34:50 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kpShYlpi4rK7e3vdpje0+5skFfimIjZXDJ6zuJyYoXckc2gjeibdwWzXtGO8NESp3xNaM4WLyD3GbJ/EJt8pCtVJ5rGnZR6Ly9edjJAj5/DOB3vxv/FeQoojt339GltH0f7oKmYMF1NZAlGoWa8iDTKIBlM0CquDlvyAD3IBahZDQgZPHUrluI5MBJoLF+ZN39BxOG4RE+LeYoKG3/AaqgG2MXv8iHwCOIIxlVJ87DjdymbOrIyVv49owL87nrpMUhmXP4bXrJYqyuUJyrAA56By4cQtBvsSH0VXNSHGpqf3JSkmTOgYoUm4Mdr+MJgv1mpEIZmZE/NgJSlrpkiiVQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MOsOOx/h10YgEKj1yhe8BZbJUIrL+kwhrFrGjhmLO6s=; b=e66+O4s397BV4bRw1vPhTD4DA+t3bfZ3TrgecWm0nkDxqdkz3jdPjJ3yWGo/z3/K19wFzbfovaQXRYaUIEIpaf4oZZzPfym3CvaJ6SWy3iFs/6muxV6b4id60JAx6ssbf9e/3KgxMNGh5unH2f//muGNfPcYiddXHzgNqh9SPoMUjvxVMaHqM++H5p0RT3710pA7XY5dG7wPycX5HrP2p2SfC36tAiIkszqtJq+ujI4uXCvTqMIfnxFFlJuKCtmRbrE/6vE7tF+TmFEYGQgrm6vfTgXf+HxQY+vvdUzNEmoGQPYZbfpKT8YwbZt8YnFIFd+sSN8RGTFV7KdB+n6VUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MOsOOx/h10YgEKj1yhe8BZbJUIrL+kwhrFrGjhmLO6s=; b=nk1z7KYYUbzR1r9N8yyLxhfEZ4e8qs/WGKCF2XuGEW2rs3YYZvobLSFyAvvm4f1PYCmDnVgsfGiPSg61nqdc7YehMW6Wz2PlystObon2rM5ni+5SwN8Bt2KBpBQh4yBj/bt837NIOUkLrFUOzwA1vOy0VzE2HnFuEW6vY1HOBoo=
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4449.eurprd07.prod.outlook.com (52.135.149.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Tue, 5 Nov 2019 20:34:47 +0000
Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::4189:4ef8:bfc1:ec58%7]) with mapi id 15.20.2430.014; Tue, 5 Nov 2019 20:34:47 +0000
From: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
CC: Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
Thread-Index: AQHVky08JY2FDXmr60OAsbMwFkv5fad7STQAgAAVH4CAAaI6gIAABbcAgAAET4A=
Date: Tue, 5 Nov 2019 20:34:47 +0000
Message-ID: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com>
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com> <CALx6S35bSAa_zq=HsF-3e9qC-vRNFRu6dn+O4ak4Hi+c=Tmz5A@mail.gmail.com> <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> <CABcZeBPfT=B+fOXAkPuoEQQHAtJrefXSgnjOpPC7-4zC_myRsA@mail.gmail.com> <D36061F0-F872-4054-ACF0-C9A88FCEC572@ericsson.com> <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk> <B74B17C8-A8D7-47F9-9DA2-610A8EB9F3BA@ericsson.com> <CABcZeBMemLcmXdWnstOwa5GFatgp5HcwMo6r-a2A9Etp03xTfA@mail.gmail.com> <5DC1D94A.9040602@erg.abdn.ac.uk>
In-Reply-To: <5DC1D94A.9040602@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com;
x-originating-ip: [109.42.0.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 616b1b8f-4e67-4a4e-715c-08d7622f99ba
x-ms-traffictypediagnostic: AM0PR07MB4449:
x-microsoft-antispam-prvs: <AM0PR07MB4449EF19FBC0983B13A86936F47E0@AM0PR07MB4449.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(366004)(39860400002)(189003)(199004)(14454004)(8936002)(66616009)(81156014)(66066001)(2351001)(1730700003)(6246003)(4326008)(99286004)(81166006)(86362001)(71190400001)(6486002)(6436002)(6916009)(71200400001)(66446008)(99936001)(64756008)(44832011)(66946007)(66556008)(66476007)(5660300002)(76116006)(7736002)(305945005)(2906002)(229853002)(11346002)(486006)(476003)(2616005)(446003)(478600001)(296002)(6512007)(8676002)(25786009)(26005)(316002)(3846002)(54906003)(36756003)(5640700003)(2501003)(6116002)(256004)(14444005)(6506007)(102836004)(53546011)(76176011)(186003)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4449; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xxRSkmdnUa3REQqlsiZ26Zd2p4Q5rZVlgUJQ/7jCCbJAgTy2/MWG/Zns35bcV5Ite7JCgOsfxnhTa+LoU/s5UGQ+fGjuHQ4wKiUUZVT0KGT/SVJg41ZTV3DFt/NJimxJ6asAPpOJv/+hC7KDM9MZupAFrp/mPB2dgM3b2mPegSQsploB5Rq6htKzyhEKpNa1zcYJZGVCww36PtCpYElTPzVMWbOHOAzblqzS6kQX3DAV78C19qR6+q+MPsGE/KMbtU6VgBgA1K/9hMs61BQcFElA0Z2p7DEdFI6Q7P0blnq1qHNBhT7I9gUi21PDRkD0bKGGaTdqlYSekQMeYwfLC+I9ipzdpL2twnK6ZwtUSzLo3UvmZO2fQtw6H5iBiQ2iPhp1v5njx6tO7rGDG2cBYTutja5fV8tgNVTlakk4VaC9/g/oJNRaB14Zh+aI6UB6
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; boundary=Apple-Mail-F1D630A4-D7D2-4AD1-ABAF-779ABE5B62B9; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 616b1b8f-4e67-4a4e-715c-08d7622f99ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2019 20:34:47.7382 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NgKyi2HH/uVRT9YqQvgAAl/CzQgcWSCy64x+mX8x3t8eXA37sH2c8iF1qEVwi1hl0qL1KFqlHi8gBoBhgsJjFyWw7SIMWQPXGiWsg0jxiT8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4449
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/eaJs7iCTwlAjeUywSCNGVkYCToE>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 20:34:57 -0000

See below.

> Am 05.11.2019 um 21:19 schrieb Gorry Fairhurst <gorry@erg.abdn.ac.uk>uk>:
> 
>> On 05/11/2019, 19:58, Eric Rescorla wrote:
>> 
>> 
>> On Mon, Nov 4, 2019 at 10:02 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com <mailto:mirja.kuehlewind@ericsson.com>> wrote:
>> 
>>    Hi Christian,
>> 
>>    please see two comments below (marked with [MK]).
>> 
>>    Mirja
>> 
>>    On 04.11.19, 18:46, "Gorry Fairhurst" <gorry@erg.abdn.ac.uk
>>    <mailto:gorry@erg.abdn.ac.uk>> wrote:
>> 
>>        Just focussing on the end...
>> 
>>        On 04/11/2019, 16:29, Christian Huitema wrote:
>>    >>
>>    >> [MK] That’s not the intention here. But we also need to
>>    consider ways
>>    >> to interact with the network where this brings benefit to both the
>>    >> network and the performance of the end-to-end traffic. There are
>>    >> situation where this is the case. And I don’t think one makes
>>    sense
>>    >> without the other.
>>    >>
>>    > You seem to be arguing for something like "performance enhancing
>>    > proxies". End-to-end encryption is indeed a way to opt out of such
>>    > proxying. Measurements so far indicate that opting out has very
>>    little
>>    > impact on actual performance, and that whatever impact there is
>>    could
>>    > be reduced by improvements in end-to-end algorithms. In fact, in
>>    many
>>    > cases, end to end performance is better without such proxies.
>>    But the
>>    > real reason for the opposition to the concept is ossification.
>>    > Enabling such proxies would quickly ossify the new transports,
>>    and a
>>    > such there is a strong consensus in the end-to-end transport
>>    designers
>>    > to use encryption and prevent interference by such devices.
>>    >
>>        On PEPs: The current case for many of the network segments I
>>    see is that
>>        QUIC is quite good, but it is considerably worse (currently)
>>    than a PEP
>>        using Split-TCP. That's not to say it can't improve - but
>>    that's not
>>        true yet. However: It's curious that people keep going back to
>>    PEPs,
>>        because network devices that change the transport header were
>>        specifically out-of-scope for this ID!
>>    >
>>    > This does not mean that network level deployment have no role in
>>    the
>>    > future. I could see for example tunnels deployed that use FEC or
>>    local
>>    > retransmission to mask the poor performance of a particular
>>    subnet. Or
>>    > I could see end-to-end devices opting into some kinds of
>>    application
>>    > level caching services in order to improve performance. But the
>>    draft
>>    > should be clear: transport protocols do not have to enable
>>    > interference with the transport bits.
>> 
>>    [MK] This is not what the draft is asking for.
>> 
>>    >
>>        There are also many operators - e.g., enterprise who rely on
>>    the methods
>>        currently mentioned in this draft. In this case, they also
>>    actually *do*
>>        care about the performance of the networks they operate. They
>>    also do
>>        care about the topics, which matters most depends on which
>>    organisation.
>>    >
>>    > My take is that this draft should not be published as is. It
>>    should be
>>    > rewritten to actually reflect the consensus of the transport area,
>>    > which has to reflect in particular the work in the QUIC working
>>    group.
>> 
>>    [MK] The purpose of this draft is exactly to find and document
>>    consensus in the transport area and in the IETF. I don't think any
>>    individual at this points knows what the consensus actually is. 
>> 
>> Well, in that case this document shouldn't be being advanced.
>> 
>> 
>>    This document has support in tsvwg (otherwise it would not have
>>    been adopted as wg document) and I also don't think there is
>>    anything in the draft that contradicts any work in the QUIC group.
>> 
>> 
>> Well, I think what you're hearing is that people think that it is badly aligned with the consensus of other parts of the IETF.

What I’m hearing is that 2-3 people think this is not aligned but don’t actually say why exactly they think that while there are a bunch of people supporting this document ( throughout the whole wg process).

Mirja

>> 
>> -Ekr
> 
> Than ks Ekr, but of course, I don't agree on your thoughts. Which is why this needs to be carefully considered.
> 
> Gorry
>