Hi, and sorry for the massive cross-posting. I suggest followups should go to babel@ietf.
The mails that I'm receiving indicate that we (Babel@IETF) have confused some people with our crypto plans. Thanks to all for your questions, and let me please try to clarify things publicly. Considering security, I am concerned by the tension between simple, auditable protocols and excessive complexity due to additional features. Of course, we could just design a simple protocol and say that extra features are out of scope, but many of the feature requests are actually legitimate (confidentiality, asymmetric keying, pairwise keying, ASN.1, etc..). So we're currently pushing for having two protocols for Babel: - HMAC for Babel [1,2,3], which is simple, understandable, implementable, and has almost no dependencies, but requires minimal changes to Babel, but has minimal features (static symmetric keying only, no pairwise keying); - Babel over DTLS [4], which pushes the crypto down to DTLS, and therefore has all the creepy features of your DTLS implementation -- at the cost of depending on a DTLS library, which some feel is overkill. [1] https://tools.ietf.org/html/rfc7298 [2] https://tools.ietf.org/html/draft-ovsienko-babel-rfc7298bis [3] https://tools.ietf.org/html/draft-do-babel-hmac [4] https://tools.ietf.org/html/draft-decimo-babel-dtls (References draft-ovsienko and draft-do are two competing protocols, both based on RFC 7298; I'm supporting draft-do or something based on it.) Both protocols have implementations [5,6], and independent reimplementations are in progress or at least being considered. Details are likely to change, but the implementations are mature enough for experimentation. [5] https://github.com/MisterDA/babeld branch unicast-dtls [6] https://github.com/wkolod/babeld branch hmac-challenge What I'd like to see eventually is: - both protocols published as RFCs; - one of the protocols being the recommended protocol (I'm kibbitzing for HMAC); - all publicly available implementations of Babel supporting the recommended protocol, at least as a compile-time option. Concerning Homenet -- Homenet will need at some point to decide what HNCP security looks like, and decide how it interacts with Babel security. My personal opinion at this early stage is that HNCP should perform key negociation and distribute symmetric keys to Babel-HMAC, but I know that at least one prominent visionary in the Homenet community feels rather strongly about asymmetric or pairwise keying. Given that HMAC security is probably going to depend on DTLS anyhow, it's not unreasonable to require Babel-DTLS in Homenet. We'll try to arrange for presentations on the subject at IETF Montréal, but all the parties involved are rather busy, so it's not a given. I hope this clarifies things, -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet