[zeromq-dev] CurveZMQ comments

Wed Sep 25 22:18:22 CEST 2013

Trevor,

Thanks for the review, it's helpful. I'm sure you're right that the
CurveZMQ handshake can be simplified. This would be a fine goal.

If you do want to propose a simpler protocol, you do at least need to
document it, and provide a proof of concept in code. Others can take
it from there, if they think it's valuable enough.

-Pieter

On Wed, Sep 25, 2013 at 10:03 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev