From nobody Thu Dec 2 11:36:55 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CB63A06E7 for ; Thu, 2 Dec 2021 11:36:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163847381331.10996.3237068538178445096@ietfa.amsl.com> Date: Thu, 02 Dec 2021 11:36:53 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 19:36:53 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Joseph Salowey 2021-11-24 draft-ietf-bess-srv6-services Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Sean Turner 2021-11-26 draft-ietf-httpbis-http2bis Mališa Vučinić 2021-12-13 draft-ietf-anima-asa-guidelines Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Kathleen Moriarty 2021-10-25 draft-ietf-dots-multihoming Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Next in the reviewer rotation: Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang Derek Atkins John Bradley From nobody Thu Dec 2 12:48:59 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4A53A0986; Thu, 2 Dec 2021 12:48:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty via Datatracker To: Cc: dots@ietf.org, draft-ietf-dots-multihoming.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163847813726.21175.10573418854191010989@ietfa.amsl.com> Reply-To: Kathleen Moriarty Date: Thu, 02 Dec 2021 12:48:57 -0800 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-dots-multihoming-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 20:48:57 -0000 Reviewer: Kathleen Moriarty Review result: Ready This draft does not add any significant security considerations from the base publications for the protocol. Key security considerations are addressed in supporting document including mutual authentication and key (asymmetric and symmetric) provisioning as well as policy requirements. The security considerations add awareness to mitigate from the possibilities of data leaks. Congratulations to all those who have worked on this series of documents! Best regards, Kathleen From nobody Thu Dec 2 22:20:49 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFBB3A13A6; Thu, 2 Dec 2021 22:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 O7WDrUm8A-s9; Thu, 2 Dec 2021 22:20:14 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 D28513A13A3; Thu, 2 Dec 2021 22:20:10 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr20.francetelecom.fr (ESMTP service) with ESMTPS id 4J52k02BGHz1yJr; Fri, 3 Dec 2021 07:20:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1638512408; bh=SxfYzbaCQLozBbR0RKGA2IQ4Dc0DqvBIv6Wi8AxKukA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UoxNIIePHDdLKog4MZOKrFFEtdGGMdyTsIY4L3wUdDXWrQgZGZs0Yn0fOF2b/VAmY uUwnEmC70YqqfX7SqJl7LZBlG25Om3dmAHdhlwsPTx9YU0mxuDbXUNMKzRwk8by96x mtxvgG0tOwNNV1LHPt7LCLDEuvzzW/Zy1xIBozTnPNqTveJjkgvPZt+UUZGaNvP8Pp GA57RtPwMYcpFcdgZ3WWC8voLpQ9opK/5HH4NLxEuQFePi3mzdRwzmduU24GSLjQH4 DtqEQZg8DUXxXgNmggFym20TwzC++sTGd2vz2F1t4WELZAEILoLS9lD7f8Cmp1PVJj exN2ou+l1x5iA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr03.francetelecom.fr (ESMTP service) with ESMTPS id 4J52k01DqfzDq7Y; Fri, 3 Dec 2021 07:20:08 +0100 (CET) From: To: Kathleen Moriarty , "secdir@ietf.org" CC: "dots@ietf.org" , "draft-ietf-dots-multihoming.all@ietf.org" Thread-Topic: Secdir early review of draft-ietf-dots-multihoming-09 Thread-Index: AQHX574IqzKFO5oGXEG/woFwIvUYRawgS9kw Content-Class: Date: Fri, 3 Dec 2021 06:20:07 +0000 Message-ID: <24290_1638512408_61A9B718_24290_87_8_787AE7BB302AE849A7480A190F8B93303545E630@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <163847813726.21175.10573418854191010989@ietfa.amsl.com> In-Reply-To: <163847813726.21175.10573418854191010989@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-12-03T06:19:46Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=b3bdd607-1e65-4740-be75-1bb6e95615d3; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-dots-multihoming-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 06:20:20 -0000 SGkgS2F0aGxlZW4sIA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldy4gTXVjaCBhcHByZWNp YXRlZC4gDQoNCldpbGwgYWNrIHlvdXIgcmV2aWV3IGluIHRoZSBuZXh0IGl0ZXJhdGlvbiBvZiB0 aGUgZHJhZnQuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDogS2F0aGxlZW4gTW9yaWFydHkgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGll dGYub3JnPg0KPiBFbnZvecOpwqA6IGpldWRpIDIgZMOpY2VtYnJlIDIwMjEgMjE6NDkNCj4gw4DC oDogc2VjZGlyQGlldGYub3JnDQo+IENjwqA6IGRvdHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtZG90 cy1tdWx0aWhvbWluZy5hbGxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogU2VjZGlyIGVhcmx5IHJldmll dyBvZiBkcmFmdC1pZXRmLWRvdHMtbXVsdGlob21pbmctMDkNCj4gDQo+IFJldmlld2VyOiBLYXRo bGVlbiBNb3JpYXJ0eQ0KPiBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KPiANCj4gVGhpcyBkcmFmdCBk b2VzIG5vdCBhZGQgYW55IHNpZ25pZmljYW50IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZyb20g dGhlDQo+IGJhc2UgcHVibGljYXRpb25zIGZvciB0aGUgcHJvdG9jb2wuIEtleSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBhcmUNCj4gYWRkcmVzc2VkIGluIHN1cHBvcnRpbmcgZG9jdW1lbnQgaW5j bHVkaW5nIG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQga2V5DQo+IChhc3ltbWV0cmljIGFuZA0K PiBzeW1tZXRyaWMpIHByb3Zpc2lvbmluZyBhcyB3ZWxsIGFzIHBvbGljeSByZXF1aXJlbWVudHMu IFRoZSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0aW9ucyBhZGQgYXdhcmVuZXNzIHRvIG1pdGlnYXRl IGZyb20gdGhlIHBvc3NpYmlsaXRpZXMgb2YgZGF0YQ0KPiBsZWFrcy4NCj4gDQo+IENvbmdyYXR1 bGF0aW9ucyB0byBhbGwgdGhvc2Ugd2hvIGhhdmUgd29ya2VkIG9uIHRoaXMgc2VyaWVzIG9mIGRv Y3VtZW50cyENCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gS2F0aGxlZW4NCj4gDQoNCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXog bGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu ClRoYW5rIHlvdS4KCg== From nobody Fri Dec 3 11:15:09 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D80FA3A03EA; Fri, 3 Dec 2021 10:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1638557716; bh=S0c5JFYQ1NwGDAcWf+KU8YJC0LQ/bt9g3/xYzSr1yA8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=MdRyFz+huOKNJjDe0bOk54t518KXP8bAr3mWLs6nv11o8Y6MEHlmSHUKQiNiqjcT3 FMVYNthfYVpfovHQeqP1oYBZim/GRreFa6TCto62Hkg+gSoVXyUJCe8BG12J++IAxJ KrYsZ3O+RlycpdU8BAaQN5ruQm5zl5QMaB7HRBJ0= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Dec 3 10:55:09 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F603A052C; Fri, 3 Dec 2021 10:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1638557706; bh=S0c5JFYQ1NwGDAcWf+KU8YJC0LQ/bt9g3/xYzSr1yA8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=ETuBwPO+9prX3hvdgDbOcpTERlaySFiNXp1gZFWRmaTThbRs2xqu4WMfEbzjM8NJM Q8CTwyujAW8/Tk4vbXonNr94AHYHRJ+KBncD/1nwj0qkGBKRrNroFR/EvXmg4jBm5X tfr33nZEw4YO51q9Lh+uYPsh4Wz5a6JDKJ5hOe9E= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8CB3A00E1 for ; Fri, 3 Dec 2021 10:55:00 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <163855770029.31433.1331532184815499712@ietfa.amsl.com> Date: Fri, 03 Dec 2021 10:55:00 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 03 Dec 2021 11:15:07 -0800 Subject: [secdir] [new-work] WG Review: General Area Dispatch (gendispatch) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 18:55:23 -0000 The General Area Dispatch (gendispatch) WG in the General Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-12-13. General Area Dispatch (gendispatch) ----------------------------------------------------------------------- Current status: Active WG Chairs: Pete Resnick Kirsty Paine Assigned Area Director: Lars Eggert General Area Directors: Lars Eggert Mailing list: Address: gendispatch@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/gendispatch Archive: https://mailarchive.ietf.org/arch/browse/gendispatch/ Group page: https://datatracker.ietf.org/group/gendispatch/ Charter: https://datatracker.ietf.org/doc/charter-ietf-gendispatch/ The GENDISPATCH working group is a DISPATCH-style working group (see RFC 7957) chartered to consider proposals for new work in the GEN area, including proposals for changes or improvements to the IETF process and process documents. GENDISPATCH is chartered to identify, or to help create, an appropriate venue for new work. GENDISPATCH will not consider any technical standardization work. Guiding principles for proposed new work include: 1. Providing a clear problem statement, historical context, motivation, and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, enough individuals have expressed a willingness to contribute (if appropriate given the subject matter of the proposal) and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap among published or ongoing work in the GEN area, the IESG, the IAB, the IETF LLC, the IRTF, other SDOs, or the wider technical community. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - Requesting that relevant bodies, including but not limited to the IESG, the IAB, the IRTF, or the IETF LLC, consider taking up the work in some form. - Deferring the decision for the new work. - Rejecting the new work. If GENDISPATCH decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. Documents progressed as AD-sponsored would typically include those that are extremely simple or make minor updates to existing process documents. Proposed new work may be deferred in cases where GENDISPATCH does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient interest in GENDISPATCH or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of GENDISPATCH is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, GENDISPATCH will strive to quickly find a home for it (usually within a few months). While most new work in the GEN area is expected to be considered in GENDISPATCH, there may be times when that is not appropriate. At the discretion of the GEN AD, new efforts may follow other paths. For example, work may go directly to a BOF, may be initiated in other working groups when it clearly belongs in that group, or may be directly AD-sponsored. While it is inevitable that some discussion of the merits of a proposal brought to GENDISPATCH are necessary in order to evaluate the appropriate disposition of the proposal, GENDISPATCH is not chartered to actually do the work proposed. Full discussions of proposed work should take place where GENDISPATCH directs the work, whether that is in a WG or BOF, the IETF discussion list or Last Call list in the case of an AD-sponsored document, or in a forum designated by the relevant body to which the work was directed. The existence of GENDISPATCH does not change the IESG's responsibilities and discretion as described in RFC 3710. Work related to the IAB, IETF LLC, IRTF, and RFC Editor processes is out of scope. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Dec 3 13:04:16 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E403A0967; Fri, 3 Dec 2021 13:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fQemlXY9WFTt; Fri, 3 Dec 2021 13:04:07 -0800 (PST) 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 B14713A0965; Fri, 3 Dec 2021 13:04:06 -0800 (PST) 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 1B3L3w7F008220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 Dec 2021 16:04:03 -0500 Date: Fri, 3 Dec 2021 13:03:58 -0800 From: Benjamin Kaduk To: "Scott G. Kelly" Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-regext-rfc7484bis.all@ietf.org Message-ID: <20211203210358.GH11486@kduck.mit.edu> References: <1638294159.982316211@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1638294159.982316211@apps.rackspace.com> Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-regext-rfc7484bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 21:04:11 -0000 Hi Scott, authors, Thanks for raising this topic in your review; it's good to have the additional focus on it. In particular... On Tue, Nov 30, 2021 at 09:42:39AM -0800, Scott G. Kelly wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > The summary of the review is almost ready > > This review is quite late, but still ahead of the telechat, so I hope it is useful. > > From the abstract: > This document specifies a method to find which Registration Data > Access Protocol (RDAP) server is authoritative to answer queries for > a requested scope, such as domain names, IP addresses, or Autonomous > System numbers. This document obsoletes RFC7484 > > Here is the security considerations section: > > "By providing a bootstrap method to find RDAP servers, this document > helps to ensure that the end users will get the RDAP data from an > authoritative source, instead of from rogue sources. The method has > the same security properties as the RDAP protocols themselves. The > transport used to access the registries can be more secure by using > TLS [RFC8446], which IANA supports. > > Additional considerations on using RDAP are described in [RFC7481]." > > Because this document is updating RFC7484, and because these security considerations are copied verbatim from that doc, I hesitate to raise my concern. Nonetheless, I think the assertion that this document "helps to ensure that the end users will get the RDAP data from an authoritative source, instead of from rogue sources." is questionable. I think the suggestion to use TLS helps, but I think it would be better to say something like this: > > "This document specifies a method to find which RDAP server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. If this data is not authenticated, an adversary may inject data that redirects the user to a rogue RDAP server. A robust authentication method such as may be provided by TLS [RFC8446] SHOULD be utilized to protect against this. > > Additional considerations on using RDAP are described in [RFC7481]." This is a good template for actual text to put in the document that covers TLS usage and the need for it. However, I think we may even be able to do better than "TLS SHOULD be utilized", since (as I understand it) RFC 7481 has a requirement that "HTTP over TLS MUST be used to protect all client-server exchanges unless operational constraints make it impossible to meet this requirement." So, we might end this text instead with "A robust authentication method is provided by TLS [RFC8446], and accordingly the use of TLS is required by RFC 7481 in the absence of operational constraints that make use of TLS impossible; in such cases, alternative authentication methods SHOULD be utilized to protect against such risks." Thanks again, Ben > I'm not attached to the precise wording, but I think implementers should be told what the risks are, and how to mitigate them. I don't think the current security considerations quite hit that aspiration. > > --Scott > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview From nobody Fri Dec 3 17:15:44 2021 Return-Path: <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@amazonses.watsen.net> X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BDD3A0D36; Fri, 3 Dec 2021 17:15:34 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=amazonses.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 O0zQs4A8SGGx; Fri, 3 Dec 2021 17:15:29 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1ABC3A0D35; Fri, 3 Dec 2021 17:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1638580527; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=d+Tp2rBViboHkYtH0ymhPIHx0M3nyhcXlmf++Vekxwg=; b=RGuaZnliQV4bq1k1kf6NoR2Fvzx/Tg/0kw8tL59DhRLSd+gMvCNtmFsX48YP3NhM XfN+mo49Hqv7HGwNPlH1tZkIuy0SsOwa0bwVim+ByWkpSxkx+COEt9Uar6KJAfsib/E L+IgjR91XOh1fDW8jFyB87fmwMvDgR/R1Bm75fJU= From: Kent Watsen Message-ID: <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sat, 4 Dec 2021 01:15:27 +0000 In-Reply-To: <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> Cc: IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.12.04-54.240.8.96 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 01:15:35 -0000 --Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yaron, Please see below for some responses to your comments. I did also just post -12 including these changes: = https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.html Here=E2=80=99s a direct link to the diffs (note: Opsdir and Gendir = comments are also included): https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-12= Kent (and Russ and Sean) >=20 > On Nov 28, 2021, at 3:22 PM, Yaron Sheffer = wrote: >=20 > In the third point below (certificate rotation), I understand why the = editors see it as out of scope. But we are still leaving implementers = with no guidance, and we=E2=80=99ve all seen enough real world cases = where this leads to people ignoring the vague =E2=80=9Cregenerate the = private key=E2=80=9D. Let me try to offer an alternative. > =20 > Old: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. > =20 > New: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. If CMP or CMC was used for initial certificate = provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for = periodic certificate registration. Similarly, implementations SHOULD = also reuse the initial origin authentication method. > =20 Russ writes: Perhaps the word "regenerate" is the thing that is causing = confusion. Suggestion: In cases where the SZTP-client does not possess an HSM, or otherwise is = unable to use an HSM for the private key, it is RECOMMENDED that the = device periodically reset the configuration to the factory default and = repeat the SZTP protocol. Repeating the SZTP protocol may cause the = device to generate a fresh private key (and associated identity = certificates). Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. To which you replied: =20 I=E2=80=99m really surprised that a factory reset is the right thing = to do in this use case. But you are the expert. The new text works for me. Yaron =20 As the originator of the OLD text, I have the following comments: 1) it is not uncommon to find new devices without an HSM or devices with = an HSM that is only used as a source of entropy (not key protection). = So saying something to address these implementations seems prudent. 2) There=E2=80=99s no reason to call out CMP/CMS. P10 also works, and = note that the YANG in the draft is extensible to allow new formats to be = introduced over time. 3) The protocol as a whole is intended to move a device from an = =E2=80=9Cunmanaged=E2=80=9D state to a =E2=80=9Cmanaged=E2=80=9D state. = That is, SZTP would no longer be in play, as the only management = connections would be, e.g., NETCONF or RESTCONF. Once in the device is = in the managed state, =E2=80=9Cnormal=E2=80=9D ongoing management = mechanisms are expected to be utilized. We can hope that the mechanisms = include periodically prompting the device to regen its key and a = reissuance of an LDevID, but details are out of scope to this draft. 4) One case I=E2=80=99m aware of where a device runs the SZTP protocol = throughout its lifecycle is when a device is deployed in a physically = insecure location (think: a kiosk in an airport) whereby, to thwart = inadvertent disclosure of networking settings from a slash-and-grab, the = entirety of the device=E2=80=99s config is stored in memory (not on = disk). As such, every time power is lost, the device automatically = reverts to its factory default state and, when power is restored, must = run the SZTP protocol to join the network and be provisioned with = configuration. The draft addresses this case with statement =E2=80=9CIt = is RECOMMENDED that a new private key is generated for each CSR = described in this document." The net-net of all this is the following: NEWEST: In cases where the SZTP-client does not possess an HSM, or is unable to use an HSM to protect the private key, it is RECOMMENDED to periodically reset the private key (and associated identity certificates) in order to minimize the lifetime of unprotected private keys. For instance, an NMS controller/orchestrator application could periodically prompt the SZTP-client to generate a new private key and provide a certificate signing request (CSR) or, alternatively, push both the key and an identity certificate to the SZTP-client using, e.g., a PKCS #12 [RFC7292]. In another example, the SZTP-client could be configured to periodically reset the configuration to its factory default, thus causing removal of the private key and associated identity certificates and reexecution of the SZTP protocol. Good? [more below] > Thanks, > Yaron >=20 > =20 > =20 > From: Russ Housley > > Date: Sunday, November 28, 2021 at 20:10 > To: Yaron Sheffer > > Cc: Kent Watsen >, = IETF SecDir >, = draft-ietf-netconf-sztp-csr.all@ietf.org = = >, last-call@ietf.org = >, netconf@ietf.org = > > Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 >=20 > Yaron: > =20 > =20 > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > =C2=B7 The commit that removes the dependency on IDevID and = LDevID does not fix the issue of non-orthogonality. There is very = detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D? > =20 > PKCS#10 is pretty simple. Are you aware of anything more that ought = to be said? > =20 > I think we should explicitly mention what this method *cannot* = provide. As far as I can tell, none of the origin authentication methods = are available when using PKCS #10 directly without wrapping it further. > =20 > That is reasonable. I will talk with my co-authors and see if we can = come up with a brief summary. One reason why the description statement in the "case p10-csr=E2=80=9D = node is so small is because that node (unlike "case cmc-csr" and "case = cmp-csr=E2=80=9D) uses the following typedef from the =E2=80=9Ccrypto-type= s=E2=80=9D draft (i.e. type ct:csr): typedef csr { type binary; description "A CertificationRequest structure, as specified in=20 RFC 2986, encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; } That is, the description for how the p10 is encoded on-the-wire is = defined elsewhere, and not duplicated here. To address your primary = point, as well as the point just mentioned, how about this? OLD: case p10-csr { leaf p10-csr { type ct:csr; description "A CertificationRequest structure, per RFC 2986."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification"; } } NEW: case p10-csr { leaf p10-csr { type ct:csr; description "A CertificationRequest structure, per RFC 2986. Encoding details are defined in the 'ct:csr' typedef defined in RFC AAAA. A raw P10 does not support origin authentication in the CSR structure. External origin authentication may be provided via the ZTP-client's authentication to the ZTP-server at the transport layer (e.g., TLS)."; reference "RFC 2986: PKCS #10: Certification Request Syntax Specification RFC AAAA: YANG Data Types and Groupings for Cryptography"; } } =20 Good? =20 > =C2=B7 I suggest to add the following reference to the = paragraph on quality randomness, as a strong proof that this is a real = world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. > =20 > In another thread, something like this was suggested for another = document: > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As example = for > predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation > of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. > =20 > If this approach works for you, we'll dig up the appropriate = references. > =20 > Yes, but the Heninger et al. reference is a better fit than the Debian = CVE because (1) it discusses network devices rather than servers and (2) = it shows how even less broken RNGs can be exploited by a network = attacker that only sees the public keys. > =20 > I just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys. How about: > =20 > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As an = example of > predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences > of low-entropy random numbers are discussed in Mining Your Ps and = Qs [...]. > The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. The final text reads: Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. As an example of predictable random numbers see CVE-2008-0166 [CVE-2008-0166], and some consequences of low-entropy random numbers are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of quality random numbers is difficult. [ISO.20543-2019], [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and others offer valuable guidance in this area. Good? > =C2=B7 I understand that key generation is out of scope and = maybe this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big hole. > =20 > I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > =20 > Not really, because the =E2=80=9Cprotocol=E2=80=9D described here is: = Client sends a CSR, Server responds with a complete client configuration = blob. This obviously doesn=E2=80=99t work for an already deployed = client. > =20 > I am really confused. The document is an addition to the Secure Zero = Touch Provisioning (SZTP). As such, it is technique to securely = provision a networking device when it is booting in a factory-default = state. That should happen at the initial deployment or after the device = is reset to the factory configuration. This is not the protocol for use = with an already deployed client. [the response for this =E2=80=9Cthird point=E2=80=9D is at the top of = this email.] Kent, on behalf of the authors --Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Yaron,

