Re: [saag] [Int-area] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
tom petch <ietfc@btconnect.com> Thu, 02 July 2020 10:59 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1587F3A0990; Thu, 2 Jul 2020 03:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.onmicrosoft.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 nUa-ZwSy3c5j; Thu, 2 Jul 2020 03:59:19 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20131.outbound.protection.outlook.com [40.107.2.131]) (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 73A623A0AA2; Thu, 2 Jul 2020 03:59:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AMBsWoB1NvBXZpL5b7gq/mlAXntZ0HI+ct80cRKrrpjaBeS3e/T8PQGpKjk/U9gLC1Bb4V89/snF5q+coHJ8qUEzjljE7HNQIUr0h4m8Ik5jQQ5Ay7jLZHdYdLFK3ouqjv2BeP+9MTH+C9lqNet7YqijTw2i4H7+bgNqeHeEn+DU9W3QiRKGH+juGx+/UzyXI8er1Zq48VBEIaqnil3EN+r6muzLipxYwZKGgIfUQpdg32qaYRhci09YBPYXf+kEwYxhxcoxIWuQOnz0uRVh/HnR38iE4zkobh0VsbJXbYh1iX3wEK4Um+gg9HUtfUFSacBjBIbpYoUqCBU576Z0YQ==
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=X8FZibuGJxZkxmEINmK/9hfnGgct+a33puPgM1RHjWo=; b=Wo8iN7hheZAmYQ9Dd1hS5SPiwts7VgpWNWIqmIEzpg9Uc/S2LxPLmj3XVe5WsXQQF/jFjkwEk1JCgHtmMdXPmJRnaTQeSitotx9ui6QBKXWActd5U3HyTQ9gLK4lObIJybhKFdDdARGm6TK7VbOoNI2biK96rauGFmtIcXoZkzrXVOPyBckElcx1jVV6ovtppKM2+rhz64nNrS3t30tH5flb/MjKZTp33AljEpm/eJElbZ9oaGKJ7crmUtr6thR8oZ8uwZjyen9o/YZ4D2zh4tJ26MWG1u4zJzMNX+b8MVmBjfnAAQ5fqN42jVeCyoD5oIXaruVRAsMOsF/BdixrPg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X8FZibuGJxZkxmEINmK/9hfnGgct+a33puPgM1RHjWo=; b=HAyWsWhbwhP+5UbCgHMCWJZrFjrSJxcto/aJw1SguBoYf4pADz/xhXHHp/O8tO+KfOWbsPJbwzCqYEk6Qgld3UA7sSH+2dAhnXkV0FO7ugEmVjVcoceAWSvNHWNsCuOXg1JkP7l1u8CfvUs9b+TcOoyFGXW/qn2BYzz8HBDvCnM=
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB6122.eurprd07.prod.outlook.com (2603:10a6:10:85::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Thu, 2 Jul 2020 10:59:16 +0000
Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::b09b:5a3b:9735:bf26]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::b09b:5a3b:9735:bf26%5]) with mapi id 15.20.3174.008; Thu, 2 Jul 2020 10:59:16 +0000
From: tom petch <ietfc@btconnect.com>
To: Colin Perkins <csp@csperkins.org>, Eric Rescorla <ekr@rtfm.com>
CC: int-area <int-area@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, IETF SAAG <saag@ietf.org>
Thread-Topic: [Int-area] [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
Thread-Index: AQHWT44kbBS95bNKF0a3Pjb+4nlVs6j0H9Fx
Date: Thu, 02 Jul 2020 10:59:15 +0000
Message-ID: <DBAPR07MB7016C144FD6E42E6F4A4A0BBA06D0@DBAPR07MB7016.eurprd07.prod.outlook.com>
References: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com> <CABcZeBM9A1RxOiHGZdBznTb7zzArG5GTQs=bhNtBy90tSXs3Pg@mail.gmail.com>, <CDFF00F2-A2DA-44D3-9F16-A233422EB071@csperkins.org>
In-Reply-To: <CDFF00F2-A2DA-44D3-9F16-A233422EB071@csperkins.org>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: csperkins.org; dkim=none (message not signed) header.d=none;csperkins.org; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [81.131.229.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8e02920f-cd48-49fd-da66-08d81e76f64c
x-ms-traffictypediagnostic: DB7PR07MB6122:
x-microsoft-antispam-prvs: <DB7PR07MB61227BAB30E0067610AF1FFDA06D0@DB7PR07MB6122.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: SKcIbxZIQhlK3rXreKDURKMQCK35Ux4NQlByQgdmyj72pne5e+SpJTfxDAXGsSEf+txjT/PQgx8x9PCyKBdRihI5eDbfTF6sAFFKZ+qis60bDyyO8aJIl2qSfW9CgDNDjxfKyiQSmKPf3iy8ERJZsju6ZYkH25XAbd/t3ZzNSrR1mqNnrevgaUhQ3ySb9+1IgfF+ntYq4VEk2PTzJO9n1O4AQ/HJOcwF7TYUZv9mhlv88mgOxqGqbjCtwFY890mKk/Qefv/GvKpAu35pIgRktEhkj43gftyfV8qCzTNT9SYjDlcmmr1pbQrVY0hzqPkBqoVeXw7ihugBkdi3tqt2KYqICGXi0mAku1kG7vPNSpjWBjOb7XV00aK/PcvbG+mCDOgZCIbBqnYxE6WUfjfEfQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(396003)(376002)(346002)(136003)(366004)(2906002)(55016002)(83380400001)(966005)(5660300002)(478600001)(33656002)(86362001)(9686003)(7696005)(4326008)(66476007)(186003)(71200400001)(66556008)(66574015)(64756008)(52536014)(8676002)(66446008)(76116006)(53546011)(54906003)(316002)(8936002)(91956017)(66946007)(6506007)(26005)(110136005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 3+TsJshTWVmfhOcv4VcK6geEO77L1vAAJH8E5Q6XNgw/7R4Hj3usmzFWWi7ePqYvcPIljPKnAgkBYDLfTWluoFSF4hLpcuv2+XuJmsM9Nl3IdD6ACefvZmS/xfJ2/rjqMnKfyVkBRW/Fy1vBsScx2zQEmFm6gcxt7PQnrls/QaJwIzeWjEPy1WLF9Nxe0LEJPx07JRHN7PEbk6TyJhJrOOnxVlcOwtDhFo0mRc569q4n/yDr2f02M9J/fhVRBt5Ubk5ZCKShD0nMvdkzN7qlp0eMAE5IAIwK58pqAHz+Xu3fnBV7kCkUSJcmUiXonh07KaFj7A8QQUSMtX1jTquk8dli7IXqgDDWzVBLiEEi00nPxH1WrVMuhIYj1ZoEF5bfyziXlQLgIO8iONzchMvgLwKmWV0NBRWooQS+cjrLoictfJzB+bSh875t4K4l8ekmjR0VEcYkxyRKmDPOwrl8X2jqDqkf8vfJs5aGrKoHeuE=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DBAPR07MB7016.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e02920f-cd48-49fd-da66-08d81e76f64c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 10:59:15.8478 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4hGMo26jNkw6Wq200iZw+CrZYK2+TvUiTzrSCmYQn+r3jciUzM8p8M6FBB51e7MmjdSaSgVHLgGPoZ7ri06ftg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6122
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/yE8mjAofuelwkp7475TzwteWdhY>
Subject: Re: [saag] [Int-area] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2020 10:59:22 -0000
From: Int-area <int-area-bounces@ietf.org> on behalf of Colin Perkins <csp@csperkins.org> Sent: 01 July 2020 10:57 On 30 Jun 2020, at 01:59, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote: > This 3rd WGLC is limited to the following two topics: > Whether or not to proceed with a request for RFC publication > of the draft. The decision on whether or not to proceed will > be based on rough consensus of the WG, see RFC 7282. Publish. Operators need help in understanding the impact of emerging technology on their ability to operate a network. This may not be easy to understand but it does at least provide something to stick out and alert them. Tom Petch > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed > strong views that this draft should not be published – those > concerns have not been resolved and are carried forward to > this WGLC. This email message was an attempt to summarize > those concerns: > > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ > > Further explanation from both Eric Rescorla and David Schinazi > is welcome and encouraged to ensure that their concerns are > clearly understood. Well, I'll try again, but I'm not sure that I can do better than I have before. For reasons that are laid out in RFC 7258, the trend in protocol design in IETF is towards encrypting more and more. I agree, but also note that RFC 7258 is clear that some network monitoring can be beneficial and that “an appropriate balance” has to be found between mitigating pervasive monitoring and supporting network management. This draft is intended to highlight issues to be considered by transport protocol designers, to help them find that balance. And, to be clear, if transport protocol designers consider the issues and decide that all the metadata in their transport protocol must be encrypted, that’s fine. We're not pushing for a particular outcome; rather that the issues be considered and discussed when making a decision on what to encrypt. The last two transport protocols that were designed and widely deployed (SCTP over DTLS and QUIC) both encrypt the vast majority of the protocol metadata. This document advertises itself as "considerations" for design of such protocols: The transport protocols developed for the Internet are used across a wide range of paths across network segments with many different regulatory, commercial, and engineering considerations. This document considers some of the costs and changes to network management and research that are implied by widespread use of transport protocols that encrypt their transport header information. It reviews the implications of developing transport protocols that use end-to-end encryption to provide confidentiality of their transport layer headers, and considers the effect of such changes on transport protocol design, transport protocol evolution, and network operations. It also considers some anticipated implications on application evolution. This provides considerations relating to the design of transport protocols and features where the transport protocol encrypts some or all of their header information. However, as I said above, the new transport protocols that are actually being designed already feature metadata encryption and as far as I can tell, there is no prospective protocol new transport protocol design project for which these issues might be live. The issues highlighted in the draft were certainly considered in the design of QUIC, especially in the discussions around the spin bit and operational aspects. I cannot envisage that they won’t also be considered in the design of future transports. In that context, it's hard not to read this document with its long litany of practices which are impacted by metadata encryption as a critique of the decisions by SCTP/DTLS and QUIC to encrypt most of the metadata. I tend to regard critiques of protocol design as a good thing, but then we maybe have a different interpretations of that term. Certainly there are implications of the decision to encrypt transport metadata. There are benefits to it, but also costs. It’s important to understand both, to make an informed judgement on what to encrypt. This impression is reinforced by the description of the actual practices themselves, which focuses almost entirely on practices which appear to be benignly motivated (e.g., performance monitoring, troubleshooting, etc.) However, we also know that metadata is widely used for practices in which the network operator is adversarial to the user, for instance: - Blocking traffic based on TCP port, IP address, SNI, etc. - Performance-based traffic class discrimination - Monitoring the user's behavior via indicia like the ones above or via traffic analysis (see [0]) Yes, I understand that the authors explicitly disclaim judgement on these practices, and the document does briefly touch on the general idea, though the "concerns...have been voiced" tends to minimize those concerns [1] but the selection of practices to focus on is extremely telling. Focusing on the downsides of encryption for (at least arguably well-meaning) network players while mostly ignoring the large class of non-benign behaviors which encryption is intended to protect against has the effect of overemphasizing the costs of encryption to those players and minimizing the benefits to the endpoints whom it is intended to protect. Different communities have different interpretations on what’s the neutral point of view phrasing here, but I'm comfortable with further highlighting malicious uses of transport metadata in the draft. We’d tried to mostly do this by reference, since such things have been widely discussed in the past, but perhaps that’s not sufficient. To be maximally clear: I don't object to this document existing and I don't think that the opinions implicit in it are ones that should not be expressed. I merely don't think that it should be published as an IETF Consensus document. -Ekr [0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5 [1] Another motivation stems from increased concerns about privacy and surveillance. Users value the ability to protect their identity and location, and defend against analysis of the traffic. Revelations about the use of pervasive surveillance [RFC7624] have, to some extent, eroded trust in the service offered by network operators and have led to an increased use of encryption to avoid unwanted eavesdropping on communications. Concerns have also been voiced about the addition of information to packets by third parties to provide analytics, customisation, advertising, cross-site tracking of users, to bill the customer, or to selectively allow or block content. Whatever the reasons, the IETF is designing protocols that include transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement the already widespread payload encryption, and to further limit exposure of transport metadata to the network. -- Colin Perkins https://csperkins.org/
- [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg… Black, David
- Re: [saag] [tsvwg] 3rd WGLC (limited-scope): draf… Paul Vixie
- [saag] Anticompetitive use of trademark and IETF … Tony Rutkowski
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… Kyle Rose
- Re: [saag] [tsvwg] 3rd WGLC (limited-scope): draf… Roni Even
- Re: [saag] [Int-area] 3rd WGLC (limited-scope): d… Tom Herbert
- Re: [saag] [tsvwg] 3rd WGLC (limited-scope): draf… Holland, Jake
- Re: [saag] [tsvwg] [Int-area] 3rd WGLC (limited-s… Gorry Fairhurst
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… Eric Rescorla
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… Hannes Tschofenig
- Re: [saag] [tsvwg] 3rd WGLC (limited-scope): draf… Colin Perkins
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… mohamed.boucadair
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… Hannes Tschofenig
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… Ruediger.Geib
- Re: [saag] 3rd WGLC (limited-scope): draft-ietf-t… Kyle Rose
- Re: [saag] [Int-area] 3rd WGLC (limited-scope): d… Dirk.von-Hugo
- Re: [saag] [Int-area] 3rd WGLC (limited-scope): d… Joseph Touch
- Re: [saag] [Int-area] 3rd WGLC (limited-scope): d… Behcet Sarikaya
- Re: [saag] [Int-area] [tsvwg] 3rd WGLC (limited-s… tom petch
- Re: [saag] [tsvwg] [Int-area] 3rd WGLC (limited-s… Spencer Dawkins at IETF
- Re: [saag] Anticompetitive use of trademark and I… Jeffrey Walton
- Re: [saag] Anticompetitive use of trademark and I… Tony Rutkowski
- Re: [saag] Anticompetitive use of trademark and I… John Levine
- Re: [saag] Anticompetitive use of trademark and I… Tony Rutkowski
- Re: [saag] Anticompetitive use of trademark and I… Tony Rutkowski
- Re: [saag] Anticompetitive use of trademark and I… John R Levine