[Nfd-dev] Update on NDNCERT protocol

[Zhiyi Zhang]

On Tue, Mar 3, 2020 at 9:34 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Zhiyi
>
> 1. sec 2.1.2 why we need version + segment components? I understand the
>> use of version component but why bother segment component? What's the
>> benefit of using these two rather than timestamp?
>>
>
> Having a segment component is future proof: the information in a CA
> profile may exceed the optimal size of one segment.
> RDR <https://redmine.named-data.net/projects/ndn-tlv/wiki/RDR> metadata
> has a segment component for the same reason.
>

but why not simply set a final block id in /<ca-prefix>/CA/INFO/version so
that the requester can fetch more back?
we can omit the segment component for the first segment?


>
> 2. sec 2.1.2 yes I am considering RSA OAEP, the main reason for using RSA
>> instead of the session key (e.g., ECDH) is the round trip -- ECDH requires
>> an additional round trip to set up the session (which may be too costly for
>> an informational query).
>>
>
> RSA-OAEP is discouraged for new designs
> <https://crypto.stackexchange.com/a/51615>.
>
> NDNCERT, being a security protocol, should prioritize security properties
> over bandwidth cost.
> ECDH plus AES-GSM would provide better security properties that includes
> forward secrecy.
>

I agree with you.
We should have session keys to support forward secrecy.


>
>
>> 3. sec 2.1.4 do we need to consider the evolvability here? given it's an
>> application layer protocol and all fields clearly defined.
>>
>
> TLV evolvability guidelines should be followed by default, unless there's
> a reason to opt out of TLV evolvability guidelines.
>

Hmm. I didn't see the reasons why NDNCERT needs to follow the evolvability.


>
>
>> 4. sec 2.2.2 you suggested the type name be email and full name, do you
>> expect them to be pre-defined as TLV types? If so, it's really a usability
>> issue because different CAs may require totally different information for
>> the probe.
>>
>
> There are two options.
>
> First option is to include TLV-TYPE number for each item as part of the CA
> profile.
> The CA profile could say:
> <ProbeDefinitions>
>   <DescriptionEntry>
>     <DescriptionKey>email</DescriptionKey>
>     <DescriptionValue>1243</DescriptionValue>
>   </DescriptionEntry>
>   <DescriptionEntry>
>     <DescriptionKey>full name</DescriptionKey>
>     <DescriptionValue>3186</DescriptionValue>
>   </DescriptionEntry>
> <ProbeDefinitions>
> This tells the requester what TLV-TYPE numbers to use.
> The requester can then send:
> <ProbeParameters>
>   <1243>david.henson at contoso.com</1243>
>   <3186>David Henson</3186>
> </ProbeParameters>
>
> Second option is to use DescriptionEntry structure in the PROBE Interest
> packet.
> <ProbeParameters>
>   <DescriptionEntry>
>     <DescriptionKey>email</DescriptionKey>
>     <DescriptionValue>david.henson at contoso.com</DescriptionValue>
>   </DescriptionEntry>
>   <DescriptionEntry>
>     <DescriptionKey>full name</DescriptionKey>
>     <DescriptionValue>David Henson</DescriptionValue>
>   </DescriptionEntry>
> </ProbeParameters>
>
> Comparing these two options:
>
>    - First option makes PROBE Interest packet smaller.
>    - Second option has less complexity in terms of binary code size.
>
>
Another possible solution is:
T:probe-parameter, L, V: first probe parameter
T:probe-parameter, L, V: second probe parameter
...
The value of probe parameters is listed in the same order as defined in CA
profile.

Should the value type be defined also? if the value can be a string, an
integer, or bytes.


>
>
>
>> 5. sec 2.2.2. regarding multiple available names in PROBE reply, I don't
>> think so? given it's not an important feature. And we may not want to
>> bother CA to design a function to output multiple namespaces?=
>>
>
> ndncert-legacy allows the same email to request one of many name prefixes.
> For example, david.henson at contoso.com can request:
> /8=ndn/8=guest/8=david.henson%25contoso.com
> /8=ndn/8=edu/8=arizona/8=%40GUEST/8=david.henson%25contoso.com
> /8=ndn/8=edu/8=ucla/8=%40GUEST/8=david.henson%25contoso.com
> and many other names.
>

Okay, fair enough. I will mention this in the spec.

Best,
Zhiyi


>
> Likewise, new NDNCERT should allow multiple names as well referrals to
> sub-CAs to appear in the PROBE reply, to preserve this feature of the
> existing system.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200303/80a2eed7/attachment.html>