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,

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