[Nfd-dev] Update on NDNCERT protocol

Zhiyi Zhang zhiyi at cs.ucla.edu
Tue Mar 3 12:43:42 PST 2020


On Tue, Mar 3, 2020 at 9:15 AM Davide Pesavento <davidepesa at gmail.com>
wrote:

> Zhiyi,
>
> On Tue, Mar 3, 2020 at 1:53 AM Zhiyi Zhang <zhiyi at cs.ucla.edu> wrote:
> >
> > Hi Junxiao,
> >
> > Thanks for the feedback, here are some questions regarding your
> comments. Could you please help to clarify?
> >
> > 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?
> > 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).
>
> I don't remember we discussed this RSA encryption during the calls.
> Can you clarify the use case?
>

Right. I came up with this idea when I am writing down the spec (I also put
a @TODO in the spec for discussion).
The rationale is: PROBE will generate names from inputs from the requester.
The inputs may contain private information like UID, email address, full
name, etc.
I am thinking we should encrypt the inputs.
There are two alternatives:
1. set up a TLS-like channel based on DH
2. insert an RSA encryption key into the CA profile so the requester can
use that key to encrypt the input


>
> Two more comments, I only took a brief look:
> 1/ What is the "salt" value used for? It shows up in the NEW Data
> content and nowhere else.
>

Oh, you are right. I will add the key derivation function to the doc. I
forgot that part.


> 2/ "The ECC curve by default is prime256v1": you're not providing any
> mechanisms to specify the elliptic curve, so saying "by default"
> doesn't make much sense. Effectively only one curve is supported.
>

Agree.

Best,
Zhiyi


>
> Thanks,
> Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200303/70c4a8d7/attachment.html>


More information about the Nfd-dev mailing list