On Wed, Sep 25, 2013 at 1:08 AM, Pieter Hintjens <[email protected]> wrote: > On Wed, Sep 25, 2013 at 1:04 AM, Trevor Perrin <[email protected]> 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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
