Re: [core] OSCORE: Questions about Section 5.2

Francesca Palombini <francesca.palombini@ericsson.com> Wed, 24 October 2018 12:38 UTC

Return-Path: <francesca.palombini@ericsson.com>
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 76E98128C65 for <core@ietfa.amsl.com>; Wed, 24 Oct 2018 05:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level:
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ewWYQ3QT; dkim=pass (1024-bit key) header.d=ericsson.com header.b=fwY0CQ5r
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 MdbhbyA_zfbj for <core@ietfa.amsl.com>; Wed, 24 Oct 2018 05:38:37 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E99D1127332 for <core@ietf.org>; Wed, 24 Oct 2018 05:38:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540384714; x=1542976714; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dQz71/b1aeHJ5V4IiK7WSvRHJWynIWVK40upTsB5AyU=; b=ewWYQ3QTz4kzlZMQVA+b0wJT4xqrEJN5Ty80rQ2aE4DhkQrSozFvjWXOl95kIk07 Vbl56bvmpm6o5FLYWjRZhA0CG1mg2MlYDeVjY5jPKDVD9aGAVGQsdRSPn/jnt+tO FoIB+1yAD53wM0fRV1lBnKG11x+6xwBzwt4Vd5lS0fM=;
X-AuditID: c1b4fb25-a0b8c9e0000018b4-9b-5bd067ca97fe
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FA.85.06324.AC760DB5; Wed, 24 Oct 2018 14:38:34 +0200 (CEST)
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 24 Oct 2018 14:38:32 +0200
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 24 Oct 2018 14:38:32 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dQz71/b1aeHJ5V4IiK7WSvRHJWynIWVK40upTsB5AyU=; b=fwY0CQ5ra/CLQyJu+eepBvW4KH9Mm31MZ+UEW4g7nlFjOa6pKrd/qxK3DvrjLkSdTYGvQ4MIlSi77RCLNdPFMcKr1jdo/ChJ06ShKM9FpP6TEQrWCvAZt+iINxvQCfS4jM82sxY0tYdwV6Cix/TC3yjbG9DoCORnRBkhVGmWjoM=
Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com (10.168.188.140) by HE1PR0701MB2298.eurprd07.prod.outlook.com (10.168.127.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.15; Wed, 24 Oct 2018 12:38:30 +0000
Received: from HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5]) by HE1PR0701MB2746.eurprd07.prod.outlook.com ([fe80::c05a:fd61:6104:51e5%6]) with mapi id 15.20.1273.019; Wed, 24 Oct 2018 12:38:30 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Jaro Fietz <jaro.fietz@aisec.fraunhofer.de>, "core@ietf.org" <core@ietf.org>
CC: "martin.striegel@aisec.fraunhofer.de" <martin.striegel@aisec.fraunhofer.de>, "stefan.hristozov@aisec.fraunhofer.de" <stefan.hristozov@aisec.fraunhofer.de>, "jaro.fietz@gmx.de" <jaro.fietz@gmx.de>
Thread-Topic: [core] OSCORE: Questions about Section 5.2
Thread-Index: AQHUYUyN2HR6KcIsjE6krSaUOmntJaUui9yA
Date: Wed, 24 Oct 2018 12:38:30 +0000
Message-ID: <476ADF31-C987-4D24-9939-713BD3F6C6DC@ericsson.com>
References: <bd95ea38-7425-13d6-a955-1e60a5bd0945@aisec.fraunhofer.de>
In-Reply-To: <bd95ea38-7425-13d6-a955-1e60a5bd0945@aisec.fraunhofer.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [217.31.165.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2298; 6:EEEHhiBK8lnpH2awGuI8TdH9UgqGaamq2z/ETbUAhRijBQ7wUW2Fa0grQ9bt+HoQTsxX3nMJbtH/TNQ3a4GRYWokWchJl+S4sUYbsBVljeTdGh3xTjkeeL03YWwXDJmJ2PuwWa00EST9i9WW5sPy8KBIRGl76kAnSEtr0MEwZslFs9OiGobv1RDvwC54VLgrKsCwVbH9xyJUx+Z+Kd8g0kMs4dkA4wdwhd07Eoo7OVtR0eUrCzBd5rja+31XXC/RhYa8j/qC3etXd7TjuZ7MncN2oCUZsVeFLnQL1X3MNrBEhWljNWD75fnEwX0sdYY2lM8ES9q7GpG2rYp3ZJci1OEP4FwaX7qCWJLCc6g9YfHqyOIsijfRblZ5SR/Kj4XunUUt6BI697fLshR9y1rPjTmy+5+NE7o0WVdqz0ORcIj5L7Zynts1DKG3XU3oEp4Fh4UjEaE6OKgsQaH2JCn6uw==; 5:nC3rIDh90lpoh+EaodsXFJy0rSXcmkTWmPq5bai82e1HjcRZswYTVsU0IorVXYpwPPgr8ir6eSp9+pgI0ZpEM07yvqcW6X8+qIxfZ+kzIFVmPjzvxhLV1hqLf42sQ4/EMYIKSze6kNn+I2X7izNSr4U5ExrJqM5Blrh2+1MmopQ=; 7:ZsczxXyel4k9JvKhK6BYABEcYGJejXLtgWMwmX65xDMiy0bkzK6F0Z/eqFJD8gUeGWTRJXMZTyrMx0e35vom2kwiuu/bxF7hW10n511XOZvOVI9/7lU5jKv07jIb7yKzCP/mZJRmYPTtP9U/zVXGzg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: d96fd1b5-c94a-46cf-60b8-08d639ad9a78
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2298;
x-ms-traffictypediagnostic: HE1PR0701MB2298:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com;
x-microsoft-antispam-prvs: <HE1PR0701MB2298F64E7FEDD6EE1C4BABA698F60@HE1PR0701MB2298.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(26323138287068)(63843785518722)(166708455590820)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231355)(944501410)(52105095)(3002001)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR0701MB2298; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2298;
x-forefront-prvs: 083526BF8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(396003)(136003)(346002)(189003)(199004)(6506007)(83716004)(606006)(110136005)(8936002)(8676002)(186003)(478600001)(6246003)(102836004)(81166006)(14454004)(14444005)(71190400001)(86362001)(81156014)(82746002)(71200400001)(256004)(26005)(25786009)(33656002)(54906003)(9326002)(966005)(2900100001)(4326008)(105586002)(6436002)(53936002)(97736004)(345774005)(36756003)(316002)(5250100002)(106356001)(6486002)(5660300001)(6306002)(2501003)(2906002)(236005)(66066001)(6512007)(11346002)(446003)(54896002)(486006)(68736007)(7736002)(2616005)(229853002)(76176011)(6116002)(99286004)(53546011)(3846002)(476003)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2298; H:HE1PR0701MB2746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: WA50de3CqyO8MyNwp5iIC+LsW5/ERnZx6p5OoJtlW3nfhtjTOgDgHY4q6WK/SB5WBge5eO+PATpTyBwg26r1+Se2ub2yEtGi/D213MukUAgqqQDq47VxSPHX1UUKeaYUEbftc5YBRVzKHO9B0IMzyaTtKdtOG0KZkcZfP5+B8CEJorErfQwnJkffs3wIhiouotF/BgCXT+kULzpbwpnFu5gtAcbxg3UqVI351k2c+zJFiZlLyQvodvDUrg9vlLjiph0TyQ2ZIyErDOVa0VuEIZ/Mllq6tY33TIO2CwPxvjkV8ZYf1Kd4Sa19mH8HPh6UwruvGy/mynjuCfQZ/TJvM4dbm22n0ubH48ewyNvx/9Q=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_476ADF31C9874D249939713BD3F6C6DCericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d96fd1b5-c94a-46cf-60b8-08d639ad9a78
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2018 12:38:30.1838 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2298
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURTAud9rn6PFdSoeTKNGQi/fxRaYJkhNIjH7xweYc36oqNM2Mw0E NYVQSiOFXJotFpqvqWlaqejK0KwUHyVqyXBKVpKGiKVpbt8C//ude37n3HMulyXFQ7QLm6TK 4NQqRYqEEVIVER3XPN4mjER7N7YKZD1LBlL2dTaPkeU3tCBZ59ogJZvc0AnO0PJa7QwjX16J kev1v4kwMkroH8+lJGVyaq+AWGFiU012+lQzyspfH6Zz0XY9KkJ2LOATcONbO12EhKwY9yPo ebdC8sEagsffKwg+0BNQpjdaNQqXkjAxZ7Jp9wiYrTMzfLCAYL7pAWHpzGB/GDH9pC3siMOh 7c6EtZzE7xEsP6nckVjWAUvBUBDLOzIorC+2+b6w9bmRsTCF3UG3cVtgYREOhJL5OsrCYnwW Or7cJC1sh89BydimlRF2g9W8eiuT2BmmzNUEvykGfdcwybMTLM5t0TxLYHRTZzt3g9HqYmSZ E/AkAxvNSwyf8IDl8nKbdAGWljoIXhpE0J5rtt1wHKZXdQQ/hRLGp/mpAaeBtmaF4QuqEPTp cm1d90PdLRNViry1u6blWQnaP+MCrXVrexisMFPanQcj8REwvPDilYNQVmwS8HwYCiurbCyH rr8zgt3OQ8TWIScNp4lLTfD18+TUSUqNJk3lqeIyWtHOF+tr23DvRGM/gowIs0iyR2SIHIkW 04pMTXaqEQFLShxFeHs4WiyKV2Rf59Rpl9VXUziNEe1jKYmzyCR9GiXGCYoMLpnj0jn1/yzB 2rnkouR0unZE7p/2UR0W05I1axiWjy2ERBjPnwp37r1Ejw9sDTo8r81yak8PKD60noeF3UMN r12Vwb0vaaFreFXOs1Dpp8i7zXBg4GJ/63z3I5+Q4MXC8V+Cyq4PJ/Xhga9ct6vd2u4zb0Id TvvFHQssmJwdDdqrWpQGiAvbr6Tm2NdKKE2iwucoqdYo/gF4sd8RXgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/KvbWfiR2SOfSNqd5it_YVpV-Nv0>
Subject: Re: [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: Wed, 24 Oct 2018 12:38:43 -0000

Hi Jaro,

Thank you for your mail and sorry for the delayed reply.

Regarding the first question, you are right, “network byte order” was not the correct term in this instance (it might have been leftover from a previous version of OSCORE where Sender ID was of type integer, and used to clarify “left padding”). Your comment also applies to the 1st bullet, regarding Partial IV which is also a byte string. Yes, your (and other implementers) interpretation is correct. We have now removed “network byte order” in Section 5.2: https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html#rfc.section.5.2

For the second question, thanks Christian for coming to the rescue, but yes, we did mean for different ID sizes to mean different IDs. So, 0x01 is different than 0x0001.  Also, the empty byte string is a valid ID. The reason for this was to be able to save bytes, as well as increase the IDs space. We sure hope implementations comply with this. So the length to use in the nonce is its byte length which does not have to be the same in all senders, which is the reason why we include it in the nonce computation as well.

Thanks for your email, and we would be interested to hear more about your implementation if you can share with us,
Francesca


From: core <core-bounces@ietf.org>; on behalf of Jaro Fietz <jaro.fietz@aisec.fraunhofer.de>;
Date: Thursday, 11 October 2018 at 12:24
To: "core@ietf.org"; <core@ietf.org>;
Cc: "martin.striegel@aisec.fraunhofer.de"; <martin.striegel@aisec.fraunhofer.de>;, "stefan.hristozov@aisec.fraunhofer.de"; <stefan.hristozov@aisec.fraunhofer.de>;, "jaro.fietz@gmx.de"; <jaro.fietz@gmx.de>;
Subject: [core] OSCORE: Questions about Section 5.2

(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.

BR,
Jaro

[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)
[3]: https://bitbucket.org/lseitz/oscore/src/67680eaddcbc84967b5529868ce86db4abd54e72/oscore-cf/src/main/java/org/eclipse/californium/oscore/OSSerializer.java?at=basic_oscore2&fileviewer=file-view-default#OSSerializer.java-272
[4]: https://bitbucket.org/lseitz/oscore/src/67680eaddcbc84967b5529868ce86db4abd54e72/oscore-cf/src/main/java/org/eclipse/californium/oscore/Encryptor.java?at=basic_oscore2&fileviewer=file-view-default#Encryptor.java-74
[5]: https://bitbucket.org/lseitz/oscore/src/67680eaddcbc84967b5529868ce86db4abd54e72/oscore-cf/src/main/java/org/eclipse/californium/oscore/OSCoreCtx.java?at=basic_oscore2&fileviewer=file-view-default#OSCoreCtx.java-316
[6]: https://github.com/chrysn/aiocoap/blob/1a7f8bbbe079714ed6ba4a979a70339688148bc6/aiocoap/oscore.py#L222-L229