[Ndn-interest] Interest Signature

[Junxiao Shi]

Dear folks

20190130 NFD call discussed signed Interest spec.

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.

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

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.
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.
However, there were no agreement on this issue yet.

Yours, Junxiao

On Tue, Jan 15, 2019 at 13:52 Mosko, Marc <mmosko at parc.com> <mmosko at parc.com>
wrote:

> Junxiao,
>
> Thank you for the detailed reply, it helps me understand the construction
> better.
>
> >>> 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.
> However, as I said, I could agree with including Name TL and zero-ed
> SignedInterestSha256DigestComponent.
>
> 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.
>
> FYI, Re-reading the text under "Signed Interest processing", it does not
> explicitly say that one removes the SignedInterestSha256DigestComponent
> before verifying the signature.
>
> If I wanted to exploit this Parameters ambiguity I would stick the
> Parameters field after the last name component and before
> SignedInterestSha256DigestComponent.
>
> 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).
>
>
> >>> 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.
>
> Ok, I understand the reasoning for this.
>
> 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.
>
> It would be helpful in the document to give your explanation here about
> why the SignedInterestSha256DigestComponent has its particular structure.
>
> Marc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190130/215515c2/attachment.html>