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

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

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