[noise] Stricter rules #1: replacing public keys

[Trevor Perrin]

The current rules allow patterns to send as many ephemeral public keys
as they want, and aren't clear whether a pattern could send multiple
different static public keys.  E.g. is this legal?

-> e
<- e
-> e # second new ephemeral?

Or this?

-> e, s
<- (whatever)
-> s # second new static?

I think there's no good reason to change your ephemeral public key
more than once (going from a pre-known "semi-ephemeral" key to a fresh
one).

Is there ever a good reason to change your static public key?  You
could imagine an entity in process of migrating from one public-key to
another.  So a zero-RTT message might be encrypted to the older public
key.  E.g:

<- s  # responder's old static public key
...
-> e, dhes
<- e, dhee, s, dhse   # responder's new static public key


Seems like a rare case, so I'm inclined to disallow this.  If you
really want to do this, you could use handshake re-initialization to
combine two patterns.  E.g.:

<- s
...
-> e, dhes

Then re-initialize with initiator/responder roles reversed, e from
first protocol as pre-message, h from first protocol as prologue:

<- e
...
-> e, dhee, s, dhse

So I lean towards clarifying:
 - only one new ephemeral can be sent during a Noise protocol (which
might replace a semi-ephemeral)
 - the static public key cannot change during a Noise protocol

?


Trevor