IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 May 2021 18:01 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9AF3A08FE for <core@ietfa.amsl.com>; Thu, 13 May 2021 11:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xtx3THjt0C17 for <core@ietfa.amsl.com>; Thu, 13 May 2021 11:01:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC93F3A091B for <core@ietf.org>; Thu, 13 May 2021 11:01:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D51E639152; Thu, 13 May 2021 14:10:07 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Xo4QdgXRa3TH; Thu, 13 May 2021 14:10:07 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 616F439147; Thu, 13 May 2021 14:10:07 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DBEE0688; Thu, 13 May 2021 14:01:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "core\@ietf.org" <core@ietf.org>
In-Reply-To: <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com>
References: <DE090650-4B4B-48C9-B4A5-3B809E1C1FF4@ericsson.com> <46B45227-684C-4CDB-A2B6-20BA70E89DF6@vigilsec.com> <D1BF84E8-5659-4AF8-8F27-BD5409BEFA83@ericsson.com> <2EF50329-22AD-4797-B8F5-89684E4CCC29@ericsson.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 13 May 2021 14:01:01 -0400
Message-ID: <7253.1620928861@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tY0AD2fuF5LHS5IWhSOXEhPhsVE>
Subject: Re: [core] FW: [COSE] draft-ietf-cose-countersign-02 - Secruity problems with COSE_Encrypt and COSE_Encrypt0 with CCM_8
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2021 18:01:18 -0000

John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.10.0 | Report a Bug | By Email