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
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Sandra Murphy
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… George, Wes
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- [sidr] David M's point about the bgpsec protocol … Sandra Murphy
- Re: [sidr] David M's point about the bgpsec proto… Randy Bush
- Re: [sidr] David M's point about the bgpsec proto… Randy Bush
- Re: [sidr] David M's point about the bgpsec proto… Sandra Murphy
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Keyur Patel (keyupate)
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Montgomery, Douglas
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Randy Bush
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… David Mandelberg
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Matthew Lepinski
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Michael Baer
- Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protoc… Sriram, Kotikalapudi
- [sidr] Levels of BGPsec/RPKI validation, was: Re:… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Roque Gagliano (rogaglia)
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… David Mandelberg
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sandra Murphy
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Roque Gagliano (rogaglia)
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Geoff Huston
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sriram, Kotikalapudi
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Jared Mauch
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Sriram, Kotikalapudi
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Iljitsch van Beijnum
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Randy Bush
- Re: [sidr] [Idr] Levels of BGPsec/RPKI validation… Tim Bruijnzeels
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Matthew Lepinski
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Matthew Lepinski
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Sriram, Kotikalapudi
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Stephen Kent
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Iljitsch van Beijnum
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Stephen Kent
- Re: [sidr] Levels of BGPsec/RPKI validation, was:… Sriram, Kotikalapudi