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

From: John Mattsson <[email-masked]>
Date: Fri, 2 Nov 2018 11:31:16 +0000

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 3 Nov 2018 02:54:42 +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 <[email-masked]> On Behalf Of John Mattsson
Sent: Friday, November 2, 2018 12:31 PM
To: [email-masked]; [email-masked]
Subject: [Ace] Minimizing overhead of certificates in constrained IoT

Hi,

Cheers,
John

_______________________________________________
Ace mailing list
[email-masked]
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.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Nov 2018 13:55:58 +0700

Much of this discussion is less of a technical nature but about framing things right.

If all signed assertions are called certificates, it may be hard to get rid of X.509, because that is what people think of when they say “certificate".

What signed assertions do we need for constrained IoT, and which of these really “need” to be certificates?

(A chain of signed assertions might ultimately terminate in an X.509 certificate, because that’s the way we store public keys with long-term validity in many places, but how important is it to have the full X.509 certificate represented in a constrained device?)

Grüße, Carsten

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 3 Nov 2018 09:40:26 -0500

> 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 l…

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?

> 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 f…

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

---

From: Joel Höglund <[email-masked]>
Date: Thu, 22 Nov 2018 15:46:26 +0000

Hi!

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

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

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.

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'm also looking forward to read more comments!

Cheers

Joel Höglund
RISE SICS