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
- [core] OSCOAP -02: sequence number reuse? Christian Amsüss
- Re: [core] OSCOAP -02: sequence number reuse? Göran Selander
- Re: [core] OSCOAP -02: sequence number reuse? Christian Amsüss