Re: [babel] Comments on the MAC authentication for Babel draft

[Juliusz Chroboczek <[e-mail]>]

Dear Antonin,

While many of these are good changes, Donald is telling me that at this
stage we're not making any changes that are not actual bug fixes.  (He's
been telling me that for the best part of a year now, sigh.)

Antonin -- what we're dealing with here is a hostile bureaucratic
organisation (similar to our University's administration), so we must
choose our battles.  I don't think any of the battles below are worth
fighting.

> 1. Key length

I disagree.  Using 64 octets for SHA-256 gives no additional security.

  https://crypto.stackexchange.com/questions/34864/key-size-for-hmac-sha256

> 2. Digest length

> Reading the length of the MAC TLV in order to compute a MAC of this
> length is not compliant with the protocol (§4.3) since MACs are
> computed without looking into the packet.

No.  The digest length is part of the algorithm.  The algorithm is carried
out-of-band.

In other words -- when a key is configured in a router, it is configured
together with the associated algorithm.  The algorithm implies a digest
length.  For example, SHA-256 truncated to 128 bits is a different
algorithm than SHA-256 with full digests.

I agree that this could be made clearer, but we're not tweaking this at
this stage.

> 3. Lazy computation

This is already legal — your proposed tweak doesn't violate any of the
MUST in this paragraph.  I agree that your wording is better, but we're
not making this change at this stage.

> 4. Accepting Challenges

> When receiving a challenge reply, a node must check if there was a
> challenge in progress before validating the challenge.

> However the text does not explicitly describe if there are changes
> to be made to the overall state when the challenge succeeds.

Right.  The obvious implementation strategy is to discard the challenge
state after a challenge has succeded.  Not doing that does not cause any
security issues (it's not required by the proof of correctness).

I think we should add « SHOULD discard the state » here, but it requires
Donald's permission.

> I was confused at first between the "challenge expiry timer", the two
> rate limits, and the neighbour state expiry timer. I suggest, for
> consistency, the following changes:

Right.  Unfortunately, we're no longer allowed to improve the wording.

> 5. Replying to challenges

> Section 4.3.1.2. Replying to challenges, the sentence [...] could be moved
> earlier

Right again.  Not worth fighting for, IMHO.

> 7. TLV names shouldn't be pluralised

Same.

> The MAC draft defines (amongst other) three optionaly tunable parameters:
[...]
> Should they be reflected in the models?

No.  The protocol is robust enough that the exact values are irrelevant to
its security.

-- Juliusz