[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