Re: [Ace] EDHOC standardization

Benjamin Kaduk <kaduk@mit.edu> Mon, 05 November 2018 09:38 UTC

Return-Path: <kaduk@mit.edu>
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 5E57C130EB0 for <ace@ietfa.amsl.com>; Mon, 5 Nov 2018 01:38:20 -0800 (PST)
X-Quarantine-ID: <Xa9ZEPCcTafT>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Xa9ZEPCcTafT for <ace@ietfa.amsl.com>; Mon, 5 Nov 2018 01:38:18 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6ED0130E37 for <ace@ietf.org>; Mon, 5 Nov 2018 01:38:16 -0800 (PST)
X-AuditID: 1209190c-06bff700000049b7-9d-5be00f86d9d1
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 55.36.18871.78F00EB5; Mon, 5 Nov 2018 04:38:15 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA59cDgZ023453; Mon, 5 Nov 2018 04:38:13 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA59c8Sb021454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 5 Nov 2018 04:38:11 -0500
Date: Mon, 5 Nov 2018 03:38:07 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "alvador.p.f@um.es" <alvador.p.f@um.es>, "ace@ietf.org" <ace@ietf.org>, John Mattsson <john.mattsson@ericsson.com>
Message-ID: <20181105093807.GY54966@kduck.kaduk.org>
References: <379B1A31-1F7E-43A6-A518-4398570CBBC7@ericsson.com> <16572.1541199115@dooku.sandelman.ca> <20181103151621.GH54966@kduck.kaduk.org> <31833.1541384214@dooku.sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <31833.1541384214@dooku.sandelman.ca>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixCmqrNvO/yDa4O5DPovv33qYLdZ1X2G1 ODVzN5NFz6F+dgcWj19fr7J5LFnyk8mjZc4eZo9zL9tYAliiuGxSUnMyy1KL9O0SuDLmPVQr OMlfsbx/A2MD4wPuLkZODgkBE4kN31tYuxi5OIQE1jBJzH7TxQbhbGCUmHvqJpRzh0ni4MqX TCAtLAIqEm23VjCC2GxAdkP3ZWYQW0RAT2L5kWdgcWaBeolLfRvA6oUFNCQ2dm1lB7F5gdbN O9vGAjF0F6PE2oV32CASghInZz5hgWjWkrjxD2QZB5AtLbH8HweIySlgJDFvTzJIhaiAssTe vkPsExgFZiFpnoWkeRZC8wJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxjB wSzJs4PxzBuvQ4wCHIxKPLwSQfejhVgTy4orcw8xSnIwKYnypl8CCvEl5adUZiQWZ8QXleak Fh9ilOBgVhLhVWJ7EC3Em5JYWZValA+TkuZgURLnndCyOFpIID2xJDU7NbUgtQgmK8PBoSTB KwSMWiHBotT01Iq0zJwShDQTByfIcB6g4TP5QIYXFyTmFmemQ+RPMSpKifPGgyQEQBIZpXlw vaBkI5G9v+YVozjQK8K82SBVPMBEBdf9CmgwE9Dgb3/ugwwuSURISTUwMvq43no1z3K9X9ls xSy5RPuAlVOr+K4tkxPTOldoW87Yf092ecC3G8EFt3XO9/m81F+wVFlqytYZTvISW9flP9Xg Noxe5er2d8nSqATbntTK9fYHtI+ksG3acO+DY941vVu3Xa85N+luZRTj/X9aX+3gp09vt8/I P2Gos/NzAeumP+s3P2E3UGIpzkg01GIuKk4EAHXOyv0RAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/PM1Gn7jFaC4Vv7cqDkpxf-JCwgE>
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: Mon, 05 Nov 2018 09:38:27 -0000

On Mon, Nov 05, 2018 at 09:16:54AM +0700, Michael Richardson wrote:
> 
> Benjamin Kaduk <kaduk@mit.edu>; wrote:
>     >> 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.
> 
>     > Are you proposing that the management of the 0/1-to-algorithm mapping
>     > be managed on a per-deployment basis or by the IETF?
> 
> I think that the existing proposal was that 0 means "negotiated out-of-band",
> which implies that it's a per-deployment basis.
> 
> I'm proposing that instead of having 0 mean "some local default",
> I'm suggesting that 0 mean, "some local default 0" and 1 mean, "some other
> local default 1", which lets the default be updated without a flag day.

That feels like a potentially awkward provisioning problem.  I guess the
idea is that any given node is only going to do 1 or 0 and not both?  Maybe
that helps.

Thanks,

Ben