<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="">
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 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 class="">Marc</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<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="">
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>