[noise] rev34 update

[Trevor Perrin]

Hi all,

I made significant changes to the rev34 draft.  Would appreciate
review, if this looks good to other people I'm hoping to publish at
end of this week:

https://github.com/noiseprotocol/noise_spec/blob/rev34/
https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf

CHANGES:

 (1) New security considerations for key reuse, making clear that
Noise static keys and PSKs shouldn't be used with non-Noise protocols,
or with different hash algorithms.

Early uses of Noise were simple and hardcoded, but now that we're
contemplating negotiation (in NLS) and people are looking at more
complex scenarios, key reuse is going to be more tempting.

So we should clearly discourage this (though it's possible to do it
safely in some cases with careful analysis, so it's hard to completely
prohibit).  This was also motivated by Karthik and others discussing
PSK reuse in TLS, recently, which made me realize Noise also needed to
be more careful.


 (2) Left the deferred patterns as they were (did not add "ss" to K1K
and I1K as had been discussed with Justin).  The reason is that adding
"ss" in these cases would create invalid patterns:

K1K:
    -> s
    <- s
    ...
    -> e, es[, ss]
    <- e, ee
    -> se

I1K:
    <- s
    ...
    -> e, es, s[, ss]
    <- e, ee
    -> se


In these cases, the responder would be encrypting data after ss but
without se, which runs afoul of our complicated final validity rule.

The validity rule makes sense here because an invalid initiator
ephemeral might cause the ee value to be fixed (e.g. zeros for
X25519), so we need to incorporate the se to randomize the encryption.
Also, if we care about authenticating the initiator (by doing ss),
then we should care about doing it well (by doing se).


 (3) Clarified the aforementioned complicated validity rule in 7.3.
Hopefully it's easier to understand what it means and why it's
necessary, now.


 (4) Added Justin's pattern derivation rules in an appendix (I edited
the text, and adjusted per above, but the logic is largely the same).


 (5) Added Nadim's proposed validity rule to disallow redundant DH operations.


Trevor