Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping

From: Mike Jones <[email-masked]>
Date: Tue, 25 Jun 2013 23:18:16 +0000

http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 seems like a substantially simpler approach than http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01.  This is evident by several metrics:

*         Number of proposed changes:  The Jones draft proposes no changes to any of the current specs.  It simply defines an encoding for GCM and adds registry entries for it.  Whereas the Barnes draft proposes a major restructuring - listing 4 major changes in the introduction and 4 smaller changes.

*         Normative text size:  The Jones GCM key wrap approach requires only 7 normative sentences in 1/2 page of text.  The Barnes draft has four pages of normative text, along with an extensive introduction describing the proposed complete restructuring of JWS and JWE.

We don't need to boil the ocean with a total redesign to enable AEAD key wrapping.  It can already easily be done with the current specs simply by defining new algorithms.  The approach taken in http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 would work for any AEAD algorithm.

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Tuesday, June 25, 2013 9:53 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping

We now have two documents - one from Richard and one from Mike - which provide the two different ways that have been proposed for doing key wrapping with an AEAD algorithm.

Please review the two documents and provide comments to the list.

Jim

---

From: John Bradley <[email-masked]>
Date: Tue, 25 Jun 2013 19:28:55 -0400

I prefer the approach Mike is proposing.   It is overall simper and less restructuring.

John B.
On 2013-06-25, at 7:18 PM, Mike Jones <[email-masked]> wrote:

> http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 seems like a substantially simpler approach thanhttp://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01.  This is evident by several metrics:
> ·         Number of proposed changes:  The Jones draft proposes no changes to any of the current specs.  It simply defines an encoding for GCM and adds registry entries for it.  Whereas the Barnes draft proposes a major restructuring – listing 4 major changes in the introduction and 4 smaller changes.
> ·         Normative text size:  The Jones GCM key wrap approach requires only 7 normative sentences in 1/2 page of text.  The Barnes draft has four pages of normative text, along with an extensive introduction describing the proposed complete restructuring of JWS and JWE.
>  
> We don’t need to boil the ocean with a total redesign to enable AEAD key wrapping.  It can already easily be done with the current specs simply by defining new algorithms.  The approach taken in http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 would work for any AEAD algorithm.
>  
>                                                                 -- Mike
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
> To: [email-masked]
> We now have two documents – one from Richard and one from Mike – which provide the two different ways that have been proposed for doing key wrapping with an AEAD algorithm.
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Roland Hedberg <[email-masked]>
Date: Wed, 26 Jun 2013 08:52:09 +0200

Likewise, I also prefer Mike's proposal.

---

From: Edmund Jay <[email-masked]>
Date: Wed, 26 Jun 2013 00:12:35 -0700 (PDT)

I'm in favor of supporting Mike's proposal due to simplicity.

________________________________
 From: Roland Hedberg <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Cc: John Bradley <[email-masked]>; Mike Jones <[email-masked]>; Jim Schaad <[email-masked]> 
Sent: Tuesday, June 25, 2013 11:52 PM
Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 26 Jun 2013 11:29:52 -0700

<no hat>

<sarcasm level="heavy">

I am shocked that you would possibly support this proposal.  It provides for
two ways of dealing with something.  It is my understanding that you never
support anything that has two ways of doing something.

How the AEAD algorithm parameters is handled completely differently for this
proposal and for the same algorithms being used in a CEK context.  This is
going to lead to confusion.

</sarcasm>

Your specification is missing some items that still need to be registered
Thus you also need to have ECDH-ES+A128GCMKW and ECDH-ES+A256GCMKW defined
in your document as well.

Your document ends up with a registration complexity that needs to be
thought about and dealt with as well.  For every new key wrap algorithm
added, you will need to register not only it alone but also it with every
different key agreement algorithm that is supported.  Thus adding a single
key wrap algorithm becomes a slight issue in terms of adding in all of the
different ways that it might be used.  This is a complexity issue that is
not discussed in the current draft.

I have not necessarily found that document size equals code size.  I have
implemented some very simple documents that were very difficult to code and
implemented some very long documents that were very easy to code.  So I
would not use that fact as a deciding factor.

(Once again I regret the fact that the group did not go with an object
descriptor for algorithms as this would have made all of this much simpler.
I actually immediately map from the string to an object description in my
JOSE implementation for simplicity reasons.  Not to mention that this is way
it needs to be done for the WebCrypto specficiation.)

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 4:18 PM
To: 'Jim Schaad'; [email-masked]
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping

http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 seems like a
substantially simpler approach than
http://tools.ietf.org/html/draft-barnes-jose-key-wrapping-01.  This is
evident by several metrics:

