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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux