[Ndn-interest] Interest Signature

[Junxiao Shi]

Hi Marc
(continuing this thread on ndn-interest only; removing mini-ndn mailing
list as this is becoming a protocol discussion)

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

>>> 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.
> This cuase extra overhead when verifying the signature -- receiver needs
> to calculate and modify the L before signature verification.
>
> 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.
>

As Zhiyi already answered, Parameters TL and SignatureInfo TL are included,
but Name TL are excluded because it's not yet generated.
I agree that reserving a zero-ed SignedInterestSha256DigestComponent is a
good solution. The same approach has been adopted by UDP checksum.

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

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.

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.


It's unnecessary to have contiguous memory. Last time I checked, every good
crypto library supports incremental SHA256 computation.
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.

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

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.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20190114/ffe51d88/attachment-0001.html>