IETF Logo Mail Archive

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

Toke Høiland-Jørgensen <toke@toke.dk> Wed, 28 November 2018 20:17 UTC

Return-Path: <toke@toke.dk>
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 412A5130FB5 for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 12:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
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 Q0u-GwvVya5S for <babel@ietfa.amsl.com>; Wed, 28 Nov 2018 12:17:21 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785DF127B92 for <babel@ietf.org>; Wed, 28 Nov 2018 12:17:21 -0800 (PST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1543436235; bh=etUs+A5e3dERqCyP62l5w4jJ74IYrx4/XUi2gyQd75k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=uTv6nYP3PKxXghVOqFdXpk1n1uWxJ+XqX/tmhm6DwNXTaO3cwp87xGjeGoT+i9J5j 8TGK+B4o0CetfH6755iAnRHmT3Mc16Jsz4u/83RJrvprJ9Lhe7loIpDoUooGZFgEZf 083vig1qOb7dbXmAEUNXK6cXLLN28HMWV5E19uMDNf45OVXYF56Dz5FNsBHF7Ql8L5 QbPvDVwYGx56oE5vQj8OdodRs/8h7QHhiyIo/OvI5wRivWJebv8vVbZlbOq50oRAIC Z5gf/T8WALV5cyNSjBEiE0KMieq5Q3ajZvNNygf/mQ7VDpWPWT0q/1f+EcmBevW3D7 pQaALDEjMZJ/Q==
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Barbara Stark <bs7652@att.com>, Dave Taht <dave.taht@gmail.com>, babel-users@lists.alioth.debian.org, babel@ietf.org
In-Reply-To: <CAPDSy+6M9+-cVXwzv1NZ0ju7DSO5h15hE9W1+XFpabNoh-V=0Q@mail.gmail.com>
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>
Date: Wed, 28 Nov 2018 21:17:15 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87wooxt0s4.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/ZZKS0c93nEv1D3Q6jHLLes4skY8>
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: Wed, 28 Nov 2018 20:17:23 -0000

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.

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.

You can usually control the config, but not necessarily the features
implemented by the device...

-Toke

v2.23.0 | Report a Bug | By Email