Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows

From: Mike Jones <[email-masked]>
Date: Tue, 19 Mar 2013 03:23:37 +0000

Since you message appears to take it as given that “there should be only one way of encrypting keys”, I’ll point out that I don’t think that it’s reasonable to assume that.  JOSE is first and foremost an engineering exercise, where the cost/benefit generality/complexity tradeoffs matter, and the goal is a ubiquitously implemented crypto format for the Web that solves the problems that people actually have, rather than a mathematical exercise, where the goal is completeness and generality.  Complexity is the enemy of adoption.

So it’s fair game to ask “What are the costs and benefits of having only one way to encrypt keys”, versus taking that as a given.

I happen to personally believe that encrypting a bare symmetric ephemeral Content Master Key is sufficiently different than encrypting a key that may be public, private, or symmetric and may have additional attributes, that it’s at least worth asking the engineering question whether special-casing the encryption of this bare symmetric ephemeral key results in engineering benefits.

Encrypting a key with attributes for storage or dissemination is not the same kind of operation as wrapping an ephemeral symmetric key to be used for block encryption.  I’m personally fine with this being done differently.  The engineering benefit if we do it differently in the way that Matt’s draft proposed, at least as I see it, is that we have to invent nothing new.  We already have a great format for encrypting arbitrary data, and keys with attributes are a whole lot like arbitrary data.

I respect that some with disagree with my personal view, but I’d also ask you to respect that the engineering tradeoffs may favor having two ways to do things that on the surface may seem similar, but are actually fairly different in nature.

Best wishes,
-- Mike

From: Richard Barnes
Sent: ‎March‎ ‎18‎, ‎2013 ‎7‎:‎36‎ ‎PM
To: Jim Schaad
CC: Manger, James H, [email-masked]
Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows

Well, I got to 788 by doing math incorrectly*.

Mike was correct on the other thread that 768 is the right number.  However, that's still too big for a 1024-bit RSA key and SHA1, since 768 + 320 = 1088 > 1024.

Regardless, there is clearly an issue here when wrapping a JWK, which is much larger, possibly containing an RSA key itself.  So if we accept the goal that there should be one way of encrypting keys, then we'll need to deal with getting around the OAEP size limitations.

--Richard

* This is why my degree is in mathematics, and not accounting.

On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:
Think in terms of encrypting a JWK directly not an intermediate key.

> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Manger, James H
> Sent: Monday, March 18, 2013 5:17 PM
> To: [email-masked]; [email-masked]<mailto:[email-masked]>
> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows
>
> Richard,
>
> How do you get a 788-bit key length?
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The total key lengths range from 256
> bits to 512 bits.
>
> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key.
>
> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key.
JWA
> already says RSA key sizes MUST be at least 2048 bits.
>
> This already looks sufficient.
>
> --
> James Manger
>
>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> > Of Richard Barnes
> > Sent: Tuesday, 19 March 2013 10:25 AM
> > Subject: [jose] WebCrypto feedback on key wrapping
> >
> > 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt
wrapped
> key objects, then we would need something other than OAEP in order to
carry
> arbitrary-length payloads.  I agreed, and suggested that something like
RSA-
> KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM
is
> troublesome due to the lack of support by native crypto libraries.
> >
> > Point number 2 likely applies for some scenarios of JWE, especially if
we
> adopt the McGrew approach.  For example, if using HMAC-SHA1 and AES with
> a 256-bit key, the total key length is 788 bits, which is too long to be
encrypted
> with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The
best
> idea I've got is to allow wrapped keys to nest, so that you can wrap a key
inside
> of another wrapped key.
> >
> > --Richard
>
>
> >> ----------
> >> Sent: Tuesday, 19 March 2013 10:23 AM
> >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows
> >>
> >> #14: Support longer wrapped keys than OAEP allows
> >>
> >>  The use of RSA-OAEP for key wrapping imposes a limit on the length
> >> of  the key package being wrapped. With SHA1, this length is N-320,
> >> where  N is the length of the RSA modulus.  Especially with larger
> >> hash  functions, and especially for wrapping private keys, the size
> >> of key  packages will be larger than this bound.  We should
> >> incorporate a  mechanism to accommodate these situations.
> >>
> >>
> >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14>
> _______________________________________________
> jose mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose

---

From: Richard Barnes <[email-masked]>
Date: Tue, 19 Mar 2013 09:55:27 -0400

I agree that it's a fair question to ask.  As I'm writing this key wrapping
document (as requested in Orlando), I'm trying to develop a comparison of
the costs of various wrapping schemes.

