IETF Logo Mail Archive

Re: [Ace] EST over CoAP: Randomness

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 14 May 2019 19:28 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 DDB271200DE for <ace@ietfa.amsl.com>; Tue, 14 May 2019 12:28:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 oqlGROSqtSDr for <ace@ietfa.amsl.com>; Tue, 14 May 2019 12:28:23 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30065.outbound.protection.outlook.com [40.107.3.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572491200C4 for <ace@ietf.org>; Tue, 14 May 2019 12:28:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2xuOWgM5rewQmvFz0epD/gwVHJPD9+lviIRVbtbERH8=; b=gnQGBkx8986b9IaS6sA/wUMFFVywKpgoOKvYfxzINl+Cd/za1rwT920ZfeXuClVrxWnK9aSgizUjhwQGfl9bOfuaMdYmb/D9rpYG2NTqJnRLM+g6ES8vu+m36guxyaX+FllTNsI74ROaMU9YFZbbQARQ8GOKV+RE2oWkLgWW3T0=
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com (20.179.44.144) by DBBPR08MB4870.eurprd08.prod.outlook.com (20.179.46.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Tue, 14 May 2019 19:28:20 +0000
Received: from DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93]) by DBBPR08MB4539.eurprd08.prod.outlook.com ([fe80::3803:e042:abea:cd93%5]) with mapi id 15.20.1878.024; Tue, 14 May 2019 19:28:20 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>, "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EST over CoAP: Randomness
Thread-Index: AdUGcOnxX76zbRm2S2qe/nEWIh3V6AAamrQAAAw3WYAACv9EMAAPxWTgACLZPZAAoLfO4AABXdqQ
Date: Tue, 14 May 2019 19:28:20 +0000
Message-ID: <DBBPR08MB45392D26EC53653EF833437FFA080@DBBPR08MB4539.eurprd08.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> <DB6P190MB0054FE4F99040ACB0CEF267DFD080@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DB6P190MB0054FE4F99040ACB0CEF267DFD080@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
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: [217.140.103.75]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 00997f65-41ec-4d32-74c0-08d6d8a252f5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:DBBPR08MB4870;
x-ms-traffictypediagnostic: DBBPR08MB4870:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DBBPR08MB4870A187DFC0A52D8832F290FA080@DBBPR08MB4870.eurprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(396003)(136003)(346002)(199004)(189003)(40434004)(2906002)(74316002)(478600001)(72206003)(9686003)(53936002)(54896002)(6306002)(55016002)(99286004)(102836004)(2501003)(6246003)(53546011)(7696005)(6506007)(7736002)(76176011)(446003)(33656002)(236005)(76116006)(73956011)(66946007)(66556008)(6436002)(64756008)(66446008)(66476007)(186003)(8936002)(26005)(316002)(229853002)(14454004)(486006)(5660300002)(66066001)(68736007)(256004)(14444005)(5024004)(606006)(25786009)(52536014)(71200400001)(71190400001)(8676002)(476003)(3846002)(86362001)(6116002)(790700001)(81166006)(81156014)(11346002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:DBBPR08MB4870; H:DBBPR08MB4539.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: QbxjEzEZxded4EQ1ycvSrdVUaD0xpmmyKET5ZBPHNp5l4qL2Y6/4AT8Wvmx8QXn9o9/4pDbOc6jM6rzlkZkQ8TskdfCR1ZZo6cX5kEan1kUtCk3SjkMKyKd6+qhZBWne0kjIBCSd6XUnPL9UKq4IikfHHhAmdZx/k8XB1/VxlhXBKylpHGaiDpEOY9AJPfjzEJs6tmCsVXw0hLmDSIsz7QlvMMuGW6WSszI1WDe+d59OdKOf2r1k4mdHeZDfgLNDFlsza58Yx/pwXhI3PxYJ+ufN+01ygpbRlDMksuCLfQ5IdfscrEYkN7QF0ksZEmPVDgb/yHK7NIbm1FF551N4n1tp2YSJzqxBFv+mGxOPiwGbzRKJn/tTWQifDj+G2DrxDEYNHqhZMcBysvZPFjKabwInRgjlA1pVZ2wfy2iFpkc=
Content-Type: multipart/alternative; boundary="_000_DBBPR08MB45392D26EC53653EF833437FFA080DBBPR08MB4539eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 00997f65-41ec-4d32-74c0-08d6d8a252f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 19:28:20.6952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4870
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/EcYVIUe7mXnxfn8GR315LHfL1jc>
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 19:28:27 -0000

Esko,

your line of thought makes sense to me. I leave it to Panos to enhance the text.

Ciao
Hannes

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

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<mailto:Hannes.Tschofenig@arm.com>>
Sent: Tuesday, May 14, 2019 18:46
To: Esko Dijk <esko.dijk@iotconsultancy.nl<mailto:esko.dijk@iotconsultancy.nl>>; Panos Kampanakis (pkampana) <pkampana@cisco.com<mailto:pkampana@cisco.com>>; ace@ietf.org<mailto: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.
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.

v2.23.0 | Report a Bug | By Email