Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00

Juliusz Chroboczek <jch@irif.fr> Fri, 02 November 2018 10:11 UTC

Return-Path: <jch@irif.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2712F1A5; Fri, 2 Nov 2018 03:11:14 -0700 (PDT)
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 LcQ11gmQef3G; Fri, 2 Nov 2018 03:11:12 -0700 (PDT)
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 D52631288BD; Fri, 2 Nov 2018 03:11:08 -0700 (PDT)
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 wA2AAx69030400; Fri, 2 Nov 2018 11:10:59 +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 ABC5446DB0; Fri, 2 Nov 2018 11:11:05 +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 9f89-qBtIOCy; Fri, 2 Nov 2018 11:11:03 +0100 (CET)
Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6543946DA9; Fri, 2 Nov 2018 11:11:03 +0100 (CET)
Date: Fri, 02 Nov 2018 11:11:03 +0100
Message-ID: <87ftwjpz60.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: <secdir@ietf.org>, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org
In-Reply-To: <154110959830.29553.6414151772410048476@ietfa.amsl.com>
References: <154110959830.29553.6414151772410048476@ietfa.amsl.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]); Fri, 02 Nov 2018 11:11:01 +0100 (CET)
X-Miltered: at korolev with ID 5BDC22B3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5BDC22B3.000 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 : 5BDC22B3.000 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/secdir/oTEkze0CAWNoLDlv8TU70M2qCqk>
Subject: Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Nov 2018 10:11:15 -0000

Dear Robert,

Thank you very much for your review.

> Issues:

> The pseudo-header is IPv4-centric.

The diagram in Section 4.1 shows 16-octet addresses, and so, if anything,
it is IPv6-centric.  I may be missing something, but I don't see any place
where we're assuming IPv4.

(The intent, of course, is that the pseudo-header is address-family
independent -- the diagram shows 16-octet addresses, but we've been
careful to avoid mentioning address families in the body text.  If you
have any advice about how to improve that, we're listening.)

> The protocol allows for multiple HMAC algorithms, but has no mechanism for
> signaling which one was used.

This is the case, and it is the intent -- checking algorithm availability
is done at key provisioning time.

> The MUST NOT at the top of page 8 will need to be adjusted after that's
> worked out.  Discussion of what to do at a verifying peer that doesn't
> implement a chosen algorithm is also needed.

I don't understand.  The first point of Section 4.3 looks clear to me --
a node doesn't compute an HMAC for every HMAC TLV it receives, it computes
an HMAC for every key it has been provisioned with.  Obviously, it knows
the algorithm of every key it has been provisioned with (else it would
have failed at configuration time), and hence there is no issue computing
all required HMACs.

Am I missing something?  Do you have any suggestions about how to make
that clearer?

> Nits:

> The claim in 1.1 about not requiring persistent storage is contradicted
> by the definition of the protocol. At the very least, there is the need
> to persist the most recent (index,PC) seen.

A node is allowed to lose its state at any time, at the cost of one RTT
worth of lost packets (it will need to issue a new challenge to every
peer).  In particular, it need not persist its state across reboots.

You're right, though, that while this is reasonably clear in the
Conceptual Overview section ("Consider a peer A that has no information
about a pair B (e.g., because it has recently rebooted)"), we need to put
an explicit "MAY discard its state at any time" in the normative part.

> The third bullet at the top of page 4 (among different nodes) has its actors
> confused. As stated, communication between A and C is irrelevant to the
> communication between B and C.

I have double-checked, and I believe the property is correct as stated.

> It would be worth building an example of bootstrapping the protocol between 
> two peers that have no previous knowledge of each other.

We've tried to do that in Section 2:

   In this situation, A discards the packet and challenges B to prove
   that it knows the HMAC key.  It sends a "challenge request", a TLV
   containing a unique nonce, a value that has never been used before
   and will never be used again.  B replies to the challenge request
   with a "challenge reply", a TLV containing a copy of the nonce chosen
   by A, in a packet protected by HMAC and containing the new value of
   B's PC.

If you have any advice about how to improve this section, we're listening.

> It's concerning to see a document (even a 00) whose point is to secure a
> protocol have no discussion at all in the Security Considerations section.

While we've done our best to describe the claimed security properties of
the protocol in Section 1.2, we still need to write up the Security
Considerations section.  We'll do that as soon as we can spend some time
together with my co-authors.

Thanks again for your work,

-- Juliusz