Subject: [COSE] MAC with no recipient structures

From: "Jim Schaad" <[email-masked]>
Date: Sat, 7 Nov 2015 14:39:41 -0800

People keep telling me that they want to have a version of MACs that do not
have a set of recipient information attached so that they can do direct
MACs.  I keep asking for a use case where this makes sense.  In all of the
use cases that I have been presented so far, a better answer is going to be
to do an AEAD encrypted item rather than a MACed item.

The scenario that wants this is going to be:

Alice sends data to Bob in such a way that Bob can authenticate the data.
Eve needs to be able to read the data in transit, without knowing if the
message contains data or misinformation and will act on the message as if it
were data.

The difference in message size between MAC and Encryption is going to be
minimal, at most a few bytes.  The execution difference is going to be a few
extra encryption operations.

What use cases exist for this where encryption is not a better security
answer anyway.

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Sat, 14 Nov 2015 10:25:38 +0100

> to do an AEAD encrypted item rather than a MACed item.

An example where this is useful is given in Section 3.7 of
draft-bergmann-ace-dcaf-cose [1]. Here, the recipient structure is empty
because CAM and C must be able to read the payload. Technically, you can
make this work with an encrypted AEAD item as well but then, the payload
information entirely goes into the AAD part because CAM and C must not
know the secret that is being used for generating the MAC tag (they just
forward the data to S).

Of course, this is a requirement only in the cross-domain authorization
scenario where C and S can be constrained and can have distinct owners.
Where this is not considered an issue, you can easily go with
COSE_encryptData and AEAD.

[1] https://tools.ietf.org/html/draft-bergmann-ace-dcaf-cose-00#section-3.7

Grüße
Olaf

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 14 Nov 2015 11:53:54 -0800

I just read through the section referenced and did not see any reason for C and CAM to have access to the content.  I will try and read the entire document later today as that might describe the reasoning.

However, you are saying that it is ok for incorrect content to be in this message as far as C and CAM are concerned?

Jim

> -----Original Message-----
> From: Olaf Bergmann [mailto:[email-masked]]
> Sent: Saturday, November 14, 2015 1:26 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [COSE] MAC with no recipient structures
> 
> > People keep telling me that they want to have a version of MACs that
> > do not have a set of recipient information attached so that they can
> > do direct MACs.  I keep asking for a use case where this makes sense.
> > In all of the use cases that I have been presented so far, a better
> > answer is going to be to do an AEAD encrypted item rather than a MACed
> item.
> 
> An example where this is useful is given in Section 3.7 of draft-bergmann-ace-
> dcaf-cose [1]. Here, the recipient structure is empty because CAM and C must be
> able to read the payload. Technically, you can make this work with an encrypted
> AEAD item as well but then, the payload information entirely goes into the AAD
> part because CAM and C must not know the secret that is being used for
> generating the MAC tag (they just forward the data to S).
> 
> Of course, this is a requirement only in the cross-domain authorization scenario
> where C and S can be constrained and can have distinct owners.
> Where this is not considered an issue, you can easily go with COSE_encryptData
> and AEAD.
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 16 Nov 2015 22:38:56 +0000

It should be up to the application whether a MAC operation or an authenticated encryption operation is the best choice for the application.  COSE needs to simply and efficiently support both, giving the application that choice.

One use case would be a CBOR mapping of OpenID Connect login for IoT usage - replacing the JWT-based ID Token with a CWT-based ID Token.  This would often be used with symmetric crypto, where per RP/IdP symmetric HMAC keys are employed.  The ID Token (containing information about the authentication that occurred) would use direct HMAC.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Saturday, November 07, 2015 2:40 PM
To: [email-masked]
Subject: [COSE] MAC with no recipient structures

People keep telling me that they want to have a version of MACs that do not have a set of recipient information attached so that they can do direct MACs.  I keep asking for a use case where this makes sense.  In all of the use cases that I have been presented so far, a better answer is going to be to do an AEAD encrypted item rather than a MACed item.

Alice sends data to Bob in such a way that Bob can authenticate the data.
Eve needs to be able to read the data in transit, without knowing if the message contains data or misinformation and will act on the message as if it were data.

The difference in message size between MAC and Encryption is going to be minimal, at most a few bytes.  The execution difference is going to be a few extra encryption operations.

What use cases exist for this where encryption is not a better security answer anyway.

Jim

_______________________________________________
COSE mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cose

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 16 Nov 2015 17:21:00 -0800

