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

[Junxiao Shi]

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.


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


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

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

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

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.

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

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.

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

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.

issued-cert-name is a full name, so it should be:

issued-cert-name = ISSUED-CERT-NAME-TYPE TLV-LENGTH Name

instead of *OCTET.

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

Yours, Junxiao

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200328/2044243b/attachment.html>