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

[Brian Campbell <[e-mail]>]

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

>
>
>
>
> *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.
>

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.


> 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).


> 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.