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

[Hannes Tschofenig <[e-mail]>]

I guess the challenge with the JOSE and the COSE work is that it is a
generic mechanism and you don't really know what applications are going
to use them. As such it is hard to say how the key management would
actually look like. Hence, it is a bit challenging to say what IoT can
and cannot do.

One consumer of the JOSE/JWS work was OAuth and there it is quite clear
how the story looks like.

In any case, whenever I read something about IoT devices I am always
wondering about what devices they are talking about.

Ciao
Hannes

On 07/02/2015 07:52 PM, Mike Jones wrote:
> 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.
> 
> The question is what *additional* value key management adds in the MAC case.
> 
> (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
>