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

Benjamin Kaduk <kaduk@mit.edu> Sat, 03 November 2018 14:40 UTC

Return-Path: <kaduk@mit.edu>
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 41D20124408 for <ace@ietfa.amsl.com>; Sat, 3 Nov 2018 07:40:38 -0700 (PDT)
X-Quarantine-ID: <9NiriCk5prqJ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 9NiriCk5prqJ for <ace@ietfa.amsl.com>; Sat, 3 Nov 2018 07:40:34 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 05F8D1277D2 for <ace@ietf.org>; Sat, 3 Nov 2018 07:40:33 -0700 (PDT)
X-AuditID: 1209190d-79bff70000004eb5-4a-5bddb360172d
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 57.5E.20149.063BDDB5; Sat, 3 Nov 2018 10:40:32 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA3EeUCF020210; Sat, 3 Nov 2018 10:40:31 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA3EeQim009750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Nov 2018 10:40:29 -0400
Date: Sat, 3 Nov 2018 09:40:26 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: "t2trg@irtf.org" <t2trg@irtf.org>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20181103144026.GD54966@kduck.kaduk.org>
References: <3F7E42DF-7CA9-4765-AB67-A53B4E7D1AC1@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3F7E42DF-7CA9-4765-AB67-A53B4E7D1AC1@ericsson.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsUixCmqrJuw+W60wduHKhbfv/UwW5yauZvJ 4v2DHhYHZo9fX6+yeSxZ8pPJY/LGw2wBzFFcNimpOZllqUX6dglcGQeunGItOKZUsaJlEksD 4yuZLkYODgkBE4neXr8uRi4OIYE1TBJn3m5jh3A2MEo8/PQayrnDJPF9wW6WLkZODhYBFYmp s1czgthsQHZD92VmEFtEQE/iVNtLsDizgIvEuUnvmEBsYQFPiZe37oHV8AJtO/lhKhuILSRg L7Hjch8TRFxQ4uTMJywQveoSf+ZdYga5jllAWmL5Pw6IsLxE89bZYGM4BRwkOq8tYQexRQWU Jfb2HWKfwCg4C8mkWUgmzUKYNAvJpAWMLKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0 UlNKNzGCA12Sdwfjv7tehxgFOBiVeHgNKu9EC7EmlhVX5h5ilORgUhLldeYFCvEl5adUZiQW Z8QXleakFh9ilOBgVhLh/dIKlONNSaysSi3Kh0lJc7AoifNOaFkcLSSQnliSmp2aWpBaBJOV 4eBQkuBdtulutJBgUWp6akVaZk4JQpqJgxNkOA/Q8GMgNbzFBYm5xZnpEPlTjLoc7xb8n84s xJKXn5cqJc4rAlIkAFKUUZoHNweUoCSy99e8YhQHekuYtx2kigeY3OAmvQJawgS0JPrPbZAl JYkIKakGxmfvI2oKXX0cDrR2xd3edCzrFqPG5Lk2MR8zzPMOLlfd/6FxrdhK9cyL2z0WNuWv ydUzqrQqdYv/vKB1nsw0p+Xp0oFv3ORe3HzM/1VR3siutmFmwqV2979VDzqSj+14FnxhnUYF s1zL+Zadl5fcXGck+o/5Qd3JtIWHfu/YvUKdxSO50XzKfyWW4oxEQy3mouJEAPOKz18rAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/V497yOfOF3GZjsB0BlurwXcqZZc>
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 14:40:38 -0000

On Fri, Nov 02, 2018 at 11:31:16AM +0000, John Mattsson wrote:
> 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.

I assume you are not considering lossy compression algorithms, and thus are
indicating that this effort could be considered a domain-specific lossless
compression algorithm.  (Or perhaps you would consider the X.509 profile
that removes many things to be "lossy"?)

Regardless, the codepoint space for CertificateCompressionAlgorithm (in
https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04)
seems large enough to allow for a domain-specific compression algorithm,
e.g., one incorporating a custom dictionary that would improve compression
efficiency at the cost of storage space on the implementation.  Is this an
avenue that you have investigated?

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

There are some good questions here (and I certainly don't have the
answers!); it will be interesting to read the rest of this thread.

-Ben