From nobody Tue Jul 14 22:02:05 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABEB3A0EEC for ; Tue, 14 Jul 2020 22:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_LOCAL_HEX=0.006, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 bAZfNlHJ9ecV for ; Tue, 14 Jul 2020 22:02:02 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255092.outbound.protection.outlook.com [40.92.255.92]) (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 84FEE3A0EEB for ; Tue, 14 Jul 2020 22:02:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aNXquaSMgqYnSvRM0aPRfQacm7aGxI3kAyYUnXhzTMrBN/J9RbswtImO3fuYr8MAP2w1WR6zwKQJx/poBbPqAKAhPB5TMmUyOIKcJqXYn/FYRtNFfJjkqaQaehIIjmmTBGpMoZPIeRwPSldtmP+rVa9ibZRPfw8j3xDLjBYgShfKBnmqvAzTcFQeXQfXzQIXEklAf1WMnGVYryLwEBhf7wsjyYHqRuE/w9DdBy8OIQpk29abfUKRL0c45brPAjCT+BheHawz121z9laHMEVz4cDV6YQVaCRDiJlQck08mcnb4T7v0/AnAVUIjNMsfffptZE0Fl5Lgvh0UKF8X8Y8Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dm8DXeKW+oxtYSe5aIVVYO2rrdJX96OnNCAU/DuC7W0=; b=YwH9kijycTy6YjOHUcYCCn67ebYiCsgtBi0X+eegQRGqftaSb+oFmdoDJhLsBRxJA5mwBvYfutvtkjt++hm+PfGcFz4M3boO62STpJpaRS2aG8tFwWq2voe1pwTq0T6jS++m9ISRFhwKThZHosrCZeQPnG7I1pR8eQLEdLvs24BRtccGBhbLMbl78zy5+ZHCYPWYl1MfLJw9K8tRUrl1vQrpts0iAc+eDF3nTNiPrr9RXaVG6nUfUOj1tRX0lnoiZf565X6cHqu3gkHvQP/PZ4UKcjzjot6zEHB0VdsHmSXdjcJUeGo368gOf0slBT+MI0xrf8F3ApuFDxsUVOtxqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dm8DXeKW+oxtYSe5aIVVYO2rrdJX96OnNCAU/DuC7W0=; b=LMEB5X74wdfImjlJxl9k5ZaXOlz/LUNDeYwIEUXfflrYel9/AuVvkbrIBZmLUVCg6I2uztic9ytGucK/qiL8xCIxTD6jsRf4GKMIDelMJKNFhQ4PYGYHeLdy5EO6NeU268h9NeTMAWq/82Po9oC/7rRpnrZ6S+r3IDm6cdCrGjIIpzcIFKr9N9VXnh7MSPtuexkf6EKFhMv1iaLCdqsgJ0QO5kgi9ZOmAu7JeAFinH8sLVotJ31Q2bOMc/lhnCFgZJWvs+IrEYjxSk6Hmtw+pUeca0ApQ2FpCKXyOZYBnD8n1CLCKM5AmgP+424ctSqd1Ege6xSxb0uTUhsTDSLohQ== Received: from PU1APC01FT023.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::4f) by PU1APC01HT155.eop-APC01.prod.protection.outlook.com (2a01:111:e400:7ebe::204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Wed, 15 Jul 2020 05:02:00 +0000 Received: from SG2PR02MB3813.apcprd02.prod.outlook.com (2a01:111:e400:7ebe::49) by PU1APC01FT023.mail.protection.outlook.com (2a01:111:e400:7ebe::260) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Wed, 15 Jul 2020 05:02:00 +0000 Received: from SG2PR02MB3813.apcprd02.prod.outlook.com ([fe80::ad37:7868:ef5f:cf13]) by SG2PR02MB3813.apcprd02.prod.outlook.com ([fe80::ad37:7868:ef5f:cf13%7]) with mapi id 15.20.3174.026; Wed, 15 Jul 2020 05:01:59 +0000 From: Tang wiki To: "isms@ietf.org" Thread-Topic: Mail regarding rfc6353 Thread-Index: AQHWWmR/kRsDXcExnESTMyhxqMdbbw== Date: Wed, 15 Jul 2020 05:01:59 +0000 Message-ID: Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:65FA5F11E90B4D78F67ECE29443F606081A7E41CD80F38E5F472F7FD757F5979; UpperCasedChecksum:DD18EACD3B40D1FCB979823C876AC3B63218FAEA42B52FDD13D320C5C0D58274; SizeAsReceived:6621; Count:42 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [74D4ZZbmSaPFnG9x4Wj5qCcFWyllt6dg] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 297fcaba-1c25-437f-1aba-08d8287c34b9 x-ms-traffictypediagnostic: PU1APC01HT155: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8/+g0kTH+yRjCy6oamo2D4hnHutGnAHSwmkNeNlTzO+xHfRt9pz0gHO+1H2M+ySWwy3xe62uFGBoehQaoZ3as5bq9Ty+GTgNvx1gv3tfuzeuQtMWRC4x42WqJelV5KaezuesCh0JodHwDvFyZu34CJi7c6wO8S5MXkSeaiOFSesz9ye2DM12zQ0yL65OBMzZ8EQfT9hA+18cDJb/PbndHA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR02MB3813.apcprd02.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: z0HqvWrkE4lCuQRxO+Lo6f9r8T77Nd+lBK1RhWuN2zsMX6OWY2YGwxxBF5Js5vcxxjxE6DYsH5SF3TjiUD1EbqOiAOrG9ixHran9wag5xaRuxRb0PPMOje4W+zbW1bxCP6HiUcbTPUHjF9UBQuXWUg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SG2PR02MB3813075B5450606ECE4AABDAB57E0SG2PR02MB3813apcp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT023.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 297fcaba-1c25-437f-1aba-08d8287c34b9 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2020 05:01:59.7317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT155 Archived-At: Subject: [Isms] Mail regarding rfc6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2020 05:02:04 -0000 --_000_SG2PR02MB3813075B5450606ECE4AABDAB57E0SG2PR02MB3813apcp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I link url to send this email to you can I get permission My name "Tangwiki" Mailbox: "abc52090241@outlook.com" abc52090241@outlook.com for you --_000_SG2PR02MB3813075B5450606ECE4AABDAB57E0SG2PR02MB3813apcp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, I link url to send thi= s email to you can I get permission
My name "Tangwiki"<= /div>
Mailbox: "abc52090241@ou= tlook.com" 
abc52090241@outlook.com for you
--_000_SG2PR02MB3813075B5450606ECE4AABDAB57E0SG2PR02MB3813apcp_-- From nobody Fri Jul 17 05:59:04 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1278E3A0B44 for ; Fri, 17 Jul 2020 05:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (768-bit key) header.d=trevilon.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 3U2wN_wCmLL7 for ; Fri, 17 Jul 2020 05:59:00 -0700 (PDT) Received: from tre.trevilon.com (tre.trevilon.com [198.57.226.42]) (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 ABE503A0B3F for ; Fri, 17 Jul 2020 05:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0tgtSJD/bdpQ/5B58bBBMZpvvLWGFM86ft/qy7X1xhg=; b=nwLKv7xm1ufF3Dul+UGSeTgbjf bb0imhWeLjQyk953kx7yJ5+m6p4krPQ47NRXoM+6go7c++uUQBc03B0boxbgaTeIwaca7mGq2Q/Dz fzk81/S7IbXVf1LSNZwHQHGok; Received: from 75-148-252-134-houston.hfc.comcastbusiness.net ([75.148.252.134]:52046 helo=[192.168.1.13]) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jwPx5-0003S8-Pv for isms@ietf.org; Fri, 17 Jul 2020 12:58:59 +0000 From: Kenneth Vaughn Content-Type: multipart/alternative; boundary="Apple-Mail=_8962D5E6-B7D2-41F1-90C2-B945E9CB669C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> Date: Fri, 17 Jul 2020 07:58:58 -0500 To: isms@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - tre.trevilon.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trevilon.com X-Get-Message-Sender-Via: tre.trevilon.com: authenticated_id: kvaughn@trevilon.com X-Authenticated-Sender: tre.trevilon.com: kvaughn@trevilon.com Archived-At: Subject: [Isms] Question regarding RFC 6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 12:59:02 -0000 --Apple-Mail=_8962D5E6-B7D2-41F1-90C2-B945E9CB669C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello and thank you for your time. I am providing guidance to both ISO TC 204 and the USDOT on the best = policies on upgrading systems currently based on prior versions of SNMP = to the latest security solutions for SNMPv3. RFC 6353 (TLSTM for SNMP) specifically references RFC 5246 (TLSv1.2), = however, TLS has been updated to TLSv1.3. I have not identified any = technical reason why using TLSv1.3 would create problems vs TLSv1.2, but = technically RFC6353 does not require this. Are there any plans to update RFC6353 to reference TLSv1.3? If not, are = you aware of any technical problem in others (e.g., ISO TC 204, USDOT, = etc) writing a specification that requires the use of RFC 6353 with the = stated exception that all references to TLSv1.2 must be replaced with = references to TLSv1.3? Or do you believe it would be appropriate to = submit (and do you believe there would there be an IETF group interested = in receiving) a proposal for a new RFC that updates the reference? If = so, who should that update proposal be sent to? Thank you for your help in this matter. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-936-647-1910 +1-571-331-5670 cell www.trevilon.com --Apple-Mail=_8962D5E6-B7D2-41F1-90C2-B945E9CB669C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello= and thank you for your time.

I am providing guidance to both ISO TC 204 and the USDOT on = the best policies on upgrading systems currently based on prior versions = of SNMP to the latest security solutions for SNMPv3.

RFC 6353 (TLSTM for = SNMP) specifically references RFC 5246 (TLSv1.2), however, TLS has = been updated to TLSv1.3. I have not identified any technical reason why = using TLSv1.3 would create problems vs TLSv1.2, but technically RFC6353 = does not require this.

Are there any plans to update RFC6353 to reference TLSv1.3? = If not, are you aware of any technical problem in others (e.g., ISO TC = 204, USDOT, etc) writing a specification that requires the use of RFC = 6353 with the stated exception that all references to TLSv1.2 must be = replaced with references to TLSv1.3? Or do you believe it would be = appropriate to submit (and do you believe there would there be an IETF = group interested in receiving) a proposal for a new RFC that updates the = reference? If so, who should that update proposal be sent to?

Thank you for your help = in this matter.

Regards,
Ken = Vaughn

Trevilon LLC
6606 FM 1488 RD = #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
www.trevilon.com

= --Apple-Mail=_8962D5E6-B7D2-41F1-90C2-B945E9CB669C-- From nobody Fri Jul 17 09:11:54 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36153A082B for ; Fri, 17 Jul 2020 09:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3IosPEoNpG8 for ; Fri, 17 Jul 2020 09:11:48 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A40F3A0807 for ; Fri, 17 Jul 2020 09:11:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 12CF168F; Fri, 17 Jul 2020 18:11:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wSHIriigXqPr; Fri, 17 Jul 2020 18:11:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 17 Jul 2020 18:11:46 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F45720154; Fri, 17 Jul 2020 18:11:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id MkmLBX00ZSpn; Fri, 17 Jul 2020 18:11:46 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id E559A200E4; Fri, 17 Jul 2020 18:11:45 +0200 (CEST) Date: Fri, 17 Jul 2020 18:11:45 +0200 From: Juergen Schoenwaelder To: Kenneth Vaughn Cc: isms@ietf.org Message-ID: <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kenneth Vaughn , isms@ietf.org References: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> Archived-At: Subject: Re: [Isms] Question regarding RFC 6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 16:11:51 -0000 Dear Kenneth, RFC 6353 says in section 9.2.1: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details. This text was published 9 years ago and this it would surely look different today. RFC 7568 (June 2015) has deprecated the usage of SSL 3.0. There is currently an Internet-Draft https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-06.html aiming to deprecate TLS 1.0 and TLS 1.1. This draft does not update RFC 6363 but this might actually be an omission (I will contact the authors to clarify this in a separate email). TLS versions evolve and what the IETF seems to be doing is to deprecate outdated TLS versions while protocols are usually designed to work with newer TLS versions. I assume that RFC 6353 has no technical issues to work with TLS 1.3 since it does not go into the TLS internals. Unless someone finds a problem with using RFC 6353 with TLS 1.3, I do not see a need to update RFC 6353. (The IETF generally does not spin RFCs to fix references that have become outdated.) If the above I-D gets published as RFC XXXX and if it formally updates RFC 6353, then requiring the implementation of RFC 6353 and RFC XXXX essentially says that (today) TLS 1.2 or 1.3 are required. I do not know whether other SDOs want to be even stricter than this today the long term trajectory of any TLS version seems to be its deprecation. /js On Fri, Jul 17, 2020 at 07:58:58AM -0500, Kenneth Vaughn wrote: > Hello and thank you for your time. > > I am providing guidance to both ISO TC 204 and the USDOT on the best policies on upgrading systems currently based on prior versions of SNMP to the latest security solutions for SNMPv3. > > RFC 6353 (TLSTM for SNMP) specifically references RFC 5246 (TLSv1.2), however, TLS has been updated to TLSv1.3. I have not identified any technical reason why using TLSv1.3 would create problems vs TLSv1.2, but technically RFC6353 does not require this. > > Are there any plans to update RFC6353 to reference TLSv1.3? If not, are you aware of any technical problem in others (e.g., ISO TC 204, USDOT, etc) writing a specification that requires the use of RFC 6353 with the stated exception that all references to TLSv1.2 must be replaced with references to TLSv1.3? Or do you believe it would be appropriate to submit (and do you believe there would there be an IETF group interested in receiving) a proposal for a new RFC that updates the reference? If so, who should that update proposal be sent to? > > Thank you for your help in this matter. > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-936-647-1910 > +1-571-331-5670 cell > www.trevilon.com > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jul 17 09:50:08 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BF53A094E for ; Fri, 17 Jul 2020 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-4Zy4UScSQe for ; Fri, 17 Jul 2020 09:50:04 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40126.outbound.protection.outlook.com [40.107.4.126]) (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 5AC6C3A094A for ; Fri, 17 Jul 2020 09:50:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qol+VXDPaM+CariM9lTWaYl8ayMBsBXkM6l41wCwAu+MDtWZGGTxeuujNEvOyCqLOX82kHRF8cVc8ntz3Sm4Nh6ZFEE4vL/+Y/JcbNt05pEJi0r/Z6z7zLTJHdwKPdv1fUyyhqRe+2Hs3/Kx89ZUr9oMeFOsC0j3xqv2NStGf2NshI/e00jtus8TiJ00zj4pZIwCR/yRf0K24UTusCxka/SbottfMkFI6llOMCWg91ot2QJQ/EOS5TOmqZOIsnoqxj8OlED2awV87GDHevIpz3ohV9wmi0iFGyYgLQhaiHvEiTYqgzSt7HRI9HCl+5tFjnksZHb89M6Fsgvzcy3gPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gaqJ3G9ltD4FiA4j3+9c7NUIzFX365uefZGhqvuER+I=; b=NG8Rc1DbvD9i3J3DEs1/uSoMJHWIAgOxuaO3sGxBZY1AGHqKxuC3vF5YJ61ql/1TFmqz3QRcNqIb4L+j+DbLbctYw3LVzHZkJNBoMi3bZ8x+bkAkN8XcmA6zphpotPZPi5rAYpArb8CldPbPUlffF7qQ0hz6xtTbkYxSX7v7pF2DOIjxbLPXxdwdVmf8QVhrXE2O3CVq5Ez6LT38zDJFUPdPFJranEuPxrBTxDnYSQveaC5N27iKR7LVxP2Iv+uyg3Ze12i7FBxtnPniKvcJGGS11HYhqRoHCGPvQSoA4W9x3NRrR2Lq6kRmrf5LszLTfv1MVsPAVFVBXpk/o+g79w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gaqJ3G9ltD4FiA4j3+9c7NUIzFX365uefZGhqvuER+I=; b=fhlXLnRE9cv+v7PJNTqClb6W5HgI6B0fWIf6BJXVGmFgjaB40zieAgDrFh+Vnx9WMrxsWLe60Su93Q0hIUJXDzHTEvESHNYhgpzbOOdArMUe/JTNIEl3tvXPhpY0Jvb7/cqigItVe/Que6nm7yzLwSatGb6AmKY0ztCxOBgLNNI= Received: from AM6PR07MB5222.eurprd07.prod.outlook.com (2603:10a6:20b:61::25) by AM7PR07MB6440.eurprd07.prod.outlook.com (2603:10a6:20b:131::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.11; Fri, 17 Jul 2020 16:50:02 +0000 Received: from AM6PR07MB5222.eurprd07.prod.outlook.com ([fe80::6d04:3a51:ec0d:9890]) by AM6PR07MB5222.eurprd07.prod.outlook.com ([fe80::6d04:3a51:ec0d:9890%7]) with mapi id 15.20.3195.022; Fri, 17 Jul 2020 16:50:01 +0000 From: tom petch To: Kenneth Vaughn , Juergen Schoenwaelder CC: "isms@ietf.org" Thread-Topic: [Isms] Question regarding RFC 6353 Thread-Index: AQHWXDoPABqan7xXe0GX6YYvqhOE3akL8XqAgAAHE9A= Date: Fri, 17 Jul 2020 16:50:01 +0000 Message-ID: References: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com>, <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> In-Reply-To: <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: trevilon.com; dkim=none (message not signed) header.d=none; trevilon.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10159c5b-7438-4c86-174c-08d82a7172e0 x-ms-traffictypediagnostic: AM7PR07MB6440: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MgdXKqJir9KbU/V0bTqfYBPyjlKpAxviXN/Tr8vhMk/oa9JXhNPRrYLm+kFuuyEMI1l7uu41XIY7aNW3vyLc/Q/c2oLSxMTaQ8ZFZnGevcwuUZDlNk3/6NQeGjt02k8WjTjBOekKToYuvEdq2wQSvJRgMwMRrAD4Dud14Tw9wEugFG7sYhMuAMirGIlpoBARIdd9KqbOhuSnGCI1FSqCFBxnZZF7O3g5IVhTTCGwVaeIeImz98bbAdzewDYz2DZicZjJtmw6fs4A7DvBMljN2P2tXv1GlocwJsrl8H1SqI9f+b54kLbvOFDaXIjRzn1gloMmbOFPPrJMbSKSisHmoTk1N+1FuXu1/KkV/8y6zEx0Y8BgjbxEOtCYMgzVpHu3A5kuKORn+SwRaK0ObdZ7Pg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5222.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(39860400002)(346002)(396003)(376002)(366004)(71200400001)(966005)(66946007)(64756008)(66446008)(186003)(5660300002)(26005)(66556008)(91956017)(76116006)(4326008)(66476007)(86362001)(2906002)(66574015)(8676002)(83080400001)(83380400001)(8936002)(52536014)(6506007)(316002)(33656002)(55016002)(7696005)(478600001)(9686003)(110136005)(15974865002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HB5xm8U2gjVQ6phL7E7y8owovPjjC/qNkgxB8HyztFViPLart7jVVhc/642DBx/X8rUgZDNTR9rx9saq0fQgXWEksuToVApxW0+YXVJFXahO5WqdVetgpiRqpemfjZqUbb4B9ZxBE6GtozZlBQgnk5gF/Tcr3Gat6brLXS0LvsAcNLm0NcoiDDzJl+VZyreSiGqw96Q9YiqZGCKdsLiRDq+u3T0PyC7B2ri7DbqBoLVUNNDpC57x7RdKQkD/AoWy2JvYKin0I7htglFm35rKXpb9XgS/xJSP/HNWl/lQPArR3l1O6V1sLzAJ/6pXJOy2gZxfw3P0u8CjCV1Vq02ygZl9d20JJV9muCjjvnoOqhnKs4mZpU1gxuFTgmtntUEq05qPwFrmvUQ8jqAkG5tDdHJ6hvhmlW0ywnCq07cVphX8LnEmU/IQtaqnr2V5w5tv28sER/2ocx1obrTNvYratL6gH+ULLvFrs1n7Rvgp2TM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5222.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10159c5b-7438-4c86-174c-08d82a7172e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2020 16:50:01.8695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EKgXQymnTqtOhDyyTJFzWE2OfzaaKlIwPNvUXQ8nG7cv4/EZc4sHQrsePqPooqVbQ85F/OYEH7HiQF5xGmZ9/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6440 Archived-At: Subject: Re: [Isms] Question regarding RFC 6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 16:50:07 -0000 From: Isms on behalf of Juergen Schoenwaelder =0A= Sent: 17 July 2020 17:11=0A= =0A= Dear Kenneth,=0A= =0A= RFC 6353 says in section 9.2.1:=0A= =0A= Implementations of TLS typically support multiple versions of the=0A= Transport Layer Security protocol as well as the older Secure Sockets=0A= Layer (SSL) protocol. Because of known security vulnerabilities,=0A= TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.=0A= See Appendix E.2 of [RFC5246] for further details.=0A= =0A= This text was published 9 years ago and this it would surely look=0A= different today. RFC 7568 (June 2015) has deprecated the usage of SSL=0A= 3.0. There is currently an Internet-Draft=0A= =0A= https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-06.html=0A= =0A= aiming to deprecate TLS 1.0 and TLS 1.1. This draft does not update=0A= RFC 6363 but this might actually be an omission (I will contact the=0A= authors to clarify this in a separate email).=0A= =0A= TLS versions evolve and what the IETF seems to be doing is to=0A= deprecate outdated TLS versions while protocols are usually designed=0A= to work with newer TLS versions. I assume that RFC 6353 has no=0A= technical issues to work with TLS 1.3 since it does not go into the=0A= TLS internals. Unless someone finds a problem with using RFC 6353 with=0A= TLS 1.3, I do not see a need to update RFC 6353. (The IETF generally=0A= does not spin RFCs to fix references that have become outdated.)=0A= =0A= If the above I-D gets published as RFC XXXX and if it formally updates=0A= RFC 6353, then requiring the implementation of RFC 6353 and RFC XXXX=0A= essentially says that (today) TLS 1.2 or 1.3 are required. I do not=0A= know whether other SDOs want to be even stricter than this today the=0A= long term trajectory of any TLS version seems to be its deprecation.=0A= =0A= =0A= What a question of CoB on a Friday afternoon.=0A= =0A= I think that it may be more complicated than that. TLS 1.3 is a radical re= structuring of TLS so that e.g. the concept of a ciphersuite changes, digit= al signatures are specified separately and while renegotiation has gone, TL= S has never been much of a fan of client authentication which SNMP is fussy= about and prohibited renegotiation as a result. I think that a some featu= res of TLS 1.3 would need banning so that the client authentication cannot = change. And some users have found TLS 1.3 not fit for purpose since it ren= ders a number of operational practices impossible, especially in areas wher= e the security of the organisation takes precedence over the security of th= e individual, not a view that receives much support in the IETF TLS WG! Th= ere is an I-D about this in the IETF OPSEC WG and what the future holds for= this is hard to know, more politics than engineering.=0A= =0A= I see the focus of the IETF on YANG these days and think it unlikely that t= he IETF would update that RFC unless a lot of energy appeared to do so.=0A= =0A= And I do not believe that the TLS WG has shown much interest in the consequ= ences for other protocols of deprecating earlier versions of TLS.=0A= =0A= I will think some more but it might be a slow process.=0A= =0A= Tom Petch=0A= /js=0A= =0A= On Fri, Jul 17, 2020 at 07:58:58AM -0500, Kenneth Vaughn wrote:=0A= > Hello and thank you for your time.=0A= >=0A= > I am providing guidance to both ISO TC 204 and the USDOT on the best poli= cies on upgrading systems currently based on prior versions of SNMP to the = latest security solutions for SNMPv3.=0A= >=0A= > RFC 6353 (TLSTM for SNMP) specifically references RFC 5246 (TLSv1.2), how= ever, TLS has been updated to TLSv1.3. I have not identified any technical = reason why using TLSv1.3 would create problems vs TLSv1.2, but technically = RFC6353 does not require this.=0A= >=0A= > Are there any plans to update RFC6353 to reference TLSv1.3? If not, are y= ou aware of any technical problem in others (e.g., ISO TC 204, USDOT, etc) = writing a specification that requires the use of RFC 6353 with the stated e= xception that all references to TLSv1.2 must be replaced with references to= TLSv1.3? Or do you believe it would be appropriate to submit (and do you b= elieve there would there be an IETF group interested in receiving) a propos= al for a new RFC that updates the reference? If so, who should that update = proposal be sent to?=0A= >=0A= > Thank you for your help in this matter.=0A= >=0A= > Regards,=0A= > Ken Vaughn=0A= >=0A= > Trevilon LLC=0A= > 6606 FM 1488 RD #148-503=0A= > Magnolia, TX 77354=0A= > +1-936-647-1910=0A= > +1-571-331-5670 cell=0A= > www.trevilon.com=0A= >=0A= =0A= > _______________________________________________=0A= > Isms mailing list=0A= > Isms@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/isms=0A= =0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= Isms mailing list=0A= Isms@ietf.org=0A= https://www.ietf.org/mailman/listinfo/isms=0A= From nobody Tue Jul 21 15:46:50 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB23A048D for ; Tue, 21 Jul 2020 15:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3RJQ06eMa76 for ; Tue, 21 Jul 2020 15:46:47 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934D93A0486 for ; Tue, 21 Jul 2020 15:46:47 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id E6330210C3; Tue, 21 Jul 2020 15:46:46 -0700 (PDT) From: Wes Hardaker To: tom petch Cc: Kenneth Vaughn , Juergen Schoenwaelder , "isms\@ietf.org" References: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> Date: Tue, 21 Jul 2020 15:46:46 -0700 In-Reply-To: (tom petch's message of "Fri, 17 Jul 2020 16:50:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Isms] Question regarding RFC 6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 22:46:49 -0000 tom petch writes: > I think that it may be more complicated than that. TLS 1.3 is a > radical restructuring of TLS so that e.g. the concept of a ciphersuite > changes, digital signatures are specified separately and while > renegotiation has gone, TLS has never been much of a fan of client > authentication which SNMP is fussy about and prohibited renegotiation > as a result. I think client-based certificate authentication is the only thing that would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a problem (but haven't done the work to prove it). RFC6353 was explicitly written to not specify one specific version of TLS to use. The only thing it states authoritatively is in 9.2.1: Because of known security vulnerabilities, TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details. The reference to TLS 1.2 via RFC5246 is in the document because we had to normatively reference *some* version of TLS, and that's what was available then. No where in the document does it say "that's the only version you should use". -- Wes Hardaker USC/ISI From nobody Wed Jul 22 02:40:26 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA233A0889 for ; Wed, 22 Jul 2020 02:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ReF_IUzB5Q9 for ; Wed, 22 Jul 2020 02:40:22 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2104.outbound.protection.outlook.com [40.107.21.104]) (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 6BEC03A0886 for ; Wed, 22 Jul 2020 02:40:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X3BXedUJTyseIknHHOt+C9wsx7lBVay/D5aAY0EGZlTMnbf3IK7LTzekI8D/EU9gYFS/GTndzlKTG8inoEiOi/knpHj/9WzOcKBJp9E2zHnxJ4Z/a4/pBlpQLHzdQ2TI+exww2f6MucCskpZxsnJ26DBkbRr2UjGRWcGDI35Tx5FqBCUEaTIx/9l+6fDmZQAYrQNF5mwJRHqlfbdPXIX24j4UWttIVUd6zfZ5URnV8QYWoztud85xySjhCjdLhsAmueb2c/hSoGRakdLZUmFv1pxgvddGwGB5G0Lc1solzGLL7Qd2o5r2KrLoYmRX5Ite+Vht3G2PE/Y6ye4+o1G8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0e4xm2sUQSK8H+hYIjcJUk2h5NEDhfFwG3CxKgU74no=; b=GquESRx3E6JIIlBNyGBKYFoDvww7hD9My1yBRFdkiK4VGT54OhC8wldz/8/4B3UNIBu6is/YR70bBxmiRd4CIKZXrnuM6wkkOV8yFHvj53p+aFclvfnVW4fjaUGvfHWwV3rTkFZVBfMTr/kbEW/fcY7qdJUGU8aBNUj7WYEqScTVJy5LNQiseRT6inw0CR33CXmzoaC4M19LSr5+QqBJt3SG4T9ICv9l2yhGlahhapSEPX4a2t3zZa3fXvZc4ZXMGz6VRz6MLNreqVmtFbRdb+5De+Ijt8V3aqUGH7DxaawhwsTf4Qr87KhQ4FXtmFbAnIwELad/wFwu2EXkd0byLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0e4xm2sUQSK8H+hYIjcJUk2h5NEDhfFwG3CxKgU74no=; b=hYfSEqijGFQ+t48+acyaK08Rvpx5b1xGNJmjoNcGrrirvHodCxGQbYo53Yf6GiPUaU2KxBbyYSqLBX2hsghQw9+Nf3IzJKxGfyQyNf6fh51JbhrMD+1mrEsmjKNEhP4yiLLAG8nivkElK0pxHbCHPTt2ZekOHzUCSRFocweUe3w= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR0702MB3800.eurprd07.prod.outlook.com (2603:10a6:209:11::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Wed, 22 Jul 2020 09:40:20 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::893c:ca97:acbf:1c76]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::893c:ca97:acbf:1c76%5]) with mapi id 15.20.3216.020; Wed, 22 Jul 2020 09:40:20 +0000 From: tom petch To: Wes Hardaker CC: Kenneth Vaughn , Juergen Schoenwaelder , "isms@ietf.org" Thread-Topic: Question regarding RFC 6353 Thread-Index: AQHWX7DXfWLA5tI62EqxNR3OP8lxTqkTVhkb Date: Wed, 22 Jul 2020 09:40:19 +0000 Message-ID: References: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hardakers.net; dkim=none (message not signed) header.d=none;hardakers.net; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9c5c25d9-da34-4848-8a78-08d82e233fb5 x-ms-traffictypediagnostic: AM6PR0702MB3800: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LjMpe4OMalJlILIDwb1xUwIQhCzAThpKi7R8Zoat2fUSYM6+G8JJLdCBXnr/MNlPi9An35mBzCBGojUlKll3dxugZy36AE2tVOFd9gPXiVvW2OHcu1PNQfN3EGznanbAYx/Z/rrzZzdE/+NrOoJoR8NzTaQNxNt1Vtcilfhp6hRE9P1SEORu34oFq6K/bi/dd9t7dgSU6ZxcxiuxA8WhJ8icT06kmr+ahbM7RVEpAG+KCEUJVDOf6igsePxomtq+FooxcY9Bpcc1B7pPJynp78wwF3nuq85dkVYrq3Ul5hhWdrzk0Qi1AXvqBjrkIZYAR+cCFTSmVRwIbCSHL18scQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(39860400002)(366004)(346002)(376002)(66476007)(64756008)(66556008)(91956017)(76116006)(66446008)(66946007)(26005)(186003)(54906003)(9686003)(316002)(5660300002)(7116003)(52536014)(55016002)(86362001)(4326008)(8936002)(478600001)(83380400001)(71200400001)(7696005)(33656002)(6916009)(2906002)(8676002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 8E0cBdgDroeLWnTNIVAj80ZYBjTp9fovEwGglaFv5O53+fYLjMbbg8/F8saf1CanT71c9emUo1Atz7TcaFhBCZQjzXsc5clblSgSNt8CgCZdqJBcxs7z0+C4OTCQBBZM26vvsViruwOk6lduflRtTb9nC2vCkCwjRV7tbr9nlz+N0GkK6oaWPshA5+EmIX4/cp57UiR//ocK/eiWXQTThNKcEWNLOufW/dJl/SwHQTnMHT2MOVMKNJB+MyVfOMG0xFXy7f7e0nc3EuLvBC/jbxq9j5ILgGxhuYDXD4q8REmHZW0VoDfi8P7rz4EYhgl/xDWsrUKvVSkQYDLT+td/cCf8QJU88AHpTYZGgaXXoPpntu/CN8b9EL5ZQEbMqP1rjyiVJyjfO4mcc0CqVcqyWX6Twa6RamV7fuuxFGLPk6f8dFZzz97CHPSj9RuPR6U9tJarKx9B0g8FnxBmxVwTDFrRpkO3Ns+URnETmx0R4ueY6g8g2I3NL5KlQYJj/DqRFqVNGPwXD2RyrAB1QLtynaw76K3NhMXh9AZBOWl8RvM3I4tMIAJrVNPRRRZA1BFXsWznUWgW9CXbJl3Shh9MfINibgFZ63rWvLOUkOSOjHkQNcffNVAeEgyTSf/9vPM26PubNH/3Y7olQOfLGAwdfg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9c5c25d9-da34-4848-8a78-08d82e233fb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 09:40:19.9016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: beDF+lEDG96XR+r2NThaXZNPeG2PWNkcwkhDnoEvVVwu5Hr7tl7SUJ/uR9eXxInRFP4opDe4oi4AZ5R9jl3BqQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3800 Archived-At: Subject: Re: [Isms] Question regarding RFC 6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 09:40:25 -0000 From: Wes Hardaker =0A= Sent: 21 July 2020 23:46=0A= tom petch writes:=0A= =0A= > I think that it may be more complicated than that. TLS 1.3 is a=0A= > radical restructuring of TLS so that e.g. the concept of a ciphersuite=0A= > changes, digital signatures are specified separately and while=0A= > renegotiation has gone, TLS has never been much of a fan of client=0A= > authentication which SNMP is fussy about and prohibited renegotiation=0A= > as a result.=0A= =0A= I think client-based certificate authentication is the only thing that=0A= would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a=0A= problem (but haven't done the work to prove it). RFC6353 was explicitly=0A= written to not specify one specific version of TLS to use. The only=0A= thing it states authoritatively is in 9.2.1:=0A= =0A= Because of known security vulnerabilities,=0A= TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.=0A= See Appendix E.2 of [RFC5246] for further details.=0A= =0A= The reference to TLS 1.2 via RFC5246 is in the document because we had=0A= to normatively reference *some* version of TLS, and that's what was=0A= available then. No where in the document does it say "that's the only=0A= version you should use".=0A= =0A= =0A= Yes, my concern is more one of Fear, Uncertainty and Doubt as opposed to ha= rd engineering, but this is security so it behoves us to be cautious. I se= e many strands=0A= =0A= Security is about operational practices and=0A= draft-ietf-opsec-ns-impact=0A= looks at what may be difficult or impractical with TLS 1.3 compared to=0A= TLS 1.2. Note that it is an I-D and it might be a year or two before=0A= the IETF gets to decide whether or not to publish it as an RFC by which=0A= time all sorts of things might have happened. The issues in the I-D have= =0A= appeared on the TLS WG list and been rejected. The I-D was proposed for=0A= adoption by the TLS WG and was rejected although it did get some review=0A= and constructive feedback, that is, its description of the behaviour of TLS= 1.3 has been reviewed.=0A= I commend that I-D to anyone looking to migrate to TLS1.3 who has anything = more than=0A= an HTTP web server.=0A= =0A= Part of the ethos of the TLS WG is that where there is a conflict=0A= between the security of an individual and that of an organisation then=0A= the former takes precedence which I see as relevant here.=0A= =0A= TLS, like SSL before it, has little concern with the authentication of=0A= the user, that often being done with renegotiation. For OAM in general,=0A= and SNMP in particular, user authentication is paramount; the protocol=0A= must yield an authenticated identity. Given the major reconstruction of=0A= TLS with 1.3, I would not assume that the user identity is ok without a=0A= careful study. SNMP prohibited renegotiation as TLS1.3 has done for=0A= different reasons. The TLS WG has just approved an I-D=0A= draft-ietf-tls-exported-authenticator=0A= which offers a replacement for renegotiation; is that ok for SNMP?=0A= probably not. The approach to signature schemes has changed in TLS 1.3;=0A= is there any impact on user certificate chains? Much of the work on=0A= TLS1.3 was on facilitating 0-RTT; is that ok? I think that given=0A= security is involved, then TLS 1.3 and all the TLS1.3 extensions need=0A= careful examination from the perspective of delivering an authenticated=0A= user identity before I would regard it as... well, not safe, because I=0A= never say anything is safe but rather without any risk that I can see.=0A= =0A= My background is operations, not security, so I have a 101 understanding=0A= of security and TLS (but will never be a cryptographer:-)=0A= =0A= HTH=0A= =0A= Tom Petch=0A= --=0A= Wes Hardaker=0A= USC/ISI=0A= From nobody Wed Jul 22 09:58:17 2020 Return-Path: X-Original-To: isms@ietfa.amsl.com Delivered-To: isms@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B34F3A0B26 for ; Wed, 22 Jul 2020 09:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 (768-bit key) header.d=trevilon.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 Pt4HS-PQOHS0 for ; Wed, 22 Jul 2020 09:58:12 -0700 (PDT) Received: from tre.trevilon.com (tre.trevilon.com [198.57.226.42]) (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 B76353A0B1A for ; Wed, 22 Jul 2020 09:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trevilon.com; s=default; h=References:To:Cc:In-Reply-To:Date:Subject: Mime-Version:Content-Type:Message-Id:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aWE8Y0vcGgB4uzdx0pRws5o7J+H2i02HlDr/LzVm8co=; b=P24SvrgK/sF+zJcM9SIkDS607 xqKv/LW1D/nSS6icU+9cWlFSjy91cpPAxIYwgPyb6xJrFyvIyJ8ofHM7hotEvJwSaaUyt7aYTD0sU w88SFmDcANqpz917bsOC7b6Fm0; Received: from 75-148-252-134-houston.hfc.comcastbusiness.net ([75.148.252.134]:55117 helo=[192.168.1.13]) by tre.trevilon.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jyI4I-0007Hb-LN; Wed, 22 Jul 2020 16:58:10 +0000 From: Kenneth Vaughn Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1C4020F3-1B49-4320-91F5-3599DB973FCC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 22 Jul 2020 11:58:09 -0500 In-Reply-To: Cc: Wes Hardaker , Juergen Schoenwaelder , "isms@ietf.org" To: tom petch References: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - tre.trevilon.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - trevilon.com X-Get-Message-Sender-Via: tre.trevilon.com: authenticated_id: kvaughn@trevilon.com X-Authenticated-Sender: tre.trevilon.com: kvaughn@trevilon.com Archived-At: Subject: Re: [Isms] Question regarding RFC 6353 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2020 16:58:15 -0000 --Apple-Mail=_1C4020F3-1B49-4320-91F5-3599DB973FCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tom et al. Thank you for this great information. We will continue to study this = topic and will present the information to the corresponding = transportation WGs to decide on our future direction.=20 To give you some background, within the US, the Intelligent = Transportation Systems (ITS) industry adopted the use of SNMPv1 in the = late 1990s for managing an array of field devices (signal controllers, = ramp meters, message signs, etc.). We have standardized the data for = these devices (and some other issues) under the National Transportation = Communications for ITS Protocol (NTCIP), which is a joint effort among = the American Association of State Highway and Transportation Officials = (AASHTO), the Institute of Transportation Engineers (ITE), and the = National Electrical Manufacturers Association (NEMA).=20 Around the same time, the UK adopted SNMP (v2) to manage some of their = field devices using a separate set of MIBs (under their UTMC project).=20= Over the years, the US and UK solutions have been almost universally = adopted within those two countries while also being widely deployed in = other countries.=20 =46rom the beginning, I have been complaining about the lack of security = in these standards, but SNMPv3 was not released until the early 2000=E2=80= =99s after deployments had already started and there was little interest = within the industry to revisit a decision when most networks at the time = were private networks and many of the links were extremely slow (e.g., = 1200 bps to the field - this even led to the development of a much more = bandwidth friendly version of SNMP that is specific to ITS). However, = there is now increased interest in securing the protocol due to: - Higher speed communication networks - often shared=20 - Higher speed processors in field equipment that run modern operating = systems (e.g., Linux) - Increased cybersecurity threats - and a few attacks that have impacted = operations in specific areas - The need to prepare for connected vehicles in the relatively near = future. Within the last decade, I have been involved in the development of two = ISO TC 204 standards to address this issue (ISO 15784-2 defining how to = use SNMP - including SNMPv3 - within ITS and ISO 20684 (all parts), = which defines standardized data for devices). After twenty years, the US is now accepting that we need to secure our = protocol and is undertaking the current study to investigate the best = way to achieve this. My best guess at this point is that the WG will = decide to maintain the path towards using SNMPv3. It seems to me that = the way in which we use the protocol is somewhat different than = traditional network management. Based on my review of various articles, = it seems as if the network management industry was (and still is) happy = to use SNMP for network monitoring potentially with very basic security = - but migrated to NETCONF for the purposes of device configuration, = which tends to be a very manual process. Within ITS, we use SNMP for = both of these purposes but also use it for automated command and control = on a fairly regular basis (e.g., altering signal timing, changing a = message on a sign, etc). And the majority of our configuration commands = are often just minor tweaks to a rather massive amount of information in = the device. Thus, my impression of NETCONF and even RESTCONF with JSON = is that they would entail a significant change in logic within our = systems coupled with an increase in bandwidth and processing utilization = while not providing any real practical benefit for our industry - except = for the odd case of the complete (or substantial) controller = re-configuration process - which is fairly rare. If you think I have = somehow mis-characterized the impacts of NETCONF/RESTCONF, I am happy to = be corrected, but assuming that my analysis is correct, I think our = industry would prefer to continue the use of SNMP - or perhaps migrate = to a completely different solution, in particular there would be some = advantages to using data distribution technologies such as AMQP, MQTT, = Kafka, or DDS but these obviously have very different trade-offs = offering much better monitoring and data sharing while not handling the = command and control as well. I will keep you posted as the project progresses, but I suspect that = there will likely be real interest within our industry to make sure that = the security for SNMPv3 is maintained and updated to work with TLSv1.3. = While I understand that the efforts to produce this type of = documentation might have to depend heavily on ITS support, I would = certainly hope that any such maintenance can be performed under the = auspices of IETF so that other users of SNMPv3 can directly benefit from = these efforts (e.g., rather than developing this update as an ISO or = NTCIP standard where most of my involvement has been to date on this = topic). NOTE: As an aside, there might also be interest within the ITS community = to add support for SNMPv3 using IEEE 1609.2 certs rather than just X.509 = certs (https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609/), but = this is likely a longer-term issue and obviously has to await feedback = from the relevant ITS committees. Regards, Ken Vaughn Trevilon LLC 6606 FM 1488 RD #148-503 Magnolia, TX 77354 +1-936-647-1910 +1-571-331-5670 cell www.trevilon.com > On Jul 22, 2020, at 4:40 AM, tom petch wrote: >=20 > From: Wes Hardaker > Sent: 21 July 2020 23:46 > tom petch writes: >=20 >> I think that it may be more complicated than that. TLS 1.3 is a >> radical restructuring of TLS so that e.g. the concept of a = ciphersuite >> changes, digital signatures are specified separately and while >> renegotiation has gone, TLS has never been much of a fan of client >> authentication which SNMP is fussy about and prohibited renegotiation >> as a result. >=20 > I think client-based certificate authentication is the only thing that > would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be = a > problem (but haven't done the work to prove it). RFC6353 was = explicitly > written to not specify one specific version of TLS to use. The only > thing it states authoritatively is in 9.2.1: >=20 > Because of known security vulnerabilities, > TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. > See Appendix E.2 of [RFC5246] for further details. >=20 > The reference to TLS 1.2 via RFC5246 is in the document because we had > to normatively reference *some* version of TLS, and that's what was > available then. No where in the document does it say "that's the only > version you should use". >=20 > > Yes, my concern is more one of Fear, Uncertainty and Doubt as opposed = to hard engineering, but this is security so it behoves us to be = cautious. I see many strands >=20 > Security is about operational practices and > draft-ietf-opsec-ns-impact > looks at what may be difficult or impractical with TLS 1.3 compared to > TLS 1.2. Note that it is an I-D and it might be a year or two before > the IETF gets to decide whether or not to publish it as an RFC by = which > time all sorts of things might have happened. The issues in the I-D = have > appeared on the TLS WG list and been rejected. The I-D was proposed = for > adoption by the TLS WG and was rejected although it did get some = review > and constructive feedback, that is, its description of the behaviour = of TLS1.3 has been reviewed. > I commend that I-D to anyone looking to migrate to TLS1.3 who has = anything more than > an HTTP web server. >=20 > Part of the ethos of the TLS WG is that where there is a conflict > between the security of an individual and that of an organisation then > the former takes precedence which I see as relevant here. >=20 > TLS, like SSL before it, has little concern with the authentication of > the user, that often being done with renegotiation. For OAM in = general, > and SNMP in particular, user authentication is paramount; the protocol > must yield an authenticated identity. Given the major reconstruction = of > TLS with 1.3, I would not assume that the user identity is ok without = a > careful study. SNMP prohibited renegotiation as TLS1.3 has done for > different reasons. The TLS WG has just approved an I-D > draft-ietf-tls-exported-authenticator > which offers a replacement for renegotiation; is that ok for SNMP? > probably not. The approach to signature schemes has changed in TLS = 1.3; > is there any impact on user certificate chains? Much of the work on > TLS1.3 was on facilitating 0-RTT; is that ok? I think that given > security is involved, then TLS 1.3 and all the TLS1.3 extensions need > careful examination from the perspective of delivering an = authenticated > user identity before I would regard it as... well, not safe, because I > never say anything is safe but rather without any risk that I can see. >=20 > My background is operations, not security, so I have a 101 = understanding > of security and TLS (but will never be a cryptographer:-) >=20 > HTH >=20 > Tom Petch > -- > Wes Hardaker > USC/ISI >=20 --Apple-Mail=_1C4020F3-1B49-4320-91F5-3599DB973FCC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Tom = et al.

Thank you for = this great information. We will continue to study this topic and will = present the information to the corresponding transportation WGs to = decide on our future direction. 

To give you some background, within the = US, the Intelligent Transportation Systems (ITS) industry adopted the = use of SNMPv1 in the late 1990s for managing an array of field devices = (signal controllers, ramp meters, message signs, etc.). We have = standardized the data for these devices (and some other issues) under = the National Transportation Communications for ITS Protocol (NTCIP), = which is a joint effort among the American Association of State Highway = and Transportation Officials (AASHTO), the Institute of Transportation = Engineers (ITE), and the National Electrical Manufacturers Association = (NEMA). 

Around the same time, the UK adopted SNMP (v2) to manage some = of their field devices using a separate set of MIBs (under their UTMC = project). 

Over the years, the US and UK solutions have been almost = universally adopted within those two countries while also being widely = deployed in other countries. 

=46rom the beginning, I have been = complaining about the lack of security in these standards, but SNMPv3 = was not released until the early 2000=E2=80=99s after deployments had = already started and there was little interest within the industry to = revisit a decision when most networks at the time were private networks = and many of the links were extremely slow (e.g., 1200 bps to the field - = this even led to the development of a much more bandwidth friendly = version of SNMP that is specific to ITS). However, there is now = increased interest in securing the protocol due to:
-= Higher speed communication networks - often shared 
- Higher speed processors in field equipment that run modern = operating systems (e.g., Linux)
- Increased = cybersecurity threats - and a few attacks that have impacted operations = in specific areas
- The need to prepare for = connected vehicles in the relatively near future.
Within the last decade, I have been = involved in the development of two ISO TC 204 standards to address this = issue (ISO 15784-2 defining how to use SNMP - including SNMPv3 - within = ITS and ISO 20684 (all parts), which defines standardized data for = devices).

After = twenty years, the US is now accepting that we need to secure our = protocol and is undertaking the current study to investigate the best = way to achieve this. My best guess at this point is that the WG will = decide to maintain the path towards using SNMPv3. It seems to me that = the way in which we use the protocol is somewhat different than = traditional network management. Based on my review of various articles, = it seems as if the network management industry was (and still is) happy = to use SNMP for network monitoring potentially with very basic security = - but migrated to NETCONF for the purposes of device configuration, = which tends to be a very manual process.  Within ITS, we use SNMP = for both of these purposes but also use it for automated command and = control on a fairly regular basis (e.g., altering signal timing, = changing a message on a sign, etc). And the majority of our = configuration commands are often just minor tweaks to a rather massive = amount of information in the device. Thus, my impression of NETCONF and = even RESTCONF with JSON is that they would entail a significant change = in logic within our systems coupled with an increase in bandwidth and = processing utilization while not providing any real practical benefit = for our industry - except for the odd case of the complete (or = substantial) controller re-configuration process - which is fairly rare. = If you think I have somehow mis-characterized the impacts of = NETCONF/RESTCONF, I am happy to be corrected, but assuming that my = analysis is correct, I think our industry would prefer to continue the = use of SNMP - or perhaps migrate to a completely different solution, in = particular there would be some advantages to using data distribution = technologies such as AMQP, MQTT, Kafka, or DDS but these obviously have = very different trade-offs offering much better monitoring and data = sharing while not handling the command and control as well.

I will keep you posted = as the project progresses, but I suspect that there will likely be real = interest within our industry to make sure that the security for SNMPv3 = is maintained and updated to work with TLSv1.3. While I understand that = the efforts to produce this type of documentation might have to depend = heavily on ITS support, I would certainly hope that any such maintenance = can be performed under the auspices of IETF so that other users of = SNMPv3 can directly benefit from these efforts (e.g., rather than = developing this update as an ISO or NTCIP standard where most of my = involvement has been to date on this topic).

NOTE: As an aside, there might also be = interest within the ITS community to add support for SNMPv3 using IEEE = 1609.2 certs rather than just X.509 certs (https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609/= ), but this is likely a longer-term issue and obviously has to await = feedback from the relevant ITS committees.

Regards,
Ken = Vaughn

Trevilon LLC
6606 FM 1488 RD = #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
www.trevilon.com

On Jul 22, 2020, at 4:40 AM, tom petch <ietfc@btconnect.com>= wrote:

From: Wes Hardaker <wjhns1@hardakers.net>
Sent: 21 July 2020 = 23:46
tom petch <ietfc@btconnect.com> writes:

I think that it may be = more complicated than that.  TLS 1.3 is a
radical = restructuring of TLS so that e.g. the concept of a ciphersuite
changes, digital signatures are specified separately and = while
renegotiation has gone, TLS has never been much of a = fan of client
authentication which SNMP is fussy about and = prohibited renegotiation
as a result.

I think client-based certificate = authentication is the only thing that
would prevent = RFC6353 from working over TLS 1.3, and I doubt it'll be a
problem (but haven't done the work to prove it). =  RFC6353 was explicitly
written to not specify one = specific version of TLS to use.  The only
thing it = states authoritatively is in 9.2.1:

=   Because of known security vulnerabilities,
=   TLSTM clients and servers MUST NOT request, offer, or use = SSL 2.0.
  See Appendix E.2 of [RFC5246] for = further details.

The reference to TLS 1.2 = via RFC5246 is in the document because we had
to = normatively reference *some* version of TLS, and that's what was
available then.  No where in the document does it say = "that's the only
version you should use".

<tp>
Yes, my concern is more one of Fear, = Uncertainty and Doubt as opposed to hard engineering, but this is = security so it behoves us to be cautious.  I see many strands

Security is about operational practices and
draft-ietf-opsec-ns-impact
looks at what may be = difficult or impractical with TLS 1.3 compared to
TLS 1.2. =  Note that it is an I-D and it might be a year or two before
the IETF gets to decide whether or not to publish it as an = RFC by which
time all sorts of things might have happened. =  The issues in the I-D have
appeared on the TLS WG = list and been rejected.  The I-D was proposed for
adoption by the TLS WG and was rejected although it did get = some review
and constructive feedback, that is, its = description of the behaviour of TLS1.3 has been reviewed.
I = commend that I-D to anyone looking to migrate to TLS1.3 who has anything = more than
an HTTP web server.

Part of the ethos of the TLS WG is that where there is a = conflict
between the security of an individual and that of = an organisation then
the former takes precedence which I = see as relevant here.

TLS, like SSL before = it, has little concern with the authentication of
the = user, that often being done with renegotiation.  For OAM in = general,
and SNMP in particular, user authentication is = paramount; the protocol
must yield an authenticated = identity.  Given the major reconstruction of
TLS with = 1.3, I would not assume that the user identity is ok without a
careful study.  SNMP prohibited renegotiation as TLS1.3 = has done for
different reasons.  The TLS WG has just = approved an I-D
draft-ietf-tls-exported-authenticator
which offers a replacement for renegotiation; is that ok for = SNMP?
probably not. The approach to signature schemes has = changed in TLS 1.3;
is there any impact on user = certificate chains?  Much of the work on
TLS1.3 was = on facilitating 0-RTT; is that ok?  I think that given
security is involved, then TLS 1.3 and all the TLS1.3 = extensions need
careful examination from the perspective = of delivering an authenticated
user identity before I = would regard it as... well, not safe, because I
never say = anything is safe but rather without any risk that I can see.

My background is operations, not security, so = I have a 101 understanding
of security and TLS (but will = never be a cryptographer:-)

HTH

Tom Petch
--
Wes = Hardaker
USC/ISI


= --Apple-Mail=_1C4020F3-1B49-4320-91F5-3599DB973FCC--