Re: [Ace] EST over CoAP

Hannes Tschofenig <> Tue, 15 May 2018 08:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0261F12D77A for <>; Tue, 15 May 2018 01:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, 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 t_zWv1xXYLBi for <>; Tue, 15 May 2018 01:27:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B41491200E5 for <>; Tue, 15 May 2018 01:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lx10mw702xudI7zGrrvOH/2mCB83pvQbSk2khhXiJ0Q=; b=mNhq15M+P9V4gLy2rSZxDs35GDiXTS9Z3FhOj5/IKttaojqp3QMWGzXx2lfVg9mH+pNKLL8wEaVCjVyGuueOiwHdntdD7YWPh4qJZ+A4Mpxqah7B7ogK//inD9FDbgw5ucr/lHra6DW696CtJORyg0E4sMx2SniLRhVPvB1ONL4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 08:27:18 +0000
Received: from ([fe80::7c43:c1a5:4f69:5365]) by ([fe80::7c43:c1a5:4f69:5365%17]) with mapi id 15.20.0755.018; Tue, 15 May 2018 08:27:17 +0000
From: Hannes Tschofenig <>
To: "Panos Kampanakis (pkampana)" <>, "" <>
Thread-Topic: EST over CoAP
Thread-Index: AdPrYipD0kyce1IOREqwxYCd2nFDSgAKCPZwAACDJXAAAGyyQAAlwdwA
Date: Tue, 15 May 2018 08:27:17 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1424; 7:Td8gr13By9xXp5kvxqBBYA9XJWZ9GLZazWKAM6IPruud9MWtzYeUUAlQ3licUqZxHl8pmY2mbd+xOQWb+S+fpug22QuLkFUk3UTGQG3nD31MgDTe++Fw85NKztAK5Hw4aY9CZ15jirEI7dkm+4MZEI4ZNlrJQLGnYFD5Dl1BZ4PZFilP+NEmLw6yS4ebsUN64Xe63c4o+AUPCtSv+qsSHPe4tX4bbxCoiqtconSdQgM6SB2DqOA9LjepWi8zsP4S
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1424;
x-ms-traffictypediagnostic: VI1PR0801MB1424:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(192374486261705)(95692535739014)(21748063052155)(87864910995729);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0801MB1424; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1424;
x-forefront-prvs: 0673F5BE31
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(366004)(376002)(396003)(53754006)(40434004)(189003)(199004)(59450400001)(3480700004)(110136005)(106356001)(5890100001)(86362001)(53936002)(81166006)(3280700002)(81156014)(55016002)(105586002)(7736002)(14454004)(6506007)(53546011)(2900100001)(790700001)(8676002)(9326002)(229853002)(6436002)(6116002)(606006)(74316002)(966005)(186003)(72206003)(3846002)(2501003)(478600001)(236005)(5250100002)(316002)(66066001)(93886005)(8936002)(2906002)(476003)(9686003)(33656002)(7696005)(99286004)(6246003)(486006)(3660700001)(76176011)(11346002)(5660300001)(446003)(26005)(7116003)(6306002)(68736007)(25786009)(21615005)(97736004)(102836004)(54896002)(15398625002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1424;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: jyxZudPYeJeDmL2HZhapq6O5ce4n4CwRJQeqGgpLz6cBGYbtuFgfFS+Gv13pPHHkswUs48IgXzYMuMlT5ppVDvok2Mk7LWbIAjyoR60zwdt1OZ3bQZdp06BnkUrAKQIzwjBhlI3HB5nWvPql/MQxhHoojogGLL/qXXG5lrQDke0SplqJZZCPHWedfLIzPIXc
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112BB24EA1AD68B1EEA0DB5FA930VI1PR0801MB2112_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: b27a4d13-fe9e-4508-b017-08d5ba3dab8a
X-MS-Exchange-CrossTenant-Network-Message-Id: b27a4d13-fe9e-4508-b017-08d5ba3dab8a
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 08:27:17.4995 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1424
Archived-At: <>
Subject: Re: [Ace] EST over CoAP
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 May 2018 08:27:26 -0000

Hi Panos,

I would say forget class 1 devices when you want to use public key crypto. (and  since it revisits the earlier analysis) was a problem with understanding where the entropy comes from. If you take a regular desktop Linux and remove keyboard, mouse, disk drive, complex process scheduling etc. then the ordinary entropy sources are suddenly gone. That was the problem identified in that paper.

I am worried about keys across devices. For this reason we have standardized protocols to allow you to provision devices with new keys. Here is a whitepaper published not too long ago that discusses the issue, see

I believe you would agree with me that there is a lot of value in the public key crypto since you don't have to expose the private key. If your design suddenly still requires this then you are losing some of the good properties of public key crypto systems.


From: Panos Kampanakis (pkampana) []
Sent: 14 May 2018 21:24
To: Hannes Tschofenig;
Subject: RE: EST over CoAP

Your recommendation about having the right hardware is valid and what everyone should do as much as possible. What about Class 1 OEMs that cannot add the hardware you are recommending? Or even the ones that will not comply with the recommendations for their own reasons? We can't forget about those.

Is the vulnerability that you were referring to that the RA or CA have to generate the key? Trust of these entities needs to be established or this model falls apart anyway. It is up to the admin to decide if it trusts the Registrar will not store and reveal the private keys or generate insecure keys on the device itself. I am more concerned about this vulnerability where some thousands of devices have the same identity and now they can all impersonate each other in my network as shown in and

We agree on the other ephemeral keys used in secure communications. Good hardware would solve these issues. Without secure hardware some of these communications could be decrypted assuming the right resources. Even though, decrypting some data per connection is a concern, I don't think that the risk is as high as a compromised identity. Also, the former concern does not mean we should not have an option to eliminate the latter.

About the Proxy section 6, I would like to see comments about in in the next iteration, as we have updated to try to address some of these comments.

From: Ace [] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 10:14 AM
To: Panos Kampanakis (pkampana) <<>>;<>
Subject: Re: [Ace] EST over CoAP

Hi Panos,

Thanks for sharing this info.

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.
You do not only need to have access to random numbers during key generation but also later when you use nonces, a DH exchange, create session keys, and IVs, and potentially even for signature generation. If you use a protocol that is not based on nonces then you may use one that relies on timestamps, which may not make the story necessarily easier.

Random number key generation is also not necessarily costly either (neither in terms of energy cost nor in terms of hardware costs).

Hence, I think you should consider the server-side key generation very carefully since you are essentially destroying the benefits of public key crypto and introduce a big vulnerability.

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


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

From: Panos Kampanakis (pkampana) []
Sent: 14 May 2018 15:58
To: Hannes Tschofenig;<>
Subject: RE: EST over CoAP

Hi Hannes,

To address your question about server-side key gen, below is the explanation we have put in the draft already and will be in the next iteration
   Constrained devices sometimes do not have the necessary hardware to
   generate statistically random numbers for private keys and DTLS
   ephemeral keys.  Past experience has shown that cheap endpoints
   sometimes generate numbers which could allow someone to decrypt the
   communication or guess the private key and impersonate as the device.
   Studies have shown that the same keys are generated by the same model
   devices deployed on-line.

   Additionally, random number key generation is costly, thus energy
   draining.  Even though the random numbers that constitute the
   identity/cert do not get generated often, an endpoint may not want to
   spend time and energy generating keypairs, and just ask for one from
   the server.

   In these scenarios, server-side key generation can be used.  The
   client asks for the server or proxy to generate the private key and
   the certificate which is transferred back to the client in the
   server-side key generation response.

This is a need that we have heard from customers at Cisco.

About the proxy-Registrar question, we already have made the change in the working copy of the draft as well. We no longer call this functionality proxying, but instead use the concept of the registrar that terminates the connection and establishes the next one.

We didn't add any new features in the doc after removing the BRSKI stuff.

If you want an early preview to comment on, we can share the repository with you.


From: Ace [] On Behalf Of Hannes Tschofenig
Sent: Monday, May 14, 2018 5:05 AM
Subject: [Ace] EST over CoAP

Hi all,

At IETF#101 Peter presented a list of open issues with the EST over CoAP draft, see

-        Operational parameter values

-        Server side key generation using simple multipart encoding

-        Explain trust relations for http/coap proxying

I have challenged the usefulness of the server-side key generation during the meeting but in general I am curious where we are with the document. It would be great to get it finalized. It appears that we are adding new features and therefore will not be able to complete the work in any reasonable timeframe.

So, do we have a plan for how to complete the document?


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.
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.