Last Call Review of draft-ietf-lpwan-coap-static-context-hc-13

Request Review of draft-ietf-lpwan-coap-static-context-hc
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-02-20
Requested 2020-02-06
Authors Ana Minaburo, Laurent Toutain, Ricardo Andreasen
Draft last updated 2020-03-20
Completed reviews Iotdir Last Call review of -11 by Stephen Farrell (diff)
Genart Last Call review of -12 by Theresa Enghardt (diff)
Opsdir Last Call review of -12 by Linda Dunbar (diff)
Tsvart Last Call review of -12 by Joseph Touch (diff)
Secdir Last Call review of -12 by Paul Wouters (diff)
Secdir Last Call review of -13 by Charlie Kaufman (diff)
Secdir Telechat review of -15 by Charlie Kaufman (diff)
Assignment Reviewer Charlie Kaufman 
State Completed Snapshot
Review review-ietf-lpwan-coap-static-context-hc-13-secdir-lc-kaufman-2020-03-20
Posted at
Reviewed rev. 13 (document currently at 19)
Review result Has Nits
Review completed: 2020-03-12


**Resend fixing typo in addresses and subject line...***

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.


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 ...".


Sent from Outlook<>