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

Hi Antonin,

Thanks for your comments. They look plausible to me although it is
common to use truncated MACs. However, I'm thinking that at this
stage, it would be best to get draft-ietf-babel-rfc6126bis, and the
draft that are being held up by it through the process, and then start
an update to or a revision of the Babel HMAC draft.

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Sat, Dec 28, 2019 at 1:15 PM Antonin Décimo <antonin.decimo@gmail.com> wrote:
>
> 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
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel