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