[noise] non replayable XK/KK?

[Trevor Perrin]

On Sat, Jan 27, 2018 at 11:00 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Sun, Jan 28, 2018 at 5:26 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> Anyways, your important observation (from the Dominic Tarr paper) is
>> that an attacker replaying an initial message in NKpsk0 (for example)
>> could confirm the server still has the same static key and PSK, if it
>> responds.
>
>
> This is an issue because the specification requires early abort as soon as a
> MAC check fails.  But if the handshake ran to completion every time before
> reporting the failure, then the information leakage would not occur.  That
> is, collect errors along the way but then continue in a constant-time manner
> as though the values were correct.


Huh!  That's a clever point.

It does depend on servers getting const-time code right, including
const-time decryption and handling of static public keys and handshake
payloads (where decryption might succeed or fail).

Is deferring errors like this is better than deferring the crypto
operations ("defer" modifier)?

One reason I could see to prefer deferring errors is that you'd like
to do 0-RTT encryption, which you'd lose in going from, say, NK to
NKdefer:

NK:
  -> e, es
  <- e, ee

NKdefer:
  -> e
  <- e, ee, es

But if you're doing 0-RTT encryption, that means the server is
probably doing something interesting with the 0-RTT payload, and doing
that in const-time is likely difficult.

So while a "defer" modifier seems worth doing, I'm not sure that
deferring errors is safe enough to recommend?  Are there other
rationales / use-cases where it would be a good and safe practice?

Trevor