Re: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8

John:

Thanks.  I wonder it it would be better go a bit higher level.  I am not sure that the external_add really has an impact on choosing whether the COSE_Mac is a good countersign mechanism.

I think there are two points:

1) When either COSE_Encrypt and COSE_Mac is used and more than two parties share the key, data origin authentication is not provided.  Any party that knows the message-authentication key can compute a valid authentication tag; therefore, the contents could originate from any one of the parties that share the key.

2) Countersignatures of COSE_Encrypt and COSE_Mac with short authentication tags do not provide the security properties associated with the same algorithm used in COSE_Sign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSE_Mac with AES-MAC 256/128 provides at most 64 bits of integrity protection.  Similarly, a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 provides at most 32 bits  bits of integrity protection.

What do you think?

Russ

> On May 13, 2021, at 8:04 AM, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi Russ,
> 
> I made a PR with a first draft of such text
> 
> https://github.com/cose-wg/countersign/pull/6
> 
> "Countersignatures of COSE_Encrypt and COSE_Mac with short tags and non-empty external_aad do not at all give the security properties normally associated with the same algorithm used in COSE_Sign. To provide 128-bit security against collision attacks, the tag length MUST be at least 256-bits. A countersignature of a COSE_Mac with AES-MAC 256/128 only gives 64-bit security and a countersignature of a COSE_Encrypt with AES-CCM-16-64-128 only gives 32-bit security. Another solution is to provide the same external_aad used in the COSE_Encrypt and COSE_Mac to the countersignature algorithm, but this external_aad is typically not available to the party performing or verifying the countersignature."
> 
> Cheers,
> John
> 
> -----Original Message-----
> From: Russ Housley <housley@vigilsec.com>
> Date: Monday, 15 March 2021 at 17:58
> To: John Mattsson <john.mattsson@ericsson.com>
> Cc: cose <cose@ietf.org>
> Subject: Re: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8
> 
> John:
> 
> Are you asking for addition text in the security considerations to warn against short MACs?  If so, can you provide the first draft of such text?
> 
> Russ
> 
> 
>> On Mar 12, 2021, at 3:12 AM, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> 
>> When I analysed an earlier version of Group OSCORE some years ago it had severe security problems when used with CCM_8 + Countersignature. The attacks were pretty bad. 64-bit offline complexity against source authentication/availability from a different person in the group and something slightly over 32-bit online security (collecting 2^32 messages) against a source authentication/availability from a third party outside of the group. The problem was that the countersignature relied on the AEAD tag for integrity protection of the additional data. This was fixed in Group OSCORE be adding all the additional data to the signature as well.
>> 
>> The use case of Countersignatures is "Countersignatures provide a method of having a second party sign some data." In this case I don't think CCM_8 + Countersignature provides the expected security. Unless you can put all the additional data to the signature as well, I think CCM_8 + Countersignature needs to be forbidden.
>> 
>> I don't really see why Group OSCORE is using countersign in the first place, it seems like a relic from a time when it was assumed that OSCORE would be a single COSE structure on the wire as well.
>> 
>> Cheers,
>> John
> 
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose