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 <[email protected]> wrote: > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
