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

[Zhiyi Zhang]

On Sat, Mar 28, 2020 at 11:51 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> These comments are on revision 5520432.
>
> *Terminology*
> "the TLV encoding of integer, string, and bytes all follow NDN TLV
> encoding", but none of these encodings is specified on the linked page.
>
> Also, links to http://named-data.net should use https://named-data.net
> instead.
>

Addressed.


>
>
> *INFO step *
>
>> 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 that important? and for completeness, I would still keep it?
>>
>
> Under RDR, the requester first expresses an Interest to retrieve the
> metadata with Interest:
>
> /<CA-Prefix>/CA/INFO/32=metadata
> CanBePrefix=1
> MustBeFresh=1
>
> The returned Data would contain the version of current CA profile. The
> requester then expresses another Interest to retrieve a specific version of
> CA profile:
>
> /<CA-Prefix>/CA/INFO/v=*VERSION*/seg=0
>
> CanBePrefix=0
>
> MustBeFresh=0
>
> The Interest listed in NDNCERT spec does not conform to either of these
> Interests and would not be used by a consumer that follows RDR procedure.
>

Addressed. I removed the Interest format.


>
>
> *PROBE step*
> probe-parameter and probe-parameter-value TLV-TYPEs should be critical, as
> a CA that does not understand these TLV-TYPEs cannot process a PROBE
> Interest correctly.
> Generally, you can assign critical TLV-TYPE numbers to everything in the
> initial protocol revision (i.e. this version), and decide whether to use
> critical or non-critical for new additions in the future.
>

The PROBE can be empty? if the CA ask the requester to get an available
name through PROBE but does not require any parameters?
hmm, maybe we shouldn't consider this scenario.


>
> *NEW step*
> ecdh-pub has 67 octets. How is this calculated?
> I used the following code to generate ECDH public key on P-256 curve and
> export as raw uncompressed format, and it is 65 octets:
>
>
> crypto.subtle.generateKey({name:"ECDH",namedCurve:"P-256"},false,["deriveKey"])
>   .then(({publicKey})=>crypto.subtle.exportKey("raw",publicKey))
>   .then(console.log)
>
>
> The link to "ndn certificate" should (1) use "NDN" instead of "ndn" (2)
> link to specific document version instead of "current".
>

Addressed.


>
> In ABNF of Data format, "ApplicationParameters" should be "Content".
>

Addressed.


> In Data format, request-id is defined as 8OCTET.
> Assuming it is the same thing as <Request_ID>, this conflicts with
> Terminology section that defines it as one name component.
> A name component needs to specify its TLV-TYPE.
>

Addressed.


>
> The status field is defined but unused. I think this field is unnecessary
> in this step.
>

Addressed. I removed it.

>
> HKDF needs three parameters
> <https://developer.mozilla.org/en-US/docs/Web/API/HkdfParams>: hash,
> salt, info.
> The hash function is not specified in the protocol.
>

Addressed. SHA256.

>
> *CHALLENGE step*
> The initial-vector for AES-GCM-128 is 12 octets, not 16 octets. Also, in
> ABNF, it should be written as 12OCTET, not 12OCTETS.
>

Addressed.


>
> In ABNF, you are missing a definition of what's the object prior to
> encryption:
>
> PLAINTEXT =
>   selected-challenge
>   1*(challenge-parameter challenge-parameter-value)
>
> The above is for the Interest payload. Data payload needs a similar
> definition.
>

Addressed.


>
> issued-cert-name is a full name, so it should be:
>
> issued-cert-name = ISSUED-CERT-NAME-TYPE TLV-LENGTH Name
>
> instead of *OCTET.
>

Addressed.


>
> *Certificate Application Procedure*
> Does the CA start the challenge timeout clock since sending NEW Data or
> since receiving the first CHALLENGE Interest?
> If the former: how can the requester know how long does it have to select
> and complete the challenge?
> If the latter: it could be insecure because a requester could send a NEW
> Interest and wait for a long time before starting CHALLENGE, forcing the CA
> to hold onto the AES session key for a long time.
>

Addressed.

Best,
Zhiyi


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