[zeromq-dev] CurveZMQ comments

[Trevor Perrin]

On Wed, Sep 25, 2013 at 1:08 AM, Pieter Hintjens <ph at imatix.com> wrote:
> On Wed, Sep 25, 2013 at 1:04 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> 1) Since it's running over TCP (not UDP), are the "anti-amplication
>> padding" and "cookie" from CurveCP still needed?
>
> You can do amplification attacks over TCP,

I believe the "anti-amplification padding" is intended to prevent
"blind amplication attacks" [1], i.e. distributed denial-of-service
attacks where responses are sent to a victim based on forging of
source IPs (eg DNS).

TCP prevents this.  With TCP, all you can do is a "self-DoS" of your
own network by, say, downloading large files, or opening huge numbers
of TCP connections.

DJB argues that his *UDP-based* CurveCP resists this better than TCP
due to its different handling of congestion, retransmits, etc [1].
But I don't believe the anti-amplification padding is relevant to
that.  There are plenty of other ways a client can send small TCP
requests that generate enormous responses (downloading webpages or
movies, for example).


> and the cookie reduces the
> state the server has to hold for unknown clients.  The cookiie
> mechanism might be simplified but at this stage I don't see a problem
> with sticking closely to CurveCP where possible.

The cookie mechanism avoids server state for new-connection requests.
So it's relevant to Dan's UDP-based CurveCP.  But once you're
exchanging TCP data you've already paid that cost.

The downside of the cookie mechanism, aside from bandwidth/complexity,
is that the server's response containing the cookie has to be
encrypted.

If you did without cookies, and also simplified the key agreement
along the "triple-Diffie Hellman" lines I suggested, then you could
have a much simpler first round trip.  Only ephemeral keys would need
to be exchanged (no cryptoboxes, cookies, etc.):

Client -> Server: C'
Client <- Server: S'
Client -> Server: <Encrypted stuff>


>> 2) Assuming the exchange of messages happens over an in-order
>> transport like TCP, would it be possible to "rekey" for forward
>> secrecy as messages are exchanged, so a key compromise at time T would
>> not affect earlier data?  (See discussion of such mechanisms here
>> [1]).
>
> Presumably, yes. Are you volunteering to do the design work? :)

If you have a stream of ordered messages this is easy (and of course,
you could view a TCP connection as a pair of such streams, once you
add message framing):

  K[i]  : 32-byte keys, where K[0] is from the key agreement
  MK[i] : 32-byte message keys used to encrypt/decrypt the i-th message

  MK[i], K[i] = Salsa20(K[i-1], nonce=0)

In other words:
 * Use Salsa20 with a 32-byte K[i-i] to generate 64 bytes of output
 * Divide that output into MK[i] and K[i]
 * Upon encrypting or decrypting Message[i], securely delete the old
keys and generate MK[i+1].


>> 3) If the client doesn't already have the server's public key, it
>> would presumably need to retrieve it, which would add a 3rd round-trip
>> to the CurveZMQ handshake before data could be sent, on top of the TCP
>> handshake.  That's a lot of latency, would you consider alternatives
>> like:
>>  - Allowing the server's long-term key to be sent in the WELCOME command
>>  - Allowing sending of client data in the INITIATE command
>
> The client can send data immediately after sending INITIATE, without
> waiting for a reply. It just sends INITIATE and then MESSAGE.

OK, I missed that.


> Why would sending the server key in WELCOME help? The client already
> needs that to send a valid HELLO.

That's an oddity of CurveCP.  I don't see any reason for the HELLO to
encrypt zero padding (perhaps its some anti-DoS measure?).

It would seem fine to return the server's long-term key in the
WELCOME, and would have various benefits:
 - client can detect key changes and notify the user or go query the
directory again
 - cients can use "Trust-on-First-Use" auth methods
 - the handshake could later be extended to return certificates in the
server response


>> 4) While the modifications to the CurveCP key agreement seem to fix
>> the known security problems, the key agreement still seems a bit
>> complicated, and I'm not aware of any security proofs for it.
>
> Sure. Sticking close to CurveCP means that as more people use that,
> and critique it, we benefit.

Maybe, but I don't know how much other use it's getting, I'm expecting
something like QUIC to draw more attention.


> If you have alternative security mechanisms to propose, that's
> excellent. You may want to read http://hintjens.com/blog:45.
>
> Concretely, for a new security mechanism for ZeroMQ, we need to:
>
> * write an RFC (use http://rfc.zeromq.org/spec:24 as a basis, perhaps)
> * write a reference codec
> * write a mechanism in libzmq.
> * build the API for clients and servers to use that.

I'm probably not going to do all that, as I have other projects :-).

But I'd be happy to provide advice / review.


Trevor


[1] http://curvecp.org/availability.html