Re: [Ace] Minimizing overhead of certificates in constrained IoT

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Sat, 03 November 2018 02:54 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373B130E10 for <ace@ietfa.amsl.com>; Fri, 2 Nov 2018 19:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
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 38fyWN-aAf4B for <ace@ietfa.amsl.com>; Fri, 2 Nov 2018 19:54:47 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40057.outbound.protection.outlook.com [40.107.4.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC35E12777C for <ace@ietf.org>; Fri, 2 Nov 2018 19:54:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Me3vz47DySBNNXL/MwjcFei6DDDYgkzsmnYafBvvH3k=; b=IGqCJWQdiyISZCLFqEvbwbBDVRl1NEOEhXuCQrGBd3Y3z/RjAqO8vc489Dw5qPXWiBgkFuJiKeTh2uKhbsI5kX5/taMYbUF00SdqOpJ9bTlLDVTf5GfA1h4IJkgIBX1bIZgBEw5Tfi2LVBLpD7Cnr1WU4mNSH+TnQCb8pleicfY=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2752.eurprd08.prod.outlook.com (10.166.199.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Sat, 3 Nov 2018 02:54:43 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::7165:6199:a54f:510c%2]) with mapi id 15.20.1294.024; Sat, 3 Nov 2018 02:54:43 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: John Mattsson <john.mattsson@ericsson.com>, "t2trg@irtf.org" <t2trg@irtf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Minimizing overhead of certificates in constrained IoT
Thread-Index: AQHUcp+R17G1j53EqkyuwSM7Na/FnqU9Wtsg
Date: Sat, 3 Nov 2018 02:54:42 +0000
Message-ID: <VI1PR0801MB2112C12BC967417DDE80F14EFAC80@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <3F7E42DF-7CA9-4765-AB67-A53B4E7D1AC1@ericsson.com>
In-Reply-To: <3F7E42DF-7CA9-4765-AB67-A53B4E7D1AC1@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [31.133.154.159]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2752; 6:0bXbWlTKv1s7V6kKvTZJ6eraHLwDv7ThODgj5oA54Ezx5PRN6WdHElLn90guGSsKVRB1klYT0iECXRBaVvmsfeg3x8p+kVHThOWPNOhZLiPGLTZuIFHwj8JkY0R8ifxrsew5Zbohe7Umbh11M8IowyUFoFF7EpfPaIG1NYwruEWXK7jnJTJSBUB8uCTOl9m78EA0cSMYWNN8VfUKr759TuvjZERlsL+HDh9kipoTfSo4uBK4ATadxl8jB6nt4EhRLFC0f2LP6ogDdK2mu/jlKmoz1yvqyYLxV0mYZue5XyLYRTgoGh38SlAhi75/EG6iGKzc1GrhlxtDpjAazPlsz77tiWRSlkRgQwAE0g5ByjdJlwucaadwNgOyYtsRLV2GUwX59bJ2jlsVBGv9WD2rnI4mK5cIJvRa6qwlgV896FBlN9yk/oIZTPsmao8aLD2AxjCowsjjvSdETD25d3t6Ng==; 5:Hif2MgE2ZqVtVe52qADsxmzwE1DDba26khZtwrs5CzmPWV4ZnZIfrC5XHh4xbcYYSIpKIX3gBUyOw01ibj1KofGwdSuTqK5/VgDaF2UGoBpfCFRgTOY+lvRYag0WOJtp4PpMr/WJOfDwyx/7CqCET4o8mLImHcHuJZNW9G5+FaI=; 7:HebwLnGhAdro6EYBJTPmn0tdid6dlFaR+8JxzgKOQsN9TzBIMNqsScw889Day8OpoQTlBDLp6tbdIKUFf1UnGoAWZlndFOyuUPTevcXhUScxE2UR95T9154dIuYloHrKu7bp5RCws21z8nONMFLwZQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 096c03ef-72f7-45c8-1830-08d64137b4ba
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2752;
x-ms-traffictypediagnostic: VI1PR0801MB2752:
x-microsoft-antispam-prvs: <VI1PR0801MB2752D5807265A0C5761C8792FAC80@VI1PR0801MB2752.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(165104125076784)(17755550239193)(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231382)(944501410)(52105095)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0801MB2752; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2752;
x-forefront-prvs: 08457955C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(346002)(366004)(39860400002)(13464003)(51444003)(199004)(189003)(40434004)(53546011)(106356001)(6506007)(5024004)(14444005)(105586002)(256004)(476003)(446003)(11346002)(6116002)(3846002)(97736004)(8936002)(7736002)(6306002)(71190400001)(71200400001)(2201001)(81156014)(81166006)(99286004)(86362001)(53936002)(72206003)(6436002)(478600001)(6246003)(2900100001)(966005)(55016002)(229853002)(9686003)(305945005)(68736007)(110136005)(2906002)(7696005)(33656002)(25786009)(5660300001)(74316002)(66066001)(486006)(2501003)(26005)(8676002)(316002)(14454004)(76176011)(102836004)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2752; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ulY8ti/WAeDh8gWWV8Wfh0KuF4JC0miLzAC3RoXxGZUbdvJbZaclvmZd6fyq0bGa/bgxOcPBTHfYDiaNA+wemnkstZiWXup2nDp76nnK14LYhsAmuqf5Vr3o0KEpAhFeiGR8UV/eITT72ZRzBQUYqmRTdQ4Y7hjcmHCT33hJ5TyIGG0rGOAnMfLN9HHdOjtyTCjFVZR3vW752BpXlt9B7M98jPfzUexdOZXpdEWQIscPcU7uKP87QcOmLY89S8QGBbnN06LxVN7Jqb6qlPVXh4s/SmoI8xfviOqZMgLEjF+qaCZZ5VF7+Kz4JAAtXfEkv+ejjPA4ZwPSEwhnw/xLZ10B4qfKrm9fum/V9UoSOkw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 096c03ef-72f7-45c8-1830-08d64137b4ba
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2018 02:54:42.8663 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2752
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/vhQ6sVkTU6URZ3__9YAV6fV7bcw>
Subject: Re: [Ace] Minimizing overhead of certificates in constrained IoT
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2018 02:54:50 -0000

