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:47 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

> > > The issue

> > > is we need a convention and we need to stick to it. Your submission does not do that.

 > > Please read 14/1104r1.

> Regarding terminology, it seems the hashes themselves are SHA-1, SHA-256 and SHA-384.  However, the HMACs which use the latter two should be (and > generally are) HMAC-SHAn[-len] to avoid confusion with the truncated HMACs.

>  No I saw the "Discussion" section. That's you discussing things with yourself. You

> say, "It seems OK though". Well guess what? It doesn't. Whatever conversation you

> have with yourself has no bearing on the matter.

 

Please do try to stick to the point.  You claimed (see text in red)

that my submission did not propose a convention (and stick to it).

Your claim is factually incorrect (see text in green).  Whether you

like the convention I proposed is quite beside the point.


  The convention I am referring to in the text that you have highlighted in red
is for the name of the hash, whether hyphens or not. You are proposing to use
both. That's not a convention, that's just stupid.

  What is really beside the point is the conversation you have with yourself.

  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 13:29
To: Mark Rison; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] document 11-14/1104r1 for TGmc

 

 

 

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

 

>  If you want to appeal to FIPS as the authority

 

I refer to FIPS as the authority since it is the authority to which the standard refers.

If you wish to refer to a different authority, please provide an alternate reference

to the hashes in question.

 

> and use SHA-256 then don't propose

> that the HMAC construct of SHA-256 be HMAC-SHA256 because according to the

> authority to which you are appealing there is no such thing as "SHA256".

 

Please read FIPS PUB 180-3.  You will find that the scope of that standard is

restricted to hash algorithms.  It does not cover HMACs.

 

  You do not know what you're talking about. There is no such things a "HMACs"

being distinct things from "hash algorithms".

 

> The issue

> is we need a convention and we need to stick to it. Your submission does not do that.

 

Please read 14/1104r1.  The bit you appear to have missed is the following, in the

"Discussion" section of the resolution of the relevant CIDs, which clearly sets out

the convention:

 

Regarding terminology, it seems the hashes themselves are SHA-1, SHA-256 and SHA-384.  However, the HMACs which use the latter two should be (and generally are) HMAC-SHAn[-len] to avoid confusion with the truncated HMACs.

 

  No I saw the "Discussion" section. That's you discussing things with yourself. You

say, "It seems OK though". Well guess what? It doesn't. Whatever conversation you

have with yourself has no bearing on the matter.

 

 

>  My convention is: [HMAC-]<ALG>[-xxx]

> where <ALG> is one of SHA1, SHA224, SHA256, SHA384, SHA512, or even SHA3 if

> and when we decide to incorporate that into our standard, and xxx is a number.

 

I had already understood that.

 

>  Your convention is both:  <ALG>[-xxx] and  HMAC-<HALG>[-xxx] 

> where ALG is one of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 and HALG

> is one of SHA1, SHA224, SHA384, SHA512.

 

That is correct (except that there are no instances of SHA-512* or HMAC-SHA512*).

 

> And that is ridiculous. 

 

Personally I think it is much less ridiculous than capriciously renaming the hashes

from what they are officially called in the document referenced by the standard.

 

  Well then stop capriciously renaming hashes!!! Just because you say "It seems

OK" does not make it so. 

 

>  If we want, we can use my convention with <ALG> being one of SHA-1,

> SHA-256, SHA-384, SHA-512 but if we're going to put hyphens in the

> middle of the algorithm names then we have to stick to it and not remove

> them when we use the HMAC construct of the algorithm.

>  Really Mark, I'm just trying to improve the standard.

 

Really, Dan, I'm just trying to improve the standard.

 

  Well you're failing in that regard then. You're proposing to add confusion.

 

  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:02
To: Mark Rison; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] document 11-14/1104r1 for TGmc

 

 

 

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

 

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

> I am confused in reading 11-14/1104r1 on these CIDs because it does not seem consistent in the naming.

