Subject: Re: [COSE] MAC with no recipient structures

From: "Jim Schaad" <[email-masked]>
Date: Sun, 6 Dec 2015 17:58:30 -0800

> -----Original Message-----
> From: Justin Richer [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2015 11:04 AM
> To: Jim Schaad <[email-masked]>
> Cc: Francesca Palombini <[email-masked]>; [email-masked]
> Subject: Re: [COSE] MAC with no recipient structures
> 
> (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 would not agree with some of these points.

I do believe that MAC has a large utility and is not going to be removed.  

I do not necessarily agree that it has a larger amount of utility over encryption in a constrained environment.  One of the big advantages of using CTR modes of encryption is that encrypting in place is even easier than it is with any version that does padding.  This means that one does not necessarily need to have two copies of the data around.  

It is true that there is some additional data that needs to be managed when doing encryption rather than a MAC.  It is not clear that there is a significant amount of data that needs to be managed.  If one assumes that some type of replay counter is maintained in both cases, then this additional data amounts to an IV prefix which is constant and thus has minimal maintenance associated with it.  (I.e. it needs to be kept and associated with the key.)

The issues dealing with allowing multiple recipients or components that just need read access is an interesting question to be addressed, and one that points to the question that I keep asking.  Does that other entity that needs read access need to have the ability to know that the data is correct?  If the entity needs to be able to validate the information, then using MACs or using encryption have the exact same level of complexity for dealing with multiple recipients and multiple keys.  There is a difference between doing "simple signatures" and the MAC/encryption case because how key management is done is completely different.   The expected security properties of are very different between the signature and the MAC case as well.

Finally, I would point out that the total security system is not necessarily the same for a constrained and an unconstrained system.  OAuth as it is commonly used today is sending MAC messages using TLS.  The fact that TLS is being used means that, from a security analysis, the only parties that would have read access to the MAC message are the parties at each end of the TLS connection.  One does not end up in situations (or at least I am assuming that one does not) where there are proxies that are going to be between these entities that also have access to the data.  This is not the case many times for a DTLS situation in the constrained environments that are being contemplated where provisions are being made for doing things like TLS<=>DTLS proxies, proxies that mediate between different sub-networks and so forth are expected components to be dealt with.   The security system and the analysis associated with it can be very different between the OpenID case and the access granting case of a CoAP network.

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

So other than the OSCoAP people, who have a use case that they are planning to use this for?  I am hearing a lot of people saying that they need it because that is what JOSE does.  I am not hearing a lot of people saying that they have a concrete use case for it.  I do not expect that COSE is going to replace JOSE for general JWT usage.

Jim

> 
>  — Justin (as an individual, remember)
> 
> > On Nov 25, 2015, at 1:49 PM, Jim Schaad <[email-masked]> wrote:
> >
> > 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.
> >
> >> -----Original Message-----
> >> 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]
> >> Subject: RE: [COSE] MAC with no recipient structures
> >>
> >> 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/hmIcl0WIceg26h5clQ4Qv4kcfG
> >> k
> >>
> >> 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
> >>
> >> 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,
> >>  -- Justin, your COSE chair.
> >>
> >> On 11/7/2015 5:39 PM, Jim Schaad wrote:
> >>> 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
> >>>
> >>>
> >>> _______________________________________________
> >>> COSE mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/cose
> >>
> >> _______________________________________________
> >> COSE mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/cose
> >>
> >> _______________________________________________
> >> COSE mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/cose
> >
> > _______________________________________________
> > COSE mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cose

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 10 Dec 2015 16:54:23 +0100

I wanted to contribute my thoughts on this statement:

> On 11/7/2015 5:39 PM, Jim Schaad wrote: 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.

When Erik and I worked on an OAuth doorlock access control scenario and
tried to take this aspect into account (based on the suggestion from
Jim) by doing two things (with relevance to ACE):
 * use an AEAD cipher for protection of the JWT, and
 * use an AEAD cipher for use with the proof of possession when the
client talks to the resource serve (=door lock)

While we haven't used CBOR/COSE yet (but the JWT) it did not lead to any
problems from that point of view. The implication of using encryption
was that the JWT content was not visible to the client, which it
shouldn't be anyway.

Of course, there are more scenarios to look into but this is our current
experience. We are going to switch to CBOR and COSE and will
let you know what the experience was. So, consider this a
work-in-progress activity.

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Fri, 11 Dec 2015 13:48:46 -0700

In my own experience with JOSE compact serializations and JWT (which I
realize isn't directly analogous to COSE but somewhat informative
nonetheless) I must say that I've found a ton of utility in JWE's symmetric
AEAD messages and pretty much exclusively use it over MAC nowadays. It is
more complicated though - looking back
<https://bitbucket.org/b_c/jose4j/wiki/Release%20Notes> I see that I had
JWS HSxxx support nearly a year before any JWE support.  And there are
still some JOSE/JWT libraries that only support the HMAC algorithms -
http://jwt.io/ has a pretty good survey of them and there aren't as many as
I remember but definitely some that are MAC only. There is something to the
simplicity.

In my view a MAC with no recipient structures isn't a particularly
necessary thing in and of itself. But I see this more as a proxy argument,
of sorts, from the faction of folks who'd like to see first order support
for all the single recipient and single signature cases. The expectation is
that single recipient/signature messages will be the vast majority of what
actually happens and it'd be nice to have direct and simplified support for
it rather than just being a sub case of the more general and more
complicated multi recipient/signature cases.

On Thu, Dec 10, 2015 at 8:54 AM, Hannes Tschofenig <
[email-masked]> wrote:

> > I do not necessarily agree that it has a larger amount of utility over
> encryption in a constrained environment.  One of the big advantages of
> using CTR modes of encryption is that encrypting in place is even easier
> than it is with any version that does padding.  This means that one does
> not necessarily need to have two copies of the data around.
> >
> > It is true that there is some additional data that needs to be managed
> when doing encryption rather than a MAC.  It is not clear that there is a
> significant amount of data that needs to be managed.  If one assumes that
> some type of replay counter is maintained in both cases, then this
> additional data amounts to an IV prefix which is constant and thus has
> minimal maintenance associated with it.  (I.e. it needs to be kept and
> associated with the key.)
> >
> > The issues dealing with allowing multiple recipients or components that
> just need read access is an interesting question to be addressed, and one
> that points to the question that I keep asking.  Does that other entity
> that needs read access need to have the ability to know that the data is
> correct?  If the entity needs to be able to validate the information, then
> using MACs or using encryption have the exact same level of complexity for
> dealing with multiple recipients and multiple keys.  There is a difference
> between doing "simple signatures" and the MAC/encryption case because how
> key management is done is completely different.   The expected security
> properties of are very different between the signature and the MAC case as
> well.
> >
> > Finally, I would point out that the total security system is not
> necessarily the same for a constrained and an unconstrained system.  OAuth
> as it is commonly used today is sending MAC messages using TLS.  The fact
> that TLS is being used means that, from a security analysis, the only
> parties that would have read access to the MAC message are the parties at
> each end of the TLS connection.  One does not end up in situations (or at
> least I am assuming that one does not) where there are proxies that are
> going to be between these entities that also have access to the data.  This
> is not the case many times for a DTLS situation in the constrained
> environments that are being contemplated where provisions are being made
> for doing things like TLS<=>DTLS proxies, proxies that mediate between
> different sub-networks and so forth are expected components to be dealt
> with.   The security system and the analysis associated with it can be very
> different between the OpenID case and the access granting
> case of a CoAP network.
> >
> >>
> > So other than the OSCoAP people, who have a use case that they are
> planning to use this for?  I am hearing a lot of people saying that they
> need it because that is what JOSE does.  I am not hearing a lot of people
> saying that they have a concrete use case for it.  I do not expect that
> COSE is going to replace JOSE for general JWT usage.
> >
> > Jim
> >
> >>