The document discusses secure messaging for internet applications using ZeroMQ. It proposes solutions like CurveZMQ and ZMTP 3.0 that provide encryption, authentication and extensibility at the protocol level. CurveZMQ defines a security handshake inspired by CurveCP that is transport neutral and compatible with SASL. ZMTP 3.0 introduces security mechanisms to ZMQ like CURVE for full encryption and authentication. The author advocates getting involved in the open RFC process to help evolve these standards.

1. CurveZMQ, ZMTP and other
Dubious Characters
Secure Messaging for the Internet
by
Pieter Hintjens, CEO, iMatix
Berlin Buzzwords 2013, 4 June, 2013

2. What's the Problem?
● ZeroMQ (ØMQ) defined a new product
category
● Message queuing & routing stacks
● JeroMQ, NullMQ, Nano, netty-zmtp, ezmtp
● All have the same problem: clear-text
● Not safe to use on public infrastructure

3. What do People Do?
● Many apps just use clear text
● Clearly not acceptable for sensitive data
● Salt Stack has its own security system
● Already cracked (chicken-salt)
● IPython uses SSH + HMAC digests
● Has several plausible vulnerabilities

4. Works in Progress
● TLS encryption above libzmq (Barber)
● TLS transports for libzmq (Young, Naudé)
● DTLS transport for libzmq (Cocagne)
● May deliver, but...
● What about interoperability?

5. The Right Solution
● Security at the protocol level (ZMTP)
● Extensible security (like SASL)
● Several example mechanisms
● Easy to plug new ones into libzmq
● Perhaps exposed as e.g. dtls://

6. What's SASL?
● IETF's solution for extensible security
● We used this when designing AMQP
● Client and server negotiate a "mechanism"
● Mechanism does the actual security
● IETF as usual makes it... complex
● We can do it somewhat simpler

7. The Security Handshake
● Client: HELLO
● Server: WELCOME (mechanism M)
● Client: INITIATE (mechanism M)
● Server: READY
● Client: MESSAGE | Server: MESSAGE

8. What is "Secure" in 2013?
● Data cannot be tapped (encrypted)
● or created fraudulently (authentic)
● or altered
● or replayed
● Keys cannot be stolen

9. Basic State of the Art
● Mechanisms must be open ended
● Allows evolution of security over time
● Processing HELLO command must be cheap
● Prevents denial-of-CPU attacks
● HELLO must be larger than WELCOME
● Prevents amplification attacks
● Send no metadata until INITIATE/READY
● Prevents leak of knowledge about peer

10. Advanced State of the Art
● Perfect forward security
● Data cannot be decrypted even with private keys
● Resists man-in-the-middle manipulation of keys
● Clients cannot be identified
● Client public keys are sent encrypted
● Resists traffic-analysis attacks
● Randomize message sizes & frequencies

11. Meet CurveCP (Bernstein)
● "Usable Security for the Internet"
● From author of NaCl (=> libsodium)
● Encryption and authentication over UDP
● Also does recovery from packet loss
● Also does a bunch of other stuff
● http://curvecp.org

12. Some CurveCP Internals
● Elliptic curve encryption, very fast
● Creates short-term keys for each connection
● Unique nonces for each command
● Achieves "advanced state of the art"
● Except defeating traffic analysis
● Which we can add ourselves

13. Why NaCl is Wonderful
● Perfectly simple API
● Fast and robust
● Preselected key sizes & algorithms
● Packaged as libsodium
● Easy to install, learn, and use

14. Why CurveCP won't happen
● Tries to do too much, too soon
● The software is complex to use
● Does not "play nice" with existing standards
● Utterly incompatible with SASL, TCP
● Remixed into more plausible MinimalT

15. Apart from that, Very Nice!
● I took CurveCP's security handshake
● Simplified it and cleaned it up
● Made it transport neutral
● Wrote down as a single protocol document
● http://rfc.zeromq.org/spec:26/CURVEZMQ

16. Meet CurveZMQ
● An Abstract Security Mechanism
● Specified as a client-server protocol
● Any transport (even avian carrier)
● TCP if we build this into ZMTP
● Or ZeroMQ tcp://, at application level
● http://curvezmq.org

17. Meet ZMTP
● The ZeroMQ Message Transport Protocol
● Wire protocol for ZeroMQ over TCP
● Fifth RFC now in drafting stage
● In ZeroMQ, JeroMQ, NetMQ, netty-zmtp, ...
● Version 3.0 is quite a big deal
● http://rfc.zeromq.org/spec:23/ZMTP

18. What's New in ZMTP 3.0?
● Extensible security mechanisms
● Extensible connection metadata
● Endpoint resources (for port sharing)
● Better backwards version detection
● Explicit socket type semantics

19. ZMTP's security mechanisms
● NULL is just that, empty
● PLAIN does clear-text authentication
● Test clients vs. production systems
● CURVE does CurveZMQ security
● Fully encrypted and authenticated
● <Insert your own here>

20. libzmq already runs ZMTP 3.0
● Git master does NULL and PLAIN
● Full backwards compatibility
● Supports extensible mechanisms
● We're now working on CURVE
● Next: DTLS, ...?

21. Meet ZAP
● The ZeroMQ Authentication Protocol
● Extensible authentication services
● Using ZeroMQ request-reply protocol
● PAM, LDAP, Kerberos, passwd, etc.
● libzmq implements ZAP 1.0
● http://rfc.zeromq.org/spec:27/ZAP

22. Get involved
● Read the RFCs on http://rfc.zeromq.org
● Come to Brussels on 21 & 22 June 2013
● For ZeroMQ Developers' Meetup
● http://zero.mq/bxl
● Talk to us on the zeromq-dev list

23. Who are we?
● ZeroMQ community including iMatix
● iMatix makes messaging products
● Distributed systems since 1991
● Original designers of AMQP (2004-07)
● Backers of ZeroMQ community (2007-)
● Authors of most ZeroMQ RFCs

24. Thanks!
● Buy the O'Reilly ZeroMQ book
● Email me: ph@imatix.com
● Twitter: @hintjens
● Blog: hintjens.com