Re: [Isms] Question regarding RFC 6353

Wes Hardaker <wjhns1@hardakers.net> Tue, 21 July 2020 22:46 UTC

Return-Path: <wjhns1@hardakers.net>
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 <isms@ietfa.amsl.com>; 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 <isms@ietfa.amsl.com>; 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 <isms@ietf.org>; 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 <wjhns1@hardakers.net>
To: tom petch <ietfc@btconnect.com>
Cc: Kenneth Vaughn <kvaughn@trevilon.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "isms\@ietf.org" <isms@ietf.org>
References: <840CBD97-1D31-48EB-A210-65CC0B43FFDC@trevilon.com> <20200717161145.zytufnzyhizpyc5p@anna.jacobs.jacobs-university.de> <AM6PR07MB52222429E1B317A012AF5033A07C0@AM6PR07MB5222.eurprd07.prod.outlook.com>
Date: Tue, 21 Jul 2020 15:46:46 -0700
In-Reply-To: <AM6PR07MB52222429E1B317A012AF5033A07C0@AM6PR07MB5222.eurprd07.prod.outlook.com> (tom petch's message of "Fri, 17 Jul 2020 16:50:01 +0000")
Message-ID: <ybleep47ag9.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/isms/TOewB7fkgpwBzsAG6OFzIcO8vEU>
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: Tue, 21 Jul 2020 22:46:49 -0000

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".
-- 
Wes Hardaker
USC/ISI