<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Yingdi, </div>
<div><br>
</div>
<div>I thought one design motivation for the security libraries was to implement some widely-applicable techniques so as to avoid likely security screw-ups in applications?  Is that something to consider here? </div>
<div><br>
</div>
<div>Also, is it practical that the average application would to have to implement timestamp/nonce checking itself to just handle a signed interest?  Even if it's not that hard, this seems way too detailed—and unrelated to the actual functionality of many applications—for
 many straightforward apps that might still use Signed Interests.</div>
<div><br>
</div>
<div>A possibility would be to offer one or more "standard" timestamp/nonce checking approaches in the library but at the same time allow applications that have different needs to override them.   There might be more likelihood of application interoperability
 if such standard techniques are widely available, too.  </div>
<div><br>
</div>
<div>As with encryption, perhaps it make sense for these capabilities to be implemented in another library "on top of" a core library that only does verification of signatures... but this second library is still useful to flesh out at this point, I think.</div>
<div><br>
</div>
<div>Just a thought... </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Jeff</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Yingdi Yu <<a href="mailto:yingdi@CS.UCLA.EDU">yingdi@CS.UCLA.EDU</a>><br>
<span style="font-weight:bold">Date: </span>Tue, 17 Feb 2015 13:05:29 -0800<br>
<span style="font-weight:bold">To: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Cc: </span>"<<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>>" <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<span style="orphans: 2; text-align: -webkit-auto; widows: 2;" class="">I do not like the idea of handling timestamp and nonce in the validator. The validator checks signatures. The timestamp and nonce is not the attributes of signatures but the attribute of
 the command. So timestamp and nonce should be handled by those which process the command. </span><br class="">
<div apple-content-edited="true" class=""><br class="">
</div>
<div apple-content-edited="true" class="">Actually, there are a variety of mechanisms to check timestamps. If we move the timestamp and nonce checking out of validator, then applications can freely choose the timestamp checking mechanism that fits their requirement
 best. Say if stop-and-wait fits the requirements of an app, then there is no need to use or implement sliding window. If strong sequencing is required, the app may use the timestamp as a session id and append sequence number after the timestamp, and then the
 nonce. For commands in the same session, they can be issued without waiting for the ack from the other side. </div>
<div apple-content-edited="true" class=""><br class="">
</div>
<div apple-content-edited="true" class="">I just do not feel it correct if we hardcode the timestamp checking procedure as a part of signature verification, because it forces every application to use the same timestamp checking mechanism. This is my 2 cents.</div>
<div apple-content-edited="true" class=""><br class="">
</div>
<div apple-content-edited="true" class="">Yingdi</div>
<div apple-content-edited="true" class=""><br class="">
</div>
<div apple-content-edited="true" class=""><br class="">
</div>
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Feb 15, 2015, at 8:14 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu" class="">shijunxiao@email.arizona.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Dear folks
<div class=""><br class="">
</div>
<div class="">During the resolution of #1990, <a href="http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing" class="">
SignedInterestProcessing</a> wiki page recommends stop-and-wait in order to fit the validation procedure.</div>
<div class=""><br class="">
</div>
<div class="">Stop-and-wait is easy to implement but is not a good design because it throttles command rate. Sliding window such as that used by TCP is a better solution for Interest ordering.</div>
<div class="">A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.</div>
<div class=""><br class="">
</div>
<div class="">The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.<br class="">
</div>
<div class="">Depending on the nature of the command, this attack may or may not cause harmful effect.</div>
<div class="">
<ul class="">
<li class="">"1. turn on kitchen light" "2. turn on bedroom light": reordering doesn't change final state; if the intention is to turn on both lights without caring the order, it's acceptable<br class="">
</li><li class="">"1. set light to red" "2. set light to green": reordering causes an undesirable final state</li></ul>
</div>
<div class="">I think this risk is acceptable, given the risk is always controllable by the requester:</div>
<div class="">
<ul class="">
<li class="">when order of execution doesn't matter (such as in first example), the requester can send multiple commands together</li><li class="">when reordering (either by network or by attacker) will cause undesirable effects (such as in second example), the requester can adopt stop-and-wait: don't send the second batch of commands before all commands in the first batch are complete</li></ul>
</div>
<div class=""><br class="">
</div>
<div class="">What do others on this mailing list think?</div>
<div class=""><br class="">
</div>
<div class="">Yours, Junxiao<br class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <span dir="ltr" class="">
<<a href="mailto:bzhang@cs.arizona.edu" target="_blank" class="">bzhang@cs.arizona.edu</a>></span> wrote:<br class="">
<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">
<div style="word-wrap:break-word" class="">
<div class="">NDN network doesn’t guarantee in-order delivery; the end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP.</div>
<div class=""><br class="">
</div>
<div class="">I don’t understand why the love of stop-and-wait. Not only did you mention it in this email, but also on the wiki page as a suggested design. Look, you used stop-and-slow because it’s easy to implement, not because it has better features. The
 traditional sliding window that TCP uses can do the same and better, and there are other ways to ensure packet order. Just your app uses stop-and-wait doesn’t mean it’s a good one for others. You should stop making such a recommendation, e.g., remove it from
 the wiki.</div>
<span class=""><font color="#888888" class="">
<div class=""><br class="">
</div>
<div class="">Beichuan</div>
</font></span></div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________ Nfd-dev mailing list <a href="mailto:Nfd-dev@lists.cs.ucla.edu">
Nfd-dev@lists.cs.ucla.edu</a><a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a></blockquote>
</span>
</body>
</html>