Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

From: John Bradley <[email-masked]>
Date: Sun, 12 Feb 2012 18:40:38 -0300

Jim,

I may be missing something.

The scenario below is using RFC6278 and pre shared EC keys to crate a master symmetric key to wrap a per message symmetric key used for generating a HMAC, or to use the master symmetric key to wrap a MAC of the message?

For EC we only included ECDSA.  

The main difference is that with EC-DH-SS only the intended recipient can verify the message.  Slightly different from the ECDSA case.  

Is the reason for this performance in a embedded environment?

I think there is a general question about key wrapping vs using the pre-shared or key agreement value directly.   
The current specs lean towards using the values directly rather than for key wrapping.

I tend to prefer key wrapping for security,  but that depends on people actually rotating keys, and it makes the minimum message size larger.

Is key agreement for integrity (signing) common?

John B.
On 2011-11-16, at 9:54 PM, Jim Schaad wrote:

> Mike,
> 
> I think that while the structures for JWS might need to undergo some changes that will mean that while the MAC and Digital Signature structures.  As I mentioned at the F2F meeting, I know of someone is doing some small device work where they are sending messages from the devices to more central locations.  In this case there is not a pre-existing shared secret generally between the two entities and they are not using TLS so they could not derive one from the session key.  Mapping what they do into the current JWS work would require some changes. Specifically
> 
> Header Object
>   - contains a MAC algorithm to be used - generally AES-GMAC
>   - contains a key wrapping algorithm - generally AES key wrap
>   - contains a key agreement algorithm - generally EC-DH
> Key Exchange Value - the CEK wrapped by the KEK where the KEK came from the static-static EC-DH algorithm
> Body
> MAC value
> 
> In this case we have four not three items that need to be placed in the sequence of items to be sent between the originator and the verifier.  I would still compute the MAC value in much the same way, only I would compute the MAC over the first three elements instead of the two elements.
> 
> This is the sort of thing that is used in a more store and forward environment or one where the answer is going to be pre-computed or where it needs to last longer than just the current session (i.e. later validation).
> 
> The same type of thing can be used for a long term shared KEK value on both the sender and recipient, where a unique CEK is generated for each message and wrapped.  David would be a better person than I am to address the question of security.  -"Do you have more security by doing an indirection and have a fresh key for doing the MAC on each operation rather than using the long term key for doing the MAC."  
> 
> If we did the above change, then I would say that the "Key Exchange Value" would become and empty string if you have a key derivied from the TLS session that you are using - but this would still lead to having four not three elements in the MAC case.
> 
> Jim
> 
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 12 Feb 2012 15:36:10 -0800

> -----Original Message-----
> From: John Bradley [mailto:[email-masked]]
> Sent: Sunday, February 12, 2012 1:41 PM
> To: Jim Schaad
> Cc: 'David McGrew'; 'Mike Jones'; [email-masked]
> Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-
> jones-json-web-encryption
> 
> Jim,
> 
> The scenario below is using RFC6278 and pre shared EC keys to crate a
master
> symmetric key to wrap a per message symmetric key used for generating a
> HMAC, or to use the master symmetric key to wrap a MAC of the message?

It is using static-ephemeral ECDH (or ECDH-ES) to generate a symmetric key
which uses A128KW to wrap a symmetric key which is used to MAC the message.

> The main difference is that with EC-DH-SS only the intended recipient can
> verify the message.  Slightly different from the ECDSA case.

But not any different from the case of using a pre-shared secret key and a
MAC algorithm.  This is the current MUST implement.  ECDSA is only a SHOULD
implement.

> Is the reason for this performance in a embedded environment?

In the case I outlined below, yes this is an embedded system.  The goal was,
in part, to use the fewest possible cryptographic primitives necessary.
Since encryption was a requirement, there was already AES and EC
shared-secret computation.  Using an AES based KDF meant that there are no
hash functions.  Adding integrity protection as well without adding new
primitives was desired.  It could use EC + the AES KDF to get a key and
AES-CBC (or AES-GMAC) to compute a MAC by adding only modes.

> The current specs lean towards using the values directly rather than for
key
> wrapping.
> 
> I tend to prefer key wrapping for security,  but that depends on people
> actually rotating keys, and it makes the minimum message size larger.

Actually it is the other way around.  Not using key wrapping is more
dependent on people actually rotating keys.  If one uses a key agreement or
key transport to carry the key, then a fresh key is being used for the MAC
every time and there is no problems with either forward security or
gathering a large number of messages with the same MAC value and being able
to do things based on that.  So you most likely trading off message size for
security depending on the source of the key you are using for the MAC
operation.   For example if it came from the TLS session then the answer
would be different. 

> Is key agreement for integrity (signing) common?

How common is it to use MACs?  In those cases how many people are
complaining because the shared keys never get rolled over?  No it is not
common, what is common is to have no security at all.  The next is to have
very long term shared keys for doing MACs. 

One could possibly argue that the entire project is a waste of time since
all of these items are sent over a TLS session (or should be) and therefore
the integrity of the transfer is already protected.  This would mean that
you are making for bigger messages by adding a second level of integrity
protection.  The question is what is the second level of integrity
protection trying to protect?  Is it trying to be long term or short term?
Without knowing what the goals are, it is not possible to say that the
answer is actually working correctly.

