<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="">
See replies in-line
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 16, 2017, at 6:05 AM, Pengyuan Zhou <<a href="mailto:zpymyyn@gmail.com" class="">zpymyyn@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Hi
 Marc,</span>
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<br class="">
</div>
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
Thanks for your reply and interesting ideas. </div>
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<br class="">
</div>
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
I do have some more questions.</div>
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<blockquote type="cite" class="">
<div class="">On 14 Apr 2017, at 21:09,<span class="Apple-converted-space"> </span><a href="mailto:Marc.Mosko@parc.com" class="">Marc.Mosko@parc.com</a><span class="Apple-converted-space"> </span>wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
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="">
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yes, this is the common publish-and-forget approach of ICN.  There are a variety of key-wrapping techniques to communicate a symmetric data key to a designated consumer (see the older CCNx way of doing it [1] or the link Jeff sent to the NDN group access
 control).  Both use techniques to wrap a symmetric keys for each consumer for some piece of data (there are a variety of technical differences and there are other proposals).</div>
<div><br class="">
</div>
<div>The larger picture is as you say, one-way encryption.  There are some advantages in this if your network model is disconnected (in time or space).  There are also some cryptographic disadvantages, such as needing to know all the consumers (to wrap the
 key for them), no forward secrecy, and correlation attacks.   It usually also has a lazy idea of revocation: to remove a group member one changes the keys going forward, but does not go backwards and re-encrypt under the assumption that whatever was previously
 published as readable has already been read (it’s could also be a huge computational endeavor).</div>
<div><br class="">
</div>
<div>Some have argued that for some content, e.g. static page elements from a bank page, it’s ok to use such an approach because an attacker already knows your going to that bank via the name (or IP address).  It’s only the personal information that needs session
 encryption.  I think as long as an attacker cannot gain more information about you (e.g. you download the “I’m super crazy rich” image vs the “I’m in debt” image) it could be ok, but that level of cognizance about what leaks information is often hard to see
 ahead of time (my example was pretty blatant).  It is safer to assume all page elements could leak information.</div>
<div><br class="">
</div>
<div>[1] <a href="https://github.com/ProjectCCNx/ccnx/blob/master/doc/specs/AccessControl/AccessControlSpecs01.pdf" class="">https://github.com/ProjectCCNx/ccnx/blob/master/doc/specs/AccessControl/AccessControlSpecs01.pdf</a></div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<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="">
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>By “publisher lists” I meant that a single publisher (e.g. Hulu) publishes a list of the approved cached (e.g. Akamai, Comcast, Fastly).  It would sign this and make it public with some TTL.  A consumer can then learn the name of the caches (really CDNs)
 and match that against a certificate in the TLS-like (CCNxKE) transaction.  If a consumer did not know to trust a specific name, then you’d be vulnerable to MITM attacks trying to set up an opportunistic encrypted session.  </div>
<div><br class="">
</div>
<div>The root of trust could be a 3rd party like today (e.g. verisign et al.) or could be provided in the “publisher list” or could be via some other mechanism like schematized trust.  One must ensure that whatever is used in this step is also resistant to
 MITM.</div>
<div><br class="">
</div>
<div>This establishes the outer security layer for an encrypted session that can then pass inner Interests and Data through it.  Those inner names do not need to be correlated to the outer names.  It thus achieves protection against observability without the
 publish-and-forget approach.  That said, it is still likely that a video provider (or other paywall content provider) would use broadcast encryption of the payloads and likely with non-obvious names.  Or other models, such as the paywall content provider running
 their own servers in the CDN’s network so the session encryption and inner object signing are all that is needed without an extra encryption layer.</div>
<div><br class="">
</div>
<div>This scheme is pretty similar to what happens today.  You connect to a publisher (e.g.
<a href="http://www.hulu.com" class="">www.hulu.com</a>) and that publisher gives you back a link to content that will then resolve (via DNS) to a CDN (e.g. a Fastly IP address).  One difference is that to get the “gold lock” the CDN is impersonating the publisher’s
 TLS certificate so the certificate name and URI host match.  In the CCNxKE approach, we decouple the channel session encryption from the content provenance, so you can separately trust both whom you talk to and what you talk about.</div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div class="" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<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></div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>