[Nfd-dev] [EXT]Re: Update on NDNCERT protocol

[Zhiyi Zhang]

I just pushed my latest commit.

On Fri, Mar 27, 2020 at 6:42 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> Some comments are not adequately addressed in revision a106193.
>
>
>>> *Terminologies*
>>> Links for timestamp, version, and segment component types should point
>>> to NDN-TR-0022 rev2
>>> <https://named-data.net/publications/techreports/ndn-tr-22-2-ndn-memo-naming-conventions/>
>>> .
>>>
>> The link should say "NDN naming conventions", not "NDN name".
>

Addressed.


>
> The NDN Testbed, as in, forwarding services, already supports signed
>>> Interest defined in NDN Packet Format v0.3 spec. The clause "before this
>>> format is officially supported by NDN Testbed" is inapplicable and should
>>> be removed.
>>>
>> This sentence is still not removed.
>

Addressed.


>
> *Packet Specification*
>>> Every TLV format specification needs to have ABNF
>>> <https://tools.ietf.org/html/rfc5234>.
>>>
>> Why does this become an "ongoing issue"?
> I can't further review the packet format until ABNF is added.
>

Addressed.


>
> "TLV Type number" should be written as "TLV-TYPE number (decimal)" and
>>> "TLV-TYPE number (hexadecimal)".
>>>
>> It still says "TLV Type". It should be "TLV-TYPE" to be consistent with
> NDN Packet Format spec.
>

Addressed.


> Also, all numbers should be assigned, not "tbd", in order for the spec to
> be implementable.
>

Addressed.


>
>>> *INFO*
>>> Since INFO Data packet is retrieved via RDR, the Interest format is
>>> defined by RDR and does not need to appear in NDNCERT protocol.
>>>
>> This is not done.
>

This is not that important? and for completeness, I would still keep it?


>
> *PROBE redirect*
>>>
>> Note: in order to let this revision proceed to implementation and
>>> deployment quickly, I strongly recommend deleting "PROBE redirect" and
>>> "PROBE privacy" section. They can be re-added in a future revision of the
>>> NDNCERT protocol.
>>>
>> I agree with you. I will put these two extensions a lower priority.
>>
> Not "lower priority", but delete it altogether so that the spec can be
> finalized.
> Re-add them in a future version (e.g. v0.3.1).
>

Addressed.


>
>
>>> *NEW*
>>> challenge: how to specify multiple possible challenges?
>>>
>>
>> Repeat the challenge TLV.
>>
> Please clarify this through ABNF.
>

Addressed.


>
> *RENEW*
>>> If RENEW is same as NEW, why not use the same verb?
>>>
>> Because they are for different purposes and indicate different operations
>> to the CA.
>>
> I'm not convinced. Please further explain.
> I strongly recommend deleting RENEW and REVOKE sections for this revision,
> so that the spec can be finalized.
> You can re-add these sections in v0.3.2.
>

Addressed.


>
> *CHALLENGE*
>>> To simplify protocol and implementations, consider merging
>>> "probe-parameter" and "challenge-parameter" into a single "parameter-key"
>>> TLV-TYPE, and merging "probe-parameter-value" and
>>> "challenge-parameter-value" into a single "parameter-value"  TLV-TYPE .
>>>
>> I see this becomes an "ongoing issue", so I'm adding this for discussion
> on next NFD call.
>

Hmm, I think it's not a big deal? but I am fine with that.


>
>
>> AES-GCM supports AEAD. I suggest passing <Request_ID> as additional data
>>> while encrypting and decrypting the payload, which cryptographically binds
>>> the payload to this request.
>>>
>> I realize that HKDF also has an "info" input parameter. <Request_ID>
> should be used there too.
>

Addressed.

Best,
Zhiyi


>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200327/c9111281/attachment-0001.html>