Re: [babel] [Babel-users] rather than ripemd160...

Dave Taht <dave@taht.net> Thu, 29 November 2018 06:12 UTC

Return-Path: <dave@taht.net>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1899012F1AC for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 22:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVNiMzDQlS-n for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 22:12:49 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16399130DC1 for <babel@ietf.org>; Wed, 28 Nov 2018 22:12:49 -0800 (PST)
Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 72E4221B39; Thu, 29 Nov 2018 06:12:45 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Toke Høiland-Jørgensen <toke@toke.dk>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, babel-users@lists.alioth.debian.org, Barbara Stark <bs7652@att.com>, babel@ietf.org
References: <CAA93jw5fHRm21yEJsabiiOF1ZP7Zh3M_gEgRo0imBOpRGhf0qA@mail.gmail.com> <87in0koun6.wl-jch@irif.fr> <87in0kx98o.fsf@toke.dk> <CAA93jw5gaYgyUX-ABX156_TnFX25Sy5SLyuRgd28fMLfRW4UHA@mail.gmail.com> <871s78x7z0.fsf@toke.dk> <2D09D61DDFA73D4C884805CC7865E6114DF44154@GAALPA1MSGUSRBF.ITServices.sbc.com> <87pnurwo5e.fsf@toke.dk> <CAPDSy+5QDu_kW-f=JWO1cPJJnDwDNpVwxwVC9SxfcE5+EOMpRg@mail.gmail.com> <87o9a9v3c6.fsf@toke.dk> <CAPDSy+6M9+-cVXwzv1NZ0ju7DSO5h15hE9W1+XFpabNoh-V=0Q@mail.gmail.com> <87wooxt0s4.fsf@toke.dk>
Date: Wed, 28 Nov 2018 22:12:33 -0800
In-Reply-To: <87wooxt0s4.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Wed, 28 Nov 2018 21:17:15 +0100")
Message-ID: <87y39cxvhq.fsf@taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/tMDNQJHgOAhllGV7wF5B7O99EbM>
Subject: Re: [babel] [Babel-users] rather than ripemd160...
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2018 06:12:51 -0000

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> David Schinazi <dschinazi.ietf@gmail.com> writes:
>
>>>
>>>
>>> Why not? If it's not MTI you risk the case where you get to pick between
>>> "good performance on weak devices" and "interoperability with RFC-only
>>> implementations".
>>>
>>
>> Where are these "RFC-only implementations" of Babel?
>
> Anyone who does a from-scratch implementation from the RFC, without
> being part of the working group process, or looking at the existing
> implementations.
>
>> Remember the IETF does not have a protocol police, MTI is purely
>> guidance. Implementors build what they (or their customers) need for
>> their use-case. Implementors will add Blake if they need it, not based
>> on whether it's MTI or not.

It is generally my experience that anything that's a MAY or
SHOULD... doesn't get implemented.

RIPEMD is an artifact of the original hmac RFC.

>
> If it's MTI, they can't claim compliance with the RFC until it's in
> there. So the "we need this box checked" type of product development
> will benefit from this; and while sure, theoretically MTI is a hint,
> it's a pretty strong one...
>
>> Lastly, remember that this is a security solution, so you do NOT want
>> to interoperate with a future theoretical implementation, because that
>> will not have the keys. Adding any new node in the network will
>> require a provisioning step, and that step ensures the new node
>> supports the required features.

Upgrading any old node to an alternate algorithm is considerably
more difficult. 2 HMAC algorithms with a different design history is
comforting.


>
> You can usually control the config, but not necessarily the features
> implemented by the device...
>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users