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

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 21 May 2014 11:14 UTC

Return-Path: <manav.bhatia@alcatel-lucent.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 3FC231A04C2; Wed, 21 May 2014 04:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 FKPllPfm5ahU; Wed, 21 May 2014 04:14:52 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF6D1A04B6; Wed, 21 May 2014 04:14:51 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s4LBEjbH019911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 May 2014 06:14:46 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s4LBEjNl019349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 May 2014 07:14:45 -0400
Received: from SG70YWXCHHUB04.zap.alcatel-lucent.com (135.253.2.38) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 May 2014 07:14:44 -0400
Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.212]) by SG70YWXCHHUB04.zap.alcatel-lucent.com ([135.253.2.38]) with mapi id 14.02.0247.003; Wed, 21 May 2014 19:14:41 +0800
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Loa Andersson <loa@pi.nu>, Manav Bhatia <manavbhatia@gmail.com>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Thread-Topic: SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05
Thread-Index: AQHPcRACnDeFnD7gHUOXWsSAGM4MlZtGKCeAgAGxPwCAAaG6AIABLjlg//+CUQCAAIezIP//ohaAgAAERwCAAAU8AIAAiYEQ
Date: Wed, 21 May 2014 11:14:40 +0000
Message-ID: <20211F91F544D247976D84C5D778A4C32E60BA5C@SG70YWXCHMBA05.zap.alcatel-lucent.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>
In-Reply-To: <537C86D6.1030703@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.253.19.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8pU6jhzZb-7YbGk0i_DGSFCQp18
Cc: "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>, IETF Security Directorate <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: Wed, 21 May 2014 11:14:54 -0000

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. 

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.

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]
> 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; 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] 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 Cc: Yaron
> >>>>>> Sheffer; 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
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64