Re: [STDS-802-11] document 11-14/1104r1 for TGmc
--- This message came from the IEEE 802.11 Working Group Reflector ---
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
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf ,
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).
> 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.
> * 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.
> * 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.
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
> To: STDS-802-11@xxxxxxxxxxxxxxxxx
> 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
_______________________________________________________________________________