Re: [secdir] [Last-Call] Secdir last call partial review of draft-ietf-lpwan-coap-static-context-hc-12

[Ana Minaburo <[e-mail]>]

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 Fri, Feb 21, 2020 at 9:23 PM Benjamin Kaduk <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/last-call
>