Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06
Sam Hartman <hartmans-ietf@mit.edu> Tue, 11 November 2014 07:57 UTC
Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EE11A8956; Mon, 10 Nov 2014 23:57:07 -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 h7g9-5OnuL26; Mon, 10 Nov 2014 23:57:06 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5517C1AD564; Mon, 10 Nov 2014 23:57:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3090420454; Tue, 11 Nov 2014 02:54:53 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzl9_rngA0yt; Tue, 11 Nov 2014 02:54:51 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (dhcp-890c.meeting.ietf.org [31.133.137.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 11 Nov 2014 02:54:51 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7AA84814C6; Tue, 11 Nov 2014 02:57:02 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Samuel Weiler <weiler@watson.org>
References: <alpine.BSF.2.11.1408181618010.1960@fledge.watson.org>
Date: Tue, 11 Nov 2014 02:57:02 -0500
In-Reply-To: <alpine.BSF.2.11.1408181618010.1960@fledge.watson.org> (Samuel Weiler's message of "Mon, 18 Aug 2014 16:38:48 -0400 (EDT)")
Message-ID: <tsloaseb25t.fsf@mit.edu>
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/secdir/NGOn4xhUjF5GtrcfPu0yBZC0snk
Cc: draft-ietf-karp-bfd-analysis.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-karp-bfd-analysis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 07:57:07 -0000
My comments are prompted by Sam noting that he was hoping others would jump in. >>>>> "Samuel" == Samuel Weiler <weiler@watson.org> writes: Samuel> Summary: I'm not seeing anything that's grossly incorrect, Samuel> but I wonder if this doc is taking the right approach. I'm skeptical this doc is taking the right approach, but was involved in the KARP discussions and had an opportunity to raise comments there and chose not to. In general, I was not able to come up with a concrete articulation of why I thought this document wasn't quite in the right direction. However, on your two specific points, I think the doc is correct, so it's probably not the case that we're in agreement about what's wrong with the approach. Samuel> The security consideration section acknowledges that Samuel> increasing the length of the sequence number or connecting Samuel> the sequence numbers to clock time could reduce the risk of Samuel> replay attacks as, presumably, could moving to the Samuel> "meticulous" approaches that require an increasing sequence Samuel> number (and recomputation) at every packet, at the possible Samuel> cost of needing special hardware or having to increase the Samuel> time between BFD packets. These seem like simpler fixes Samuel> that adding a new hash algorithm, which is what the doc Samuel> ultimately suggests, and I wonder if adding GMAC is really Samuel> needed. There were extensive discussions of the performance arguments. My understanding is that something like GMAC might allow performance to be good enough to increase the sequence numbers fairly often, and that clearly is not true with SHA-1. There were a number of people in the KARP sessions arguing that given the performance constraints SHA-1 was the wrong security algorithm, myself included. Samuel> One thing that's not explicitly discussed, and which I would Samuel> like to see, is a general analysis of algorithm agility - Samuel> how hard is it to add a new algorithm? The doc says that Samuel> BFD has no key rollover mechanism - I suspect that adding Samuel> that and algorithm agility are more important, in the long Samuel> run, than just adding a stronger hash algorithm. (Which Samuel> isn't to say that we even need to improve those, just that Samuel> they may be more important.) This should be discussed. The design guide to which this is an analysis document requires those things be discussed. Well, in particular, the design guide requires a discussion of a gap analysis to the KARP requirements, and the KARP requirements mention algorithm agility and key rollover explicitly. Samuel> I'm also somewhat skeptical of the premise that BFD needs to Samuel> use algorithms that match the routing algorithm strength: Samuel> Moving the routing protocols to a stronger algorithm Samuel> while using weaker algorithm for BFD would allow the Samuel> attacker to bring down BFD in order to bring down the Samuel> routing protocol. BFD therefore needs to match the routing Samuel> protocols in its strength of algorithm. Samuel> Are the attack models of the two really aligned? As best I can tell, yes. In both cases you are concerned about integrity and replay. Samuel> Do the Samuel> keying models for both suggest that one or the other could Samuel> cope with weaker algorithms? Can one be more easily Samuel> rekeyed, thus making it easier to cope with weaker Samuel> algorithms? No. They are both annoying to re-key. It's likely that the IETF will pretend that both use the KARP crypto key table for keying. (Some of the glue to actualize this has not happened and there seems to be a lack of energy to do that glue) Hope this helps. --Sam
- [secdir] secdir review of draft-ietf-karp-bfd-ana… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-karp-bfd… manav bhatia
- Re: [secdir] secdir review of draft-ietf-karp-bfd… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-karp-bfd… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-karp-bfd… Manav Bhatia