Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT)

Juliusz Chroboczek <jch@irif.fr> Thu, 08 August 2019 13:47 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 76B291200B6; Thu, 8 Aug 2019 06:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMAAzbzz3s9p; Thu, 8 Aug 2019 06:47:09 -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 70D5E120044; Thu, 8 Aug 2019 06:47:09 -0700 (PDT)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x78DkwAx019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Aug 2019 15:46:58 +0200
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x78DkuCU026804; Thu, 8 Aug 2019 15:46:58 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 561642EF21; Thu, 8 Aug 2019 15:46:59 +0200 (CEST)
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 SX8rfU7O16Tm; Thu, 8 Aug 2019 15:46:58 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 421A52EF1F; Thu, 8 Aug 2019 15:46:56 +0200 (CEST)
Date: Thu, 08 Aug 2019 15:46:56 +0200
Message-ID: <87v9v7wyzz.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-babel-hmac@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel-chairs@ietf.org, babel@ietf.org
In-Reply-To: <156520650683.8432.7109781814790904901.idtracker@ietfa.amsl.com>
References: <156520650683.8432.7109781814790904901.idtracker@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="UTF-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 08 Aug 2019 15:46:58 +0200 (CEST)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 08 Aug 2019 15:46:58 +0200 (CEST)
X-Miltered: at korolev with ID 5D4C27D2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5D4C27D0.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5D4C27D2.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 5D4C27D0.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 : 5D4C27D2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5D4C27D0.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/nzYza31cUWwjJNsQP6g3m19vQ6A>
Subject: Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT)
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: Thu, 08 Aug 2019 13:47:12 -0000

Dear Roman,

Thank you for your review.

> (1) Section 1.2.  Per “any packet accepted as authentic is the exactly copy of
> a packet originally sent”, this text can be read two ways – packet as Babel
> packet or as an IP packet.  I think  mean the former.  Recommend making this
> clearer as s/any packet/any Babel packet/

Done.

> (2) Section 2, Per the paragraph, “By itself, this mechanism is safe
> against replay …”, please reiterate that for the attack by C to work:
> A and B must have both lost state; that C is replaying packets with PC
> previously sent by B (e.g., n+2).

Only A needs to have lost its state.  Clarified.

> (3) Section 4.1.  Per “The node takes the concatenation of the pseudo-header
> and the packet including the packet header but excluding the packet trailer
> (from octet 0 inclusive up to (Body Length + 4) exclusive)”, as input for the
> HMAC.  “packet” is used to sometimes mean IP packet and sometimes a Babel
> packet carried in an IP packet.

Clarified.

> (4) Section 2.  This section suggests that “one or more HMACs can be
> appended to the packet”.  Under what conditions would it be more than
> one?  What happens if only some of the HMACs are valid?  Is use of the
> same key assumed?

This section is a conceptual overview, and is optimised for easy
readability.  The exact details are given in 4.3.  I've added the
paranthetical remark "(one per key)", but refuse to overload this section
any further.

> (5) Section 4.1.  The hash algorithm appears to be negotiated/set out of band
> (rather than negotiated). The text should explicitly state that somewhere.

Section 3.1.

> (6) Section 6.  Per “In particular, reception of a packet with no
> correct HMAC creates no local state whatsoever (Section 4.3)”, unless
> this HMAC verification is happening on the NIC, this doesn’t seem
> sufficiently precise.  The “no local state” claim is likely true only as
> it relates to the tables data structures describes in Section 3.
> However, the IP and DTLS stack certainly have to account for the packet.

There is no DTLS in this protocol.

I'm leaving this sentence as is -- after trying it out, I don't think that
mentioning the small amount of state caused by reception of a UDP packet
(an ND entry) is informative.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

> (7) Section 1 enumerates a series of attacks.  These are different than the
> ones listed in Section 6 of draft-ietf-babel-rfc6126bis and Section 1 of
> draft-ietf-babel-dtls.  As HMAC and DTLS are mitigations for attacks in
> draft-ietf-babel-rfc6126bis, they really should be harmonized.

I'll look at making this uniform between the three drafts.

> (8) Section 1.  Per the “spoof of a malformed packet”, how would an HMAC
> address this?  Even assuming that a node discards the message without
> processing if the HMAC is bad, this would still be a problem from
> a malicious peer.

Please explain.

> (9) Editorial nits:

Fixed, thanks.

-- Juliusz