Re: [core] OSCOAP -02: sequence number reuse?

Christian Amsüss <c.amsuess@energyharvesting.at> Wed, 22 March 2017 15:49 UTC

Return-Path: <c.amsuess@energyharvesting.at>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255DC1299C4; Wed, 22 Mar 2017 08:49:32 -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] 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 pDOOXv5-KlXx; Wed, 22 Mar 2017 08:49:30 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5E71299D7; Wed, 22 Mar 2017 08:49:29 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8001:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8CE9646988; Wed, 22 Mar 2017 16:49:27 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id AE8EE2A; Wed, 22 Mar 2017 16:49:26 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 77BAF3BE; Wed, 22 Mar 2017 16:49:26 +0100 (CET)
Received: (nullmailer pid 24161 invoked by uid 1000); Wed, 22 Mar 2017 15:49:26 -0000
Date: Wed, 22 Mar 2017 16:49:26 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: Göran Selander <goran.selander@ericsson.com>
Cc: "draft-ietf-core-object-security@ietf.org" <draft-ietf-core-object-security@ietf.org>, draft-tiloca-core-multicast-oscoap@ietf.org, "core@ietf.org" <core@ietf.org>
Message-ID: <20170322154925.a2d737yteqfpa5du@hephaistos.amsuess.com>
References: <20170321195624.evktq3olnpfugaw7@hephaistos.amsuess.com> <D4F7D23D.7A2A8%goran.selander@ericsson.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="taackkpzdvlphsm2"
Content-Disposition: inline
In-Reply-To: <D4F7D23D.7A2A8%goran.selander@ericsson.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lRv8axFShxNjsO16d4NuoewtGuw>
Subject: Re: [core] OSCOAP -02: sequence number reuse?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 15:49:32 -0000

On Wed, Mar 22, 2017 at 10:17:02AM +0000, Göran Selander wrote:
> Judging by your proposal you got the point despite these errors. I’ve
> updated the draft, please check if I got it right:
>
> As an exercise, verify that this construction works even if client and
> server change roles. And also with Observe in that case.

As I read it now, it should work. (Without observe and role reversal, it
works in my implementation, the rest is pending but requires some more
streamlining in the API).

Where I do see trouble coming up is when the multicast proposals get
warmed up again. For then, I can envision at least two solutions[1], so
I suppose we're good.

Best regards
Christian


[1]: (Diverting this into a footnote so it's on record, even though it's
not relevant for this thread itself, but might spin off a new one for
multicast:)

* Approach A: Unless only one node that is allowed to do requests, all
  responses must bear a sequence number of their own instead of
  mirroring.

  This adds back the sequence numbers to the message length. (As the
  multicast responses probably need the KID as well, this just means
  that the compressed responses take the [partIV, kid, ciphertext] form.

* Approach B: Allocate not 1 but n "mirror spaces". This would take
  ceil(log2(n_participants)) bits off the sequence number range, but the
  responders would then only need to send their KID (sender ID) and the
  ciphertext.

  (Basically they'd encode the peer number in reverse bit sequence in
  the partial IV, where 0 is used for sequence numbers the device has
  dealt itself, 1 is for sequence numbers out of the list of the first
  partner (or the unicast partner), and 2 etc is for sequence numbers of
  other people's pools.

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614