For this case, what is the benefit that you see for favoring HMAC over
AES-GCM?

Jim

> From: Mike Jones [mailto:[email-masked]]
> Sent: Monday, November 16, 2015 2:39 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: RE: [COSE] MAC with no recipient structures
> 
> It should be up to the application whether a MAC operation or an
authenticated
> encryption operation is the best choice for the application.  COSE needs
to
> simply and efficiently support both, giving the application that choice.
> 
> One use case would be a CBOR mapping of OpenID Connect login for IoT usage
-
> replacing the JWT-based ID Token with a CWT-based ID Token.  This would
> often be used with symmetric crypto, where per RP/IdP symmetric HMAC keys
> are employed.  The ID Token (containing information about the
authentication
> that occurred) would use direct HMAC.
> 
> 				-- Mike
> 
MACs.  I
> keep asking for a use case where this makes sense.  In all of the use
cases that I
> have been presented so far, a better answer is going to be to do an AEAD
> encrypted item rather than a MACed item.
> 
message
> contains data or misinformation and will act on the message as if it were
data.
> What use cases exist for this where encryption is not a better security
answer
> anyway.

---

From: Mike Jones <[email-masked]>
Date: Tue, 17 Nov 2015 01:33:49 +0000

For starters - there's no need for encryption support.  Also, the ID Token claims are viewable by intermediaries.

But I really think you have the question backwards.  Why not allow applications the choice of HMAC?  Unless there's a compelling reason not to, COSE should do so - particularly in light of the JOSE experience in which no-explicit-recipient HMAC is second-most used behind digital signatures, with encryption being a distant third - data also cited recently by Justin.  If you look at the set of JOSE libraries represented at http://openid.net/developers/libraries/#jwt, you'll find that most, including Microsoft's current production JOSE libraries, don't support encryption, because they don't have a need for it.

I see no reason not to allow the same implementation choices by COSE developers.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 5:21 PM
To: Mike Jones; [email-masked]
Subject: RE: [COSE] MAC with no recipient structures

For this case, what is the benefit that you see for favoring HMAC over AES-GCM?

Jim

authenticated
to
-
> replacing the JWT-based ID Token with a CWT-based ID Token.  This 
> would often be used with symmetric crypto, where per RP/IdP symmetric 
> HMAC keys are employed.  The ID Token (containing information about 
> the
authentication
> do
not
MACs.  I
cases that I
> have been presented so far, a better answer is going to be to do an 
> AEAD encrypted item rather than a MACed item.
> 
message
data.
> 
> The difference in message size between MAC and Encryption is going to 
> be minimal, at most a few bytes.  The execution difference is going to 
> be a
few
answer

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 19 Nov 2015 12:22:48 +0100

Hi Jim,

"Jim Schaad" <[email-masked]> writes:

> I just read through the section referenced and did not see any reason
> for C and CAM to have access to the content.  I will try and read the
> entire document later today as that might describe the reasoning.

the reason comes from the way authorization is used. That would be a
long discussion more related to ACE than COSE.

> However, you are saying that it is ok for incorrect content to be in
> this message as far as C and CAM are concerned?

No, it would not. My draft assumes that this structure is passed within
the payload of an encrypt structure hop-by-hop.

Grüße
Olaf

---

From: Justin Richer <[email-masked]>
Date: Fri, 20 Nov 2015 02:26:52 -0500

What I'm hearing from this thread is a lot of support for plain MAC 
structures, including several documented use cases. Not the least of 
which is mapping to JOSE's HS* algorithm suite in JWS, one of the two 
most-used and most-successful portions of JOSE to date.

Consequently, I'm not seeing any consensus to drop plain MAC support in 
favor of any other method. I'm also not seeing opposition to defining 
AEAD structures in addition to MAC structures in COSE and allowing 
applications to choose.

Therefore, we'll keep MAC in place until there's sufficient consensus to 
remove the capability from COSE.

Thank you,
  -- Justin, your COSE chair.

---

From: Mike Jones <[email-masked]>
Date: Sat, 21 Nov 2015 19:54:24 +0000

As a point of clarification, this thread wasn't about removing MAC.  It was about adding a MAC representation with no explicit recipient - the equivalent of the JWS example in http://tools.ietf.org/html/rfc7515#section-3.3.

This feature request is tracked as https://github.com/cose-wg/cose-issues/issues/10 - Make "recipients" field optional.

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Thursday, November 19, 2015 11:27 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] MAC with no recipient structures

