[Ndn-interest] Interest Signature
shijunxiao at email.arizona.edu
Mon Jan 14 15:55:41 PST 2019
(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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ndn-interest