<div><div dir="auto">Dear folks</div></div><div dir="auto"><br></div><div dir="auto">20190130 NFD call discussed signed Interest spec.</div><div dir="auto"><br></div><div dir="auto">We accepted the suggestion of distinguishing between “last name component has type 35” and “Interest has Parameters”: if Interest has no Parameters, the signed portion would include a Parameters element with zero TLV-LENGTH. There’s still ambiguity between “omitted Parameters” and “Interest has empty Parameters” but these two can be seen as equivalent.</div><div dir="auto"><br></div><div dir="auto">We also decided to merge SignedInterestSha256DigestComponent into ParametersSha256DigestComponent. ParametersSha256DigestComponent will cover a portion of Interest starting at any TLV element whose TLV-TYPE falls in a certain range and toward the end of Interest. This TLV-TYPE number range will include Parameters and InterestSignatureInfo, and have room for future extension. I have suggested to reserve a range of 16 numbers, i.e. 0x23-0x32.</div><div dir="auto">Note that once an TLV element in this range is found, the digest will cover all subsequent TLV elements, not just TLV elements in the number range. This allows digest computation from a consecutive buffer, which is easier for hardware acceleration in high-speed forwarders.</div><div dir="auto">A benefit of reusing ParametersSha256DigestComponent is that, if a forwarder wants to verify ParametersSha256DigestComponent, it can do so without needing to understand signed Interest, and any future specification does not need to introduction new types of digest components again.</div><div dir="auto">A drawback of this definition is that, the position of TLV element within an Interest is now tied to whether it’s included in ParametersSha256DigestComponent computation. Any future specification that introduces a new TLV element into the Interest that should not be covered by ParametersSha256DigestComponent will have to place it before Parameters. This might cause undesirable effects.</div><div dir="auto"><br></div><div dir="auto">An unresolved question, more related to Parameters than signed Interest, is how to respond to a parameterized/signed Interest with multiple segments. If the parameterized/signed Interest has CanBePrefix element, the response Data could have an additional SegmentNameComponent (formerly, GenericNameComponent with segment marker). However, this implies Interests retrieving subsequent Data segments would have a ParametersSha256DigestComponent in its name, which in turn requires these Interests to be parameterized. Given the producer has already received the Parameters, sending the Parameters again would be a waste of bandwidth.</div><div dir="auto">My position on this is prohibiting multi-segment response to parameterized/signed Interest. When the response cannot fit in one segment, the producer can publish the response segments under a different name prefix that does not contain ParametersSha256DigestComponent, and reply to the parameterized/signed Interest with a “redirect” Data pointing to the secondary name prefix.</div><div dir="auto">However, there were no agreement on this issue yet.</div><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 15, 2019 at 13:52 Mosko, Marc <<a href="mailto:mmosko@parc.com">mmosko@parc.com</a>> <<a href="mailto:mmosko@parc.com">mmosko@parc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Junxiao,<br>
<br>
Thank you for the detailed reply, it helps me understand the construction better.<br>
<br>
>>> 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.<br>
However, as I said, I could agree with including Name TL and zero-ed SignedInterestSha256DigestComponent.<br>
<br>
Because the SignedInfo parameter is required, it will have a TL prefix, so that one is ok.  As you point out, the discrepancy happens if the original had a Parameters and the fake uses a name with the Parameters value in that field and omits Parameters field.  I think you could either include a Parameters TL (with 0 length) in the digest if it is missing or use the 0-padded name approach.<br>
<br>
FYI, Re-reading the text under "Signed Interest processing", it does not explicitly say that one removes the SignedInterestSha256DigestComponent before verifying the signature.<br>
<br>
If I wanted to exploit this Parameters ambiguity I would stick the Parameters field after the last name component and before SignedInterestSha256DigestComponent.<br>
<br>
Although I do not now of a specific attack -- it would likely be application level and depend on how someone parases the name -- it does seem wrong to admit a case where two different interests can have the same signature.  If they were properly formed, they would have different SignedInterestSha256DigestComponent (one has Parameters and one does not).<br>
<br>
<br>
>>> 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>
<br>
Ok, I understand the reasoning for this.<br>
<br>
Because the SignatureInfo includes a nonce and timestamp (which are both required for a signed interest), it seems very unlikely that Interests from two different sources could have the same SignedInterestSha256DigestComponent even if it excluded the signature value.  It would require that a bad actor actually see the good interest first and generate a fake or flood a zillion interests guessing the next nonce and timestamp.  But I understand that doing it with the signature value makes a self-verifying system if a forwarder were to actually verify the digests.<br>
<br>
It would be helpful in the document to give your explanation here about why the SignedInterestSha256DigestComponent has its particular structure.<br>
<br>
Marc<br>
<br></blockquote></div></div>