[noise] Mechanical definition of "fallback" modifier

[Trevor Perrin]

On Sat, Jun 10, 2017 at 9:16 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> I'm working on adding the rev32 changes to Noise-C / Noise-Java.  As part of
> that I'm implementing the "fallback" and "pskN" modifiers as mechanical
> translations on the base pattern at runtime.

Nice!, I'm eager to see how that works out, and what issues pop up.


> While "pskN" is well defined mechanically in rev32, "fallback" is not.
> Here's my attempt to make the definition precise:

Great, comments below.


> ---Start of definition---
> The "fallback" modifier applies to interactive base patterns that with the
> following properties:
>   * The pre-message must either be empty or "-> s".

Seems overly restrictive, I'm not sure we need any restrictions on the
pre-messages?


>   * The first handshake message must consist of a single "e" token.
> The "fallback" modifier thus applies to "NN", "NX", "XN", "XX", "KN", and
> "KX".  Applying "fallback" to any other base pattern is an error.


How about this, instead:  The first handshake message must not contain
any tokens which trigger a MixKey() call, such as ee, es, se, ss, or
psk.

This allows IN and IX, which seems reasonable to me.

It's true that if your 0-RTT handshake doesn't send s in clear then
you won't be able to use INfallback or IXfallback, but I think that's
a concern for some higher-level discussion of combining fallback
handshakes and 0-RTT handshakes.

I also would only discuss restrictions wrt the input pattern, not the
base pattern, because you could imagine other modifiers transforming a
base pattern so the restrictions apply or don't apply.


> The following modifications are applied to the base pattern:
>   * The "e" token in the first message is moved to the pre-message as either
> "<- e" or "<- e, s".
>   * The first message is deleted from the handshake.
>   * The remaining messages have their directions reversed.
>   * All "es" tokens are replaced with "se", and all "se" tokens are replaced
> with "es".

Revision 32 should have eliminated the need for some of this, because
the roles are no longer reversed.  So all you have to do is eliminate
the first message and move the public keys from the first message into
the initiator's pre-key message, your last 2 bullets are no longer
needed.


> The "fallback" modifier does not commute well with other modifiers:
> "XXfallback+psk2" is not the same handshake as "XXpsk2+fallback" for
> example.  "XXfallback+psk0" is valid, but "XXpsk0+fallback" is invalid
> because the first message is no longer a single "e" token.

Another issue is that fallback removes removes one message, so psk0 or
psk1 + fallback are always invalid, but psk3+fallback would be
equivalent to fallback+psk2.


>
> It is recommended that if the "fallback" modifier is present, then it should
> be applied before all other modifiers.

If we're going with the alphabetic convention, I'm not sure this
comment is necessary?


> The definition could be simplified further by restricting it to "XX" only.
> I'm not sure whether things like "NNfallback" and "KXfallback" are useful,
> but maybe someone can think of a use for them.

I think it's better to stay general.  NXfallback and IXfallback seem
obviously useful.  NNfallback could make sense if the client is
authenticating some other way (e.g. sending a password or signature
inside an encrypted transport payload).

Trevor