Hi John,

I see CWT as a combination of Kerberos ticket (for the use of symmetric key) and a certificate format (for the asymmetric key usage) encoded in CBOR.
The claims in the CWT are essentially the attributes you carry in a certificate.

Ciao
Hannes

-----Original Message-----
From: Ace <ace-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Friday, November 2, 2018 12:31 PM
To: t2trg@irtf.org; ace@ietf.org
Subject: [Ace] Minimizing overhead of certificates in constrained IoT

Hi,

We recently submitted https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-00, which build on research done by Research Institutes of Sweden, Royal Institute of Technology in Stockholm, and Nexus:

https://kth.diva-portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf
https://doi.org/10.1007/978-3-319-93797-7_14

The mechanism in the draft aims to reduce message overhead with the approach to start with a heavily profiled X.509 certificate and encode it to CBOR, resulting in around 50% savings in message overhead and storage. A major reason for submitting this early draft is to start a discussion on how to minimize the overhead (message size, code size, memory, storage, processing, etc.) caused by certificates in IoT deployments.

Current X.509 certificates are demanding in several ways (message, code size, memory, processing, etc. and are not designed for constrained IoT environments. The quite large sizes of even well profiled X.509 certificates mean that they take up a large part of the total number of bytes when used in protocols. Transmitting, receiving, or even listening for radio is relatively expensive in terms of power consumption and as the radio resources are often constrained, large messages lead to interference and therefore more latency than just the message sizes would infer.

That fact that certificates are sent encrypted in new protocols (TLS 1.3, DTLS 1.3, EDHOC) means that compression in intermediaries will not work in the future. TLS 1.3 and DTLS 1.3 are currently looking at certificate compression, but these mechanisms are not optimal for constrained IoT. The use of general lossless compression algorithms are quite heavy, and they do not compress things optimally.

With the submission of raft-raza-ace-cbor-certificates we would like to start a discussion on how to minimize the overhead caused by certificates.

- Which aspects do the community prioritise the most? i.e. message size, code size, memory, processing, etc. And how should trade-offs between these aspects look like?

- For how long time is people planning to use older protocols that do not encrypt certificates? Is it worth specifying gateway type of compression for these protocols?

draft-raza-ace-cbor-certificates does currently take the approached to start with a heavily profiled X.509 certificate and encode it to CBOR. Another approach is to not start with X.509 and do certificates in CBOR directly. This can be even more optimal from a theoretical point of view but may never deployed. Previous attempts to introduce new certificate types seem to have failed. On the other hand the current mechanism increases code size and processing for the part verifying the certificate.

- How should new IoT CBOR certificates be introduced in protocols? As a new type of certificate or a new compression/encoding algorithm for certificates? Is compression/encoding done inside the protocol or outside of the protocol?

- Is CBOR the correct choice if a new encoding is specified? We certainly think so.

- What are peoples’ opinions on general lossless compression algorithms?

- Which protocols would the IoT community want to use with new certificates/encoding/compression?

I think that a good place to start a discussion about these topics would be in T2TRG. If people find this interesting, I suggest having a quick introduction on the Friday plenary session and then further discussions in the security breakout.

Cheers,
John

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.