It would be interesting to get feedback on the group as to how you would
measure cost in this case?  For example:
-- Which algorithms can/cannot be supported
-- How large the encrypted object is
-- How many encryption formats a JOSE library has to support

On the latter point, the request to use GCM for key wrapping has gotten me
thinking that perhaps we should just make JWE self-similar, by using a JWE
to wrap the key for a JWE*.  That would reduce the number of encryption
code paths from two (JWE, key wrapping) to one (JWE).  Again, I'll try to
make a concrete proposal in the forthcoming document.

--Richard

On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones <[email-masked]>wrote:

>  Since you message appears to take it as given that “there should be only
> one way of encrypting keys”, I’ll point out that I don’t think that it’s
> reasonable to assume that.  JOSE is first and foremost an engineering
> exercise, where the cost/benefit generality/complexity tradeoffs matter,
> and the goal is a ubiquitously implemented crypto format for the Web that
> solves the problems that people actually have, rather than a mathematical
> exercise, where the goal is completeness and generality.  Complexity is the
> enemy of adoption.
>
> So it’s fair game to ask “What are the costs and benefits of having only
> one way to encrypt keys”, versus taking that as a given.
>
> I happen to personally believe that encrypting a bare symmetric
> ephemeral Content Master Key is sufficiently different than encrypting a
> key that may be public, private, or symmetric and may have additional
> attributes, that it’s at least worth asking the engineering question
> whether special-casing the encryption of this bare symmetric ephemeral key
> results in engineering benefits.
>
> Encrypting a key with attributes for storage or dissemination is not the
> same kind of operation as wrapping an ephemeral symmetric key to be used
> for block encryption.  I’m personally fine with this being done
> differently.  The engineering benefit if we do it differently in the way
> that Matt’s draft proposed, at least as I see it, is that we have to invent
> nothing new.  We already have a great format for encrypting arbitrary data,
> and keys with attributes are a whole lot like arbitrary data.
>
> I respect that some with disagree with my personal view, but I’d also ask
> you to respect that the engineering tradeoffs may favor having two ways to
> do things that on the surface may seem similar, but are actually fairly
> different in nature.
>
> Best wishes,
> -- Mike
>
>  *From:* Richard Barnes
> *Sent:* March 18, 2013 7:36 PM
> *To:* Jim Schaad
> *CC:* Manger, James H, [email-masked]
>
> *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows
>
>  Mike was correct on the other thread that 768 is the right number.
>  However, that's still too big for a 1024-bit RSA key and SHA1, since 768 +
> 320 = 1088 > 1024.
>
>  Regardless, there is clearly an issue here when wrapping a JWK, which is
> much larger, possibly containing an RSA key itself.  So if we accept the
> goal that there should be one way of encrypting keys, then we'll need to
> deal with getting around the OAEP size limitations.
>
>  --Richard
>
> On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[email-masked]>wrote:
>
>> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>  > Manger, James H
>> > To: [email-masked]; [email-masked]
>> > > From: [email-masked] [mailto:[email-masked]] On Behalf
>> > > Of Richard Barnes
>> > [email-masked]

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Mar 2013 14:02:37 +0000

Personally, I don't think it's worth discussing this much further without a more complete counter-proposal on the table.  As I said in the meeting, I can see the desire for "on true way" from an architectural purity standpoint, but pragmatically I mostly agree with Mike.

While some might say "keys are keys are keys", I do think the context that a key is used is an important consideration.  Now, does JWE as it exists right now have an important enough differentiation in context to warrant special consideration?  I'm leaning toward "yes", if one also assumes that the key associated with a JWE is transient (which I think is a desirable property here).

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 19 Mar 2013 08:16:37 -0700

<personal>

The issue has been raised for discussion.  I do not believe that documenting what the extents of the issue are is out of scope of any and all follow on discussion.  Until that has been done it is not possible to talk about what the costs and benefits are.  If you have a full set of costs and benefits that would be an interesting message to see.

From: Mike Jones [mailto:[email-masked]] 
Sent: Monday, March 18, 2013 8:24 PM
To: Jim Schaad; Richard Barnes
Cc: James H Manger; [email-masked]
Subject: RE: [jose] #14: Support longer wrapped keys than OAEP allows

Best wishes,

-- Mike

From: Richard Barnes

--Richard

On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[email-masked]> wrote:

JWA
wrapped
carry
RSA-
is
we
encrypted
best
inside

---

