Re: [babel] WG adoption call for draft-do-babel-hmac (7/19 - 8/6)

[Juliusz Chroboczek <[e-mail]>]

>> That said, this design leads to N times more efficient CPU DOS
>> (non-accelerated SHA256 on slow CPU times MTU worth of HMACs = quite
>> a lot of computation on low-end devices). Then again, I am not sure it
>> really matters (and implementation can constrain that as they want to
>> anyway).

> Not even that actually, as long as you keep reasonably low number of
> keys on a device (ideally only one);

Exactly.  Section 1.1 says

    The protocol is inapplicable in situations where [...] large numbers
    of trusted keys are provisioned on a single link at the same time.

and Section 4.3 says

    The HMAC of the packet MUST NOT be computed for each HMAC TLV
    contained in the packet, but only once for each configured key.

I'll see if it can be made clearer.

That being said -- Denis Ovsienko and David Schinazi have suggested that
the HMAC should be associated with a key-id, a small integer that allows
matching provisioned keys with in-packet keys.  I'm not a big fan, but I'm
willing to add it to the document if people feel strongly about it.

-- Juliusz