.         Number of proposed changes:  The Jones draft proposes no changes
to any of the current specs.  It simply defines an encoding for GCM and adds
registry entries for it.  Whereas the Barnes draft proposes a major
restructuring - listing 4 major changes in the introduction and 4 smaller
changes.

.         Normative text size:  The Jones GCM key wrap approach requires
only 7 normative sentences in 1/2 page of text.  The Barnes draft has four
pages of normative text, along with an extensive introduction describing the
proposed complete restructuring of JWS and JWE.

We don't need to boil the ocean with a total redesign to enable AEAD key
wrapping.  It can already easily be done with the current specs simply by
defining new algorithms.  The approach taken in
http://tools.ietf.org/html/draft-jones-jose-aes-gcm-key-wrap-00 would work
for any AEAD algorithm.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: Tuesday, June 25, 2013 9:53 AM
To: [email-masked]
Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping

We now have two documents - one from Richard and one from Mike - which
provide the two different ways that have been proposed for doing key
wrapping with an AEAD algorithm.

Jim

---

From: Mike Jones <[email-masked]>
Date: Wed, 26 Jun 2013 19:21:38 +0000

Yes, we could also propose algorithm combinations for key agreement followed GCM key wrapping but I didn't think that was an ask from the working group.  The Denver minutes just recorded my action item as "key wrap draft for AES-GCM-keywrap", so that's what I did.  We could have a discussion on Monday's call and on the list about whether the working group is also interested in other algorithms.

Remember, the beauty of having the algorithms registry is that algorithms can be added "just in time" - as actual need for them is demonstrated.  We don't have to register all conceivable algorithm combinations up front for the JWE/JWA specs to be complete.

As for how the AEAD parameters are handled I used a parameter encoding that doesn't result in double base64url encoding anything.  I could have instead introduced separate "iv" and "tag" header parameter values, but didn't do so for that reason.  But if people would prefer that approach because it's more parallel to the use of GCM for plaintext encryption, I have no problem with that.

I do believe that the objective of my draft was met - demonstrating that AEAD key wrapping can be easily done with the current drafts.  The details of how the algorithm parameters are encoded is secondary to that and algorithm-specific; several reasonable choices are possible within the current JWE framework - one of which was described in my draft.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, June 26, 2013 11:30 AM
To: Mike Jones; [email-masked]
Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping

<no hat>
<sarcasm level="heavy">

I am shocked that you would possibly support this proposal.  It provides for two ways of dealing with something.  It is my understanding that you never support anything that has two ways of doing something.

How the AEAD algorithm parameters is handled completely differently for this proposal and for the same algorithms being used in a CEK context.  This is going to lead to confusion.

</sarcasm>

Your specification is missing some items that still need to be registered  Thus you also need to have ECDH-ES+A128GCMKW and ECDH-ES+A256GCMKW defined in your document as well.

Your document ends up with a registration complexity that needs to be thought about and dealt with as well.  For every new key wrap algorithm added, you will need to register not only it alone but also it with every different key agreement algorithm that is supported.  Thus adding a single key wrap algorithm becomes a slight issue in terms of adding in all of the different ways that it might be used.  This is a complexity issue that is not discussed in the current draft.

I have not necessarily found that document size equals code size.  I have implemented some very simple documents that were very difficult to code and implemented some very long documents that were very easy to code.  So I would not use that fact as a deciding factor.

(Once again I regret the fact that the group did not go with an object descriptor for algorithms as this would have made all of this much simpler.  I actually immediately map from the string to an object description in my JOSE implementation for simplicity reasons.  Not to mention that this is way it needs to be done for the WebCrypto specficiation.)

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, June 25, 2013 4:18 PM
To: 'Jim Schaad'; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping

                                                                -- Mike

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 26 Jun 2013 20:18:29 -0700

My point was that there were some issues that your draft did not fully
address that need to be evaluated as part of your proposal not that these
algorithms would need to be added.  The n x m addition of algorithms to the
registry is an issue that is there for your draft that is not present for
Richard's draft and therefore needs to be considered in the arguments.

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 12:22 PM
To: Jim Schaad; [email-masked]
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping

Yes, we could also propose algorithm combinations for key agreement followed
GCM key wrapping but I didn't think that was an ask from the working group.
The Denver minutes just recorded my action item as "key wrap draft for
AES-GCM-keywrap", so that's what I did.  We could have a discussion on
Monday's call and on the list about whether the working group is also
interested in other algorithms.

Remember, the beauty of having the algorithms registry is that algorithms
can be added "just in time" - as actual need for them is demonstrated.  We
don't have to register all conceivable algorithm combinations up front for
the JWE/JWA specs to be complete.

As for how the AEAD parameters are handled I used a parameter encoding that
doesn't result in double base64url encoding anything.  I could have instead
introduced separate "iv" and "tag" header parameter values, but didn't do so
for that reason.  But if people would prefer that approach because it's more
parallel to the use of GCM for plaintext encryption, I have no problem with
that.

