Subject: [lp-wan] Benjamin Kaduk's No Objection on draft-ietf-lpwan-coap-static-context-hc-18: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 01 Mar 2021 19:04:14 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lpwan-coap-static-context-hc-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the updates in the -17 and -18, they do address my remaining
Discuss points and most of my comments.  I do have a few further
remarks, most notably a suggested rephrasing for the security
considerations section, but I believe they are all editorial in nature.

Section 5

nit: s/based header/basic header/

nit: s/stock/incorporate/ (or similar)

Section 5.3.1

   SCHC will send the second element of the URI-Path with the length
   (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 "eth0").

I don't think I understand where the 0x05 comes from -- aren't there
only four non-NUL characters in "eth0"?

Section 6.3

(nit) I think the "The [RFC7967] defines a No-Response option limiting
the responses made by a server to a request" was better than the current
"The [RFC7967] defines a No-Response".

Section 7.1

   Note that a client located in an Application Server sending a request
   to a server located in the Device may not be compressed through this
   Rule since the MID will not start with 7 bits equal to 0.  A CoAP

nit(?): I am not 100% sure I understand the specifics here, but I think
the concern is just that the CoAP client in the Application Server might
be using the simple "single Message ID" strategy for all its outbound
requests, and thus might use more than 9 bits of message-ID space and
achieve the "not start with 7 bits equal to 0" condition.  As far as I
can tell, though, there is no fundamental reason why such requests would
*always* have a MID that does not start with 7 bits equal to zero, so I
would suggest s/will not/might not/.

Section 7.3

I recognize the width constraints of the table, but in Figure 13 the
"mapp-sent" CDA is not a term that seems to be used anywhere else in the
document.  I believe that it is okay to format this with a line break,
so that "mapping-" is on the first line and "sent" on the second.

   must include it without compression.  The use of integrity translates
   into an overhead in total message length, limiting the amount of
   compression that can be achieved and plays into the cost of adding
   security to the exchange.

nit: s/integrity/integrity protection/

   The piv field lends itself to having some bits masked off with "MSB"
   MO and "LSB" CDA.  This SCHC description could be useful in
   applications where the message frequency is low such as LPWAN
   technologies.  Note that compressing the sequence numbers may reduce
   the maximum number of sequence numbers used in an exchange.  Once the
   sequence number exceeds the maximum value, the OSCORE keys need to be
   re-established.

nit: s/maximum number of sequence numbers used in an exchange/maximum
number of sequence numbers that can be used in an exchange/

Section 9

The change to say that "when using another layer two, integrity
protection is mandatory" is enough to address my discuss point, but the
section as a whole is still fairly inscrutable in general.  If it's
useful, here's my take on how it could be written -- feel free to ignore
or take whichever parts you do/don't want.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The use of SCHC header compression for CoAP header fields only affects
the representation of the header information.  SCHC header compression
itself does not increase or decrease the overall level of security of
the communication.  When the connection does not use a security protocol
(such as OSCORE, DTLS, etc.), it is necessary to use a layer-two
security mechanism to protect the SCHC messages.

If LPWAN is the layer-two technology, the SCHC security considerations
of [RFC8724] continue to apply.  When using another layer-two protocol,
use of a cryptographic integrity-protection mechanisms to protect the
SCHC headers is REQUIRED.  Such cryptographic integrity protection is
necessary in order to continue to provide the properties that [RFC8724]
relies upon.

When SCHC is used with OSCORE, the security considerations of [RFC8613]
continue to apply.

When SCHC is used with the OSCORE outer headers, the Initialization
Vector (IV) size in the Compression Residue must be carefully selected.
There is a tradeoff between compression efficiency (with a longer "MSB"
MO prefix) and the frequency at which the Device must renew its key
material (in order to prevent the IV from expanding to an uncompressable
value).  The key renewal operation itself requires several message
exchanges and requires energy-intensive computation, but the optimal
tradeoff will depend on the specifics of the device and expected usage
patterns.

If an attacker can introduce a corrupted SCHC-compressed packet onto a
link, DoS attacks are possible by causing excessive resource consumption
at the decompressor.  However, an attacker able to inject packets at the
link layer is also capable of other, potentially more damaging, attacks.

SCHC compression emits variable-length Compression Residues for some
CoAP fields.  In the compressed header representation, the length field
that is sent is not the length of the original header field but rather
the length of the Compression Residue that is being transmitted.  If a
corrupted packet arrives at the decompressor with a longer or shorter
length than the original compressed representation possessed, the SCHC
decompression procedures will detect an error and drop the packet.

SCHC header compression rules MUST remain tightly coupled between
compressor and decompressor.  If the compression rules get out of sync,
a Compression Residue might be decompressed differently at the receiver
than the initial message submitted to compression procedures.
Accordingly, any time the context Rules are updated on an OSCORE
endpoint, that endpoint MUST trigger OSCORE key re-establishment.
Similar procedures may be appropriate to signal Rule udpates when other
message-protection mechanisms are in use.