What I'm hearing from this thread is a lot of support for plain MAC structures, including several documented use cases. Not the least of which is mapping to JOSE's HS* algorithm suite in JWS, one of the two most-used and most-successful portions of JOSE to date.

Consequently, I'm not seeing any consensus to drop plain MAC support in favor of any other method. I'm also not seeing opposition to defining AEAD structures in addition to MAC structures in COSE and allowing applications to choose.

Therefore, we'll keep MAC in place until there's sufficient consensus to remove the capability from COSE.

Thank you,

On 11/7/2015 5:39 PM, Jim Schaad wrote:
> answer is going to be to do an AEAD encrypted item rather than a MACed item.
>
> Eve needs to be able to read the data in transit, without knowing if 
> the message contains data or misinformation and will act on the 
> message as if it were data.
>
> be a few extra encryption operations.
>

---

From: Francesca Palombini <[email-masked]>
Date: Wed, 25 Nov 2015 14:42:50 +0000

Hi,

In the context of "visibility" another use case was mentioned before(*): electricity consumption is measured by a meter, forwarded to a gateway where the tenant reads the consumption and further to the distribution operator. The communication between meter and gateway, and gateway and network is protected on transport layer; and between meter and network on application layer, using COSE. Encryption of the COSE message does not allow the tenant to read the metering. 

Multiple recipients here are not necessary and, for optimization reasons, the COSE message should be able to omit the recipient structure (analogously to the COSE_Encrypted structure).

(*) https://mailarchive.ietf.org/arch/msg/core/hmIcl0WIceg26h5clQ4Qv4kcfGk 

Francesca

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: den 21 november 2015 20:54
To: Justin Richer; Jim Schaad; [email-masked]
Subject: Re: [COSE] MAC with no recipient structures

				-- Mike

-----Original Message-----
From: COSE [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Thursday, November 19, 2015 11:27 PM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [COSE] MAC with no recipient structures

Thank you,

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 25 Nov 2015 10:49:11 -0800

Again, let me ask the question.  Are you willing to be in a position where
the tenant reads and acts on an incorrect data value since it cannot
validate the MAC on the data.

> From: Francesca Palombini [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2015 6:43 AM
> To: Mike Jones <[email-masked]>; Jim Schaad
> <[email-masked]>; [email-masked]
> In the context of "visibility" another use case was mentioned before(*):
> electricity consumption is measured by a meter, forwarded to a gateway
where
> the tenant reads the consumption and further to the distribution operator.
The
> communication between meter and gateway, and gateway and network is
> protected on transport layer; and between meter and network on application
> layer, using COSE. Encryption of the COSE message does not allow the
tenant to
> read the metering.
> 
> Multiple recipients here are not necessary and, for optimization reasons,
the
> COSE message should be able to omit the recipient structure (analogously
to the
> COSE_Encrypted structure).
> 
> As a point of clarification, this thread wasn't about removing MAC.  It
was about
> adding a MAC representation with no explicit recipient - the equivalent of
the
> JWS example in http://tools.ietf.org/html/rfc7515#section-3.3.
> 
> This feature request is tracked as https://github.com/cose-wg/cose-
> issues/issues/10 - Make "recipients" field optional.
> 
> 				-- Mike
> 
structures,
> including several documented use cases. Not the least of which is mapping
to
> JOSE's HS* algorithm suite in JWS, one of the two most-used and most-
> successful portions of JOSE to date.
> 
favor
> of any other method. I'm also not seeing opposition to defining AEAD
structures
> in addition to MAC structures in COSE and allowing applications to choose.
> 
remove
> the capability from COSE.
> 
> Thank you,

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Nov 2015 14:04:11 -0500

(As an individual)

Speaking from my own experience with JOSE, the simplicity and utility of MAC-only cannot be denied. I can only see this being compounded in constrained environments. Decrypting payload means I need to keep two copies of the data around, I need to manage encryption state, and I need to solve issues with multiple recipients or components that need just read access. All of these go away with simple signatures or MACs without losing functionality or security. Security is always contextual in the application, and complexity is the enemy of getting security actually applied in a system.

I see absolutely zero reason to not support this simplified case, and others have made it clear it’s desirable for their use cases. I think the burden is on you (Jim) to prove that it’s not desirable, and I’m not personally seeing support for that position in this working group.

 — Justin (as an individual, remember)

> On Nov 25, 2015, at 1:49 PM, Jim Schaad <[email-masked]> wrote:
>