Re: [Ace] EST over CoAP

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 14 May 2018 18:49 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781E1276AF for <ace@ietfa.amsl.com>; Mon, 14 May 2018 11:49:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.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 uIBRpEAvG-nb for <ace@ietfa.amsl.com>; Mon, 14 May 2018 11:49:11 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10055.outbound.protection.outlook.com [40.107.1.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36921273E2 for <ace@ietf.org>; Mon, 14 May 2018 11:49:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7ZIHhCjJRsbmOgpe7FIuWi+gGGCUYH+l++KMaCml4+4=; b=WdiRzhMyw4yZA6fecEwO4QYo4PLYv7G7btEH3jN+SGVeugaSpQumhIw+BftjgxfKuLrsKI7ertldP4Ddy/1rBNKeng3RdKDPQ5AIUuT+ZY+AlhiyE/iWzip6OB+dzcXmLl0j33jCFfwNa1jRa9tb5Hmhln9Z4CiI44akHfvj3OE=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2127.eurprd08.prod.outlook.com (10.168.68.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Mon, 14 May 2018 18:49:05 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Mon, 14 May 2018 18:49:05 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EST over CoAP
Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAcCgAAAAQuHQ
Date: Mon, 14 May 2018 18:49:05 +0000
Message-ID: <VI1PR0801MB21125E90F6D045A50DC52E40FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB21122D93F906F952E5E85C87FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <a4d27053f1d2431abee07d2597e14972@XCH-ALN-010.cisco.com> <VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <30117.1526309628@localhost>
In-Reply-To: <30117.1526309628@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [156.67.194.220]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2127; 7:NNmiXQTR1T5ZW/OBn2MehjhdMt5RNxky5N422mxDas+KVlccLn/6GZlT9FPEnUO8lTXZdx28ApIC6bqUBzRCef/1DlAb3nVSrsFrC7Zw5SAz98Hy2lCGTeYN+FkFCbPnr/LeP86egnOD72fnMnvZ4wnls5VDKsADfoqop5mUcBf+4WsBDiX2DSLsuAB3FQuScb7vQRiOT92nKUkAi4/2jr57EyBy4SblQIkEGU3wpxHh6tDb9tNHvEnnoQPlZ4dH
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2127;
x-ms-traffictypediagnostic: VI1PR0801MB2127:
x-microsoft-antispam-prvs: <VI1PR0801MB2127BC398DFD525BCB458498FA9C0@VI1PR0801MB2127.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(180628864354917)(192374486261705)(237425016533630);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0801MB2127; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2127;
x-forefront-prvs: 067270ECAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39380400002)(396003)(39860400002)(13464003)(51444003)(189003)(199004)(40434004)(76176011)(11346002)(53546011)(53936002)(2501003)(81156014)(81166006)(26005)(99286004)(186003)(74316002)(8676002)(8936002)(7736002)(305945005)(55016002)(86362001)(68736007)(5250100002)(9686003)(6306002)(59450400001)(5890100001)(5660300001)(446003)(476003)(6506007)(7696005)(6246003)(25786009)(486006)(102836004)(93886005)(6116002)(3846002)(2906002)(6436002)(478600001)(2900100001)(33656002)(229853002)(14454004)(316002)(66066001)(110136005)(106356001)(97736004)(966005)(3280700002)(72206003)(3660700001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2127; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: kwf+ZcWXN4GvvxhyJ+TrA25uFfKyviHymHule8A9H7iZ+lv7Xb9KJlfiH89z0XSJ41IF2FHFCfT2NABDnb0jTGTx6Tc5RoyK6Uz8BsE3T6lCyaWtC2Jt8zpRTGgJblEE8yhQs853QYlPcIFv2QLU6JDFTcSV2u+2GfhC0lHW9UV+Qgwi4a7ZDCKKzazAczT7
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: baeac7bd-a766-4095-e0f3-08d5b9cb5e58
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: baeac7bd-a766-4095-e0f3-08d5b9cb5e58
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2018 18:49:05.4238 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2127
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/YcJKInVhN9tUSV4gKgK1Lh6wnSc>
Subject: Re: [Ace] EST over CoAP
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 May 2018 18:49:14 -0000

Here is my personal take on this: you have to do your threat assessment to find out what attacks you care about. This will determine your hardware requirements (not the other way around). At a minimum you will have to figure out how to provide randomness in your design and that can come at a very low cost. For example, if I use ST's MCU finder http://www.st.com/en/development-tools/st-mcu-finder.html and search for microcontrollers that have TRNG support then I get 410 results (only for STM MCUs).

If you aim for devices that also provide ECC/RSA crypto in hardware + tamper-resistant key storage then we will move past the RFC 7228-type of constrained IoT device classes. You have can a look of what this means in context of Arm IP: https://developer.arm.com/products/system-ip/trustzone-security-ip

On a meta-level I have difficulties with the security design decisions made in IETF IoT-related groups since they swing back and forth between the extremes in pretty much no time. At the London IETF meeting I hear people talking about drafting guidelines for the use of new crypto algorithms with IoT devices since P256r1 and AES128-CCM is not good enough for them. At the same time I am having a hard time convincing people that using an unauthenticated identifier is not good for security.

Ciao
Hannes

-----Original Message-----
From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: 14 May 2018 16:54
To: ace@ietf.org
Subject: Re: [Ace] EST over CoAP


Hannes Tschofenig <Hannes.Tschofenig@arm.com>; wrote:
    > Regarding the randomness requirement and the energy consumption. We
    > have been a bit advocate for adding hardware-based random numbers to
    > devices since randomness is a basic requirement for most security
    > protocols.

I think that this is the future, and I very much agree with you.

There seems to be a stock of older designs which have gone through other kinds of validation (for instance, think about the engineering review of physical cases and PCB design for electric metering).

My impression is that there is a desire to significantly update the security profile of these devices (some of which are in the field already).  What was deployed had poor security, or had proprietary protocols and there is a desire to move it up to "par".

The other thing I hear is that the crypto libraries involved take some time to get FIPS-140 certified and so the one that the devices were deployed with do RSA only, and there is a desire to update them to ECDSA (or EdDSA), and means new keys.

I think that any device with any kind of TPM would rather generate it's own keys.  Whether it's a physical TPM, or some kind of TrustZone,etc. version.

    > In a nutshell, I think you are better of recommending OEMs to select
    > the right hardware for the given task.

I'd like to find some text that acknowledges the past, while setting things up better for the future.

    > PS: For the proxy work (in context of DTLS/TLS) you might want to reach
    > out to your co-worker Owen Friel.

he's in other loops already, but he seems shy to post to lists.

    > IMPORTANT NOTICE: The contents of this email and any attachments are

I wish your email system would omit this, as it's both meaningless and sometimes harmful.

--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works  -= IPv6 IoT consulting =-



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.