Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

David Mandelberg <> Wed, 09 September 2015 01:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C5E3D1B31B8 for <>; Tue, 8 Sep 2015 18:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EMsLWETNjEJI for <>; Tue, 8 Sep 2015 18:21:55 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3604B1B31B4 for <>; Tue, 8 Sep 2015 18:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1441761714; bh=SLxY3n+GXV+nY1QYlAh2Wg+67xWwOsxVywK7BuRLcgM=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=Mwt7o8DKH2gpwb2IRiARD5U8AbEKC6ebj7eIXOP0UlDKo3KjRGTORVk8hTS7qz1OAulrNdf6kZMxHzcag9rJeGzFISulX3ZPCbXavA07RXGmftjxqgza1wmwX+DKIG9hvnSoK+URaI9zPtTK0YfKvaEhbUTFji4YRyN0qHZO6ywQ0LGBtR2dcMLUqKkenKIPwYp+pparQtMFom4oq0YBgANiXMWLGo+rtQCwQHZ6oR7GPbAfl+AT+mRgGPzafWekJflsRJjCUApVPIrYjJK+fqTNsdpzoZ9xIApJGaNKm0Ta6x3LFdU5IWhHorkC49V/5zpP16Lb4FuueiN/o9jaig==
Received: from [] by with NNFMP; 09 Sep 2015 01:21:54 -0000
Received: from [] by with NNFMP; 09 Sep 2015 01:21:54 -0000
Received: from [] by with NNFMP; 09 Sep 2015 01:21:54 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 1LxQ7HgVM1lCBTK8CdJBXBtl6yPDp._.IIU6vVUZmeHGZCl xDVnH2nNP2mwlxsKDw0V5QsJbwNsyHngwbJM.m8peqFp1cTySAvCgxGFjk5u YcH0PL1BF3.rBC6ERYI0W8dskZiJZotZk.Nz2ZVDSNifZCPg5BSDXUfkQQAm A2b37I3dPuYhQj0W9LeTQ_Zgi4NzDSAMsm8aVii0UoZdQtRxqeowh2XOCeIx qxbYhiu92SvKTL7Dy9Z_wYRk0swcekPatqF2p1Y7Db8ZoCdTnycEDZwOXX0e JJCbBln_QyGhNhenp4oN_glOjWh3no6EewBEgvwKfqbRpTkAxUEhuQDCKHMl dx_6gwz8r7oCHZwSdfhZV1B48Bm4296bIdxOO5vkDBjVFQTtvNJaTWMQuWiN gdXM7E14T0PZEwxsuKtLjBTJGFYEDcvclfUs2KMssWAtaaoDqvAJu0k3LewZ sjzJKvuOBuf7U4F8B.5b_KfJmHWhro3YuYxvM0m9rZpQ.5PqjtwKv2u9qbeF rE6PC9ACnVrkLS.YQKb0ai2ht8bf7I6ukKSdtWg--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from ( []) by (Postfix) with ESMTPSA id 6CB721C6095 for <>; Tue, 8 Sep 2015 21:21:52 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Sep 2015 21:21:52 -0400
From: David Mandelberg <>
In-Reply-To: <>
References: <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Sep 2015 01:21:57 -0000

On 2015-09-08 21:07, Rob Austein wrote:
> Hmm, I would have thought we'd want to keep the chaining, in the 
> sense
> that non-originating would sign the previous signature.  I've no real
> objection to signing everything else again, it's just removal of the
> previous signature that I find odd here.
> The benefit I see to keeping the signature chaining is that it adds 
> an
> ordering constraint to the signatures (signature A must have been
> created after signature B), corresponding to the order in which we
> expect the update to travel between signers.  This seems like a good
> thing, and I don't see why we'd want to remove it.  As you've
> demonstrated, it doesn't remove all possible forms of mischief, but 
> it
> raises the bar a bit, and it's cheap, so why not?

I agree that signature chaining provides the guarantee you stated, that 
signatures were generated in order. But in the presence of 
non-validating signers, I don't think it provides any other guarantee.

What does the guarantee about signature order provide? I don't see how 
it's useful, but I could be missing something.

> Am I missing something?  Where's the benefit in removing the 
> chaining?

There's no benefit to removing it, except that I don't see any benefit 
to keeping it (if we sign the full data, as I described).

David Eric Mandelberg / dseomn