Subject: [secdir] Secdir review of draft-ietf-lpwan-coap-static-content-hc-13

From: Charlie Kaufman <[email-masked]>
Date: Fri, 13 Mar 2020 06:10:31 +0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This draft defines how SCHC (Static Context Header Compression) should be applied to the CoAP (Constrained Application Protocol). It appears that this is designed for low end devices speaking standard protocols with a lot of static content they would like to suppress to avoid wasting processing time and communications overhead. That means that these devices are likely to be generating and parsing the compressed content directly rather than generating the full content and then compressing it. The only security considerations worth noting is that whenever compression is used with a protocol intended to be encrypted (which this one is), the question should be raised as to whether the compression can be leveraged by an attacker to make traffic analysis more effective. In this case, I don't believe it can, but there should probably be an explanation of why in the security considerations.

With a compression scheme like Lempel Ziv, the value of some field potentially supplied by an attacker can affect the compression of some other field potentially containing a secret. This allows traffic analysis looking at the lengths of messages containing content supplied by an adversary to reveal secrets. On the other hand, with a compression scheme like Huffman coding, fields are compressed independently. This scheme appears to be more like Huffman; the compression rules are not dynamically adjusted based on variable content. If anything, the compression here seems likely to make traffic analysis more difficult by making messages shorter such that the lengths are masked by padding.

Nits:

The acronym CoAP appears 181 times in this document but is never defined/expanded except in the references. It probably should be either on first use or in terminology.

The capitalization of certain keywords (e.g., Rule, Residue, Plaintext, Outer, Header) seems inconsistent. If whether the word is capitalized is intended to convey some meaning to the reader, that should probably be mentioned somewhere, and in any case the usage should be consistent.

"to performs the" -> "to perform the"
"might be use" -> "might be used"
"knwoledge" -> "knowledge"
"to appears" -> "to appear"
"length send" -> "length sent"
"bits on the SCHC packet" -> "bits in the SCHC packet"

"This document does not have any more Security consideration than the ones already raised on..."
->"This document does not have any security considerations beyond those raised in..."

...except that the security considerations goes on to raise some issues. So unless those are duplicating ones mentioned in the referenced document, the introductory phrase should probably be "These security considerations are in addition to those raised in ...".

 --Charlie

Sent from Outlook<http://aka.ms/weboutlook>