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

[Markus Stenberg <[e-mail]>]

On 29 Jul 2018, at 1.53, Juliusz Chroboczek <[e-mail]> wrote:
>   Whenever B resets its PC, or whenever B doesn't know whether
>>   its PC has been reset, it picks an index that it has never used
>>   before (either by drawing it randomly or by using a reliable hardware
>>   clock) and starts sending PCs with that index.
> 
>> I think there are 3 potential sources for index:
> 
>> - nvram/flash (truly unique, frequently but not always available)
>> - magic timestamp (e.g. GPS, magical secure NTP might give us ~unique timestamp, or RTC that never goes backward for this purpose.. but typical routers do not have strictly monotonic hardware clocks the text notes)
>> - something pseudorandom that has sufficiently low collision likelihood given the number of bits of index
> 
>> so I think the text (and some of the following) is slightly
>> optimistic. I would probably just settle for a sufficiently low
>> collision chance.
> So I just need to add "likely", as in "likely not used before"?  Or are
> you suggesting something more?

Nah, just wording changes here and there (there are few places that assume the options 1/2 which are not realistic always).

>> Also, I would like to have byte(/few bits) somewhere indicating the
>> algorithm used for HMAC. Maybe I’m just tired and can’t see one that is
>> already there.
> 
> There's none.  The procedure is:
> 
>  - receiver computes HMAC for each algo/key pair it has been provisioned with;
>  - it does a bytewise comparison of the result of each key computation
>    with each HMAC computed in the packet.
> 
> So the receiver doesn't need to know the algorithm used by the sender --
> it only needs to know which algorithm is associated to each of the keys it
> has been provisioned with.
> 
> Am I missing something?  What purpose would adding info about the
> algorithm to the on-the-wire HMAC serve?

Ah, nevermind, I was still in the mindset with the key id actually on the wire (that’s what I get for rereading drafts at night). Without it, as I reread section 4.3, algorithm does not have to be either. So it is fine as it stands.

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).

Cheers,

-Markus