[noise] Generic fallback handling

[Rhys Weatherley]

On Sun, May 29, 2016 at 3:05 AM, <alex at centromere.net> wrote:

> On 2016-05-26 01:44, Rhys Weatherley wrote:
>
>> This API doesn't provide a complete implementation of Noise Pipes - it
>> only provides a primitive to make the application's life easier.
>> There are still the issues of packet types and framing for the
>> application to deal with.
>>
>
> In your estimation, can all Noise Pipes be provided completely on the
> application level, with API support just being a convenience wrapper?
>

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.


> The other approach is pre-message analysis: look at the arguments and
>> pre-messages for the new pattern.  Clear any key that is no longer
>> required, and check that required keys are already present in the
>> HandshakeState.  Each requirement is dealt with separately with a
>> keep/clear decision for each.
>>
>
> "the new pattern" -- what if, after your analysis is complete, that
> there are multiple valid patterns from which to choose?
>

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".

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.

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.

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)?

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160529/4b6aca07/attachment.html>