Subject: [lp-wan] Roman Danyliw's Discuss on draft-ietf-lpwan-coap-static-context-hc-13: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 10 Mar 2020 19:51:28 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-lpwan-coap-static-context-hc-13: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

**  Section 9. (as Paul Wouters mentioned in his SECDIR review, thanks Paul!)
Per “This document does not have any more Security consideration than the ones
already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]”, this reference in
Section 12 (Security Considerations) contains the statement that “SCHC is
expected to be implemented on top of LPWAN technologies, which are expected to
implement security measures.”, this assumption doesn't necessarily seem valid
here?  What are the implications?

** Section 9.  Per “The size of the Initialisation Vector residue size must be
considered carefully. A too large value has a impact on the compression
efficiency and a too small value will force the device to renew its key more
often.”, can you be a bit clearer on the tradeoff:

-- how small is still acceptable given the security properties that still need
to be preserved in the AEAD nonce?

-- Given a particular smaller size, what factors would would influence more
frequent key renewal?

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

I support Ben Kaduk's DISCUSS position.

** Section 9.  Does it make sense to: s/the packet must be dropped by the
decompressor/the packet MUST be dropped by the decompressor/?

** Editorial Nits:
-- Section 3.1. s/knwoledge/knowledge/
-- Section 3. Typo. s/optmize/optimize/