<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 2:27 PM Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi Zhiyi<br><div class="gmail_quote" dir="auto"><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Your mentioned attack scenario is valid and possible. Thank you for pointing that out!</div><div>Given the ndncert protocol is for two ends only, I think we can add a Diffie-Hellman process in the NEW command and its reply.</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">I hope you are referring to ECDH, not classical Diffie-Hellman. Many IoT devices have binary code size constraint. Since ECDSA must be supported, it takes less binary code to add ECDH than to add classical DH.</div></div></blockquote><div><br></div><div>Yes. ECDH is what in my mind.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>With the negotiated shared secret by DH, the requester and issuer can:</div><div>1. Use hmac to sign the request which is faster and fits IoT scenarios</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">This is false. With low-cost crypto chip such as ECC508 (less than $1), IoT devices can easily access ECDH and ECDSA implemented by hardware.</div><div dir="auto">Also, NDNCERT is not just for IoT.</div></div></blockquote><div><br></div><div>It's true that NDNCERT is not just for IoT. Even though many chips are equiped with ECC support, there are still many boards who don't have (e.g., the xpro boards we were using). On xpro board, our real world tests show that HMAC is more than ten times faster than ECC.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2. Use key derived from the shared secret to AES encrypt the sensitive components and Data content (prevent Eve to see the PIN_E and all the other sensitive info)</div></div></blockquote></div><div dir="auto">Yes.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>On the other hand, I will update the email format to include the full certificate name and request id (each request instance has a unique ID)</div></div></blockquote></div><div dir="auto">Usability is a concern: user is going to neglect the request ID. There are two solutions:</div><div dir="auto">First, digest of the public key can be represented as graphics (e.g. a cat face with various colors and features). A client with GUI capability can display the graphics, and the user can compare the graphics with one generated by CA and embedded in the email.</div></div></blockquote><div><br></div><div>This sounds interesting, but I hold another opinion on this. If we apply DH (or ECDH) in NDNCERT protocol, there is already no way that Eve can see the which challenge has been selected and what the PIN_E is. In this case, Eve cannot hurt anymore.</div><div>NDNCERT command line tools are more like a prototype to show how to use NDNCERT library. I would expect each system has their own realization of CA. If they want to have the fancy images, they can implement this feature.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">Second, the PIN code can be prefixed by the request ID. The email says "PIN code 777777-666666"; the client prompts "Enter PIN code: 777777-"; the user types "666666".</div></div></blockquote><div><br></div><div>I would adopt this solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I have already take the ndncert server offline. We will perform a major upgrade on ndncert protocol and ndncert codebase.</div></div></blockquote></div><div dir="auto">When can we see a preview of the new protocol?</div></div></blockquote><div><br></div><div>I have some slides but is not in a good shape. I can organize it and update a google slide link later.</div><div>Some new features:</div><div><br></div><div>1. Use interest parameters to save the bandwidth used by Data name</div><div>2. ECDH for encrpting Interest name (partially) and Data content</div><div>3. Support ephemeral certificates by letting requester to specific the certificate validity period (of course cannot larger than CA's max validitiy period setting)</div><div>4. Support "code start" by using TOFO (trust on first use) when the requester don't know CA in advance. (Notice it's possbile to have Man In the Middle attack in this case)</div><div>5. Simpified APIs (the current API requires many embedded call backs to work together)</div><div><br></div><div>Best,</div><div>Zhiyi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Yours, Junxiao</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>