[secdir] Answer to: review draft-ietf-lpwan-coap-static-context-hc-12

[Ana Minaburo <[e-mail]>]

Dear all,

Thanks for reviewing our draft, we have been working the Security Section.
This new version reflects the fact that SCHC CoAP compression may not be
managed by the same entity as the IP/UDP compression.

We have published the version -14 with this new text:
Security considerations

*When applied to LPWAN, the Security Considerations of SCHC header
compression RFC8724 are valid for SCHC CoAP header compression. When CoAP
uses OSCORE, the security considerations defined in RFC8613 does not change
when SCHC header compression is applied.*

The definition of SCHC over CoAP header fields permits the compression of
header information only. The SCHC header compression itself does not
increase or reduce the level of security in the communication. When the
connection does not use any security protocol as OSCORE, DTLS, or other, it
is highly necessary to use a layer two security.

DoS attacks are possible if an intruder can introduce a compressed SCHC
corrupted packet onto the link and cause a compression efficiency
reduction. However, an intruder having the ability to add corrupted packets
at the link layer raises additional security issues than those related to
the use of header compression.

SCHC compression returns variable-length Residues for some CoAP fields. In
the compressed header, the length sent is not the original header field
length but the length of the Residue. So if a corrupted packet comes to the
decompressor with a longer or shorter length than the one in the original
header, SCHC decompression will detect an error and drops the packet.

*OSCORE compression is also based on the same compression method described
in {{rfc8724}}. The size of the Initialisation Vector (IV) residue must be
considered carefully. A residue size obtained with LSB CDA over the IV has
an impact on the compression efficiency and the frequency the device will
renew its key. This operation requires several exchanges and is
energy-consuming.*

SCHC header and compression Rules MUST remain tightly coupled. Otherwise,
an encrypted residue may be decompressed differently by the receiver. To
avoid this situation, if the Rule is modified in one location, the OSCORE
keys MUST be re-established.

----

Regards

Ana, Laurent & Ricardo