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/
https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/
Ana
On Fri, Feb 21, 2020 at 9:23 PM Benjamin Kaduk <kaduk@xxxxxxx> wrote:
Hi Paul,
Thanks for doing the review and raising the potentially serious issues.
On Fri, Feb 21, 2020 at 10:52:13AM -0800, Paul Wouters via Datatracker wrote:
>
> Review is partially done. Another assignment may be needed to complete it.
>
> Reviewer: Paul Wouters
> Review result: Serious Issues
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> I agree with the comments raised by the genart review by Theresa Enghardt. The
> Security Section is just a reference to another document that specifies in its
> own Security Consideration:
>
> As explained in Section 5, SCHC is expected to be implemented on top
> of LPWAN technologies, which are expected to implement security
> measures.
>
> This document explains that packets are wrapped in CoAP and then this document
> can be used to compress fields, similar to the references document. But now
> this is happening in the most outer layer, which the referenced document
> basically states that in its Security Considerations, it assumes the outer
> layer has some kind of LPWAN based security meassures in place.
>
> It seems these two drafts need some coordination to determine where, how and
> which Security Considerations are relevant.
It does seem like it, since CoAP is not guaranteed to be used over a
physical medium with integrated security technologies (though many expected
use cases do).
> Additionally, I'm a bit worried about multiple layers doing compression. Can
> this lead to security issues? If not, why not?
>
> Where is it sais that compression states need to be checked for bogus
> instructions? How are these prevented? Think of the ever-decompressing zip file
> hacks of the past. How are these DoS attacks prevented ?
I think the "static context" nature of this compression mechanism prevents
issues with near-infinite expansion, at least, though there would of course
still be room for bugs when handling noncompliant input.
-Ben
> Other than this issue, I found Section 1 Introducion a bit confusing. It seems
> to drop a reference to another document and then explain that other document,
> without really talking about this document? Or if it does, it was not very
> clear to me.
>
> I did not review this document for nits - my apologies but I ran out of time.
>
>
> --
> last-call mailing list
> last-call@xxxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
