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
