Re: [babel] Minor clarification to HMAC

[Juliusz Chroboczek <[e-mail]>]

> 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 initially thought like you, but Sawssen and Étienne convinced me that
creating the entry late does not add any security.

Suppose that the packet passes HMAC.  Then one of the possible cases is
possible:

  - the neighbour entry already exists;
  - the neighbour entry doesn't exist, and we're going to send a challenge.

In the first case, the point is moot.  In the second case, we're going to
create a neighbour entry anyway, so we might as well create it immediately.

(Note that the data structures of the protocol are conceptual, not
prescriptive -- an implementation is allowed e.g. to use an "incomplete
neighbour" data structure that is smaller than a full neighbour structure
for holding uncompleted challenges, as long as the effect is identical to
what is described in the protocol.

> I am not quite sure why the second 'may need to be created' is there..

I was hoping nobody would notice ;-)

For the challenge to be successful, the neighbour entry must exist --
there's no way we could have sent a challenge if no neighbour entry
exists.  (It could be the case of course that the challenge reply is an
attack, and no neighbour entry exists, so the implementation must still
check for the existence of the neighbour entry.)  I didn't want to mention
that right now, in order to limit the amount of confusion.

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

Yes.  The protocol is designed to make it possible to encode a cookie in
the Nonce (that's why Nonces can be as much as 192 octets long).  However,
the draft does not specify how to implement it with cookies, so the point
is somewhat moot.

(Note that even with cookies, you still need to rate-limit challenges.
A global challenge counter should be enough, but I haven't given it any
serious thought.  Which is why I won't attempt to specify the cookie
variant of the protocol in this revision of the protocol.)

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

Please reconsider in light of the above.

-- Juliusz