Re: [babel] Some open HMAC issues

[David Schinazi <[e-mail]>]

> On Jul 2, 2018, at 16:50, Juliusz Chroboczek <[e-mail]> wrote:
> 
>>> But why is it needed? It's just one more thing to configure, which makes
>>> configuration more verbose and prone to errors...
> 
>> Without a KeyID, the receiving complexity is proportional to the number of
>> configured keys. That means that nodes configured with n keys not
>> only spend O(n) times more CPU per received packet,
> 
> Where n is just the number of keys configured, and not something an
> attacker can control (see Sections 1.1 and 4.3 of draft-do-babel-hmac).
> In practice, I expect n to be usually just 1, and at most 2 during key
> rotation.

In homenet there was discussion of pairwise symmetric keys
distributed via HNCP. So n could be quadratic in the number of routers.

> Without an explicit KeyID, the set of keys is just a set -- it can be
> implemented for example as a directory of keys, where adding a new key is
> just an scp to the directory, or it can be implemented as a set of TLVs
> flooded by HNCP, where adding a key consists in flooding a new TLV.

If you have a TLV you use to deploy the key, you can deploy the KeyID as
the first two bytes of that TLV. That way both the KeyID and key are flooded
together.

> If you have an explicit KeyID, then you need to make sure that the KeyID
> is consistent among all of the routers in a given security domain.  You
> can no longer just scp the key,

KeyID does not prevent scp, just put the keyID in the name:
scp my_new_secret.key babel-router42.local:/etc/babeld/keys/foo-12345.key

> you need to pick a KeyID that is currently
> unused.  If you're using an automated distribution protocol, then the
> protocol must be able to choose a KeyID that is currently unused not only
> by nodes that participate in said protocol, but also by nodes that don't.

I don't see why. Having a KeyID conflict just means you'll try both keys.

> Worse is better, David.  It is better to have a protocol that has a slight
> inefficiency but is easy to deploy and to manage, than a protocol that is
> slightly more efficient but that nobody will want to deploy because of the
> very significant complications due to the KeyID.

I'm less worried about efficiency and more about robustness to DoS.

An implementation is free to always send KeyID as 42 and silently drop
any HMAC TLV KeyID that isn't 42 if it can't handle the complexity.

In general I agree with your position that adding unnecessary
complexity is bad. But here I'm not sure I agree with how much complexity
this actually represents.

David