[Babel-users] A summary of Babel cryptographic extensions
Juliusz Chroboczek
jch at irif.fr
Sat Jul 7 10:55:16 BST 2018
Hi, and sorry for the massive cross-posting. I suggest followups should
go to babel at ietf.
The mails that I'm receiving indicate that we (Babel at 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
More information about the Babel-users
mailing list