Subject: [lp-wan] security section

From: Laurent Toutain <[email-masked]>
Date: Mon, 2 Mar 2020 18:24:05 +0100

Hi,

The review of the CoAP document is going well, the only challenging issue
is the security section. The draft is saying that there is no new thread
since coap document is based on RFC 8724.
----
Security considerations {#SecConsiderations}

This document does not have any more Security consideration than the ones
already raised on {{I-D.ietf-lpwan-ipv6-static-context-hc}}

---

 But this not convince the genart :

*Major issues:*

* Section 9, Security considerations I find it difficult to believe that
compressing CoAP headers in addition to UDP/IP does not add any new
security considerations and does not modify the existing ones. As an
application-layer protocol, the information contained in CoAP might be more
sensitive than the information in the UDP and IP headers, thus, its
security considerations should be carefully examined. For example, does
compression improve security by making it more difficult for an observer to
parse the packet, as the observer does not have the context? Does
compression make the existing security problems better or worse if you
compress the CoAP header as well? Do the possible threats mentioned in RFC
7252 still apply if headers are compressed? Might compressing the CoAP
headers affect computational resources, like an attacker sending forged
packets, if the protocol has variable length fields and multiple occurences
of the same field?*

This is the only blocking point and if solve the document can be accepted.
We need your help to fill this section, and we would like to discuss it
during next interim meeting, because we don't see any new thread introduced
by CoAP compression. The Zip explosion has been raised, but SCHC does the
opposite. zip compression gives the size of what has been suppressed. SCHC
length the size of the remaining part, so no risk to expend too much the
size. But since CoAP is the protocol that uses variable length residue, we
add a paragraph to explain it. The other thread may comes from re keying
with OSCORE if the IV is too small.

Here is the text we plan to add and discuss on Wednesday.

This document does not have any more Security consideration than the ones
already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]. Nevertheless,
CoAP compression exhibit two main differences compared to IPv6 or UDP
compression. CoAP uses variable length field compression for URI elements
and CoAP is based on a state machine which, by definition introduces states
in the Device or in the Application.

Variable length field cannot produce a packet expansion either on the LPWAN
network or in the Internet network after decompression. On the opposite to
zip or other compression mechanism, the length is not used to indicate
information that should be reconstructed at the other end, but to the
information, length sent as a Residue. Therefore, if a length is set to a
high value, but the number of bits sent on the network does not correspond
to that value, the packet must be dropped by the decompressor. SCHC also
defines a max-packet-size indicating that decompressed packet must not
overpass this limit.

OSCORE compression may limit the size of the initialization vector. When it
reaches its limit, the device must renew its key. This operation may be
long and energy-consuming. Rules must consider the frequency of exchange to
avoid too often key exchange.

Ana and Laurent