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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 14 Apr 2014 22:21:23 +0000

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 15 Apr 2014 02:58:51 +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:[email-masked]] On Behalf Of Nobo Akiya
> (nobo)
> Sent: Tuesday, April 15, 2014 3:51 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-ietf-bfd-hmac-sha
> 
> Hi Authors,
> 
> 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]

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 15 Apr 2014 12:36:11 +0000

Hi Manav,

Ah I see, thanks for clarification!

-Nobo

> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Monday, April 14, 2014 10:59 PM
> To: Nobo Akiya (nobo); [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-bfd-hmac-sha
> 
> Hi Nobo,
> 
> 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
> 
> > 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]