From nobody Fri Oct 4 02:20:22 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A4512085B; Fri, 4 Oct 2019 02:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 nPYzE842_W9o; Fri, 4 Oct 2019 02:20:17 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60085.outbound.protection.outlook.com [40.107.6.85]) (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 C90EB12007C; Fri, 4 Oct 2019 02:20:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ms+0ezMKXWaIHIH+sovaPcK+rW+EimbUXMot1jH4oGsX76Yi/3Oi0mjbhZ+UboNd5ycol8nqu/CMEaadraCk8gwYA0l+UDodaYCBQzsmXeqQpcawzAB2Hv3clvZdUXlhfUTdFcSvreVa90dkobWokNeeBJxCotWPgfEq4KUHu5JD0YQRRWRuvECJyKLfS5emuUWg9X4Wx8nLmFOFX8VFL/bGzyn01mAYuhuLl8Dd2dI0cwrmLOHgzsDd1+6ZLH8+Lzdh/jF4t/25EpLyQq9eSdCD+SyjFT+52HZJLHS8pxybGv3u/j1L6uihtHrJkhySKbstvDOv8giCF+SZyLQIrg== 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=q2WsDnT+l5qiEHCdhKAbmR08PcFdaSqxf+X5EEEw/OI=; b=PWBfUWAfDMZXtqaxxM41k4k1UhEO36C6K8Bm4+D+ro43HTHToxA8LDJ/TqXQdqPu0z2udDNPvg62J7ksIgpIdWiPb2mxwPS9bq1SpbaNYxnrQrX1Af9nrHmKS2iKzRCe5xbblMTeMVG8ixO36shh3BhtIZ2ifvzCIpZURvj9OWHfdO1z76ByD8lmUUwSGoGgki+vZfjbiHckjMf7meO6GrH/X8AO0LBfwLOBpuei7gisPtFbMCRLei1ZbvEhvStUHUmymetC25ntbqrxAThQ/8fYTB0yY82IsZl0lttzI/gdo/EJEQLWEhOqshJslUGetxqYpHmZTjobchAhncWujA== 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=q2WsDnT+l5qiEHCdhKAbmR08PcFdaSqxf+X5EEEw/OI=; b=mhPMV2tCs6GRV4hzYc38c6eLhBQUmU6NrEhVYejtIKeBHWenFt+C/7ma73ezFnCogKPpuReLoyADiPG1TNh8xMG2Mpds+Sn6LHN5dz/Ud0TwyoTW79X2JryXBbafA/4AY+R0X4WsYYS8nRO+lo7oTwhwZEqXooMYpCU+OKc1IRQ= Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB4076.eurprd07.prod.outlook.com (52.134.96.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.12; Fri, 4 Oct 2019 09:20:14 +0000 Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::e48c:a942:9682:2ce4%7]) with mapi id 15.20.2327.022; Fri, 4 Oct 2019 09:20:13 +0000 From: Magnus Westerlund To: "taps@ietf.org" , "draft-ietf-taps-transport-security.all@ietf.org" Thread-Topic: AD review of draft-ietf-taps-transport-security-08 Thread-Index: AdVzDTwWSyDxyrCQRGKUhFVUKpeSOwHh6/iA Date: Fri, 4 Oct 2019 09:20:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd0a55dc-27f5-48af-6ef8-08d748ac1039 x-ms-traffictypediagnostic: DB7PR07MB4076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018093A9B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(136003)(366004)(376002)(189003)(199004)(51914003)(5660300002)(229853002)(86362001)(8676002)(81156014)(478600001)(316002)(102836004)(26005)(81166006)(15650500001)(99286004)(99936001)(6246003)(6506007)(110136005)(14454004)(6436002)(8936002)(305945005)(14444005)(186003)(76116006)(3846002)(6116002)(2616005)(256004)(7736002)(118296001)(11346002)(36756003)(91956017)(25786009)(486006)(450100002)(71200400001)(66616009)(66476007)(6512007)(71190400001)(6486002)(446003)(2501003)(66446008)(66556008)(2906002)(76176011)(44832011)(476003)(64756008)(66066001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4076; H:DB7PR07MB5736.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: +Q/dHdSt3DVtfv0lYYgcrgXxmdgRQ+PXVnhGkpgNLUFlyh7mszD19OmWvFA9D7b9JijWqtJ3fpkXvOaXhxRdqthg/o7oMCBd0rZwG80rIdKaGHjlMaJ5FpmhNTGo81iFeV0vlBF0IoJu0neXlKvFA8GwmnVlQzTCoPK9qW/W8b1re4ahh0GpowAfxqwDNnil2QLUfCYAjG51CoC09ZVvZv3Br/1bkRKB+vrVa5hTtUK52aQrYxpD7vHzYGUyAL6z2PtB6DNN3URaZpYI7Tq7b5TL1KsPiMv9s7zUC3kKllL8uF7U2IGryjWarb4IeAPmTVlrdHEeBFS3jL25nDDRbHLreI04J2DCvmUIFm3nkxE33mkzlekNhkbNDPO3tPqm+UWyEfGmTJvNQqxsPNoeE5GFOMROLm4+nQNwPiuoKGM= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-VMjIvp8TFn+UpqK3VqYF" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd0a55dc-27f5-48af-6ef8-08d748ac1039 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2019 09:20:13.8082 (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: Z6hc8eAwJwb9Eg4j8b8WXgG+NQr/17LCnWC+d2d8CSHqDkjPcGHxZ57y7bA4iTYccIPoaXkXaglsrfeej0D4gbHSRZElI23ReIYOnc6RshE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4076 Archived-At: Subject: Re: [Taps] AD review of draft-ietf-taps-transport-security-08 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 09:20:20 -0000 --=-VMjIvp8TFn+UpqK3VqYF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the answers.=20 I will initiate IETF last call of this draft now.=20 Phillip, please update the writeup regarding the intentional reference to t= he obsoleted TCP-AO. Cheers Magnus On Thu, 2019-09-26 at 08:01 +0000, Magnus Westerlund wrote: > Hi, > =20 > Sorry about the delay in getting the AD review done. Below are my comment= s and > questions. Note the questions are truly questions and after answering we = can > discuss if there needed to be any changes or not. > =20 > =20 > 1. Section 4.1: Is there a reason to use TLS 1.2 specification (RFC5246) > rather than TLS 1.3 as the general reference? > =20 > 2. Comment on the writeup: Considering that ID nits results in the below > relevant references warning I would expect some comment in the writeup if= they > are intentional. If not please update the references. If they are intenti= onal, > please update the writeup to note them. > =20 > =20 > =20 > -- Obsolete informational reference (is this intentional?): RFC 2385 > (Obsoleted by RFC 5925) > =20 > -- Obsolete informational reference (is this intentional?): RFC 4474 > (Obsoleted by RFC 8224) > =20 > -- Obsolete informational reference (is this intentional?): RFC 5246 > (Obsoleted by RFC 8446) > =20 > -- Obsolete informational reference (is this intentional?): RFC 7539 > (Obsoleted by RFC 8439) > =20 > 3. Section 4.1.2: Is there a point to mention that TLS forward secrecy a= re > dependent on cipher suit for the key exchange and not ensured prior to 1.= 3? > =20 > 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 1.3 > draft: =E2=80=9C(Note that this extension is only supported in > DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)=E2=80=9D > =20 > 5. Section 4.3.3: =E2=80=9CQUIC transport relies on UDP.=E2=80=9D Althoug= h QUIC is targeting > UDP as its main deployment vessel, isn=E2=80=99t QUIC in fact dependent o= n a > unreliable datagram service. But, maybe writing UDP is more straightforwa= rd? > =20 > 6. Section 4.5.4: When it comes to variants of SRTP. I think referencing = RFC > 7201 would actually be reasonable, as in the many different options hide = some > transport security options that so far is not discussed in this document.= Like > securing multicasted / broadcasted RTP.=20 > =20 > 7. Section 4.5.4: So are ZRTP included as variant because it provides new > security features? Is that session continuity, or something else?=20 > =20 > 8. Section 11: There are a number of references here that I don=E2=80=99t= think meets > the requirement for references. These are the ones that only have a title= and > n.d. All these could include a URL a date when these pages was visited an= d > contained the information you want to reference.=20 > =20 > =20 > Cheers > =20 > Magnus Westerlund --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-VMjIvp8TFn+UpqK3VqYF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAwNDA5MjAxMVowLwYJKoZIhvcN AQkEMSIEIApHQdeP6IiSKIJk8iYDYerd/6etu1XHQnMxcSiOoSlOMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAchdD4LkgwyYT B/eWzNfqr5XNMpbIturXji5iT2NlG0KfE4ncogBotBeU+mghQMYP0i4LHpikOtVENQwAD+larvln sdI9haFO9oOCEqgaFCFzPyy6vNT2Aoo+dwXVLeADZMVr25qsNDA9De6jkivVG27juThIZGoFlZBy pvASpIcCP1nEV1aMgqTDvsHWl3FepLY7gculcMHzLPmnZdDR/C7Gzc3TK270fYNmnUhiOTB5G0fl CSRTJ0lFSvf6XYkhrYErtzBv3nGbCb0VEZF+9BGjjCAbtCkaUDcNJETji4Y5UA+JhJDCb3UtJJWW +qj0JjORsgj+9Hqo0sFP8c0CmwAAAAAAAA== --=-VMjIvp8TFn+UpqK3VqYF-- From nobody Fri Oct 4 06:56:08 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1187C12091C; Fri, 4 Oct 2019 06:55:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: magnus.westerlund@ericsson.com, philipp@tiesel.net, taps-chairs@ietf.org, Philipp Tiesel , draft-ietf-taps-transport-security@ietf.org, taps@ietf.org Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2019 06:55:56 -0700 Archived-At: Subject: [Taps] Last Call: (A Survey of Transport Security Protocols) to Informational RFC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 13:56:01 -0000 The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'A Survey of Transport Security Protocols' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. Moreover, this document defines a minimal set of security features that a secure transport system should provide. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Oct 4 11:44:36 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1734E120945; Fri, 4 Oct 2019 11:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001] 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 nYpKfkctWiQl; Fri, 4 Oct 2019 11:44:31 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 23FEE120025; Fri, 4 Oct 2019 11:44:30 -0700 (PDT) X-Envelope-From: philipp@tiesel.net Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x94IiQjB014500 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Oct 2019 20:44:26 +0200 Received: from dhcp-242.in-panik.de ([217.197.86.242]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1iGSWj-0000Ug-Af; Fri, 04 Oct 2019 20:42:05 +0200 From: "Philipp S. Tiesel" Message-Id: <231DF732-90B1-493C-ADF5-C9A7F3E413F2@tiesel.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_5686BBC4-228C-4E1F-B1C5-5F43AB58ED16" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 4 Oct 2019 20:44:25 +0200 In-Reply-To: Cc: "taps@ietf.org" , "draft-ietf-taps-transport-security.all@ietf.org" To: Magnus Westerlund References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Taps] AD review of draft-ietf-taps-transport-security-08 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 18:44:34 -0000 --Apple-Mail=_5686BBC4-228C-4E1F-B1C5-5F43AB58ED16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, the writeup has been updated to explain the obsolete references. - We = can go ahead > On 4. Oct 2019, at 11:20, Magnus Westerlund = wrote: >=20 > Thanks for the answers.=20 >=20 > I will initiate IETF last call of this draft now.=20 >=20 > Phillip, please update the writeup regarding the intentional reference = to the > obsoleted TCP-AO. >=20 > Cheers >=20 > Magnus >=20 > On Thu, 2019-09-26 at 08:01 +0000, Magnus Westerlund wrote: >> Hi, >>=20 >> Sorry about the delay in getting the AD review done. Below are my = comments and >> questions. Note the questions are truly questions and after answering = we can >> discuss if there needed to be any changes or not. >>=20 >>=20 >> 1. Section 4.1: Is there a reason to use TLS 1.2 specification = (RFC5246) >> rather than TLS 1.3 as the general reference? >>=20 >> 2. Comment on the writeup: Considering that ID nits results in the = below >> relevant references warning I would expect some comment in the = writeup if they >> are intentional. If not please update the references. If they are = intentional, >> please update the writeup to note them. >>=20 >>=20 >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 2385 >> (Obsoleted by RFC 5925) >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 4474 >> (Obsoleted by RFC 8224) >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 5246 >> (Obsoleted by RFC 8446) >>=20 >> -- Obsolete informational reference (is this intentional?): RFC 7539 >> (Obsoleted by RFC 8439) >>=20 >> 3. Section 4.1.2: Is there a point to mention that TLS forward = secrecy are >> dependent on cipher suit for the key exchange and not ensured prior = to 1.3? >>=20 >> 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS = 1.3 >> draft: =E2=80=9C(Note that this extension is only supported in >> DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)=E2=80=9D >>=20 >> 5. Section 4.3.3: =E2=80=9CQUIC transport relies on UDP.=E2=80=9D = Although QUIC is targeting >> UDP as its main deployment vessel, isn=E2=80=99t QUIC in fact = dependent on a >> unreliable datagram service. But, maybe writing UDP is more = straightforward? >>=20 >> 6. Section 4.5.4: When it comes to variants of SRTP. I think = referencing RFC >> 7201 would actually be reasonable, as in the many different options = hide some >> transport security options that so far is not discussed in this = document. Like >> securing multicasted / broadcasted RTP.=20 >>=20 >> 7. Section 4.5.4: So are ZRTP included as variant because it provides = new >> security features? Is that session continuity, or something else?=20 >>=20 >> 8. Section 11: There are a number of references here that I don=E2=80=99= t think meets >> the requirement for references. These are the ones that only have a = title and >> n.d. All these could include a URL a date when these pages was = visited and >> contained the information you want to reference.=20 >>=20 >>=20 >> Cheers >>=20 >> Magnus Westerlund > --=20 > Cheers >=20 > Magnus Westerlund=20 >=20 >=20 > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com = > ---------------------------------------------------------------------- AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_5686BBC4-228C-4E1F-B1C5-5F43AB58ED16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

