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: Friday, July 10, 2015 2:56 PM
To: Jim Schaad
Cc: [e-mail]
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

 

 

 

On Thu, Jul 9, 2015 at 7:12 PM, Jim Schaad <[e-mail] <mailto:[e-mail]> > wrote:

 

 

From: Brian Campbell [mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Thursday, July 09, 2015 3:37 PM
To: 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)

 

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.

 

Wouldn't you get assurance of origination with symmetric key wrap + MAC? Even with multiple recipients. Following from what you said and thinking about it, seems like it should and that would be something that key wrap + MAC can provide that KDF + MAC cannot. Though I remain somewhat skeptical about how often multiple recipient messages would actually be used.

 

You can get origination to the point of – somebody in this group of people – but you don’t know which of the members in the group generated the message.  With KDF + MAC you cannot do multiple recipients.  You need KDF + MAC + WRAP in order to do multiple recipients.  In that case you lose the origination even if you are using static-static because anybody in the group can publish a forgery.

 

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.

 

I've admittedly not done the comparison but the message size overhead seems like it'd be similar with something like ECDSA (admittedly not RSA).

 

ECDSA = 2 * SHA-256 or 32 bytes

Truncated AES-CMAC is 8 bytes (64 bits)

 

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.

 

 

I've thought about it. Perhaps I just lack the experience or don't have the intellect. But I don't see it and I don't think I'm alone. And I strongly suspect that many people that would want to use this spec, or library implementations of it, won't understand either.