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

Loa Andersson <loa@pi.nu> Wed, 28 May 2014 07:14 UTC

Return-Path: <loa@pi.nu>
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 CF58A1A03C1; Wed, 28 May 2014 00:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 lsP9MtTcuhMN; Wed, 28 May 2014 00:14:10 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD251A0384; Wed, 28 May 2014 00:14:09 -0700 (PDT)
Received: from [192.168.1.8] (unknown [119.94.254.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2721D18013DA; Wed, 28 May 2014 09:14:01 +0200 (CEST)
Message-ID: <53858CB7.8080508@pi.nu>
Date: Wed, 28 May 2014 09:13:59 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Manav Bhatia <manavbhatia@gmail.com>
References: <53761B24.1060501@gmail.com> <20211F91F544D247976D84C5D778A4C32E60982F@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537A694C.60101@gmail.com> <537BC7B6.5040406@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B609@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C5BCE.4010801@cs.tcd.ie> <20211F91F544D247976D84C5D778A4C32E60B6A8@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537C7EDB.9050000@cs.tcd.ie> <CAG1kdogiEJp=jy5D+tvXnAZ2XD0Xe1=kB-do_=h4PU1V9j7KKQ@mail.gmail.com> <537C86D6.1030703@pi.nu> <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.com> <537CA2D2.4070103@cs.tcd.ie> <54E263B5-41C7-4523-9941-B3E39AE077CD@mit.edu> <57ee448f94f94cd7ba040903e604aa3c@SG70XWXCHHUB01.zap.alcatel-lucent.com> <CAG1kdoj=VpE_EJc1zB=50eTsr=44Jr4yUc3BZVH2QpLJMR6mHQ@mail.gmail.com> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8302E4@SZXEMA504-MBS.china.huawei.com> <53858ACE.8030909@pi.nu> <CAG1kdoidVWx2i_TEsBtvDCVPq99_ZpnNkY59GPi-=RHfzrO0wQ@mail.gmail.com>
In-Reply-To: <CAG1kdoidVWx2i_TEsBtvDCVPq99_ZpnNkY59GPi-=RHfzrO0wQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/U6chDX66oJHh5Uuigjul1EPc2Uo
Cc: "Bhatia, Manav \(Manav\)" <manav.bhatia@alcatel-lucent.com>, IETF Security Directorate <secdir@ietf.org>, "draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org" <draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>, The IESG <iesg@ietf.org>, Vero Zheng <vero.zheng@huawei.com>
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: Wed, 28 May 2014 07:14:13 -0000

Folks,

This is not entirely scientific, but based on the diff's bwetween
version -04 and -06, does to me not indicate that the changes are
such that we need to take the draft back to the wg for a new wglc.

Unless the responsible AD or my co-chairs speaks up and have a
different opinion, it is my opinion that we now should move this
draft ahead.

/Loa

On 2014-05-28 09:06, Manav Bhatia wrote:
> Yup, thats correct!
>
>
> On Wed, May 28, 2014 at 12:35 PM, Loa Andersson <loa@pi.nu
> <mailto:loa@pi.nu>> wrote:
>
>     All,
>
>     Do I understand correctly if we are now OK to go ahead and have
>     this draft approved?
>
>     /Loa
>
>
>     On 2014-05-26 03:30, Vero Zheng wrote:
>
>         Thanks Yaron and Manav for working this out.
>
>         I have just confirmed the post.
>
>         Cheers, Vero
>
>         *From:*Manav Bhatia [mailto:manavbhatia@gmail.com
>         <mailto:manavbhatia@gmail.com>]
>         *Sent:* Sunday, May 25, 2014 1:50 PM
>         *To:* Yaron Sheffer
>         *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav); IETF
>
>         Security Directorate;
>         draft-ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org
>         <mailto:draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>__;
>         The IESG; Loa
>         Andersson
>         *Subject:* Re: [secdir] SecDir review of
>
>         draft-ietf-mpls-ldp-hello-__crypto-auth-05
>
>         Hi,
>
>         Yaron, I and few of us exchanged quite a few emails offline and
>         we have
>         come up with a version that addresses Yaron's and Stephen's concerns
>         about repeating the HMAC stuff thats already present in RFC
>         2104. We've
>         cleaned it up pretty nicely with very minimal changes.
>
>         I am unable to submit this latest and the greatest version since
>         i have
>         updated my email ID in this version. The tracker requires one of the
>         co-authors to authenticate/approve the submission.
>
>         I am attaching the latest version with this email in case folks
>         want to
>         go through this till it becomes available formally.
>
>         The draft is all set to fly now! :-)
>
>         Cheers, Manav
>
>         On Wed, May 21, 2014 at 7:54 PM, Yaron Sheffer
>         <yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>
>         <mailto:yaronf.ietf@gmail.com <mailto:yaronf.ietf@gmail.com>>__>
>         wrote:
>
>         IMHO, this is purely a naming problem. Apad does NOT modify the base
>         HMAC, please see
>         http://tools.ietf.org/html/__draft-ietf-mpls-ldp-hello-__crypto-auth-05#section-5
>         <http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-05#section-5>.
>         It is just one more thing that's signed by HMAC.
>
>         My problem with this draft is that they have different ideas
>         about the
>         key length, compared to RFC 2104 (top of Sec. 5.1). Also, I am
>         unhappy
>         that they spell out the HMAC construction instead of leaving it as a
>         black box.
>
>         But I think Apad is just fine, if it weren't for the unfortunate
>         name
>         that leads people to think it's modifying HMAC.
>
>         Thanks,
>                   Yaron
>
>
>         On 05/21/2014 04:28 PM, Uri Blumenthal wrote:
>
>             Once again, please.
>
>             1. Who specifically, at NIST and at IESG, says that HMAC
>             needs Apad for security reasons (and therefore is not secure
>             as-is)?
>
>             2. What are those security reasons, and what are the attacks
>             that are foiled by Apad?
>
>             3. What published papers/references/whatever is this
>             documented? As HMAC came with security proofs, I’d like to
>             see where and how they are invalidated (if they indeed are).
>
>
>
>             On May 21, 2014, at 8:57 , Stephen Farrell
>             <stephen.farrell@cs.tcd.ie
>             <mailto:stephen.farrell@cs.tcd.ie>
>             <mailto:stephen.farrell@cs.__tcd.ie
>             <mailto:stephen.farrell@cs.tcd.ie>>> wrote:
>
>
>
>                 On 21/05/14 12:14, Bhatia, Manav (Manav) wrote:
>
>                     I agree with Loa.
>
>                     Our current draft is very simple and has gone
>                     through multiple
>                     iterations of reviews in at least two WGs. It brings
>                     LDP to the same
>                     level of security as other protocols running in the
>                     networks.
>
>
>                 Fully agree with that goal.
>
>
>                     I think we should just push it forward and if there
>                     is an interest in
>                     writing a new ID that updates HMAC specification,
>                     then we write one
>                     that includes the Apad stuff. I think the latter
>                     should anyways be
>                     done, regardless of what happens to this particular
>                     draft.
>
>
>                 I need to read it. But I'd be happier if that HMAC draft
>                 existed
>                 and was going to be processed - then we wouldn't have to
>                 do this
>                 discussion again.
>
>                 Cheers,
>                 S.
>
>
>                     The IETF submission site is down and hence couldn’t
>                     upload the
>                     revised ID (addressing Yaron's comments). Will do it
>                     tomorrow once
>                     its up.
>
>                     After that its ready to be placed before the IESG.
>
>                     Cheers, Manav
>
>                         -----Original Message----- From: Loa Andersson
>                         [mailto:loa@pi.nu <mailto:loa@pi.nu>
>                         <mailto:loa@pi.nu <mailto:loa@pi.nu>>]
>
>                         Sent: Wednesday, May 21, 2014 4:29 PM To: Manav
>                         Bhatia; Stephen
>                         Farrell Cc: Bhatia, Manav (Manav); IETF Security
>                         Directorate; The
>                         IESG;
>                         draft-ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org
>                         <mailto:draft-ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>
>
>         <mailto:ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org
>         <mailto:ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>__>;
>
>                         Yaron Sheffer Subject: Re: SecDir review of
>                         draft-ietf-mpls-ldp-hello-__crypto-auth-05
>
>                         Folks,
>
>                         I'm only the document shepherd. My feeling is
>                         that we are raising
>                         the hurdle step by step for the KARP - initiated
>                         RFCs, the first
>                         was comparatively smooth, now we are trying to
>                         put an 18 months
>                         effort (individual draft to RFC) in front of
>                         approving something
>                         that is comparatively simple and seen as raising
>                         LDP to the same
>                         security as the other routing protocols.
>
>                         So if we get to tired to push this, we are all
>                         better off not
>                         doing the security work for this particular
>                         protocol?
>
>                         Someone said - "Never let the best be the enemy
>                         of the possible"!
>
>                         /Loa
>
>
>
>                         On 2014-05-21 12:39, Manav Bhatia wrote:
>
>                             Stephen,
>
>                                     This however is a long drawn
>                                     discussion because everyone
>                                     needs to
>
>                         be
>
>                                     convinced on the merits of updating
>                                     the HMAC specification --
>                                     which
>
>                         I
>
>                                     am not sure will take how long.
>
>
>                                 So I need to look at this draft, HMAC
>                                 and the other cases but
>                                 it seems to me that you're copying a
>                                 page or two of crypto spec
>                                 each time and changing one line. Doing
>                                 that over and over is a
>                                 recipe for long term pain, isn't it?
>
>
>                             It sure is.
>
>                             I had volunteered to write a 1-2 page long
>                             ID that updated the
>                             HMAC
>
>                         to
>
>                             include the Apad, but the idea was shot
>                             down. The only
>                             alternative left was to include the crypto
>                             stuff in each standard
>                             that we wrote later.
>
>
>                                 (And we've had this discussion for each
>                                 such draft while I've
>                                 been on the IESG I think, which is also
>                                 somewhat drawn out;-)
>
>
>                             This draft is probably the last one thats
>                             coming from the Routing
>                             WG which will have this level of crypto
>                             mathematics spelled out.
>                             All other IGPs are already covered. In case
>                             we need to change
>                             something
>
>                         in
>
>                             the ones already covered we can refer to the
>                             base RFC where we
>                             have detailed the crypto maths. For example,
>                             draft-ietf-ospf-security-__extension-manual-keying-08
>                             amongst
>                             other things also updates the definition of
>                             Apad. It points to
>                             the exact mathematics in RFC 5709 and only
>                             updates the Apad
>                             definition in that draft. This draft btw has
>                             cleared the WG LC
>                             and would be appearing before you guys very
>                             soon.
>
>                             Given this, i think we should just pass this
>                             draft with this
>                             level of details. Subsequently, when LDP
>                             wants to update
>                             something, it can normatively refer to this
>                             RFC and only give the
>                             changes.
>
>                             Cheers, Manav
>
>
>                                 S.
>
>
>
>                                     Cheers, Manav
>
>
>
>                                         S
>
>
>                                             Cheers, Manav
>
>                                                 -----Original
>                                                 Message----- From:
>                                                 Stephen Farrell
>                                                 [mailto:stephen.farrell@cs.__tcd.ie
>                                                 <mailto:stephen.farrell@cs.tcd.ie>
>                                                 <mailto:stephen.farrell@cs.__tcd.ie
>                                                 <mailto:stephen.farrell@cs.tcd.ie>>]
>                                                 Sent:
>
>         Wednesday, May
>
>                                                 21, 2014 2:53 AM To:
>                                                 Bhatia, Manav (Manav); IETF
>                                                 Security Directorate;
>                                                 The IESG; draft-
>                                                 ietf-mpls-ldp-hello-crypto-__auth.all@tools.ietf.org
>                                                 <mailto:ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>
>
>         <mailto:ietf-mpls-ldp-hello-__crypto-auth.all@tools.ietf.org
>         <mailto:ietf-mpls-ldp-hello-crypto-auth.all@tools.ietf.org>__> Cc:
>
>                                                 Yaron
>                                                 Sheffer;manavbhatia@gmail.com
>                                                 <mailto:Sheffer%3Bmanavbhatia@gmail.com>
>                                                 <mailto:manavbhatia@gmail.com
>                                                 <mailto:manavbhatia@gmail.com>>
>                                                 Subject: Re:
>
>                                                 SecDir review of
>                                                 draft-ietf-mpls-ldp-hello-__crypto-auth-05
>
>
>
>                                                 On 19/05/14 21:27, Yaron
>                                                 Sheffer wrote:
>
>
>                                                             * 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.
>
>
>                                                         This is a
>                                                         decision that
>                                                         was taken by Sec
>                                                         Ads when
>                                                         we were doing
>                                                         the crypto
>                                                         protection for
>                                                         the IGPs
>                                                         based on some
>                                                         feedback from NIST.
>
>                                                 This
>
>                                                         mathematics is
>                                                         not new and has
>                                                         been done for all
>                                                         IGPs and has
>                                                         been approved
>                                                         and rather
>                                                         encouraged by
>                                                         the Security ADs.
>
>
>                                                 The above does not sound
>                                                 like something I
>                                                 recognise. I
>                                                 have repeatedly asked
>                                                 that documents not re-define
>                                                 HMAC. Perhaps this time,
>                                                 I'll make that a DISCUSS and
>                                                 not budge. I probably
>                                                 should have done that before
>                                                 TBH.
>
>                                                 If you are revising that
>                                                 doc, *please* get rid of the
>                                                 re-definition and just
>                                                 properly refer to HMAC. Its
>                                                 about time to stop
>                                                 repeating that error.
>
>                                                 S.
>
>
>
>
>
>
>
>
>                         --
>
>
>                         Loa Andersson email:loa@mail01.huawei.com
>                         <mailto:email%3Aloa@mail01.huawei.com>
>                         <mailto:loa@mail01.huawei.com
>                         <mailto:loa@mail01.huawei.com>>
>                         Senior MPLS Expertloa@pi.nu
>                         <mailto:Expertloa@pi.nu> <mailto:loa@pi.nu
>                         <mailto:loa@pi.nu>> Huawei
>                         Technologies (consultant)     phone:+46 739 81
>                         21 64 <tel:%2B46%20739%2081%2021%2064>
>                         <tel:%2B46%20739%2081%2021%__2064>
>
>
>                 _________________________________________________
>                 secdir mailing list
>                 secdir@ietf.org <mailto:secdir@ietf.org>
>                 <mailto:secdir@ietf.org <mailto:secdir@ietf.org>>
>
>                 https://www.ietf.org/mailman/__listinfo/secdir
>                 <https://www.ietf.org/mailman/listinfo/secdir>
>                 wiki:http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview
>                 <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>
>
>
>             _________________________________________________
>             secdir mailing list
>             secdir@ietf.org <mailto:secdir@ietf.org>
>             <mailto:secdir@ietf.org <mailto:secdir@ietf.org>>
>
>             https://www.ietf.org/mailman/__listinfo/secdir
>             <https://www.ietf.org/mailman/listinfo/secdir>
>             wiki:http://tools.ietf.org/__area/sec/trac/wiki/__SecDirReview
>             <http://tools.ietf.org/area/sec/trac/wiki/SecDirReview>
>
>
>
>     --
>
>
>     Loa Andersson                        email: loa@mail01.huawei.com
>     <mailto:loa@mail01.huawei.com>
>     Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
>     Huawei Technologies (consultant)     phone: +46 739 81 21 64
>     <tel:%2B46%20739%2081%2021%2064>
>
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64