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

[Zhiyi Zhang]

Hi Junxiao,

Thanks for your comments. I just pushed my change.
I agree with most of your suggestions and made the changes accordingly.
For the remaining ones, I put some of them into the issues in the spec for
further discussion and comment on the others in this email.

On Mon, Mar 23, 2020 at 5:59 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> Comments on revision 226dbac.
>
>
> *Major Changes*
> The term "users" should be replaced by "requesters" or "clients" to be
> consistent with terminology list.
>
>
> *Terminologies*
> Section title "terminologies" should be just "terminology". The singular
> form terminology <https://www.merriam-webster.com/dictionary/terminology>
> refers to a group of technical or special terms used in a subject, such as
> NDNCERT protocol. The plural form terminologies
> <https://www.wordhippo.com/what-is/the-plural-of/terminology.html> refers
> to several groups of terms used in multiple subjects.
> 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 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.
> Terms "parent namespace" and "sub namespace" need to be defined in this
> section. Their semantics are fuzzy in overview section.
> Links to NDN Packet Format spec should use specific version
> https://named-data.net/doc/NDN-packet-spec/0.3/ , not "current".
>
> *Packet Specification*
> Every "phase" should be replaced by "step" or "Interest and Data" or
> "request and response".
> Every TLV format specification needs to have ABNF
> <https://tools.ietf.org/html/rfc5234>.
> "TLV Type number" should be written as "TLV-TYPE number (decimal)" and
> "TLV-TYPE number (hexadecimal)". Having both decimal and hexadecimal can
> greatly help programming and traffic trace analysis.
>
> *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.
> max-validity-period is defined to be "int value". Terminology list points
> this to NDN Packet Format, but it does not define how to encode "int
> value". If you mean "non negative integer", this has to be clarified either
> here or in terminology list.
>
>
> *PROBE*
> What happens if the CA cannot issue any certificate for the provided
> probe-parameter-value(s)? I suggest replying with a Data packet that has
> zero Name element. Alternatively, you'll have to define an error format.
>
>
> *PROBE redirect*
> Is it possible to receive redirects to multiple CAs? In NDNCERT-legacy, a
> requester can obtain guest certificates from a number of CAs.
> Is it possible for the Data to contain both name prefixes and redirects?
>

No according to the current spec. I think we may not need this.


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


>
>
> *NEW*
> challenge: how to specify multiple possible challenges?
>

Repeat the challenge TLV.


> salt: clarify that the AES key is AES-GCM-128 key, because this is the
> entropy from ECDH on P-256 curve.
>
> *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.

Best,
Zhiyi


>
> *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 .
> initial-vector: specify this to be fixed 12-byte IV that is more efficient
> in processing, see this answer <https://crypto.stackexchange.com/a/41610>.
> 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.
>
> Yours, Junxiao
>
> On Thu, Mar 19, 2020 at 6:53 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
>
>> Hi folks,
>>
>> I've updated the NDNCERT spec based on today's NFD call (Mar 19).
>> Regarding the error message part, I am sure there are error types that I
>> missed. Please help to add more.
>>
>> https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3
>>
>> Also, please feel free to share your comments/suggestions here.
>>
>> Best,
>> Zhiyi
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200326/fd23b307/attachment.html>