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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: John Bradley [mailto:[e-mail]]
> Sent: Sunday, February 12, 2012 1:41 PM
> To: Jim Schaad
> Cc: 'David McGrew'; 'Mike Jones'; [e-mail]
> Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-
> jones-json-web-encryption
> 
> 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?

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.

> 
> 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.

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.

> 
> 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.

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.

> 
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jose