Re: [jose] Draft describing encrypting JWK key representations, with JWE

[Yaron Sheffer <[e-mail]>]

Hi Mike,

I understand your point, I believe. At the technical level, using PBKDF2 
for crypto keys simply does not buy you any security, but has a high 
cost in performance (the performance cost is after all the whole point 
of PBKDF2).

But the more important level is educational: I suggest that the document 
should make a very clear distinction between passwords and keys, so that 
implementors know what they're dealing with and the risks involved. 
Using password processing for keys would go against this goal.

Thanks,
	Yaron

On 03/15/2013 07:55 PM, Peck, Michael A wrote:
> I'll try to clarify (and hopefully not dig a deeper hole).
>
> JWE currently provides a "dir" mechanism allowing a symmetric key previously agreed to out of band to be used for content encryption.
> All of the other JWE mechanisms use a fresh symmetric key for each encryption.
>
> My suggestion was that instead of directly using the pre-shared symmetric key to encrypt content, if JWE makes the PBKDF2 mechanism available the symmetric key could be used as the PBKDF2 "password", resulting in a fresh key generated for each content encryption.  In this particular case the password input to PBKDF2 would hopefully be very random - I would think there would be no more risk than using the pre-shared key directly, rather less risk.
>
> General password considerations are a different matter.  Passwords have lots of issues but if we're stuck with them we should at least advise how to do the best we can.
>
> Mike
>
>> -----Original Message-----
>> From: Yaron Sheffer [mailto:[e-mail]]
>> Sent: Friday, March 15, 2013 1:42 PM
>> To: Peck, Michael A
>> Cc: Richard Barnes; Mike Jones; [e-mail]; [e-mail]
>> Subject: Re: [jose] Draft describing encrypting JWK key representations, with
>> JWE
>>
>> Hi Mike and Mike,
>>
>> The NIST SP is about using PBKDF2 for storage encryption (which I'm not
>> thrilled with, either). Not for sending the encrypted blob over the
>> wire, for an attacker to intercept and decrypt off-line. And if we read
>> the NIST document, let's adopt the whole thing - quoting from sec. A.1:
>> "Passwords shorter than 10 characters are usually considered to be
>> weak." Are we going to make this recommendation too? Well I guess not.
>>
>> *Please* do not mix passwords with cryptographic keys. If the WG goes
>> through the risk vs. benefit analysis and decides to have a
>> password-based mechanism, fine. But please leave the shared-key
>> mechanism as-is. It's important that readers of JOSE specs are very
>> clear about the difference between randomly generated keys and
>> user-memorable (or even -generated) passwords.
>>
>> Let's be clear: even a single use of a user-generated password for
>> on-the-wire encryption is risky. So-called key rotation of actual
>> cryptographic keys is a whole different matter.
>>
>> Thanks,
>> 	Yaron
>>
>>
>> On 03/15/2013 06:58 PM, Peck, Michael A wrote:
>>> +1
>>>
>>> NIST Special Publication 800-132 provides recommendations for the
>>> parameters that the group may find useful.
>>>
>>> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
>>>
>>> It may also be worth thinking about using PBKDF2 instead of the "dir"
>>> (Direct Encryption with a Shared Symmetric Key) mechanism described in
>>> draft-ietf-jose-json-web-algorithms-08 section 4.6.  The shared
>>> symmetric key would be used as the PBKDF2 "password", and this would
>>> force a new key to be used for each encryption, rather than the current
>>> "dir" approach of using the same encryption key repeatedly.
>>>
>>> Mike
>>>
>>> *From:*[e-mail] [mailto:[e-mail]] *On Behalf
>>> Of *Richard Barnes
>>> *Sent:* Friday, March 15, 2013 12:53 PM
>>> *To:* Mike Jones
>>> *Cc:* Yaron Sheffer; [e-mail]; [e-mail]
>>> *Subject:* Re: [jose] Draft describing encrypting JWK key
>>> representations, with JWE
>>>
>>> Do I count as an expert?  :)
>>>
>>> As I understand it, PBDKF2 is completely fine for key protection.
>>>    PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g.,
>>> having a high number of iterations. We might want to make some
>>> recommendations as to how you set those parameters. And the actual key
>>> wrapping is done with something like AES-KW, so that step is fine.
>>>
>>> So I would be completely fine with adding this to JWE / JWA.  We should
>>> do this.
>>>
>>> --Richard
>>>
>>> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones
>>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>>
>>> That's up to the working group.  I'm actually hoping that experts on the
>>> lists will respond to Yaron's comments before we make a decision on
>>> whether PBKDF2 as specified is an appropriate key wrapping algorithm or
>> not.
>>>
>>> Assuming that the content in Matt's draft eventually becomes an RFC or
>>> part of one, the PBKDF2 definition would end up in the algorithms
>>> registry either way, even if it's not part of the JWA spec itself.
>>>
>>>                                                               Cheers,
>>>
>>>                                                               -- Mike
>>>
>>> *From:*[e-mail] <mailto:[e-mail]>
>>> [mailto:[e-mail] <mailto:[e-mail]>] *On
>> Behalf
>>> Of *Richard Barnes
>>> *Sent:* Friday, March 15, 2013 9:43 AM
>>> *To:* Mike Jones
>>> *Cc:* Yaron Sheffer; [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>
>>> *Subject:* Re: [jose] Draft describing encrypting JWK key
>>> representations, with JWE
>>>
>>> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key
>>> wrapping algorithm?
>>>
>>> --Richard
>>>
>>> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones
>>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
>>>
>>> [Adding JOSE mailing list to the thread]
>>>
>>> For clarification, PBKDF2 is not the only algorithm that could be used
>>> to wrap keys in this scheme.  This draft *adds* PBKDF2 to the set of
>>> algorithms already specified for use with encryption in the JSON Web
>>> Algorithms (JWA) specification
>>> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08).  In
>>> particular, other algorithms such as AES Key Wrap and AES GCM are also
>>> present there.
>>>
>>> I'll let others who are experts in PBKDF2 and password-based encryption
>>> respond to Yaron's specific comment.
>>>
>>>                                   -- Mike
>>>
>>> -----Original Message-----
>>> From: Yaron Sheffer [mailto:[e-mail]
>>> <mailto:[e-mail]>]
>>> Sent: Friday, March 15, 2013 8:16 AM
>>> To: [e-mail] <mailto:[e-mail]>; Mike Jones
>>> Subject: Re: Draft describing encrypting JWK key representations, with JWE
>>>
>>> Hi Mike,
>>>
>>> I'm probably missing something, but I'm worried about the security of
>>> this scheme (though I do appreciate the usability/convenience of
>> passwords).
>>>
>>> PBKDF2 is meant to make dictionary attacks on stored passwords harder,
>>> as a second line defense, once the server has been breached. Using it to
>>> encrypt data and then sending the data on the wire, makes the data
>>> vulnerable to this same dictionary attack (in this case the effort comes
>>> to the space of all possible passwords - say 1 million - times 1000).
>>> Moreover, this also puts the password itself in danger.
>>>
>>> Thanks,
>>>           Yaron
>>>
>>>   >
>>>   > ------------------------------
>>>   >
>>>   > Message: 5
>>>   > Date: Fri, 15 Mar 2013 14:10:32 +0000
>>>   > From: Mike Jones <[e-mail]
>>> <mailto:[e-mail]>>
>>>   > To: "[e-mail] <mailto:[e-mail]>" <[e-mail]
>>> <mailto:[e-mail]>>
>>>   > Subject: [Cfrg] Draft describing encrypting JWK key representations
>>>   >       with JWE
>>>   > Message-ID:
>>>   >
>>>   >
>> <[e-mail]
>> d.corp.
>>>
>> <mailto:4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.r
>> edmond.corp.%0b>>
>>> microsoft.com <http://microsoft.com>>
>>>   >
>>>   > Content-Type: text/plain; charset="us-ascii"
>>>   >
>>>   > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>>>   >
>>>   > This also adds password-based encryption to the algorithm registry.
>>>   >
>>>   >                                                              -- Mike
>>>   >
>>>   > -------------- next part -------------- An HTML attachment was
>>>   > scrubbed...
>>>   > URL:
>>>   > <http://www.irtf.org/mail-
>> archive/web/cfrg/attachments/20130315/02e36b
>>>   > 24/attachment.htm>
>>>   >
>>>   > ------------------------------
>>>   >
>>>   > _______________________________________________
>>>   > Cfrg mailing list
>>>   > [e-mail] <mailto:[e-mail]>
>>>   > http://www.irtf.org/mailman/listinfo/cfrg
>>>   >
>>>   >
>>>   > End of Cfrg Digest, Vol 95, Issue 3
>>>   > ***********************************
>>>   >
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/jose
>>>