From: Mike Jones <[email-masked]>
Date: Tue, 19 Mar 2013 16:32:34 +0000

I completely agree that documenting the engineering tradeoffs is in scope and a worthwhile exercise.  The point of my message was simply that we needn’t “accept the goal that there should be one way of encrypting keys” without doing this analysis.

I think Matt Miller had it right when he wrote this morning “Personally, I don't think it's worth discussing this much further without a more complete counter-proposal on the table”.  Should a concrete counter-proposal to Matt’s draft be written, at that point we could have a much more concrete discussion.

                                                                Cheers,
                                                                -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Tuesday, March 19, 2013 8:17 AM
To: Mike Jones; 'Richard Barnes'
Cc: 'James H Manger'; [email-masked]
Subject: RE: [jose] #14: Support longer wrapped keys than OAEP allows

<personal>

Cc: James H Manger; [email-masked]<mailto:[email-masked]>

Best wishes,
-- Mike

From: Richard Barnes
Sent: ‎March‎ ‎18‎, ‎2013 ‎7‎:‎36‎ ‎PM
To: Jim Schaad
CC: Manger, James H, [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows

--Richard

> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
JWA
wrapped
carry
RSA-
is
we
encrypted
best
inside

---

From: Axel Nennker <[email-masked]>
Date: Fri, 22 Mar 2013 22:50:27 +0100

+1

2013/3/19 Mike Jones <[email-masked]>

>  I completely agree that documenting the engineering tradeoffs is in
> scope and a worthwhile exercise.  The point of my message was simply that
> we needn’t “accept the goal that there should be one way of encrypting
> keys” without doing this analysis.****
>
> ** **
>
> I think Matt Miller had it right when he wrote this morning “Personally,
> I don't think it's worth discussing this much further without a more
> complete counter-proposal on the table”.  Should a concrete
> counter-proposal to Matt’s draft be written, at that point we could have a
> much more concrete discussion.****
>
> ** **
>
>                                                                 Cheers,***
> *
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* Jim Schaad [mailto:[email-masked]]
> *Sent:* Tuesday, March 19, 2013 8:17 AM
> *To:* Mike Jones; 'Richard Barnes'
>
> *Cc:* 'James H Manger'; [email-masked]
> *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows***
> *
>
>  ** **
>
> <personal>****
>
> ** **
>
> The issue has been raised for discussion.  I do not believe that
> documenting what the extents of the issue are is out of scope of any and
> all follow on discussion.  Until that has been done it is not possible to
> talk about what the costs and benefits are.  If you have a full set of
> costs and benefits that would be an interesting message to see.****
>
> ** **
>
> *From:* Mike Jones [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Monday, March 18, 2013 8:24 PM
> *To:* Jim Schaad; Richard Barnes
> *Cc:* James H Manger; [email-masked]
> *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows***
> *
>
> ** **
>
> enemy of adoption.****
>  ****
> one way to encrypt keys”, versus taking that as a given.****
>
>  ****
>
> results in engineering benefits.****
>
>  ****
>
> and keys with attributes are a whole lot like arbitrary data.****
>
>  ****
>
> different in nature.****
>  ****
> Best wishes,****
> -- Mike****
>  ****
> *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows***
> *
>
>  ****
>
> Well, I got to 788 by doing math incorrectly*.  ****
>
> ** **
>
> 320 = 1088 > 1024. ****
> ** **
> deal with getting around the OAEP size limitations.****
>
> ** **
>
> --Richard
>
> * This is why my degree is in mathematics, and not accounting.****
>
> On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <[email-masked]>
> wrote:****
>
> Think in terms of encrypting a JWK directly not an intermediate key.****
>
>
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of*
> ***
>
> > Manger, James H
> > >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/14>****
>
> > https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Axel Nennker <[email-masked]>
Date: Fri, 22 Mar 2013 22:51:46 +0100

glows in the dark JWEs would be nice to have too.

2013/3/19 Richard Barnes <[email-masked]>

> I agree that it's a fair question to ask.  As I'm writing this key
> wrapping document (as requested in Orlando), I'm trying to develop a
> comparison of the costs of various wrapping schemes.
>
>>  Since you message appears to take it as given that “there should be
>> only one way of encrypting keys”, I’ll point out that I don’t think that
>> it’s reasonable to assume that.  JOSE is first and foremost an engineering
>>  Regardless, there is clearly an issue here when wrapping a JWK, which
>> is much larger, possibly containing an RSA key itself.  So if we accept the
>>> Of