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

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to