Re: [babel] Secdir last call review of draft-ietf-babel-information-model-11

Juliusz Chroboczek <> Mon, 26 October 2020 15:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83B4C3A0C70; Mon, 26 Oct 2020 08:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LjNIhgl_Zp6b; Mon, 26 Oct 2020 08:46:49 -0700 (PDT)
Received: from ( [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0CCB3A0D90; Mon, 26 Oct 2020 08:46:32 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id 09QFkSAf022467; Mon, 26 Oct 2020 16:46:28 +0100
Received: from (localhost []) by (Postfix) with ESMTP id D716010B82D; Mon, 26 Oct 2020 16:46:28 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id dnfT-Q_CSl3X; Mon, 26 Oct 2020 16:46:22 +0100 (CET)
Received: from (unknown []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id 3E7DF10B82A; Mon, 26 Oct 2020 16:46:18 +0100 (CET)
Date: Mon, 26 Oct 2020 16:46:18 +0100
Message-ID: <>
From: Juliusz Chroboczek <>
To: Valery Smyslov <>
In-Reply-To: <>
References: <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 ( []); Mon, 26 Oct 2020 16:46:29 +0100 (CET)
X-Miltered: at korolev with ID 5F96EF54.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5F96EF54.002 from<>
X-j-chkmail-Score: MSGID : 5F96EF54.002 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [babel] Secdir last call review of draft-ietf-babel-information-model-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Oct 2020 15:46:51 -0000

>    babel-mac-algorithms:  List of supported MAC computation algorithms.
>       Possible values include "HMAC-SHA256", "BLAKE2s".

> BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the desired
> size of the MAC is a parameter for it. Where the size of MAC is specified? For
> HMAC with SHA256 I can at least imagine that full 256 bits output is used as a
> MAC...

Right.  The intent is that Blake2s is used with 32-octet keys and 16-octet
hashes (collision-resistance is not a concern for Babel-MAC while
dictionary attacks are).  Barbara, I think that you should explicitly
state that Blake2s implies 128-bit hashes.  (You may also consider
renaming BLAKE2s to BLAKE2s-128.)

>    babel-mac-key-value:

> I wonder of the rationale for imposing the above restrictions on HMAC key
> length. HMAC can use keys of any length, but if the key is greater than block
> size of underlying hash function, then it's first hashed (small performance
> penalty). So I imagine that the rationale is to avoid this penalty.

This was discussed at length on the mailing list.  It's not about
performance, it's about making it more difficult to use an unsafe
procedure for generating keys.

Since Babel-MAC is vulnerable to dictionary attacks, the key must either
be drawn randomly or generated using a procedure that is hardened against
such attacks (scrypt, etc.).  Applying the procedure described in RFC 2104
to a user-provided passphrase is not safe, and therefore we try to make it
difficult for a naive user to do so.

I am opposed to putting the RFC 2104 hashing procedure in the information
model.  Doing so would be a disservice to our users.

>    Short (and zero-length) keys and keys that make use of only
>    alphanumeric characters are highly susceptible to brute force
>    attacks.

> Formally, brute force attack with zero-length keys is not defined, since there
> is no key to find and all is in clear.

The key length is not carried in the clear by the protocol.  Guessing the
key length requires a brute-force attack, even when it is zero.

> 1. The document contains an entry in the Informational model defining which
> hash functions can be used with HMAC authentication. However, there is no
> corresponding entry of which ciphersuites can be used with DTLS. Is it up to
> DTLS library to select ciphersuites?

Yes.  Babel-DTLS is intended to inherit the security properties of the
system's DTLS library.  If the DTLS library is unsafe, then Babel-DTLS
must not be used until the library is fixed.

-- Juliusz