Re: [Ace] EDHOC standardization
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 02 November 2018 22:52 UTC
Return-Path: <mcr@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 27D74128B14 for <ace@ietfa.amsl.com>; Fri, 2 Nov 2018 15:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 opGUvuozx7gt for <ace@ietfa.amsl.com>; Fri, 2 Nov 2018 15:52:26 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F8C127598 for <ace@ietf.org>; Fri, 2 Nov 2018 15:52:26 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [58.64.45.2]) by relay.sandelman.ca (Postfix) with ESMTPS id 5B8AB1F8BE; Fri, 2 Nov 2018 22:52:22 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5365268B; Sat, 3 Nov 2018 04:21:55 +0530 (IST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: John Mattsson <john.mattsson@ericsson.com>
cc: "alvador.p.f@um.es" <alvador.p.f@um.es>, "ace@ietf.org" <ace@ietf.org>
In-reply-to: <379B1A31-1F7E-43A6-A518-4398570CBBC7@ericsson.com>
References: <379B1A31-1F7E-43A6-A518-4398570CBBC7@ericsson.com>
Comments: In-reply-to John Mattsson <john.mattsson@ericsson.com> message dated "Fri, 02 Nov 2018 12:31:16 +0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 03 Nov 2018 05:51:55 +0700
Message-ID: <16572.1541199115@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Wk6Np17Jk1tJ98B__bWPOvrzTYQ>
Subject: Re: [Ace] EDHOC standardization
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: Fri, 02 Nov 2018 22:52:29 -0000
John Mattsson <john.mattsson@ericsson.com> wrote: > of negotiation is still needed. The current plan for the next version > is to introduce cipher suites and to let the cipher suite with value 0 > indicate that algorithms have been negotiated out-of-band. I agree with the idea that some common default should be very easy to refer to, but I don't like the idea that the gateway has to remember what the out-of-band "default" is on a per-device basis. I would say that we need at least 0/1, so that we can say that it's the current vs the "new" default. If you consider the case where the sensor is on very low bandwidth connection (I would say LoRaWAN, but I am not well qualified in that space). The sensor gets visited every two or three years by a technician (if only to make sure that the sensor is still where it is supposed to be). While there new firmware updates are applied, and as a result the algorithm defaults are updated. During the cycle, some devices are updated and some are still old. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
- [Ace] EDHOC standardization Salvador Pérez
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Salvador Pérez
- Re: [Ace] EDHOC standardization Rene Struik
- Re: [Ace] EDHOC standardization Antonio Skarmeta
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Göran Selander
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Owen Friel (ofriel)
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Ace] EDHOC standardization Jim Schaad
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- [Ace] (protocol flows) Re: [Lwip] EDHOC standardi… Rene Struik
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- [Ace] (details on use case scenario?) Re: [Lwip] … Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander