RE: [jose] Platform Support for JWA Crypto Algorithms

My pain for the missing support for concat-kdf in Firefox/NSS has vanished in the meantime.
So I could happily live with the current spec.

Maybe the examples could be improved by saying something like:
"In the case of A128CBC+HS256 the loop in concat-kdf collapses into one iteration.

CEK

  = sha256(0,0,0,1,CMK, 0, 0, 0, 128, 65, 49, 50, 56, 67, 66, 67, 43,

   72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-127]

  = [37, 245, 125, 247, 113, 155, 238, 98, 228, 206, 62, 65, 81, 153, 79, 91]

CIK

  = sha256(0,0,0,1,CMK, 0, 0, 1, 0, 65, 49, 50, 56, 67, 66, 67, 43,

   72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255]

  = [203, 194, 197, 180, 120, 46, 123, 202, 78, 12, 33, 116, 214, 247,

     128, 41, 175, 53, 181, 164, 224, 223, 56, 146, 179, 193, 18, 223,

     146, 85, 244, 127]
"

Maybe even have this paragraph in JWA where JWA references to the example appendices in JWE?
Such a sentence would prevent implementers thinking they have to implement the full concat-kdf if they only want to support some encryption algorithms.

I agree that we should not easily break the current implementations. It is good that the concat-kdf collapses to one iteration for the examples which are relevant for current and future implementations of encryption algorithms. That simplifies the implementation. I still think that implementing it in NSS with multiple iterations will be hard because the digest engine is reset when finish is called (says the documentation. Have not tried it).

I am unsure about the optional PartyUInfo/PartyVInfo. Sounds like optional values lead to interop problems.

Axel



From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, November 01, 2012 11:04 AM
To: Axel Nennker; Ryan Sleevi
Cc: Wan-Teh Chang; Nennker, Axel; <public-webcrypto@w3.org>
Subject: RE: [jose] Platform Support for JWA Crypto Algorithms

To be clear, the working group decided to delete the separate "kdf" field (and the separate "int" field) and only specify any needed KDF (and integrity) algorithms as part of composite algorithms (when needed).  So the algorithms "A128CBC+HS256" and "A256CBC+HS512" also specify the KDF to be used when generating the CEK and CIK from CMK, but for algorithms where separate keys aren't needed, such as "A128GCM", this issue doesn't come up.  This change is already in the -06 drafts.

The fact that PBKDF2 might be implemented in some platforms doesn't help interop at all if it's hard to implement on the platforms where it isn't.  On those platforms, the question would be "how hard is it to implement this required functionality without platform support"?  For an apples-to-apples comparison, it would be useful to have the equivalent of these Appendices  http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5 showing how to implement PBKDF2 without platform support for it.  Do you want to produce alternative appendices showing how to implement and use PBKDF2 without platform support, Axel?  That would let us actually do an apples-to-apples comparison of the choices.

BTW, the security reasons for including parameters such as the algorithm identifier, the output length, and optional PartyUInfo and PartyVInfo values in the KDF calculation would also apply to KDF algorithms other than Concat.  (We would likely want to include them as inputs to PBKDF2 as well, for instance.)  Changing KDFs probably wouldn't change the nature of the inputs we would want to provide to the calculation.

BTW, just as an efficiency observation, any algorithm that includes steps like "iterate 1000 times" doesn't seem like it could possibly be as efficient as Concat, for which there are no iterations at all in our use case.

Axel, please don't read my messages as saying that I'm not open to alternatives - I am.  But I also want to make sure that any alternatives considered would actually improve interoperability and efficiency while providing equivalent security.  I don't think that PBKDF2 meets the bar in that regard, for the reasons described above.

                                                            Cheers,
                                                            -- Mike

From: Axel Nennker [mailto:ignisvulpis@gmail.com]
Sent: Thursday, November 01, 2012 2:00 AM
To: Ryan Sleevi
Cc: Wan-Teh Chang; Mike Jones; Axel Nennker; <public-webcrypto@w3.org>
Subject: Re: [jose] Platform Support for JWA Crypto Algorithms

Could you please elaborate on "different security properties"? This might help the group to get to a more informed consensus later.

In the past the group did not care much for "future" implementations. For example we have RSA1_5 while we agree that RSAOAEP is superior. RSA1_5 is implemented now on many platforms while RSAOAEP might be in the future.

My impression is that PBKDF2 is the most widely implemented KDF. My impression is that PBKDF2 will only get better if we use it with a randomly generated "password". It might make sense to use the base64-encoded CMK as the password because not all implementation might be happy with null-bytes in the password. The key to security here is  the randomness of the input. My impression is that an iteration-count of 1000 was recommended because the password is generally not very random. In JWE we have a randomly generated password with 32 bytes length, that should get us a "good" CIK/CEK when using PBKDF2.

Given that we already have implementations using a variant of concat-kdf we might agree to have a value for the jwe header field "kdf" that specifies the current "JWE-v6" kdf.
The question is what is the default when there is not kdf field.

Regarding whether the jwe-concat-kdf is really the NIST concat kdf: I think that the requirement to have sender and receiver encoded in otherInfo does not work easily in the general JWE case.
In openid connect we might need to use client_id and audience if we want to claim NIST compliance...

Overall I think that we have good security properties in all variants of KDFs if the CMK is as random as possible.



2012/10/31 Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>>
I don't think it's a fair contrast. Historically, KDFs have generally been about the combination of low-level primitives in "acceptable" forms, rather than being considered a low-level primitive themselves. That is, they are, at best, high-level syntactic sugar.

The blessing by NIST (finally!) actually provides incentive and benefit for cryptographic libraries, particularly those concerned with FIPS 140-2/defined security boundaries, to treat the KDFs as low-level primitives. The ones most likely to be implemented are thus the ones recommended by NIST (since NIST cares about such things), and so the best hope for *future* implementations (which will eventually exist) is to use HKDF/Concat.

If you're talking about "how easy is it for an application developer to implement", PBKDF2/HKDF/Concat are more or less the same. But they have different security properties, and like Mike said, the latter algorithms make more sense (albiet with the need to address the various oddities with how JOSE currently incorrectly uses Concat)

On Wed, Oct 31, 2012 at 2:15 PM, Axel Nennker <ignisvulpis@gmail.com<mailto:ignisvulpis@gmail.com>> wrote:
I think we need a table with the same platform as in Mike's table that started this discussion with KDFs that actually have implementations.
Specification in RFCs or blessing by NIST does not count. Implementations rule.
Usage

Param Name

Param Val

Description

.NET

Windows native

OS X

iOS

Java JCA

BouncyCastle

Android

PHP

PHPSecLib

Python

M2Crypto

PyCrypto

Ruby

OpenSSL

node.js

NSS


JWE

kdf

CS256

Concat Key Derivation Function (KDF)

NO

Win7





NO

NO

NO

NO

NO

NO

NO

NO



NO

NO

NO

JWE

kdf

CS384

Concat Key Derivation Function (KDF)

NO

Win7





NO

NO

NO

NO

NO

NO

NO

NO



NO

NO

NO

JWE

kdf

CS512

Concat Key Derivation Function (KDF)

NO

Win7





NO

NO

NO

NO

NO

NO

NO

NO



NO

NO

NO


Axel
2012/10/31 Wan-Teh Chang <wtc@google.com<mailto:wtc@google.com>>
On Mon, Oct 29, 2012 at 4:23 PM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
>
> However, as an NSS developer, I do not see your presented argument as a
> reason not to use Concat-KDF, and Concat-KDF would be more preferable, as a
> NIST-blessed KDF, since NSS cares especially for NIST-blessed algorithms.

I think HKDF (hash-based key derivation function) is also worth considering.
It is specified in RFC 5869 and is also blessed by NIST in SP 800-56C.

Wan-Teh
_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose