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

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

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


> -----Original Message-----
> From: John Bradley [mailto:[e-mail]]
> Sent: Sunday, February 12, 2012 4:26 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
> 
> 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
> >>>
> >>>
> >
> >