Re: [Ace] EST over CoAP
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 14 May 2018 14:54 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 9821C12D94F for <ace@ietfa.amsl.com>; Mon, 14 May 2018 07:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 9UiDaiY4urtV for <ace@ietfa.amsl.com>; Mon, 14 May 2018 07:54:09 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1DA120227 for <ace@ietf.org>; Mon, 14 May 2018 07:54:09 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D75120090 for <ace@ietf.org>; Mon, 14 May 2018 11:06:16 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id C2CC92B58; Mon, 14 May 2018 10:53:48 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BF3662B47 for <ace@ietf.org>; Mon, 14 May 2018 10:53:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ace@ietf.org" <ace@ietf.org>
In-Reply-To: <VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <VI1PR0801MB21122D93F906F952E5E85C87FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <a4d27053f1d2431abee07d2597e14972@XCH-ALN-010.cisco.com> <VI1PR0801MB21125B520BA3DE027A49AFA6FA9C0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 14 May 2018 10:53:48 -0400
Message-ID: <30117.1526309628@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/D-Aiql4NqpCIzmv-pqAc4YAXWYw>
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 14:54:12 -0000
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 =-
- [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Michael Richardson
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Michael Richardson
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Michael Richardson
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Michael StJohns
- Re: [Ace] EST over CoAP Mohit Sethi
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Hannes Tschofenig
- Re: [Ace] EST over CoAP Panos Kampanakis (pkampana)
- Re: [Ace] EST over CoAP Mohit Sethi
- Re: [Ace] EST over CoAP Hannes Tschofenig
- [Ace] CA generated keys (was Re: EST over CoAP) Michael Richardson