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

From: Brian Campbell <[email-masked]>
Date: Thu, 2 Jul 2015 11:31:53 -0600

What value does key management on the MAC authentication key really
provide? I'm struggling to see it. What I do see is that it will make
messages larger and add complexity. And it seems very likely to be a source
of confusion that results in security problems around when integrity only
is provided vs. integrity and sender authentication. The latter being what
most will expect a MAC provides while the former isn't very useful but
potentially very problematic.

FWIW, I asked same(ish) question on the JOSE list
<http://www.ietf.org/mail-archive/web/jose/current/msg05156.html> yesterday
in regard to an individual draft about key managed MAC keys in JOSE.

On Sat, Jun 27, 2015 at 9:25 AM, Jim Schaad <[email-masked]> wrote:

*From:* Cose [mailto:[email-masked]] *On Behalf Of *Mike Jones
*Sent:* Saturday, June 27, 2015 2:07 AM
*To:* [email-masked]
*Subject:* [Cose] Review of draft-schaad-cose-msg-01

[JLS] This was discussed on the mailing list.  There are a number of
trade-offs that were discussed.  Please review that discussion and see if
you have something new to add.  Please remember that we are looking at both
the message size and the code size as criteria when making decisions.

*2.  HMACs should be optimized for the no-key-management case.*

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.

I’m fine with the optional ability to have key management for MACs, but the
default should be that no key management information is present in the
representation.  The only algorithm represented by default should be the
MAC algorithm – not even “dir” (direct).  I suspect that this can be
cleanly done by omitting the key management layer entirely when it’s not
used, rather than explicitly using “dir” (direct).

[JLS] See above.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 02 Jul 2015 19:36:41 +0200

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Jul 2015 17:52:39 +0000

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:[email-masked]] 
Sent: Thursday, July 02, 2015 10:37 AM
To: Brian Campbell; Jim Schaad
Cc: Mike Jones; [email-masked]
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 02 Jul 2015 19:47:57 +0200

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 7 Jul 2015 16:25:39 -0700

> From: Mike Jones [mailto:[email-masked]]
> Sent: Thursday, July 02, 2015 10:53 AM
> To: Hannes Tschofenig; Brian Campbell; Jim Schaad
> Cc: [email-masked]
> 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

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
> 
> I personally don't think we should target devices that cannot even do key
> management for symmetric cryptography. I would even argue that we
> 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.
> 
> meeting; it explains the performance of state-of-the-art crypto on common
> Cortex M class MCUs.

---

From: Derek Atkins <[email-masked]>
Date: Wed, 08 Jul 2015 12:44:21 -0400

> also able to do public key crypto.

I agree with all of this except for the RNG.  You don't need an RNG for
many use cases and can perform good security.  But of course it does
depend on the use-case.

> have enough insecure IoT devices in the market.

Sure.. Many IoT devices don't even try :)

> common Cortex M class MCUs.

I would quickly argue it's not "state-of-the-art" crypto.  It's ECC.
There are ... better... key agreement algorithms out there for IoT.

> https://www.ietf.org/proceedings/92/slides/slides-92-lwig-3.pdf

:)

> Hannes

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Jul 2015 10:37:33 -0700

I will freely admit that I do not know what the sizes of constrained devices
are today.  Based on the talks that I have heard on what is a constrained
device, I generally think of a range starting with a Z80 plus some side
hardware for AES and work up from there.  I generally don't think of 286's
as being all of that constrained let alone something that can actually do
64-bit natively.  At that point all one is looking at is power supply
constraints.

Jim

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Wednesday, July 08, 2015 9:44 AM
> To: Hannes Tschofenig
> Cc: Brian Campbell; Jim Schaad; Mike Jones; [email-masked]
> >> 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.
> >
many
> use cases and can perform good security.  But of course it does depend on
> the use-case.
> 
> > on our protocols that make them pretty insecure in practice. We
> > already have enough insecure IoT devices in the market.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 8 Jul 2015 10:44:47 -0700

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.

> From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Tuesday, July 07, 2015 4:26 PM
> To: 'Mike Jones'
> Cc: [email-masked]
> > 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.
> 
> 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.
> (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.
> 
> >
> > case.  If you're using a deterministic content encryption algorithm
> > and you're encrypting the same plaintext with the same key without key
> > 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
> >
> > on
> _______________________________________________
> Cose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Jul 2015 12:36:37 +0300

On Thu, Jul 09, 2015 at 06:12:49PM -0700, Jim Schaad wrote:
>  
> Looking at the new signature formats coming out of CFRG, I am not sure
> what the lengths of the signatures are,

AFAICT,

64 or 112-114 bytes (packable to 112 with some bit shuffling). One
proposal allows half-length hash, giving 48 or 84 bytes.

Public keys are 32 or 57 bytes.

(All can be defined on intermediate size curves too, for
intermediate signature/pubkey size at intermediate security).

-Ilari

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 07:07:19 -0600

> Sure.. Many IoT devices don't even try :)

I just want us to be cognizant of the possibility that a dense complicated
crypto messaging syntax will probably not change that situation. If it's
not easy and approachable, it has the potential to be ignored.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 10 Jul 2015 09:28:24 -0400

Brian Campbell <[email-masked]> writes:

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

Being able to do DH does not imply being able to sign.  They are
different protocols and not every public-key method can be used for both
operations.

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

Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw DH)
can still tell you that the transmission has not been modified between
you and the party you're talking to.  You're right that it tells you
nothing about the party you're talking to (i.e., without authentication
of the DH keys you have no idea if you're talking to a MITM or the real
endpoint).  However, using DH + MAC does tell you that you're not being
spoofed by a "passive" eavesdropper.

