Re: [Isms] Question regarding RFC 6353

tom petch <> Wed, 22 July 2020 09:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CA233A0889 for <>; Wed, 22 Jul 2020 02:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ReF_IUzB5Q9 for <>; Wed, 22 Jul 2020 02:40:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BEC03A0886 for <>; Wed, 22 Jul 2020 02:40:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; 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;; 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; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (2603:10a6:20b:134::11) by (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 ([fe80::893c:ca97:acbf:1c76]) by ([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 <>, "" <>
Thread-Topic: Question regarding RFC 6353
Thread-Index: AQHWX7DXfWLA5tI62EqxNR3OP8lxTqkTVhkb
Date: Wed, 22 Jul 2020 09:40:19 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-GB
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
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:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; 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-MS-Exchange-CrossTenant-AuthAs: Internal
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-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 <>
Sent: 21 July 2020 23:46
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".

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
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
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:-)


Tom Petch
Wes Hardaker