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

[John Bradley <[e-mail]>]

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.
On 2012-02-12, at 9:15 PM, Jim Schaad wrote:

> 
> 
>> -----Original Message-----
>> From: John Bradley [mailto:[e-mail]]
>> Sent: Sunday, February 12, 2012 4:05 PM
>> To: Jim Schaad
>> Cc: 'Mike Jones'; [e-mail]
>> Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-
>> jones-json-web-encryption
>> 
>> 
>> 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.
> 
> 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.
> 
>> 
>>> 
>>>> 
>>>> 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.
> 
> I am not saying that it needs to be a MUST - but the current structure does
> not support it in any fashion.
> 
>> 
>>> 
>>>> 
>>>> 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.
> 
> 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.
> 
>> 
>> 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.
>> 
> 
> 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.
> 
>> 
>>> 
>>>> 
>>>> 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.
> 
> 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
> 
>> 
>> 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
>>> 
>>> 
> 
>