Re: [babel] Minor clarification to HMAC

In terms of security properties, notably resource exhaustion/contention, I am bit leery of creating entry before validity of remote party is actually verified (= challenge response received). I prefer the old text. I am not quite sure why the second 'may need to be created' is there..

I guess naive implementation would just remember specific nonces it has sent/freceived, but for new peers you can also just use e.g. nonce that contains timestamp (+ peer address (+- something))[1], which allows challenge sender to remain stateless until challenge responder proves they have the key.

So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)

Cheers,

-Markus

[1] extra stuff is mostly for replay protection purposes, but I am not sure if it is a threat or not in this case. I have just cycled 140km, sue me.

> On 28.06.2019, at 16.21, Juliusz Chroboczek <jch@irif.fr> wrote:
> 
> Dear all,
> 
> Sawssen and Étienne (in copy of this mail) are currently working on
> cleaning up and completing the reference implementation of draft-...-hmac.
> We have just realised that the draft is not quite clear on two points.
> 
> The draft says that a neighbour entry MUST NOT be created before HMAC is
> verified (Section 4.3 first bullet).
> 
> It later says that a neighbour entry "might need to be created" when
> a challenge is sent, and "may need to be created" when a challenge is
> received.  However, it does not say whether it is legal to create an entry
> earlier.
> 
> I would therefore like to kindly request the permission of the group and
> the chairs to add the following between the first and second bullet points
> of Section 4.3:
> 
>  * A neighbour entry for the sender of the packet MAY be created at this
>    stage.  (Alternatively, an implementation MAY delay the creation of
>    a neighbour entry until a challenge request or reply is received.)
> 
> This clarification does not invalidate any implementations, it just makes
> the intent of the draft authors more explicit.
> 
> -- Juliusz
> 
> 
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
> 