From nobody Tue Oct 1 00:58:09 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCA1200FB; Tue, 1 Oct 2019 00:58:08 -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 uOKQ06_H3sdD; Tue, 1 Oct 2019 00:58:05 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50077.outbound.protection.outlook.com [40.107.5.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206481200FE; Tue, 1 Oct 2019 00:58:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4WAkZvf5T0HUJfB9tSwH6lfWFuyM4FM3rXot6fXd3aekU1jEdI3EEeLRAYPwVeA910r8iZy6kQUuio5zvuGt4dTTPwDawOxZws5yAY4DgeLUfJrqaJBtw5+sNWS4jtMSmrEcSLTa3m9i4dQJZV2OyK9CSluu9UoLfg3ye7bJtCtpZaH0bgaQrcixiNfwmKwaENwf5JQJQJL8LM3WW/M15BrArLb5rtlllPoHcPQVFmCUEVEBw0ddlJo3D0XdV/j2fUJypWUi9IpZewb+IYa5jGFfKSBoR6eJ0XDRs8MY5ldg8CYtw5eUG8YqeVnxHpTGPZcMvrRQjqKqKdHblmHgg== 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=zkXciIVR0FP6L+X/GXVrquNICC9dYPh1b3+6tbJ0oaM=; b=Edpt0noizwqjayXaocdwqCl9o8F+abowL1T/97cgD5w6tCvl1tvgaFtQ+DXZz6OTIyOrXn298FX1gxDzI7piAElJ6TMEQvNzUgK3Sufkkap3J78sXW8xAZHxb+fHlMmcvKC6T5FQKMMCTbPeDyX7kZVm7pX8NZ1qK7CWb5mF8HN/DYyGJDP9oqwT7BJjtKBlN0Y+30eB+yj8ttpto1MUWB/JChdb94ryHIu9jPFE/GiI53IratrgPTFG3qlS3da79P9aOdsEBgCOp/x92y0nvI1mfqkAf346gZKYfxiHBVUZs5mR6P242O/gEa/U/9Rc7zbF7kKTkm09FPWSJ26dXw== 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=zkXciIVR0FP6L+X/GXVrquNICC9dYPh1b3+6tbJ0oaM=; b=mq+oXqSfjMe6DQQ9yTOnje9Yyx10aRw5j4OFPCa58xwnYjDK/0d7K0eRBWnHNSmdXz02zgicrqbkh/UzheGJsDjjuf8Tgw6saAdtCx8j2nNExFoVne2uDV9EXReO5mh5VGaYUxCcLa72Rwv2F561MRfxtO/wPSvG0OJ9zJzSKJM= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3148.eurprd07.prod.outlook.com (10.170.247.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Tue, 1 Oct 2019 07:58:02 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 07:58:02 +0000 From: John Mattsson To: Kathleen Moriarty , "Salz, Rich" CC: "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGqrOKnGYrSipku+oSGSF7Gj3ac9+dkAgAeauwA= Date: Tue, 1 Oct 2019 07:58:01 +0000 Message-ID: References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> In-Reply-To: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d8f73d1-4d64-4c00-d112-08d746451549 x-ms-traffictypediagnostic: HE1PR07MB3148: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(199004)(189003)(51444003)(13464003)(71190400001)(26005)(316002)(99286004)(966005)(33656002)(6436002)(229853002)(478600001)(76176011)(5660300002)(256004)(25786009)(14444005)(14454004)(71200400001)(86362001)(6486002)(44832011)(486006)(476003)(8936002)(64756008)(102836004)(2616005)(76116006)(66066001)(54906003)(6116002)(446003)(6246003)(11346002)(110136005)(53546011)(6506007)(305945005)(7736002)(66946007)(58126008)(66574012)(66556008)(4326008)(186003)(6512007)(2906002)(81156014)(81166006)(6306002)(8676002)(36756003)(3846002)(66476007)(66446008)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3148; H:HE1PR07MB4169.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: Bg0Q5ow2Twoka25D7eEpNCm/+arujI6ODo7GG3rz5urmA7kdFK/iVwaH0bGd7zf6aJ9zNWSU1xjZVU9G89SW1vbfALQdSZYzrz0wXLYvQ1NtR3LuQ9I8ugd0CIPE3mm5/RFkBZKhC2khOxv0z2V9ohXXQiSY4rzYcFzpmx79j/nYFHQR+7rlsWJwOznQ5TOORHGfp6aknVNNRx8WeXzhQT7rwO43q8ecWt19ueJwdH+Xvnk0DU+tZhliHVCO8D8C38MGuEI11Zbcwl08q+5+NLKaSldRMZcQa4EcDdkF/MxqZ3TcSNEdD4/hhOs5ctYdZgm9UsqqJrsmHqaCRkUhV9VjrqRGiQtVISYWCuTTuNE2blOv1LeJRH9Rwkjy5+C1ta6jY49MrziEMfvHYjgGa2P2rCUwy+FNEEEDgIYWWXXT+eF1z4kEzGRilA40HAxTwTEHJGUVwtIvM7HFDtF6tA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <680BB3D61A9F014187F8E81463EAD89D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d8f73d1-4d64-4c00-d112-08d746451549 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 07:58:01.8152 (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: iokg4aoxuc40s2fZLE9OhnixQ1bSiujPc8b7NUaAmWyvCwF2wmzaos+cjWfgMRgkSjlZzaR/pbk19rE7ASDSlzNtTRXp1IigcSBohOQyM7o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3148 Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 07:58:09 -0000 S2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90 ZToNCg0KPk5JU1QgaGFzIHB1c2hlZCBiYWNrIHRoZWlyIGRhdGUgZm9yIFVTIGdvdmVybm1lbnQg b3JnYW5pemF0aW9ucyB0byBoYXZlIGEgcGxhbiB0byBzdXBwb3J0IFRMU3YxLjMsIHdoYXTigJlz IHRoZSBkcml2ZXIgdG8gZ2V0IGFoZWFkIG9mIHRoYXQ/DQoNCk5JU1QgU1AgODAwLTUyIHJldiAy IHJlcXVpcmVzIHN1cHBvcnQgZm9yIFRMUyAxLjMgYnkgSmFudWFyeSAxLCAyMDI0LiBJIHRoaW5r IHRoYXQgaXMgYSBnb29kIGFuZCBhbWJpdGlvdXMgcGxhbi4gSW4gZmFjdCBpdCB3b3VsZCBiZSB2 ZXJ5IGdvb2QgaWYgSUVURiBhZ3JlZWQgb24gdGhlIHNhbWUgcmVxdWlyZW1lbnQuDQoNCj4gSSB0 aGluayBlbmNvdXJhZ2luZyBpbXBsZW1lbnRhdGlvbiBvZiBUTFN2MS4zIGlzIGdvb2QgYW5kIGlt cG9ydGFudCwgYnV0IGFyZSB0aGVyZSBvdGhlciB3YXlzIGJlc2lkZXMgZGVwcmVjYXRpb24/DQoN ClllcywgSSB0aGluayB0aGVyZSBpcyBhdCBsZWFzdCB0d28gdGhpbmdzIElFVEYgY2FuIGRvOg0K DQotIFRoZSBmaXJzdCB0aGluZyBpcyB0byBkbyBsaWtlIE5JU1QgYW5kIGFscmVhZHkgbm93IGdp dmUgaW1wbGVtZW50b3JzIGEgZGF0ZSB3aGVuIHN1cHBvcnQgZm9yIFRMUyAxLjMgaXMgcmVxdWly ZWQuDQoNCi0gVGhlIHNlY29uZCB0aGluZyBpcyB0byBkbyBsaWtlIDNHUFAgYW5kIG1hbmRhdGUg c3VwcG9ydCBmb3IgVExTIDEuMyBpbiBuZXcgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50 cy4NCg0KVGhpcyB3b3VsZCBhdm9pZCB0d28gdGhpbmcgdGhhdCBoYXBwZW5lZCBpbiB0aGUgcGFz dC4gRmlyc3QsIElFVEYgcHVibGlzaGVkIFJGQyA4MjYxIHRoYXQgbWFuZGF0ZWQgc3VwcG9ydCBm b3IgRFRMUyAxLjAgYW5kIG5vdCBEVExTIDEuMiBhbG1vc3QgNiB5ZWFycyBhZnRlciBSRkMgNjM0 NyBtYWRlIERUTFMgMS4wIG9ic29sZXRlLiBTZWNvbmRseSwganVzdCA3IG1vbnRocyBhZnRlciBw dWJsaXNoaW5nIGEgZHJhZnQgcmVseWluZyBvbiBEVExTIDEuMCwgSUVURiBzdGFydGVkIHdvcmtp bmcgb24gYSBkcmFmdCBmb3JiaWRkaW5nIGl04oCZcyB1c2UuDQoNCkNoZWVycywNCkpvaG4NCg0K 77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEthdGhsZWVuIE1vcmlhcnR5IDxr YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAyNiBTZXB0 ZW1iZXIgMjAxOSBhdCAxNTo1MA0KVG86ICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4N CkNjOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sICJUTFNAaWV0 Zi5vcmciIDxUTFNAaWV0Zi5vcmc+LCAic2FhZ0BpZXRmLm9yZyIgPHNhYWdAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1RMU10gTGVzc29ucyBsZWFybmVkIGZyb20gVExTIDEuMCBhbmQgVExTIDEu MSBkZXByZWNhdGlvbg0KDQogICAgDQogICAgDQogICAgU2VudCBmcm9tIG15IG1vYmlsZSBkZXZp Y2UNCiAgICANCiAgICA+IE9uIFNlcCAyNiwgMjAxOSwgYXQgOTowMiBBTSwgU2FseiwgUmljaCA8 cnNhbHpAYWthbWFpLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IFRoZXNlIGFyZSBleGNlbGxl bnQgcG9pbnRzLiAgUGVyaGFwcyB0aGV5IGNhbiBiZSBzcXVlZXplZCBpbnRvIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0 ZS8gID8gIEl0J3MgYmVlbiB3YWl0aW5nIDkwIGRheXMsIGEgYnJpZWYgcmVzZXQgbWlnaHQgbm90 IGh1cnQgOikNCiAgICA+IA0KICAgIFRoaXMgd291bGQgbm90IGJlIGEgYnJpZWYgcmVzZXQgYW5k IEnigJlkIHByZWZlciBub3QgdG8gc2VlIHRoZW0gY29tYmluZWQgaW50byB0aGUgZXhpc3Rpbmcg ZHJhZnQgd2l0aCBXRyBhZ3JlZW1lbnQuDQogICAgDQogICAgV2l0aCBSRkM3NTI1LCBUTFN2MS4y IGNhbiBiZSBjb25maWd1cmVkIHRvIGJlIHNlY3VyZS4gIEkgc2VlIHRoZSBwb2ludHMgbWFkZSwg YnV0IGRvbuKAmXQgc2VlIHRoZSB1cmdlbmN5IGFzIG9ic29sZXRlIGlzIGRpZmZlcmVudCBmcm9t IGRlcHJlY2lhdGlvbi4NCiAgICANCiAgICBJIHRoaW5rIGVuY291cmFnaW5nIGltcGxlbWVudGF0 aW9uIG9mIFRMU3YxLjMgaXMgZ29vZCBhbmQgaW1wb3J0YW50LCBidXQgYXJlIHRoZXJlIG90aGVy IHdheXMgYmVzaWRlcyBkZXByZWNhdGlvbj8NCiAgICANCiAgICBOSVNUIGhhcyBwdXNoZWQgYmFj ayB0aGVpciBkYXRlIGZvciBVUyBnb3Zlcm5tZW50IG9yZ2FuaXphdGlvbnMgdG8gaGF2ZSBhIHBs YW4gdG8gc3VwcG9ydCBUTFN2MS4zLCB3aGF04oCZcyB0aGUgZHJpdmVyIHRvIGdldCBhaGVhZCBv ZiB0aGF0Pw0KICAgIA0KICAgIEEgdnVsbmVyYWJpbGl0eSB3b3VsZCBzcGVlZCB0aGluZ3MgdXAs IGJ1dCBJIGRvIGhvcGUgdGhhdCBkb2VzIG5vdCBoYXBwZW4uDQogICAgDQogICAgQmVzdCByZWdh cmRzLA0KICAgIEthdGhsZWVuIA0KICAgIA0KICAgID4gT24gOS8yNi8xOSwgODoxOCBBTSwgIkpv aG4gTWF0dHNzb24iIDxqb2huLm1hdHRzc29uPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3Jn PiB3cm90ZToNCiAgICA+IA0KICAgID4gICAgSGksDQogICAgPiANCiAgICA+ICAgIEhvcGVmdWxs eSwgd2UgaGF2ZSBsZWFybmVkIHNvbWUgbGVzc29ucyBmcm9tIHRoZSBUTFMgMS4wIGFuZCBUTFMg MS4xIGRlcHJlY2F0aW9uLiBUTFMgMS4wIGFuZCBUTFMgMS4xIGFyZSAodG8gY2l0ZSBNYXJ0aW4g VGhvbXNvbikgYnJva2VuIGluIGEgbXlyaWFkIHN1YnRsZSB3YXlzIGFuZCBzaG91bGQgYWNjb3Jk aW5nIHRvIG1lIG9wdGltYWxseSBoYXZlIGJlZW4gZGVwcmVjYXRlZCB5ZWFycyBhZ28uDQogICAg PiANCiAgICA+ICAgIDNHUFAgbWFuZGF0ZWQgc3VwcG9ydCBvZiBUTFMgMS4yIGluIFJlbC0xMyAo MjAxNSkgYnV0IGNvdWxkIGF0IHRoYXQgdGltZSBub3QgZm9yYmlkIHVzZSBvZiBUTFMgMS4xIGFz IHRoYXQgd291bGQgcG90ZW50aWFsbHkgYnJlYWsgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHNvbWUg UmVsLTEyIG5vZGVzICh0aGF0IGhhZCBUTFMgMS4yIGFzIHNob3VsZCBzdXBwb3J0KS4gVGhlIGxl c3NvbiAzR1BQIGxlYXJuZWQgZnJvbSB0aGlzIHdhcyB0aGUgbmVlZCB0byBhcyBlYXJseSBhcyBw b3NzaWJsZSBtYW5kYXRlIHN1cHBvcnQgb2YgbmV3IHByb3RvY29sIHZlcnNpb25zLiBXaXRoIFRM UyAxLjMsIDNHUFAgdG9vayBhY3Rpb24gZWFybHkgYW5kIFRMUyAxLjMgc3VwcG9ydCB3YXMgbWFu ZGF0ZWQgZm9yIG5ldHdvcmsgbm9kZXMgaW4gUmVsLTE1ICgyMDE4KSBhbmQgZm9yIG1vYmlsZSBw aG9uZXMgaW4gUmVsLTE2ICgyMDE5KS4NCiAgICA+IA0KICAgID4gICAgQXQgc29tZSBwb2ludCBp biB0aW1lIHdlIHdpbGwgd2FudCB0byBkZXByZWNhdGUgVExTIDEuMi4gVG8gZW5hYmxlIHRoYXQs IFRMUyAxLjMgc3VwcG9ydCBzaG91bGQgYmUgbWFuZGF0ZWQgb3IgZW5jb3VyYWdlZCBhcyBtdWNo IGFzIHBvc3NpYmxlLiBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgYSBzaXR1YXRpb24gd2hlcmUgd2Ug d2FudCB0byBkZXByZWNhdGUgVExTIDEuMiBidXQgcmVhbGl6ZSB0aGF0IGl0IGNhbm5vdCBiZSBk b25lIGJlY2F1c2Ugc29tZSBpbXBsZW1lbnRhdGlvbnMgb25seSBzdXBwb3J0IFRMUyAxLjIuIEhv dyBjYW4gSUVURiBlbmFibGUgc21vb3RoZXIgYW5kIGZhc3RlciBkZXByZWNhdGlvbnMgaW4gdGhl IGZ1dHVyZT8gVGhlIGJyb3dzZXIgaW5kdXN0cnkgaGFzIGEgZGVjZW50IHRyYWNrIHJlY29yZCBv ZiBhbGdvcml0aG0gZGVwcmVjYXRpb24gYW5kIEkgaG9wZSB0byBzb29uIHNlZSB0aGUgZm9sbG93 aW5nIHdhcm5pbmcgaW4gbXkgYnJvd3NlcjoNCiAgICA+IA0KICAgID4gICAg4oCcVExTIDEuMiBp cyBvYnNvbGV0ZS4gRW5hYmxlIFRMUyAxLjMgb3IgbGF0ZXIu4oCdDQogICAgPiANCiAgICA+ICAg IE90aGVyIGluZHVzdHJpZXMgaGF2ZSBsZXNzIHN0ZWxsYXIgdHJhY2sgcmVjb3JkcyBvZiBhbGdv cml0aG0gZGVwcmVjYXRpb24uDQogICAgPiANCiAgICA+ICAgIEhvdyBjYW4gSUVURiBiZSBtb3Jl IHByby1hY3RpdmUgcmVnYXJkaW5nIGRlcHJlY2F0aW9ucyBpbiB0aGUgZnV0dXJlPyBJbiB0aGUg YmVzdCBvZiB3b3Jkcywgbm9ib2R5IHNob3VsZCBiZSBzdXJwcmlzZWQgd2hlbiBJRVRGIGRlcHJl Y2F0ZXMgYSBwcm90b2NvbCB2ZXJzaW9uIG9yIGFsZ29yaXRobS4gTklTVCBhbmQgc2ltaWxhciBv cmdhbml6YXRpb25zIGluIG90aGVyIGNvdW50cmllcyBoYXZlIHRoZSBwcmFjdGljZSB0byBsb25n IHRpbWUgaW4gYWR2YW5jZSBwdWJsaXNoIGRlYWRsaW5lcyBmb3Igc2VjdXJpdHkgbGV2ZWxzLCBh bGdvcml0aG1zLCBhbmQgcHJvdG9jb2wgdmVyc2lvbnMuIENhbiB0aGUgSUVURiBkbyBzb21ldGhp bmcgc2ltaWxhciwgbm90IGp1c3QgZm9yIFRMUyBidXQgaW4gZ2VuZXJhbD8gRm9yIFRMUywgdGhl cmUgYXJlIHNldmVyYWwgdGhpbmdzIHRvIGRlcHJlY2F0ZSwgaW4gYWRkaXRpb24gdG8gTUQ1IGFu ZCBTSEEtMSwgYWxzbyBQS0NTMS12MV81LCBSU0EtMjA0OCwgMjI0LWJpdCBFQ0MsIGZmZGhlMjA0 OCwgYW5kIG5vbi1yZWNvbW1lbmRlZCBjaXBoZXIgc3VpdGVzIChTdGF0aWMgUlNBLCBDQkMsIERI LCBOVUxMLCBldGMuKSBzaG91bGQgYmUgZGVwcmVjYXRlZCBpbiB0aGUgZnV0dXJlLg0KICAgID4g DQogICAgPiAgICBDaGVlcnMsDQogICAgPiAgICBKb2huDQogICAgPiANCiAgICA+ICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICBUTFMg bWFpbGluZyBsaXN0DQogICAgPiAgICBUTFNAaWV0Zi5vcmcNCiAgICA+ICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAgPiANCiAgICA+IA0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IFRMUyBt YWlsaW5nIGxpc3QNCiAgICA+IFRMU0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90bHMNCiAgICANCg0K From nobody Tue Oct 1 04:03:08 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C1212013B; Tue, 1 Oct 2019 04:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE_QP9Yp6C1W; Tue, 1 Oct 2019 04:03:03 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 06BFB120071; Tue, 1 Oct 2019 04:03:03 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id o44so11128246ota.10; Tue, 01 Oct 2019 04:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tt5JSGL8IoLk8TkPLnWeY0SHhz4cm0yCRXCE8210c30=; b=PWZg1vBcVTtLrpy8mRVcPJ0wFYyh4u5ErWdMIzcexiUp7uShc6tvcpiWUPinMqde08 ZVeNz9cweOgWSWKy+FTkPJbOtF+qgMw823+JLZvFWFhurgLG8Q8oJOQAujb5lkF1J7uo LYESAmKh2OArkJ33ExmeSng0aF5dd0sob/LhdL5p/mtJzsLiOnIUcZ+J7Aiok/sgYu5/ 2uEWp3Ve9c2sXG+4qSbdMnFSKKAzOT9TfFgT5RLZCdc1L8+3PeVjEpILAnhsV4hpta4P Bz33kJgYccEeNycs2MZerVYmTjALzlli4A3Y4/9xO12Xj8NM5ZqKF/t0wjW5seqM+Zc6 YdfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tt5JSGL8IoLk8TkPLnWeY0SHhz4cm0yCRXCE8210c30=; b=K7LoKiILE9tFqPppStjwYvwT9C1Is7L7Kqy+gWrp7mDP7LN7kSskJOMBzXMvhHMEAT xuMC1iWpezKKtePX7Npok+Qw1AUxc6SFe0us90C0llmWi4iWlf5LlnIWCf3UDh4AnnQb N8hAIEBwii7jmChrIL3iL2xdohxDea4eOCQRtLvjuy2MWocdps7rcwb61qBk0bD1ZhgP RoeHjk4GCiwJHCg+BWKcuTSnS7jJLcbEEPJm0IS7oaijp8iXvo2fdcZdSztFZdl/Xt3h BxMGp+wdFNzSJdjvS5CpQKOYgRsHW1wYb1UGsgz4voXfL2V361MwIDIKc5IySWoavhkr NMYg== X-Gm-Message-State: APjAAAWm7u7wmGjvEGbnCzK6etMB55u6t6bOqI+7ZecN6ziKPEWvOFGz eqe71JTwcwVZ9lwtNGkYEoNc7B8OPBnfayh3ye0= X-Google-Smtp-Source: APXvYqyy5tCxVGK5N5CMxtQ3yPu3t2Lw1B9u8tg21b7pz+0/26vzCwGCIld18MlXUlXvU/YOXemixvOshGcoZRPXCng= X-Received: by 2002:a9d:6642:: with SMTP id q2mr15957115otm.250.1569927782332; Tue, 01 Oct 2019 04:03:02 -0700 (PDT) MIME-Version: 1.0 References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> In-Reply-To: From: Kathleen Moriarty Date: Tue, 1 Oct 2019 07:02:26 -0400 Message-ID: To: John Mattsson Cc: "Salz, Rich" , "TLS@ietf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9fe540593d74bb1" Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 11:03:07 -0000 --000000000000c9fe540593d74bb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2019 at 3:58 AM John Mattsson wrote: > Kathleen Moriarty wrote: > > >NIST has pushed back their date for US government organizations to have = a > plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of that? > > NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I > think that is a good and ambitious plan. In fact it would be very good if > IETF agreed on the same requirement. > Right, so they are not saying TLSv1.2 can't be used at that time, only that TLSv1.3 must be supported. "It requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and requires support for TLS 1.3 by January 1, 2024. " This is a good goal and fairly reasonable given that a number of customers are asking for TLSv1.3. Government customers will drive this further in the US. > > > I think encouraging implementation of TLSv1.3 is good and important, bu= t > are there other ways besides deprecation? > > Yes, I think there is at least two things IETF can do: > > - The first thing is to do like NIST and already now give implementors a > date when support for TLS 1.3 is required. > We've never done that as far as I know? SHould we? Or should this be left to documents like NIST's and other regulatory requirements that drive customer purchasing decisions? > > - The second thing is to do like 3GPP and mandate support for TLS 1.3 in > new implementations and deployments. > The second is typical from the point of publication. So back when I was an AD, we were already looking for TLS mentions in drafts and once TLSv1.3 was published, is when you switch from the prior version being required to support for TLSv1.3 being required. I'm guessing this continued (especially with Eric as an AD for another year after I stepped down), but I am not watching closely. > This would avoid two thing that happened in the past. First, IETF > published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 > almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 > months after publishing a draft relying on DTLS 1.0, IETF started working > on a draft forbidding it=E2=80=99s use. > Unfortunately, things like that do happen, but shouldn't. In some instances, an explanation is made as to why an older version is required and it's an exception. Was that the case? (Sorry I don't have the time to research the old discusses and history of the RFC at the moment). It's not the right thing, but with TLS versions, they usually stick out a bit when you read a draft and it's an easy thing to catch if you're skimming a draft as an AD with 400 pages of reading to get through for a telechat. Bets regards, Kathleen > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: Kathleen Moriarty > Date: Thursday, 26 September 2019 at 15:50 > To: "Salz, Rich" > Cc: John Mattsson , "TLS@ietf.org" < > TLS@ietf.org>, "saag@ietf.org" > Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation > > > > Sent from my mobile device > > > On Sep 26, 2019, at 9:02 AM, Salz, Rich wrote: > > > > These are excellent points. Perhaps they can be squeezed into > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > ? It's been waiting 90 days, a brief reset might not hurt :) > > > This would not be a brief reset and I=E2=80=99d prefer not to see the= m > combined into the existing draft with WG agreement. > > With RFC7525, TLSv1.2 can be configured to be secure. I see the > points made, but don=E2=80=99t see the urgency as obsolete is different f= rom > depreciation. > > I think encouraging implementation of TLSv1.3 is good and important, > but are there other ways besides deprecation? > > NIST has pushed back their date for US government organizations to > have a plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of= that? > > A vulnerability would speed things up, but I do hope that does not > happen. > > Best regards, > Kathleen > > > On 9/26/19, 8:18 AM, "John Mattsson" 40ericsson.com@dmarc.ietf.org> wrote: > > > > Hi, > > > > Hopefully, we have learned some lessons from the TLS 1.0 and TLS > 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken = in > a myriad subtle ways and should according to me optimally have been > deprecated years ago. > > > > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at > that time not forbid use of TLS 1.1 as that would potentially break > interoperability with some Rel-12 nodes (that had TLS 1.2 as should > support). The lesson 3GPP learned from this was the need to as early as > possible mandate support of new protocol versions. With TLS 1.3, 3GPP too= k > action early and TLS 1.3 support was mandated for network nodes in Rel-15 > (2018) and for mobile phones in Rel-16 (2019). > > > > At some point in time we will want to deprecate TLS 1.2. To > enable that, TLS 1.3 support should be mandated or encouraged as much as > possible. I would like to avoid a situation where we want to deprecate TL= S > 1.2 but realize that it cannot be done because some implementations only > support TLS 1.2. How can IETF enable smoother and faster deprecations in > the future? The browser industry has a decent track record of algorithm > deprecation and I hope to soon see the following warning in my browser: > > > > =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D > > > > Other industries have less stellar track records of algorithm > deprecation. > > > > How can IETF be more pro-active regarding deprecations in the > future? In the best of words, nobody should be surprised when IETF > deprecates a protocol version or algorithm. NIST and similar organization= s > in other countries have the practice to long time in advance publish > deadlines for security levels, algorithms, and protocol versions. Can the > IETF do something similar, not just for TLS but in general? For TLS, ther= e > are several things to deprecate, in addition to MD5 and SHA-1, also > PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher > suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the futu= re. > > > > Cheers, > > John > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --=20 Best regards, Kathleen --000000000000c9fe540593d74bb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 1, 2019 at 3:58 AM John M= attsson <john.mattsson@eri= csson.com> wrote:
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:=

>NIST has pushed back their date for US government organizations to have= a plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of that?=

NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I thi= nk that is a good and ambitious plan. In fact it would be very good if IETF= agreed on the same requirement.

Right,= so they are not saying TLSv1.2 can't be used at that time, only that T= LSv1.3 must be supported.=C2=A0=C2=A0

"I= t requires that TLS 1.2 configured with FIPS-based cipher suites be support= ed by all government TLS servers and clients and requires support for TLS 1= .3 by January 1, 2024.=C2=A0"

<= div>This is a good goal and fairly reasonable given that a number of custom= ers are asking for TLSv1.3.=C2=A0 Government customers will drive this furt= her in the US.
=C2=A0

> I think encouraging implementation of TLSv1.3 is good and important, b= ut are there other ways besides deprecation?

Yes, I think there is at least two things IETF can do:

- The first thing is to do like NIST and already now give implementors a da= te when support for TLS 1.3 is required.

We've never done that as far as I know?=C2=A0 SHould we?=C2=A0 Or sho= uld this be left to documents like NIST's and other regulatory requirem= ents that drive customer purchasing decisions?
=C2=A0

- The second thing is to do like 3GPP and mandate support for TLS 1.3 in ne= w implementations and deployments.

The = second is typical from the point of publication.=C2=A0 So back when I was a= n AD, we were already looking for TLS mentions in drafts and once TLSv1.3 w= as published, is when you switch from the prior version being required to s= upport for TLSv1.3 being required.=C2=A0 I'm guessing this continued (e= specially with Eric as an AD for another year after I stepped down), but I = am not watching closely.=C2=A0


This would avoid two thing that happened in the past. First, IETF published= RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 almost 6 year= s after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 months after publ= ishing a draft relying on DTLS 1.0, IETF started working on a draft forbidd= ing it=E2=80=99s use.

Unfortunately, th= ings like that do happen, but shouldn't.=C2=A0 In some instances, an ex= planation is made as to why an older version is required and it's an ex= ception.=C2=A0 Was that the case?=C2=A0 (Sorry I don't have the time to= research the old discusses and history of the RFC at the moment).=C2=A0

It's not the right thing, but with TLS versions,= they usually stick out a bit when you read a draft and it's an easy th= ing to catch if you're skimming a draft as an AD with 400 pages of read= ing to get through for a telechat.

Bets regards,
Kathleen


Cheers,
John

=EF=BB=BF-----Original Message-----
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thursday, 26 September 2019 at 15:50
To: "Salz, Rich" <rsalz@akamai.com>
Cc: John Mattsson <john.mattsson@ericsson.com>, "TLS@ietf.org" <TLS@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation



=C2=A0 =C2=A0 Sent from my mobile device

=C2=A0 =C2=A0 > On Sep 26, 2019, at 9:02 AM, Salz, Rich <rsalz@akamai.com> wrote: =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > These are excellent points.=C2=A0 Perhaps they can be sq= ueezed into https://datatracke= r.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/=C2=A0 ?=C2=A0 It&#= 39;s been waiting 90 days, a brief reset might not hurt :)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 This would not be a brief reset and I=E2=80=99d prefer not to= see them combined into the existing draft with WG agreement.

=C2=A0 =C2=A0 With RFC7525, TLSv1.2 can be configured to be secure.=C2=A0 I= see the points made, but don=E2=80=99t see the urgency as obsolete is diff= erent from depreciation.

=C2=A0 =C2=A0 I think encouraging implementation of TLSv1.3 is good and imp= ortant, but are there other ways besides deprecation?

=C2=A0 =C2=A0 NIST has pushed back their date for US government organizatio= ns to have a plan to support TLSv1.3, what=E2=80=99s the driver to get ahea= d of that?

=C2=A0 =C2=A0 A vulnerability would speed things up, but I do hope that doe= s not happen.

=C2=A0 =C2=A0 Best regards,
=C2=A0 =C2=A0 Kathleen

=C2=A0 =C2=A0 > On 9/26/19, 8:18 AM, "John Mattsson" <john.= mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Hi,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Hopefully, we have learned some lessons fro= m the TLS 1.0 and TLS 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Mar= tin Thomson) broken in a myriad subtle ways and should according to me opti= mally have been deprecated years ago.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 3GPP mandated support of TLS 1.2 in Rel-13 = (2015) but could at that time not forbid use of TLS 1.1 as that would poten= tially break interoperability with some Rel-12 nodes (that had TLS 1.2 as s= hould support). The lesson 3GPP learned from this was the need to as early = as possible mandate support of new protocol versions. With TLS 1.3, 3GPP to= ok action early and TLS 1.3 support was mandated for network nodes in Rel-1= 5 (2018) and for mobile phones in Rel-16 (2019).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 At some point in time we will want to depre= cate TLS 1.2. To enable that, TLS 1.3 support should be mandated or encoura= ged as much as possible. I would like to avoid a situation where we want to= deprecate TLS 1.2 but realize that it cannot be done because some implemen= tations only support TLS 1.2. How can IETF enable smoother and faster depre= cations in the future? The browser industry has a decent track record of al= gorithm deprecation and I hope to soon see the following warning in my brow= ser:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.= 3 or later.=E2=80=9D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Other industries have less stellar track re= cords of algorithm deprecation.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 How can IETF be more pro-active regarding d= eprecations in the future? In the best of words, nobody should be surprised= when IETF deprecates a protocol version or algorithm. NIST and similar org= anizations in other countries have the practice to long time in advance pub= lish deadlines for security levels, algorithms, and protocol versions. Can = the IETF do something similar, not just for TLS but in general? For TLS, th= ere are several things to deprecate, in addition to MD5 and SHA-1, also PKC= S1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suite= s (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the future.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 John
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 ___________________________________________= ____
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 TLS@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 https://www.ietf.org/mailma= n/listinfo/tls
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > TLS mailing list
=C2=A0 =C2=A0 > TLS@ie= tf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/tl= s




--

Best regards,
Kathleen
--000000000000c9fe540593d74bb1-- From nobody Tue Oct 1 06:38:07 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9031200CE; Tue, 1 Oct 2019 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 HiKBuu4NXKeP; Tue, 1 Oct 2019 06:37:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 37E87120024; Tue, 1 Oct 2019 06:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569937065; bh=5hPbXsq/aYiq0TmayXlY/PFDCT8a/arWi74oPfr0YhU=; h=X-UI-Sender-Class:From:To:References:In-Reply-To:Subject:Date; b=j9pQ2UTDzNK9AQ+hZMiLqbd+WirvwsQdREZqc2de9/cTsX49Hq5jFQIsMDZ9Xe1Hp gZ/Ilv7y9PfoaUxf2kCxPsHJeFzkvJ6Gb9GjL+zem+MZIn3oeg4cBOSPODa3E2HKZo kUrm6k0me9FX1wHHerh05gx6X5so64JOqAqowN6k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from E108678 ([80.92.116.217]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1po0-1iHVGj38X2-002If7; Tue, 01 Oct 2019 15:37:45 +0200 From: To: "'John Mattsson'" , , References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> In-Reply-To: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> Date: Tue, 1 Oct 2019 15:37:05 +0200 Message-ID: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDADKbUP4/3gAM9SAzHCUgPUKIoKalwn67A Content-Language: de X-CheckRecipientChecked: true x-ts-tracking-id: 71b26417-e9f7-43f0-aea7-971ab7e956ae.1 X-Provags-ID: V03:K1:YXavmIPscQmXVHU8cmwy3sUoUbpf9/cFySyAMVFVFBnjxboMUIx SkSPV0IxG37EEUz0GVDmyj7ah4V56XgFSeN+/++jU5sqHMubYvLpqhYIiG09KYav+cH6hXf wSVkwkhsT2qVDxRnophyyU1l4s3zEHbkYEJTX0qUAueYua08E4k2PDQfBMZ3zZaCVxAT5R9 /+kbpeV4juqZYTFdPHc+A== X-UI-Out-Filterresults: notjunk:1;V03:K0:y1H40qmI3A0=:EqIKCepVNvv6OzOnSGE+mA FGJajWba3bm8CH05fDlQhY5W7KSG+50tDiFnUvgkTWOqYku5U9wU2ha/VV/fMk+Sc4CnpT9vz 4bJamvify3N6/CDmly2eBMlr8mB+5vDvBh9fQjtsoEXd4tQjHR8z+/7/AXofxwxEdN3KknAkP qnI0JncnXb2EH3tsh6pLDMUBCFZGhovl5QAoYn5RyT4AaWgpAfAifEmiIzW/MQo1heox3+9fj fT5lZb4xru2E3rxdrlxCOZ8c3lKjB2V+p/RGZclasBjQJcd24wybiMSTRk2sxUiaadrBJLdqz hQIfiNJybO7NJnq+rH+YWeE7z1eMLgKjDBnLei3BmG4wC3Opajttz+IXV9thH1QKlzXHmZVnP wRIf8g+rkmojoed1E7i3Bmd3Qf/EgbVqq2gm1v6DvSunZ0XfFccVErAKU7G8S9BMD/v0Y2bQv LtAC2bzQ4S+F6EzAvufQ2wJk9j6mh7he459HXhQaAhbxtDvwI2MkfiboqqpknoodOLZBBPISb cCCvVi/bv+1ZONk3uUuSvfN8fYusQYIkX4yaEC3kCtAIPwPhyM8cJEmYs9t6hAf6zQvUdFcp5 rty11QNNQQ/I9WOVgURoN/6KA9gS1vVXWiu3nWb/c8euNZ2vNdb3JrbRhZ6hYU/scaR9dfbOs FTgERN3i+kNcTxqjL5vrc4CHHswfF6j0u6e7skA0pJjgi2dqPbKWGGWHUZbXxrFsMOsq66tp3 DETn0wNvJBG7YSkMchmlhN8SKQCSiWGEs9M3rNWGQr1Y2Gh4SRDf3ZYfyLqHZnxN4MDe6IoAH 3GIvi4+1Ft3Fal4NrRHnSLVGuaLjAYg7gCL31F/hd8mc15vxvs7ng8lGANUeWOkW9VhwTcyc2 eUcr0NBEZrVjyXhMTNXK0aNsBMY7Q6T1TJp70rUkcCVAECqu0mvKF5zxhvBJbzHoaBOv2icgz 8T3PibTW2sCyI3H6EfORrHA2L5gAACY/Uqdk33K6xfSCnf834JW0qRapgi4tuCDQE+hPiFlZp WjaJLROix/ShNVr9UdUYSJKLPPmPWeQW7fkoGQSvAnkGcY2O38fprvyjixsLN6H6qiKQOpjyJ z0ErSg5u73pubICmbBEOi4nqzzSX4nPiIbCtxpEYDds09T9cyRrSJtPAMBeUvrHrL0+kNcHsd 1uiF9quTIZgzbv2qKB1jBhQeQmxQDbKA4FmuFkfuexdgDpaBm274Y5kSY4iMnU8rFzLv64fj7 2XZ1Fsc08wu3s2ieyMBXrfc7GGqhTLFpbdGS83ee5IFAmrI0A23tXvV9Y7sM= Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 13:37:59 -0000 IMHO the problem with deprecation is not in the IETF but rather with the = deployments.=20 Ciao Hannes PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you = follow RFC 7925/7525. -----Original Message----- From: TLS On Behalf Of John Mattsson Sent: Donnerstag, 26. September 2019 14:18 To: TLS@ietf.org; saag@ietf.org Subject: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Hi, Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 = deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in = a myriad subtle ways and should according to me optimally have been = deprecated years ago. 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time = not forbid use of TLS 1.1 as that would potentially break = interoperability with some Rel-12 nodes (that had TLS 1.2 as should = support). The lesson 3GPP learned from this was the need to as early as = possible mandate support of new protocol versions. With TLS 1.3, 3GPP = took action early and TLS 1.3 support was mandated for network nodes in = Rel-15 (2018) and for mobile phones in Rel-16 (2019). At some point in time we will want to deprecate TLS 1.2. To enable that, = TLS 1.3 support should be mandated or encouraged as much as possible. I = would like to avoid a situation where we want to deprecate TLS 1.2 but = realize that it cannot be done because some implementations only support = TLS 1.2. How can IETF enable smoother and faster deprecations in the = future? The browser industry has a decent track record of algorithm = deprecation and I hope to soon see the following warning in my browser: =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D Other industries have less stellar track records of algorithm = deprecation. How can IETF be more pro-active regarding deprecations in the future? In = the best of words, nobody should be surprised when IETF deprecates a = protocol version or algorithm. NIST and similar organizations in other = countries have the practice to long time in advance publish deadlines = for security levels, algorithms, and protocol versions. Can the IETF do = something similar, not just for TLS but in general? For TLS, there are = several things to deprecate, in addition to MD5 and SHA-1, also = PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher = suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the = future. Cheers, John _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 1 10:20:00 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00DF120971; Tue, 1 Oct 2019 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 p43tQAVDzWXs; Tue, 1 Oct 2019 10:19:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119251209C1; Tue, 1 Oct 2019 10:19:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E9733897A; Tue, 1 Oct 2019 13:17:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AFDF5D9A; Tue, 1 Oct 2019 13:19:37 -0400 (EDT) From: Michael Richardson To: "TLS\@ietf.org" , "saag\@ietf.org" In-Reply-To: References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 17:19:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Mattsson wrote: >> NIST has pushed back their date for US government organizations to >> have a plan to support TLSv1.3, what=E2=80=99s the driver to get ahe= ad of that? > NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024.= I > think that is a good and ambitious plan. In fact it would be very good > if IETF agreed on the same requirement. I guess this is on outward facing web sites. Does it say which cipher suites are required, and certificate chains are re= quired? (TLS 1.3 with RSA-1024+SHA1 certificates would be dumb) Does it say that *only* TLS 1.3 is to be supported? Does it say anything about outgoing connections supporting APIs and the lik= e? > Yes, I think there is at least two things IETF can do: > - The first thing is to do like NIST and already now give implementors > a date when support for TLS 1.3 is required. But, it's so incredibly context sensitive. > - The second thing is to do like 3GPP and mandate support for TLS 1.3 > in new implementations and deployments. But, the IETF doesn't really write requirements like this. > This would avoid two thing that happened in the past. First, IETF > published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 > almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 > months after publishing a draft relying on DTLS 1.0, IETF started > working on a draft forbidding it=E2=80=99s use. Deprecating it from new work is not the same as removing it from implementations. My question above about *only* has to do with the knock-on effect. Entity XYZ keeps 1.2 (or 1.1) available because API FOO is used by entity BAR, which can not upgrade to 1.3 today. Entity BAR never experiences pain, never upgrades, and nobody is sure when/if they can turn off 1.2. This is a bit of a variation of the "Postel principal is bad" situation. One thing that entities like NIST could require is that compliant organizations report, in the years leading up to 2024, and after, to log and report the proportion of TLS version that connect. How can the IETF help? *An IETF standard for logging TLS connection parameters would help here* =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2TiqkACgkQgItw+93Q 3WWP4wf/add7tJC9mJUF5IxUZ8GKwlHVejuVSFyFlpwfWvKm4dTWRUiqUwRu5bD3 QP6LGJrkD5i8njt2sykwX/frcSDrg3iInTWXVkAAdmzJ/vyCPixcoB6exiqx5Pxn nr4QsYirWhtV49pFygiNwToD5NE3OHi//oiCgspAMFCqeQ4bq41v2ONzMvzwXm2F xsoOajuBzWekR9TP7AtCHR9Z2vE0uxeQwBwi4VYgGoBPLuTax8F2g1LHfArKsDV1 /dWlMKoCCilslGBqNPtfWpzkkOZGHYBri2V1pvaNME+y6vv54dtnuOy9bUq2BFD+ eXRe7boOu3H/cTsq7tkWx7RMmHEF+Q== =JR/G -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 1 15:21:04 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8325C12021C; Tue, 1 Oct 2019 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=auckland.ac.nz 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 YA-FvH7H1CrQ; Tue, 1 Oct 2019 15:21:01 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 D520312012C; Tue, 1 Oct 2019 15:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569968461; x=1601504461; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OBwXXTvFGdujNPdEQQhTJo25/wKKhMEDSWkVB9evi8s=; b=AFp1IJYVwNcN9pdLK4fwXzonyldl1xEE4j2sQsQjYFIRM426ChW5RKtm elX7QkhYNcjvAPS6JcMlubludolHAUEmBF8eBDrj8SgeVcmqoR7HHChQ8 nfQJZnaXfCK0HAlPNMwwZdvwQZgvm8kQ8SVElC6ge7O8eDJqcKqKfHqku pKKmA81/qU+E4u7D2rTFsYtXbAGQfCDYTL7LOf2VKqr6LZaEehGXKxUlJ VgK4hyhcPxJBVqWjOtwiU65wKK7qnKwCa8WBEGSUc8qegtbXqJBWSJyEd cOFhKN9w/ywLDoV1/JleAbT7fKXBJUCn38axRwavj5L6A+rKhR5vl+EtE Q==; X-IronPort-AV: E=Sophos;i="5.64,572,1559476800"; d="scan'208";a="90133194" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Oct 2019 11:20:59 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 2 Oct 2019 11:20:58 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 2 Oct 2019 11:20:58 +1300 From: Peter Gutmann To: "hannes.tschofenig@gmx.net" , 'John Mattsson' , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGRuT2dEqLFcbEmEm2g+1AcjWadE9+mAgAFsGw8= Date: Tue, 1 Oct 2019 22:20:57 +0000 Message-ID: <1569968457142.91354@cs.auckland.ac.nz> References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com>, <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> In-Reply-To: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 22:21:03 -0000 hannes.tschofenig@gmx.net writes:=0A= =0A= >IMHO the problem with deprecation is not in the IETF but rather with the d= eployments.=0A= >=0A= >PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follo= w=0A= >RFC 7925/7525.=0A= =0A= Maybe the text could be updated to have one section of text for the web and= =0A= one for everything else, since they're totally, totally different=0A= environments. I was at a meeting last week to discuss upgrade mechanisms f= or=0A= some globally deployed infrastructure and they were looking at a 2-3 year t= ime=0A= window to start the upgrade process, with completion by 2030 at the latest.= =0A= =0A= That's not a typo for 2020, it's 2030.=0A= =0A= So the text needs to acknowledge the two different operating environments, = the=0A= web where you can replace anything you want at a drop of a hat, and the res= t=0A= of the world where it takes serious effort to make the change. Moving from= =0A= TLS 1.0 to TLS 1.2 with EMS/EtM/LTS within ten years, for the non-web world= ,=0A= is a practical goal. Moving to an entirely new protocol in that time frame= =0A= (TLS 1.3) probably isn't going to happen.=0A= =0A= Peter.=0A= From nobody Thu Oct 3 08:48:12 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C643E120850 for ; Thu, 3 Oct 2019 08:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 G7O6YcFT558e for ; Thu, 3 Oct 2019 08:48:08 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 3C1E91200B6 for ; Thu, 3 Oct 2019 08:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id A19B362116 for ; Thu, 3 Oct 2019 11:48:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Axnio4UuHhen for ; Thu, 3 Oct 2019 11:48:02 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 6475762124 for ; Thu, 3 Oct 2019 11:48:01 -0400 (EDT) From: Robert Moskowitz To: saag@ietf.org Message-ID: Date: Thu, 3 Oct 2019 11:48:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CDDAC90D38E6F5E929D9C56B" Content-Language: en-US Archived-At: Subject: [saag] Please review/comment on draft-moskowitz-hip-new-crypto-02 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 15:48:10 -0000 This is a multi-part message in MIME format. --------------CDDAC90D38E6F5E929D9C56B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This draft adds support of EdDSA, EC25519/EC448, and Keccak hashes and cipher (Keyak) to HIP (rfc 7401). The interest to this group, is I believe this is the 1st? major adoption of Keccak (FIPS 202, sp800-185, and sp800-56Cr1) in IETF drafts. KMAC vs HMAC is perhaps the simplest change.  It would seem that KMAC (sp800-185) is more efficient than HMAC and might be of advantage to high capacity situations. Then there is the KDF based on sp800-56Cr1 (called KEYMAT in HIP lingo).  This is a significant change from RFC5869 and sp800-108. But I have assurances? that it meets the needed strength requirements. Finally I am perhaps 'jumping the gun' on NIST's lightweight crypto competition with specifying Keyak, but for a constrained device developer, it means one underlying engine to support. TBD is a separate draft to amend RFC7402 to add Keyak to HIP's use of ESP (and include diet-ESP). The only 'hidden' gotcha is EdDSA25519 using SHA512 rather than a cSHAKE256 with 512 bits output (see KEYMAT above).  This has code-size implications to constrained system developers.  Otherwise it is all 'new' crypto. ====================================== A new version of I-D, draft-moskowitz-hip-new-crypto-02.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-hip-new-crypto Revision: 02 Title: New Cryptographic Algorithms for HIP Document date: 2019-10-03 Group: Individual Submission Pages: 12 URL:https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt Status:https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ Htmlized:https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02 Htmlized:https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto Diff:https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02 Abstract: This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------CDDAC90D38E6F5E929D9C56B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit This draft adds support of EdDSA, EC25519/EC448, and Keccak hashes and cipher (Keyak) to HIP (rfc 7401).

The interest to this group, is I believe this is the 1st? major adoption of Keccak (FIPS 202, sp800-185, and sp800-56Cr1) in IETF drafts.

KMAC vs HMAC is perhaps the simplest change.  It would seem that KMAC (sp800-185) is more efficient than HMAC and might be of advantage to high capacity situations.

Then there is the KDF based on sp800-56Cr1 (called KEYMAT in HIP lingo).  This is a significant change from RFC5869 and sp800-108.  But I have assurances? that it meets the needed strength requirements.

Finally I am perhaps 'jumping the gun' on NIST's lightweight crypto competition with specifying Keyak, but for a constrained device developer, it means one underlying engine to support.

TBD is a separate draft to amend RFC7402 to add Keyak to HIP's use of ESP (and include diet-ESP).

The only 'hidden' gotcha is EdDSA25519 using SHA512 rather than a cSHAKE256 with 512 bits output (see KEYMAT above).  This has code-size implications to constrained system developers.  Otherwise it is all 'new' crypto.

======================================

A new version of I-D, draft-moskowitz-hip-new-crypto-02.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-hip-new-crypto
Revision:	02
Title:		New Cryptographic Algorithms for HIP
Document date:	2019-10-03
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto
Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02

Abstract:
   This document provides new cryptographic algorithms to be used with
   HIP.  The Edwards Elliptic Curve and the Keccak sponge functions are
   the main focus.  The HIP parameters and processing instructions
   impacted by these algorithms are defined.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------CDDAC90D38E6F5E929D9C56B-- From nobody Sat Oct 5 03:36:33 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E841200C5; Sat, 5 Oct 2019 03:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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] 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 mN22EvTRpOYi; Sat, 5 Oct 2019 03:36:30 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40047.outbound.protection.outlook.com [40.107.4.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329D0120033; Sat, 5 Oct 2019 03:36:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EeUIUBlAYd/lzKm1bUOCcDgqMB6W/CjDLE0CZPdes43tTm70e2MnRgllXVGR8aAwNpzplS3qOecQkrTTfRMJBFtcXzNVY+KU4DZC+zz+rWxpJIojrmAkj1DE6fCvPRIAUq2DGNF/0qBwel2+E/BcGkH0quh4PFMEr46St+dLpOOLzDbHGZN/1+3iqLCM7igII4HLEE+ysTv5GWPMmvqKpODKQ7UyZ8yOv0JYkdrX5MoDbXMkM7TDNGfE/nPfY3V32YqH2ji0yKZugnQvio/9HO0aopwB/jbnsMBFh4Ol3CDpDdjru0AbkXrJEPerhhYVBrlVCERAcXTOIdrAyAVX1w== 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=VlltzUx0nXak1Cp2vbDBmsRikov4e1Mzj8sjHpI+UEo=; b=gEiiB/QgLhBhEKNLfvZ8empX3sp7QUvK/+hiKGv7Kp0vxFetGnpEUz1g72SsPxYYj83AZ1q9Gmxq0nK7rVivcT4eXhmSLRxlsXiv65VvJdImDQ3WJUe2JEwbjXkFmOJQqkbfXJVYUFRWk5fbkL/oSmnFDZM/lN8q7mF58dD4U1ICeAIB859IKgtRIW+YkJUIn7K3qJdWfZP2jVgQN3zsfn2bxBE701osawIz6hv4Y6tdP4+zZ+6tTV5/4cynQ5kM6DYKXwnrXbLIakHLD9DInY9Sldo1FKJNONRGMgqJQpVCVXjFEVzbxjPzXK7xenzFY4l2xSEanl1FRUd4RJACNA== 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=VlltzUx0nXak1Cp2vbDBmsRikov4e1Mzj8sjHpI+UEo=; b=AfsdKnXfeLwvU0Vk8YRjrOTgUOqlkevHVxw998ibqmCA1cgEsVtcJQQJkrjznW1amfxJ1a+gfOx8JwW2FLhmhEQhua6Cv5QN74X17RGb7RBnmzaxWgrrvqpeh0O5afmJ9dLJ5JZbcynThUNz54AyNb2Bu8KeaSxZsy5GNjOlNWw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3084.eurprd07.prod.outlook.com (10.170.247.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Sat, 5 Oct 2019 10:36:27 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2327.021; Sat, 5 Oct 2019 10:36:27 +0000 From: John Mattsson To: "hannes.tschofenig@gmx.net" , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGRuT2dEqLFcbEmEm2g+1AcjWadF0deAgAY4YQA= Date: Sat, 5 Oct 2019 10:36:27 +0000 Message-ID: <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> In-Reply-To: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c63e079f-2a73-4455-006e-08d7497fe0d2 x-ms-traffictypediagnostic: HE1PR07MB3084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(39860400002)(366004)(346002)(199004)(189003)(8936002)(478600001)(86362001)(186003)(110136005)(36756003)(486006)(2501003)(6246003)(99286004)(14444005)(2906002)(26005)(14454004)(446003)(3846002)(256004)(2616005)(6116002)(71190400001)(71200400001)(2201001)(476003)(25786009)(66066001)(44832011)(6512007)(66946007)(7736002)(76116006)(11346002)(6506007)(66446008)(64756008)(5660300002)(66476007)(66556008)(58126008)(229853002)(91956017)(6436002)(305945005)(4744005)(316002)(8676002)(33656002)(81156014)(81166006)(102836004)(76176011)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3084; H:HE1PR07MB4169.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: SETWXdXmUtYZEk5Qw7a+t89UQvnAvCSJifbvkiqzws/tAC3iJXbLGeIMF1OpF7mQRYjbohVUXzHasXaZ9W6agDnMIYuOTOTAWS/QRa5Fhc/Wk4EddxlzTIpgNRisce6OblS+PfBy85cS08MvmMfFWTasVqH1cjFRKWpKqRO/3r0++yZiZ49Xv5R90mrmMJ3g95sqkrW/cbDnvMYKnczWdfVyLJNJKAzhlkgo6bfOKT3OfEHNGIc50R9IRs3OEPmsmT17POK7/R7PpzvO7YjFwZ14AkJ0migS71W+5URnculbiR1k9JrhBGvEiEs/55Lmu+AQOeGqtHJti2dTfsX/JgvqrM7rmc5hoGwznxvG1qMa1TVIcc9YpQa7jvwvsCS+jaYYc2adV77BS+nX32uz92Vv76scuh4O/xcO2f97hEY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c63e079f-2a73-4455-006e-08d7497fe0d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2019 10:36:27.6108 (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: On2msrtgHpBiLuOzBKGC/8yLknE1Mn4MPPsv2wt38LViu6ovxpyLQgjrnivRTyPIOxbUSTKP5M+SeZfTktqkB+uv25qS+tpWgxJcBqHN2No= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3084 Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2019 10:36:32 -0000 Imhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3 cm90ZToNCg0KPiBQUzogQXMgS2F0aGxlZW4gbm90ZWQgVExTIDEuMiBhbmQgRFRMUyAxLjIgYXJl IHBlcmZlY3RseSBmaW5lIGlmIHlvdSBmb2xsb3cgUkZDIDc5MjUvNzUyNS4NCg0KV2hpbGUgVExT IDEuMiBhbmQgRFRMUyAxLjIgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gYmUgc2VjdXJlLCBSRkMgNzUy NSBpcyBkZWZpbml0ZWx5IG5vdCBlbm91Z2guIFJGQyA3NTQwIHdvdWxkIGJlIGEgZ29vZCBzdGFy dCwgYnV0IGFsc28gdGhhdCB3b3VsZCBuZWVkIHRvIGJlIGV4dGVuZGVkIHdpdGggc3VwcG9ydCBv ZiBleHRlbnNpb25zIGxpa2UgRXh0ZW5kZWQgTWFzdGVyIFNlY3JldCwgU2lnbmF0dXJlIEFsZ29y aXRobXMsIGFuZCBDZXJ0aWZpY2F0ZSBTdGF0dXMgUmVxdWVzdCB0byBiZSBjb25zaWRlcmVkIGZp bmUgaW4gMjAxOS4NCg0KQ2hlZXJzLA0KSm9obg0KDQrvu78NCiANCg0K From nobody Sat Oct 5 04:22:02 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3525E120815 for ; Sat, 5 Oct 2019 04:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 uGCNdm8ElKdv for ; Sat, 5 Oct 2019 04:21:49 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830125.outbound.protection.outlook.com [40.107.83.125]) (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 143BB1202DD for ; Sat, 5 Oct 2019 04:21:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lv2N9wVNFdAAsb1LkziUs1ke+WERoLuU/GQ+7qc86KHCGaeDtI6WbNw9QtV0cMUf8olbFg6NXZ8awlwaUGPO1ve6tOWF4CSk2+gK/Q/Vot6b0pLgzkalECB73/uOmTXGlBMqsU0YtZFI/n+teXt0inRc04zgYD0zg30wj2U/ji6jxEMZ6vS4iELij3/yJaz2z8ZqLIX8yhgo23ssZZcOqDIIlWy5kO8D5iUpbbBC18fZGvkhBrpBUilXYO+E/2U2RjZqLgFJI5k1AqxBoln8HjJ09tM7NZUVAW3c/ZAFhMgtGh9UKY0KcC4bW+CTdqIXBVs6QJLcSC0C4VdwjlSnMA== 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=GuU/FjGRfLO9n1a6xZr+Wm655N02qrN8kVW3Qz3CL0Q=; b=lM7Q3cDJAZPlzivn7XaHMwdIiOFVWP2kA0mwBZrBS/HNlsWXJzEgZJa2HWSheXf7lCU9++lsThCG+56dnOro1G8TyE5S18vthur2vrtNn0pBL9CP3e6mzP9TLhnj/sUiGfph8H3ULVgftjC1/Q5MdRzmOADy3dSVjhzNzplscXFQrs8kr3PXQsrkI5hJXcaRh9hiyc9lAajfOFiL6zhMNH9z4OCjB2tFyETlL8LLT5QHYofQt+pg86dKYSHK35sAl92eYXpcKfBRYOOTTiY7/UwEYuTF8sgDsao1DWTgRMck6gn6uf7rmAM5RUO31TBPivcjOpj0b/HV43MGimy0pw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GuU/FjGRfLO9n1a6xZr+Wm655N02qrN8kVW3Qz3CL0Q=; b=EhXwHZrR+xvYOXHkrdy1CzZzP8Ml+2jpeMvhgqSu/1sxweBL7kV4gygkQEEhOWHM+Ek38SG+HpVeXqyi6fadl+hjRoBynGAKXXT+zCdyTbPrnVxvmT6hH+ejh1cJv7aJNIgT0hAH2CEP8GRoN95N7ZnQi/w0jyuBG9zySMUwbuM= Received: from MW2PR0901MB3785.namprd09.prod.outlook.com (52.132.153.143) by MW2PR0901MB2426.namprd09.prod.outlook.com (52.132.151.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.23; Sat, 5 Oct 2019 11:21:46 +0000 Received: from MW2PR0901MB3785.namprd09.prod.outlook.com ([fe80::541d:424d:f9b6:5dd5]) by MW2PR0901MB3785.namprd09.prod.outlook.com ([fe80::541d:424d:f9b6:5dd5%7]) with mapi id 15.20.2327.023; Sat, 5 Oct 2019 11:21:46 +0000 From: "Dang, Quynh (Fed)" To: John Mattsson , "Mark D. Baushke" , Jim Schaad CC: "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhycMHNjF0f1WkKcU2xOH+ATAKc2abmAgAKtrACAAJaMgIABRZUAgAG2pICAAAjIgIAAGs6AgADSvACADl0Jqg== Date: Sat, 5 Oct 2019 11:21:45 +0000 Message-ID: References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> <1569336830344.45369@cs.auckland.ac.nz> <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> <26766.1569438669@contrail-ubm16-mdb.svec1.juniper.net>, <2558A4D5-B732-4862-9692-A86735A82BD1@ericsson.com> In-Reply-To: <2558A4D5-B732-4862-9692-A86735A82BD1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-originating-ip: [2610:20:6005:219::67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2ad95c01-8d56-4612-93e9-08d74986350c x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: MW2PR0901MB2426: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(366004)(39860400002)(376002)(189003)(199004)(53754006)(13464003)(46003)(6306002)(102836004)(52536014)(105004)(606006)(7696005)(486006)(5660300002)(476003)(76176011)(966005)(6436002)(53546011)(6506007)(6246003)(186003)(45080400002)(54896002)(55016002)(14444005)(99286004)(256004)(11346002)(14454004)(446003)(74316002)(9686003)(19627405001)(229853002)(478600001)(236005)(7736002)(76116006)(4326008)(33656002)(71190400001)(91956017)(110136005)(2906002)(8936002)(6116002)(21615005)(316002)(64756008)(66476007)(66446008)(66556008)(25786009)(81166006)(86362001)(81156014)(8676002)(66946007)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR0901MB2426; H:MW2PR0901MB3785.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kZBJADVA3oUvR/yK9K/sKd0wmFZW33kVowzwWynM/SVHzt2ZnNo5xY2I6jMhoFcSpYYB6ZfmLpXz27MejDGu39w/SEnqOEuDOs2Gihj8Fu45uDEmHmmf2rLFvp7ASVEryW0Ei+YCG447YO67APXGAe4dkQv248NNUin6a+RE++g/39/JS6kSIeB53zCI82Bt6y7F/jJqbysGp2DaUv3q3ZFgA0ZgDrNu7sW2CTADxXASBQUtQAuD6MbQ+Ze/TjP5xc0z8Vj9rslygL26ImOnMRsZGivAv/15kPbg0wZ17xJ3ftDo4XuSvYhqnbcKIjRLJwUIJ+v+cn1Cl+ad3uG2yuxTmrjg9JvADFnB5IGIt7DY7wmooZnudM1AtiP9w5d7WNAXu51naUs/jTYaCNwLPg0wU1fm8oTqwI44bScjzGnKxEB3NjAkW3dV2lYUXA2MZfMb9w7LG44qWmwQzLgV0A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MW2PR0901MB3785D8A402F1C63891DB577CF3990MW2PR0901MB3785_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 2ad95c01-8d56-4612-93e9-08d74986350c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2019 11:21:45.8437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G0ZzJKOpeIOfecRL7jYSNF8y4W33AmLtvw8uvNv8fuUxrpPv8Jukr2aStVzOSq4U X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR0901MB2426 Archived-At: Subject: Re: [saag] Improving the CHAP protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2019 11:22:01 -0000 --_000_MW2PR0901MB3785D8A402F1C63891DB577CF3990MW2PR0901MB3785_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpTSEFLRTEyOC8yNTYgaXMgYWJvdXQgMjUlIGZhc3RlciB0aGFuIFNIQTMtMjU2 LiBUaGV5IGJvdGggaGF2ZSB0aGUgc2FtZSBsZXZlbCBvZiBjb2xsaXNpb24gcmVzaXN0YW5jZSBz dHJlbmd0aDogMTI4IGJpdHMuDQoNCkluIGEgTUFDIG1vZGUgKHN1Y2ggYXMgS01BQyksIFNIQUtF MTI4IGhhcyAyNTYgYml0cyBvZiBzZWN1cml0eSBpZiB0aGUgTUFDIGtleSBoYXMgYXQgbGVhc3Qg MjU2IGJpdHMgb2Ygc2VjdXJpdHkgYW5kIHRoZSB0YWcgKG91dHB1dCBzaXplKSBpcyBhdCBsZWFz dCAyNTYgYml0cywgZm9yIHByYWN0aWNhbCBwdXJwb3Nlcy4NCg0KaHR0cHM6Ly9rZWNjYWsudGVh bS8yMDE3L2lzX3NoYTNfc2xvdy5odG1sIGdpdmVzIHBlcmZvcm1hbmNlIGluZm9ybWF0aW9uIGFi b3V0IFNIQUtFcyAoS2VjY2FrKS4gVGhlIHNpdGUgaGFzIGEgbG90IG9mIG90aGVyIGluZm9ybWF0 aW9uIGFib3V0IEtlY2Nhay4NCg0KU0hBS0UxMjgvMjU2IGlzIG5vdCBhIE5JU1QtYXBwcm92ZWQg aGFzaCBmdW5jdGlvbiBmb3IgZ2VuZXJhbCB1c2VzLiBOSVNUIHdpbGwgZXZhbHVhdGUgZWFjaCB1 c2UgY2FzZSBvZiBTSEFLRTEyOCBhbmQvb3IgU0hBS0UyNTYgd2hlbiByZXF1ZXN0ZWQsIHRoZW4g bWFrZSBhIGRlY2lzaW9uIHdoZXRoZXIgb3Igbm90IHN1Y2ggdXNlIGNhc2UgaXMgYWxsb3dlZC4N Cg0KUmVnYXJkcywNClF1eW5oLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IHNhYWcgPHNhYWctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEpvaG4gTWF0dHNz b24gPGpvaG4ubWF0dHNzb249NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTZW50OiBU aHVyc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE5IDM6NDUgQU0NClRvOiBNYXJrIEQuIEJhdXNoa2Ug PG1kYj00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPjsgSmltIFNjaGFhZCA8aWV0ZkBhdWd1 c3RjZWxsYXJzLmNvbT4NCkNjOiBzYWFnQGlldGYub3JnIDxzYWFnQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtzYWFnXSBJbXByb3ZpbmcgdGhlIENIQVAgcHJvdG9jb2wNCg0KSSB3b3VsZCBhbHNv IHByZWZlciBTSEFLRSBjb21wYXJlZCB0byBTSEEzLTI1Ni4gSSB0aGluayBTSEFLRTEyOCBvZmZl ciBlbm91Z2ggc2VjdXJpdHkgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUsIGJ1dCBqdXN0IFNI QUtFMjU2IG1heSBiZSBiZXR0ZXIgaWYgd2Ugd2FudCBhIHNpbmdsZSBhbGdvcml0aG0gdG8gZnVs ZmlsIDI1Ni1iaXQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZyb20gZS5nLiBnb3Zlcm5tZW50cy4g RG8vd2lsbCBhbnkgY29uc3RyYWluZWQgSW9UIGRldmljZXMgdXNlIENIQVA/IFRoZW4gdGhlaXIg cmVxdWlyZW1lbnRzIHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQuDQoNCi9Kb2huDQoNCu+7 vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYWFnIDxzYWFnLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiAiTWFyayBELiBCYXVzaGtlIiA8bWRiPTQwanVuaXBlci5uZXRA ZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIDI1IFNlcHRlbWJlciAyMDE5IGF0IDIx OjExDQpUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4NCkNjOiAic2FhZ0Bp ZXRmLm9yZyIgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NhYWddIEltcHJvdmluZyB0 aGUgQ0hBUCBwcm90b2NvbA0KDQogICAgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNv bT4gd3JpdGVzOg0KDQogICAgPiBJZiB5b3UgZG8gdGhhdCwgSSBkb24ndCBrbm93IGlmIHlvdSB3 YW50IFNIQTMtMjU2IG9yIFNIQUtFLiBTSEFLRQ0KICAgID4gc2VlbXMgdG8gYmUgdXNlZCBtb3Jl IGZyb20gd2hhdCBJIGhhdmUgc2VlbiBzbyBmYXIuDQoNCiAgICBJIHRoaW5rIFNIQUtFMjU2IGlz IHRoZSBiZXR0ZXIgZW50cnkgaW4gbXkgb3BpbmlvbiBpZiB5b3Ugd2FudCBzb21ldGhpbmcNCiAg ICBmb3IgdGhlIGZ1dHVyZS4NCg0KICAgIEkgYmVsaWV2ZSB5b3Ugd2lsbCBmaW5kIGltcGxlbWVu dGF0aW9ucyBpbiBwb3B1bGFyIGNyeXB0byBsaWJyYXJpZXMNCiAgICAocHJvdmlkZWQgaW4gYWxw aGFiZXRpY2FsIG9yZGVyKSBzdWNoIGFzIEJvdW5jeSBDYXN0bGUsIENyeXB0bysrLA0KICAgIExp YmdjcnlwdCwgYW5kIE9wZW5TU0wuDQoNCiAgICAgICAgIC0tIE1hcmsNCg0KICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2FhZyBtYWlsaW5n IGxpc3QNCiAgICBzYWFnQGlldGYub3JnDQogICAgaHR0cHM6Ly9nY2MwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGc2FhZyZhbXA7ZGF0YT0wMiU3QzAxJTdDcXV5bmguZGFuZyU0MG5p c3QuZ292JTdDOGFjOGVjNzE2M2ZjNGQwZTM4ZDYwOGQ3NDI1NTljY2UlN0MyYWI1ZDgyZmQ4ZmE0 Nzk3YTkzZTA1NDY1NWM2MWRlYyU3QzElN0MxJTdDNjM3MDUwODA3NzgzNzM0NDY1JmFtcDtzZGF0 YT1VWXVwYld1aXVvMlh5c2QlMkJGVFlzTlBqNHNjSzE0QzB2MHZOUEl2U0pybk0lM0QmYW1wO3Jl c2VydmVkPTANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2FhZyBtYWlsaW5nIGxpc3QNCnNhYWdAaWV0Zi5vcmcNCmh0dHBzOi8vZ2NjMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRm Lm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNhYWcmYW1wO2RhdGE9MDIlN0MwMSU3Q3F1eW5o LmRhbmclNDBuaXN0LmdvdiU3QzhhYzhlYzcxNjNmYzRkMGUzOGQ2MDhkNzQyNTU5Y2NlJTdDMmFi NWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMSU3QzYzNzA1MDgwNzc4Mzc0NDQ3 MiZhbXA7c2RhdGE9JTJGdm9ncm4yQm9Ob2pKR1dadGlub01ER2JiSWp2Z0xXRW9PWE4lMkJuQkZM cXclM0QmYW1wO3Jlc2VydmVkPTANCg== --_000_MW2PR0901MB3785D8A402F1C63891DB577CF3990MW2PR0901MB3785_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhpIGFsbCw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEy cHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KU0hBS0UxMjgvMjU2IGlzIGFib3V0IDI1 JSBmYXN0ZXIgdGhhbiBTSEEzLTI1Ni4gVGhleSBib3RoIGhhdmUgdGhlIHNhbWUgbGV2ZWwgb2Yg Y29sbGlzaW9uIHJlc2lzdGFuY2Ugc3RyZW5ndGg6IDEyOCBiaXRzLiZuYnNwOzwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQpJbiBhIE1B QyBtb2RlIChzdWNoIGFzIEtNQUMpLCBTSEFLRTEyOCBoYXMgMjU2IGJpdHMgb2Ygc2VjdXJpdHkg aWYgdGhlIE1BQyBrZXkgaGFzIGF0IGxlYXN0IDI1NiBiaXRzIG9mIHNlY3VyaXR5IGFuZCB0aGUg dGFnIChvdXRwdXQgc2l6ZSkgaXMgYXQgbGVhc3QgMjU2IGJpdHMsIGZvciBwcmFjdGljYWwgcHVy cG9zZXMuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJp YWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAs IDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJp LCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7Ij4NCjxhIGhyZWY9Imh0dHBzOi8va2VjY2FrLnRlYW0vMjAxNy9pc19zaGEz X3Nsb3cuaHRtbCI+aHR0cHM6Ly9rZWNjYWsudGVhbS8yMDE3L2lzX3NoYTNfc2xvdy5odG1sPC9h PiZuYnNwO2dpdmVzIHBlcmZvcm1hbmNlIGluZm9ybWF0aW9uIGFib3V0IFNIQUtFcyAoS2VjY2Fr KS4gVGhlIHNpdGUgaGFzIGEgbG90IG9mIG90aGVyIGluZm9ybWF0aW9uIGFib3V0IEtlY2Nhay4m bmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KU0hBS0UxMjgvMjU2IGlzIG5vdCBhIE5JU1QtYXBwcm92ZWQgaGFzaCBm dW5jdGlvbiBmb3IgZ2VuZXJhbCB1c2VzLiBOSVNUIHdpbGwgZXZhbHVhdGUgZWFjaCB1c2UgY2Fz ZSBvZiBTSEFLRTEyOCBhbmQvb3IgU0hBS0UyNTYgd2hlbiByZXF1ZXN0ZWQsIHRoZW4gbWFrZSBh IGRlY2lzaW9uIHdoZXRoZXIgb3Igbm90IHN1Y2ggdXNlIGNhc2UgaXMgYWxsb3dlZC4mbmJzcDsm bmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAw LCAwKTsiPg0KUmVnYXJkcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJp LCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7Ij4NClF1eW5oLiZuYnNwOzwvZGl2Pg0KPGRpdiBpZD0iYXBwZW5kb25zZW5k Ij48L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7d2lkdGg6OTglIiB0YWJp bmRleD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1zZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9 IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0eWxlPSJmb250LXNpemU6MTFwdCIgY29sb3I9IiMwMDAw MDAiPjxiPkZyb206PC9iPiBzYWFnICZsdDtzYWFnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJl aGFsZiBvZiBKb2huIE1hdHRzc29uICZsdDtqb2huLm1hdHRzc29uPTQwZXJpY3Nzb24uY29tQGRt YXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDI2 LCAyMDE5IDM6NDUgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcmsgRC4gQmF1c2hrZSAmbHQ7bWRiPTQw anVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7OyBKaW0gU2NoYWFkICZsdDtpZXRmQGF1Z3Vz dGNlbGxhcnMuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gc2FhZ0BpZXRmLm9yZyAmbHQ7c2FhZ0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWFnXSBJbXByb3ZpbmcgdGhl IENIQVAgcHJvdG9jb2w8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJCb2R5RnJhZ21lbnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTFwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5JIHdvdWxkIGFsc28gcHJlZmVyIFNIQUtF IGNvbXBhcmVkIHRvIFNIQTMtMjU2LiBJIHRoaW5rIFNIQUtFMTI4IG9mZmVyIGVub3VnaCBzZWN1 cml0eSBmb3IgdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZSwgYnV0IGp1c3QgU0hBS0UyNTYgbWF5IGJl IGJldHRlciBpZiB3ZSB3YW50IGEgc2luZ2xlIGFsZ29yaXRobSB0byBmdWxmaWwgMjU2LWJpdCBz ZWN1cml0eSByZXF1aXJlbWVudHMgZnJvbSBlLmcuIGdvdmVybm1lbnRzLg0KIERvL3dpbGwgYW55 IGNvbnN0cmFpbmVkIElvVCBkZXZpY2VzIHVzZSBDSEFQPyBUaGVuIHRoZWlyIHJlcXVpcmVtZW50 cyBzaG91bGQgYmUgdGFrZW4gaW50byBhY2NvdW50Ljxicj4NCjxicj4NCi9Kb2huPGJyPg0KPGJy Pg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBzYWFnICZsdDtzYWFn LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtNYXJrIEQuIEJhdXNoa2Um cXVvdDsgJmx0O21kYj00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ozxicj4NCkRhdGU6 IFdlZG5lc2RheSwgMjUgU2VwdGVtYmVyIDIwMTkgYXQgMjE6MTE8YnI+DQpUbzogSmltIFNjaGFh ZCAmbHQ7aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSZndDs8YnI+DQpDYzogJnF1b3Q7c2FhZ0BpZXRm Lm9yZyZxdW90OyAmbHQ7c2FhZ0BpZXRmLm9yZyZndDs8YnI+DQpTdWJqZWN0OiBSZTogW3NhYWdd IEltcHJvdmluZyB0aGUgQ0hBUCBwcm90b2NvbDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyBKaW0gU2NoYWFkICZsdDtpZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0OyB3cml0ZXM6PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IElmIHlvdSBk byB0aGF0LCBJIGRvbid0IGtub3cgaWYgeW91IHdhbnQgU0hBMy0yNTYgb3IgU0hBS0UuIFNIQUtF PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgc2VlbXMgdG8gYmUgdXNlZCBtb3JlIGZyb20g d2hhdCBJIGhhdmUgc2VlbiBzbyBmYXIuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyBJIHRoaW5rIFNIQUtFMjU2IGlzIHRoZSBiZXR0ZXIgZW50cnkgaW4g bXkgb3BpbmlvbiBpZiB5b3Ugd2FudCBzb21ldGhpbmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg Zm9yIHRoZSBmdXR1cmUuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyBJIGJlbGlldmUgeW91IHdpbGwgZmluZCBpbXBsZW1lbnRhdGlvbnMgaW4gcG9wdWxh ciBjcnlwdG8gbGlicmFyaWVzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IChwcm92aWRlZCBpbiBh bHBoYWJldGljYWwgb3JkZXIpIHN1Y2ggYXMgQm91bmN5IENhc3RsZSwgQ3J5cHRvJiM0MzsmIzQz Oyw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgTGliZ2NyeXB0LCBhbmQgT3BlblNTTC48YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1hcms8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHNhYWcgbWFpbGluZyBsaXN0PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IHNhYWdAaWV0Zi5vcmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cHM6Ly9nY2MwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2FhZyZh bXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3F1eW5oLmRhbmclNDBuaXN0LmdvdiU3QzhhYzhlYzcxNjNm YzRkMGUzOGQ2MDhkNzQyNTU5Y2NlJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMl N0MxJTdDMSU3QzYzNzA1MDgwNzc4MzczNDQ2NSZhbXA7YW1wO3NkYXRhPVVZdXBiV3VpdW8yWHlz ZCUyQkZUWXNOUGo0c2NLMTRDMHYwdk5QSXZTSnJuTSUzRCZhbXA7YW1wO3Jlc2VydmVkPTAiPg0K aHR0cHM6Ly9nY2MwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc2FhZyZhbXA7YW1w O2RhdGE9MDIlN0MwMSU3Q3F1eW5oLmRhbmclNDBuaXN0LmdvdiU3QzhhYzhlYzcxNjNmYzRkMGUz OGQ2MDhkNzQyNTU5Y2NlJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2NTVjNjFkZWMlN0MxJTdD MSU3QzYzNzA1MDgwNzc4MzczNDQ2NSZhbXA7YW1wO3NkYXRhPVVZdXBiV3VpdW8yWHlzZCUyQkZU WXNOUGo0c2NLMTRDMHYwdk5QSXZTSnJuTSUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8L2E+PGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2FhZyBtYWlsaW5nIGxpc3Q8YnI+DQpzYWFnQGll dGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9nY2MwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGc2FhZyZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3F1eW5oLmRhbmclNDBuaXN0Lmdv diU3QzhhYzhlYzcxNjNmYzRkMGUzOGQ2MDhkNzQyNTU5Y2NlJTdDMmFiNWQ4MmZkOGZhNDc5N2E5 M2UwNTQ2NTVjNjFkZWMlN0MxJTdDMSU3QzYzNzA1MDgwNzc4Mzc0NDQ3MiZhbXA7YW1wO3NkYXRh PSUyRnZvZ3JuMkJvTm9qSkdXWnRpbm9NREdiYklqdmdMV0VvT1hOJTJCbkJGTHF3JTNEJmFtcDth bXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9nY2MwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGc2FhZyZhbXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3F1eW5oLmRhbmclNDBuaXN0LmdvdiU3Qzhh YzhlYzcxNjNmYzRkMGUzOGQ2MDhkNzQyNTU5Y2NlJTdDMmFiNWQ4MmZkOGZhNDc5N2E5M2UwNTQ2 NTVjNjFkZWMlN0MxJTdDMSU3QzYzNzA1MDgwNzc4Mzc0NDQ3MiZhbXA7YW1wO3NkYXRhPSUyRnZv Z3JuMkJvTm9qSkdXWnRpbm9NREdiYklqdmdMV0VvT1hOJTJCbkJGTHF3JTNEJmFtcDthbXA7cmVz ZXJ2ZWQ9MDwvYT48YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_MW2PR0901MB3785D8A402F1C63891DB577CF3990MW2PR0901MB3785_-- From nobody Sun Oct 6 09:12:19 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2A120073 for ; Sun, 6 Oct 2019 09:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 MwoWHO3gF8hd for ; Sun, 6 Oct 2019 09:12:15 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C6CD712004F for ; Sun, 6 Oct 2019 09:12:14 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x96GCAdn013547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 6 Oct 2019 12:12:12 -0400 Date: Sun, 6 Oct 2019 09:12:10 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20191006161144.GV6722@kduck.mit.edu> References: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] Fwd: Last Call: (A Survey of Transport Security Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2019 16:12:17 -0000 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 From nobody Mon Oct 7 16:18:26 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785BB120044 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=unavailable 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 mAwvD2k7Qn25 for ; Mon, 7 Oct 2019 16:18:13 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 280ED120019 for ; Mon, 7 Oct 2019 16:18:13 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id w6so10484238lfl.2 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=GQmwQCRCvbah7jRTXK2GnaelmP4qNEm36MoB9dw+EUPsMCkd5VgmQh1psKQxIrQXSB 4Hv8t5PF6J6lX5aAJjZTHb1HNbh35rF0i8c4fIvy0+J4maRHMB1hvIdUxo9TsaFY/HuZ sgvkowZTa7/dVmJZGcIL70wE/UAwG+KFDtA+pAd6janeO28fW1Iu+5jvoaEqR3LizyCn Kf6vmD4pyNSDk55o/u7T6gVrYGx/kREvdyi2v9MllrDxeAWV7sTEYrIjQFoFendgmYwA cLZQuJ6nLpuqLxIa5E1FPuiq4xzMXMBgxNPt/C2GrX/tqhLPxHylrCrbkE0sHO4appwM 1D3w== X-Gm-Message-State: APjAAAXaVcq1N7+0DgQ/17I5oe0sP1ZA/5pz7ngv1S/YZ3XRQWA4ZcxD Wy7bKd5jjKmIkFQg072/86jFxkt40TepV7+sB0l17Q== 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: [saag] (no subject) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 23:18:17 -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 Tue Oct 8 14:10:56 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC5A12008C; Tue, 8 Oct 2019 14:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=nAqnoU6z; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=chfUA6Gi 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 O8wSTm8sCEnX; Tue, 8 Oct 2019 14:10:45 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 C7438120046; Tue, 8 Oct 2019 14:10:45 -0700 (PDT) Received: from pps.filterd (m0170394.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x98LAW0u002453; Tue, 8 Oct 2019 17:10:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=si7jZ5AA09Af4XKG2wKKODxkBlhXNB988CP5lxnJLpk=; b=nAqnoU6zyJm/aAaYqX5rbmKYNGqfmZpFl/u7BgiWFsjuhYUbdsP8PSYyNmbuHBpVQSul G6klpEHzA6M7Cg55D82rxy8C/Hv6zXnhNZ5VI9LXbRx4v6dJaUt/kRLe+xBCAIYzf+dG 8da7ldsVSliYm74hi3ItKMJl9U7TRqhcsT9o2x8hwz/aQ2y5If+2luEYSCjEED0ABjcm RyE5iAW9KLirI//Y2aPjbIFMnfPSxZnAUZMoMjbtUM+mzooDHFKgku8jZz0oLMjqvFY2 If6jNxKWHZ1P7q9N5Hu3KfMgVOok97vTb/6B44kkXyDIiO+lXU2JC/S2HvDW0RPJHdSi DA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2venr7r2eq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Oct 2019 17:10:44 -0400 Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x98L8QtH175803; Tue, 8 Oct 2019 17:10:44 -0400 Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [168.159.213.141] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2vemep90ce-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 08 Oct 2019 17:10:44 -0400 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x98LAMQD005172 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Oct 2019 17:10:43 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x98LAMQD005172 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1570569043; bh=ydghZdW/trnz7+LTmOdaqS81BGc=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=chfUA6GiWuDXII9riNlqmXcXJjgL8mRckQWtBRYUrYaO687Y09mruFJXpwkgSgnlj tfXEbSodtuNj5timcPBHzkiOU3Mn1jkMWc0kBFquTcH6Qm8GqoZdU8iXJqhhezr7mb u4PzsrwbBNor/oWyoE7LEeJvfV/GJIV1eUhoq2sI= Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd06.lss.emc.com (RSA Interceptor); Tue, 8 Oct 2019 17:08:47 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x98L8iMF023106 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 8 Oct 2019 17:08:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0439.000; Tue, 8 Oct 2019 17:08:46 -0400 From: "Black, David" To: "saag@ietf.org" , "opsawg@ietf.org" CC: tsvwg-chairs , "Black, David" Thread-Topic: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 Thread-Index: AdV+HJIZhebOrRcXTIK6bGArgFWweQ== Date: Tue, 8 Oct 2019 21:08:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-10-08T21:02:00.0767379Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.238.21.131] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493630766752MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-08_08:2019-10-08,2019-10-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 impostorscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=961 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910080164 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 mlxlogscore=986 suspectscore=0 malwarescore=0 adultscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910080164 Archived-At: Subject: [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 21:10:48 -0000 --_000_CE03DB3D7B45C245BCA0D2432779493630766752MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI - some OPS area and SEC area eyes on this TSVWG draft now (during WGLC)= would be a good thing ;-). Thanks, --David (TSVWG co-chair) From: Black, David Sent: Tuesday, October 8, 2019 5:06 PM To: tsvwg@ietf.org Cc: Black, David Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 201= 9 This email announces a TSVWG Working Group Last Call (WGLC) on: The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet draft-ietf-tsvwg-transport-encrypt-08 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ This draft is intended to become an Informational RFC. This WGLC will run through the end of the day on Wednesday, October 23. That should allow time before the Singapore draft submission cutoff for the authors to revise the draft with any changes that result from WGLC. Comments should be sent to the tsvwg@ietf.org list, = although purely editorial comments may be sent directly to the authors. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you wo= uld like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on this draft. Thanks, David, Gorry and Wes (TSVWG Co-Chairs) --_000_CE03DB3D7B45C245BCA0D2432779493630766752MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI – some OPS a= rea and SEC area eyes on this TSVWG draft now (during WGLC) would be a good= thing ;-).

 

Thanks, --David (TSVWG= co-chair)

 

From: Black, David <david.black@emc.com>= ;
Sent: Tuesday, October 8, 2019 5:06 PM
To: tsvwg@ietf.org
Cc: Black, David
Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 Octo= ber 2019

 

This email announces a TSVWG Working Group Last C= all (WGLC) on:

 

The Impact of Transport Header Confidentiality on= Network Operation and

        &= nbsp;           &nbs= p;  Evolution of the Internet

        &= nbsp;        draft-ietf-tsvwg-transport-= encrypt-08

https://datatracker.ietf.org/doc/draft-ietf= -tsvwg-transport-encrypt/

 

This draft is intended to become an Informational= RFC.

 

This WGLC will run through the end of the day on = Wednesday, October 23.

That should allow time before the Singapore draft= submission cutoff for

the authors to revise the draft with any changes = that result from WGLC.

 

Comments should be sent to the tsvwg@ietf.org list, although purely

editorial comments may be sent directly to the au= thors. Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to

track such editorial comments as part of the WGLC= process.

 

No IPR disclosures have been submitted directly o= n this draft.

 

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)

 

--_000_CE03DB3D7B45C245BCA0D2432779493630766752MX307CL04corpem_-- From nobody Tue Oct 8 15:04:12 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217C9120046 for ; Tue, 8 Oct 2019 15:04:11 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 uPDXYBbS3-kz for ; Tue, 8 Oct 2019 15:04:08 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 78B8E120020 for ; Tue, 8 Oct 2019 15:04:08 -0700 (PDT) Received: from xse125.mail2web.com ([66.113.196.125] helo=xse.mail2web.com) by mx147.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iHxaN-0010FY-GS for saag@ietf.org; Wed, 09 Oct 2019 00:04:05 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46nrwK0t6zz71XT for ; Tue, 8 Oct 2019 15:04:01 -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 1iHxaK-0006EC-VK for saag@ietf.org; Tue, 08 Oct 2019 15:04:01 -0700 Received: (qmail 30399 invoked from network); 8 Oct 2019 22:04:00 -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 ; 8 Oct 2019 22:04:00 -0000 To: Benjamin Kaduk , saag@ietf.org References: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> <20191006161144.GV6722@kduck.mit.edu> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 8 Oct 2019 15:04:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191006161144.GV6722@kduck.mit.edu> Content-Type: multipart/alternative; boundary="------------FDF20E3A1071408B4B7FD0AF" Content-Language: en-US X-Originating-IP: 66.113.196.125 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.125/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.125/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVVy7woNr8hVnK EYT/WlWYMUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59fvboWvpfNpoTZ/UTiDpiMw6U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/GLPGseHORnR7zfibQ2DIPryme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8SnwqlUrBK2R/GBg9vCpMGFHw53FxnHnL50HZvyS1o3x98IkV0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm2uprb+vd2Fz Rl4tm4DfGPMsKUUOgv9CuPdeK9VuRcw0TqHgXyoZvKfP9Nm52j29AQeYUOp7A73HI6oJg7w/Vocn lngNmbSCS/YJsomf4aS+4BqmVLnIdnm03T/hAzUBVF1677oPXF7r5zsW33ZNliqzwES3a0ULUNAa F84x6Jj38SP3vpvbnzv7vbeEFVncH9Q84QG89JN6MvpNdzLqW7pewgiaZytSSbKPC6Fj5qRxHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+3dXjeYKJrFblnlO7Rr89Ia08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [saag] Fwd: Last Call: (A Survey of Transport Security Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 22:04:11 -0000 This is a multi-part message in MIME format. --------------FDF20E3A1071408B4B7FD0AF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 --------------FDF20E3A1071408B4B7FD0AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

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-announce

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--------------FDF20E3A1071408B4B7FD0AF-- From nobody Tue Oct 8 19:42:56 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF712006D for ; Tue, 8 Oct 2019 19:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, SPF_PASS=-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 SXsFF4OC6a0a for ; Tue, 8 Oct 2019 19:42:51 -0700 (PDT) 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 [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 From: Christian Huitema To: Benjamin Kaduk , saag@ietf.org References: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> <20191006161144.GV6722@kduck.mit.edu> Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <3278891e-a18f-4045-6efb-34d76d608352@huitema.net> Date: Tue, 8 Oct 2019 19:42:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------952407BE5796FA7723A006FD" Content-Language: en-US X-Originating-IP: 66.113.197.126 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59fvYghnsr4imsy708TXlwpzMU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5hmwN8D4LrepG7AX8WNwY8fOdU2kQFJEzfkq4ITozmM46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnHY2vFR2X3V3 u1DLkE7IQAkcUbp3Bqu4p2xgXhpsPNPB69BsSJSxcyfz9l7PtUpARgeYUOp7A73HI6oJg7w/VocK FIxNlsy2WJpil5s07kEDyBw3j/aBxjxoZyMqfIL/jJq7xqDoiTjjGpNS1XGXbXI/CQeOLSIbTLMj Ll707sxvAztqzrCt4TZ/wLtujY/tpUpf8ouLb5QDITSNRDXKSuNIsNTbWtIINgLIkbhCu78rPAlb DjazCbhs7qBpykynMha5/rijjcguRYfyvX/qs6BGikecEG2YoGT07Mx+/Nev83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [saag] Fwd: Last Call: (A Survey of Transport Security Protocols) to Informational RFC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 02:42:55 -0000 This is a multi-part message in MIME format. --------------952407BE5796FA7723A006FD Content-Type: text/plain; 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.t= xt. 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 Pr= otocols' >>> 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 ma= y be >>> sent to iesg@ietf.org instead. In either case, please retain the begi= nning of >>> the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document provides a survey of commonly used or notable networ= k >>> security protocols, with a focus on how they interact and integrat= e >>> with applications and transport protocols. Its goal is to supplem= ent >>> 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 Transp= ort >>> Services system may need to support. Moreover, this document defi= nes >>> 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/b= allot/ >>> >>> >>> 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 --------------952407BE5796FA7723A006FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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'
  <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-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
--------------952407BE5796FA7723A006FD-- From nobody Wed Oct 16 06:40:47 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0D5120108; Wed, 16 Oct 2019 06:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=armh.onmicrosoft.com header.b=dU21wJib; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=u2QCBJVt 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 C8BWV_inwGqD; Wed, 16 Oct 2019 06:40:44 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20047.outbound.protection.outlook.com [40.107.2.47]) (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 CACF9120103; Wed, 16 Oct 2019 06:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R0tnCGmANZf3GrIqw0BDtJZTpNRpZ8EisQcJTBDQ+Rk=; b=dU21wJib1sr2CzbnnlqTF8/TXg2BNHBjBLvq2kT3psdAzp24d+ewRtZQFH0y6mIi7kd4OG0w5r4oZ7uHJjdEfBvVUnY0DBH/zmhRn2O2+mmkAgnQSqIffuRfIx2VFTKPXKv0dyiwYGNxozVhZHN0hqr88yM2SU8NhT+rlflHjEs= Received: from VE1PR08CA0022.eurprd08.prod.outlook.com (2603:10a6:803:104::35) by AM6PR08MB3989.eurprd08.prod.outlook.com (2603:10a6:20b:b0::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 16 Oct 2019 13:40:37 +0000 Received: from DB5EUR03FT059.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::209) by VE1PR08CA0022.outlook.office365.com (2603:10a6:803:104::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Wed, 16 Oct 2019 13:40:37 +0000 Authentication-Results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=arm.com; Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT059.mail.protection.outlook.com (10.152.21.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Wed, 16 Oct 2019 13:40:36 +0000 Received: ("Tessian outbound 6481c7fa5a3c:v33"); Wed, 16 Oct 2019 13:40:34 +0000 X-CR-MTA-TID: 64aa7808 Received: from 55f405c3df37.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.12.59]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 389183F3-6152-406E-AA60-99060F22B9F3.1; Wed, 16 Oct 2019 13:40:29 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2059.outbound.protection.outlook.com [104.47.12.59]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 55f405c3df37.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 16 Oct 2019 13:40:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PqiMFFTY//nsfVJpHW4bTPRaLIV35Tn5ySXagEmUUKKGn71ushMx7jBxph7N1feQq0tnFRwi7wEC3AGzq4ngIkbdrZ9Y2xyXfSATSts7U9kckwxpiQ34bHRygZ0FHPjZzmAUGXTS9BUqLzFzlB0eMoEPubW9wwRzFbLm6AaG9btG/xXDvOZzp3VmZn4Z86nnS7OI0yl3vU6OywwNX2FgOcUnfdzUSktP8IynnUDuIauvLfe1xLUb7zGaJxxKlmQCDh2LwLbj48/BMr/XKlnGIFOlbvoBlP8rfi6LvQTn+iAU9j1ENpzk8DgH2gPb+hPjRoq/0NYn6XewV69t/E1F3g== 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=cR5N/Bq366amcpSju8DCspeN2eGyC9NqxzjgEZyxRHc=; b=PTdIQ8bAlejF3BTV6TCryX6n7qI9s3ozetvKpLTW6QGpWeOX9Sbl9+SnABag+anHoh/rNfZ1rPcdjNmrvevIzpNbzIkCnuluYIH/bsxEP6qJJSJBP1VHubLDvCyEIPPBB74/FL9gWswLQ/x8QYMIFfRNU3CaPIGLtce3NQOuWYRaXtjkQYMndpG5ORx/OE7llPG2UwxSENaA2/BVrCQPQob3qBpuHYVLo1nz6scFiw+q0nR5U2bIaLbpkCUC94t2QQ0JGQwFNn/4AIRZ24yLQ/g4rLuyzeorJloc7ZhcmPRe8f7dNlt0cYYKW5NB50kP85viVczu0nlVzsfXrDj8/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cR5N/Bq366amcpSju8DCspeN2eGyC9NqxzjgEZyxRHc=; b=u2QCBJVtobTNozvJq82OU8Z7mnGmLEQob9AL5BrgbP7xzvSIY9Cx1KbXETblLae082ZZqpUbgV9z9fDTSCA/1em3IRHj455zWOnc7LhtEjN1N0vdWx3M/02vyn+LUbcqjJ1jsIMat9aAoqJfoYETTccnmSRgAKUsk9/oXT4liMo= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB3870.eurprd08.prod.outlook.com (20.178.80.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Wed, 16 Oct 2019 13:40:27 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31%2]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 13:40:27 +0000 From: Hannes Tschofenig To: John Mattsson , "hannes.tschofenig@gmx.net" , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVe2jJg2f9VjEFuEec6uHWJQ1CSKddU8Lw Date: Wed, 16 Oct 2019 13:40:27 +0000 Message-ID: References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> In-Reply-To: <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 60c5849c-ccb4-4776-93b6-e0334875c308.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.83] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: b616f816-3cad-4943-5b92-08d7523e6d3f X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: VI1PR08MB3870:|AM6PR08MB3989: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:6790;OLM:6790; x-forefront-prvs: 0192E812EC X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(39860400002)(396003)(366004)(13464003)(189003)(199004)(305945005)(66556008)(6116002)(76116006)(66476007)(2906002)(2201001)(26005)(64756008)(6436002)(478600001)(6506007)(5660300002)(186003)(102836004)(53546011)(3846002)(966005)(74316002)(66946007)(33656002)(7736002)(66446008)(6246003)(7696005)(76176011)(11346002)(446003)(99286004)(66066001)(14454004)(71190400001)(71200400001)(8936002)(55016002)(486006)(52536014)(81166006)(476003)(2501003)(25786009)(8676002)(9686003)(81156014)(229853002)(14444005)(256004)(110136005)(86362001)(6306002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3870; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: N9j5BWWyxcMhxg20NH5fD0GIBH1XQeSA+Ov114HFwAVIzkowWh3+hpumRo9z9zvZrnNO4pXAvrw5bNnl7/UaMzskwk5fDFft8/1aGJt5VuIdUoeGIK7d+PWIgbWFFYhsX4hxF7IqSiXaCsEAUYEqSfb30J8+p0iLc5mUGXyDWKxTCwLc2BMUMfV6N6srXLLz4yoZSC7Xpyc2JPO3ehiUPf9Ph3VE4FiWTBce6X5o0nH3PHozEpdFwqnokhxDoclMIthrpwwXN5wGyN/n+QxyWMHeipN8G83xZV+zD98nA5nLxXAnbmdEtIbgXHQfvNDSurj1Ivr52HWfJpF7FTISImCl7rjH/9jaYIcPpdc81luGYgQX+KLGy1OkzuBakn1Yv1mMhBduyBCG8LmFMETxtTV+DLSFjQRA6IhXqOQmbIaa8aLSuwOtbTPHBVdRZBuKFs2qphMcdslxb13gXQqjEQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3870 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT059.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(376002)(1110001)(339900001)(13464003)(199004)(189003)(40434004)(14444005)(11346002)(9686003)(336012)(446003)(47776003)(2201001)(6116002)(3846002)(8936002)(450100002)(74316002)(2906002)(33656002)(7736002)(229853002)(436003)(86362001)(5024004)(305945005)(52536014)(102836004)(6306002)(7696005)(70206006)(6506007)(53546011)(26826003)(22756006)(55016002)(14454004)(76130400001)(186003)(2501003)(76176011)(478600001)(26005)(966005)(5660300002)(316002)(476003)(8676002)(50466002)(81156014)(81166006)(99286004)(356004)(110136005)(486006)(6246003)(66066001)(70586007)(126002)(25786009)(23676004)(2486003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3989; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Fail; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 0f6e2a7c-f4b6-4c1b-669f-08d7523e67b3 X-Forefront-PRVS: 0192E812EC X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3ulNnLwMQ70mCKB6KErHTfxLvm+JdZvChcgewAo4h3U+mcEX7k9YWZK3szCbmuY+k5uuX5wdGjDFhaknTk7xmAZ3i0DDmQ59wpF56GcUAlw4hqHv45urChMEib8DmRjjwT587ghCgnBC95E3mdshS2A0jrEqHCh/xnO9Y6VZ5wiJ/VjuHUwVwdo8QBYj91aH8JdxJtVCHW1U4y6cfxeQCqBBf+2XLHpkQgaGJlb4kAKR6NUKYhDcrj3cVQwY6gydml1nZQnPeih2ys3UedGkTGaWlfttPWfZcxWu86zmk5+KIyBUaYNnh92GThClZQuzARxrwk9h69jBJEFE5eTfHNYm4SkvBCcgS/FuN/jA1pft8KfxYM+8cviP307FrLyvrlKleUQuSegDpr95n+UlHE7wRpTzIq3isMw9J564gTlGtktV8Gt5F+ZhUFPcLtt7IlsSbC4gtgJgx1gK0uYHIA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2019 13:40:36.9812 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b616f816-3cad-4943-5b92-08d7523e6d3f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3989 Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 13:40:47 -0000 Sm9obiwgIHlvdSByZWZlcmVuY2UgUkZDIDc1NDAgYW5kIEkgYmVsaWV2ZSB5b3Ugd2FudGVkIHRv IHJlZmVyIHRvIFJGQyA3OTI1IGluc3RlYWQuDQoNClJGQyA3OTI1IHRhbGtzIGFib3V0IHRoZSBF eHRlbmRlZCBNYXN0ZXIgU2VjcmV0IGV4dGVuc2lvbiwgU2lnbmF0dXJlIEFsZ29yaXRobSBleHRl bnNpb24sIGFuZA0KT0NTUCBzdGFwbGluZy4NCg0KQ2lhbw0KSGFubmVzDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYWFnIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBKb2huIE1hdHRzc29uDQpTZW50OiBTYW1zdGFnLCA1LiBPa3RvYmVyIDIwMTkgMTI6 MzYNClRvOiBoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0OyBUTFNAaWV0Zi5vcmc7IHNhYWdAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2FhZ10gW1RMU10gTGVzc29ucyBsZWFybmVkIGZyb20gVExT IDEuMCBhbmQgVExTIDEuMSBkZXByZWNhdGlvbg0KDQoiaGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dCIgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KDQo+IFBTOiBBcyBLYXRobGVl biBub3RlZCBUTFMgMS4yIGFuZCBEVExTIDEuMiBhcmUgcGVyZmVjdGx5IGZpbmUgaWYgeW91IGZv bGxvdyBSRkMgNzkyNS83NTI1Lg0KDQpXaGlsZSBUTFMgMS4yIGFuZCBEVExTIDEuMiBjYW4gYmUg Y29uZmlndXJlZCB0byBiZSBzZWN1cmUsIFJGQyA3NTI1IGlzIGRlZmluaXRlbHkgbm90IGVub3Vn aC4gUkZDIDc1NDAgd291bGQgYmUgYSBnb29kIHN0YXJ0LCBidXQgYWxzbyB0aGF0IHdvdWxkIG5l ZWQgdG8gYmUgZXh0ZW5kZWQgd2l0aCBzdXBwb3J0IG9mIGV4dGVuc2lvbnMgbGlrZSBFeHRlbmRl ZCBNYXN0ZXIgU2VjcmV0LCBTaWduYXR1cmUgQWxnb3JpdGhtcywgYW5kIENlcnRpZmljYXRlIFN0 YXR1cyBSZXF1ZXN0IHRvIGJlIGNvbnNpZGVyZWQgZmluZSBpbiAyMDE5Lg0KDQpDaGVlcnMsDQpK b2huDQoNCu+7vw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= From nobody Thu Oct 17 06:01:29 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE25120233 for ; Thu, 17 Oct 2019 06:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=cert.org 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 0eHxxV9IurnE for ; Thu, 17 Oct 2019 06:01:17 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 2CEEC120271 for ; Thu, 17 Oct 2019 06:01:17 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x9HD19Qx036098 for ; Thu, 17 Oct 2019 09:01:09 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x9HD19Qx036098 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1571317269; bh=rte3G1dMqQTQJ1NIpEvr7F+gB31LwRHAJLliveKAmew=; h=From:To:Subject:Date:From; b=hLq0wRRoJqv4TXvFIzDJhWcv9St9LD6maynBzKmcf8vn8YoljdVhXsJQINA0iXtwV IVSn68r2vIyCs6y1l5dl7frdRj34CYJgFZfo8qYsIdHQd1cgAWBzmGJE/HWx+W52/8 0EPNNnguP1bHJ21x1YDzdWQq/X95rLt3Dt+8lC+M= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x9HD1ABI005192 for ; Thu, 17 Oct 2019 09:01:10 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Thu, 17 Oct 2019 09:01:10 -0400 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: IETF 106 agenda items Thread-Index: AdWE6fSQIApU2DT4RGyEQLDlkTJWrw== Date: Thu, 17 Oct 2019 13:01:09 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B348BF95@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] IETF 106 agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 13:01:28 -0000 Hello! In preparation for the IETF 106 meeting in Singapore, we are putting togeth= er the SAAG agenda. Historically, after the working group reports, we have= had one or two invited presentations, or an introduction to a cross-cuttin= g activity that could impact security work. We would appreciate ideas on p= resentation topics that you believe would be of interest to the community. = If you can identify an appropriate presenter (not necessarily yourself) th= at would be helpful. Thanks, Roman and Ben From nobody Thu Oct 17 08:40:17 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3090120962 for ; Thu, 17 Oct 2019 08:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=W7d9Q9Dr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=w2ww2lsI 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 IbDWrmu1OZaV for ; Thu, 17 Oct 2019 08:40:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DFD812096A for ; Thu, 17 Oct 2019 08:40:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9D8F522189 for ; Thu, 17 Oct 2019 11:39:59 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 17 Oct 2019 11:39:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=kM0Vf CBlUhV9rT01YW+Wynv1QhFfAkeSB9Vdai/ba24=; b=W7d9Q9DrLXr6mfLko1cER wuejl5q4sbzhJfknp7l/VV6QyrNwh5ZQKOreOaaLvuzR4Zvr0wrd8eNecJ76NdO+ IiElvGdGIxP79y0BseE5mCPx8ar3yhesj0zgVr0endz3YUQZgb1lgeRkBVMZvoXK cUpGLx5hPbkbLbatJpiM2ZDEG7lRsOSWabNzAa7n/6/2dIw/EuPe3mPlPI+19X0G 2olbZscsZ70tpIEkIJH77UEhq1MUgy3yrnlwpUqCz413h1Zd71OLN74YYYdN9xYu Wam4SR2KCxtLYGA9Z6/MIGxGssd40dqMYncsRPv5wMhj6/hk+toH/Kyf589v1DRm Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=kM0VfCBlUhV9rT01YW+Wynv1QhFfAkeSB9Vdai/ba 24=; b=w2ww2lsI0pu8pkEe33Q1o3mg3/7q8Gdl0lBbC1gvetr5MKsxooHathqqJ twoL4QGsXrZb2zZqHCRZRa9kPW6XaKZ/JY8gHkSrvYgUT9EjLnluOVPnhzuyA1Wh vA3IPI3L3TKB36I22gsJ/wi/X7kfqZoOgKsF42+rjsYuXYSX83pLeS2F+LlP01CI bfvYGMo5qIt1QRCcqq7R2h+fK7Z6bhfwP5W0PSrjvcVHojH7fPDUhT+PABSYekmR wfy2ObXrADv6CMQ98A6mT2UoOOMnc1qixjkv6JwtGd/dBZZygpHu5sX+Joe96Gik tQoIbIzFVYiVtE5ITnepof87w/3fQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeejgdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3BB70E00A5; Thu, 17 Oct 2019 11:39:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> Date: Thu, 17 Oct 2019 08:39:39 -0700 From: "Martin Thomson" To: saag@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 15:40:16 -0000 I think that John was referring to the TLS usage profile in 7540, which = is, I believe, still good advice. The IoT profile in RFC 7925 also has = good advice, but there is some bias toward things like CCM, which I don'= t believe are as widely applicable. On Wed, Oct 16, 2019, at 06:40, Hannes Tschofenig wrote: > John, you reference RFC 7540 and I believe you wanted to refer to RFC= =20 > 7925 instead. >=20 > RFC 7925 talks about the Extended Master Secret extension, Signature=20= > Algorithm extension, and > OCSP stapling. >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: saag On Behalf Of John Mattsson > Sent: Samstag, 5. Oktober 2019 12:36 > To: hannes.tschofenig@gmx.net; TLS@ietf.org; saag@ietf.org > Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 dep= recation >=20 > "hannes.tschofenig@gmx.net" wrote: >=20 > > PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you= follow RFC 7925/7525. >=20 > While TLS 1.2 and DTLS 1.2 can be configured to be secure, RFC 7525 is= =20 > definitely not enough. RFC 7540 would be a good start, but also that=20= > would need to be extended with support of extensions like Extended=20 > Master Secret, Signature Algorithms, and Certificate Status Request to= =20 > be considered fine in 2019. >=20 > Cheers, > John >=20 > =EF=BB=BF >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > IMPORTANT NOTICE: The contents of this email and any attachments are=20= > confidential and may also be privileged. If you are not the intended=20= > recipient, please notify the sender immediately and do not disclose th= e=20 > contents to any other person, use it for any purpose, or store or copy= =20 > the information in any medium. Thank you. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Fri Oct 18 10:48:01 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192641208ED for ; Fri, 18 Oct 2019 10:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 kBRS9naG0yYy for ; Fri, 18 Oct 2019 10:47:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E8D1208DC for ; Fri, 18 Oct 2019 10:47:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8F02BE3E for ; Fri, 18 Oct 2019 18:47:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA9wKGseWerO for ; Fri, 18 Oct 2019 18:47:19 +0100 (IST) Received: from [10.150.37.47] (unknown [104.129.159.229]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8F873BE2F for ; Fri, 18 Oct 2019 18:47:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571420839; bh=JkEEMJ6siDHbELUgZqUMOxLA7KJ6kFWnyx8mu3Uua1Q=; h=To:From:Subject:Date:From; b=yQKeqic8dXg9kfzcA5U5BgEtlZam4bS8jC83IA89n5/6Yx/jsnuONXrLyZfdHndSk 41qca0+Oa3Cal1JZFu4bRaJrVG/+bzgeZJeNUDzAvVfwMebF9dTBNLpPffr38ZPW6J A9hZy3HdJdg21z7gk6tUqERQBXM84n87J56Zg3Ow= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 18 Oct 2019 18:47:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7ple33rFta5M1dTEfmQer0YcFYnt6tLZ3" Archived-At: Subject: [saag] NIST draft report on routing security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 17:47:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7ple33rFta5M1dTEfmQer0YcFYnt6tLZ3 Content-Type: multipart/mixed; boundary="Z5POCfqTkJgVmuU0z76OvKrIbeOIOElQM"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" Message-ID: Subject: NIST draft report on routing security --Z5POCfqTkJgVmuU0z76OvKrIbeOIOElQM Content-Type: multipart/mixed; boundary="------------9B22EA7894523CC2B7499CC0" Content-Language: en-GB This is a multi-part message in MIME format. --------------9B22EA7894523CC2B7499CC0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, NIST have a draft report on routing security [1] that's open for public comment until Nov 15. I'm told (have yet to read it) that refers to a bunch of IETF work, as you might imagine. If folks on here have any comments, you can of course make them directly. If you think there'd be value in the IAB commenting on this as the IAB, then please respond here with the comments you'd suggest the IAB might want to make. Given the timeline, it'd be good to get any such comments by the end of the month. Thanks, S. [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-dra= ft2.pdf --------------9B22EA7894523CC2B7499CC0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------9B22EA7894523CC2B7499CC0-- --Z5POCfqTkJgVmuU0z76OvKrIbeOIOElQM-- --7ple33rFta5M1dTEfmQer0YcFYnt6tLZ3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2p+qIACgkQWrL68XsX K+rplw//e6SdFLvRIOwAXeQT9V/4eHa60fSQIGvTajfTiNV1Z5cDEUOGgH0euZs3 7dIzDHrBcGZ3w8J4ZaTzCR4vFpYvQCsKovGkcpII5r3+Wc+TzEuC6gSbMfNtXu5P I8m1g4djQHhegtjaZ7TAHK0tAMjBUAf8ffRuXLtu3LvjyaQ9kjHjQK+KJ7WHiOp/ qFaz0ofz+0A/IMj2mk+ANoBWDH8GyekYQPcaqnffySFJPHFT7m7fQhzRuOd3Oa4S vnjVWvg8nL7GbwdzqJW4j2L0ovAuaKcgMntbHRoFTmcY3xM3E1UNxn7ozampjdjU A/q5Vt4lomChZShi/ezvXpcHHC98VxQr1e1bcxsEBCfp89mKDiwLEzH0vt7oD9Jj cAqHASkisdmVpGzzfoPQenKvmvNpR+iuVIlHq5MC2/1U/Zx4m3yKzL5KCu9/U9BP iOrrTAcC1qHSYyIpmb4ZGRy/SdAlVK/OcKddupfViIWVwZRdqcLkbyU5rSJ1BKaK b+ysJeoDPfv8lqf/LoUW84jIyxq4Be5gyEeqparvuKXyuiX+thZyl/fKW0URR0kB MqK/d1YU/Qv1piCZyv5lnLJmcpqSctjRhGLW32V884UMjGLOqpOnvhC4GouUQYd1 95EF/17wzmTTKlNmysQiOOAjxwaHHYnQem2nZOSr4iNPdOSB5fA= =bbLu -----END PGP SIGNATURE----- --7ple33rFta5M1dTEfmQer0YcFYnt6tLZ3-- From nobody Thu Oct 24 09:11:26 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7D120965; Thu, 24 Oct 2019 09:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 cRfzqf2GIZnG; Thu, 24 Oct 2019 09:10:55 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D90120979; Thu, 24 Oct 2019 09:10:55 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 46zXKT64zXz10GR; Thu, 24 Oct 2019 18:10:53 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 46zXKT51sgzDq7l; Thu, 24 Oct 2019 18:10:53 +0200 (CEST) Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0468.000; Thu, 24 Oct 2019 18:10:53 +0200 From: To: "Gorry Fairhurst (gorry@erg.abdn.ac.uk)" , tsvwg-chairs , "Black, David" CC: "saag@ietf.org" , "opsawg@ietf.org" , "IETF IPPM WG (ippm@ietf.org)" , "quic@ietf.org" , "tsvwg@ietf.org" , "etosat@ietf.org" Thread-Topic: TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 Thread-Index: AdV+HJIZhebOrRcXTIK6bGArgFWweQEbzmAgAfqMkPA= Date: Thu, 24 Oct 2019 16:10:53 +0000 Message-ID: <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> References: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 16:10:58 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My view on the draft is that a section is missing. I suggest adding a section 7 named "end-to-end interdomain OAM" to bridge i= OAM and OAM of end-to-end encrypted flows. The content of the section might= relies on the following: Fast interdomain troubleshooting requires a minimal interoperability to est= imate delay and packet loss. QUIC spinbit approach is an example which supports end-to-end interdomain O= AM. The signal exposed is end-to-end protected and not encrypted; its enfor= cement is under the control of the endpoint; its activation is limited to a= small percentage of the flows. Here are other comments on the draft. I read the draft very quickly so seve= ral ones might be inappropriate: =B7 Encryption and protection should be clearly separated; o TCPcrypt header protection (part end-to-end encrypted, part end-to-end= protected and on-path readable) mechanism ; o QUIC spinbit protection (end-to-end protected and on-path readable); =B7 QUIC spinbit on-path troubleshooting properties : applies to in= terdomain; =B7 DTLS on-path troubleshooting properties might be described; =B7 Not sure that the draft recall transport proxies usage, like fo= r satco; =B7 Security section should highlight the privacy risk when on-path= probes have to do whole packet decryption to get header information ; Regards Emile De : saag [mailto:saag-bounces@ietf.org] De la part de Black, David Envoy=E9 : mardi 8 octobre 2019 23:09 =C0 : saag@ietf.org; opsawg@ietf.org Cc : tsvwg-chairs Objet : [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23= October 2019 FYI - some OPS area and SEC area eyes on this TSVWG draft now (during WGLC)= would be a good thing ;-). Thanks, --David (TSVWG co-chair) From: Black, David Sent: Tuesday, October 8, 2019 5:06 PM To: tsvwg@ietf.org Cc: Black, David Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019 This email announces a TSVWG Working Group Last Call (WGLC) on: The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet draft-ietf-tsvwg-transport-encrypt-08 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ This draft is intended to become an Informational RFC. This WGLC will run through the end of the day on Wednesday, October 23. That should allow time before the Singapore draft submission cutoff for the authors to revise the draft with any changes that result from WGLC. Comments should be sent to the tsvwg@ietf.org list, = although purely editorial comments may be sent directly to the authors. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you wo= uld like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on this draft. Thanks, David, Gorry and Wes (TSVWG Co-Chairs) ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

My view on the= draft is that a section is missing.

 

I suggest addi= ng a section 7 named “end-to-end interdomain OAM” to bridge iOA= M and OAM of end-to-end encrypted flows. The content of the section might relies on the following:

 

Fast interdomain troubleshooting requires a minimal interope= rability to estimate delay and packet loss.

QUIC spinbit approach is an example which supports end-to-en= d interdomain OAM. The signal exposed is end-to-end protected and not encrypted; its enforcement is under the control of the endpoint; its activation is limited to a = small percentage of the flows.

 

Here are other comments on the draft. I read the draft very quickly = so several ones might be inappropriate<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Arial"= ,"sans-serif";color:black">:

=B7    &n= bsp;    Encryp= tion and protection should be clearly separated;  

o=     TCPcrypt header protection (part end-to-end encrypted, part end-to-end protected and on-path readable= ) mechanism ;

o=     QUIC s= pinbit protection (end-to-end protected and on-path readable= );

=B7    &n= bsp;    QUIC s= pinbit on-path troubleshooting properties : applies to interdomain;

=B7    &n= bsp;    DTLS o= n-path troubleshooting properties might be described;

=B7    &n= bsp;    Not su= re that the draft recall trans= port proxies usage, like for satco;

=B7    &n= bsp;    Securi= ty section should highlight the privacy risk when on-path probes have= to do whole packet decryption to get header information ;

 

Regards=

Emile

 

 

De : saag= [mailto:saag-bounces@ietf.org] De la part de Black, David
Envoy=E9 : mardi 8 octobre 2019 23:09
=C0 : saag@ietf.org; opsawg@ietf.org
Cc : tsvwg-chairs
Objet : [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-0= 8, closes 23 October 2019

 

FYI = 211; some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) = would be a good thing ;-).

&n= bsp;

Thanks,= --David (TSVWG co-chair)

&n= bsp;

From: Black, David <david.black@emc.com>
Sent: Tuesday, October 8, 2019 5:06 PM
To: tsvwg@ietf.org
Cc: Black, David
Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 Octo= ber 2019

 

This email announces a TSVWG= Working Group Last Call (WGLC) on:

 

The Impact of Transport Head= er Confidentiality on Network Operation and

    &nbs= p;            &= nbsp;     Evolution of the Internet

    &nbs= p;            draft-= ietf-tsvwg-transport-encrypt-08

https://datatracker.ie= tf.org/doc/draft-ietf-tsvwg-transport-encrypt/

 

This draft is intended to be= come an Informational RFC.

 

This WGLC will run through t= he end of the day on Wednesday, October 23.

That should allow time befor= e the Singapore draft submission cutoff for

the authors to revise the dr= aft with any changes that result from WGLC.

 

Comments should be sent to t= he tsvwg@ietf.org list, although purely

editorial comments may be se= nt directly to the authors. Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to<= /span>

track such editorial comment= s as part of the WGLC process.

 

No IPR disclosures have been= submitted directly on this draft.

 

Thanks,

David, Gorry and Wes

(TSVWG Co-Chairs)=

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0OPEXCAUBM44corp_-- From nobody Wed Oct 30 09:38:39 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A619D120058 for ; Wed, 30 Oct 2019 09:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans-eu.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 hZeJRay6TRij for ; Wed, 30 Oct 2019 09:38:35 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 34B65120024 for ; Wed, 30 Oct 2019 09:38:35 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id v9so3074002wrq.5 for ; Wed, 30 Oct 2019 09:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans-eu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0U7cwkcD/gWJDvQjb4BG5q1mDaSwnR4ZdRQVtSPR4jY=; b=1kq4OCfsDXKg5TCBv7scWlNtj4j/VuSsYe0Gogfvas6mJMH1lVAq1/w5thMeLJmB4Z N0lcQWPkDxV6LBlZEHGtGMGVkej8+Y8GDJiStjM3O19onKALbT6xQdoUxifYlrpZ3nW/ rFW+1WVmiYaVHYXpUOnSfAkaNO+FD7s6BL+9L8+0yLRNQjXTa1otwz3lX98zFP+DtC53 FJ+5XzuEefbSQ21RbP4Bh8m4hXqnRJx6gCzP1fSMIHQFCB4XG+YMf1bII9ai4WAIIhi+ pmNGwG9FVYgVaEYDgKdM+P1DajDxWGnGTDsYGhahfzfY80CRK/MeqQajb9QK/27P4Joo jRCA== 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=0U7cwkcD/gWJDvQjb4BG5q1mDaSwnR4ZdRQVtSPR4jY=; b=MfFWaCE6xSR89IfbGfhrTWi5Hb/LDXHOqAFvxyC/mtwXWQLIRoSlBPqXeTc04ls1dT cEFLkdLrQM0fJ0mU2O8ex6fuAER4br5kUm0lZlu0mWnu83y44Dg0HfnrlCptPVaoBoAr GlmCCjRTO+Rh2alWJ3Su0DL9wGecLYU8GEA/6I1DFhOrXRFxk//lSSCBGc4TCtyXP+P1 ChrO3SMYkQ20nJK+ttraKiXiT/mp1+9PSSYNqRHx51nYFgc6HqYZvSwmbHb+ZTgSVpqw EYTZ/Ti6Fmtv6ZTRfv93eTlKj2Ik1Av0iTN3r9BH2XovprHZj1riBhe/jbMvzwVVagyV HOJQ== X-Gm-Message-State: APjAAAUnGKrOIpICfn8Hwu3Ogzbm83K9ystmbSkV96T/VrdG3DDT+y2e RAuVHtnLZlhhGJdn6BlyiZfgTf9QWlkAra1abdJuv2QZCLj2j8UZ X-Google-Smtp-Source: APXvYqxPaZVusfFGQggR+6k+YbC0jGxL3QNAY0okbYI5t13aLQe2Rlqx1LmWhztua200MGQAicgnlQInnSrEcd2Wbdg= X-Received: by 2002:a5d:55c7:: with SMTP id i7mr715943wrw.371.1572453513418; Wed, 30 Oct 2019 09:38:33 -0700 (PDT) MIME-Version: 1.0 From: Melchior Aelmans Date: Wed, 30 Oct 2019 11:38:22 -0500 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="00000000000017eefb0596235d3c" Archived-At: Subject: [saag] NIST draft report on routing security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2019 16:38:37 -0000 --00000000000017eefb0596235d3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi SAAG, Just a few remarks and questions I spotted after reading https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft= 2.pdf ; - Security recommendation 35: why only filter customer sessions with ROA data? Shouldn't filtering take place on all EBGP sessions? - Currently the draft only links to the RIPE validator; shouldn't links be included to NLnet Labs and Cloudflare OctoRPKI for example? - Security recommendation 51: why only =E2=80=9Csmaller ISPs=E2=80=9D? Cheers, Melchior --00000000000017eefb0596235d3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi SAAG,

Just a few remarks and questio= ns I spotted after=C2=A0 reading=C2=A0https://nvlpubs.nis= t.gov/nistpubs/SpecialPublications/NIST.SP.800-189-draft2.pdf;

-=C2=A0Security recommendation 35: why only filter customer ses= sions with ROA data? Shouldn't filtering take place on all EBGP session= s?

- Currently the draft only links to the RIP= E validator; shouldn't links be included to NLnet Labs and Cloudflare O= ctoRPKI for example?

-=C2=A0Security recomme= ndation 51: why only =E2=80=9Csmaller ISPs=E2=80=9D?=C2=A0
<= br>
Cheers,
Melchior
--00000000000017eefb0596235d3c-- From nobody Thu Oct 31 14:11:17 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B8312081B for ; Thu, 31 Oct 2019 14:11:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 u-dUGCfeBiOT for ; Thu, 31 Oct 2019 14:11:13 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) (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 359DE120090 for ; Thu, 31 Oct 2019 14:11:13 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.86_2) (envelope-from ) id 1iQHip-0001yV-0s for saag@ietf.org; Thu, 31 Oct 2019 22:11:11 +0100 Date: Thu, 31 Oct 2019 22:11:11 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: saag@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [saag] Update (-01) on Key Synchronization Protocol (KeySync) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 21:11:16 -0000 Dear SAAG List Please be informed that we have just submitted an update of the I-D on Key Synchronization Protocol (KeySync). This document describes the pEp KeySync protocol, which is designed to perform secure peer-to-peer synchronization of private keys across devices belonging to the same user. https://tools.ietf.org/html/draft-hoeneisen-pep-keysync-01 The document is discussed on the medup@ietf.org list. The topic of "Private Key Synchronization among different devices of a user" has drawn quite some interest among the security experts in the IETF. If considered useful, we could offer a short presentation on the KeySync protocol incl. a screencast of our running code, e.g. in the SAAG WG. We have not requested a slot with the chairs (yet), but would do, if several people expressed their interest within the next few days. All the best Bernie ---------- Forwarded message ---------- [...] A new version of I-D, draft-hoeneisen-pep-keysync-01.txt has been successfully submitted by Bernie Hoeneisen and posted to the IETF repository. Name: draft-hoeneisen-pep-keysync Revision: 01 Title: pretty Easy privacy (pEp): Key Synchronization Protocol (KeySync) Document date: 2019-10-31 Group: Individual Submission Pages: 55 URL: https://www.ietf.org/internet-drafts/draft-hoeneisen-pep-keysync-01.txt Status: https://datatracker.ietf.org/doc/draft-hoeneisen-pep-keysync/ Htmlized: https://tools.ietf.org/html/draft-hoeneisen-pep-keysync-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoeneisen-pep-keysync Diff: https://www.ietf.org/rfcdiff?url2=draft-hoeneisen-pep-keysync-01 Abstract: This document describes the pEp KeySync protocol, which is designed to perform secure peer-to-peer synchronization of private keys across devices belonging to the same user. Modern users of messaging systems typically have multiple devices for communicating, and attempting to use encryption on all of these devices often leads to situations where messages cannot be decrypted on a given device due to missing private key data. Current approaches to resolve key synchronicity issues are cumbersome and potentially unsecure. The pEp KeySync protocol is designed to facilitate this personal key synchronization in a user-friendly manner. From nobody Thu Oct 31 14:38:16 2019 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFB812013A for ; Thu, 31 Oct 2019 14:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Y68AEJ4l2x5W for ; Thu, 31 Oct 2019 14:38:14 -0700 (PDT) Received: from mail.felixhandte.com (felixhandte.com [54.172.180.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126AE120074 for ; Thu, 31 Oct 2019 14:38:14 -0700 (PDT) Received: from [172.30.220.235] (unknown [163.114.130.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.felixhandte.com (Postfix) with ESMTPSA id 5BD1B3005E for ; Thu, 31 Oct 2019 21:38:13 +0000 (UTC) To: saag@ietf.org From: "W. Felix Handte" Message-ID: <0977c11c-d394-5fc1-e753-8c287e8a5de7@felixhandte.com> Date: Thu, 31 Oct 2019 17:38:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] New I-D: Security Considerations Regarding Compression Dictionaries X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2019 21:38:15 -0000 Hello all, For a year now, I've been discussing in the http wg the possibility of specifying a new content-encoding for http traffic that uses dictionary-based compression. (Dictionary-based compression is a really powerful tool that we've had a lot of success deploying internally at Facebook and that is seeing increasing adoption elsewhere [0].) To make a long story short: this is not a new idea. There have been a number of previous attempts at specifying a better compression scheme for HTTP that relies on external state. Of those proposals, most have met their demise at the hands of security concerns. The common refrain has been that the security implications are not well understood, and that until they are, any dictionary-based compression scheme will be viewed with a great deal of suspicion. Accordingly, I have been working to perform a security analysis of dictionary-based compression in the context of internet protocols, and have just published a draft [1]. Your feedback, thoughts, etc. are greatly appreciated! I will be presenting this at httpbis session 2 in Singapore. It was suggested to me that this work might also be of interest to this group. If it makes sense, I would be happy to present and discuss it in Singapore with the SAAG WG as well. Thanks, Felix [0] https://engineering.fb.com/core-data/zstandard/ [1] https://datatracker.ietf.org/doc/draft-handte-httpbis-dict-sec/