[noise] Rev30 branch

[Trevor Perrin]

On Wed, Jun 29, 2016 at 6:38 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Thu, Jun 30, 2016 at 10:49 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>>  - generalizes Noise Pipes to allow combining different patterns
>> besides XX/IK (e.g. NX/NK, IX/IK, XX/XK).
>
>
> Nice.  Should be easy to extend my fallback() method in Noise-C and
> Noise-Java to do this.
>
> However, does this mean that new patterns will need to be defined for the
> fallback part?  XX/IK/XXfallback, NX/NK/NXfallback, IX/IK/IXfallback, ...?
> The NX/NK one is the interesting one: XXfallback requires client
> authentication but NX and NK don't, so XXfallback is not sufficient to
> complete the protocol.
>
> Perhaps there is some general way to transform the pattern for AA in AA/BB
> into AAfallback?


Good question, this will take some thinking.

I think most cases can use XXfallback, or a very similar NXfallback if
no client auth:

----

XX/IK -> XXfallback (default Pipes)

XX/XK -> XXfallback (deferred client auth on resumption)
IX/IK -> XXfallback (no client ID hiding on initial session)

NX/NK -> NXfallback (no client auth)


Noise_XXfallback(s, rs, re):
  <- e
  ...
  -> e, dhee, s, dhse
  <- s, dhse


Noise_NXfallback(s, re):
  <- e
  ...
  -> e, dhee, s, dhse

The fallback patterns are derived by just making the first message
("e") a pre-message.

----

If you don't care about client identity hiding, IX/IK isn't ideal,
because if the server fails to decrypt the IK first message, it
doesn't learn the client's identity.

So you might want to use a variant of IK (call it IKclear?) where the
client's identity is moved outside the encryption:

IX/IKclear -> IXfallback

Noise_IKclear(s, rs):
  <- s
  ...
  -> e, s, dhes, dhss
  <- e, dhee, dhes

Noise_IXfallback(s, rs, re):
  <- e, s
  ...
  -> e, dhee, dhes, s, dhse

Note that IXfallback is derived the same way as XXfallback and
NXfallback, but it's technically invalid per current spec, which
demands premessages be formatted "s, e" instead of "e, s".

No current patterns use "s, e" pre-messages, so I'm thinking we should
just change this in Section 8 so that "e, s" is the valid pre-message,
and then the fallback conversion is simpler.


Trevor