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

From: John Mattsson <[email-masked]>
Date: Thu, 13 May 2021 14:14:46 +0000

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 <[email-masked]>
Date: Thursday, 13 May 2021 at 14:04
To: Russ Housley <[email-masked]>
Cc: cose <[email-masked]>
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 <[email-masked]>
Date: Monday, 15 March 2021 at 17:58
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
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=[email-masked]> 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

---

From: John Mattsson <[email-masked]>
Date: Thu, 13 May 2021 14:34:26 +0000

Hi,

Another big disadvantage with the current design is that the user to chose between more useless in the signature mode and less security in pair-wise.

In the signature mode, the tag provides no security and you want as small as possible. For pair-wise many application would definitly want to use 16 bytes tags, e.g. application aligning with the CSNA suite.

I think 8-18 additional bytes overhead for the signature mode makes a difference. One example would be warning broadcasts in cellular networks. In some networks the amount of data that can be broadcasten with acceptable latency is 75 bytes. Group OSCORE without the useless AEAD tag could be used, but Group OSCORE with the tag cannot.

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Thursday, 13 May 2021 at 16:14
To: "[email-masked]" <[email-masked]>
Subject: FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8

Hi,

to 

Cheers,
John

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

Hi Russ,

Cheers,
John

-----Original Message-----
From: Russ Housley <[email-masked]>
Date: Monday, 15 March 2021 at 17:58
To: John Mattsson <[email-masked]>
Cc: cose <[email-masked]>
Subject: Re: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8

John:

Russ

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 May 2021 14:01:01 -0400

John Mattsson <john.mattsson=[email-masked]> wrote:
    > 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

I don't understand the need.  I know that the countersignature use in Group
OSCORE was compatible with RFC8152, but beyond that, I never quite understand
how it was used.

I'd like to ask if there are some slides from ACE that might help illuminate
this?

    > 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

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

Hmm. I see your point, I think.
I don't have the right pieces of OSCORE paged in to understand the impact to
existing protocols, or if they are even far enough along to deal.

But, sometimes, better is the enemy of good enough.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: John Mattsson <[email-masked]>
Date: Mon, 17 May 2021 06:57:20 +0000

Hi,

I think the RFC 8613 'AEAD Algorithm' should be reserved for the cases were there is no signature, e.g. pair-wise, then the group request mode with signatures would have to have additional algorithms to be used with the signature algorithm. The signature construction needs to be changed so that it is secure with AES-CTR and ChaCha20 when standardized by COSE WG.

- It would be very strange to force people wanting to use AES-CCM, AES-GCM, or ChaCha20-Poly1305 or other 16-bit tag algorithms in pair-wise to use 80-byte source authentication, when it can trivially by done with 64 bytes. While the TLS conclusions regarding CCM_8 is misleading, I think there will be a trend toward 128 bit tags. Many deployments for government and financial institutions always use 128 bit tags.

- Some aspects of the "verifying the request" is not well specified today, maybe as a consequence of the symmetric tag + siggnature construction. The order of decrypt, signature verification, and update of the replay window is not defined. This need to be exactly specified or stated what can be done in parallel. The current text about replay window update is liked to decryption, this need to be changed as the replay window linked to the sender can absolutely not be updated unless the signature (source authentication) verifies.

Cheers,
John

---

From: John Mattsson <[email-masked]>
Date: Wed, 19 May 2021 03:38:16 +0000

Hi,

Other security problems found in the past related to an attacker removing the signature was purely related to the questionable choice to use a have the sender countersign it's own AEAD ciphertext. Due to this some important features were removed from an earlier version.

After discussion in COSE the currently suggested text in draft-ietf-cose-countersign will likely be:

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

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

I'll make a PR to align draft-ietf-core-oscore-groupcomm with the security consideration in draft-ietf-cose-countersign, significantly lower the overhead, and try to restore the important features that were removed.

Cheers,
John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Monday, 17 May 2021 at 08:57
To: Michael Richardson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8

Hi,

Cheers,
John