Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 16 May 2014 16:35 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 A51481A0076 for <secdir@ietfa.amsl.com>; Fri, 16 May 2014 09:35:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 EOvxm0irnCBa for <secdir@ietfa.amsl.com>; Fri, 16 May 2014 09:35:55 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0091A0281 for <secdir@ietf.org>; Fri, 16 May 2014 09:35:49 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t60so2789206wes.41 for <secdir@ietf.org>; Fri, 16 May 2014 09:35:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BldJiCFWSq180WtSGVZytMeRCRApdWtwp3w43Wf999s=; b=qpvbPWL+21cb6pCngXnIbli0NeUDZsbUVIcnKPA+33dazvJUgTi2bMzFIMC/C0TqRR rHLLTkbsawflu9xU4OAZjjSUlVQbjL2wWNNky1DPrwFkDCyWCLD+9ffU1XZIHigwfJob 10KXH+Tv52uY0FGp3wK8VbbS4quoWciRzk5OVKzXIShdoJLRPG3y790RMdyNk8eu0dau OO0GmZaOdfbdVZ8E2/qyx/CBD21A9WU91TpZ9tK3/6+jtjZX8G9T4P6jVQIMDtHo2PNX 1fehrV5BsHMItolXG03xTQ8ZPiUeEUqTlcK9KR53U8C+QO3UNOrTl0wZgwcqrSvJq973 DnMA==
X-Received: by 10.194.82.170 with SMTP id j10mr3112764wjy.63.1400258141162; Fri, 16 May 2014 09:35:41 -0700 (PDT)
Received: from [10.0.0.1] (bzq-79-179-142-94.red.bezeqint.net. [79.179.142.94]) by mx.google.com with ESMTPSA id go1sm4201228wib.7.2014.05.16.09.35.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 09:35:40 -0700 (PDT)
Message-ID: <53763E5B.3060703@gmail.com>
Date: Fri, 16 May 2014 19:35:39 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Uri Blumenthal <uri@MIT.EDU>
References: <53761B24.1060501@gmail.com> <20140516104303.5znqhmi83ockgsgg@webmail.mit.edu>
In-Reply-To: <20140516104303.5znqhmi83ockgsgg@webmail.mit.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ISHo2c6a3SiAegEeD9TQKPy3M2s
Cc: draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
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: Fri, 16 May 2014 16:35:58 -0000

On 05/16/2014 05:43 PM, Uri Blumenthal wrote:
> Quoting Yaron Sheffer <yaronf.ietf@gmail.com>:
>> .......
>> This document proposes to add cryptographic authentication to LDP "all
>> routers" Hello messages, which are transported as unicast UDP.
>>
>> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This
>> reviewer does not have the appropriate background to critique the
>> proposed solution, but there must be an overwhelming reason to reopen
>> cryptographic primitives.
>
> They do seem to be using HMAC, even though without explicitly naming it
> so (5.1
> and 5.2). Also, HMAC is referred to in the Normative References.
>

Yes, of course. But then they argue with the standard definition, "While 
[RFC2104] supports a key that is up to B octets long, this application 
uses L as the Ks length consistent with [...]". And then instead of 
using it like a black box, they spell it out in 5.2, so developers are 
encouraged to re-implement HMAC instead of using one of dozens of 
existing implementations.

>> • "The mechanism described herein is not perfect and does not need to be
>> perfect." This is kind of vague, and would be better replaced by your
>> security goals.
>
> Concur. :-)
>