[core] OSCORE: Questions about Section 5.2

Jaro Fietz <jaro.fietz@aisec.fraunhofer.de> Thu, 11 October 2018 09:14 UTC

Return-Path: <jaro.fietz@aisec.fraunhofer.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 37D0B130DC7 for <core@ietfa.amsl.com>; Thu, 11 Oct 2018 02:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id w1O7h521ktvb for <core@ietfa.amsl.com>; Thu, 11 Oct 2018 02:14:25 -0700 (PDT)
Received: from mail-edgeKA24.fraunhofer.de (mail-edgeka24.fraunhofer.de []) (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 2F6FD130DC1 for <core@ietf.org>; Thu, 11 Oct 2018 02:14:22 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FpAADaE79b/xmnZsAYAUoaAQEBAQECA?= =?us-ascii?q?QEBAQcCAQEBAYFlAoELd2ZtOoN1iHWLV4FogjaWLjsNIA6DeEaEVyE4FgEDAQE?= =?us-ascii?q?CAQECAgJpHAyCZQQvHDsDAQEBAQEBJwEBAQEBAQEBAQEBAQEBARoCDTZXVl0CX?= =?us-ascii?q?w0BBwEBgxwBggEPiHmdCoEuH4QMAUuEXwUJAYs7gVg/gRInDIVhGQEBAhiBJwE?= =?us-ascii?q?BCIMXglcCjnOPHQcCgQqBAQSEQ4MVhmcGF4kgBYZrAYw0iV6BWSKBVTMaJIM8g?= =?us-ascii?q?iIDF4NGhRSFQG0BCYoZgj4BAQ?=
X-IronPort-AV: E=Sophos; i="5.54,367,1534802400"; d="scan'208,217"; a="10585598"
Received: from mail-mtadd25.fraunhofer.de ([]) by mail-edgeKA24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2018 11:14:19 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AACiE79b/xBhWMAYAUobAQEBAQMBA?= =?us-ascii?q?QEHAwEBAYFlAoELgV2BJ4N1iHWNP5kfDSCEBkaEdzgWAQMBAQIBAQJtHAyFY1Z?= =?us-ascii?q?dAl8NAQcBAYMcAYIBD4h5nQqBLh+EDAFLhF8FCQGNEz+BEicMhWEZAQECGIEnA?= =?us-ascii?q?QEIgxeCVwKOc48dBwKBCoEBBIRDgxWGZwYXiSAFhmsBjDSJXoFZIYFVMxokgzy?= =?us-ascii?q?CIgMXg0aFFIVAPTABCYoZgj4BAQ?=
X-IronPort-AV: E=Sophos; i="5.54,367,1534802400"; d="scan'208,217"; a="16496182"
Received: from fgdemucivp01ltm.xch.fraunhofer.de (HELO FGDEMUCIMP11EXC.ads.fraunhofer.de) ([]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/AES256-SHA; 11 Oct 2018 11:14:17 +0200
Received: from [] ( by FGDEMUCIMP11EXC.ads.fraunhofer.de ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 11 Oct 2018 11:14:16 +0200
To: <core@ietf.org>
CC: <stefan.hristozov@aisec.fraunhofer.de>, <jaro.fietz@gmx.de>, <martin.striegel@aisec.fraunhofer.de>
From: Jaro Fietz <jaro.fietz@aisec.fraunhofer.de>
Message-ID: <bd95ea38-7425-13d6-a955-1e60a5bd0945@aisec.fraunhofer.de>
Date: Thu, 11 Oct 2018 11:14:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------8138581241C82B2DC3495EE9"
Content-Language: en-US
X-TM-AS-Product-Ver: SMEX-
X-TM-AS-Result: No--5.274100-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/VO7jni8KxpLeWMvUD5KORd5jDuI>
X-Mailman-Approved-At: Thu, 11 Oct 2018 03:23:39 -0700
Subject: [core] OSCORE: Questions about Section 5.2
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Oct 2018 09:14:55 -0000

(resending this mail as I didn't confirm my mail address for over a week 
which is apparently too long)

Hello authors,

I'm currently implementing parts of OSCORE in C for a minimal OSCORE 
server. While working through the specification I encountered two 
questions so far, both regarding section "5.2. AEAD Nonce".

The first question is about the statement "left-pad the Sender ID of the 
endpoint that generated the Partial IV (ID_PIV) in network byte order 
with zeroes to exactly nonce length minus 6 bytes" (Section 5.2)
Given that the Partial IV is the sender sequence number [1], the ID_PIV 
is the Sender ID of the respective Sender Context. The Sender ID itself 
is defined as "Sender ID. Byte string used to [...]" (Section 3.1). 
Combining this with the original statement of "left-pad the Sender ID 
[...] in network byte order" assumes that byte strings have a network 
byte order. From my understanding only primitives with a size larger 
than a single byte can have / are affected by endianess. But a byte 
string consists of bytes, which don't have a byte order. No matter the 
host byte order, a byte string will always be represented equal on all 
machines. Thus I'm not sure how to interpret the paraphrased statement 
"encode a byte string in network byte order". Both oscore_californium 
and aiocoap just write the byte array to the nonce, which is what I 
think is meant and what I did as well.

The second question is regarding the statement "concatenate the size of 
the ID_PIV (a single byte S) with the padded ID_PIV and the padded PIV" 
(Section 5.2), especially the "size of the ID_PIV".
As reasoned above, ID_PIV is a byte-string. The size of a byte-string to 
me would be its length in bytes. Given [2] and my interpretation, the 
Sender ID of all relevant nodes in a network would have the same length, 
only different contents. While the (size, id)-pairs (1, [1]) and (2, 
[0,1]) would technically be different sender IDs, I don't know if 
implementations would actually honour that behaviour and if it would 
make sense from a deployment point of view. Thus, the reason for 
including the length of the Sender ID isn't obvious to me (yet, it may 
become more obvious when I work further through the specification). Thus 
my initial question was what length exactly would be included in the 
nonce, leaving me with two interpretations: First, just have the same 
length of the Sender ID in all packets, which would be its byte-length 
(assuming all Sender ID byte strings are configured to have the same 
length). Second, interpret the Sender ID as network byte order integer, 
strip its leading zeroes and take the resulting number's byte-length.
When looking through existing implementations, I in fact encountered 
both interpretations. The oscore_californium project used the length of 
the sender id array [3, 4, 5], while aiocoap uses the zero-stripped 
length of its number representation [6].

Which of these interpretations is correct, so which one should I implement?

If the Sender ID was an integer instead of a byte string, both above 
statements would be logical and make sense, but in the context of byte 
arrays the wording feels a little to me.


[1]: "The 'Partial IV' parameter. The value is set to the Sender 
Sequence Number." (Section 5)
[2]: "The maximum length of Sender ID in bytes equals the length of AEAD 
nonce minus 6, see Section 5.2." (Section 3.3)