Re: [babel] Babel-MAC: key size and digest size

[Antonin Décimo <[e-mail]>]

Hello again,

I'm keeping in mind that (§7):
> Every implementation MUST implement HMAC-SHA256 as defined in
> [RFC6234] and Section 2 of [RFC2104] , SHOULD implement keyed
> BLAKE2s [RFC7693] , and MAY implement other MAC algorithms.


1. Key length

This is the change I'm proposing in §7:

 Keys must be chosen in a manner that makes them difficult to guess.
-Ideally, they should have a length of 32 octets (both for HMAC-SHA256
-and Blake2s), and be chosen randomly.
+Ideally, they should be chosen randomly, and have the maximum key
+length supported by the MAC algorithm (32 octets for keyed BLAKE2S)
+or no less than the block size of the MAC algorithm (64 octets for
+HMAC-SHA256).


2. Digest length

After a bit of sleep, I realised that 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.

> Then, for each key configured on the receiving interface, the
> receiver computes the MAC of the packet. It then compares every
> generated MAC against every MAC included in the packet;

Still, it was an error I was almost going to make. I propose the
following change to ensure that we're always using the maximum digest
length of the MAC algorithm.

This is the change I'm proposing in §4.1:

 implementation MUST implement HMAC-SHA256 as defined in
 <xref target="RFC6234"/> and Section 2 of <xref target="RFC2104"/>,
 SHOULD implement keyed BLAKE2s <xref target="RFC7693"/>, and MAY implement
 other MAC algorithms.
+The length of the MAC MUST be the maximum MAC length computable by
+the MAC algorithm (32 octets for both HMAC-SHA256 and keyed
+BLAKE2S).


3. Lazy computation

With the idea that computing a MAC is more costly than comparing MACs,
and that there's a very limited amount of MACs to check, I propose we
lazily compute MACs. Instead of computing the MAC for every key on
packet reception, we compute the MAC with the first key, then check it
against the MACs carried by the packet. If there's a match, the packet
is immediately accepted. If there's no match, we the proceed to the
next key until all keys are exhausted, and the packet is rejected.

This is the change I'm proposing in §4.3:

-Then, for each key configured on the receiving interface, the
-receiver computes the MAC of the packet.  It then compares every
-generated MAC against every MAC included in the packet; if there is
-at least one match, the packet passes the MAC test; if there is none,
-the packet MUST be silently dropped and processing stops at this
-point.
+Then, for each key configured on the receiving interface, the
+receiver computes the MAC of the packet and compares it against every
+MAC included in the packet; if there is at least one match, the
+packet passes the MAC test; if there is none, the receiver proceeds
+with the next key.  If none of the MAC matched, the packet MUST be
+silently dropped and processing stops at this point.


Cheers!

-- Antonin