So IMHO it does have some benefit.

-derek

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 10 Jul 2015 10:14:15 -0400

On Fri, July 10, 2015 9:07 am, Brian Campbell wrote:
>> already

That's only half the problem.  Many people ignore security because there
is this belief "I can't reasonably run those algorithms on my devices."

So I would augment this to say that it not only needs to be easy and
approachable, but it also needs to be implementable on the hardware.  That
often rules out many cryptographic algorithms (like RSA and DH, and
sometimes even ECC) depending on space, power, and timing constraints of
the devices.

-derek

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Jul 2015 20:11:18 +0300

> So IMHO it does have some benefit.

It occurs to me that any sort of asymmetric key management with MACs
is unsafe, since knowing just public key enables message forgery.

This does not straightforwardly extend to symmetric schems (like
key wrapping), but are those useful with MACs?

-Ilari

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 10 Jul 2015 11:21:19 -0700

> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Friday, July 10, 2015 10:11 AM
> To: Derek Atkins
> > Performing a MAC using the output of a DH (be it ECDH, AEDH, or raw
> > DH) can still tell you that the transmission has not been modified
> > between you and the party you're talking to.  You're right that it
> > tells you nothing about the party you're talking to (i.e., without
> > authentication of the DH keys you have no idea if you're talking to a
> > MITM or the real endpoint).  However, using DH + MAC does tell you
> > that you're not being spoofed by a "passive" eavesdropper.
> >
> It occurs to me that any sort of asymmetric key management with MACs is
> unsafe, since knowing just public key enables message forgery.

We are going to need to have a consistent definition of message forgery for this to be a true statement.  Can one have a forgery from an anonymous person?  If you don't make a statement about who is sending the message, which may not be done in this case, then I have a problem with saying something is a forgery.

To have origination, one needs to use static-static DH.  Without this one does not have statement of origin.

> 
> This does not straightforwardly extend to symmetric schems (like key
> wrapping), but are those useful with MACs?

Depends to a large extent on what you are doing for key roll over of your shared secrets.   If you don't do it very often, then as I stated in my last message it can improve security as some attacks can be easier to detect.

jim

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 13:08:20 -0600

That's fair, Derek. I just hope the WG keeps both in mind.

---

From: Mike Jones <[email-masked]>
Date: Fri, 10 Jul 2015 19:31:51 +0000

+1
________________________________
From: Brian Campbell<mailto:[email-masked]>
Sent: ‎7/‎10/‎2015 12:08 PM
To: Derek Atkins<mailto:[email-masked]>
Cc: Hannes Tschofenig<mailto:[email-masked]>; Jim Schaad<mailto:[email-masked]>; Mike Jones<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

On Fri, Jul 10, 2015 at 8:14 AM, Derek Atkins <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, July 10, 2015 9:07 am, Brian Campbell wrote:
> On Wed, Jul 8, 2015 at 10:44 AM, Derek Atkins <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> writes:

-derek
--
       Derek Atkins                 617-623-3745<tel:617-623-3745>
       [email-masked]<mailto:[email-masked]>             www.ihtfp.com<http://www.ihtfp.com>
       Computer and Internet Security Consultant

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 16:06:48 -0600

