Re: [babel] Some open HMAC issues

[Juliusz Chroboczek <[e-mail]>]

>> 2. Having nonces of arbitrary size implies dynamic allocation.  At any
>> rate, you need dynamic allocation for nonces, since they're
>> short-lived and per-neighbour.

> Not necessarily. When receiving a challenge request, you can just do
> memcpy(outgoing_packet_buffer, incoming_packet_buffer, nonce->size). And
> for the nonces you send yourself you know in advance what size they are
> going to be, so you can just put a static buffer of that size in 'struct
> neighbour'.

Right on both counts.  My bad.

>> 3. You do want to allow tiny indices (unless we adopt Markus' proposal),
>> since some implementations will want to save bytes on the wire by
>> using a real-time clock.

> Sure, that's fine. Should 0-size be allowed, or should we require at
> least one byte?

Allow it.  The property that's required is that a node never reuses the
same index with the same key -- one possible implementation strategy would
be to perform key rotation whenever state has been lost, in which case
0-size indices would be fine.

>> I haven't made an opinion yet on whether we want a limit to the size of
>> indices.

> Well, I think we should. My implementation will currently discard any PC
> TLVs with an index longer than 10 bytes :)

Hmm.

I mean, hmm.

>>> Or maybe just forgo the complexity entirely and make the index a
>>> fixed size; you just know that someone is going to pick a way too
>>> small value and make themselves susceptible to replay attacks at some
>>> point...
>> 
>> Disagreed.

> Right, fair enough. As long as the danger of replay attacks is spelled
> out clearly in the draft I guess we can trust implementors to not do
> something stupid...

More implementation guidance is needed in the draft, granted.

-- Juliusz