Hi!
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
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:
>
....
>
> 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
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?
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!
Cheers
Joel Höglund
RISE SICS
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
