Re: [Isms] Question regarding RFC 6353

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 17 July 2020 16:11 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 <isms@ietfa.amsl.com>; 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 <isms@ietfa.amsl.com>; 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 <isms@ietf.org>; 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 <j.schoenwaelder@jacobs-university.de>
To: Kenneth Vaughn <kvaughn@trevilon.com>
Cc: isms@ietf.org
Message-ID: <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kenneth Vaughn <kvaughn@trevilon.com>, 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: <https://mailarchive.ietf.org/arch/msg/isms/_evq4BgPXEP9Hc53tjCIbXY6afc>
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 <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isms/>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=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         <https://www.jacobs-university.de/>