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

[Benjamin Kaduk <[e-mail]>]

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