And my question was about ephemeral-static DH and RSA-OAEP (both of which
are used in the MAC example at
https://cose-wg.github.io/cose-spec/#rfc.appendix.C.1.4) . Without the
statement of origin, I don't see what value there is?

On Fri, Jul 10, 2015 at 12:21 PM, Jim Schaad <[email-masked]> wrote:

> We are going to need to have a consistent definition of message forgery
> for this to be a true statement.  Can one have a forgery from an anonymous
> person?  If you don't make a statement about who is sending the message,
> which may not be done in this case, then I have a problem with saying
> something is a forgery.
>
> Depends to a large extent on what you are doing for key roll over of your
> shared secrets.   If you don't do it very often, then as I stated in my
> last message it can improve security as some attacks can be easier to
> detect.
>
> jim
>
> >
> >
> > -Ilari
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 10 Jul 2015 15:33:27 -0700

From: Brian Campbell [mailto:[email-masked]] 
Sent: Friday, July 10, 2015 3:07 PM
To: Jim Schaad
Cc: Ilari Liusvaara; [email-masked]
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

And my question was about ephemeral-static DH and RSA-OAEP (both of which are used in the MAC example at https://cose-wg.github.io/cose-spec/#rfc.appendix.C.1.4) . Without the statement of origin, I don't see what value there is?

It would be static-static DH not ES DH.  Otherwise – yes it is the same as RSA

On Fri, Jul 10, 2015 at 12:21 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

> From: Ilari Liusvaara [mailto:[email-masked] <mailto:[email-masked]> ]
> Cc: Brian Campbell; Jim Schaad; Mike Jones; [email-masked] <mailto:[email-masked]> 

jim

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 16:34:05 -0600

Really, there's no overhead from the key management part?

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2015 16:36:53 -0600

On Fri, Jul 10, 2015 at 4:33 PM, Jim Schaad <[email-masked]> wrote:

>
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Friday, July 10, 2015 3:07 PM
> *To:* Jim Schaad
> *Cc:* Ilari Liusvaara; [email-masked]
> *Subject:* Re: [Cose] Key management for MACs (was Re: Review of
> draft-schaad-cose-msg-01)
>
>
>

So back to what I was originally saying - that RSA and the same as RSA are
the key management modes that I'm suggesting not be used for MAC.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 10 Jul 2015 16:08:10 -0700

The overhead on key management is going to be based a lot on what you are doing.

If you are doing direct shared secret –then you have a kid

If you are doing ECDH-SS – then you need two kids and a nonce (which can be very short)

If you are doing ECDSA – then you need a kid

This means that to be the same size you have 24 bytes to express a second kid (which could be implicit) and a nonce (which can be a short as 2 or 3 bytes).  I don’t think you need that much space – so yes, it would be smaller.  

The overhead from the basic messages (MAC vs Sign) is going to be about the same in both cases.

From: Brian Campbell [mailto:[email-masked]] 
Sent: Friday, July 10, 2015 3:34 PM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

 

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 10 Jul 2015 23:11:39 +0000

Per my issue 2, I believe that the default key management mode should be “no key management” – what we called “direct” in JOSE.  If developers want to also add it in, more power to them.

Yes, key rotation will have to occasionally be done to make this safe.  That’s always been a given.  (And yes, that’s part of the meaning of “key management” that is out of scope for this working group, but is clearly necessary for any secure application.)

The overhead you’re not talking about below Jim is the computation time and power overhead of generating the ephemeral key and encrypting it.  If this isn’t absolutely necessary, it’s better to not do it.  JOSE seems to be working fine without this even being an option…

                                                                -- Mike

From: Cose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Friday, July 10, 2015 4:08 PM
To: 'Brian Campbell'
Cc: [email-masked]
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

From: Brian Campbell [mailto:[email-masked]]
Sent: Friday, July 10, 2015 3:34 PM
To: Jim Schaad
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Cose] Key management for MACs (was Re: Review of draft-schaad-cose-msg-01)

---

From: Brian Campbell <[email-masked]>
Date: Sat, 11 Jul 2015 06:10:15 -0600

The context around the overhead was signing vs. key agreement - so ECDH-SS
+ MAC vs. ECDSA. I was presuming that ECDH-SS would need a random MAC key
and key wrap it using the agreed key.  So the wrapped key was part of the
overhead I had in mind when I said I thought they'd be similar. But yeah,
okay, a  ECDH-SS with a KDF would be smaller.

On Fri, Jul 10, 2015 at 5:08 PM, Jim Schaad <[email-masked]> wrote:

> This means that to be the same size you have 24 bytes to express a second
> kid (which could be implicit) and a nonce (which can be a short as 2 or 3
> bytes).  I don’t think you need that much space – so yes, it would be
> smaller.
>
>
>
> *Sent:* Friday, July 10, 2015 3:34 PM
> *To:* Jim Schaad
> *Cc:* [email-masked]

---

From: Derek Atkins <[email-masked]>
Date: Mon, 13 Jul 2015 13:36:45 -0400

> is unsafe, since knowing just public key enables message forgery.

Pardon?  I don't understand that.  Just knowing your Public Key does not
mean I can send messages that appear to come from you.  The key used for
the MAC is the derived shared secret, so I would need to know your
Private Key as well in order to generate the correct shared secret.

At worst I could record and replay the session, assuming the other end
also uses a static public/private keypair.  Or I could act as an active
man-in-the-middle.

-derek

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Jul 2015 20:47:52 +0300

> Private Key as well in order to generate the correct shared secret.

Forgot about static-static DH (which might actually be useful, given
that it can cut down number of keys asymptotically).

There's also MAC keyed by dynamic DH key (one protocol I cooked
up a while back did that). But from message perspective, it would
be static-static.

But many asymmetric crypto primitives are not useful there, given
that those allow to agree or transport a known key, rendering the
MAC pretty much meaningless.

-Ilari