Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

[Brian Campbell <[e-mail]>]

I typically look to MACs with a pre-shared key for integrity protection and
authentication of the sender (the latter, as you say, "assumes that there
are only two parties involved and you did not send the message yourself). I
use the key directly and I'd be really surprised if I wasn't in the vast
majority in doing so. This is all that JOSE offers, as we know. I suspect
some keys get rotated more than others.

The paper you sent mostly goes over my head, honestly. But seems concerns
about that kind of cryptanalysis could be mitigated by running the key
though a KDF with a nonce or other additional context, as you said. Key
wrapping a random per-message MAC key also ensures that repeated MAC
operations aren't being done with the pre-shared key. But then repeated key
wrapping is. I presume repeated key wrapping is considered better than
repeated MACing? A key wrapping approach seems more complicated and likely
results in more size overhead for the message. But maybe I'm wrong. Are
there reasons in practice that one would chose key wrapping over a KDF?

If I were able to do DH, I'd have a public/private key and I guess I never
would have thought about doing a key agreement and MAC. I'd probably just
sign with my key. Maybe I'm just not very creative. But while having
options is good, having too many options can be problematic.

Doing a MAC with RSA OAEP key encryption or ECDH-ES key agreement, to me
anyway, seems to provide little value and a big opportunity for confusion
and security problems. I don't believe it's an option that should be
provided.


On Wed, Jul 8, 2015 at 11:44 AM, Jim Schaad <[e-mail]> wrote:

> Another case where key management for MACs can be very useful is the case
> of
> DH direct.  This allows for creating of a new unique key for the MAC every
> time, while not needing to keep per connection secrets for everything.
>
> Just what security service do you exect to get from a MAC?  That is going
> to
> control how you feel about doing key management.
>
> > -----Original Message-----
> > From: Cose [mailto:[e-mail]] On Behalf Of Jim Schaad
> > Sent: Tuesday, July 07, 2015 4:26 PM
> > To: 'Mike Jones'
> > Cc: [e-mail]
> > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-
> > schaad-cose-msg-01)
> >
> >
> >
> > > -----Original Message-----
> > > From: Mike Jones [mailto:[e-mail]]
> > > Sent: Thursday, July 02, 2015 10:53 AM
> > > To: Hannes Tschofenig; Brian Campbell; Jim Schaad
> > > Cc: [e-mail]
> > > Subject: RE: [Cose] Key management for MACs (was Re: Review of draft-
> > > schaad-cose-msg-01)
> > >
> > > If MACs without key management were insecure, I'm sure that JWS [RFC
> > > 7515] wouldn't have survived the SecDir review or the IESG review
> > > since it has no key management for MACs, but it did.
> >
> > [JLS] There was no assumption that there was no key lifetime management
> > for the case of JWS or JWE.  The assumption was that the key management
> > was being down outside of these documents.  I am sure (or at least
> strongly
> > hope) that nobody is suggesting that a single key was going to be
> > negotiated between the sender and the receiver of a message and it would
> > never be modified in the future.
> >
> > >
> > > The question is what *additional* value key management adds in the
> > MAC
> > > case.
> >
> > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-
> > GCM/multi-
> > forge-01.pdf
> >
> > provides a method to looking at how to attack a key.  This would be done
> > by looking at the recipient of the message as an oracle to see how it
> > responds to messages.  The more one uses the same key the more data
> > there is to work with to attack keys.  From this point of view,
> encryption
> > can be better because traffic analysis might be all you get from re-using
> a
> > key.
> >
> > Even doing something as simple as running the shared secret through a KDF
> > (with perhaps a sequence number or time marker in the context) will make
> > the system more secure as the same key is no longer being used to MAC
> > every message.
> >
> > >
> > > (I completely understand the value of key management in the encryption
> > > case.  If you're using a deterministic content encryption algorithm
> > > and you're encrypting the same plaintext with the same key without key
> > > management, the ciphertext values will match, allowing attackers to
> > > correlate messages.  Using a randomly generated content encryption key
> > > means that encryptions of the same plaintext result in different
> > ciphertext
> > > values - preventing this correlation.  But the payload in a MAC is not
> > > a secret, so there's no equivalent benefit in the MAC case.)
> > >
> > >                             -- Mike
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:[e-mail]]
> > > Sent: Thursday, July 02, 2015 10:37 AM
> > > To: Brian Campbell; Jim Schaad
> > > Cc: Mike Jones; [e-mail]
> > > Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-
> > > schaad-cose-msg-01)
> > >
> > >
> > >
> > > > Particularly for constrained devices, it is unlikely that
> > > > applications will want to pay the performance penalty of generating
> > > > and encrypting a key management key to perform a MAC operation.
> > > > Heck, they may not have credible random number generation in the
> > > > first place!  And they are likewise unlikely to want to pay the
> > > > message size penalty of carrying the encrypted key.
> > >
> > > It would be good to know what devices you have in mind in this
> > discussion.
> > >
> > > I personally don't think we should target devices that cannot even do
> > > key management for symmetric cryptography. I would even argue that we
> > > should aim for devices that support a random number generator and are
> > > also able to do public key crypto.
> > >
> > > We are not doing ourselves a flavor if we place artificial constraints
> > > on
> > our
> > > protocols that make them pretty insecure in practice. We already have
> > > enough insecure IoT devices in the market.
> > >
> > > Here is the slide deck I presented in the LWIG group at the last IETF
> > > meeting; it explains the performance of state-of-the-art crypto on
> > > common Cortex M class MCUs.
> > > https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf
> > >
> > > Ciao
> > > Hannes
> >
> > _______________________________________________
> > Cose mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> Cose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>