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

[John Bradley <[e-mail]>]

On 2012-02-12, at 8:36 PM, Jim Schaad wrote:

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

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.

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

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

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

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.

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

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.


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

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