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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