> Is it supposed to be SHA1 or SHA-1 for example (as you note).

I think it is supposed to be "SHA-1".  Please note the following part of 14/1104r1, where I've added emphasis:

Regarding terminology, it seems the hashes themselves are SHA-1, SHA-256 and SHA-384.  However, the HMACs which use the latter two should be (and generally are) HMAC-SHAn[-len] to avoid confusion with the truncated HMACs.  It seems OK, though, to keep HMAC-SHA-1 since it seems harder to think the 1 might be a truncation length, and this aligns with the referenced RFC 2202 at 2619.48.

 

> So to help those of us that do not work with the security protocols daily, what is the appropriate names...can we safely say that it is supposed to be SHA1, SHA256, SHA128.



I don't think so.  There is a reference to FIPS PUB 180-3-2008 in the standard.  This is available at

http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf

and explicitly states near the beginning that "This Standard specifies five secure hash algorithms - SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512".

 

 

  If you want to appeal to FIPS as the authority and use SHA-256 then don't propose

that the HMAC construct of SHA-256 be HMAC-SHA256 because according to the

authority to which you are appealing there is no such thing as "SHA256". The issue

is we need a convention and we need to stick to it. Your submission does not do that.

 

  My convention is: [HMAC-]<ALG>[-xxx]

 

where <ALG> is one of SHA1, SHA224, SHA256, SHA384, SHA512, or even SHA3 if

and when we decide to incorporate that into our standard, and xxx is a number.

 

  Your convention is both:  <ALG>[-xxx] and  HMAC-<HALG>[-xxx] 

 

where ALG is one of SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 and HALG

is one of SHA1, SHA224, SHA384, SHA512. And that is ridiculous. 

 

  If we want, we can use my convention with <ALG> being one of SHA-1,

SHA-256, SHA-384, SHA-512 but if we're going to put hyphens in the

middle of the algorithm names then we have to stick to it and not remove

them when we use the HMAC construct of the algorithm.

 

  Really Mark, I'm just trying to improve the standard.

 

  Dan.

 

> Given the nominal names then I understand from your suggestion that the "-xxx" is then the amount to truncate to. (without the word truncate to prefix the name).

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: *** IEEE stds-802-11 List *** [mailto:STDS-802-11@xxxxxxxx] On Behalf Of Jon Rosdahl
Sent: 18 September 2014 11:02
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] document 11-14/1104r1 for TGmc

 

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

Hi Dan,

   As doc 11-14/1104r1 has a lot of CIDs, it took a bit of reading to find where your concern area was in the document.  (for those reading along it is I believe CID 3432, 3426, 3427, 3429).

I am confused in reading 11-14/1104r1 on these CIDs because it does not seem consistent in the naming.

Is it supposed to be SHA1 or SHA-1 for example (as you note).

So to help those of us that do not work with the security protocols daily, what is the appropriate names...can we safely say that it is supposed to be SHA1, SHA256, SHA128.

Given the nominal names then I understand from your suggestion that the "-xxx" is then the amount to truncate to. (without the word truncate to prefix the name).

The other parts that are noted as needing to be change you do not comment on.

Do we need to say "delete securely" in all cases or is "delete" sufficient.

does "destroy" imply "delete securely" and thus it is a valid term to use, and should be used when ever we mean "delete securely"

Thanks,
Jon

 


-----------------------------------------------------------------------------
Jon Rosdahl                    Senior Standards Architect
hm:801-756-1496             CSR Technologies Inc.
cell:801-376-6435            10871 North 5750 West
office: 801-492-4023         Highland, UT 84003

A Job is only necessary to eat!
A Family is necessary to be happy!!

 

On Thu, Sep 18, 2014 at 1:14 AM, Dan Harkins <dharkins@xxxxxxxxxxxxxxxxx> wrote:

--- 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 _______________________________________________________________________________

_______________________________________________________________________________

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 _______________________________________________________________________________