Please see below for some responses to = your comments.

I= did also just post -12 including these changes:
https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.= html

Here=E2=80=99s a direct link to = the diffs (note: Opsdir and Gendir comments are also included):
= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-12<= br class=3D"">

Kent (and Russ and Sean)



On Nov 28, 2021, at 3:22 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

In the third point below (certificate rotation), I = understand why the editors see it as out of scope. But we are still = leaving implementers with no guidance, and we=E2=80=99ve all seen enough = real world cases where this leads to people ignoring the vague = =E2=80=9Cregenerate the private key=E2=80=9D. Let me try to offer an = alternative.
 
Old:
 
In cases where the = SZTP-client does not possess an HSM, or otherwise is unable to use an = HSM for the private key, it is RECOMMENDED to regenerate the private key = (and associated identity certificates) periodically. Details for how to = generate a new private key and associate a new identity certificate are = outside the scope of this document.
 
New:
 
In cases where the SZTP-client does not possess an HSM, or = otherwise is unable to use an HSM for the private key, it is RECOMMENDED = to regenerate the private key (and associated identity certificates) = periodically. If CMP or CMC was used for initial certificate = provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for = periodic certificate registration. Similarly, implementations SHOULD = also reuse the initial origin authentication method.
 

Russ writes:

    Perhaps the word = "regenerate" is the thing that is causing confusion.
    Suggestion:

In cases where the SZTP-client = does not possess an HSM, or otherwise is unable to use an HSM for the = private key, it is RECOMMENDED that the device periodically reset the = configuration to the factory default and repeat the SZTP protocol. =  Repeating the SZTP protocol may cause the device to generate a = fresh private key (and associated identity certificates). Details for = how to generate a new private key and associate a new identity = certificate are outside the scope of this = document.


To which you replied:
 
    I=E2=80=99m really = surprised that a factory reset is the right thing to do in this use = case. But you are the expert.
    The new text works for = me.
    Yaron
 

As the = originator of the OLD text, I have the following comments:

1) it is not uncommon to find new devices = without an HSM or devices with an HSM that is only used as a source = of entropy (not key protection).  So saying something to address = these implementations seems prudent.

2) = There=E2=80=99s no reason to call out CMP/CMS.  P10 also works, and = note that the YANG in the draft is extensible to allow new formats = to be introduced over time.

3) The protocol as a whole is intended to move a = device from an =E2=80=9Cunmanaged=E2=80=9D state to a =E2=80=9Cmanaged=E2=80= =9D state. That is, SZTP would no longer be in play, as the only = management connections would be, e.g., NETCONF or = RESTCONF.  Once in the device is in the managed state, = =E2=80=9Cnormal=E2=80=9D ongoing management mechanisms are expected to = be utilized.  We can hope that the mechanisms include = periodically prompting the device to regen its key and a reissuance of = an LDevID, but details are out of scope to this draft.

4) One case I=E2=80=99m aware of = where a device runs the SZTP protocol throughout its lifecycle is when a = device is deployed in a physically insecure location (think: a = kiosk in an airport) whereby, to thwart inadvertent disclosure = of networking settings from a slash-and-grab, the entirety of the = device=E2=80=99s config is stored in memory (not on disk).  As = such, every time power is lost, the device automatically reverts to its = factory default state and, when power is restored, must run the = SZTP protocol to join the network and be provisioned with configuration. = The draft addresses this case with statement =E2=80=9CIt is RECOMMENDED = that a new private key is generated for each CSR described in this = document."


The net-net of all this is the = following:

NEWEST:

   In cases where the SZTP-client does = not possess an HSM, or is unable
   to use = an HSM to protect the private key, it is RECOMMENDED to
   periodically reset the private key (and = associated identity
   certificates) in order to = minimize the lifetime of unprotected
  =  private keys.  For instance, an NMS = controller/orchestrator
   application could = periodically prompt the SZTP-client to generate a
   new private key and provide a certificate = signing request (CSR) or,
   alternatively, = push both the key and an identity certificate to the
   SZTP-client using, e.g., a PKCS #12 = [RFC7292].  In another example,
  =  the SZTP-client could be configured to periodically = reset the
   configuration to its factory = default, thus causing removal of the
  =  private key and associated identity certificates = and reexecution of
   the SZTP protocol.


Good?

[more below]


Thanks,
          &= nbsp;     Yaron

 
 

From: Russ Housley <housley@vigilsec.com>
Date: Sunday, November 28, = 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, = IETF SecDir <secdir@ietf.org>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last call = review of draft-ietf-netconf-sztp-csr-11

Yaron:
 
 
Thank you for addressing my comments, I am happy with most of = your responses but I do have a few remaining questions:
 

=C2=B7         The commit that = removes the dependency on IDevID and LDevID does not fix the issue of = non-orthogonality. There is very detailed description for CMP and CMC, = but nothing for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 = out of the box and it=E2=80=99ll just work=E2=80=9D? Or does it mean = =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD=E2=80=9D?

 
PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?
 
I think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin = authentication methods are available when using PKCS #10 directly = without wrapping it further.
 
That= is reasonable.  I will talk with my co-authors and see if we can = come up with a brief = summary.


One reason why the = description statement in the "case p10-csr=E2=80=9D node is so small is = because that node (unlike "case cmc-csr" and "case cmp-csr=E2=80=9D) = uses the following typedef from the =E2=80=9Ccrypto-types=E2=80=9D draft = (i.e. type ct:csr):

    =  typedef csr {
       type = binary;
       description
         "A CertificationRequest = structure, as specified in 
      =     RFC 2986, encoded using ASN.1 distinguished encoding
          rules (DER), as specified = in ITU-T X.690.";
       reference
         "RFC 2986:
            PKCS #10: = Certification Request Syntax Specification
    =         Version 1.7
    =       ITU-T X.690:
      =       Information technology - ASN.1 encoding rules:
            Specification of = Basic Encoding Rules (BER),
        =     Canonical Encoding Rules (CER) and Distinguished
            Encoding Rules = (DER).";
     }

That is, the description for how the p10 is encoded = on-the-wire is defined elsewhere, and not duplicated here.  To = address your primary point, as well as the point just mentioned, how = about this?

OLD:

         case p10-csr {
           leaf p10-csr {
             type = ct:csr;
            =  description
          =      "A CertificationRequest structure, per RFC = 2986.";
            =  reference
            =    "RFC 2986: PKCS #10: Certification
  =                     =     Request Syntax Specification";
    =        }
        =  }

NEW:

         case p10-csr {
           leaf p10-csr {
             type = ct:csr;
            =  description
          =      "A CertificationRequest structure, per = RFC 2986.
            =     Encoding details are defined in the 'ct:csr'
              =   typedef defined in RFC AAAA.

              =   A raw P10 does not support origin authentication in
              =   the CSR structure.  External = origin authentication
        =         may be provided via the = ZTP-client's authentication
      =           to the ZTP-server at the = transport layer (e.g., TLS).";
      =        reference
      =          "RFC 2986: PKCS #10: Certification = Request Syntax
          =               =   Specification
        =         RFC AAAA: YANG Data Types and Groupings = for
              =             Cryptography";
           }
 =        }

 

Good? =  



=C2=B7         I suggest to add the = following reference to the paragraph on quality randomness, as a strong = proof that this is a real world concern:

 
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, = "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
 
In another thread, something like this was suggested for = another document:
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate = pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to = reproduce the PRNG environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force = searching the whole key space. As example for
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6]. The generation
   of quality random numbers = is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS = 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and
   others offers valuable guidance in this = area.
 
If this approach works for you, we'll = dig up the appropriate references.
 
Yes, but the Heninger et al. reference is a better fit than = the Debian CVE because (1) it discusses network devices rather than = servers and (2) it shows how even less broken RNGs can be exploited by a = network attacker that only sees the public keys.
 
I = just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys.  How about:
 
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to reproduce the PRNG = environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force searching the whole key = space. As an example of
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6], and some consequences
   of low-entropy = random numbers are discussed in Mining Your Ps and Qs = [...].
   The generation of quality = random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A = Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], = and
  =  others offers valuable guidance in this = area.


The final text = reads:

  =  Implementations must randomly generate nonces and = private keys.  The
   use of = inadequate pseudo-random number generators (PRNGs) to generate
   cryptographic keys can result in little or no = security.  An attacker
   may = find it much easier to reproduce the PRNG environment that
   produced the keys, searching the resulting small = set of
   possibilities, rather than brute force = searching the whole key space.
   As an = example of predictable random numbers see CVE-2008-0166
   [CVE-2008-0166], and some consequences of = low-entropy random numbers
   are discussed = in Mining Your Ps and Qs [MiningPsQs].  The generation
   of quality random numbers is = difficult.  [ISO.20543-2019],
  =  [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 = [RFC4086], and
   others offer valuable = guidance in this area.

Good?



=C2=B7         I understand that = key generation is out of scope and maybe this needs to be a separate = work item, but recommending periodic replacement of the certs without = recommending a suitable mechanism leaves this solution with a big = hole.

 
I do not agree. =  It does offer the protocol for obtaining replacement certificates = for devices that are able to generating a fresh public/private key pair. =  Getting more detailed would be algorithm specific, which is not = appropriate in this document.
 
Not really, because the =E2=80=9Cprotocol=E2=80=9D described = here is: Client sends a CSR, Server responds with a complete client = configuration blob. This obviously doesn=E2=80=99t work for an already = deployed client.
 
I = am really confused.  The document  is an addition to = the Secure Zero Touch Provisioning (SZTP).  As such, it is = technique to securely provision a networking device when it is booting = in a factory-default state.  That should happen at the initial = deployment or after the device is reset to the factory configuration. =  This is not the protocol for use with an already deployed = client.


[the response for this = =E2=80=9Cthird point=E2=80=9D is at the top of this = email.]



Kent, on behalf of the authors




= --Apple-Mail=_20E1DB5D-7C67-4359-804C-DAB12ED05EA3-- From nobody Sat Dec 4 03:58:53 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14D3A07FF; Sat, 4 Dec 2021 03:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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=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 nPNRHOg5LlPt; Sat, 4 Dec 2021 03:58:18 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 3690F3A07FC; Sat, 4 Dec 2021 03:58:18 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id s137so5737656pgs.5; Sat, 04 Dec 2021 03:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=YEe03L8CMnAXeYNUbKiTeX7LY2GWe7J58EJqZenrfLE=; b=aA9hvhyDYJyxlHC0WjF3MkZfEJ79WoKSvDoBjKYS5uo5tkJUtouPT/n1hiFIixyLlA Mc91jjvbAx081z3GsxfkPmw0/0Moc2lKcEx/OW4m0Jrt/94hOHJD8yoaTZtnqHXwq260 1a2K3JIhjcZMO4fE4itJ0jRGBufG6LF1FksBSLylipf1TPUOPm+Po1Z9tFdgc12MxuKR a+oMZlD1M+d5dgfam8nIfao8koHLo+QKsq8UvjiB185ScTcPp9KIUjWgvjQ5qMkpVSMe SESeGVkXnTL4JaMCBl8Wpe1ndNOIWtyfZ/MmO6UkFYdn9ir/KfuVWahWMM5mhXX0/GLU vxXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=YEe03L8CMnAXeYNUbKiTeX7LY2GWe7J58EJqZenrfLE=; b=BcAV1wtiMo/8hfKlbzpjmA/H/BQrB/1DsrxP2Sgggbpo66tBWIRzNmkSvh+wTHtIc3 M/tn0LstQSutiQShoqKyZMcH7ynnXinXYQZeyX+tsCbuKBFEFeArnlvSWDFVj1+6d1aw rGUmiPi/Vh8VAtWAiMndIKAt9IBTSqczL3pxlK5f+TtISjS9v5uxlgNtWtO0dE8IxWke lrQvRnIbDZNczxa7xZax8KgUwXxoKIRE1hkh6CTG8tp5xrI6w8ZI277KxhFn+rs8WAY5 AckTSvrX9CZBOoo8BV3iqCJn+1IbeW0IyklHrIzPOeggmaJMniVP10Nbca6DVsUj4m/q L1TQ== X-Gm-Message-State: AOAM531udaM6VmRWz67w+OdcFxApzSWauMbX5cLEqIKkGfUX0x4ThRJ8 WqbiPg5HzPiZVDtiei3oQHfl0DM4Wlc= X-Google-Smtp-Source: ABdhPJzprH9cfWw9Q5khBhqo9zwdtBxQlNYa/CnbsjOODAyZCxemPZVlbuTuKLG4MU/InV9zaQ+yFA== X-Received: by 2002:a65:40cd:: with SMTP id u13mr9219833pgp.450.1638619096543; Sat, 04 Dec 2021 03:58:16 -0800 (PST) Received: from MacBook-Pro-2.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id t8sm6102309pfe.28.2021.12.04.03.58.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Dec 2021 03:58:16 -0800 (PST) MIME-Version: 1.0 Date: Sat, 4 Dec 2021 13:58:10 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> Message-ID: <21D42DFF-02A0-F141-B59B-4E4E54C12934@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol>, <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> To: Kent Watsen Cc: IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2021 11:58:24 -0000

I am good with the latest text= . Thank you Kent and Russ!

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Kent Watsen <kent+ietf@watsen.net&g= t;
Date: Saturday, December 4, 2021 at 03:15
To: Yaron = Sheffer <yaronf.ietf@gmail.com>
Cc: IETF SecDir <secdir@= ietf.org>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netco= nf-sztp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>= , netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir l= ast call review of draft-ietf-netconf-sztp-csr-11

 

Hi Yaron,=

 <= /p>

Please see be= low for some responses to your comments.

 

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

In the third point below (certifica= te rotation), I understand why the editors see it as out of scope. But we a= re still leaving implementers with no guidance, and we=E2=80=99ve all seen = enough real world cases where this leads to people ignoring the vague =E2= =80=9Cregenerate the private key=E2=80=9D. Let me try to offer an alternati= ve.

 

Old:

 

In cases where the SZTP-client does not possess an HSM, or o= therwise is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) periodica= lly. Details for how to generate a new private key and associate a new iden= tity certificate are outside the scope of this document.

 

New:=

 <= /o:p>

In case= s where the SZTP-client does not possess an HSM, or otherwise is unable to = use an HSM for the private key, it is RECOMMENDED to regenerate the private= key (and associated identity certificates) periodically. If CMP or CMC was= used for initial certificate provisioning, it is RECOMMENDED to reuse the = protocol (CMC or CMP) for periodic certificate registration. Similarly, imp= lementations SHOULD also reuse the initial origin authentication method.

&nbs= p;

 

Russ writes:

 

    Perhaps the word "regenerate" is the thing = that is causing confusion.

    S= uggestion:

 

In cases where the SZTP-client does not= possess an HSM, or otherwise is unable to use an HSM for the private key, = it is RECOMMENDED that the device periodically reset the configuration to t= he factory default and repeat the SZTP protocol.  Repeating the SZTP p= rotocol may cause the device to generate a fresh private key (and associate= d identity certificates). Details for how to generate a new private key and= associate a new identity certificate are outside the scope of this documen= t.

 

 

To which you replied:

 

    I=E2=80=99m= really surprised that a factory reset is the right thing to do in this use= case. But you are the expert.

  &nbs= p; The new text works for me.

   = ; Yaron

 

=

 

As the originator of the OLD text, I have the= following comments:

1) it is not uncommon to find new devices witho= ut an HSM or devices with an HSM that is only used as a source of entr= opy (not key protection).  So saying something to address these implem= entations seems prudent.

2) There=E2=80=99s no reason to call o= ut CMP/CMS.  P10 also works, and note that the YANG in the draft is&nb= sp;extensible to allow new formats to be introduced over time.

 

3) The protocol as a wh= ole is intended to move a device from an =E2=80=9Cunmanaged=E2=80=9D state = to a =E2=80=9Cmanaged=E2=80=9D state. That is, SZTP would no longer be= in play, as the only management connections would be, e.g., NETCONF or RES= TCONF.  Once in the device is in the managed state, =E2=80=9Cnorm= al=E2=80=9D ongoing management mechanisms are expected to be utilized. = ; We can hope that the mechanisms include periodically prompting the d= evice to regen its key and a reissuance of an LDevID, but details are = out of scope to this draft.

4) One case I=E2=80=99m aware of where a device runs the SZTP p= rotocol throughout its lifecycle is when a device is deployed in a phy= sically insecure location (think: a kiosk in an airport) whereby, to thwart= inadvertent disclosure of networking settings from a slash-and-grab, = the entirety of the device=E2=80=99s config is stored in memory (not on dis= k).  As such, every time power is lost, the device automatically rever= ts to its factory default state and, when power is restored, must run = the SZTP protocol to join the network and be provisioned with configuration= . The draft addresses this case with statement =E2=80=9CIt is RECOMMENDED t= hat a new private key is generated for each CSR described in this docu= ment."

 

The net-net of all this is the following:

 

NEWEST:

&nbs= p;

   In ca= ses where the SZTP-client does not possess an HSM, or is unable
&nb= sp;  to use an HSM to protect the private key, it is RECOMMENDED = to
   periodically reset the private key (and associated ident= ity
   certificates) in order to minimize the lifetime of = ;unprotected
   private keys.  For instance, an NMS = controller/orchestrator
   application could periodically prom= pt the SZTP-client to generate a
   new private key and p= rovide a certificate signing request (CSR) or,
   alterna= tively, push both the key and an identity certificate to the
 =  SZTP-client using, e.g., a PKCS #12 [RFC7292].  In another=  example,
   the SZTP-client could be configured to perio= dically reset the
   configuration to its factory default= , thus causing removal of the
   private key and associat= ed identity certificates and reexecution of
   the SZTP p= rotocol.

 

Good?

 

[more below]

 

 

Thanks,

    =             Yaron

 <= /span>

 =

&= nbsp;

From:&nb= sp;Russ Housley <housley@vigilsec.com>
Date= : Sunday, November 28, = 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@gma= il.com>
Cc: Kent Watsen <kent+ietf@watsen.= net>, IETF SecDir <secdir@ietf= .org>, draft-ietf-netconf-sztp-csr.= all@ietf.org <draft-ietf-netconf-sz= tp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, <= /span>netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-= csr-11

Yaron:

 

 

Thank you for addressing my com= ments, I am happy with most of your responses but I do have a few remaining= questions:

 

=C2=B7         The commit that removes the d= ependency on IDevID and LDevID does not fix the issue of non-orthogonality.= There is very detailed description for CMP and CMC, but nothing for PKCS #= 10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80= =99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for= these certs is still TBD=E2=80=9D?

<= div style=3D'margin-left:.5in'>

 

=

PKCS#10 is pretty simple.  Are yo= u aware of anything more that ought to be said?

<= /div>
<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= /div>

I think we should explicitly mention what this method *ca= nnot* provide. As far as I can tell, none of the origin authentication = methods are available when using PKCS #10 directly without wrapping it furt= her.

 

That is reasonable.  I will talk with my = co-authors and see if we can come up with a brief summary.

 

 

One reason why the description statement in the "case= p10-csr=E2=80=9D node is so small is because that node (unlike "case&= nbsp;cmc-csr" and "case cmp-csr=E2=80=9D) uses the following type= def from the =E2=80=9Ccrypto-types=E2=80=9D draft (i.e. type ct:csr):
     typedef csr {
       type bina= ry;
       description
       = ;  "A CertificationRequest structure, as specified in 
&n= bsp;         RFC 2986, encoded using ASN.1 distinguishe= d encoding
          rules (DER), as specified = in ITU-T X.690.";
       reference
  &n= bsp;      "RFC 2986:
        &nb= sp;   PKCS #10: Certification Request Syntax Specification
  &= nbsp;         Version 1.7
       = ;   ITU-T X.690:
            Informat= ion technology - ASN.1 encoding rules:
         = ;   Specification of Basic Encoding Rules (BER),
    &nbs= p;       Canonical Encoding Rules (CER) and Distinguished            Encoding Rules (DER).";
=      }

That is, the description for how the p10 is en= coded on-the-wire is defined elsewhere, and not duplicated here.  To a= ddress your primary point, as well as the point just mentioned, how about t= his?


OLD:

         c= ase p10-csr {
           leaf p10-csr {             type ct:csr;
  &nb= sp;          description
      &= nbsp;        "A CertificationRequest structure, pe= r RFC 2986.";
             refer= ence
               "RFC 29= 86: PKCS #10: Certification
            &n= bsp;             Request Syntax Specification= ";
           }
    &nbs= p;    }

NEW:

         case p10-csr {
    =        leaf p10-csr {
        &n= bsp;    type ct:csr;
           =  description
              &nbs= p;"A CertificationRequest structure, per RFC 2986.
  &nbs= p;             Encoding details are defined i= n the 'ct:csr'
               &n= bsp;typedef defined in RFC AAAA.

          =       A raw P10 does not support origin authentica= tion in
                the= CSR structure.  External origin authentication
  &n= bsp;             may be provided via the= ZTP-client's authentication
          &nb= sp;     to the ZTP-server at the transport layer (e.g.,= TLS).";
             reference<= br>               "RFC 2986: P= KCS #10: Certification Request Syntax
        &= nbsp;                 Specific= ation
                RFC A= AAA: YANG Data Types and Groupings for
         = ;                 Cryptography= ";
           }
    &nbs= p;    }

 

 

Good?  

 

 



=C2=B7         I suggest to add the following= reference to the paragraph on quality randomness, as a strong proof that t= his is a real world concern:

 

Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman,= "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/>.

=

 

In another thread, something like this was suggested for another docu= ment:

=

 

   Implementations must randomly generate nonces = and private keys.

   The use of inadequate pseudo-random numb= er generators (PRNGs) to

   generate cryptographic keys can result= in little or no security. An attacker

   may find it much easie= r to reproduce the PRNG environment that

   produced the keys, sea= rching the resulting small set of possibilities,

=
=

   rather than br= ute force searching the whole key space. As example for

   predict= able random numbers see CVE-2008-0166 [=E2=80=A6]. The generation

  &nb= sp;of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80= =A6],

=

   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [= =E2=80=A6], BCP 106 [RFC4086], and

   others offers valuable = guidance in this area.

 

If this approach works for you, we'll dig up th= e appropriate references.

 

Yes, but the Heninger et al. reference is a b= etter fit than the Debian CVE because (1) it discusses network devices rath= er than servers and (2) it shows how even less broken RNGs can be exploited= by a network attacker that only sees the public keys.

=
<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= /div>

I just read the Abstract of the paper, and I see your point about= the attacker only observing the public keys.  How about:

 

 

   Impleme= ntations must randomly generate nonces and private keys.

   The use of inadequate pseudo-random number g= enerators (PRNGs) to

   gener= ate cryptographic keys can result in little or no security. An attacker

   may find it much easier to re= produce the PRNG environment that

 = ;  produced the keys, searching the resulting small set of possibiliti= es,

   rather than brute forc= e searching the whole key space. As an example of

   predictable random numbers see CVE-2008-0166 [=E2= =80=A6], and some consequences

  &= nbsp;of low-entropy random numbers are discussed in Mining Your Ps and= Qs [...].

