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

Dave Taht <dave@taht.net> Wed, 28 November 2018 03:30 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 5E49B130EDF for <babel@ietfa.amsl.com>; Tue, 27 Nov 2018 19:30:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Iv6xTdfJxMsH for <babel@ietfa.amsl.com>; Tue, 27 Nov 2018 19:30:04 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FEE130EDA for <babel@ietf.org>; Tue, 27 Nov 2018 19:30:04 -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 D4E1121455; Wed, 28 Nov 2018 03:30:00 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Toke Høiland-Jørgensen <toke@toke.dk>, 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>
Date: Tue, 27 Nov 2018 19:29:49 -0800
In-Reply-To: <CAPDSy+5QDu_kW-f=JWO1cPJJnDwDNpVwxwVC9SxfcE5+EOMpRg@mail.gmail.com> (David Schinazi's message of "Tue, 27 Nov 2018 13:42:54 -0800")
Message-ID: <87d0qp3mmq.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/GRu6ttq5-DyOyZ1R0pKr3hx10Ts>
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 03:30:06 -0000

David Schinazi <dschinazi.ietf@gmail.com> writes:

> I feel strongly against making anything but SHA-256 mandatory to
> implement. It will delay publication and not improve the
> interoperability story. That said, I agree that the Blake2 family is a
> good fit here so it would be nice to have bird and babeld support them
> - but they do not need to be in the spec.

Are we weeks, months, or years away from publication? Do we have
time to, like, actually code up, and test interoperability, performance,
and methods, before prague?

>
> David
>
> On Mon, Nov 26, 2018 at 12:59 PM Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
>
>     "STARK, BARBARA H" <bs7652@att.com> writes:
>     
>     > FYI. IETF policies re "downrefs" in standards track RFCs is
>     described in
>     > https://tools.ietf.org/html/rfc3967 (and updated by
>     https://tools.ietf.org/html/rfc8067).
>     > In short, it's not prohibited, but careful review is required. 
>     > Note RFC3967 Section 2 first bullet
>     >
>     > There are a number of circumstances in which an IETF document
>     may
>     > need to make a normative reference to a document at a lower
>     maturity
>     > level, but such a reference conflicts with Section 4.2.4 of
>     > [RFC2026]. For example:
>     >
>     > o A standards track document may need to refer to a protocol or
>     > algorithm developed by an external body but modified, adapted,
>     or
>     > profiled by an IETF informational RFC, for example, MD5
>     [RFC1321]
>     > and HMAC [RFC2104]. Note that this does not override the IETF's
>     > duty to see that the specification is indeed sufficiently clear
>     to
>     > enable creation of interoperable implementations.
>     
>     Ah, so HMAC itself is already an informational RFC? Great, let's
>     do
>     blake2, then! :D
>     
>     -Toke
>     
>     _______________________________________________
>     Babel-users mailing list
>     Babel-users@alioth-lists.debian.net
>     https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
>    
>
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users