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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Mar 2013 17:15:30 +0200

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 <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [Cfrg] Draft describing encrypting JWK key representations
> 	with JWE
> Message-ID:
> 	<[email-masked]>
> 	
> 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/02e36b24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Mar 2013 16:14:48 +0000

[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:[email-masked]] 
Sent: Friday, March 15, 2013 8:16 AM
To: [email-masked]; 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

> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL: 
> <http://www.irtf.org/mail-archive/web/cfrg/attachments/20130315/02e36b
> 24/attachment.htm>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Mar 2013 16:48:50 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
[Adding JOSE mailing list to the thread]

                                -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 15, 2013 8:16 AM
To: [email-masked]<mailto:[email-masked]>; Mike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE

Hi Mike,

Thanks,
        Yaron

> From: Mike Jones <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> <[email-masked].
<mailto:[email-masked].%0b>> microsoft.com<http://microsoft.com>>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Mar 2013 19:42:18 +0200

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:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, March 15, 2013 12:53 PM
> *To:* Mike Jones
> *Cc:* Yaron Sheffer; [email-masked]; [email-masked]
> *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
> <[email-masked] <mailto:[email-masked]>> 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:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf
> Of *Richard Barnes
> *Sent:* Friday, March 15, 2013 9:43 AM
> *To:* Mike Jones
> *Cc:* Yaron Sheffer; [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [jose] Draft describing encrypting JWK key
> representations, with JWE
>
> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> 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.
>
> To: [email-masked] <mailto:[email-masked]>; Mike Jones
>  > To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> <mailto:[email-masked].%0b>>
> microsoft.com <http://microsoft.com>>
>  >
>  > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Peck, Michael A" <[email-masked]>
Date: Fri, 15 Mar 2013 17:55:45 +0000

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

>Sent: Friday, March 15, 2013 1:42 PM
>To: Peck, Michael A
>Cc: Richard Barnes; Mike Jones; [email-masked]; [email-masked]
>> It may also be worth thinking about using PBKDF2 instead of the "dir"
>> symmetric key would be used as the PBKDF2 "password", and this would
>> "dir" approach of using the same encryption key repeatedly.
>>
>> Mike
>>
>> 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
>> Assuming that the content in Matt's draft eventually becomes an RFC or
>> registry either way, even if it's not part of the JWA spec itself.
>>
>>                                                              Cheers,
>>
>>                                                              -- Mike
>>
>>  > <http://www.irtf.org/mail-
>archive/web/cfrg/attachments/20130315/02e36b
>>  > 24/attachment.htm>
>>  >

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Mar 2013 20:20:31 +0200

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

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 15 Mar 2013 14:36:07 -0400

Use PBKDF2 as a general key wrap mechanism seems to be a bad idea.  Take the
key and use it as a key wrap key for randomly generated content encryption
key.  Thus alg should be "AES128KW" rather than direct.

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peck, Michael A
Sent: Friday, March 15, 2013 12:59 PM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; [email-masked]; [email-masked]
Subject: Re: [jose] Draft describing encrypting JWK key representations,
with JWE

+1

NIST Special Publication 800-132 provides recommendations for the parameters
that the group may find useful.

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Friday, March 15, 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; [email-masked]; [email-masked]
Subject: Re: [jose] Draft describing encrypting JWK key representations,
with JWE

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 <[email-masked]>
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; [email-masked]; [email-masked]
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 <[email-masked]>
wrote:

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:[email-masked]]
Sent: Friday, March 15, 2013 8:16 AM
To: [email-masked]; 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

<mailto:[email-masked]
.%0b> 
> microsoft.com>
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 Mar 2013 21:45:30 +0200

no way to generate a strong key in JavaScript. So you also need a way to use a key directly. But I'm by no means a JOSE expert, they may have different assumptions. 

Thanks, Yaron 

Jim Schaad <ietf@augus

Jim Schaad <[email-masked]> wrote:

>symmetric
>PBKDF2
>do
><[email-masked]>
>wrote:
>
>whether
>part
><[email-masked]>
>wrote:
>
>to
>this
>as a

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 16 Mar 2013 14:24:53 +0200

Well I guess that's for me. So here goes:

Despite the protections afforded by PBKDF2 and PBES2, password-protected 
data is still subject to off-line dictionary attacks, when using 
human-generated passwords. The same applies to machine generated 
passwords, if they need to be memorable to humans.

Such dictionary attacks reveal both the data and the password to an 
eavesdropper. Therefore:

- Password-based encryption should not be used for high value data.
- Password-based encryption should not be used with high-value 
passwords, e.g. with a user's long-term password.

Thanks,
	Yaron

On 03/15/2013 09:47 PM, Matt Miller (mamille2) wrote:
> My intent for introducing PBES2 key wrapping algorithms was for those times when the key exchange is at the human-level.  I think there are probably better mechanisms when the input in appropriately random to start with, although I personally don't see a tremendous amount of harm using a PBES2-based algorithm with stronger "passwords".
>
> I tried to address some concerns around the use of passwords, but did rely on what RFC2898 already says about specific values for iteration counts and salts.  I'd be happy to incorporate more direction there, if someone could help provide some text.  I'd also be happy to help incorporate this into whatever other document we'd rather have it in.
>
>
> - m&m
>
> Matt Miller < [email-masked] >
> Cisco Systems, Inc.
>
> On Mar 15, 2013, at 1:55 PM, "Peck, Michael A" <[email-masked]>
>   wrote:
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 16 Mar 2013 22:56:43 +0200

Hi Ryan,

Yes, the complete first sentence in my mail (which the listserv gobbled) 
was: "prior to the new Webcrypto API there's no way to generate a strong 
key in JavaScript." Do the JOSE specs assume this API is always available?

Thanks,
      Yaron

On 16.3.2013 22:14, Ryan Sleevi wrote:
> On Fri, March 15, 2013 12:45 pm, Yaron Sheffer wrote:
>>   no way to generate a strong key in JavaScript. So you also need a way to
>>   use a key directly. But I'm by no means a JOSE expert, they may have
>>   different assumptions.
>>
>>   Thanks, Yaron
> window.crypto.getRandomValues() ?
>
> Already implemented today by WebKit and Firefox, as part of the W3C Web
> Cryptography API -
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
>