[noise] Oddity with IKnoidh, IXfallback, and PSK's

[Trevor Perrin]

On Thu, Jul 7, 2016 at 1:27 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
>
> All of the extra fallback scenarios work except for one: IKnoidh ->
> IXfallback when PSK's are involved (the scenario is fine if there isn't a
> PSK).  It took a while to figure out why.
>
>     Noise_IKnoidh(s, rs):
>       <- s
>       ...
>       -> e, s, dhes, dhss
>       <- e, dhee, dhes
>
> If there is a PSK involved, then the "s" token from the initiator to the
> responder in the abbreviated handshake will be encrypted and MAC'ed.  The
> associated data for this token encryption is based on a "h" generated from
> the "rs" in the IKnoidh pre-message.
>
> When the packet arrives at the IKnoidh responder, the "s" token cannot be
> decrypted if the responder's "rs" has changed.  The associated data "h"
> value will be different, so the "s" value from the initiator will be
> discarded before it can be decrypted.  The initiator's "s" value is then no
> longer available to initiate the "IXfallback" pattern.
[...]
>
> Maybe the lack of support for PSK's in this case is OK.  Maybe not.
> Something to think about.


Hmm!  Good observation.  Agreed this will take some thinking.

Brainstorming, some options might be:

(1) Recipient holds onto its old static public keys, so it can decrypt
the initial message even after changing its private key.

(2) In the PSK case, send the initiator static but treat it as a
pre-message, instead of part of the main handshake.

(3) Have some special token or rule that allows exempting initiator's
"s" from encryption in this PSK case (so it's treated like an "e"
token).


Trevor