[secdir] Secdir review of draft-ietf-lpwan-coap-static-context-hc-15

[Charlie Kaufman <[e-mail]>]

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 CoAP 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. One 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. (The explanation is that the values in earlier fields do not affect the compression of later fields, so an attacker cannot supply values whose length after compression will leak the values of other compressed fields).

This document is very difficult to read and could use an editing pass by a native English speaker, but I suspect that is not its only problem. Synchronizing the compression parameters is explicitly out of scope for this document, but this document allows for so many different variations in the parameter settings that it's not clear whether these settings are intended to by dynamically negotiated.

While there are lots of aspects of this specification that I'm uncertain about, I am fairly certain it does not introduce any security problems.

Details:

Introduction: What does "designed to easily interop with HTTP" mean?

Section 2 is confusing. For example:

"In the first example Figure 1, a Rule compresses the complete header stack from IPv6 to CoAP. In this case, SCHC C/D (Static Context Header Compression Compressor/Decompressor) is performed at the Sender and at the Receiver. The host communicating with the device do not implement SCHC C/D."

This text seems to make some distinction between the communications endpoint and the host on which the communications endpoint runs. But its not clear what the distinction is. I'm guessing there is a presumption that the host processes the network layer headers and some application processes the packet "payload", but if so doing the IPv6 and UDP header compression within the application makes no sense.

The punctuation around figures 1, 2, and 3 including:

((((((())))))) ----- ------ ------ -----

does not make a lot of sense. The figures could use more explanation as to what the columns mean.

Nits:

Capitalization of "RFC" should be consistent (in particular, in section 1.1: [RFC2119][rfc8174])

"still is too large for" -> "is still too large for"

"requires to install" -> "requires the installation of"

"device do not" -> "device does not"

"[rfc8724] document" -> "[rfc8724]"

Sorry... there are just too many nits to enumerate.