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

[Markus Stenberg <[e-mail]>]

> On 29 Jul 2018, at 13.40, Juliusz Chroboczek <[e-mail]> wrote:
>>> 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.

I think I prefer the current scheme - the most common case should be exactly 1 key anyway, and corner case ‘few’ keys (either during key roll-over, or at some trust domain cross-over point).

-Markus