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

[Junxiao Shi]

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


*NEW*
challenge: how to specify multiple possible challenges?
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?

*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/20200323/5dae8768/attachment.html>