> > I think that while the structures for JWS might need to undergo some
> changes that will mean that while the MAC and Digital Signature
structures.
> As I mentioned at the F2F meeting, I know of someone is doing some small
> device work where they are sending messages from the devices to more
> central locations.  In this case there is not a pre-existing shared secret
> generally between the two entities and they are not using TLS so they
could
> not derive one from the session key.  Mapping what they do into the
current
> JWS work would require some changes. Specifically
> >
> > Header Object
> > In this case we have four not three items that need to be placed in the
> sequence of items to be sent between the originator and the verifier.  I
> would still compute the MAC value in much the same way, only I would
> compute the MAC over the first three elements instead of the two
> elements.
> >
> > This is the sort of thing that is used in a more store and forward
> environment or one where the answer is going to be pre-computed or
> where it needs to last longer than just the current session (i.e. later
> validation).
> >
> > The same type of thing can be used for a long term shared KEK value on
> both the sender and recipient, where a unique CEK is generated for each
> message and wrapped.  David would be a better person than I am to address
> the question of security.  -"Do you have more security by doing an
indirection
> and have a fresh key for doing the MAC on each operation rather than using
> the long term key for doing the MAC."
> >
> > If we did the above change, then I would say that the "Key Exchange
> Value" would become and empty string if you have a key derivied from the
> TLS session that you are using - but this would still lead to having four
not
> three elements in the MAC case.
> >
> > Jim
> >
> >

---

From: John Bradley <[email-masked]>
Date: Sun, 12 Feb 2012 21:05:10 -0300

> which uses A128KW to wrap a symmetric key which is used to MAC the message.

Ah OK you had static static that confused me.  We do have ECDSA-ES for encryption, but hadn't thought about it for signing, because it is more integrity, without knowing the identity of the originator.

> MAC algorithm.  This is the current MUST implement.  ECDSA is only a SHOULD

I don't know that we are going to get more agreement on ECDH-ES being a MUST than ECDSA.

> AES-CBC (or AES-GMAC) to compute a MAC by adding only modes.

In your original post I missed that the body was encrypted, I thought you were only encrypting the key.

Generating a unauthenticated integrity check.

If we are talking about Encryption then ECDH-ES with AES-GWC in the existing spec works.
We do need to add the MAC integrity check to support CBC.

Again in ECDH-ES only the recipient is authenticated.

> operation.   For example if it came from the TLS session then the answer

My confidence in people using a fresh key for the MAC each time in wrapping is less than yours.  
I admit encouraging them to do the right thing is probably the best, rather than optimizing for there potential mistakes.

> answer is actually working correctly.
In general with HMAC type integrity checks people infer the identity of the originator through the possession of the long term secret.  

The scenario you present seems to not care about the identity of the originator.  

Sorry if the questions are simple.
I am just trying to understand the use case.

John B.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 12 Feb 2012 16:15:29 -0800

> Sent: Sunday, February 12, 2012 4:05 PM
> To: Jim Schaad
> Cc: 'Mike Jones'; [email-masked]
> Ah OK you had static static that confused me.  We do have ECDSA-ES for
> encryption, but hadn't thought about it for signing, because it is more
> integrity, without knowing the identity of the originator.

Yeah - I forgot - it depends on if you want to know who sent it.  If you
want to know who sent it then you need to use static-static.  But that is
completely orthogonal to the rest of the argument.

> I don't know that we are going to get more agreement on ECDH-ES being a

I am not saying that it needs to be a MUST - but the current structure does
not support it in any fashion.

> were only encrypting the key.

In this case I am not encrypting the body.  I am only doing an
authentication operation.  What I am looking at is the number of primitives
that are required for the sender to be able to do both operations.

> >> I think there is a general question about key wrapping vs using the
pre-
> >> shared or key agreement value directly.
> I admit encouraging them to do the right thing is probably the best,
rather
> than optimizing for there potential mistakes.
> 

There are a lot of things people can do that is bad.  That does not mean we
should discourage those that want to do it correctly.

> In general with HMAC type integrity checks people infer the identity of
the
> originator through the possession of the long term secret.
> 

See above note - It actually does use a static-static.  But as I can easily
add to that to the list of "private" algorithms this is not a stumbling
block.  Note that if you look at the above I needed to add a new ECDH
algorithm in any event since I am not using the standard KDF function.

Jim

---

From: John Bradley <[email-masked]>
Date: Sun, 12 Feb 2012 21:26:18 -0300

I can see adding ECDH-SS for both signing and encryption.   It gets you both at the same time sort of.

Is there a problem with reusing the KDF from ECDH-ES?

I think I see what you are after now.

John B.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 12 Feb 2012 16:50:47 -0800

In this case there was, but normally there is not.  The KDF function from
ECDH-ES uses SHA-256 as it's primitive.  Since the system that I was looking
at had no hash functions that did not work in that context.

Jim

> Sent: Sunday, February 12, 2012 4:26 PM
> To: Jim Schaad
> I can see adding ECDH-SS for both signing and encryption.   It gets you
both at
> the same time sort of.
> >>>> symmetric key to wrap a per message symmetric key used for
> generating
> >> a
> >>> But not any different from the case of using a pre-shared secret key
and
> > a
> >> I don't know that we are going to get more agreement on ECDH-ES being
> a
> >> MUST than ECDSA.
> >
> >>> In the case I outlined below, yes this is an embedded system.  The
goal
> >> was,
> >>> shared-secret computation.  Using an AES based KDF meant that there
> are
> >> no
> >> In your original post I missed that the body was encrypted, I thought
you
> >> were only encrypting the key.
> >
> >>> dependent on people actually rotating keys.  If one uses a key
> agreement
> >> or
> >>> gathering a large number of messages with the same MAC value and
> being
> >> able
> >>> to do things based on that.  So you most likely trading off message
size
> > for
> >>>>> Key Exchange Value - the CEK wrapped by the KEK where the KEK
> came
> >>>> from the static-static EC-DH algorithm
> >>>>> Body
> >>>>> MAC value
> >>>>>