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

[John Mattsson <[e-mail]>]

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 <[e-mail]>
Date: Monday, 17 May 2021 at 08:57
To: Michael Richardson <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8

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

-----Original Message-----
From: Michael Richardson <[e-mail]>
Date: Thursday, 13 May 2021 at 20:01
To: John Mattsson <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8


John Mattsson <john.mattsson=[e-mail]> 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
    > OSCORE.

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

    > AEAD() || Countersignature( AEAD() )

    > to

    > 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide