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

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

 

 

From: Brian Campbell [mailto:[e-mail]] 
Sent: Thursday, July 09, 2015 3:37 PM
To: Jim Schaad
Cc: Mike Jones; [e-mail]
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

 

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?

[JLS] Since you are using a random key every time, and can fail if the same key is presented in a specific number of times, yes doing a key wrap is better than using the shared key directly.  The receiver can be designed to not function as an oracle on if the key is good. Also one cannot use existing tags and messages to try any offline attacks as the key changes each time.

Situations where this might be useful are those such as in the latest ACE draft, which I just briefly scanned.  It posits multiple security contexts (i.e. shared keys) in a room and the need to potentially send the same command to all of those contexts.  One can either send multiple messages (one recipient per message, two messages) or send a single message using key wrapping for both contexts (one message two recipients).  It would depend on how power consumption looks to see which is the better win.

There are circumstances where the integrity bit is important, but the origination is not where sending a message to multiple recipients can be useful.

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. 

[JLS] And you are lucky to be in environments where you are not counting bytes of the message.  Looking at the new signature formats coming out of CFRG, I am not sure what the lengths of the signatures are, but there are environments where MACs are going to be the best one can do.  Supporting those environments is also a requirement.

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. 

 

[JLS] there seems to be a trend away from RSA for anything, but you might want to think harder about the key agreement cases.

  

 

On Wed, Jul 8, 2015 at 11:44 AM, Jim Schaad <[e-mail] <mailto:[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] <mailto:[e-mail]> ] On Behalf Of Jim Schaad
> Sent: Tuesday, July 07, 2015 4:26 PM
> To: 'Mike Jones'
> Cc: [e-mail] <mailto:[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] <mailto:[e-mail]> ]
> > Sent: Thursday, July 02, 2015 10:53 AM
> > To: Hannes Tschofenig; Brian Campbell; Jim Schaad
> > Cc: [e-mail] <mailto:[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] <mailto:[e-mail]> ]
> > Sent: Thursday, July 02, 2015 10:37 AM
> > To: Brian Campbell; Jim Schaad
> > Cc: Mike Jones; [e-mail] <mailto:[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] <mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Cose mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/cose