Re: [Ace] EST over CoAP: Randomness

Esko Dijk <esko.dijk@iotconsultancy.nl> Tue, 14 May 2019 18:56 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
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 346A81200B5 for <ace@ietfa.amsl.com>; Tue, 14 May 2019 11:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.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 oGcQXfO4_VTw for <ace@ietfa.amsl.com>; Tue, 14 May 2019 11:56:36 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150124.outbound.protection.outlook.com [40.107.15.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28E31200B1 for <ace@ietf.org>; Tue, 14 May 2019 11:56:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b+5WBznYcb/lo/4nPATIzBoJCe9mdH4Fj+bKsQCjV1o=; b=IhMuRyLb4SFpRQgoX8jQ6NKZdJdLtYoDIJ6qwPzMg8Ce2Rs8+G1vcviKG+ql67i2tmJMDzCv2LA0rFStDzaHiyMMWyPk3j6IWBU+mowC2bqsf0nJ4URcIVPi45npJrwSaRS3vMZa2b0p7/gwRZAAxxPw9fYerxCxbk4vUtSmSyE=
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0565.EURP190.PROD.OUTLOOK.COM (10.175.242.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Tue, 14 May 2019 18:56:32 +0000
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::c46d:5ae5:fe3e:ca20]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::c46d:5ae5:fe3e:ca20%8]) with mapi id 15.20.1878.024; Tue, 14 May 2019 18:56:32 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EST over CoAP: Randomness
Thread-Index: AdUGcOnxX76zbRm2S2qe/nEWIh3V6AAamrQAAAw3WYAACv9EMAAPxWTgACLZPZAAoLfO4A==
Date: Tue, 14 May 2019 18:56:32 +0000
Message-ID: <DB6P190MB0054FE4F99040ACB0CEF267DFD080@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
References: <DBBPR08MB45393CDF71E7DB02F6C6938CFA330@DBBPR08MB4539.eurprd08.prod.outlook.com> <MWHPR11MB18386309CD27A19485A6B204C90C0@MWHPR11MB1838.namprd11.prod.outlook.com> <DBBPR08MB4539CB2F66FB6DB66E30776FFA0C0@DBBPR08MB4539.eurprd08.prod.outlook.com> <MWHPR11MB18389FB713EB9DEDDC75BA99C90C0@MWHPR11MB1838.namprd11.prod.outlook.com> <DB6P190MB0054CCBC63956CBDFF8E0F37FD0C0@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM> <DBBPR08MB45396D216551692BCE594780FA080@DBBPR08MB4539.eurprd08.prod.outlook.com>
In-Reply-To: <DBBPR08MB45396D216551692BCE594780FA080@DBBPR08MB4539.eurprd08.prod.outlook.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl;
x-originating-ip: [2001:1c02:3101:4800:4c05:986f:8d90:9390]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 91cb4556-b90f-475d-82c3-08d6d89de171
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DB6P190MB0565;
x-ms-traffictypediagnostic: DB6P190MB0565:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DB6P190MB05656CAA92160FA72BAF2361FD080@DB6P190MB0565.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(136003)(396003)(39830400003)(40434004)(189003)(199004)(74482002)(99286004)(25786009)(71190400001)(74316002)(14454004)(33656002)(71200400001)(14444005)(5024004)(6436002)(256004)(508600001)(229853002)(2501003)(9686003)(55016002)(66556008)(66476007)(64756008)(53936002)(46003)(73956011)(76116006)(7696005)(86362001)(110136005)(102836004)(476003)(53546011)(6506007)(2906002)(446003)(54896002)(6306002)(76176011)(606006)(236005)(486006)(5660300002)(44832011)(52536014)(9326002)(316002)(81156014)(8936002)(6116002)(7736002)(68736007)(186003)(66946007)(8676002)(66446008)(11346002)(81166006)(6246003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0565; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: KgZp+mB8tOAPC7l+hu4gOIsWKEq+QQarHj7ySZVfceDPpErlEz7THfXdOLd47Of7AXQ+MEWk/XaigYgSEuboprdL6P/jQ7YmkdD9pyqKooiIqpLWNswRc8o3TOAIidRHhyzzQr8jQ1oU1JhtLteKgW+ghr5OpjbViMmoyvErkyQQKDUZ9UxwmAw2JFwCrqlubmgHaIibkEZRUzP3+CMreRcGgRHh+ErW3TuBIE9Ok5uSK7khR7pbS5tLrBgWj/OFiEGnrjYYvvdkheQ9FXjM/lyQS81NZefS9YZNJEAq5K9fVF0Kb82UqO/Z8dFuzGpdcUXD3DhM9udYjqGnWuBB71UiHZTFvSse1+PSX697dLFyajkdWYOGrG6m5UgTj+UPjtTIKEKpmtVoi00HZtIWPBR+aH5hFdpYRIPcVa8ao9g=
Content-Type: multipart/alternative; boundary="_000_DB6P190MB0054FE4F99040ACB0CEF267DFD080DB6P190MB0054EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-Network-Message-Id: 91cb4556-b90f-475d-82c3-08d6d89de171
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 18:56:32.2030 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0565
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/er4-hIbYMHKZNpy1Zd9u175lAg4>
Subject: Re: [Ace] EST over CoAP: Randomness
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 14 May 2019 18:56:39 -0000

Hi Hannes,

Agree. The draft is already referencing RFC 7925, so it could additionally reference Section 12 (https://tools.ietf.org/html/rfc7925#section-12) which explains that randomness is also needed for all DTLS handshakes. What I mention about “being able to trust the randomness level” is then maybe a more psychological requirement rather than technical. A powerful server with RTC just sounds more capable to do private key generation than an IoT device, which is why server-side keygen may be preferred ;)

Esko

From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Sent: Tuesday, May 14, 2019 18:46
To: Esko Dijk <esko.dijk@iotconsultancy.nl>nl>; Panos Kampanakis (pkampana) <pkampana@cisco.com>om>; ace@ietf.org
Subject: RE: [Ace] EST over CoAP: Randomness

Hi Esko,

good to hear from you.


  *   Another reason for server-side keygen can be that an IT department/manager wants it that way. There could be a policy that the keypairs for all domain certificates must be created by the systems under direct control of the IT department. (E.g. to comply with other policies or to be able to trust the randomness level. Or just because that was the way it always has been when PCs were provisioned with certificates.)  This could be listed as an additional reason.

For readers interested in making informed decisions I believe it is worthwhile to point out that they need random number generation capabilities on IoT devices – not just for the private key generation in context of the EST exchange. I fear that some people, including IT managers, just glance over the details and focus on isolated aspects. I am sure you agree with me that this would be a too simplistic view.

Ciao
Hannes

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.