Re: [babel] Babel-MAC: Blake2s is 128-bits by default

I'm sorry I didn't reply earlier on this thread. Even before Juliusz'
email, the consensus seemed odd to me, for the reasons he outlined and I
intended to raise this up. Note that I have not taken part in any
implementation Babel, and I am basing my opinion purely on the facts laid
out in this thread. I think blake2s should use 128-bit signatures.

Gabriel Kerneis

On Mon, Nov 16, 2020 at 5:28 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> H Juliusz,
>
> Speaking as a WG participant, I think your argument make sense and I
> would supporting going in the direction you suggest.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 <(508)%20333-2270> (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
> On Sun, Nov 15, 2020 at 12:55 PM Juliusz Chroboczek <jch@irif.fr> wrote:
> >
> > After reading your replies, and thinking it over carefully, I disagree
> > with the apparent consensus.  I think Blake2s in Babel-MAC should use
> > 128-bit keys, as in the initial implementation.  Please hear me out.
> >
> > Toke and Dave originally suggested adding Blake2s to Babel-HMAC for two
> > reasons:
> >
> >   - it is more computationally lightweight on platforms that don't
> >     implement SHA-256 in hardware;
> >   - it may serve as a fallback if SHA2 is ever broken.
> >
> > While I am still not quite convinced by these arguments, I've agreed to
> > add the SHOULD Blake2s and to implement Blake2s for the following
> reasons:
> >
> >   - it serves as a good example of adding a new algorithm to Babel-MAC;
> >   - with 128-bit signatures, it is useful on low-rate networks, which
> >     Babel is commonly used with.
> >
> > For these reasons, we implemented Blake2s with 128-bit signatures.
> > Unfortunately, some confusion ensued, Toke implemented Blake2s with
> > 256-bit signatures, Antonin changed our implementation to interoperate
> > with Toke's (without discussing the issue with me beforehand), hence the
> > current situation.
> >
> > If Blake2s uses 256-bit signatures, then I see little convincing reason
> to
> > keep it around in addition to SHA-256.  For this reason, I recommend the
> > following course of action:
> >
> >   1. Toke agrees to switch to 128-bit Blake2s signatures;
> >   2. we discard Antonin's branch (which is just a private branch), and do
> >      128-bit Blake2s signatures instead;
> >   3. during AUTH48, I make the clarification that the SHOULD implement
> >      applies to 128-bit signatures.
> >
> > Two more points.  First, under no circumstances will I go against WG
> > consensus on this point -- if the WG strongly believes that the SHOULD
> > applies to 256-bit signatures, I will naturally follow the consensus.
> > Second, Babel-HMAC is an extensible protocol, so even if the RFC ends up
> > recommending n-bit signatures, nothing prevents a given implementation
> > from implementing m-bit signatures in addition to the RFC-recommended
> > n-bit signatures.
> >
> > Sorry again for the confusion.
> >
> > -- Juliusz
> >
> > _______________________________________________
> > babel mailing list
> > babel@ietf.org
> > https://www.ietf.org/mailman/listinfo/babel
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>