<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 15, 2014 at 9:19 PM, Yingdi Yu <span dir="ltr"><<a href="mailto:yingdi@cs.ucla.edu" target="_blank">yingdi@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div>
<span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word"><div>On Sep 15, 2014, at 5:20 PM, Wentao Shang <<a href="mailto:wentaoshang@gmail.com" target="_blank">wentaoshang@gmail.com</a>> wrote:</div></div></span></span></div></span><div><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><br><br><div class="gmail_quote"><span class="">On Mon, Sep 15, 2014 at 4:02 PM, Alex Afanasyev<span> </span><span dir="ltr"><<a href="mailto:alexander.afanasyev@ucla.edu" target="_blank">alexander.afanasyev@ucla.edu</a>></span><span> </span>wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><span class=""><br>On Sep 15, 2014, at 3:50 PM, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu" target="_blank">lixia@cs.ucla.edu</a>> wrote:<br><br></span><span class="">> 1/ I agree with Wentao on the following:<br>><br>>> a link object "A -> B" involves two parties, i.e., A and B. Unless A and B are actually the same party, you need to have two signatures, one from A and one from B, to indicate that both parties have agreed on this link relationship.<br><br></span></span><span class="">This is very general statement.  On a surface, this could be a desired property.  The whole question which goal is this property achieving?  In my opinion, giving provider a tool to allow/deny hosting things inside the provider is much bigger harm then allowing anybody to express their desire for their client to try to request data from the specific provider. </span></blockquote><span class=""><div><br></div><div>I don't quite understand this argument: if the provider doesn't want to host the client's content, the link relationship wouldn't have existed in the first place.</div></span></div></div></div></blockquote><div><br></div><div>No, it is not about hosting the client's content, the client still hosts its own data from its own machine, but the machine is connected to the internet through att's network. Basically, the client only bought the internet access from att. If a link object signed by att is required to publish the data, it implies that att can decide the type of data that the client can publish. I think this violates the network neutrality, and nobody would like that.</div></div></div></blockquote><div><br></div><div>In this case, yes, double signature is not necessary because the link is pointing to the client's own data. As I said, double signature is only meaningful when the link tries to connect two different parties.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> The signature is only a technical means for the provider to express its approval of hosting. Whether the provide *will* host or not sounds more like a layer-10 issue to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As I mentioned before, even if such property implemented in the LINK, how is it different from just sending of bunch of unsatisfiable Interests towards the provider?<br></blockquote><div><br></div><div>I'm not comfortable with the logic behind this argument: if there are two backdoors that can lead to the same security hole, can we simply say that we can leave the 2nd door open because the hackers are going to use the 1st door anyway?</div></div></div></div></blockquote><div><br></div></span><div>No, the logic is: if one of the backdoor is easier to be exploited to launch an attack, what is the point of fixing the other backdoor (which is more difficult to be exploited)? Attackers are not fools.</div></div></div></blockquote><div><br></div><div>I don't have counter-argument to this one from technical perspective :) But at least this discussion should go into the "security considerations" section in the documentation.</div><div><br></div><div>Wentao</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Yingdi</div><br></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">PhD @ IRL, CSD, UCLA</div>
</div></div>