Re: [Gen-art] Genart last call review of draft-ietf-lpwan-coap-static-context-hc-12

Theresa, thanks for your review. Authors, thanks for your responses. I entered a No Objection ballot pointing out the remaining issues with the security considerations.

Alissa

> On Mar 9, 2020, at 11:26 PM, Theresa Enghardt <ietf@tenghardt.net> wrote:
> 
> Hi Laurent,
> 
> Thanks for the new revision, which greatly improves the document.
> 
> However, I have a few comments on your new text:
> 
> In the text at the beginning of Section 3, you added text to give more context, which is a great idea.
> However, I'm not sure about the first sentence: 
> "SCHC with CoAP will be used exactly the same way as it is applied in any protocol as IP or UDP with the difference that the fields description needs to be defined based on both headers and target values of the request and the responses."
> To me the last part of this sentence sounds like for CoAP you have to define a rule to match both a request and a reply packet, so you would have to match two packets (in a single rule?). Is this really the case? I thought a single rule always matches one packet, but maybe I misunderstood. In any case, could you rephrase this to make it more clear, please?
> 
> Also, I saw some typos and grammar errors in Section 3:
> s/optmize/optimize/
> s/To performs/To perform/
> s/TV might be use/TV might be used/
> s/Resulting in a smaller compression residue./This results in a smaller compression residue./
> 
> Some more nits in Section 7.3:
> s/TheSCHC/The SCHC/
> s/alreadypresent/already present/
> s/in section Section 4/in Section 4/
> 
> Regarding the Security Considerations, thanks for discussing this in your interim meeting and for adding text.
> 
> I'll leave the judgment of whether any security aspects are still missing etc. to the Secdir reviewer and/or ADs.
> 
> Regarding the text you added:
> On 05.03.20 23:50, Laurent Toutain wrote:
>> For the security section after discussion in the intermin meeting, we propose to add this:
>> 
>> This document does not have any more Security consideration than the ones already raised on {{rfc8724}}. Variable length residues may be used to compress URI elements. They cannot produce a packet expansion either on the LPWAN network or in the Internet network after decompression. The length send is not used to indicate the information that should be reconstructed at the other end, but on the contrary the information sent as a Residue. Therefore, if a length is set to a high value, but the number of bits on the SCHC packet is smaller, the packet must be dropped by the decompressor.
>> 
> Overall, I find this paragraph difficult to follow.
> What is the relationship between the first sentence and the rest of the paragraph?
> First you say there are not more Security Considerations, then you say that there are?
> 
> Please add a sentence that provides a context for your statements. Is this a consideration that implementations need to be aware of in case variable residues are used? Or is this a suggestion to use variable length residues to make something more/less secure?
> 
> What is a packet expansion? I haven't seen this term in the rest of the document. Is it a problem if they (the variable length residues or the URI elements?) cannot produce a packet expanision?
> This sentence is hard to parse and seems gramatically broken: "The length send is not used to indicate the information that should be reconstructed at the other end, but on the contrary the information sent as a Residue."
> 
> 
>> OSCORE compression is also based on the same compression method described in {{rfc8427}}. The size of the Initialisation Vector residue size must be considered carefully. A too large value has a impact on the compression efficiency and a too small value will force the device to renew its key more often. This operation may be long and energy consuming.
>> 
> "This operation may be long and energy consuming." - Which operation? The previous sentence talks about the size of an initialization vector, not about an operation.
> 
> 
> Thanks,
> Theresa
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art