Skip to main content

Last Call Review of draft-ietf-lpwan-coap-static-context-hc-13
review-ietf-lpwan-coap-static-context-hc-13-secdir-lc-kaufman-2020-03-20-00

Request Review of draft-ietf-lpwan-coap-static-context-hc
Requested revision 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
I-D last updated 2020-03-20
Completed reviews Iotdir Last Call review of -11 by Stephen Farrell (diff)
Genart Last Call review of -12 by Reese Enghardt (diff)
Opsdir Last Call review of -12 by Linda Dunbar (diff)
Tsvart Last Call review of -12 by Dr. Joseph D. 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
Request Last Call review on draft-ietf-lpwan-coap-static-context-hc by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/r7FS-5aOz2vJPKWLBgUVn5GIBDY/
Reviewed revision 13 (document currently at 19)
Result Has nits
Completed 2020-03-12
review-ietf-lpwan-coap-static-context-hc-13-secdir-lc-kaufman-2020-03-20-00
**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.

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>