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

Joel Höglund <> Thu, 22 November 2018 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0872F126C7E for <>; Thu, 22 Nov 2018 07:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dn4ePg7DoXmS for <>; Thu, 22 Nov 2018 07:46:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBF921200B3 for <>; Thu, 22 Nov 2018 07:46:30 -0800 (PST)
Received: from 1gPrBT-0006jZ-Tn by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gPrBT-0006k9-V2 for; Thu, 22 Nov 2018 07:46:27 -0800
Received: by emcmailer; Thu, 22 Nov 2018 07:46:27 -0800
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gPrBT-0006jZ-Tn for; Thu, 22 Nov 2018 07:46:27 -0800
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 22 Nov 2018 16:46:27 +0100
Received: from ([fe80::74af:9420:2d85:73d]) by ([fe80::74af:9420:2d85:73d%21]) with mapi id 15.01.1531.003; Thu, 22 Nov 2018 16:46:27 +0100
From: =?iso-8859-1?Q?Joel_H=F6glund?= <>
To: "" <>
Thread-Topic: [Ace] Minimizing overhead of certificates in constrained IoT
Thread-Index: AQHUcp+R17G1j53EqkyuwSM7Na/FnqU+IRIAgBk8MoCABJ1x0g==
Date: Thu, 22 Nov 2018 15:46:26 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: en-GB, sv-SE, en-US
Content-Language: en-GB
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_34541d17d2384820808cca7009694d0drise_"
MIME-Version: 1.0
X-Proto: esmtps
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <>
Subject: Re: [Ace] Minimizing overhead of certificates in constrained IoT
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Nov 2018 15:47:54 -0000


We're happy for the questions and hope to see more discussions happening. A few comments given inline below:

    On Fri, Nov 02, 2018 at 11:31:16AM +0000, John Mattsson wrote:

    > Hi,
    > We recently submitted, which build on research done by Research Institutes of Sweden, Royal Institute of Technology in Stockholm, and Nexus:
    > 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"?)

As long as we are signing the 'original' - profiled but uncompressed - x.509 certificate, the decompression mechanism must be able to restore the exact uncompressed content for the signature to be valid. So in this sense the proposed cbor based encoding schema works as a domain-specific lossless compression algorithm. From a "human readable" perspective, the profile could be seen as lossy, as it forbids using some certificate fields such as country codes, but we believe the benefits outweighs the drawbacks.

    Regardless, the codepoint space for CertificateCompressionAlgorithm (in
    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?

We haven't yet discussed on how to best align our efforts with the TLS Certificate Compression proposal. As a first impression it seems like the proposed cbor certificates could be advertised through the CertificateCompressionAlgorithm extension as one available compression algorithm by the servers and IoT devices supporting it, if the TLS proposal is extended to also encompass DTLS.

To further improve compression for IoT devices in general, the cost for a custom dictionary could easily become bigger than the savings. But if there are ideas for scenarios where a more refined custom dictionary could be beneficial, that would definitely be an area for further investigation.

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

I'm also looking forward to read more comments!


Joel Höglund