Subject: Re: [lp-wan] Benjamin Kaduk's Discuss on draft-ietf-lpwan-coap-static-context-hc-16: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 1 Mar 2021 19:03:42 -0800

Hi Ana,

My apologies for not having responded to your messages in a more timely
fashion.

Thank you for submitting the -17 (and -18); that was exactly the right
thing to do, and helps make it more visible to me that I need to take
action for this document.

The good news is that the new text in the -18 generally does a good job at
addressing my comments; I will update my ballot position shortly, with what
I believe are only editorial remarks remaining.

I'll also reply inline here on one point, to help clarify for posterity
(even though the updates in the -18 did make the changes I was looking
for).

On Thu, Jan 21, 2021 at 04:14:41PM +0100, Ana Minaburo wrote:
> On Wed, Jan 6, 2021 at 10:21 AM Ana Minaburo <[email-masked]> wrote:
> >
> > On Fri, Dec 11, 2020, at 3:18 AM Benjamin Kaduk via Datatracker <
> > [email-masked]> wrote:
> >
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> This point from my previous review does not seem to be addressed:
> >>
> >> While the expanded security considerations do cover several important
> >> points, I think it's important to specifically state that the RFC 8724
> >> procedures assume that SCHC is implemented on top of LPWAN technologies
> >> that implement security mechanisms.  I think we also need to specify
> >> that either (a) this assumption remains for the CoAP usage of SCHC, or
> >> that (b) CoAP has use cases outside of LPWAN, and when SCHC is used in
> >> those non-LPWAN cases, the attacks (such as are now described in the
> >> -15) are more readily performed than in the secure LPWAN environment
> >> when no other integrity protection mechanism is in place for the
> >> compressed packets.
> >>
> >
> > AM: I think there is an error here, we made the following changes to the
> > first paragraph of section 9. Please tell us what is missing at this point?
> >
> > Text -15:
> >
> > 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.

Interestingly, the text you quote below as "Text -16" does not seem to be
in a published version of the I-D that I can find.  The -16 I am looking at
seems to have the same text as the "Text -15" above.  My concern with the
-15 text is that it makes a positive statement about what considerations
apply when LPWAN is used and when OSCORE is used, but makes no statement
about other scenarios.  This was problematic because the considerations
that apply to the other scenarios are very different.  The following
paragraph did include a statement "When the connection does not use any
security protocol as OSCORE, DTLS, or other, it is highly necessary to use
a layer two security," but "highly necessary" is not a requirement, and it
also does not say much about why the need is present.

> > Text -16:
> > "When applied *on top of LPWAN*, the Security Considerations of SCHC
> > header compression {{rfc8724}} are valid for SCHC CoAP header compression. *When
> > other technologies are used, an integrity protection mechanism MUST be
> > defined to carry SCHC compressed packets*. When CoAP uses OSCORE, the
> > security considerations defined in {{rfc8613}} does not change when SCHC
> > header compression is applied."

This text seems like it would have been okay.  In some abstract sense it
would have been nice to re-do the security analysis for the generic case
[i.e., without integrity protection], but as SEC AD I'm basically required
to always be in favor of mandatory integrity protection, and requiring
integrity protection supersedes the need for the additional analysis.

>   Text -18
> The use of SCHC header compression over CoAP header fields allow the
> compression of the 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 necessary to use a layer two security.
> 
>    If LPWAN is the layer two technology, the use of SCHC over the CoAP
> protocol keeps valid the Security Considerations of SCHC header compression
> [RFC8724].  When using another layer two, integrity protection is mandatory.

This text preserves the "when not using LPWAN, integrity protection is
mandatory" property, so it is also okay.

Thanks again for your work on this document, and sorry again for the delays
I caused.

-Ben

---

From: Ana Minaburo <[email-masked]>
Date: Thu, 4 Mar 2021 10:59:00 +0100

Dear Benjamin,

Thank you very much for your amazing work and all the valuable comments and
information you have provided to this work.
I'm working on the last version that I will publish when the tool opens
again.

Keep safe and see you in Zoom :)
Ana

On Tue, Mar 2, 2021 at 4:04 AM Benjamin Kaduk <[email-masked]> wrote:

> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Mar 2021 12:34:14 +0000

Hi Benjamin

I join my thanks (as chair this time) for the incredible quality of your reviews. I hope it is very clear that we are deeply thankful and that obviously, we understand that a work of that depth and breadth times the number of drafts that pass through your hands implies some latencies here and there.

Much, much appreciated!

Pascal

Le 4 mars 2021 à 10:59, Ana Minaburo <[email-masked]> a écrit :

Dear Benjamin,

Thank you very much for your amazing work and all the valuable comments and information you have provided to this work.
I'm working on the last version that I will publish when the tool opens again.

On Tue, Mar 2, 2021 at 4:04 AM Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ana,

On Thu, Jan 21, 2021 at 04:14:41PM +0100, Ana Minaburo wrote:
> On Wed, Jan 6, 2021 at 10:21 AM Ana Minaburo <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > [email-masked]<mailto:[email-masked]>> wrote:
> >

-Ben

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan