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

[Manav Bhatia <[e-mail]>]

Hi Loa,

We dont need to. The changes are only editorial in nature.

Cheers, Manav


On Wed, May 28, 2014 at 12:43 PM, Loa Andersson <[e-mail]> wrote:

> 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 <[e-mail]
> > <mailto:[e-mail]>> 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:[e-mail]
> >         <mailto:[e-mail]>]
> >         *Sent:* Sunday, May 25, 2014 1:50 PM
> >         *To:* Yaron Sheffer
> >         *Cc:* Uri Blumenthal; Stephen Farrell; Bhatia, Manav (Manav);
> IETF
> >
> >         Security Directorate;
> >         [e-mail]
> >         <mailto:[e-mail]
> >__;
> >         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
> >         <[e-mail] <mailto:[e-mail]>
> >         <mailto:[e-mail] <mailto:[e-mail]>>__>
> >         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
> >             <[e-mail]
> >             <mailto:[e-mail]>
> >             <mailto:stephen.farrell@cs.__tcd.ie
> >             <mailto:[e-mail]>>> 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:[e-mail] <mailto:[e-mail]>
> >                         <mailto:[e-mail] <mailto:[e-mail]>>]
> >
> >                         Sent: Wednesday, May 21, 2014 4:29 PM To: Manav
> >                         Bhatia; Stephen
> >                         Farrell Cc: Bhatia, Manav (Manav); IETF Security
> >                         Directorate; The
> >                         IESG;
> >
> [e-mail]
> >                         <mailto:
> [e-mail]>
> >
> >         <mailto:[e-mail]
> >         <mailto:[e-mail]>__>;
> >
> >                         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:
> [e-mail]>
> >                                                 <mailto:
> stephen.farrell@cs.__tcd.ie
> >                                                 <mailto:
> [e-mail]>>]
> >                                                 Sent:
> >
> >         Wednesday, May
> >
> >                                                 21, 2014 2:53 AM To:
> >                                                 Bhatia, Manav (Manav);
> IETF
> >                                                 Security Directorate;
> >                                                 The IESG; draft-
> >
> [e-mail]
> >                                                 <mailto:
> [e-mail]>
> >
> >         <mailto:[e-mail]
> >         <mailto:[e-mail]>__>
> Cc:
> >
> >                                                 Yaron
> >
> Sheffer;[e-mail]
> >                                                 <mailto:
> [e-mail]>
> >                                                 <mailto:
> [e-mail]
> >                                                 <mailto:
> [e-mail]>>
> >                                                 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:[e-mail]
> >                         <mailto:[e-mail]>
> >                         <mailto:[e-mail]
> >                         <mailto:[e-mail]>>
> >                         Senior MPLS [e-mail]
> >                         <mailto:[e-mail]> <mailto:[e-mail]
> >                         <mailto:[e-mail]>> Huawei
> >                         Technologies (consultant)     phone:[phone]
> >                         21 64 <tel:%2B46%20739%2081%2021%2064>
> >                         <tel:%2B46%20739%2081%2021%__2064>
> >
> >
> >                 _________________________________________________
> >                 secdir mailing list
> >                 [e-mail] <mailto:[e-mail]>
> >                 <mailto:[e-mail] <mailto:[e-mail]>>
> >
> >                 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
> >             [e-mail] <mailto:[e-mail]>
> >             <mailto:[e-mail] <mailto:[e-mail]>>
> >
> >             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: [e-mail]
> >     <mailto:[e-mail]>
> >     Senior MPLS Expert [e-mail] <mailto:[e-mail]>
> >     Huawei Technologies (consultant)     phone: [phone]
> >     <tel:%2B46%20739%2081%2021%2064>
> >
> >
>
> --
>
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
>