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

[Ana Minaburo <[e-mail]>]

Dear Roman,

Thank you for your review, a new version of the draft has been published
today with a new security section. We have discussed this section during
the virtual IETF meeting taking your inputs into account.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/


Ana

On Wed, Mar 11, 2020 at 3:51 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> 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/
>
>
>
>