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

Juliusz Chroboczek <jch@irif.fr> Sun, 23 December 2018 20:14 UTC

Return-Path: <jch@irif.fr>
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 890521277CC; Sun, 23 Dec 2018 12:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S60n0cCQXVBt; Sun, 23 Dec 2018 12:14:35 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [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 ietfa.amsl.com (Postfix) with ESMTPS id A63BF1277BB; Sun, 23 Dec 2018 12:14:34 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wBNKEP1U017360; Sun, 23 Dec 2018 21:14:25 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1F81293B8A; Sun, 23 Dec 2018 21:14:32 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id oAUMwx7s7O_e; Sun, 23 Dec 2018 21:14:29 +0100 (CET)
Received: from pirx.irif.fr (user-164-126-143-147.play-internet.pl [164.126.143.147]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (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: <87bm5cuhjx.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Dave Taht <dave.taht@gmail.com>
Cc: Donald Eastlake <d3e3e3@gmail.com>, babel-chairs@ietf.org, Babel at IETF <babel@ietf.org>
In-Reply-To: <CAA93jw4vF9fX+WF-B2n4GA5SSvSO-kyaq+Y6MV=cbfb-su6LrA@mail.gmail.com>
References: <CAF4+nEFK9myw_RazFN_tsJmdY2m53jWP5jUUBF3Ebm71y5mywA@mail.gmail.com> <CAA93jw4vF9fX+WF-B2n4GA5SSvSO-kyaq+Y6MV=cbfb-su6LrA@mail.gmail.com>
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 (korolev.univ-paris7.fr [194.254.61.138]); 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 mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5C1FECA1.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/TYN99iC8mUUs_Iuy-ZW4fdcCUOg>
Subject: Re: [babel] WG Last Call on draft-ietf-babel-hmac
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: 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. :)

Yep.

> "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
context.

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
sequences.

> "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?

Donald?

-- Juliusz