I do believe that the objective of my draft was met - demonstrating that
AEAD key wrapping can be easily done with the current drafts.  The details
of how the algorithm parameters are encoded is secondary to that and
algorithm-specific; several reasonable choices are possible within the
current JWE framework - one of which was described in my draft.

                                                                -- Mike

<no hat>

<sarcasm level="heavy">

</sarcasm>

Jim

                                                                -- Mike

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 27 Jun 2013 04:01:14 +0000

For my part, I consider the fact that people will need to register specific algorithm combinations that they actually need to be a feature - not a bug.  The smaller the set of algorithm combinations registered, the more likely that they will be implemented and will interoperate.  Trying to claim that we support the combinatorial explosion of mask generation functions, hash functions, key derivation functions, key wrapping functions, etc. that are possible will almost certainly result in less interoperability and more developer confusion than a small set of registered choices, carefully considered.  I'm glad to have people consider these criteria in their evaluation of the two choices.

                                                                           -- Mike

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, June 26, 2013 8:18 PM
To: Mike Jones; [email-masked]
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping

My point was that there were some issues that your draft did not fully address that need to be evaluated as part of your proposal not that these algorithms would need to be added.  The n x m addition of algorithms to the registry is an issue that is there for your draft that is not present for Richard's draft and therefore needs to be considered in the arguments.

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, June 26, 2013 12:22 PM
To: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, June 26, 2013 11:30 AM
To: Mike Jones; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping

<no hat>
<sarcasm level="heavy">

</sarcasm>

Jim

                                                                -- Mike

Jim

---

From: Breno de Medeiros <[email-masked]>
Date: Wed, 26 Jun 2013 21:21:46 -0700

I also don't believe that supporting the matrix of possible
algorithmic combinations satisfies any business need.

On Wed, Jun 26, 2013 at 9:01 PM, Mike Jones <[email-masked]> wrote:
> For my part, I consider the fact that people will need to register specific
> algorithm combinations that they actually need to be a feature – not a bug.
> The smaller the set of algorithm combinations registered, the more likely
> that they will be implemented and will interoperate.  Trying to claim that
> we support the combinatorial explosion of mask generation functions, hash
> functions, key derivation functions, key wrapping functions, etc. that are
> possible will almost certainly result in less interoperability and more
> developer confusion than a small set of registered choices, carefully
> considered.  I’m glad to have people consider these criteria in their
> evaluation of the two choices.
>
>
>
>
> -- Mike
>
>
>
> Richard’s draft and therefore needs to be considered in the arguments.
>
>
>
> GCM key wrapping but I didn’t think that was an ask from the working group.
> The Denver minutes just recorded my action item as “key wrap draft for
> AES-GCM-keywrap”, so that’s what I did.  We could have a discussion on
> Monday’s call and on the list about whether the working group is also
> can be added “just in time” – as actual need for them is demonstrated.  We
> don’t have to register all conceivable algorithm combinations up front for
> doesn’t result in double base64url encoding anything.  I could have instead
> introduced separate “iv” and “tag” header parameter values, but didn’t do so
> for that reason.  But if people would prefer that approach because it’s more
> I do believe that the objective of my draft was met – demonstrating that
> current JWE framework – one of which was described in my draft.
>
>
>
>                                                                 -- Mike
>
>
>
> <sarcasm level=”heavy”>
> ·        Number of proposed changes:  The Jones draft proposes no changes to
> any of the current specs.  It simply defines an encoding for GCM and adds
> restructuring – listing 4 major changes in the introduction and 4 smaller
> changes.
>
> ·        Normative text size:  The Jones GCM key wrap approach requires only
> 7 normative sentences in 1/2 page of text.  The Barnes draft has four pages
> of normative text, along with an extensive introduction describing the
> We don’t need to boil the ocean with a total redesign to enable AEAD key
> We now have two documents – one from Richard and one from Mike – which

-- 
--Breno

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 27 Jun 2013 09:42:27 -0700

That is not the experience that we have seen with TLS.  In this case people
want to constantly register the entire matrix of items.  I would not expect
that desire to change.

Jim

From: Mike Jones [mailto:[email-masked]] 
Sent: Wednesday, June 26, 2013 9:01 PM
To: Jim Schaad; [email-masked]
Subject: RE: [jose] Issue #13 - use AES-GCM for Key Wrapping

algorithm combinations that they actually need to be a feature - not a bug.
considered.  I'm glad to have people consider these criteria in their

-- Mike

                                                                -- Mike

<no hat>

<sarcasm level="heavy">

</sarcasm>

Jim

                                                                -- Mike

Jim