Re: [Ace] EDHOC standardization

Michael Richardson <> Fri, 02 November 2018 22:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27D74128B14 for <>; Fri, 2 Nov 2018 15:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id opGUvuozx7gt for <>; Fri, 2 Nov 2018 15:52:26 -0700 (PDT)
Received: from ( [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0F8C127598 for <>; Fri, 2 Nov 2018 15:52:26 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id 5B8AB1F8BE; Fri, 2 Nov 2018 22:52:22 +0000 (UTC)
Received: by (Postfix, from userid 179) id 5365268B; Sat, 3 Nov 2018 04:21:55 +0530 (IST)
From: Michael Richardson <>
To: John Mattsson <>
cc: "alvador.p.f\" <>, "ace\" <>
In-reply-to: <>
References: <>
Comments: In-reply-to John Mattsson <> 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: <>
Archived-At: <>
Subject: Re: [Ace] EDHOC standardization
X-Mailman-Version: 2.1.29
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: Fri, 02 Nov 2018 22:52:29 -0000

John Mattsson <> 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  [ 
]        |   ruby on rails    [