<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 29, 2016 at 3:05 AM,  <span dir="ltr"><<a href="mailto:alex@centromere.net" target="_blank">alex@centromere.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-05-26 01:44, Rhys Weatherley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This API doesn't provide a complete implementation of Noise Pipes - it<br>
only provides a primitive to make the application's life easier.<br>
There are still the issues of packet types and framing for the<br>
application to deal with.<br>

</blockquote>
<br></span>
In your estimation, can all Noise Pipes be provided completely on the<br>
application level, with API support just being a convenience wrapper?<span class=""><br></span></blockquote><div><br></div><div>With this primitive, the remaining technical parts of Noise Pipes are issues of packet framing and socket operations.  There are also policy decisions as to how to store the credentials from a previous XX full handshake to use in a future IK abbreviated handshake.  API support for all that would be a plus, but it doesn't necessarily belong in the core Noise protocol code.  We've discussed a "TransportState" or something similar in the past for formalizing higher-level activities.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other approach is pre-message analysis: look at the arguments and<br>
pre-messages for the new pattern.  Clear any key that is no longer<br>
required, and check that required keys are already present in the<br>
HandshakeState.  Each requirement is dealt with separately with a<br>
keep/clear decision for each.<br>

</blockquote>
<br></span>
"the new pattern" -- what if, after your analysis is complete, that<br>
there are multiple valid patterns from which to choose?<br></blockquote><div><br></div><div>The application will need to make some policy decision, and would then call Fallback(pattern) for the chosen one.  The policy decision might be static, based on application-specific knowledge about the higher-level protocol, or based on the presence or absence of static/ephemeral key values in the abbreviated handshake.  It's hard to make a one size fits all rule.  But what we can do is define a primitive for "once the application has decided to transition from A to B, here's how it is done".<br><br></div><div>As an extension to my previous description, I will note that I see fallback and resumption as two different but related problems.  Fallback is executed immediately within the context of a single session: "whoops, IK failed, try XXfallback instead".  Resumption is where the initial session worked perfectly, but it also outputs credentials that can be used to establish a new session at some later date (maybe much later).  The XX -> IK part of Noise Pipes is resumption.  IK -> XXfallback is fallback.<br><br></div><div>Resumption can use pre-message analysis to determine what values need to be retained in non-volatile storage for the later session (remote static public key, generated PSK, etc).  Fallback uses pre-message analysis to make an instantaneous decision as to how to restart the current session with a new pattern based on information already present in the session.<br><br></div><div>For resumption scenarios, there might be multiple patterns that could be used in the new session; e.g. XX might resume as either IK or PSK_NN.  The application would of course need to export multiple credentials and then make some policy decision as to which to import to Initialize() the new session. Export([IK, PSK_NN])?  Import(PSK_NN)?<br></div><div><br></div></div></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>