<= p class=3DMsoNormal style=3D'margin-left:.5in'>   The generation = of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],

   NIST SP 800-90A Rev.1 [=E2=80= =A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and

   others offers valuable guidance in this are= a.

 

 

The final text reads:

 

   Implementations mu= st randomly generate nonces and private keys.  The
 =  use of inadequate pseudo-random number generators (PRNGs) to ge= nerate
   cryptographic keys can result in little or no securi= ty.  An attacker
   may find it much easier to = reproduce the PRNG environment that
   produced the keys,= searching the resulting small set of
   possibilities, rather= than brute force searching the whole key space.
   As an= example of predictable random numbers see CVE-2008-0166
   [C= VE-2008-0166], and some consequences of low-entropy random numbers
=    are discussed in Mining Your Ps and Qs [MiningPsQs]. &nbs= p;The generation
   of quality random numbers is difficul= t.  [ISO.20543-2019],
   [NIST.SP.800-90Ar1], BSI AI= S 31 [AIS31], BCP 106 [RFC4086], and
   others offer valu= able guidance in this area.

Good?<= o:p>

 

 

 

=

=C2=B7    &nb= sp;    I understand that key generation is out of scope and maybe this needs to = be a separate work item, but recommending periodic replacement of the certs= without recommending a suitable mechanism leaves this solution with a big = hole.

 

I do not agree.  It does offer the protocol= for obtaining replacement certificates for devices that are able to genera= ting a fresh public/private key pair.  Getting more detailed would be = algorithm specific, which is not appropriate in this document.

 

Not really, because the =E2=80=9Cprotocol=E2= =80=9D described here is: Client sends a CSR, Server responds with a comple= te client configuration blob. This obviously doesn=E2=80=99t work for an al= ready deployed client.

<= div>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>I am really confused.  = The document  is an addition to the Secure Zero Touch Provisionin= g (SZTP).  As such, it is technique to securely provision a networking= device when it is booting in a factory-default state.  That should ha= ppen at the initial deployment or after the device is reset to the factory = configuration.  This is not the protocol for use with an already deplo= yed client.

 

 

[the response for this =E2=80=9Cthi= rd point=E2=80=9D is at the top of this email.]

 

 

 

Kent, on behalf of t= he authors

 

 

 

 

= From nobody Sun Dec 5 18:36:21 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 292CC3A089E; Sun, 5 Dec 2021 18:36:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: bess@ietf.org, draft-ietf-bess-srv6-services.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163875817110.10559.7120945470066479131@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Sun, 05 Dec 2021 18:36:11 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bess-srv6-services-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 02:36:11 -0000 Reviewer: Joseph Salowey Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document is ready. I did not find any security issues in the document and the security considerations section looks good. From nobody Mon Dec 6 18:36:17 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EA23A0EDE; Mon, 6 Dec 2021 18:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 K24KqmKkovQW; Mon, 6 Dec 2021 18:36:03 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 120113A0EDC; Mon, 6 Dec 2021 18:36:03 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id 30so5082462uag.13; Mon, 06 Dec 2021 18:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+oxAIliLbIn4FsBiGjRCdNppWbGBdO/sQPvR0Lv+E1Y=; b=jlmR2mmdYG47HfURoPrlOa9gYSpOAwuS2YtYfqAlfJIxfO+IZbmHIlncC/0ftw4Y/Q PcpMDsxEZmHIGfKf01xdb+88am1r6E9v6lQ86uezVC+psj0plT06H8IImWfaJVej6KZk SmgQyD5gO6KYOrNUdFSccqv4s9txTi0XuOk+sdNwBid9ETUfyLf5a9U4+5IC2lx1tk4q /U+4MoOcjbFQNGeaJsyaSt6gFr760tZF8asLXZNQvF4vFowfwsuLYge6KxK4Zzm5ISje aZ86HaXzrTEw5KhzOkbejFZUO62iSc8KYq0LecCZJDicPw7VVVgNEt09q89TEhdueVIG MNqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+oxAIliLbIn4FsBiGjRCdNppWbGBdO/sQPvR0Lv+E1Y=; b=dX8Gp3Q/le4hnmeyvoOagvRULM9jb1gxSliOtsvcYBhY46HvIjpATh9z/1x9iHEMjr GvCUo852zT/km0k3zvIwquFd4sccHMzZJ4MfZceED1uYsV9Ok5ymsCVoIpIAx8266d8u 60jvD7sWxqEvMco/qMsbxsxRSVdbgFSK9XNL4heNNQ2ZpKkNRfF3wzRHlYfpbJ5ym3m2 T4EP0f9ZEJI2QQy9rh8nqdnTFZnI+twCtECZz5rwc0xwsBkYzw92Ja1KMGFs6CxnqsOE jkaP4Vn2KbjSB23pOHK76TmtgaZcxU49RkG2K16c0Sdzof4tX1AuGjN/JXklzB8oKBcD dIog== X-Gm-Message-State: AOAM533Z7PwO5kjXIi9S1HEoZGSk5S1gqD0kYEmYOM2ITFYA5B0/9xi5 SdyeLmE8C4ZuzCaH6z3cPsgdj7xVbcwWlcB9DAELcNW+ X-Google-Smtp-Source: ABdhPJyeA62E7SmIBDZ5KKWr7D6f2sNGybJMC5SgTswapNA/9+lY6Qcen7qnfN9vCkj6J8/I6BWfMCtKe25ucXNQD7k= X-Received: by 2002:ab0:6813:: with SMTP id z19mr46340581uar.28.1638844560388; Mon, 06 Dec 2021 18:36:00 -0800 (PST) MIME-Version: 1.0 References: <163875817110.10559.7120945470066479131@ietfa.amsl.com> In-Reply-To: <163875817110.10559.7120945470066479131@ietfa.amsl.com> From: Ketan Talaulikar Date: Tue, 7 Dec 2021 08:05:49 +0530 Message-ID: To: Joseph Salowey Cc: secdir@ietf.org, bess@ietf.org, draft-ietf-bess-srv6-services.all@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary="000000000000dd351905d2853b91" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-srv6-services-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 02:36:08 -0000 --000000000000dd351905d2853b91 Content-Type: text/plain; charset="UTF-8" Hi Joseph, Thanks for your review of this document. Thanks, Ketan (on behalf of co-authors) On Mon, Dec 6, 2021 at 8:06 AM Joseph Salowey via Datatracker < noreply@ietf.org> wrote: > Reviewer: Joseph Salowey > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is the document is ready. > > I did not find any security issues in the document and the security > considerations section looks good. > > > --000000000000dd351905d2853b91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joseph,

Thanks for your review of th= is document.

Thanks,
Ketan (on behalf of= co-authors)


On Mon, Dec 6, 2021 at 8:06 AM Joseph Salo= wey via Datatracker <noreply@ietf.or= g> wrote:
Reviewer: Joseph Salowey
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is the document is ready.

I did not find any security issues in the document and the security
considerations section looks good.


--000000000000dd351905d2853b91-- From nobody Mon Dec 6 20:19:14 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 680553A103A; Mon, 6 Dec 2021 20:19:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sean Turner via Datatracker To: Cc: draft-ietf-httpbis-http2bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163885075235.5076.15549152460730053106@ietfa.amsl.com> Reply-To: Sean Turner Date: Mon, 06 Dec 2021 20:19:12 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-httpbis-http2bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 04:19:13 -0000 Reviewer: Sean Turner Review result: Has Nits Ready with nits. And by nits I mean editorial nits. I could not think of anything security/privacy-related. BTW - this I-D was a pleasure to read. Thanks to everybody who made it that way. I read the GENART and TSVDIR reviews so I hopefully did not duplicate anything they raised. I will admit that I did not just focus on new text. If, as a result, I have unwittingly stumbled onto a hard fought WG consensus, then I do not want my questions/comments to be see as restarting that discussion. s3.3 (editorial): Even though s3 is clear that this section is about starting with http, I would have thought that the last sentence in para 2 would have been the very 1st sentence in the section to make that point very clear in case it missed in s3. s4.1 (editorial): s/Frames defined in this documented/ Frames defined in this document s4.1 (editorial): s/Implementations MUST ignore and discard any frame that has a type that is unknown./Implementations MUST ignore and discard frames of unknown types. s4.1 (editorial): s/Unused flags are those that have no defined semantics for a particular frame type, and MUST be ignored and MUST be left unset (0x0) when sending./Unused flags are those that have no defined semantics for a particular frame type; unused flags MUST be ignored and MUST be left unset (0x0) when sending. s4.3 (editorial): s/END_HEADERS flag cleared/END_HEADERS flag unset “unset” is used in s4.1. s5 (editorial): s/Streams can be established and used unilaterally or shared by either the client or server./Streams can be established and used unilaterally or shared by either endpoint. 5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be disabled, but in s5.2.2 you explain how to do exactly that. In s5.2.1, are you really saying you can’t skip implementing the flow control mechanism and frames related to connection control, i.e., WINDOW_UPDATE? s5.3 (compliment): I think this is a great way to describe deprecating features that did not work. s7 (question): Since we already have h3, is it worth adding an h3 required error? s8.3.1 (question): s8.3.1 includes this: The recipient of a HTTP/2 request MUST ignore the Host header field if :authority is present. And, it also includes this: A server SHOULD treat a request as malformed if it contains a Host header field that identifies a different entity to the :authority pseudo-header field. If I follow the MUST, then is the SHOULD ever followed? s9.2.1, last para, 1st sentence (editorial): Should the DHE suites reference [TLS13] or [TLS1.2] in the TLS1.2 section? s11 (confirmation, and I guess this is somewhat related to the last GENART comment): Because you obsolete RFC 7540 with this I-D, I am going with the assumption that the obsoleting is about the protocol and not about the registries. As a result, there’s no need to copy the IANA instructions for what’s in 7540 to this I-D. s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446? From nobody Mon Dec 6 22:12:46 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF63A1157; Mon, 6 Dec 2021 22:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Ny1Nioas; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nKEQ312D 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 xnXR5iMbftRG; Mon, 6 Dec 2021 22:12:26 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8681D3A1158; Mon, 6 Dec 2021 22:12:26 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 967715C01E8; Tue, 7 Dec 2021 01:12:25 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 07 Dec 2021 01:12:25 -0500 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 :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=CL WlqkRDeDWWVghiT2AGF9nKWI8wguDvHvQDPuotDFg=; b=Ny1NioasUaTYJJjhmN PdAE9l3TR+jFUsw7I/iWnTcZ79uIXVHc5iKdvq3+S5gyUxMjmpOUP/LsY04nqoBF 5vYwRKxa5vdJ52Zj7wjyz/KbUAa6c99FyrpjMu1rZeFuY22Nmga792ykwSH9Gz+E J7kvq8iOtFrwPOHZISh0v28lCMcbAYPuGRMFf5uoV4kMkAOQD8iYs2ynyPeDSYdl T/H4uXZh2lBh0k8uIusUnoJBZfXiFgc43M6E511idyzDnqGuKGC5CuSVlMMRtAUp PiZxoCxwFrUWSE66bjm8AAnZS7hn4y/nAJfwhEHN38CQn/fz9IbgjlXVUCOPTbQg E3NQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=CLWlqkRDeDWWVghiT2AGF9nKWI8wguDvHvQDPuotD Fg=; b=nKEQ312D690G4iEswsBjGIybRnwfeBS92lz03qofsVvwGtp8JgPFmyXoB F7kKuCfHPkoJZ7iEIG9DRtEFLSF7P74VglY5QnTmU3Yzb9bAikqZ0ZYtkr+rBosU gahLTnS/wp3wgzm4oDmHVX6IhjYGWXofs8AiY8S2p4QJmuUIpOuG5oFA/qgn4qQ/ ISbYsS69EjVl8dl8hLx6h35bUujf0DXNOP69xxCekt1J7yzgTgRsus+EFH5eEvOZ G/5UyEMCl9dtbs7BtMuQu9vxdn/D9jXNXlefA+mdLRUcvLBK2KSYu4TTEUudm4WN qQFuypz1X6eL+HOIJmljzbye4Hs0g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeggdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepjefhffelheevudefjeefvddvhfdvieetudehueffudevudeugeel feffffelvdefnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4D3663C0246; Tue, 7 Dec 2021 01:12:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4492-g121c2470aa-fm-20211206.001-g121c2470 Mime-Version: 1.0 Message-Id: <2ba1e1fd-ce3b-4411-a155-6ee05537b935@www.fastmail.com> In-Reply-To: <163885075235.5076.15549152460730053106@ietfa.amsl.com> References: <163885075235.5076.15549152460730053106@ietfa.amsl.com> Date: Tue, 07 Dec 2021 17:12:05 +1100 From: "Martin Thomson" To: "Sean Turner" , secdir@ietf.org Cc: draft-ietf-httpbis-http2bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-http2bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 06:12:32 -0000 Hey Sean, Most of your changes are pretty straightforward and easy to address. T= hanks for the review. You can review the changes I'm proposing here: https://github.com/httpwg= /http2-spec/pull/1001 On Tue, Dec 7, 2021, at 15:19, Sean Turner via Datatracker wrote: > s3.3 (editorial): Even though s3 is clear that this section is about s= tarting > with http, I would have thought that the last sentence in para 2 would= have > been the very 1st sentence in the section to make that point very clea= r in case > it missed in s3. Yeah, this is a little buried. At the same time, I do somewhat like the= natural flow that this text has. The pull request above tries to pull = out the important piece, but I'm not sure that I made it better in the p= rocess. We'll kick it around some. > 5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be disab= led, but > in s5.2.2 you explain how to do exactly that. In s5.2.1, are you reall= y saying > you can=E2=80=99t skip implementing the flow control mechanism and fra= mes related to > connection control, i.e., WINDOW_UPDATE? Good question. I've clarified by saying that endpoints have to respect = flow control set by their peer, even though they can opt out of setting = limits of their own. The original was incorrect-ish, but I was never mo= tivated to fix it before. > s7 (question): Since we already have h3, is it worth adding an h3 requ= ired > error? I don't think we need it for various reasons, mostly because HTTP/1.1 is= very much lowest common denominator, from which we can kick off Alt-Svc= and other stuff. We've discussed various options in this space and we = continue to have those discussions, but I don't get the impression that = the HTTP11_REQUIRED thing is anything more than safety valve. > s8.3.1 (question): s8.3.1 includes this: > > The recipient of a HTTP/2 request MUST ignore > the Host header field if :authority is present. > > And, it also includes this: > > A server SHOULD treat a request as malformed if > it contains a Host header field that identifies a > different entity to the :authority pseudo-header field. > > If I follow the MUST, then is the SHOULD ever followed? The MUST was not intended to be so broad; it's OK to validate as well. = What we don't want to see is the Host header field being used to determi= ne the target URI. I've narrowed it some (hopefully not too much). > s11 (confirmation, and I guess this is somewhat related to the last GE= NART > comment): Because you obsolete RFC 7540 with this I-D, I am going with= the > assumption that the obsoleting is about the protocol and not about the > registries. As a result, there=E2=80=99s no need to copy the IANA inst= ructions for > what=E2=80=99s in 7540 to this I-D. Yeah, I don't know that we're ever going to get this right, but I think = that we can rely on what is in the registries already and save making an= other copy. FWIW, IANA got the changes absolutely right first time, so = I don't think this is going to produce a bad result. It's just a bit od= d, that's all. > s12.1 (question): Is it worth referring to 8446bis instead of RFC 8446? I am not sure that I want to wait behind that. As that particular chang= e is easy, it's something we can do if the stars align at any time befor= e AUTH48, so I've been putting off that decision in the hopes that we ca= n go out together. Of course, I was hoping that this could go out with = HTTP/3 and all the other HTTP docs, but that opportunity seems to have p= assed. Thanks, Martin From nobody Wed Dec 8 12:46:58 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABBF3A0B5E for ; Wed, 8 Dec 2021 12:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 H3HL_GfZmoeH for ; Wed, 8 Dec 2021 12:46:41 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 F0DFC3A09BD for ; Wed, 8 Dec 2021 12:46:40 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id z9so3380296qtj.9 for ; Wed, 08 Dec 2021 12:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ggac4QKpiGsZDxmCn+GzgHyQ1OcS1d8A9LapO/QUD5s=; b=agW+OY2PUdj0d4YuM4Q0VEmiij+jiIR3Ln9mJrm+HYx4QS67ZJG0AlXlW0qzstfsZ5 Xv0jvFYfoBq3uoAm2Xggo1eKu4H4cLzxMZV5vdX9F/0FXYiLCyLNkGcREYnkntl6q0C+ 9oUp9sRfNEhLJZaff2pJR6+G/lSuKWG62G7qU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ggac4QKpiGsZDxmCn+GzgHyQ1OcS1d8A9LapO/QUD5s=; b=OlhUxDKw02GZBmObV5t+lvLkpfNDTLFQ7Zw5dq6zHrtENjgJ0By4LSwy8Sptat+LPQ qx9XYsKbwwwdEOgJEQnQcPojzXnVslieXucrUdo0To4tYPKPDL9DM4SL6hVu2cYbMQoJ hYJntknQfkQq9F4vqWqDCxSznYNfWkAvGnMGeDlASbBN2EviHSBWmYtPlM/RT7d9bqfG 2IzySokCa9Qm9oFg7S/c/qJuTlN16sF+2BNqXWyJTlt6lWa9ewALfnYOYWoOmAOg9uUN 1duYvNuM5oTBOhdU65OcaPKSHZs7M3bO1mklqOc5du92DOw51Jfi1q0BUSp4Sjm4qVi6 OO5w== X-Gm-Message-State: AOAM533Nvr1nVrpN+bxRAbmi5NfDXBoTxhBcqbtOFa1hYAZGAdF4rN+F uw4zigVEIyKUBCVGbTvhR9/2YKSUmw9ToA== X-Google-Smtp-Source: ABdhPJwcJHOaGzcCN/FYFyZsVXFhdq7jvm6THaFY7sCIkfI83ErJMhKwGhAuxEZBhduBlTeYaTMZew== X-Received: by 2002:ac8:5982:: with SMTP id e2mr11136854qte.530.1638996399400; Wed, 08 Dec 2021 12:46:39 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id j22sm2074479qko.68.2021.12.08.12.46.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Dec 2021 12:46:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: <2ba1e1fd-ce3b-4411-a155-6ee05537b935@www.fastmail.com> Date: Wed, 8 Dec 2021 15:46:38 -0500 Cc: secdir@ietf.org, draft-ietf-httpbis-http2bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163885075235.5076.15549152460730053106@ietfa.amsl.com> <2ba1e1fd-ce3b-4411-a155-6ee05537b935@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-httpbis-http2bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 20:46:47 -0000 Martin, Perfectly fine with how you resolved all of these. Cheers, spt > On Dec 7, 2021, at 01:12, Martin Thomson wrote: >=20 > Hey Sean, >=20 > Most of your changes are pretty straightforward and easy to address. = Thanks for the review. >=20 > You can review the changes I'm proposing here: = https://github.com/httpwg/http2-spec/pull/1001 >=20 > On Tue, Dec 7, 2021, at 15:19, Sean Turner via Datatracker wrote: >> s3.3 (editorial): Even though s3 is clear that this section is about = starting >> with http, I would have thought that the last sentence in para 2 = would have >> been the very 1st sentence in the section to make that point very = clear in case >> it missed in s3. >=20 > Yeah, this is a little buried. At the same time, I do somewhat like = the natural flow that this text has. The pull request above tries to = pull out the important piece, but I'm not sure that I made it better in = the process. We'll kick it around some. >=20 >> 5.2.1/s5.2.2 (question): s5.2.1 indicates flow control cannot be = disabled, but >> in s5.2.2 you explain how to do exactly that. In s5.2.1, are you = really saying >> you can=E2=80=99t skip implementing the flow control mechanism and = frames related to >> connection control, i.e., WINDOW_UPDATE? >=20 > Good question. I've clarified by saying that endpoints have to = respect flow control set by their peer, even though they can opt out of = setting limits of their own. The original was incorrect-ish, but I was = never motivated to fix it before. >=20 >> s7 (question): Since we already have h3, is it worth adding an h3 = required >> error? >=20 > I don't think we need it for various reasons, mostly because HTTP/1.1 = is very much lowest common denominator, from which we can kick off = Alt-Svc and other stuff. We've discussed various options in this space = and we continue to have those discussions, but I don't get the = impression that the HTTP11_REQUIRED thing is anything more than safety = valve. >=20 >> s8.3.1 (question): s8.3.1 includes this: >>=20 >> The recipient of a HTTP/2 request MUST ignore >> the Host header field if :authority is present. >>=20 >> And, it also includes this: >>=20 >> A server SHOULD treat a request as malformed if >> it contains a Host header field that identifies a >> different entity to the :authority pseudo-header field. >>=20 >> If I follow the MUST, then is the SHOULD ever followed? >=20 > The MUST was not intended to be so broad; it's OK to validate as well. = What we don't want to see is the Host header field being used to = determine the target URI. I've narrowed it some (hopefully not too = much). >=20 >> s11 (confirmation, and I guess this is somewhat related to the last = GENART >> comment): Because you obsolete RFC 7540 with this I-D, I am going = with the >> assumption that the obsoleting is about the protocol and not about = the >> registries. As a result, there=E2=80=99s no need to copy the IANA = instructions for >> what=E2=80=99s in 7540 to this I-D. >=20 > Yeah, I don't know that we're ever going to get this right, but I = think that we can rely on what is in the registries already and save = making another copy. FWIW, IANA got the changes absolutely right first = time, so I don't think this is going to produce a bad result. It's just = a bit odd, that's all. >=20 >> s12.1 (question): Is it worth referring to 8446bis instead of RFC = 8446? >=20 > I am not sure that I want to wait behind that. As that particular = change is easy, it's something we can do if the stars align at any time = before AUTH48, so I've been putting off that decision in the hopes that = we can go out together. Of course, I was hoping that this could go out = with HTTP/3 and all the other HTTP docs, but that opportunity seems to = have passed. >=20 > Thanks, > Martin From nobody Wed Dec 8 21:14:14 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D4B3A0E49 for ; Wed, 8 Dec 2021 21:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 D1EteRsnUyr6 for ; Wed, 8 Dec 2021 21:14:08 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 09EBD3A0E4A for ; Wed, 8 Dec 2021 21:14:07 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id t11so4338028qtw.3 for ; Wed, 08 Dec 2021 21:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7d1Fr5OPGHl6B85vKafkJKyJRdDbNzrCgNoWlno9DOk=; b=KYzcLIcX5rCzct2qz0VJs9wNSZ0ZrPWKm83ay/FJWL7gK21TVmQoqOr1gxF3+EGIdy 4DaC929RROsq7nfRaO7o9N0QvCUxn5SfMzcEqWzVEyzCaY+m4+D0V67+frTNgkBYIivT f+xcG2dWzxq7T+BmEtnu8Ga/oqgks65vpHxsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7d1Fr5OPGHl6B85vKafkJKyJRdDbNzrCgNoWlno9DOk=; b=6LeAvpSpja1bddCWT8kvOQsqL4vBxB79yn/1bPmuRQv9AgGyp2pT3mqalCxcNfMjSu R1Ao1VK4/tKJdxO937AI+dpFD8k53Vql2STpWbmeLdR3NC1UB+B2aw3lAjUmLx2d1Uxe RcSRH+y3wQNRd0JSFwkd3MOJXpcuWkIXre9GNw4y6rXFm6IHzzPcldJ8ibmX5K3+nC7/ nwArRiBa9BiAwXg9U/XVeQdqu0P6PYhw4zeS1KGA3Ksu/Ema+9E4yWQwgYltUSKrrIpF dYIT9crwdYuPLEkjg2vfxhGltCnW6Jo7sehOKTg3koTy6pKxyCsPtabHnzy7x1SLWzVm yIAw== X-Gm-Message-State: AOAM533k6spx8HhV9RsDQ90I6C8whMZ6YbpZTmzpyuOWt26JVbG8WHaY 46083IEN1qYTPsVgZHkE8cYdEGUz3sBbdQ== X-Google-Smtp-Source: ABdhPJyGYBCNi/3aXiSPCHhgsYFkbRyKzfZvmLUz7E+Z0LqrT6alwQatgqUspWsi7Gug2UxfBsbA2w== X-Received: by 2002:a05:622a:11c9:: with SMTP id n9mr14289189qtk.385.1639026845635; Wed, 08 Dec 2021 21:14:05 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id i23sm2406372qkl.101.2021.12.08.21.14.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Dec 2021 21:14:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: <163469775639.5436.17223656477070371812@ietfa.amsl.com> Date: Thu, 9 Dec 2021 00:14:03 -0500 Cc: secdir@ietf.org, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <163469775639.5436.17223656477070371812@ietfa.amsl.com> To: draft-ietf-taps-interface.all@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-taps-interface-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 05:14:13 -0000 I went ahead and submitted Issues/PRs for these. Note that some were addressed by other merged PRs, some I reconsidered = and withdrew as comments, and some I revised after re-reading them. = And, I came up with a new one about whether the PSK modes need to be = included in s6.3.1: https://github.com/ietf-tapswg/api-drafts/issues/999 Cheers, spt > On Oct 19, 2021, at 22:42, Sean Turner via Datatracker = wrote: >=20 > Reviewer: Sean Turner > Review result: Has Issues >=20 > This is an early sector review. Based on the ARTART early reviews of = this I-D > and the -arch I-D, there is no doubt going to need to be another = review after > the authors get done restructuring both I-Ds. >=20 > BTW: Theresa thank you for the heads up about that restructuring. It = forced me > to read the -arch and -impl I-Ds, but that probably helped me not make = silly > requests of the authors/WG. >=20 > tl;dr: I picked "has issues" knowing there is a rewrite on the way and = I would > like to reserve final judgement until then. >=20 > I apologize upfront because I am going to ramble a bit before I get to = the > specifics: >=20 > The taps I-Ds are about =E2=80=9Ca protocol-independent Transport = Services Application > Programming Interface (API).=E2=80=9D I took a pretty liberal approach = when reviewing > this I-D from a security perspective because these I-Ds are somewhat = different > than the =E2=80=9Cnormal=E2=80=9D protocol I-Ds. As noted in the -arch = I-D: these I-Ds do not > specify =E2=80=9Cspecific protocols or algorithms=E2=80=9D =E2=80=A6 = gasp. But, that=E2=80=99s probably okay in > this context. >=20 > I wondered what you would say about an API: > - Apps need to use the API properly! check: see -arch I-D > - Implementation/Library needs to be from trust source! check: see = -interface > I-D - Apps need to use the right keys at the right time! check: see = -arch I-D - > Avoid fallback/downgrade to insecure protocols! check: see -arch I-D = and -impl > I-D - Deal with 0-RTT! check: see -impl I-D - Address privacy aspects! = check: > see -interface I-D >=20 > I mean maybe you could add something about: >=20 > - randomness for keys - but that better already be in the security = protocol > specifications so I do not think it is absolutely needed here. >=20 > - following good programming techniques - but I am not sure where you = would > point nor whether it really makes sense to do so. >=20 > I think I found what I was looking for is somewhere in the stack of = I-Ds. Am I > worried somebody can implement this wrong. Sure. But, not any more = than I would > be for any other protocol. >=20 > Now on to the specifics: >=20 > NOTE: I tried not repeat anything from the ARTART review. >=20 > 0) s6: maybe this wording would be better? >=20 > For these two sentences are you trying to say that MUST else if? >=20 > OLD: At least one Local Endpoint MUST be specified if the = Preconnection is > used to Listen() for incoming Connections, but the list of Local > Endpoints MAY be empty if the Preconnection is used to Initiate() > connections. >=20 > NEW: At least one Remote Endpoint MUST > be specified if the Preconnection is used to Initiate() Connections, > but the list of Remote Endpoints MAY be empty if the Preconnection = is > used to Listen() for incoming Connections https://github.com/ietf-tapswg/api-drafts/issues/973 > 1) s6.3.1 I know this is an example, but can we replace: >=20 > SecurityParameters.Set(supported-group, "secp256k1") >=20 > with >=20 > SecurityParameters.Set(supported-group, "secp256r1") >=20 > r1 the current MTI for TLS. k1 is for bitcoin :) >=20 > Or, is this where I get a bitcoin because I caught the shiny object? = :) https://github.com/ietf-tapswg/api-drafts/issues/975 > 2) s6.3.2: Is this like checking the certificate status? https://github.com/ietf-tapswg/api-drafts/issues/977 > 3) s8.1.1- I read this definition a bunch. Are there two special = values? The > Type line says =E2=80=9CFull Coverage=E2=80=9D is special, but then = the description says =E2=80=9C0=E2=80=9D is > special too. Maybe look at s91.3.6 for inspiration? https://github.com/ietf-tapswg/api-drafts/issues/978 > 4) s8.1.2: Any reason it=E2=80=99s not called connPriority? Seems = arbitrary to drop the > end of the word when connTimeout is even longer. https://github.com/ietf-tapswg/api-drafts/issues/979 > 5) s8.1.2-should =E2=80=9CType=E2=80=9D line also include = (non-negative) like s8.1.1 and > s9.1.3.2 do? https://github.com/ietf-tapswg/api-drafts/issues/981 > 6) s8.1.3/.4: The Numeric values specifies seconds, minutes, hours, or > millennia? https://github.com/ietf-tapswg/api-drafts/issues/983 > 7) s8.1.6: don=E2=80=99t you need to specify the Type? I guess = Enumeration is what > you=E2=80=99re after? https://github.com/ietf-tapswg/api-drafts/issues/984 > 8) s8.1.11.2/.3/.4: Are these sizes in bytes too like 8.1.11.1? https://github.com/ietf-tapswg/api-drafts/issues/986 > 9) s8.2.1: RFC 5482 allows granularity of minutes or seconds don=E2=80=99= t you need to > say which it is here? https://github.com/ietf-tapswg/api-drafts/issues/988 > 10) s8.2.2: Is there some reason it=E2=80=99s not called = tcp.userTimeoutEnabled? https://github.com/ietf-tapswg/api-drafts/issues/989 > 11) s8.2.3: Is there some reason it=E2=80=99s not called = tcp.userTimeoutChangable? https://github.com/ietf-tapswg/api-drafts/issues/991 > 12) s9.1.3.2: Why 100? https://github.com/ietf-tapswg/api-drafts/issues/993 > 13) s9.1.3.2: Why shorten to msrPrio when msgOrdered is almost as long = and > safelyReplayable is longer? https://github.com/ietf-tapswg/api-drafts/issues/994 > 14) A.1: Could the caution about freeing memory be generalized? https://github.com/ietf-tapswg/api-drafts/issues/996 > 15) What follows are the I-D nits references to check. Some of these = might be > on purpose: >=20 > =3D=3D Outdated reference: A later version (-11) exists of > draft-ietf-taps-arch-10 >=20 > ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) >=20 > =3D=3D Outdated reference: A later version (-06) exists of > draft-ietf-httpbis-priority-03 >=20 > =3D=3D Outdated reference: A later version (-10) exists of > draft-ietf-taps-impl-09 >=20 > -- Obsolete informational reference (is this intentional?): RFC 5245 > (Obsoleted by RFC 8445, RFC 8839) >=20 > -- Obsolete informational reference (is this intentional?): RFC 5766 > (Obsoleted by RFC 8656) https://github.com/ietf-tapswg/api-drafts/issues/997 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview From nobody Fri Dec 10 18:38:03 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA33A079C; Fri, 10 Dec 2021 18:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2UZBJcdjg6vD; Fri, 10 Dec 2021 18:37:56 -0800 (PST) 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 E56853A0793; Fri, 10 Dec 2021 18:37:54 -0800 (PST) Received: from 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 1BB2biEO009571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Dec 2021 21:37:50 -0500 Date: Fri, 10 Dec 2021 18:37:43 -0800 From: Benjamin Kaduk To: Yaron Sheffer Cc: Kent Watsen , "draft-ietf-netconf-sztp-csr.all@ietf.org" , IETF SecDir Message-ID: <20211211023743.GO11486@mit.edu> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> <0100017d8302a1ac-1b711386-b799-416b-99b5-4e68fceca3d0-000000@email.amazonses.com> <21D42DFF-02A0-F141-B59B-4E4E54C12934@hxcore.ol> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21D42DFF-02A0-F141-B59B-4E4E54C12934@hxcore.ol> Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 02:38:01 -0000 Yes, thanks to Kent and Russ, and also thank you Yaron for the review and follow-up! -Ben On Sat, Dec 04, 2021 at 01:58:10PM +0200, Yaron Sheffer wrote: > I am good with the latest text. Thank you Kent and Russ! > > > > Yaron > > > > From: Kent Watsen > Date: Saturday, December 4, 2021 at 03:15 > To: Yaron Sheffer > Cc: IETF SecDir , > draft-ietf-netconf-sztp-csr.all@ietf.org > , last-call@ietf.org > , netconf@ietf.org > Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 > > > > Hi Yaron, > > > > Please see below for some responses to your comments. > > > > I did also just post -12 including these changes: > > https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-12.html > > Here's a direct link to the diffs (note: Opsdir and Gendir comments are > also included): > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-12 > > > > Kent (and Russ and Sean) > > > > > > > > On Nov 28, 2021, at 3:22 PM, Yaron Sheffer > wrote: > > > > In the third point below (certificate rotation), I understand why the > editors see it as out of scope. But we are still leaving implementers > with no guidance, and we've all seen enough real world cases where this > leads to people ignoring the vague "regenerate the private key". Let me > try to offer an alternative. > > > > Old: > > > > In cases where the SZTP-client does not possess an HSM, or otherwise is > unable to use an HSM for the private key, it is RECOMMENDED to > regenerate the private key (and associated identity certificates) > periodically. Details for how to generate a new private key and > associate a new identity certificate are outside the scope of this > document. > > > > New: > > > > In cases where the SZTP-client does not possess an HSM, or otherwise is > unable to use an HSM for the private key, it is RECOMMENDED to > regenerate the private key (and associated identity certificates) > periodically. If CMP or CMC was used for initial certificate > provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for > periodic certificate registration. Similarly, implementations SHOULD > also reuse the initial origin authentication method. > > > > > > Russ writes: > > > > Perhaps the word "regenerate" is the thing that is causing confusion. > > Suggestion: > > > > In cases where the SZTP-client does not possess an HSM, or otherwise is > unable to use an HSM for the private key, it is RECOMMENDED that the > device periodically reset the configuration to the factory default and > repeat the SZTP protocol. Repeating the SZTP protocol may cause the > device to generate a fresh private key (and associated identity > certificates). Details for how to generate a new private key and > associate a new identity certificate are outside the scope of this > document. > > > > > > To which you replied: > > > > I'm really surprised that a factory reset is the right thing to do in > this use case. But you are the expert. > > The new text works for me. > > Yaron > > > > > > As the originator of the OLD text, I have the following comments: > > 1) it is not uncommon to find new devices without an HSM or devices with > an HSM that is only used as a source of entropy (not key protection). So > saying something to address these implementations seems prudent. > > 2) There's no reason to call out CMP/CMS. P10 also works, and note that > the YANG in the draft is extensible to allow new formats to be introduced > over time. > > > > 3) The protocol as a whole is intended to move a device from an > "unmanaged" state to a "managed" state. That is, SZTP would no longer be > in play, as the only management connections would be, e.g., NETCONF or > RESTCONF. Once in the device is in the managed state, "normal" ongoing > management mechanisms are expected to be utilized. We can hope that the > mechanisms include periodically prompting the device to regen its key and > a reissuance of an LDevID, but details are out of scope to this draft. > > 4) One case I'm aware of where a device runs the SZTP protocol throughout > its lifecycle is when a device is deployed in a physically insecure > location (think: a kiosk in an airport) whereby, to thwart inadvertent > disclosure of networking settings from a slash-and-grab, the entirety of > the device's config is stored in memory (not on disk). As such, every > time power is lost, the device automatically reverts to its factory > default state and, when power is restored, must run the SZTP protocol to > join the network and be provisioned with configuration. The draft > addresses this case with statement "It is RECOMMENDED that a new private > key is generated for each CSR described in this document." > > > > The net-net of all this is the following: > > > > NEWEST: > > > > In cases where the SZTP-client does not possess an HSM, or is unable > to use an HSM to protect the private key, it is RECOMMENDED to > periodically reset the private key (and associated identity > certificates) in order to minimize the lifetime of unprotected > private keys. For instance, an NMS controller/orchestrator > application could periodically prompt the SZTP-client to generate a > new private key and provide a certificate signing request (CSR) or, > alternatively, push both the key and an identity certificate to the > SZTP-client using, e.g., a PKCS #12 [RFC7292]. In another example, > the SZTP-client could be configured to periodically reset the > configuration to its factory default, thus causing removal of the > private key and associated identity certificates and reexecution of > the SZTP protocol. > > > > Good? > > > > [more below] > > > > > > Thanks, > > Yaron > > > > > > > > From: Russ Housley > Date: Sunday, November 28, 2021 at 20:10 > To: Yaron Sheffer > Cc: Kent Watsen , IETF SecDir > , draft-ietf-netconf-sztp-csr.all@ietf.org , last-call@ietf.org , netconf@ietf.org > Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 > > Yaron: > > > > > > Thank you for addressing my comments, I am happy with most of your > responses but I do have a few remaining questions: > > > > . The commit that removes the dependency on IDevID and > LDevID does not fix the issue of non-orthogonality. There is very > detailed description for CMP and CMC, but nothing for PKCS #10 > (p10-csr). Does it mean "use PKCS#10 out of the box and it'll just > work"? Or does it mean "the usage of PKCS#10 for these certs is > still TBD"? > > > > PKCS#10 is pretty simple. Are you aware of anything more that ought > to be said? > > > > I think we should explicitly mention what this method *cannot* > provide. As far as I can tell, none of the origin authentication > methods are available when using PKCS #10 directly without wrapping it > further. > > > > That is reasonable. I will talk with my co-authors and see if we can > come up with a brief summary. > > > > > > One reason why the description statement in the "case p10-csr" node is so > small is because that node (unlike "case cmc-csr" and "case cmp-csr") uses > the following typedef from the "crypto-types" draft (i.e. type ct:csr): > > typedef csr { > type binary; > description > "A CertificationRequest structure, as specified in > RFC 2986, encoded using ASN.1 distinguished encoding > rules (DER), as specified in ITU-T X.690."; > reference > "RFC 2986: > PKCS #10: Certification Request Syntax Specification > Version 1.7 > ITU-T X.690: > Information technology - ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), > Canonical Encoding Rules (CER) and Distinguished > Encoding Rules (DER)."; > } > > That is, the description for how the p10 is encoded on-the-wire is defined > elsewhere, and not duplicated here. To address your primary point, as > well as the point just mentioned, how about this? > > OLD: > case p10-csr { > leaf p10-csr { > type ct:csr; > description > "A CertificationRequest structure, per RFC 2986."; > reference > "RFC 2986: PKCS #10: Certification > Request Syntax Specification"; > } > } > > NEW: > > case p10-csr { > leaf p10-csr { > type ct:csr; > description > "A CertificationRequest structure, per RFC 2986. > Encoding details are defined in the 'ct:csr' > typedef defined in RFC AAAA. > > A raw P10 does not support origin authentication in > the CSR structure. External origin authentication > may be provided via the ZTP-client's authentication > to the ZTP-server at the transport layer (e.g., TLS)."; > reference > "RFC 2986: PKCS #10: Certification Request Syntax > Specification > RFC AAAA: YANG Data Types and Groupings for > Cryptography"; > } > } > > > > > > Good? > > > > > > . I suggest to add the following reference to the paragraph > on quality randomness, as a strong proof that this is a real world > concern: > > > > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining > Your Ps and Qs: Detection of Widespread Weak Keys in Network > Devices", Proceedings of the 21st USENIX Security Symposium , August > 2012, . > > > > In another thread, something like this was suggested for another > document: > > > > Implementations must randomly generate nonces and private keys. > > The use of inadequate pseudo-random number generators (PRNGs) to > > generate cryptographic keys can result in little or no security. An > attacker > > may find it much easier to reproduce the PRNG environment that > > produced the keys, searching the resulting small set of > possibilities, > > rather than brute force searching the whole key space. As example > for > > predictable random numbers see CVE-2008-0166 [...]. The generation > > of quality random numbers is difficult. ISO/IEC 20543:2019 [...], > > NIST SP 800-90A Rev.1 [...], BSI AIS 31 V2.0 [...], BCP 106 > [RFC4086], and > > others offers valuable guidance in this area. > > > > If this approach works for you, we'll dig up the appropriate > references. > > > > Yes, but the Heninger et al. reference is a better fit than the Debian > CVE because (1) it discusses network devices rather than servers and > (2) it shows how even less broken RNGs can be exploited by a network > attacker that only sees the public keys. > > > > I just read the Abstract of the paper, and I see your point about the > attacker only observing the public keys. How about: > > > > > > Implementations must randomly generate nonces and private keys. > > The use of inadequate pseudo-random number generators (PRNGs) to > > generate cryptographic keys can result in little or no security. An > attacker > > may find it much easier to reproduce the PRNG environment that > > produced the keys, searching the resulting small set of > possibilities, > > rather than brute force searching the whole key space. As an example > of > > predictable random numbers see CVE-2008-0166 [...], and some > consequences > > of low-entropy random numbers are discussed in Mining Your Ps and Qs > [...]. > > The generation of quality random numbers is difficult. ISO/IEC > 20543:2019 [...], > > NIST SP 800-90A Rev.1 [...], BSI AIS 31 V2.0 [...], BCP 106 > [RFC4086], and > > others offers valuable guidance in this area. > > > > > > The final text reads: > > > > Implementations must randomly generate nonces and private keys. The > use of inadequate pseudo-random number generators (PRNGs) to generate > cryptographic keys can result in little or no security. An attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of > possibilities, rather than brute force searching the whole key space. > As an example of predictable random numbers see CVE-2008-0166 > [CVE-2008-0166], and some consequences of low-entropy random numbers > are discussed in Mining Your Ps and Qs [MiningPsQs]. The generation > of quality random numbers is difficult. [ISO.20543-2019], > [NIST.SP.800-90Ar1], BSI AIS 31 [AIS31], BCP 106 [RFC4086], and > others offer valuable guidance in this area. > > Good? > > > > > > > > . I understand that key generation is out of scope and maybe > this needs to be a separate work item, but recommending periodic > replacement of the certs without recommending a suitable mechanism > leaves this solution with a big hole. > > > > I do not agree. It does offer the protocol for obtaining replacement > certificates for devices that are able to generating a fresh > public/private key pair. Getting more detailed would be algorithm > specific, which is not appropriate in this document. > > > > Not really, because the "protocol" described here is: Client sends a > CSR, Server responds with a complete client configuration blob. This > obviously doesn't work for an already deployed client. > > > > I am really confused. The document is an addition to the Secure Zero > Touch Provisioning (SZTP). As such, it is technique to securely > provision a networking device when it is booting in a factory-default > state. That should happen at the initial deployment or after the device > is reset to the factory configuration. This is not the protocol for use > with an already deployed client. > > > > > > [the response for this "third point" is at the top of this email.] > > > > > > > > Kent, on behalf of the authors > > > > > > > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Sat Dec 11 00:28:56 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 375BB3A0A1E for ; Sat, 11 Dec 2021 00:28:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163921133319.27248.6385859655955371061@ietfa.amsl.com> Date: Sat, 11 Dec 2021 00:28:53 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 08:28:54 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview For telechat 2021-12-16 Reviewer LC end Draft Rich Salz R2021-11-19 draft-ietf-tls-external-psk-guidance Yaron Sheffer R2021-11-23 draft-ietf-netconf-sztp-csr Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Alexey Melnikov R2021-12-17 draft-ietf-idr-bgp-open-policy Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Rich Salz R2021-11-19 draft-ietf-tls-external-psk-guidance Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Yaron Sheffer R2021-11-23 draft-ietf-netconf-sztp-csr Mališa Vučinić 2021-12-13 draft-ietf-anima-asa-guidelines Carl Wallace 2021-12-24 draft-ietf-quic-datagram Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2021-12-23 draft-ietf-httpbis-targeted-cache-control Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Liang Xia Dacheng Zhang John Bradley Nancy Cam-Winget Shaun Cooley Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell From nobody Sat Dec 11 06:35:02 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3493A089A; Sat, 11 Dec 2021 06:35:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163923330133.25390.15619360580796692604@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Sat, 11 Dec 2021 06:35:01 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-netconf-sztp-csr-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 14:35:01 -0000 Reviewer: Yaron Sheffer Review result: Ready The latest version addresses all my previous review's comments. From nobody Sat Dec 11 07:15:24 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 439D93A091C; Sat, 11 Dec 2021 07:15:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: draft-ietf-tls-external-psk-guidance.all@ietf.org, last-call@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163923572222.5743.13943101720568132784@ietfa.amsl.com> Reply-To: Rich Salz Date: Sat, 11 Dec 2021 07:15:22 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-tls-external-psk-guidance-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2021 15:15:22 -0000 Reviewer: Rich Salz Review result: Ready This draft addresses my only real concern, which was pointing out that using the MAC address as an identifier has issues. Thanks. I like the other changes, too. From nobody Sat Dec 11 17:41:02 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 464C73A05A0; Mon, 6 Dec 2021 13:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1638826135; bh=2wia7cS2GuG1fFZh2Gxy7C4aVJwr3J85CXc6Okm4rYk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=AtWdb+Zn3HzmNLaC5Enlbkv7Qf7rMTZIuPdlLIw9ePB3RdBpXHsLaxAMXO7ik94ML 66EovyNRYoEYNp5qzuiYDpABcA6qORP0ZOJQzpNsD2CwFEEA4OWWN7OMutmmqVLWPA naIsLs6pR18KWdLggECN6w5bnba6+ttzlTHn90g8= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Dec 6 13:28:49 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3EC3A05DC; Mon, 6 Dec 2021 13:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1638826129; bh=2wia7cS2GuG1fFZh2Gxy7C4aVJwr3J85CXc6Okm4rYk=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=MeHPrpMljHcpzHBFwHcR+Kv1/lydtp1PTg0KyHf+OrfF4jA+zHkREF++mVJZVOwDh fdk+401aIqXBh1KRYLSjjpjOCa/1ifu+wrilVd0x0M4gDGqON6Pd17pS3ucMGH9jsR C9UPg7tlm6xmibMDKYnMayOubytBomgeUfyGxMkk= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D08183A0039 for ; Mon, 6 Dec 2021 13:28:42 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <163882612283.32151.1252139008024384075@ietfa.amsl.com> Date: Mon, 06 Dec 2021 13:28:42 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 11 Dec 2021 17:41:00 -0800 Subject: [secdir] [new-work] WG Review: Software Updates for Internet of Things (suit) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 21:29:01 -0000 The Software Updates for Internet of Things (suit) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-12-15. Software Updates for Internet of Things (suit) ----------------------------------------------------------------------- Current status: Active WG Chairs: Dave Thaler David Waltermire Russ Housley Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: suit@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/suit Archive: https://mailarchive.ietf.org/arch/search/?email_list=suit Group page: https://datatracker.ietf.org/group/suit/ Charter: https://datatracker.ietf.org/doc/charter-ietf-suit/ Vulnerabilities in Internet of Things (IoT) devices have raised the need for a secure firmware update mechanism that is also suitable for constrained devices. Security experts, researchers, and regulators recommend that all IoT devices be equipped with such a mechanism. While there are many proprietary firmware update mechanisms in use today, there is no modern interoperable approach allowing secure updates to firmware in IoT devices. In June 2016, the Internet Architecture Board organized a workshop on 'Internet of Things (IoT) Software Update (IOTSU)', and RFC 8240 documents various requirements and challenges that are specific to IoT devices. A firmware update solution consists of several components, including: * A mechanism to transport firmware images to compatible devices. * A manifest that provides meta-data about the firmware image (such as a firmware package identifier, the hardware the package needs to run, and dependencies on other firmware packages), as well as cryptographic information for protecting the firmware image in an end-to-end fashion. * The firmware image itself. The SUIT WG is defining a firmware update solution (taking into account past learning from RFC 4108 and other proprietary firmware update solutions) that are usable on Class 1 (as defined in RFC 7228) devices, i.e., devices with ~10 KiB RAM and ~100 KiB flash. The solution may apply to more capable devices as well. The SUIT WG is not defining any new transport or discovery mechanisms, but may describe how to use existing mechanisms within the architecture. The SUIT WG has already completed work on two documents: * An IoT firmware update architecture. * An information model for the SUIT manifest. Now that the information model is complete, the SUIT WG has selected the CBOR serialization format and the associated COSE cryptographic mechanisms to encode the SUIT manifest. The SUIT WG may consider a small number of additional formats in the future; however, to reduce the complexity of a firmware management solution, a very small number of formats is preferred to enable SUIT maifest integration and interoperability with other IoT technologies and ecosystems. To support a wide range of deployment scenarios, the formats are expected to be expressive enough to allow the use of different firmware sources and permission models. To enable SUIT Status Tracker functionality (per RFC9019), the SUIT WG is also defining extensions to determine if a particular manifest could be successfully deployed to a device and determine if an operation was successful. In addition, the SUIT WG will work with the RATS WG to specify claims related to the SUIT Status Tracker that can be used to provide evidence in support of the RATS architecture. The SUIT WG will continue to work with silicon vendors and OEMs that develop IoT operating systems to produce implementations based on SUIT WG specifications. In particular, the SUIT WG plans to continue to participate in IETF Hackathons. The SUIT WG document deliverables are: * A SUIT manifest format specification using CBOR. * Extensions to the SUIT manifest for optional capabilities, including: - firmware encryption, - trust domains, - update management, and - inclusion of a file in the MUD format (RFC 8520). * A secure method for an IoT device to report on firmware update status. In addition, either the SUIT WG or the RATS WG will produce: * A set of claims for attesting to firmware update status. Milestones: Dec 2021 - Adopt SUIT Manifest update management document as WG item Dec 2021 - Adopt SUIT Manifest trust domains document as WG item Dec 2021 - Adopt SUIT Manifest MUD extension document as WG item Mar 2022 - Decide with RATS WG in which working group the 'set of claims for attesting to firmware update status' document should be produced Aug 2022 - Submit firmware encryption document to the IESG for publication as a Proposed Standard Sep 2022 - Submit SUIT Status Tracker document to the IESG for publication as a Proposed Standard Nov 2022 - Submit SUIT Manifest update management document to the IESG for publication as a Proposed Standard Nov 2022 - Submit SUIT Manifest trust domains document to the IESG for publication as a Proposed Standard Dec 2022 - Submit SUIT Manifest MUD extension document to the IESG for publication as a Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Dec 15 21:20:24 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F983A0DE3; Wed, 15 Dec 2021 21:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1639631909; bh=8m6MWLuVX5HP1ipt1R/dXQDDjnwzmRbqvGBzdqgtfsY=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=bXL8XhtjI3SSvjynxHcP+jJ0PSuJCeN/4uca79vVvyGz7HdrQKX9qyD0kDPDdl6cB ka+fOZncIRc9fpgvx3TuBagN+Zf875UfryI5ncSnSBlumNPef2AIm0gEd5iiyEkZU6 bwYFHiOCy1nG9TES4uWvbTftua1ONa9lw/PHtKdQ= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Dec 15 21:18:28 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC113A0DDD; Wed, 15 Dec 2021 21:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1639631908; bh=8m6MWLuVX5HP1ipt1R/dXQDDjnwzmRbqvGBzdqgtfsY=; h=Date:To:From:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=nbMF6PXECequOxPLp67lZnO+ziXZV2QjuP5OSSgrIZ5OHF/MAuBzdsT/q6wCLSdtm wCjSm6ixboT5M5jjM+j30csSdMl640LRMeVY/X+HuBEuMrHu2DIMgumHgCJS2XdKBC neswUvrPf96E6U7SIh2QLq46POfnLdsb4yHJIRvo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C608A3A0DDD for ; Wed, 15 Dec 2021 21:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.559, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no 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 H6uc6-OK5SXm for ; Wed, 15 Dec 2021 21:18:23 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 358093A0DD9 for ; Wed, 15 Dec 2021 21:18:22 -0800 (PST) Received: from [194.5.48.220] (helo=[10.129.0.70]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mxj9o-0006Tj-Eb for new-work@ietf.org; Thu, 16 Dec 2021 05:18:20 +0000 Message-ID: <432fc72c-5a56-454d-3eea-e4f2cf16629a@w3.org> Date: Thu, 16 Dec 2021 13:18:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: new-work@ietf.org From: xueyuan Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 15 Dec 2021 21:20:22 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web of Things Interest Group (until 2022-01-24/25) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 05:18:33 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIFByb3Bvc2FsCnRvIHJldmlldyBhIGRyYWZ0IGNoYXJ0ZXIgZm9yIHRoZSBXZWIgb2Yg VGhpbmdzIEludGVyZXN0IEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMjEvMTIvd290 LWlnLTIwMjEuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMg YXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJs aWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZp dGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDA0OjU5IFVUQyBvbiAyMDIyLTAxLTI1CigyMzo1 OSwgQm9zdG9uIHRpbWUgb24gMjAyMi0wMS0yNCkgb24gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIuClBs ZWFzZSBzZW5kIGNvbW1lbnRzIHRvIHB1YmxpYy1uZXctd29ya0B3My5vcmcsCndoaWNoIGhhcyBh IHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cHM6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGlj L3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVz cG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fu bm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBX M0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIg QWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3 aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBB ZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3Ig aGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpUaGUgY3VycmVudCBjaGFydGVyIGlzIGhlcmVi eSBleHRlbmRlZCB1bnRpbCAzMSBNYXJjaCAyMDIyIHRvCmFjY29tbW9kYXRlIHRoZSBjaGFydGVy IHJldmlldyBwZXJpb2Q6Cmh0dHBzOi8vd3d3LnczLm9yZy8yMDE5LzEwL3dvdC1pZy0yMDE5Lmh0 bWwKCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZv cm1hdGlvbiwgcGxlYXNlCmNvbnRhY3QgS2F6dXl1a2kgQXNoaW11cmEsIFdlYiBvZiBUaGluZ3Mg SW50ZXJlc3QgR3JvdXAgVGVhbSBDb250YWN0LAphdCA8YXNoaW11cmFAdzMub3JnPi4KClRoYW5r IHlvdSwKClh1ZXl1YW4gSmlhLMKgIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFd IGh0dHBzOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QK bmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXctd29yawo= From nobody Thu Dec 16 03:23:56 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328A3A0C9D; Thu, 16 Dec 2021 03:23:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: Cc: draft-ietf-idr-bgp-open-policy.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163965382531.11053.17265990456702454292@ietfa.amsl.com> Reply-To: Alexey Melnikov Date: Thu, 16 Dec 2021 03:23:45 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-bgp-open-policy-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 11:23:46 -0000 Reviewer: Alexey Melnikov Review result: Ready Reviewer: Alexey Melnikov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I reviewed an earlier version of this document and found its Security Considerations to be adequate. Reading the new version I see that they are much improved and discuss various unintentional and malicious modifications in more details. I think the document is better for the new Security Considerations. From nobody Thu Dec 16 14:24:57 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A69C3A0D24 for ; Thu, 16 Dec 2021 14:24:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <163969349548.1348.4498933023494368004@ietfa.amsl.com> Date: Thu, 16 Dec 2021 14:24:55 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 22:24:56 -0000 Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Alan DeKok 2021-12-30 draft-ietf-sidrops-6486bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Mališa Vučinić 2021-12-13 draft-ietf-anima-asa-guidelines Carl Wallace 2021-12-24 draft-ietf-quic-datagram Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2021-12-23 draft-ietf-httpbis-targeted-cache-control Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Linda Dunbar 2022-01-31 draft-ietf-idr-rpd Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley From nobody Fri Dec 17 20:28:20 2021 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DD43A089B; Fri, 17 Dec 2021 10:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1639766529; bh=hL4R6OWay1m3tqH/HRVStRBoi4BunPrB/QQLmpnwQRs=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=ZEA3N50NiDQctX758rA3ccdhfUJW/00OEianvs5Y2ga1hUcoRkhpSL3gTUrQSeiMp iyAs4wv76qg4sZ/uQk6O/vjnNmz+BL3yRqvAtG8EtJD9iTFBg9NpCpIzhb5n1wVbDJ ihlpE4aCx6ZzA+m8oH4uLL5+defjye6PL2I49e8w= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Dec 17 10:42:00 2021 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1223A07E1; Fri, 17 Dec 2021 10:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1639766510; bh=hL4R6OWay1m3tqH/HRVStRBoi4BunPrB/QQLmpnwQRs=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=PeR9TVquEM1Caz8KJK2oG/uNH0G4pzP0sHCrp57dCEBEXPbWicSVX8ZlmhrWyzPol KvZLEHKaVPIrqxLnctTgLJ+dGCnlzRbnlcbLIMpCfnKHD3SK3+mtaDpJWOy37OZyNg sBmzAsAfSaqEaaotLzCHWHIiXj+BUCJHv4OuiSYo= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5413A07A2 for ; Fri, 17 Dec 2021 10:41:44 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <163976650448.10747.12895872627007352551@ietfa.amsl.com> Date: Fri, 17 Dec 2021 10:41:44 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 17 Dec 2021 20:28:19 -0800 Subject: [secdir] [new-work] WG Review: Secure Telephone Identity Revisited (stir) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 18:42:19 -0000 The Secure Telephone Identity Revisited (stir) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-12-27. Secure Telephone Identity Revisited (stir) ----------------------------------------------------------------------- Current status: Active WG Chairs: Ben Campbell Russ Housley Robert Sparks Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Mailing list: Address: stir@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: https://mailarchive.ietf.org/arch/browse/stir/ Group page: https://datatracker.ietf.org/group/stir/ Charter: https://datatracker.ietf.org/doc/charter-ietf-stir/ The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify and maintain a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will work on mechanisms for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. It is important to note that while the main focus of this working group is telephone numbers, the STIR working group will not develop any mechanisms that require changes to circuit-switched technologies. Moreover, the work of this group is limited to developing a solution for telephone numbers. Expansion of the authorization mechanism to identities using the user@domain or other name forms is out of scope. The group will also consider extensions that leverage STIR to solve related identity problems around telephone calls and other telephone-number based communication, including call diversion and forwarding, rich identity presentation for delivery to a called party, messaging that uses telephone numbers, connected identity (mechanisms that identify the called party reached to the calling party), and similar use cases related to fraud and security. The working group will coordinate with the Security Area on credential management and signature mechanics. The working group will coordinate with other working groups in the ART Area regarding signaling through existing deployments. The working group welcomes input from potential implementors or operators of technologies developed by this working group. For example, national numbering authorities might consider acting as credential authorities for telephone numbers within their purview. Authentication and authorization of identity is closely linked to privacy, and these security features sometimes come at the cost of privacy. Anonymous calls are already defined in SIP standards, and this working group will not propose changes to these standards. In order to support anonymity, the working group will provide a solution in which the called party receives an indication that the source telephone number is unavailable. This working group, to the extent feasible, will specify privacy-friendly mechanisms that do not reveal any more information to user agents or third parties than a call that does not make use of secure telephone identification mechanisms. Milestones: - Submit PASSPorT Extension for rich call data for publication as Proposed Standard - Submit Assertion Values for a Resource Priority Header Claim in Support of Emergency Services Networks as Proposed Standard - Submit STIR Certificate Delegation as Proposed Standard - Submit Privacy analysis for Informational _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Dec 22 10:52:48 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F17903A086F; Wed, 22 Dec 2021 10:52:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carl Wallace via Datatracker To: Cc: draft-ietf-quic-datagram.all@ietf.org, last-call@ietf.org, quic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164019915492.5710.15723155597958890951@ietfa.amsl.com> Reply-To: Carl Wallace Date: Wed, 22 Dec 2021 10:52:34 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-quic-datagram-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2021 18:52:35 -0000 Reviewer: Carl Wallace Review result: Ready This is a well written document. My only comments are likely due to my lack of familiarity with QUIC. 1) Section 5 states "this frame SHOULD be sent as soon as possible, and MAY be coalesced with other frames." It was not clear to me how this squared with Section 4's "if this bit is set to 0, the Length field is absent and the Datagram Data field extends to the end of the packet." Should the MAY be other packets instead of frames? Or is at most one datagram frame with no length present permitted in a packet, with it being last? 2) Section 3 may benefit from including words a la section 4.6.2 of RFC 9001 regarding resetting state when max_datagram_frame_size is rejected. On first read, it was not clear to me why this value did not latch. From nobody Thu Dec 23 11:30:56 2021 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7003A094D for ; Thu, 23 Dec 2021 11:30:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <164028785455.1189.17881487374892701631@ietfa.amsl.com> Date: Thu, 23 Dec 2021 11:30:54 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 19:30:55 -0000 No new assignments this week. Review instructions and related resources are at: https://trac.ietf.org/trac/sec/wiki/SecDirReview Last calls: Reviewer LC end Draft Shaun Cooley 2021-10-18 draft-ietf-jmap-smime Alan DeKok 2021-12-30 draft-ietf-sidrops-6486bis Aanchal Malhotra 2021-10-15 draft-ietf-kitten-tls-channel-bindings-for-tls13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer Stefan Santesson 2021-08-11 draft-ietf-bier-te-arch Mališa Vučinić 2021-12-13 draft-ietf-anima-asa-guidelines Brian Weis 2021-08-19 draft-ietf-dnsop-svcb-https Klaas Wierenga 2021-12-23 draft-ietf-httpbis-targeted-cache-control Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth Liang Xia 2021-09-07 draft-ietf-bess-evpn-igmp-mld-proxy Liang Xia 2021-03-17 draft-ietf-core-sid Dacheng Zhang 2021-09-07 draft-ietf-bess-evpn-bum-procedure-updates Early review requests: Reviewer Due Draft Linda Dunbar 2022-01-31 draft-ietf-idr-rpd Stephen Farrell 2021-09-15 draft-ietf-ippm-ioam-direct-export Stephen Farrell 2021-06-21 draft-ietf-idr-bgpls-srv6-ext Tina Tsou 2021-08-25 draft-ietf-opsawg-sbom-access Loganaden Velvindron 2021-08-18 draft-ietf-taps-arch Christopher Wood 2021-12-20 draft-ietf-opsawg-mud-iot-dns-considerations Next in the reviewer rotation: Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley