Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

Michael Baer <baerm@tislabs.com> Tue, 10 February 2015 17:11 UTC

Return-Path: <baerm@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 393AE1A9117 for <sidr@ietfa.amsl.com>; Tue, 10 Feb 2015 09:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 yl1cF9dLs-b0 for <sidr@ietfa.amsl.com>; Tue, 10 Feb 2015 09:11:26 -0800 (PST)
Received: from mail.mikesoffice.com (dns.mikesoffice.com [75.101.48.145]) by ietfa.amsl.com (Postfix) with ESMTP id 182F01A9119 for <sidr@ietf.org>; Tue, 10 Feb 2015 09:09:05 -0800 (PST)
Received: from localhost (unknown [173.239.75.179]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 70660395D3E; Tue, 10 Feb 2015 09:09:04 -0800 (PST)
From: Michael Baer <baerm@tislabs.com>
To: David Mandelberg <david@mandelberg.org>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org>
X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.:<GckOP:; wBMTb7\%Y"JI=R<M6g?6}tR)6Z7rp5X*24G\bkb!
Date: Tue, 10 Feb 2015 09:09:03 -0800
In-Reply-To: <82de0e0b8d59df99675cf4eb22996d08@mail.mandelberg.org> (David Mandelberg's message of "Thu, 05 Feb 2015 23:38:16 -0500")
Message-ID: <87iof9r8wg.fsf@rebma.mikesoffice.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/MTO1MulHxYF4lP5TKmawSMSyfwM>
Cc: sidr@ietf.org
Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11
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: Tue, 10 Feb 2015 17:11:29 -0000

>>>>> On Thu, 05 Feb 2015 23:38:16 -0500, David Mandelberg <david@mandelberg.org> said:

    David> After reviewing this document, I have one concern below, and
    David> some nits that I'll send to the editor. Otherwise it looks
    David> good to me.

    David> In sections 4.1 and 4.2, there are two different to-be-signed
    David> structures. If I understand correctly, the same router keys
    David> will be used to sign data from both structures. It might be
    David> possible for an attacker to take a valid signature of data
    David> from the structure in 4.2, and present it as a valid
    David> signature of the same bytes interpreted with the structure in
    David> 4.1. I'm not sure anything malicious could be done this way,
    David> but reinterpreting the meaning of signed data seems like a
    David> bad idea to me. It would be easy to prevent this by
    David> prepending both structures with a single byte that MUST BE 0
    David> for 4.1 and MUST BE 1 for 4.2. Apologies if this has already
    David> been discussed and is not an issue.

I don't believe this is a problem.  The signature is calculated by
creating a digest of the data and then creating a signature from that
digest.  I'm definitely not a cryptography expert, but my understanding
of digest functions generally is that with even slightly differing
input, the resulting set of bits should be completely different.
Assuming the digest function chosen is not flawed, there shouldn't be a
set of bits from the digest of 4.1 that could be used to successfully
replace the digest of 4.2, except by chance.

-Mike

-- 
Michael Baer
baerm@tislabs.com