IETF Logo Mail Archive

Re: [babel] Some open HMAC issues

Toke Høiland-Jørgensen <toke@toke.dk> Mon, 02 July 2018 17:19 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 386A1130F39 for <babel@ietfa.amsl.com>; Mon, 2 Jul 2018 10:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 Af5EHD_swOtb for <babel@ietfa.amsl.com>; Mon, 2 Jul 2018 10:19:12 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA741311F5 for <babel@ietf.org>; Mon, 2 Jul 2018 10:19:12 -0700 (PDT)
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=1530551950; bh=YjLCSpzGKhFPJYKKWdkJQpXOhLSrQ68P4BVcNsq091A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NI4K0iHIcNVRVijMuMLU0GSbIIBwJeNWEf91/O+ZIbafnj9ueNMnFFhSkL0khUnUA cU1qZ+7aVPWuw60A0lkUue5HVe7b/JRXfYkVpPCT/q/UirhhOL/ENI/3xuqkYnMc6l KA6Pi+0Am2E7mHDjjHoWpHFq5l7rT5ClA08ShhMFWZnQ7gOIQWK2eIbomQlH55BdU6 w8RMfd72NcPl8vkfrN9Svuj5zzpDUpaWFkWjlCT2LNrJJBlsKCiaVXZJk7ZvNW5XYA GC4RYS4nxey1NDg6kkTOULu8VaTk+wJsty3oi+lULH/OpM7Zkx1K1prTYuXQSScUUa 3s8jceMzGHhnQ==
To: David Schinazi <dschinazi@apple.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, Weronika Kołodziejak <weronika.kolodziejak@gmail.com>, Clara Dô <clarado_perso@yahoo.fr>, babel@ietf.org
In-Reply-To: <375EE128-E5F3-487C-9A9E-89A8C976489F@apple.com>
References: <87sh545st3.wl-jch@irif.fr> <411E2C9F-A910-4899-8DD7-92C0C85EBC54@apple.com> <87sh523xy8.wl-jch@irif.fr> <7E5E0D4C-0049-47D1-ACFA-31EA0F843237@apple.com> <87d0w5ingo.fsf@toke.dk> <375EE128-E5F3-487C-9A9E-89A8C976489F@apple.com>
Date: Mon, 02 Jul 2018 19:19:21 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87a7r9imhy.fsf@toke.dk>
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/bVBAeSEkfwf8pc73jl5AdDCcJW8>
Subject: Re: [babel] Some open HMAC issues
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 17:19:26 -0000

David Schinazi <dschinazi@apple.com> writes:

>> On Jul 2, 2018, at 09:58, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 
>> But why is it needed? It's just one more thing to configure, which makes
>> configuration more verbose and prone to errors...
>
> Without a KeyID, the receiving complexity is proportional to the number of
> configured keys. That means that nodes configured with n keys not
> only spend O(n) times more CPU per received packet, they are also n times
> more vulnerable to DoS attacks. This becomes a tradeoff between
> - better performance, slightly better security
> OR
> - slightly easier configuration, two bytes saved on the wire
>
> I'm not advocating that this is absolutely necessary, but I'd like to
> discuss the pros and cons in case people think of other ways this
> is better or worse.

Hmm, I'm not sure that I am convinced that it is worth the tradeoff to
add the key ID. But assuming it is: Is there any reason why this ID
needs to be user configured? We could just define it as a 16-bit
truncated hash of the key itself, or something like that?

-Toke

v2.23.0 | Report a Bug | By Email