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

[Zhiyi Zhang]

Just pushed.

Besides the comments you made, I also added `allow-longer-name` to the CA
profile to indicate whether CA allows longer identity name applications
(apply /example/alice). I removed `certificate` from the CA profile because
we can reuse CertificateV2.

Best,
Zhiyi

On Tue, Mar 31, 2020 at 2:02 PM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:

>
>
> 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/34d2d118/attachment-0001.html>