Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11] document 11-14/1104r1 for TGmc



--- This message came from the IEEE 802.11 Working Group Reflector ---

On 9/18/14 3:25 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

I'm going to ignore all the bluster and repetition, and focus on the

substantive matters.

 

> > This claim is at variance with FIPS PUB 180-3-2008, referred to in clause 2,

>  Well then why do you want to remove the hyphen when using the algorithm

> in the HMAC construct?

 

Because it avoids confusion with the truncation length.  Please note

that a hash and an HMAC which uses a hash are two different things.


  Having implemented both hash algorithms and the HMAC construct, and having
implemented a fully-compliant RSN implementation that uses them both, I am well
aware of that fact. But an HMAC uses a hash and which one is typically identified
by naming it. if you are going to pedantically insist on having the hash name
match FIPS 180-3 then you should be pedantically consistent.

I note that RFC 2104, referenced in clause 2 (normative), explicitly refers

to HMAC-SHA1 and to HMAC-SHA1-80.  I note that RFC 2202, referenced in

Annex A (informative) refers to HMAC-SHA-1.

 

[I also note that FIPS PUB 180-4 suggests "hash/len" terminology for

truncated hashes.  Would this notation be better for truncated HMACs,

at the slight risk of introducing confusion as to whether division is

being indicated?]


  In other words, there is no universal convention to which we can refer. That
being the case we can make our own convention and that convention should
be simple and straightforward. A convention that can be stated with a single
parsing rule is, by definition, more simple and straightforward than a convention
that requires 2 parsing rules.

  My proposed convention is more simple and straightforward than yours.

> > > * if we want to use the HMAC construct we prepend "HMAC-" to the SHA family

> > >      algorithm indicated, including any possible indication of truncation- for

> > >      example, HMAC-SHA256 or HMAC-SHA1-128.

> > I'm fine with this, and 14/1104r1 does this.

>  Well no it doesn't.

 

I'm sorry, I was too hasty here.  Yes, I think we should not use

a hyphen in the hash part of HMAC-hash[-len].


  "the hash part" is the name of the hash. 

> > > we should not be using

> > > the definite article when describing the use of SHA1 in an HMAC

> > > construct while truncating the output to 64 bits.

> > if it is felt that the

> > term should not be accompanied by an article, I fine with that.

>  Good, let's get rid of it.

 

If I don't hear any objections from anyone else, I will make the

changes in 14/1104.


  I object the the hash naming convention (including when it is used in an HMAC
construct) of 11-14/1104r1. 

  Dan.

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Dan Harkins [mailto:dharkins@xxxxxxxxxxxxxxxxx]
Sent: 18 September 2014 12:12
To: Mark Rison; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: document 11-14/1104r1 for TGmc

 

 

 

On 9/18/14 2:01 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

 

Hello,

 

   There are 3 families of the Secure Hash Algorithm. There's the 1st family of

SHA, (which is just designated SHA1) and there's the 2nd family of SHA (known

as SHA2) which is SHA256 and SHA512, including truncated versions of each,

SHA224 is a truncated version of SHA256 and SHA384 is a truncated version of

SHA512.

 

This claim is at variance with FIPS PUB 180-3-2008, referred to in clause 2,

which in turn states that "This Standard specifies five secure hash algorithms

- SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512".  If the hashes have been

renamed, then we need to update the reference in clause 2 (I note that this

document was superseded in 2012, but the latest version, namely

still states that "This Standard specifies secure hash algorithms

- SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256",

so it seems that the names of the hash algorithms in question do have a hyphen).

 

  Well then why do you want to remove the hyphen when using the algorithm

in the HMAC construct?

 

 

   It is important to understand, though, that SHA1, SHA256, and SHA512 are

different. They are not just truncated versions of the same function. And while

SHA256 does actually produce 256-bits of digest output, SHA1 does not

produce 1-bit of digest output, it produces 160-bits.  But we (802.11) do

truncate the output of SHA family hash functions. For instance, we sometimes

want only the first 128-bits of SHA1. Just to make things more complicated,

we also use the HMAC construct with a SHA family algorithm.

 

I agree with all of this, and 14/1104r1 does not contradict any of this.

 

   So how to deal with identifying the appropriate algorithm in the appropriate

family of SHA, whether it is alone or as HMAC, and how to identify the particular

output bit length that we are concerned with? 11-14/1104r1 does a poor job.

Let me propose a better way:

   * the particular algorithm of the family is used without any hyphens- for

      example, it's SHA256 not SHA-256, and it's SHA1 always.

 

I believe this violates FIPS PUB 180-3-2008, referred to in clause 2.

 

  I believe "violates" is the overstatement of the week! Congratulations.

 

  But if one can "violate" a FIPS by removing a hyphen from the algorithm name

why does 11-14/1104r1 violate this FIPS so egregiously? 

 

   * when we want to truncate we add a hyphen and indicate the bit length we

      want to use- for example, it's SHA256-128 (not sure why we'd do this but it's

      an example) or SHA1-128.

 

I'm fine with this.  One would have to fix the "SHA-256-128" at 2009.58

(in the "AP PeerKey protocol").

   * if we don't add a hyphen and number indicating truncation then the entire

      length of the algorithm output is used.

 

I'm fine with this, and 14/1104r1 does this.

 

   * if we want to use the HMAC construct we prepend "HMAC-" to the SHA family

      algorithm indicated, including any possible indication of truncation- for

      example, HMAC-SHA256 or HMAC-SHA1-128.

 

