Re: [babel] WG Last Call on draft-ietf-babel-hmac

Juliusz Chroboczek <> Sun, 23 December 2018 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 890521277CC; Sun, 23 Dec 2018 12:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S60n0cCQXVBt; Sun, 23 Dec 2018 12:14:35 -0800 (PST)
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 A63BF1277BB; Sun, 23 Dec 2018 12:14:34 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4/relay1/82085) with ESMTP id wBNKEP1U017360; Sun, 23 Dec 2018 21:14:25 +0100
Received: from (localhost []) by (Postfix) with ESMTP id 1F81293B8A; Sun, 23 Dec 2018 21:14:32 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10023) with ESMTP id oAUMwx7s7O_e; Sun, 23 Dec 2018 21:14:29 +0100 (CET)
Received: from ( []) (Authenticated sender: jch) by (Postfix) with ESMTPSA id 3627693B88; Sun, 23 Dec 2018 21:14:28 +0100 (CET)
Date: Sun, 23 Dec 2018 21:14:26 +0100
Message-ID: <>
From: Juliusz Chroboczek <>
To: Dave Taht <>
Cc: Donald Eastlake <>,, Babel at IETF <>
In-Reply-To: <>
References: <> <>
User-Agent: Wanderlust/2.15.9
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 ( []); Sun, 23 Dec 2018 21:14:26 +0100 (CET)
X-Miltered: at korolev with ID 5C1FECA1.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5C1FECA1.001 from<>
X-j-chkmail-Score: MSGID : 5C1FECA1.001 on : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <>
Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac
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: Sun, 23 Dec 2018 20:14:37 -0000

Hi Dave, and thanks for your comments.

> "and it does not require any form of persistent storage."

> I would just strike this claim, because it does. While in one
> embodiment (hnet) it is possible to bootstrap keys, in most others you
> need a routing protocol running before you can dynamically ship conf
> files or dynamic configuration to the ends of the network.

I've clarified that.

(The claim here is that there is no storage necessary for indices and
seqnos -- indices and seqnos can be discarded when a router reboots, at
the cost of a mere RTT of lost data (the time needed for a challenge).  Of
course, persistent storage is needed for storing keys.)

> "per-interface 32-bit integer known as the "packet counter" (PC)."

> Do we have the blessing of a cryptographer type saying just how secure
> this and the nonce and index are?

What do you mean?

> "Every implementation MUST implement HMAC-SHA256
>    [RFC6234], and MAY implement other HMAC algorithms.

> I think we managed to get blake2s up to a SHOULD in the past weeks. :)


> "Every implementation MUST implement HMAC-SHA256 [RFC6234], SHOULD
>    implement blake2s, and MAY implement other HMAC algorithms.

Yep, but with a precise reference (chapter and verse).

> "SHOULD implement two or more IETF-approved HMAC algorithms".

Nope.  The IETF is not in the business of approving HMAC algorithms.

> "if the PC overflows, a new index is generated;"

> "*When* the PC overflows", not if.

I'm not sure what your point is.  A PC overflow will happen once in
4 billion Babel packets.  With reasonable parameters, that's once in a few
hundred years.

> And overflow + new index generation is one of those things that
> implementors MUST test.

If an implementation is buggy, it will become unreachable after a few
hundred years without a reboot.  I'm not too worried.

> I'm not not huge on the word "index", as used throughout, as in most
> programming contexts that's usually a 32 bit integer. Secondary Nonce?

It was originally the "sender's nonce", but David pointed out it's not
a nonce (it's used multiple times).  I then suggested "tag", but David
pointed out that the term "tag" has a different meaning in a security

Index is unusual, granted, but it makes sense: the protocol relies on
having multiple sequences of PCs, and the index identifies the PC sequence
we're in right now -- think of it as indexing a (virtual) table of PC

> "can
>    be fairly large (up to 192 octets)"

> "There MUST be a minimum size defined for the nonce and index of" (go
> drinking with a good cryptographer).

You don't need a cryptographer, it's a rather trivial probability
computation.  Advice is given in the third paragraph of the Security
Considerations section.

> Otherwise implementors will use a single byte.

If an implementation never loses its PC (e.g. because it has a reliable
hardware clock), size 0 indices make perfect sense.

For nonces, you need to make sure that a nonce is never reused for a given
(key, source, destination) triplet.  If you have reliable persistent
state, then you can use a counter that is set to 0 whenever you rekey.
The counter can be encoded in the minimum number of octets necessary, and
hence when the counter is 0, a 0-byte nonce makes perfect sense.

In short, 0-byte indices and nonces make perfect sense, and I'm opposed to
fixing a minimum size.

> 7.  IANA Considerations

> Has anyone gone to iana so these tlvs can be baked in stone?


-- Juliusz