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

[Donald Eastlake <[e-mail]>]

Hi Antonin and Juliusz,

I'll just reply where I think I can add to Juliusz responses.

On Wed, Aug 26, 2020 at 6:26 AM Juliusz Chroboczek <[e-mail]> wrote:
>
> Dear Antonin,
>
> ...
>
> > 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.

I am opposed to the blanket requirement suggested by Antonin as follows:

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

Some MAC algorithms may produce very long MACs whose non-truncated use
would squeeze out too much useful data. This is a factor in the engineering
tradeoff that is being ignored in this suggested change. Truncated MACs are
quite common in IETF protocols, although there is usually a floor size
below which you are not permitted to go. And there are even arguments that
a modest amount of truncation can strengthen a MAC. (Also, from a different
point of view, the proposed requirement is trivially evaded because you
could just define a new MAC algorithm with the truncation or other
condensation of the MAC value from another MAC algorithm and say that this
new MAC algorithm is what you are using.)

> > 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 succeeded.  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 think adding this "SHOULD" would be too much of a change. In principle it
doesn't require my permission, it requires Martin Vigoureux's permission
since the draft is out of the WG and in the IESG.

Since it doesn't affect correct operation, I would suggest just creating a
draft-ietf-babel-hmacbis-00 draft and putting it in that. There seems to be
enough WG interest in this that I don't see any need for a formal WG
adoption call.

6. Timers

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

I don't see any problem with typo fixes and clarifications so the changes
in point 6 seem fine to me.

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

I think the changes in Section 7 would be OK also.

9. Relations with the Information Model

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

Prior to writing this message, I reviewed the entire Babel hmac draft and
noticed the following: In Section 4.1, the empty box in the IPv4
psuedo-header diagram bothers me. I think it should say the following in
that box:

Dest address (cont.)


for destination address continued.

But I'm not sure it is worth fixing these editorial things right now. When
the draft is actually processed by the RFC Editor, all the authors will get
a message including what editorial problems or ambiguities the RFC Editor
thinks they have found along with a request to review the entire draft. At
that point any editorial things can be cleared up.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [e-mail]

> -- Juliusz