I'm fine with this, and 14/1104r1 does this.

 

  Well no it doesn't. And if you're fine with this then you're fine with "violating"

FIPS 180-3. It would help to converge on this matter if you would not simultaneously

oppose something using words that imply violence while also approving the use of

such violence later on.

 

 

   * if we don't prepend "HMAC-" then we are using the algorithm directly, and

      not as a keyed hash function.

 

I'm fine with this, and 14/1104r1 does this.

 

   While 11-14/1104r1 does this correct in some cases- it proposes to

change "HMAC-SHA-256" to "HMAC-SHA256"-- it does it wrong in other

cases- it proposes to change "SHA1" to "SHA-1".

 

SHA-1 is correct when it refers to the name of the hash, per

FIPS PUB 180-3-2008, referred to in clause 2.

 

I am fine with changing HMAC-SHA-1 to HMAC-SHA1, though as 11/1104r1

points out, HMAC-SHA-1 is the terminology used in RFC 2202,

referred to in Annex A (informative).

 

   Also, if we adopt this more correct way of referring to these various

incarnations of hashing we do not need to say something like

"Truncate-128(HMAC-SHA1(xxx))" we just say HMAC-SHA1-128(xxx)".

 

This change implies a significant difference, namely that

Truncate-128 requires irretrievable deletion of the bits beyond

bits 0-127, while HMAC-hash-128 does not.  I am not opposed to

requiring HMAC-hash-len to be specified as irretrievably deleting

extraneous bits, but this is a technical change beyond the scope

of 14/1104r1.

 

   Minor grammatical gripe: there is no such algorithm called

"HMAC-SHA1-64"

 

There are explicit references to "the HMAC-SHA1-64 hash algorithm"

at 958.64 and "HMAC-SHA1-64 hash algorithm" (missing article) at

1767.6.

, or even "HMAC-SHA-1-64" so we should not be using

the definite article when describing the use of SHA1 in an HMAC

construct while truncating the output to 64 bits.

 

Observe the use of the definite article before "HMAC-SHA1[-n]"

at 1932.38, 1935.37, 1941.62.  However, if it is felt that the

term should not be accompanied by an article, I fine with that.

 

  Good, let's get rid of it.

 

  Dan.

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

 

-----Original Message-----

From: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx] On Behalf Of Dan Harkins

Sent: 18 September 2014 10:14

Subject: [STDS-802-11] document 11-14/1104r1 for TGmc

--- This message came from the IEEE 802.11 Working Group Reflector ---

   Hello,

   I may not be at the 11mc session where 11-14/1104r1 is presented so I

want to get discussion on it started on the mailing list.

   There are some issues with the proposed description of various designations

of the Secure Hash Algorithm family of hash functions. In an effort to obtain

what the author views as "consistency" he has introduced ambiguity and,

in my opinion, incorrectness.

   There are 3 families of the Secure Hash Algorithm. There's the 1st family of

SHA, (which is just designated SHA1) and there's the 2nd family of SHA (known

as SHA2) which is SHA256 and SHA512, including truncated versions of each,

SHA224 is a truncated version of SHA256 and SHA384 is a truncated version of

SHA512. The 3rd family of SHA, SHA3 is a weird beast that we don't need to

trouble  ourselves with since we're not using it.

   It is important to understand, though, that SHA1, SHA256, and SHA512 are

different. They are not just truncated versions of the same function. And while

SHA256 does actually produce 256-bits of digest output, SHA1 does not

produce 1-bit of digest output, it produces 160-bits.  But we (802.11) do

truncate the output of SHA family hash functions. For instance, we sometimes

want only the first 128-bits of SHA1. Just to make things more complicated,

we also use the HMAC construct with a SHA family algorithm.

   So how to deal with identifying the appropriate algorithm in the appropriate

family of SHA, whether it is alone or as HMAC, and how to identify the particular

output bit length that we are concerned with? 11-14/1104r1 does a poor job.

Let me propose a better way:

   * the particular algorithm of the family is used without any hyphens- for

      example, it's SHA256 not SHA-256, and it's SHA1 always.

   * when we want to truncate we add a hyphen and indicate the bit length we

      want to use- for example, it's SHA256-128 (not sure why we'd do this but it's

      an example) or SHA1-128.

   * if we don't add a hyphen and number indicating truncation then the entire

      length of the algorithm output is used.

   * if we want to use the HMAC construct we prepend "HMAC-" to the SHA family

      algorithm indicated, including any possible indication of truncation- for

      example, HMAC-SHA256 or HMAC-SHA1-128.

   * if we don't prepend "HMAC-" then we are using the algorithm directly, and

      not as a keyed hash function.

   While 11-14/1104r1 does this correct in some cases- it proposes to

change "HMAC-SHA-256" to "HMAC-SHA256"-- it does it wrong in other

cases- it proposes to change "SHA1" to "SHA-1".

   Also, if we adopt this more correct way of referring to these various

incarnations of hashing we do not need to say something like

"Truncate-128(HMAC-SHA1(xxx))" we just say HMAC-SHA1-128(xxx)".

   Minor grammatical gripe: there is no such algorithm called

"HMAC-SHA1-64", or even "HMAC-SHA-1-64" so we should not be using

the definite article when describing the use of SHA1 in an HMAC

construct while truncating the output to 64 bits.

   Please modify 11-14/1104r1 to adopt this more correct terminology

before it gets adopted.

   regards,

   Dan.

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector

- it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the

LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-

11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html

_______________________________________________________________________________

 

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________