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

[John Mattsson <[e-mail]>]

Hi,

I just posted the following suggsted addition to the COSE countersign draft

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

https://mailarchive.ietf.org/arch/msg/cose/9vv0DC_7tL1_DfvHd4VNp-dXz38/

Earlier versions of Group OSCORE had these quite significant vulnerabilities. My
understanding is that this weakness is addressed in the current version of Group
OSCORE by adding more information to the signature external_aad. 

However, I see no reason to actually use countersignatures in Group OSCORE.
The definition of countersignature in the oxford dictionary is
"a signature added to a document already signed by another person." The use in
Group OSCORE where the same entity calculates the AEAD and the signature seems
very strange, and there seems to be no good reason for it. Wrapping the COSE_Encrypt
in a COSE_Sign seems like a much more natural solution. 

The COSE WG will soon register AEAD algorithms without integrity protection such
as AES-CTR. The is after a request from FIDO that wants to wrap a COSE_Encrypt
in a COSE_MAC.

https://mailarchive.ietf.org/arch/msg/cose/ELiOc-ED9IoaFhR5d9FS7KBC-vc/

The use of AEAD together with a signature waste 8-16 bytes in each packet
without any benefit whatsoever. This goes very much against the design
philosofies behind CoAP and OSCORE, where every byte has to be justified.

Now when COSE WG is specifying "AEAD" algorithms without integrity protection
I think CORE should take the time to modify the signature parts of
Group OSCORE from

AEAD() || Countersignature( AEAD() )

to 

ENC() || Signature ( MAC( ENC() ) )

Cheers,
John

-----Original Message-----
From: John Mattsson <[e-mail]>
Date: Thursday, 13 May 2021 at 14:04
To: Russ Housley <[e-mail]>
Cc: cose <[e-mail]>
Subject: Re: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8

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 <[e-mail]>
Date: Monday, 15 March 2021 at 17:58
To: John Mattsson <[e-mail]>
Cc: cose <[e-mail]>
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=[e-mail]> 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