<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Marc,<div class=""><br class=""></div><div class="">Thanks for your reply and interesting ideas. </div><div class=""><br class=""></div><div class="">I do have some more questions.</div><div class=""><div><blockquote type="cite" class=""><div class="">On 14 Apr 2017, at 21:09, <a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a> wrote:</div><br class="Apple-interchange-newline"><div class="">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">

<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Pengyuan,
<div class=""><br class="">
</div>
<div class="">In general there is not the same idea of TLS handshakes because the trust anchors for content would not be the same as the replica name hosting that content in cache.  NDN has several tech reports on different ways to encrypt data that you can
 find in their publications section.</div>
<div class=""><br class="">
</div>
<div class="">In the CICN community, we’ve addressed this mainly two ways:</div>
<div class=""><br class="">
</div>
<div class="">1) The publisher includes the public key in the first content chunk (or a named pointed to it).  If the content is encrypted for a particular recipient, then the publisher wraps a symmetric key in the first chunk then generates per-chunk session
 keys based on the symmetric key and the chunk number (i.e. the chunk number becomes part of the IV in the AES algorithm’s key derivation).  In CICN, we’ve favored encapsulation encryption (i.e. there’s an unencrypted outer name used for transport and an inner
 name part of the wrapped encrypted object) as that leaks the least amount of information.</div>
<div class=""><br class=""></div></div></div></blockquote>In that sense, encryption is not made on the fly, will that be vulnerable for those relative static content which exist in the network for long time?<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">
</div>
<div class="">2) When a replica name is known, for example the publisher lists that you can get the content from Comcast or Akamai, then the client can use a TLS like protocol to get session encryption to that replica.  See, for example, <a href="https://www.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.txt" class="">https://www.ietf.org/id/draft-wood-icnrg-ccnxkeyexchange-01.txt</a>.
  This form of opportunistic channel encryption does not replace the end-to-end manifest (or merkle hash tree) signing, but compliments it.  It also includes mechanisms where a user can authenticate to a publisher then get a re-direction token to continue a
 TLS-like session with a particular replica.</div>
<div class=""><br class=""></div></div></div></blockquote>This seems interesting and I may misunderstood this. By publisher lists, does that assume that multiple publishers willing to provide same contents to users in a “sharing” way? If so, I’m wondering the feasibility due to the actual competition relationship of the publishers.<br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">
</div>
<div class="">Marc</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Apr 14, 2017, at 11:55 AM, Pengyuan Zhou <<a href="mailto:zpymyyn@gmail.com" class="">zpymyyn@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi all,<br class="">
<br class="">
According to my understanding, the KeyLocator has the storage location of the key.<br class="">
<br class="">
My question is where normally should the key be stored, especially for secure transmission?<br class="">
<br class="">
Since NDN is not end-to-end, there might not be thing like "TLS handshake”, or is there?<br class="">
<br class="">
If not, then how does NDN realise the agreement of "Master Secret and Session key” (or sth. similar)?<br class="">
<br class="">
Seems to me that all the key info including the KeyLocator are predefined before transmission, is that realistic?<br class="">
<br class="">
There might be understanding, please correct me if so.<br class="">
<br class="">
Thanks.<br class="">
<br class="">
Best,<br class="">
Pengyuan Zhou<br class="">
University of Helsinki<br class="">
_______________________________________________<br class="">
Ndn-interest mailing list<br class="">
<a href="mailto:Ndn-interest@lists.cs.ucla.edu" class="">Ndn-interest@lists.cs.ucla.edu</a><br class="">
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" class="">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>

</div></blockquote></div><br class=""></div></body></html>