<div dir="ltr"><div>Hi Marc</div><div>(continuing this thread on ndn-interest only; removing mini-ndn mailing list as this is becoming a protocol discussion)<br></div><div><br></div><div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I noticed at the end of the code review comments there is the statement "The signature should not cover Name-TYPE and Name-Length."  I did not see it in the comments, but I assume you are applying the same logic to the Parameters and SignatureInfo fields?<br></blockquote><div><br></div><div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>>
 Actually not. The reason why we don't include Name's T and L is because
 after generating the signature value, we need to append a 
SignedInterestSha256Digest component to the end of the current name, 
thus changing the Name's L.<br>
This cuase extra overhead when verifying the signature -- receiver needs
 to calculate and modify the L before signature verification.<br>
<br>
Might I suggest that you pre-append a zero-ed component and adjust the 
L, then do the signature.  The receiver would then need to zero the 
field to compare signatures.  That would allow keeping the Name T & L
 so the digest is over properly delimited fields.  Otherwise, I would 
try to find some other way of delimiting the name value to avoid attacks
 on the multiple fields.  One example would be to just include a length 
in the digest before the Name of the name length you're digesting.  It 
could just be a simple uint32 and does not need to be fancy.<br></blockquote><div> </div></div>

</div><div>As Zhiyi already answered, Parameters TL and SignatureInfo TL are included, but Name TL are excluded because it's not yet generated.</div><div>I agree that reserving a zero-ed SignedInterestSha256DigestComponent is a good solution. The same approach has been adopted by UDP checksum.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think that is not correct.  When computing a digest over multiple fields, you need to delimit those fields somehow (a special character or length encoding, etc.).  Otherwise, you could have a first field with the values of the later fields and the later fields empty and get the same digest and thus the same signature.  For example, if my digest is over fields A and B, if I do not delimit them, I could have A="abc" and B="def" or A="abcdef" and B="" and they would look the same.<br></blockquote><div> </div><div>Since Parameters TL and SignatureInfo TL are included, the only case of confusion due to lack of delimiter is between "having Parameters" and "TLV-TYPE of last name component equals Parameters, but no Parameters". I know about this case but thought it's insignificant.</div><div>However, as I said, I could agree with including Name TL and zero-ed 
SignedInterestSha256DigestComponent.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So it appears that the signature is only on the tuple (Name \  ParametersSha256Digest, Parameters, SignatureInfo).  Usually one would makes those contiguous memory to simplify the digest calculation, so I would have expected the BNF to have Parameters and SignatureInfo directly after Name, assuming that the BNF implies normal ordering.</blockquote><div><br></div><div>It's unnecessary to have contiguous memory. Last time I checked, every good crypto library supports incremental SHA256 computation.</div><div>It's more important to place elements that a network forwarder cares about early in the packet, and this means Name, CanBePrefix, MustBeFresh, ForwardingHint, and HopLimit. This allows the network forwarder to stop decoding as soon as encountering Parameters.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was not clear on why the SignedInterestSha256Digest included the 
InterestSignatureValue -- that is to make the name uniquely correlated 
to the signer?  It is not clear to me what security value this adds 
compared to having SignedInterestSha256Digest = Digest(Parameters, 
SignedInfo).  This is because you're already binding 
SignedInterestSha256Digest to the KeyId and using the KeyId to verify 
the signature over a larger body.  If it is possible to remove 
InterestSignatureValue from SignedInterestSha256Digest it greatly 
simplified operation.  I think it would be worth reviewing why it is 
there and what increased assurance it adds.<br></blockquote><div><br></div><div>SignedInterestSha256DigestComponent covers InterestSignatureValue to ensure proper operation of network forwarders, and in particular PIT aggregation. Under NDN Packet Format v0.3, PIT aggregation uses Name+CanBePrefix+MustBeFresh as index key. If 
SignedInterestSha256DigestComponent does not cover 
InterestSignatureValue, a signed Interest with a good signature can be aggregated into a signed Interest with a bad signature, and this scenario remains undetectable by the network. Covering 
InterestSignatureValue enables a network forwarder to detect such scenario: a forwarder can occasionally compute the digest and compare it to 
SignedInterestSha256DigestComponent, and block a malicious consumer if the digest does not match.<br></div><div><br></div><div>Yours, Junxiao<br></div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div></div></div></div></div>