the writeup has been updated to = explain the obsolete references. - We can go ahead

On 4. = Oct 2019, at 11:20, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Thanks for = the answers. 

I will = initiate IETF last call of this draft now. 

Phillip, = please update the writeup regarding the intentional reference to = the
obsoleted = TCP-AO.

Cheers

Magnus

On Thu, 2019-09-26 at 08:01 +0000, Magnus Westerlund = wrote:
Hi,

Sorry about the delay in getting the AD review = done. Below are my comments and
questions. Note the = questions are truly questions and after answering we can
discuss if there needed to be any changes or not.


1. Section 4.1: Is there a = reason to use TLS 1.2 specification (RFC5246)
rather than = TLS 1.3 as the general reference?

2. = Comment on the writeup: Considering that ID nits results in the below
relevant references warning I would expect some comment in = the writeup if they
are intentional. If not please update = the references. If they are intentional,
please update the = writeup to note them.



 -- Obsolete informational reference (is this = intentional?): RFC 2385
    (Obsoleted = by RFC 5925)

 -- Obsolete = informational reference (is this intentional?): RFC 4474
    (Obsoleted by RFC 8224)

 -- Obsolete informational reference (is = this intentional?): RFC 5246
    (Obsoleted by RFC 8446)

 -- Obsolete informational reference (is = this intentional?): RFC 7539
    (Obsoleted by RFC 8439)

3.  Section 4.1.2: Is there a point to = mention that TLS forward secrecy are
dependent on cipher = suit for the key exchange and not ensured prior to 1.3?

4. Section 4.1.2: Second to last paragraph: Broken reference = to DTLS 1.3
draft: =E2=80=9C(Note that this extension is = only supported in
  DTLS 1.2 and 1.3 = {{?I-D.ietf-tls-dtls13}.)=E2=80=9D

5. = Section 4.3.3: =E2=80=9CQUIC transport relies on UDP.=E2=80=9D Although = QUIC is targeting
UDP as its main deployment vessel, = isn=E2=80=99t QUIC in fact dependent on a
unreliable = datagram service. But, maybe writing UDP is more straightforward?

6. Section 4.5.4: When it comes to variants of = SRTP. I think referencing RFC
7201 would actually be = reasonable, as in the many different options hide some
transport security options that so far is not discussed in = this document. Like
securing multicasted / broadcasted = RTP. 

7. Section 4.5.4: So are ZRTP included as variant because it = provides new
security features? Is that session = continuity, or something else? 

8. Section 11: There are a number of references here that I = don=E2=80=99t think meets
the requirement for references. = These are the ones that only have a title and
n.d. All = these could include a URL a date when these pages was visited and
contained the information you want to reference. 


Cheers

Magnus = Westerlund
-- Cheers

Magnus Westerlund 


---------------------------------------------------------------= -------
Network = Architecture & Protocols, Ericsson Research
---------------------------------------------------------------= -------
Ericsson AB =             &n= bsp;   | Phone  +46 10 7148287
Torshamnsgatan = 23           | Mobile = +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
---------------------------------------------------------------= -------

AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_5686BBC4-228C-4E1F-B1C5-5F43AB58ED16-- From nobody Mon Oct 7 16:18:19 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160F212006F for ; Mon, 7 Oct 2019 16:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 m_fvgcYtchPF for ; Mon, 7 Oct 2019 16:18:13 -0700 (PDT) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 2C9F1120044 for ; Mon, 7 Oct 2019 16:18:13 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id d17so10488619lfa.7 for ; Mon, 07 Oct 2019 16:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DQdB6rvV+miY2Q1dge3i3aSc/OIK7bAkkvwriEX+M3c=; b=bT7hez/aPSZ+sAjRJD21IrXO8bwHJoxU5jRfFWDQNLMJThkZ9ulpAm9uAG0fjHptrO X52+0xuj1DFaS/QCppEWoJ0a6fIiF8WmHbJGdh2xSpN5iMpaYf0Fdr7wbzFw6C1pMvDr XdjnlF6txMaD5K3Dkbd/NR+19HYXvTrBjDcVyGqPw4yiIJ/EytU5sA8z++dL8HCJqxBq 1H1H0xvj9bhVuNSNiFW+s53+I8g08Ixxvz9YJwtwQzx+vQw8eWPmoxsSgBiZ7bOY6KHe /0wK5zlHvPoA6CYbF0HoY0B3NBboLJzf6Huw7onW8fnlgt5UPukT7PVW34G2CpFb+frM dTaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DQdB6rvV+miY2Q1dge3i3aSc/OIK7bAkkvwriEX+M3c=; b=J9EFBRPZ/YMHTjF+1bdJgU44ZOPGOPZ8cbbjMR5e1r7oFjtvYEfYSAnBY7IDgw1mPG 2q85AwXvzmA3DkQpCNTTM7kwDI5s+gXRALwk2e7gJA01aqN0wYMVsnN2XmXSxg+wTKNa l2PnrkpAmkIZf/o9zlhPvL8Ix1nD58tpEZx4GnhOkYdMwowMmykMdfVS9LMLz5792yqV XFmFRKh2Ssv6eTdw3IiSwG1g/K69wPz9C+fvV4AbaF4xue8um6XUwbJMteZfUw5V65XE lVNy1A41FYfEW72l3BIw1Cj74Tt2qlwhqmj4Lz1HOL1wHPBKi2er1e/0fF5k2cFh9rqc VBrg== X-Gm-Message-State: APjAAAVZtUDVYZki1oerAKi+LzLgUvLHRs5lDuCJ5ztwCfYUlyC3li/8 HRpK9jAQUzAxqxYA06uh/NwQkulAA4TFn0qYwGFTKggHN4k= X-Google-Smtp-Source: APXvYqzjghYdfyGOj0m32DQdHyhO1hsR5Wv8Hkv9YA94Tdu7hCEjU14i6o2Vt+zxHm1AioD+X5QvP9/YkcIFWeEPENY= X-Received: by 2002:a19:c80b:: with SMTP id y11mr19175739lff.184.1570490291052; Mon, 07 Oct 2019 16:18:11 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Mon, 7 Oct 2019 16:17:34 -0700 Message-ID: To: draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000ebf84505945a43b0" Archived-At: Subject: [Taps] (no subject) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 23:18:16 -0000 --000000000000ebf84505945a43b0 Content-Type: text/plain; charset="UTF-8" Document: draft-ietf-taps-transport-security-09.txt I've reviewed this document and I do not think it should be published in its current form. It's probably most useful to start with the objective of this document. Here's what the abstract says: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. Moreover, this document defines a minimal set of security features that a secure transport system should provide. First off, I should say that I am generally skeptical of the goal of defining a "secure transport system", at least if we mean by that something encompassing protocols as diverse as TLS, DTLS, QUIC, and IPsec. Even though these are built on largely similar cryptographic cores (in the case of TLS, DTLS, and QUIC, essentially identical handshakes) and offer relatively similar security record formats (AEAD-protected records), their actual notional service interfaces are quite different. As a few examples: - TLS depends on reliable transport services, DTLS ignores them, QUIC offers its own built-in reliable transport abstraction, and IPsec has no notion of transport at all, and relies on L4 transport protocols to provide any notion of application reliability semantics (not too dissimilar to the relationship between DTLS and SCTP in WebRTC). - Despite the above, these protocols actually aren't 1-1 with deployment models, so for instance DTLS used to provide a VPN is really much more like IPsec than TLS is. So gluing DTLS for IoT and DTLS-VPNs together doesn't make sense. - Although based on the same underlying authorization mechanisms, these protocols have different naming models (QUIC, TLS, and (mostly) DTLS) talking mostly in terms of domain names and IPsec talking mostly in terms of IP addresses (this also goes to whether you have a dependency on DNSSEC). - These protocols have totally different scopes, with the application protocols thinking in terms of host/port quarters and IPsec thinking in terms of all traffic between two devices. So, I don't think it's really possible to talk about all of these as if they were somehow even partially interchangeable instances of a class of protocols. Even if we ignore this, I don't feel like the document does a very good job of achieving this goal. A huge fraction of this document is taken up by fairly detailed survey of the properties of each of the relevant protocols. To the extent to which it is meaningful to do a comparison between these protocol instances, this document seems to me to focus largely on the wrong pieces, which is to say the cryptographic details rather than the exposed interface semantics. Here's a concrete example: IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and TCP port 4500. Its primary goal is to generate keys for Security Associations (SAs). An SA contains shared (cryptographic) information used for establishing other SAs or keying ESP; See Section 4.4.2. IKEv2 first uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", which is a set of keys used to encrypt further IKEv2 messages. IKE then performs a phase of authentication in which both peers present blobs signed by a shared secret or private key that authenticates the entire IKE exchange and the IKE identities. IKE then derives further sets of keys on demand, which together with traffic policies are referred to as the "Child SA". These Child SA keys are used by ESP. IKEv2 negotiates which protocols are acceptable to each peer for both the IKE and Child SAs using "Proposals". Each proposal specifies an encryption and authentication algorithm, or an AEAD algorithm, a Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function algorithm. Each peer may support multiple proposals, and the most preferred mutually supported proposal is chosen during the handshake. How is any of this detail relevant? Suppose that IKEv2 were replaced with a totally different handshake (IKEv1, DTLS, QUIC crypto), how would the external behavior of the system be interestingly different? >From the perspective of the consumer of such a system, the way to think about this is that there is a handshake protocol which spits out keys which are then fed into the IP-level packet protection machinery (note that this is effectively what OpenVPN is, and to some extent Wireguard, though Wireguard uses different packet protection). Here's another example: Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection [RFC8548]. It is a family of TCP encryption protocols (TEP), distinguished by key exchange algorithm. The use of a TEP is negotiated with a TCP option during the initial TCP handshake via the mechanism described by TCP Encryption Negotiation Option (ENO) [RFC8547]. In the case of initial session establishment, once a tcpcrypt TEP has been negotiated the key exchange occurs within the data segments of the first few packets exchanged after the handshake completes. The initiator of a connection sends a list of supported AEAD algorithms, a random nonce, and an ephemeral public key share. The responder typically chooses a mutually-supported AEAD algorithm and replies with this choice, its own nonce, and ephemeral key share. An initial shared secret is derived from the ENO handshake, the tcpcrypt handshake, and the initial keying material resulting from the key exchange. The traffic encryption keys on the initial connection are derived from the shared secret. Connections can be re-keyed before the natural AEAD limit for a single set of traffic encryption keys is reached. Each tcpcrypt session is associated with a ladder of resumption IDs, each derived from the respective entry in a ladder of shared secrets. These resumption IDs can be used to negotiate a stateful resumption of the session in a subsequent connection, resulting in use of a new shared secret and traffic encryption keys without requiring a new key exchange. Willingness to resume a session is signaled via the ENO option during the TCP handshake. Given the length constraints imposed by TCP options, unlike stateless resumption mechanisms (such as that provided by session tickets in TLS) resumption in tcpcrypt requires the maintenance of state on the server, and so successful resumption across a pool of servers implies shared state. How does all this detail help someone understand the role that tcpcrypt plays in the ecosystem. Suppose, for instance, that tcpcrypt didn't have resumption at all (not a totally absurd design decision), how would that meaningfully affect the consumer's experience of using it in a system? Partly my complaint here is about presentation: a flat list of protocols complete with a lot of detail serves to obscure the high order architectural ideas. However, I think it's also a conceptual issue, which is that this document focuses on the security services provided (PFS, unilateral authentication, etc.) but that's actually a way in which these protocols are quite similar, deriving as they mostly do from the same few underlying cryptographic handshake shapes, with the differences to a great extent depending on in which era the protocols were designed (e.g., AES-CTR/HMAC versus AES-GCM), and where even those properties are to some extent subject to negotiation. It's also not uncommon to see features migrate between protocols, but that doesn't change the basic architectural properties. Instead, I think this document -- if it is to exist at all -- should focus on the architectural position that these protocols occupy in the stack rather than on the details of the protocol. This would give you something that looked like this: - Generic application-layer channel security protocols - TLS - DTLS - QUIC* [Plus some other stuff] - CurveCP (?) - Transport-level security - tcpcrypt - MinimaLT (?) - IP-layer VPN protocols - IKEv2, - OpenVPN - WireGuard - DTLS VPNs - Application-bound protocols - DTLS-SRTP, ZRTP And then I would have each of these start by emphasizing the common features of these protocols and how they fit into the ecosystem, and only briefly cover differences in the protocols to the extent to which they were meaningfully observable (usually barely at all). One thing I would emphasize in this context is that the protocol differences are far less relevant from this perspective. For instance, OpenVPN and IKEv2/IPsec use totally different cryptographic handshakes but from an architectural perspective they fit into the same basic box, which is part of why OpenVPN is such an easy drop-in for IPsec-style systems. Another example along these lines is TLS: SSLv2, SSLv3/TLS1.0-1.2, and TLS 1.3 are really quite different protocols, but they all occupy the same basic position in the stack and serve the same purposes, which is why it has been (relatively) easy to just drop newer versions of TLS into the system. Once you do this, I think you will also need to radically rework S 6, but I'm willing to withold judgement. I made a number of more detailed comments on my copy, but upon looking back, I think they mostly apply to sections I think you should cut. --000000000000ebf84505945a43b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-ietf-taps-transport-security-09.txt
I've reviewed this document and I do not think it should be published<= br>in its current form.

It's probably most useful to start with = the objective of this
document. Here's what the abstract says:
=C2=A0 =C2=A0This document provides a survey of commonly used or notable = network
=C2=A0 =C2=A0security protocols, with a focus on how they intera= ct and integrate
=C2=A0 =C2=A0with applications and transport protocols.= =C2=A0 Its goal is to supplement
=C2=A0 =C2=A0efforts to define and cata= log transport services by describing the
=C2=A0 =C2=A0interfaces require= d to add security protocols.=C2=A0 This survey is not
=C2=A0 =C2=A0limit= ed to protocols developed within the scope or context of the
=C2=A0 =C2= =A0IETF, and those included represent a superset of features a Transport=C2=A0 =C2=A0Services system may need to support.=C2=A0 Moreover, this doc= ument defines
=C2=A0 =C2=A0a minimal set of security features that a sec= ure transport system
=C2=A0 =C2=A0should provide.

First off, I sh= ould say that I am generally skeptical of the goal
of defining a "s= ecure transport system", at least if we mean by
that something enco= mpassing protocols as diverse as TLS, DTLS,
QUIC, and IPsec. Even though= these are built on largely similar
cryptographic cores (in the case of = TLS, DTLS, and QUIC, essentially
identical handshakes) and offer relativ= ely similar security
record formats (AEAD-protected records), their actu= al notional
service interfaces are quite different. As a few examples:
- TLS depends on reliable transport services, DTLS ignores
=C2=A0 = them, QUIC offers its own built-in reliable transport abstraction,
=C2= =A0 and IPsec has no notion of transport at all, and relies on
=C2=A0 L4= transport protocols to provide any notion of application
=C2=A0 reliabi= lity semantics (not too dissimilar to the relationship
=C2=A0 between DT= LS and SCTP in WebRTC).

- Despite the above, these protocols actuall= y aren't 1-1 with
=C2=A0 deployment models, so for instance DTLS use= d to provide a VPN is
=C2=A0 really much more like IPsec than TLS is. So= gluing DTLS
=C2=A0 for IoT and DTLS-VPNs together doesn't make sens= e.
=C2=A0
- Although based on the same underlying authorization mech= anisms,
=C2=A0 these protocols have different naming models (QUIC, TLS,<= br>=C2=A0 and (mostly) DTLS) talking mostly in terms of domain names
=C2= =A0 and IPsec talking mostly in terms of IP addresses (this also
=C2=A0 = goes to whether you have a dependency on DNSSEC).
=C2=A0
- These pro= tocols have totally different scopes, with the application
=C2=A0 protoc= ols thinking in terms of host/port quarters and IPsec thinking
=C2=A0 in= terms of all traffic between two devices.

So, I don't think it&= #39;s really possible to talk about all of these
as if they were somehow= even partially interchangeable instances
of a class of protocols.

Even if we ignore this, I don't feel like the document does a ver= y
good job of achieving this goal. A huge fraction of this document istaken up by fairly detailed survey of the properties of each of the
re= levant protocols. To the extent to which it is meaningful to do a
compar= ison between these protocol instances, this document seems to me
to focu= s largely on the wrong pieces, which is to say the
cryptographic details= rather than the exposed interface
semantics. Here's a concrete exam= ple:

=C2=A0 =C2=A0IKEv2 is a control protocol that runs on UDP ports= 500 or 4500 and
=C2=A0 =C2=A0TCP port 4500.=C2=A0 Its primary goal is t= o generate keys for Security
=C2=A0 =C2=A0Associations (SAs).=C2=A0 An S= A contains shared (cryptographic)
=C2=A0 =C2=A0information used for esta= blishing other SAs or keying ESP; See
=C2=A0 =C2=A0Section 4.4.2.=C2=A0 = IKEv2 first uses a Diffie-Hellman key exchange to
=C2=A0 =C2=A0generate = keys for the "IKE SA", which is a set of keys used to
=C2=A0 = =C2=A0encrypt further IKEv2 messages.=C2=A0 IKE then performs a phase of=C2=A0 =C2=A0authentication in which both peers present blobs signed by a = shared
=C2=A0 =C2=A0secret or private key that authenticates the entire = IKE exchange and
=C2=A0 =C2=A0the IKE identities.=C2=A0 IKE then derives= further sets of keys on demand,
=C2=A0 =C2=A0which together with traffi= c policies are referred to as the "Child
=C2=A0 =C2=A0SA".=C2= =A0 These Child SA keys are used by ESP.

=C2=A0 =C2=A0IKEv2 negotiat= es which protocols are acceptable to each peer for both
=C2=A0 =C2=A0the= IKE and Child SAs using "Proposals".=C2=A0 Each proposal specifi= es an
=C2=A0 =C2=A0encryption and authentication algorithm, or an AEAD a= lgorithm, a
=C2=A0 =C2=A0Diffie-Hellman group, and (for IKE SAs only) a = pseudorandom function
=C2=A0 =C2=A0algorithm.=C2=A0 Each peer may suppor= t multiple proposals, and the most
=C2=A0 =C2=A0preferred mutually suppo= rted proposal is chosen during the handshake.

How is any of this det= ail relevant? Suppose that IKEv2 were replaced
with a totally different = handshake (IKEv1, DTLS, QUIC crypto), how
would the external behavior of= the system be interestingly different?
From the perspective of the cons= umer of such a system, the way to
think about this is that there is a ha= ndshake protocol which spits out
keys which are then fed into the IP-lev= el packet protection machinery
(note that this is effectively what OpenV= PN is, and to some extent
Wireguard, though Wireguard uses different pac= ket protection).


Here's another example:

=C2=A0 =C2= =A0Tcpcrypt extends TCP to enable opportunistic encryption between the
= =C2=A0 =C2=A0two ends of a TCP connection [RFC8548].=C2=A0 It is a family o= f TCP
=C2=A0 =C2=A0encryption protocols (TEP), distinguished by key exch= ange algorithm.
=C2=A0 =C2=A0The use of a TEP is negotiated with a TCP o= ption during the initial
=C2=A0 =C2=A0TCP handshake via the mechanism de= scribed by TCP Encryption
=C2=A0 =C2=A0Negotiation Option (ENO) [RFC8547= ].=C2=A0 In the case of initial session
=C2=A0 =C2=A0establishment, once= a tcpcrypt TEP has been negotiated the key
=C2=A0 =C2=A0exchange occurs= within the data segments of the first few packets
=C2=A0 =C2=A0exchange= d after the handshake completes.=C2=A0 The initiator of a
=C2=A0 =C2=A0c= onnection sends a list of supported AEAD algorithms, a random nonce,
=C2= =A0 =C2=A0and an ephemeral public key share.=C2=A0 The responder typically = chooses a
=C2=A0 =C2=A0mutually-supported AEAD algorithm and replies wit= h this choice, its
=C2=A0 =C2=A0own nonce, and ephemeral key share.=C2= =A0 An initial shared secret is
=C2=A0 =C2=A0derived from the ENO handsh= ake, the tcpcrypt handshake, and the
=C2=A0 =C2=A0initial keying materia= l resulting from the key exchange.=C2=A0 The traffic
=C2=A0 =C2=A0encryp= tion keys on the initial connection are derived from the shared
=C2=A0 = =C2=A0secret.=C2=A0 Connections can be re-keyed before the natural AEAD lim= it
=C2=A0 =C2=A0for a single set of traffic encryption keys is reached.<= br>
=C2=A0 =C2=A0Each tcpcrypt session is associated with a ladder of re= sumption IDs,
=C2=A0 =C2=A0each derived from the respective entry in a l= adder of shared secrets.
=C2=A0 =C2=A0These resumption IDs can be used t= o negotiate a stateful resumption
=C2=A0 =C2=A0of the session in a subse= quent connection, resulting in use of a new
=C2=A0 =C2=A0shared secret a= nd traffic encryption keys without requiring a new key
=C2=A0 =C2=A0exch= ange.=C2=A0 Willingness to resume a session is signaled via the ENO
=C2= =A0 =C2=A0option during the TCP handshake.=C2=A0 Given the length constrain= ts
=C2=A0 =C2=A0imposed by TCP options, unlike stateless resumption mech= anisms (such
=C2=A0 =C2=A0as that provided by session tickets in TLS) re= sumption in tcpcrypt
=C2=A0 =C2=A0requires the maintenance of state on t= he server, and so successful
=C2=A0 =C2=A0resumption across a pool of se= rvers implies shared state.

How does all this detail help someone un= derstand the role that tcpcrypt
plays in the ecosystem. Suppose, for ins= tance, that tcpcrypt didn't
have resumption at all (not a totally ab= surd design decision), how would
that meaningfully affect the consumer&#= 39;s experience of using it in a
system?


Partly my complaint = here is about presentation: a flat list of protocols
complete with a lot= of detail serves to obscure the high order
architectural ideas. However= , I think it's also a conceptual issue,
which is that this document = focuses on the security services provided
(PFS, unilateral authenticatio= n, etc.) but that's actually a way in
which these protocols are quit= e similar, deriving as they mostly do
from the same few underlying crypt= ographic handshake shapes, with the
differences to a great extent depend= ing on in which era the protocols
were designed (e.g., AES-CTR/HMAC vers= us AES-GCM), and where even
those properties are to some extent subject = to negotiation. It's
also not uncommon to see features migrate betwe= en protocols, but that
doesn't change the basic architectural proper= ties.

Instead, I think this document -- if it is to exist at all -- = should
focus on the architectural position that these protocols occupyin the stack rather than on the details of the protocol. This
would gi= ve you something that looked like this:

- Generic application-layer = channel security protocols
=C2=A0 - TLS
=C2=A0 - DTLS
=C2=A0 - QUI= C* [Plus some other stuff]
=C2=A0 - CurveCP (?)
=C2=A0
- Transpor= t-level security
=C2=A0 - tcpcrypt
=C2=A0 - MinimaLT (?)
=C2=A0 - IP-layer VPN protocols
=C2=A0 - IKEv2,
=C2=A0 - OpenVPN
=C2= =A0 - WireGuard
=C2=A0 - DTLS VPNs

- Application-bound protocols<= br>=C2=A0 - DTLS-SRTP, ZRTP

And then I would have each of these star= t by emphasizing the common
features of these protocols and how they fit= into the ecosystem, and
only briefly cover differences in the protocols= to the extent to which
they were meaningfully observable (usually barel= y at all).

One thing I would emphasize in this context is that the p= rotocol
differences are far less relevant from this perspective. For ins= tance,
OpenVPN and IKEv2/IPsec use totally different cryptographic hands= hakes
but from an architectural perspective they fit into the same basic=
box, which is part of why OpenVPN is such an easy drop-in for
IPsec-= style systems.

Another example along these lines is TLS: SSLv2, SSLv= 3/TLS1.0-1.2, and
TLS 1.3 are really quite different protocols, but they= all occupy
the same basic position in the stack and serve the same purp= oses,
which is why it has been (relatively) easy to just drop newer
v= ersions of TLS into the system.

Once you do this, I think you will a= lso need to radically rework
S 6, but I'm willing to withold judgeme= nt.


I made a number of more detailed comments on my copy, but up= on
looking back, I think they mostly apply to sections I think
you sh= ould cut.
--000000000000ebf84505945a43b0-- From nobody Wed Oct 16 04:12:05 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AFB1200EC; Wed, 16 Oct 2019 04:12:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: ietf@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Paul Wouters Message-ID: <157122432277.7898.5381887084807383180@ietfa.amsl.com> Date: Wed, 16 Oct 2019 04:12:02 -0700 Archived-At: Subject: [Taps] Secdir last call review of draft-ietf-taps-transport-security-09 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 11:12:03 -0000 Reviewer: Paul Wouters Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is: Ready I had done an early review and checked the differences since, and it addressed my remaining nits. From nobody Thu Oct 24 01:06:26 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FD91208D9; Thu, 24 Oct 2019 01:06:24 -0700 (PDT) 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 vcePoDQdcNb7; Thu, 24 Oct 2019 01:06:22 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50085.outbound.protection.outlook.com [40.107.5.85]) (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 57B06120048; Thu, 24 Oct 2019 01:06:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cKKr+adZRCD1FOyn0lkgx88LLgCYhHnQtgi2musBY29kMSSuQPllbt2tpBgg9a0kDqHwF0C7+R29/twHJcOB++bM/YE4v0tRvBqOva2HoHbP5vAYMeYBzDpmgd9t6uUwZG1R+oCmMb2kN/eV7gsSg69i1tEp3rGVAwAFMZOSBC4x0vveMYhT899NFKJg8OGW5tfqHYUakogdGgE18TkmZDRvUbJApZD80Hpu0pHCvgZufRb74dYsiy+N0OV1dxb/TJXFxCCZoDJJ9x1kcgef3HndnIEjIKtHSSVC84BD+B/GJb2P0IuU3mV+JmSUL9RTMkVXohyxBPZimN8JQM9P0w== 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=xfriAA3SSvn6dWjr5e9MnwuoQ1SbjAnRzMiHbdr5G6M=; b=nwYuU9nrATwXR6Pd2C/cqmk/QmrkQfs/PX9htlwHzsU3Wd7s8KzDfObP0gxgK26t1zBU625ueWewsDjww6dMDwYskjyqcApcN4haUJYKWJIhyKcT8tQIni+Kbj7+GzewT3UuFqnZxYsJNK7wsmie2QX0ziEF+5PCW4nmxuH4CX9MU6dLxwNTRNPCBeSfDReu65xEUUpT8Iu2jFubcY6JIRSNmBuk/2LXf8V8jFQsTQnSohWBkQg9Fk5wXhaYBhiT8L2td3WsIBR0eJoYEnxSJFT8S/ZBCHVL2VJr2U69QIJSztxhonSX6A+hI/XInZsCixuFK+mkr55f0FdgOBvs4Q== 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=xfriAA3SSvn6dWjr5e9MnwuoQ1SbjAnRzMiHbdr5G6M=; b=fa5Vfy1R4R33FnLGXvu+kXnrnAmz4BqxGV7H68sojAOeS6LGI6WgPbSk1qHS473DeEufuO5+EUVqg7ccF2axH3Ms//8HxYv5YRO50JwC66pwokG9fK8+7gcj4iF+5jemzqJroCwsowQlYHTuIw4ZATg3+6o5m8ro7gW3U5vN42o= Received: from HE1PR0701MB2697.eurprd07.prod.outlook.com (10.168.188.16) by HE1PR0701MB2667.eurprd07.prod.outlook.com (10.168.188.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Thu, 24 Oct 2019 08:06:20 +0000 Received: from HE1PR0701MB2697.eurprd07.prod.outlook.com ([fe80::1d5c:4814:3c1e:b769]) by HE1PR0701MB2697.eurprd07.prod.outlook.com ([fe80::1d5c:4814:3c1e:b769%10]) with mapi id 15.20.2387.019; Thu, 24 Oct 2019 08:06:20 +0000 From: Magnus Westerlund To: "taps@ietf.org" , "draft-ietf-taps-transport-security.all@ietf.org" Thread-Topic: IETF last call comments on draft-ietf-taps-transport-security Thread-Index: AQHVikHr1GhdQdO2WEOQmxKct/uzOA== Date: Thu, 24 Oct 2019 08:06:19 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a2d5142-ae7b-4ef4-0f1e-08d758590da6 x-ms-traffictypediagnostic: HE1PR0701MB2667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0200DDA8BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(366004)(346002)(136003)(39860400002)(199004)(189003)(2906002)(3846002)(6116002)(110136005)(102836004)(99286004)(316002)(5660300002)(118296001)(14444005)(15650500001)(256004)(2501003)(8676002)(6486002)(71200400001)(6436002)(8936002)(71190400001)(81156014)(81166006)(66616009)(486006)(86362001)(99936001)(76116006)(66556008)(476003)(305945005)(66476007)(2616005)(66066001)(186003)(478600001)(66946007)(64756008)(26005)(450100002)(36756003)(6506007)(7736002)(6512007)(66446008)(14454004)(44832011)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2667; H:HE1PR0701MB2697.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: X3f5sWVF+bbx0v4cay0zniMGeRHFFVH8mUI63Qn8QW4m2mhimECkyJWHBP2oOhRf/NV0yS4rZkHQILo0AG03JIdFbjgU8Ke6QUkynrPQ3QS7BYdVamOCHF9WYVZN7pFDudF3oBG7qR/H0uMcpnEf4F1O+d0dkK1xap7mgAeP2BpJer9+YaTA/NSQ7n46NPo4TKPVXvdr3OJFnxvzPPMkyJmSj48m34qc8B0ihYxo+C/laZ4L+Rv8+Sse3xYQf1NNskFL6HU7trps7e/7LOiA3QaWBCle3SaUSrxJDVcMPCDpgYnALxr8dT1/EJTmq5OBzfGUFcqRrwdsoMtBM+TtKNknUvpfgZSaji4vQOFefwCXFK+M2cOaAZ7gg5jdOMbC0T8SXO2/4+DSeSvlVGUr29VqMsT0wCeQ6xIYxf3Pfa/YaGzSq91mQ2cn3+3gtCsf x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-0OWP5A69mKnpiEQoEMDj" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a2d5142-ae7b-4ef4-0f1e-08d758590da6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2019 08:06:19.8695 (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: ylcTylPzv3Dbq9vFzyS0vE3BGVqo2CyI8nCdu5Mqr2STeF4lUta3xtuYf87RuHcNTAsxuUxnQhF29CmoDcXll/eYwI/UsIDkh9L36mgsM74= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2667 Archived-At: Subject: [Taps] IETF last call comments on draft-ietf-taps-transport-security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 08:06:25 -0000 --=-0OWP5A69mKnpiEQoEMDj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authors and WG, Considering the IETF last call comments by Eric Rescorla and Christian Huit= ema I would like to see discussion on the points they bring up. I can understand = that addressing this fully could be a very significant change to the document.= =20 I do see the point they are bringing up about the architectural view of how= the protocols are used. I get the impression that TAPS does have a small set of viable security architectures and the choices do affect properties seen fro= m the TAPS API level. Also there are details beyond the properties that gets affe= cted by the layering of security and transport mechanisms and what implementatio= n parts you have to trust for the security properties. So discussion of these aspects may be needed.=20 So please discuss how these are addressed.=20 =20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-0OWP5A69mKnpiEQoEMDj Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTAyNDA4MDYxOFowLwYJKoZIhvcN AQkEMSIEIIngMUOPVZbO51dGm26eydrA/NUprk4Ea8TlYOR8J1eAMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAXagqeOiNM0fD Eyooe8wmh9JnoGjv18JJmobMQ0D9MZxW5vwEnXYjk36e+26Ts9VxIKCJ2d05hvbqS19iA1HG1rOJ tiNURPAweK6OpC02WoKwBxvX4V8S/+KKOQv7SZMVLsA0je4QP08aeqBQW1/mP4fGjiwu+/U0Pv/9 y7ezhREqMVojNtz9mI22C1+bhAvVSp6PKbQwSiap8GN9wf9N5Mb6JVHT5Su6H2Q/j/g8drILnIuy SCVs2EXE7CPhcwiaF4kW4mx4ycI72wAsoFSnQYx18CeOX4nj+NX6j7zCA1KfnRlxY8L2ziBFZGOa jmELSrp0a/essZTQ/drNLKmh9gAAAAAAAA== --=-0OWP5A69mKnpiEQoEMDj-- From nobody Thu Oct 24 06:10:17 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FA6120120 for ; Thu, 24 Oct 2019 06:10:16 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 BwegIFsIZ8JA for ; Thu, 24 Oct 2019 06:10:13 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30071.outbound.protection.outlook.com [40.107.3.71]) (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 BD7BC12011C for ; Thu, 24 Oct 2019 06:10:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A5XM5CxqbrCH4U1NI6ASJ1MlfdFogcEAFKCqCj9qZ6a8Ej4Jb2zVLmNbc58x7HrYvqDqLe/TtNDSf+1wrA/ffs6x7GE5cjXXgh+iEQkKKymHnXYCivlCoeHtbFKlw1IuebCWyC+T3jwyo/Ls0iwIuRYD47R5i6PfRTRwpkCCH/8LJ5/4C0wfOt5a81Gwgc9gJR80cZ52eiJPpgvkkB/lIqDDcP853nCIA4MU0JwCmChkKsRwi5wKm6z/ybAOSq+ZCWfbsfBt8mQW4bzqkT+e2W5lxXP0Y8plqj/upOkPxQJBQVaCpkLpPnS6fIHzfO0GvOnMIDLfxrbPMzX6fw6fQQ== 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=ij25+DsC91B3GeO+6i8x1EzIAn0nIveQ1NXZUvpVEeo=; b=ghXqDY2E+30pyoYhAD1aUCbtx7jhLnQVo0+8oVnkeqE6w75tcjwX8ZulHZdOuQm9wHfBMQdrJ6/o0abv3pEFueBg13NRdYjQVsXtcX9qsyqiZFCagQSr1b9ljgqZ1mpR+tUV6dvQrgjJbwajt97BCNPbe+Urnq8lGy/0AbaTW/ld42hggiw3RR+C/mniKKPmYDPBC0/XgnKPY7dkMWjTvArue3XRlGITuqUYB7tM5MJKROlYFicQ9Ho1u5sA6HVd+UCmc7QDD/VJ0+YMuEplNg0ZwInE04Wdap/qE1VaUaRPwGjJ9NBUa8UbfyoKdCXtwnqOdjhqTXIXFisAXXZJIA== 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=ij25+DsC91B3GeO+6i8x1EzIAn0nIveQ1NXZUvpVEeo=; b=YMxNxSFEJK/tn7i3fFbJJpa4ZZVIvEVwcNuxAfkDCGlLPeXM7J1PUnrV3+o6pTKUXRIDOX+a8Fm+M6UONQV9GBvn1c6J17jL/pzZi35iqHjChF6HxtUYE11UJkWXMmejIXv06jF9X2XJasGT3+VGn2Dy5acvwGbU0jfd7TKOJjI= Received: from HE1PR0701MB2697.eurprd07.prod.outlook.com (10.168.188.16) by HE1PR0701MB2937.eurprd07.prod.outlook.com (10.168.98.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.18; Thu, 24 Oct 2019 13:10:10 +0000 Received: from HE1PR0701MB2697.eurprd07.prod.outlook.com ([fe80::1d5c:4814:3c1e:b769]) by HE1PR0701MB2697.eurprd07.prod.outlook.com ([fe80::1d5c:4814:3c1e:b769%10]) with mapi id 15.20.2387.019; Thu, 24 Oct 2019 13:10:10 +0000 From: Magnus Westerlund To: "taps@ietf.org" Thread-Topic: [saag] Fwd: Last Call: (A Survey of Transport Security Protocols) to Informational RFC Thread-Index: AQHVert4Ra17n+l+i06Fdbvrm+1NV6dNzCYAgAOG9gCAAE3eAIAYQbMw Date: Thu, 24 Oct 2019 13:10:10 +0000 Message-ID: References: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> <20191006161144.GV6722@kduck.mit.edu> <3278891e-a18f-4045-6efb-34d76d608352@huitema.net> In-Reply-To: <3278891e-a18f-4045-6efb-34d76d608352@huitema.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1f2eb9b9-8eb2-4a15-c4ec-08d758837fb4 x-ms-traffictypediagnostic: HE1PR0701MB2937: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0200DDA8BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(39860400002)(396003)(346002)(199004)(189003)(6916009)(71200400001)(71190400001)(14454004)(8936002)(55016002)(1730700003)(52536014)(33656002)(229853002)(2473003)(9686003)(54896002)(81166006)(81156014)(66066001)(6306002)(76116006)(64756008)(66476007)(66946007)(66446008)(66556008)(66616009)(6436002)(8676002)(5640700003)(478600001)(102836004)(316002)(6506007)(2351001)(2906002)(790700001)(6116002)(26005)(3846002)(186003)(7736002)(74316002)(25786009)(86362001)(76176011)(7696005)(99286004)(2501003)(99936001)(11346002)(486006)(44832011)(476003)(558084003)(446003)(14444005)(256004)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2937; H:HE1PR0701MB2697.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: oDJ4ornr+zK/K6/4iV7sZ76uwgygLnKbxSWNfjJCm3Jhd/KQK9SkHAHm6Z4CDxmVZnvkUOJjKMjIoghZGsO6toqgpujzKPgGrEdrl7oHoGGd9vkNUL6Rxg0bRcX4Dfb/jSXUczuBr4pajIn2D30iSUhA0BbAQ3ne0VvcxKnz4Qe6DkZSuuY9qjWPGF6Z6OnX6j2YeCf4M7UAuAM/X7NTf7wc+6rU/7EKhjOd2JjCD7EM/S2y+Yp0iMeEeeq5+V92TIDtSrVhpf6ZyECFRRkExByE+94nUGItavtFvxabSRGjuMiqiXm4pvmdpAgTs3AsJHsIHBSOSEBjoVTcEzZGZgIK6yNpMhiC1xi8+UL5STZ4wZMkFti0ifNZDnJvwhTFj/zLtvPnNuSPLEDVKLf+2HcPLLbWbQ5VyKYB+1G7zl7KqYSkOIplksVSPnno55ye x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0009_01D58A7D.1CDBCE50" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f2eb9b9-8eb2-4a15-c4ec-08d758837fb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2019 13:10:10.1278 (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: LLQ0uPQciVkQdnVvvAZ3bb1R1l6/Mo5weuq69Uv/I6S4R2c5ddTUf8dahN/sZaXTZSXrnruo3CmDOLp9iFMozJgABeUzwMJpzy+9AGnht+E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2937 Archived-At: Subject: [Taps] FW: [saag] Fwd: Last Call: (A Survey of Transport Security Protocols) to Informational RFC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 13:10:16 -0000 ------=_NextPart_000_0009_01D58A7D.1CDBCE50 Content-Type: multipart/mixed; boundary="----=_NextPart_001_000A_01D58A7D.1CDBCE50" ------=_NextPart_001_000A_01D58A7D.1CDBCE50 Content-Type: multipart/alternative; boundary="----=_NextPart_002_000B_01D58A7D.1CDBCE50" ------=_NextPart_002_000B_01D58A7D.1CDBCE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, As Philipp asked about my reference to Christian's email and it wasn't sent to the WG. It was sent to SAAG, and a response to a request for people to take a look by one of the Sec Ads. Cheers Magnus Westerlund ------=_NextPart_002_000B_01D58A7D.1CDBCE50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As Philipp asked about my reference = to Christian’s email and it wasn’t sent to the WG. It was = sent to SAAG, and a response to a request for people to take a look by = one of the Sec Ads.

 

Cheers

 

Magnus Westerlund

------=_NextPart_002_000B_01D58A7D.1CDBCE50-- ------=_NextPart_001_000A_01D58A7D.1CDBCE50 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0511C1200BA; Tue, 8 Oct 2019 19:42:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF712006D for ; Tue, 8 Oct 2019 19:42:55 -0700 (PDT) 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 SXsFF4OC6a0a for ; Tue, 8 Oct 2019 19:42:51 -0700 (PDT) Received: from HE1EUR02FT062.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::209) by DB6PR07CA0084.outlook.office365.com (2603:10a6:6:2b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.11 via Frontend Transport; Wed, 9 Oct 2019 02:43:10 +0000 Received: from mail.ietf.org (4.31.198.44) by HE1EUR02FT062.mail.protection.outlook.com (10.152.11.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.20 via Frontend Transport; Wed, 9 Oct 2019 02:43:09 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F74012010D; Tue, 8 Oct 2019 19:43:07 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iI1w4-0004hA-7D for saag@ietf.org; Tue, 08 Oct 2019 19:42:44 -0700 Received: (qmail 24778 invoked from network); 9 Oct 2019 02:42:43 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Oct 2019 02:42:43 -0000 Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 7EFA312007A for ; Tue, 8 Oct 2019 19:42:51 -0700 (PDT) Received: from xse380.mail2web.com ([66.113.197.126] helo=xse.mail2web.com) by mx12.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iI1w7-0006pS-7P for saag@ietf.org; Wed, 09 Oct 2019 04:42:49 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46nz5w2TpBz3CjT for ; Tue, 8 Oct 2019 19:42:44 -0700 (PDT) Received: from AM5EUR02FT053.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e1e::200) by AM3PR07CA0063.outlook.office365.com (2603:10a6:207:4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13 via Frontend Transport; Wed, 9 Oct 2019 02:43:13 +0000 Received: from mx.emea.email.fireeyecloud.com (154.57.155.23) by AM5EUR02FT053.mail.protection.outlook.com (10.152.9.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.20 via Frontend Transport; Wed, 9 Oct 2019 02:43:13 +0000 Received: from AM0PR07MB4306.eurprd07.prod.outlook.com (2603:10a6:10:d4::21) by DB7PR07MB5736.eurprd07.prod.outlook.com with HTTPS via DBBPR09CA0033.EURPRD09.PROD.OUTLOOK.COM; Wed, 9 Oct 2019 02:43:14 +0000 Received: from AM3PR07CA0063.eurprd07.prod.outlook.com (2603:10a6:207:4::21) by AM0PR07MB4306.eurprd07.prod.outlook.com (2603:10a6:208:b1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 9 Oct 2019 02:43:13 +0000 Received: from [10.81.176.253] ([10.81.176.253:42816] helo=ams-etp-emps-prod-14.fireeyecloud.com) by AMS-110 (envelope-from ) (ecelerity 4.2.38.62370 r(:)) with ESMTPS (cipher=DHE-RSA-AES128-GCM-SHA256) id 66/93-26187-1494D9D5; Wed, 09 Oct 2019 02:43:13 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2054.outbound.protection.outlook.com [104.47.14.54]) by prd07-euw1-15 (envelope-from ) FireEye ETP with ESMTPS (cipher=AES256-GCM-SHA384) id 1168009810494D9D5a57de553; batch_id 11/68-00981-0494D9D5; Wed, 9 Oct 2019 02:43:12 +0000 (UTC) Received: from DB6PR07CA0084.eurprd07.prod.outlook.com (2603:10a6:6:2b::22) by DB7PR07MB5096.eurprd07.prod.outlook.com (2603:10a6:10:2b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Wed, 9 Oct 2019 02:43:10 +0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by ams-etp-emps-prod-14.fireeyecloud.com (Postfix) with SMTP id 46nz6T00c6znnR5 for ; Wed, 9 Oct 2019 02:43:13 +0000 (UTC) Received: from mx.emea.email.fireeyecloud.com (ams-etp-emps-data-prod-vip.cso.fireeye.com [10.81.75.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams-etp-emps-prod-14.fireeyecloud.com (Postfix) with ESMTPS id 46nz6S4J2YznnR1 for ; Wed, 9 Oct 2019 02:43:12 +0000 (UTC) From: "Christian Huitema" Sender: "saag" To: "Benjamin Kaduk" , References: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> <20191006161144.GV6722@kduck.mit.edu> In-Reply-To: Subject: Re: [saag] Fwd: Last Call: (A Survey of Transport Security Protocols) to Informational RFC Date: Wed, 9 Oct 2019 04:42:42 +0200 Message-ID: <3278891e-a18f-4045-6efb-34d76d608352@huitema.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_01D58A7D.1CDB0B00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHVert4Ra17n+l+i06Fdbvrm+1NV6dNzCYAgAOG9gCAAE3eAA== List-Help: List-Subscribe: , List-Unsubscribe: , Content-Language: en-us x-ms-exchange-organization-authas: Anonymous x-ms-exchange-organization-authsource: AM5EUR02FT053.eop-EUR02.prod.protection.outlook.com x-ms-exchange-organization-originalserveripaddress: 10.152.9.196 x-ms-exchange-organization-originalclientipaddress: 154.57.155.23 authentication-results: spf=fail (sender IP is 154.57.155.23) smtp.mailfrom=ietf.org; ericsson.com; dkim=fail (body hash did not verify) header.d=ietf.org;ericsson.com; dmarc=none action=none header.from=huitema.net;compauth=none reason=405 x-originating-ip: 66.113.197.126 x-forefront-antispam-report: CIP:154.57.155.23;IPV:CAL;SCL:-1;CTRY:US;EFV:NLI;SFV:SFE;SFS:;DIR:INB;SFP:;SCL:-1;SRVR:AM0PR07MB4306;H:mx.emea.email.fireeyecloud.com;FPR:;SPF:None;LANG:en; received-spf: Pass (protection.outlook.com: domain of ietf.org designates 4.31.198.44 as permitted sender) receiver=protection.outlook.com; client-ip=4.31.198.44; helo=mail.ietf.org; x-ms-publictraffictype: Email list-id: Security Area Advisory Group dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1570588977; bh=JmLRh/akPYqL/7WBoq8J+RLWd4AVjR0JbfFwqdqhWuU=; h=From:To:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=DBqLf1cW5MTaC8A9Srzz27PG0YQOkETCV7W0nptcufrrjeG+5lGz2iYJlO60e4+hc +FviC2yqFgLKYpkGIzAA+IPIEv6mGZmqIHV3dt3Ih+Y42Ha2wejSwf6HRH8wE0wK9q 0OZAiiGg7BZHs/2rj2HtLXrpHPrA+o5hFU3/e66M= list-archive: x-original-to: saag@ietfa.amsl.com x-beenthere: saag@ietf.org errors-to: saag-bounces@ietf.org x-mailman-version: 2.1.29 list-post: user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 delivered-to: saag@ietfa.amsl.com x-ms-office365-filtering-correlation-id: 669d7a97-9e43-4945-5049-08d74c626e07 x-microsoft-antispam: BCL:0; x-ms-traffictypediagnostic: DB7PR07MB5096:|DB7PR07MB5096:|AM0PR07MB4306: This is a multipart message in MIME format. ------=_NextPart_000_0004_01D58A7D.1CDB0B00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01D58A7D.1CDB3210" ------=_NextPart_001_0005_01D58A7D.1CDB3210 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Please disregard my previous message. I got my email very confused, and reviewed a TSVWG draft instead of draft-ietf-taps-transport-security-09.txt. My assessment of draft-ietf-taps-transport-security-09.txt would be pretty close to EKR's review. The TAPS architecture assumes some kind of "protocol agnostic" API. Applications would specify the transport features that they want using an abstract definition, and the TAPS implementation would then automatically select among the implementations available on the platform. In the target scenario, the application could specify something like "encrypted connection, authenticating the server, and providing a reliable stream". The platform could then select "SCTP over DTLS", or "TLS over TCP", or "QUIC". I personally have serious doubts about the viability of such scenarios. Protocols like QUIC or TLS are implemented in application space and shipped with the application code, so an application can guarantee that its protocol of choice is available without going through a selection API. But the IETF did charter the TAPS working group and that's what it does. Based on the TAPS charter, the authors go on to inventory a set of security protocols and attempt to characterize them by drawing a set of properties. I agree with EKR's observation that the proposed classification feels somewhat arbitrary. Can we really compare IPSEC and TLS by checking whether they support pre-shared keys or source validation? Can we do that without analyzing the type of identities supported by these protocols? Obviously, much of the security properties are function of something else that API features. Can we compare TLS 1.0 negotiating RC4 to TLS 1.3 negotiating AES128-GCM? If we really dream of protocol selection APIs as envisaged in the TAPS charter, should it expose available algorithms as well as stated features? Does it matter whether there is a formal proof available for the protocol design? In fact, this document begs another question. It is a product of a transport area working group trying to compare properties of protocols defined in the security area. It is applying the same methodology to comparing security protocols that it used for comparing UDP, TCP and SCTP. Clearly, some of the authors do have security expertise, but that's the working group as a whole does not. Should the transport area write down assessments of security protocols? -- Christian Huitema On 10/8/2019 3:04 PM, Christian Huitema wrote: As the draft mentions: The use of transport layer authentication and encryption exposes a tussle between middlebox vendors, operators, applications developers and users Much of the draft content goes on explaining the middlebox vendors' view of that tussle. As such, the draft is not terribly helpful... On 10/6/2019 9:12 AM, Benjamin Kaduk wrote: I think several folks have taken an early look at this one; now would be a great time to take a second look. -Ben On Fri, Oct 04, 2019 at 06:55:56AM -0700, The IESG wrote: The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'A Survey of Transport Security Protocols' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. Moreover, this document defines a minimal set of security features that a secure transport system should provide. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_001_0005_01D58A7D.1CDB3210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please disregard my previous message. I got my email very confused, and reviewed a TSVWG draft instead of draft-ietf-taps-transport-security-09.txt.

My assessment of draft-ietf-taps-transport-security-09.txt would be pretty close to EKR's review.

The TAPS architecture assumes some kind of "protocol = agnostic" API. Applications would specify the transport features that they want using an abstract definition, and the TAPS implementation would then automatically select among the implementations available on the platform. In the target scenario, the application could specify something like "encrypted connection, = authenticating the server, and providing a reliable stream". The platform = could then select "SCTP over DTLS", or "TLS over = TCP", or "QUIC". I personally have serious doubts about the viability of such scenarios. Protocols like QUIC or TLS are implemented in application space and shipped with the application code, so an application can guarantee that its protocol of choice is available without going through a selection API. But the IETF did charter the TAPS working group and that's what it does.

Based on the TAPS charter, the authors go on to inventory a set of security protocols and attempt to characterize them by drawing a set of properties. I agree with EKR's observation that the proposed classification feels somewhat arbitrary. Can we really compare IPSEC and TLS by checking whether they support pre-shared keys or source validation? Can we do that without analyzing the type of identities supported by these protocols? Obviously, much of the security properties are function of something else that API features. Can we compare TLS 1.0 negotiating RC4 to TLS 1.3 negotiating AES128-GCM? If we really dream of protocol selection APIs as envisaged in the TAPS charter, should it expose available algorithms as well as stated features? Does it matter whether there is a formal proof available for the protocol design?

In fact, this document begs another question. It is a product of a transport area working group trying to compare properties of protocols defined in the security area. It is applying the same methodology to comparing security protocols that it used for comparing UDP, TCP and SCTP. Clearly, some of the authors do have security expertise, but that's the working group as a whole does not. Should the transport area write down assessments of security protocols?

-- Christian Huitema

On 10/8/2019 3:04 PM, Christian = Huitema wrote:
=20

As the draft mentions:

   The use of transport layer authentication and encryption =
exposes a
   tussle between middlebox vendors, operators, applications developers
   and users

Much of the draft content goes on explaining the middlebox vendors' view of that tussle. As such, the draft is not terribly helpful...

On 10/6/2019 9:12 AM, Benjamin = Kaduk wrote:
I think several folks =
have taken an early look at this one; now would be a
great time to take a second look.

-Ben

On Fri, Oct 04, 2019 at 06:55:56AM -0700, The IESG wrote:

The IESG has received a =
request from the Transport Services WG (taps) to
consider the following document: - 'A Survey of Transport Security =
Protocols'
  <draft-ietf-taps-transport-security-09.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits =
final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-18. =
Exceptionally, comments may be
sent to iesg@ietf.org =
instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document provides a survey of commonly used or notable network
   security protocols, with a focus on how they interact and integrate
   with applications and transport protocols.  Its goal is to supplement
   efforts to define and catalog transport services by describing the
   interfaces required to add security protocols.  This survey is not
   limited to protocols developed within the scope or context of the
   IETF, and those included represent a superset of features a Transport
   Services system may need to support.  Moreover, this document defines
   a minimal set of security features that a secure transport system
   should provide.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-taps=
-transport-security/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-taps=
-transport-security/ballot/


No IPR declarations have been submitted directly on this I-D.




_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-annou=
nce

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/=
mailman/listinfo/saag
------=_NextPart_001_0005_01D58A7D.1CDB3210-- ------=_NextPart_000_0004_01D58A7D.1CDB0B00 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-ID: <2B577C0C4E273540A424B69E54A7E39E@eurprd07.prod.outlook.com> Content-Disposition: attachment; filename="ATT00001.txt" _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag ------=_NextPart_000_0004_01D58A7D.1CDB0B00-- ------=_NextPart_001_000A_01D58A7D.1CDBCE50-- ------=_NextPart_000_0009_01D58A7D.1CDBCE50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xOTEwMjQxMzEwMDNaMCMGCSqGSIb3DQEJBDEWBBRyozaeAF7d6IKgbIutcqNXQPmy wzBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBAI9VEW/OPjjVh8FzuSSItevxt/9yy7eVQub/eZCKX3v1T82p oZj2AFfgzscBmr0VUIM2ym+01LZAX5z+GbocZw5rDjriz3E0ovGGZzJYFaNa61Huf8nxEfC8imtn ZQ3RBoje62VYeJc42Vysa/V2fsYAkL5gWU2TzLf0EOKF8uesUr6Itr0vstoUdmtQuJ1lKj9WlDiS oFEjnwo9yKRCbW7he7XNDjS8ZFhfTXAPJ2o0x+ba49o0IitkwZLVunbfOCnAWRg/3EMdF+VwgIkI PrQnqGjxrRh9FmW7yylINxELqEu/8MiWPYAUHTTeeUWlOYmSNSjLvXqm4vOZo6AvwWwAAAAAAAA= ------=_NextPart_000_0009_01D58A7D.1CDBCE50-- From nobody Fri Oct 25 01:02:23 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9512012D for ; Fri, 25 Oct 2019 01:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 QvtCy0Ikk7is for ; Fri, 25 Oct 2019 01:02:18 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 DDF3412012A for ; Fri, 25 Oct 2019 01:02:17 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iNuVx-0002N0-U7 for taps@ietf.org; Fri, 25 Oct 2019 08:00:05 +0000 Content-Type: multipart/alternative; boundary="===============7384721001378382791==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 25 Oct 2019 08:00:05 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 08:02:20 -0000 --===============7384721001378382791== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+2/-5/=F0=9F=92=AC6) 2 issues created: - Default values (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/357 [API] = - Fix "Implementing maintenance" section (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/356 = 6 issues received 6 new comments: - #257 Not all Events are shown in the diagram (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/257 [Architecture] = - #145 Draft should point at implementations somewhere (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/145 [Implementation] [= ready for text] = - #309 Clarification on queued receives (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/309 [API] = - #343 Listeners should have backpressure (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/343 [API] [ready for t= ext] = - #282 Implementation should describe how to handle proxies/TOR (1 by mir= jak) https://github.com/ietf-tapswg/api-drafts/issues/282 [Implementation] [= discuss] [help wanted] = - #255 Editorial: Move Message Object to basic objects section (1 by tfpa= uly) https://github.com/ietf-tapswg/api-drafts/issues/255 [Architecture] [di= scuss] = 5 issues closed: - Update implementation mapping text for SCTP https://github.com/ietf-tap= swg/api-drafts/issues/337 [Implementation] [ready for text] = - The recommended default and can we specify rather than recommend? https= ://github.com/ietf-tapswg/api-drafts/issues/317 [API] [ready for text] = - Listeners should have backpressure https://github.com/ietf-tapswg/api-d= rafts/issues/343 [API] [ready for text] = - Not all Events are shown in the diagram https://github.com/ietf-tapswg/= api-drafts/issues/257 [Architecture] = - Editorial: Move Message Object to basic objects section https://github.= com/ietf-tapswg/api-drafts/issues/255 [Architecture] [discuss] = Pull requests ------------- * ietf-tapswg/api-drafts (+4/-4/=F0=9F=92=AC2) 4 pull requests submitted: - Architecture: Make overview section an actual overview (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/355 = - Cleanup diagram to remove message, and add rendezvous (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/354 = - Rename "Basic Objects" to "Connection Objects" to reduce confusion (by = tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/353 = - Implementation: mapping back to RFC 8303 (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/352 = 2 pull requests received 2 new comments: - #352 Implementation: mapping back to RFC 8303 (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/352 = - #346 Fixes #313 per Gorry's comments (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/346 = 4 pull requests merged: - Implementation: mapping back to RFC 8303 https://github.com/ietf-tapswg/api-drafts/pull/352 = - Architecture: Make overview section an actual overview https://github.com/ietf-tapswg/api-drafts/pull/355 = - Cleanup diagram to remove message, and add rendezvous https://github.com/ietf-tapswg/api-drafts/pull/354 = - Rename "Basic Objects" to "Connection Objects" to reduce confusion https://github.com/ietf-tapswg/api-drafts/pull/353 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============7384721001378382791== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday October 25, 2019

Issues

ietf-tapswg/api-drafts (+2/-5/=F0=9F=92=AC6)

2 issues created:

6 issues received 6 new comments:

5 issues closed:

Pull requests

ietf-tapswg/api-drafts (+4/-4/=F0=9F=92=AC2)

4 pull requests submitted:

2 pull requests received 2 new comments:

4 pull requests merged:

Repositories tracked by this digest:

--===============7384721001378382791==-- From nobody Fri Oct 25 14:20:04 2019 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 011B7120A2D; Fri, 25 Oct 2019 14:12:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: magnus.westerlund@ericsson.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793699.2724.7451086718990701161.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:17 -0700 Archived-At: Subject: [Taps] taps - Requested session has been scheduled for IETF 106 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:14:08 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:00 requested) Tuesday, 19 November 2019, Afternoon Session II 1520-1650 Room Name: Hullet size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/taps.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: maprg panrg httpbis Technology Overlap: quic tls tsvarea tsvwg tcpm iccrg coinrg Key Participant Conflict: irtfopen rmcat avtcore mops loops mboned secdispatch mops tsvwg ippm People who must be present: Colin Perkins Aaron Falk Michael Welzl Magnus Westerlund Gorry Fairhurst Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Anna Brunstrom Tommy Pauly Kyle Rose Christopher A. Wood Jake Holland Philipp S. Tiesel Theresa Enghardt Resources Requested: Special Requests: The IRTF Chair is a contributor to TAPS so please avoid IRTF RGs if possible. --------------------------------------------------------- From nobody Tue Oct 29 05:35:24 2019 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5077120074; Tue, 29 Oct 2019 05:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9ajqWG-9k_U5; Tue, 29 Oct 2019 05:35:21 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 67FCB1200F9; Tue, 29 Oct 2019 05:35:21 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x9TCZGEI026078 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 13:35:16 +0100 Received: from [217.7.22.35] (helo=c02z21drlvdm.dhcp.xxp.sap.corp) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1iPQg5-0003hI-Rk; Tue, 29 Oct 2019 13:32:49 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: "Philipp S. Tiesel" In-Reply-To: Date: Tue, 29 Oct 2019 13:35:14 +0100 Cc: "draft-ietf-taps-transport-security.all@ietf.org" , Magnus Westerlund Content-Transfer-Encoding: quoted-printable Message-Id: <2EDC8909-135A-4E09-A245-EA680C0545CD@in-panik.de> References: To: "taps@ietf.org" X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [Taps] IETF last call comments on draft-ietf-taps-transport-security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 12:35:23 -0000 Hi, as shepherd of the document and contributor to the WG, I am a little = puzzled about the way this document got stalled after overall successful = reviews. The major criticism I extracted from Eric's and Christian's = reviews is neither new nor surprising, but maybe we should iterate them = again to make the document more useful =E2=80=93 especially for people = that are generally skeptical towards TAPS' mission. Here are my thoghts on the major points of criticism: General skepticism towards TAPS: De-coupling the API contract from the actual transport used is an = ambitious project. It is easy to state that this is not going to happen = and that we can not fight (protocol) ossification, but this does not = remove the need to evolve, it just shifts the responsibility towards the = application developers. In the security domain, De-coupling the API = contract from the actual security protocol may look like a bad idea at = first glance, as every bad choice can lead to an additional attack = vector, but this is only true under the assumption that all application = developers are security experts. Using a "TAPS autopilot" for your = applications' secure transport can never be as secure as a complete = security design, but is certainly better than copy&paste from Stack = Overflow. This holds especially when looking at the software lifecycle. = The TLS library example from 2017 might still be acceptable today, but = won't be in 2023. The decision made in the TAPS system can be changed = with an OS update =E2=80=93 the application code won't.=20 The question is whether we must make this argument again and again or = accept that this form of general criticism can only prove right or wrong = over time. Security work outside of the Security area:=20 This document is clearly in Security scope. We had not a real an = alternative to writing this:=20 =E2=80=A2 Excluding security protocols from TAPS makes the whole = approach useless.=20 =E2=80=A2 Asking the security area to write the document for us = is not how the IETF works.=20 As we have people with strong security background among the authors and = in the group and asked for reviews from the Security area early on, I = see not how we could have approached this need differently.=20 What we can do is try to involve the Security area more than just asking = for reviews: approach the Security area, have this presented in = secdispatch, and ask for more input =E2=80=93 Not sure if this will = help. Mixed bag of things: This document is clearly two things: A survey of security protocols and = a description of the security-related transport features they provide we = need as input in the API and implementation documents. As the document is still of an acceptable size, we had a WG consensus = that this is acceptable. When reading EKR's review, I am not sure = whether this was a good decision. Having a clear separation of a survey = and MINSET-like feature document, like we did with RFC 8303 +=20 RFC 8304 and MINSET, would make the survey much cleaner and the feature = document better digestible, especially for people who are skeptical = towards the general TAPS idea. I think none of these are a reason to abandon the document, but things = we should briefly discuss here and now. Afterwards, we should use the = meeting in Singapore to coordinate the action items resulting from this = discussion. AVE! Philipp S. Tiesel > On 24. Oct 2019, at 10:06, Magnus Westerlund = wrote: >=20 > Authors and WG, >=20 > Considering the IETF last call comments by Eric Rescorla and Christian = Huitema I > would like to see discussion on the points they bring up. I can = understand that > addressing this fully could be a very significant change to the = document.=20 >=20 > I do see the point they are bringing up about the architectural view = of how the > protocols are used. I get the impression that TAPS does have a small = set of > viable security architectures and the choices do affect properties = seen from the > TAPS API level. Also there are details beyond the properties that gets = affected > by the layering of security and transport mechanisms and what = implementation > parts you have to trust for the security properties. So discussion of = these > aspects may be needed.=20 >=20 > So please discuss how these are addressed.=20 >=20 > Cheers >=20 > Magnus Westerlund=20 -- =20 Philipp S. Tiesel https://philipp.tiesel.net/