Subject: [dane] Digest identifiers in -registry-acronyms-02

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 16:29:39 -0500

(Sorry if this has already been raised, but...)

The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a
little silly, in that nobody else in the world really seems to care that
these are variants of SHA2.  The standard practice across many libraries is
to just use some variant of "SHA-XXX", where XXX=256,384,512.

OpenSSL: shaXXX
WebCrypto: SHA-XXX
BouncyCastle: SHAXXXDigest
CNG: BCRYPT_SHAXXX_ALGORITHM
PKCS#11: CKM_SHAXXX

So I would suggest we just change these to "SHA-256" and "SHA-512".

--Richard

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Dec 2013 16:34:31 -0500

On Dec 10, 2013, at 4:29 PM, Richard Barnes <[email-masked]> wrote:

> (Sorry if this has already been raised, but…)
> 
> The digest identifiers in draft-ietf-dane-registry-acronyms-02 seem a little silly, in that nobody else in the world really seems to care that these are variants of SHA2.  The standard practice across many libraries is to just use some variant of "SHA-XXX", where XXX=256,384,512.
> 

Richard, 

First version had this but an comment was made that we could have both SHA2  and SHA3 in 512 bit variant thus the recommendation 
was to future proof us. 

> So I would suggest we just change these to "SHA-256" and "SHA-512".

Unless the chair's tell me to make the change it will not be made, 
feel free to bring this up in the IETF LC if you think this is important. 

	Olafur

> 
> --Richard
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 17:18:29 -0500

Fair enough, I guess.  But all of these libraries already have algorithm
IDs for SHA256/SHA512, so some new convention is going to have to come for
SHA3/512.

I can just see the administrators saying "Damn, I forgot the '2' again!"

On Tue, Dec 10, 2013 at 4:34 PM, Olafur Gudmundsson <[email-masked]> wrote:

> First version had this but an comment was made that we could have both
> SHA2  and SHA3 in 512 bit variant thus the recommendation
> was to future proof us.
>
> > OpenSSL: shaXXX
> > WebCrypto: SHA-XXX

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Dec 2013 22:47:33 +0000

> So I would suggest we just change these to "SHA-256" and "SHA-512".

It is not possible to find digest names that universally match
prior practice.  So likely any recognizable non-confusing names
are sufficient.

For example in OpenSSL the names are:

    #define SN_sha256               "SHA256"
    #define LN_sha256               "sha256"

with no hyphens at all.  So, perhaps surprisingly, I have
no objects to the digest names, it is clear what they mean,
and no single choice matches established practice.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Wed, 11 Dec 2013 01:05:18 +0100 (CET)

> to just use some variant of "SHA-XXX", where XXX=256,384,512.

while sha224, sha256, sha384 and sha512 are members of the SHA2-Family,
they're not all the same algorithm, they use two seperate algorithms.

sha256 + sha224  use the same 32-bit algorithm
(different internal start value, output truncation for sha224)

   http://tools.ietf.org/html/rfc6234#section-5.1

sha512 + sha384  use the same 64-bit algorithm
(different internal start value, output truncation for sha384)

   http://tools.ietf.org/html/rfc6234#section-5.2

> So I would suggest we just change these to "SHA-256" and "SHA-512".

In theory, reusing (or copying) an existing IANA registry would
be preferable to inventing yet another different variant.

Unfortunately, it seems that all variants already exist...

  TLS:      http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18

    0 	none 	Y 	[RFC5246]
    1 	md5 	Y 	[RFC5246]
    2 	sha1 	Y 	[RFC5246]
    3 	sha224 	Y 	[RFC5246]
    4 	sha256 	Y 	[RFC5246]
    5 	sha384 	Y 	[RFC5246]
    6 	sha512 	Y 	[RFC5246]

  PKIX/CMS: http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml

    "md2" 	1.2.840.113549.2.2 	[RFC3279]
    "md5" 	1.2.840.113549.2.5 	[RFC3279]
    "sha-1" 	1.3.14.3.2.26 	[RFC3279]
    "sha-224" 	2.16.840.1.101.3.4.2.4 	[RFC4055]
    "sha-256" 	2.16.840.1.101.3.4.2.1 	[RFC4055]
    "sha-384" 	2.16.840.1.101.3.4.2.2 	[RFC4055]
    "sha-512" 	2.16.840.1.101.3.4.2.3 	[RFC4055]

  IPSEC:    http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-6

    1 	MD5 	[RFC1321]
    2 	SHA 	[NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.]
    3 	Tiger 	[Anderson, R., and Biham, E., "Fast Software Encryption", Springer LNCS v. 1039, 1996.]
    4 	SHA2-256 	[Marcus_Leech][RFC4868]
    5 	SHA2-384 	[Marcus_Leech][RFC4868]
    6 	SHA2-512 	[Marcus_Leech][RFC4868]

  DKIM:     http://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml#dkim-parameters-7

    sha1 	[FIPS-180-3-2008] 	active
    sha256 	[FIPS-180-3-2008] 	active

  DNSSEC/NSEC3:  http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3

    0 	Reserved 	[RFC5155]
    1 	SHA-1 		[RFC5155]

  DNSSEC:    http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

  Number  Description    Mnemonic
    5 	RSA/SHA-1 	RSASHA1 	Y  Y 	[RFC3110][RFC4034]
    6 	DSA-NSEC3-SHA1 	DSA-NSEC3-SHA1 	Y  Y 	[RFC5155][proposed standard]
    8 	RSA/SHA-256 	RSASHA256 	Y  * 	[RFC5702][proposed standard]
    9 	Reserved 				[RFC6725]
    10 	RSA/SHA-512 	RSASHA512 	Y  * 	[RFC5702][proposed standard]

RFC 4634 / 6234  http://tools.ietf.org/html/rfc6234#page-3

    4.1. SHA-224 and SHA-256
    4.2. SHA-384 and SHA-512

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 Dec 2013 15:13:51 -0500 (EST)

>    6 	SHA2-512 	[Marcus_Leech][RFC4868]

Awesome. IPsec is the only registry that did it right[1] :)

Paul
[1] Apart from the 1 missing in SHA1