RE: Comments on draft-ietf-bfd-hmac-sha

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Tue, 15 April 2014 02:59 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CA1A0310 for <rtg-bfd@ietfa.amsl.com>; Mon, 14 Apr 2014 19:59:10 -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 h2BJKFkf61Tf for <rtg-bfd@ietfa.amsl.com>; Mon, 14 Apr 2014 19:59:09 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1C1A04E8 for <rtg-bfd@ietf.org>; Mon, 14 Apr 2014 19:59:01 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s3F2wt3R023413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Apr 2014 21:58:55 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s3F2wr4G001940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Apr 2014 22:58:53 -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; Mon, 14 Apr 2014 22:58:53 -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; Tue, 15 Apr 2014 10:58:52 +0800
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, "draft-ietf-bfd-hmac-sha@tools.ietf.org" <draft-ietf-bfd-hmac-sha@tools.ietf.org>
Subject: RE: Comments on draft-ietf-bfd-hmac-sha
Thread-Topic: Comments on draft-ietf-bfd-hmac-sha
Thread-Index: Ac9YIlbosz55+Nx5RgqmDHvfyuFe+gAMyFQw
Date: Tue, 15 Apr 2014 02:58:51 +0000
Message-ID: <20211F91F544D247976D84C5D778A4C32E5EC50D@SG70YWXCHMBA05.zap.alcatel-lucent.com>
References: <CECE764681BE964CBE1DFF78F3CDD3941E1081CF@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E1081CF@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.253.19.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QaVuR13cd7qvmIYUIlNiPUmRFwI
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 02:59:11 -0000

Hi Nobo,

Thanks for the review. We'll be addressing them all in the next revision.

One quick comment.

It's a standard track document because vendors have to implement the crypto-mathematics given in this document down to the last dot (if there ever was such a phrase) to come up with an interoperable implementation.

The crypto-maths here includes the notion of an Additional Pad (Apad) which increases the security, and isnt defined in the regular NIST documents that we refer to in this draft. How it increases the security is a long painful discussion best done in a pub when everything around is us already fuzzy and blurred.

Cheers, Manav

> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya
> (nobo)
> Sent: Tuesday, April 15, 2014 3:51 AM
> To: draft-ietf-bfd-hmac-sha@tools.ietf.org
> Cc: rtg-bfd@ietf.org
> Subject: Comments on draft-ietf-bfd-hmac-sha
> 
> Hi Authors,
> 
> I have reviewed your draft (draft-ietf-bfd-hmac-sha), comments below.
> Since document is nearing expiration, perhaps you can address some of
> these comments and re-publish?
> 
> 
> (1) Section 3, couple of places
> 
> s/avaliable/available/g
> 
> 
> (2) Section 2, 3, 4
> 
> I see that most texts from sections 3 & 4 overlaps with texts in draft-
> ietf-bfd-generic-crypto-auth. Are texts in section 2 something required
> for BFD to use HMAC-SHA (i.e. required to interop)?  I'm just wondering
> why this is a standard-track document, i.e. with draft-ietf-bfd-
> generic-crypto-auth available, whether or not we need to write
> standard-track draft for every authentication that BFD need to use
> going forward. Maybe I over-looked something ...
> 
> 
> (3) Section 2
> 
> Missing '.' chars.
> 
> [old]
>    B is the block size of H, measured in octets rather than bits.  Note
>    that B is the internal block size, not the hash size.  For SHA-1 and
>    SHA-256: B == 64 For SHA-384 and SHA-512: B == 128 L is the length
> of
>    the hash, measured in octets rather than bits.
> [new]
>    B is the block size of H, measured in octets rather than bits.  Note
>    that B is the internal block size, not the hash size.  For SHA-1 and
>    SHA-256: B == 64. For SHA-384 and SHA-512: B == 128. L is the length
>    of the hash, measured in octets rather than bits.
> [snip]
> 
> 
> -Nobo