[sidr] David M's point about the bgpsec protocol (embarrassing)

Sandra Murphy <sandy@tislabs.com> Thu, 12 February 2015 22:39 UTC

Return-Path: <sandy@tislabs.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F69A1A19E5 for <sidr@ietfa.amsl.com>; Thu, 12 Feb 2015 14:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level:
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 LzdAJbM5bV1k for <sidr@ietfa.amsl.com>; Thu, 12 Feb 2015 14:39:47 -0800 (PST)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5261A038C for <sidr@ietf.org>; Thu, 12 Feb 2015 14:39:45 -0800 (PST)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DF2FF28B0041; Thu, 12 Feb 2015 17:39:44 -0500 (EST)
Received: from cloud.netsec (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 98ACB1F8035; Thu, 12 Feb 2015 17:39:44 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_3E71515A-0414-4359-A9A1-EC68274528BE"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <54DA7C98.4040604@mandelberg.org>
Date: Thu, 12 Feb 2015 17:40:01 -0500
Message-Id: <C28E78CF-4428-4EE6-B494-5123243F51B4@tislabs.com>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> <87iof9r8wg.fsf@rebma.mikesoffice.com> <54DA7C98.4040604@mandelberg.org>
To: Randy Bush <randy@psg.com>, Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/iORi32ktPFjXMzn7MnahQqJZ1pg>
Cc: sidr@ietf.org, Sandra Murphy <sandy@tislabs.com>
Subject: [sidr] David M's point about the bgpsec protocol (embarrassing)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Feb 2015 22:39:49 -0000

I think David is right.

This is embarrassing.  I was looking at the syntax for the protocol in response to David's previous message, realizing that there's no text about what the NLRI length and NLRI prefix fields' syntax should be, looking right at those fields, thinking only that we needed to copy the text from 4271/4760, and did not spot this.

This is embarrassing for the whole wg for not spotting the syntax laxness.  And embarrassing to all the security folk.  There's a standard problem in security protocols about not signing any old group of bits you are given because the signed bits might be used in some other context.  So this should have been spotted much earlier.

I keep hoping if I look at it closely there's a reason why this is not a problem.  Surely SteveK/MattL/SteveB/RussH/etc if the problem were this obvious?

Have you two looked at this?

--Sandy

On Feb 10, 2015, at 4:48 PM, David Mandelberg <david@mandelberg.org> wrote:

> All, while coming up with the example below, I realized another issue.
> The structure in 4.1 doesn't include an Address Family Identifier.
> Unless I missed something, this means that a signature for 1.2.0.0/16
> would be exactly the same as a signature for 102::/16. This would be a
> much more practical attack than the one I originally though of.
>