[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Trevor Perrin]

On Sun, Jul 5, 2015 at 5:41 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Sun, Jul 5, 2015 at 8:30 AM, Trevor Perrin <trevp at trevp.net> wrote:
>> key.  So you could modify above to authenticate the first message
>> using static-static DH: does this work?
>>
>>   <- s
>>   ******
>>   -> e, dhes, s, dhss
>>   <- e, dhee, dhes
>
> Yes, this works I think. So the first step is a BoxX.

This is now HandshakeIK (I = client sends identity immediately, K =
server's static key is known to client).


> One immediate concern, however, is that it destroys PFS of the
> anonymity. If the responder's private s is ever compromised, an
> attacker who has been recording network traffic can then learn all the
> public keys who have communicated. This might be an acceptable and
> unavoidable tradeoff, though, in which case, I guess I'm fine with it.

Yeah that's the tradeoff if you want to send the client's identity in
the first flow.  You could consider HandshakeIE if it's possible to
pre-distribute a semi-ephemeral public key for the server, as well as
a static key:

HandshakeIE:
  <- s, e
  ******
  -> e, dhee, dhes, s, dhse
  <- e, dhee, dhes


> Question: is KCI a problem with this handshake?

If the server's static private key is compromised, the client's first
flow can be forged.  Presumably all that does is allocate a record on
the server.  The server's response will then introduce a fresher
ephemeral and perform a fresher authentication of the client.

HandshakeIE would also mitigate this, since the client authenticates
in the first flow using the server's semi-ephemeral key instead of
static key.


>>   <- s
>>   ******
> "s: The creator performs an encrypted write of her static public key. "
> "Pre-messages are not part of the protocol proper, but the parties
> should create and consume them as if they were."
>
> It might be worth noting that these pre-messages don't involve
> changing the nonce, though.

That follows because there's no k yet, so the values read / written
are in the clear.  Does this need to be explicit?


> That would be great. A lingering concern is something I read in the
> KEA+ paper -- that it's been *proved* that a two step handshake will
> never be able to have certain robust security properties, leading the
> authors to propose KEA+C, which includes an additional confirmation
> back-and-forth. I'm not sure how relevant this is to noise though.
> What's up here?

The exchange of authenticated-encryption ciphertexts is intended to
naturally provide "key confirmation".  But I need to add some text to
clarify when this happens, and in general clarify which properties
apply to which messages.


>> Replay of the first message is a real problem.  No great solution I
>> know short of timestamps or blacklists.
>
> Well in that case, can I propose we add djb's TAIA to the noise
> standard?
[...]
>
> Then the above handshake you proposed could be augmented as:
>
> <- s
> ******
> -> e, dhes, s, dhss, τ
> <- e, dhee, dhes
>
> For a server, it's simple enough to keep track of the latest τ
> received from a given client, to avoid a replay DoS that causes the
> currently communicating client to have his key invalidated.

I think that makes several assumptions specific to your use case:
 - there's a limited and known set of clients, so it's feasible for
servers to track a single record for each of them
 - clients can't have multiple simultaneous sessions with the server
 - clients have reliable clocks
 - servers have durable storage

Also, it's easy for you to add this - just add your time value into
the payload.  I think I'd prefer to keep the core minimal and generic,
and not add this.

Trevor