Re: [COSE] COSE Support for AES-CTR and AES-CBC

Brendan Moran <brendan.moran.ietf@gmail.com> Mon, 07 November 2022 11:03 UTC

Return-Path: <brendan.moran.ietf@gmail.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14CEC1524B7 for <cose@ietfa.amsl.com>; Mon, 7 Nov 2022 03:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4b5Z4Fw5I2d for <cose@ietfa.amsl.com>; Mon, 7 Nov 2022 03:03:57 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BFAC1524C7 for <cose@ietf.org>; Mon, 7 Nov 2022 03:03:57 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id l11so16935375edb.4 for <cose@ietf.org>; Mon, 07 Nov 2022 03:03:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HusaGOwH3FMbmgEWxIDNlyPmh5Si4uy/uuIGKLocuaI=; b=PPWLek7WErG1BIniI3yEz6gtgApI1z5qCiZJPRkpzYoToCp/5XKLqFVz5bWwpL6mKn m8TkxVqMehCWfOQ1FxcznZmmC+pKbec8Mr5BGOvxKB8zs/3n9t4Z6X1/DzdQF1FvRIFX l1sgKrSd3JcmEZFEbw1kuX9ol2xaYONVATZMytgm315/83+r/EaA5F2DHWHoYsnomJAz cLJ4u2g3JwRuuT7Vs56xqajBhWehzVMF/BY64aGQ0OgRuKbt6iHxcBX3WCRNUSyss0Dc lPGfijs/adLxSLDDbXIq0No/lE6/m+89yTFDsB8ln3jdnEl/xX0a5E5G3LMBtauztYdu ZHUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HusaGOwH3FMbmgEWxIDNlyPmh5Si4uy/uuIGKLocuaI=; b=jJvI9Yp0nYlLu4OvlhOiJVcTzmcxgo4K2Z9jp24jFmg654e9QotUQ7DuvEinr7GK4j PRjULluFmaig6+URIGYQU1Fo9Dh1cX+vUbbgxoWkxSHO0bp5hdX7dOrBgPrILfJQjWDR kf9csvYHMwKaHGowJU7eQCyjN8ZysBqFDxUTdrmCk1GqUXxyw3AuKm2syR37osVOJt+p jCb5wEoE/2Yi6+KC5DgfpkkKGIfQdXTvw6HhxoIDsRkMeUPnt9hXHF99nKZggQNMYjl+ Dg1qEtv5o0YnRXTYGK8jj3NvA80EDt5sE21czwzzazKOYpeLE656ATm2lTk3Gc2CHVgZ xWxQ==
X-Gm-Message-State: ACrzQf1sXva7ZiTMz37W/y1SQifHbhzpYl5Zd3suD1gCoSxRlMPmcED1 RSek4gQjGPq7jppZRrxKjasnsaql/B9eh0aNR7s=
X-Google-Smtp-Source: AMsMyM58fb8JO+/BlKbQHGEolzYsITjsIHZ0IreNblhQhUt8qKinrkXox8h+H9SLeIA+Lzcw58xtGgsy0LQcbSRGVD8=
X-Received: by 2002:aa7:dbc6:0:b0:464:6bce:97c with SMTP id v6-20020aa7dbc6000000b004646bce097cmr17062869edt.310.1667819034669; Mon, 07 Nov 2022 03:03:54 -0800 (PST)
MIME-Version: 1.0
References: <CO1PR00MB13086039D60B9997AE5F5928F54E9@CO1PR00MB1308.namprd00.prod.outlook.com> <SA1PR00MB1310AB40F32B3B2E9FC36D31F5239@SA1PR00MB1310.namprd00.prod.outlook.com> <ADE35F26-5BF8-4205-A8B5-36C1F55E8207@vigilsec.com> <32d84d35531543469a4a196a7b137cb1@amazon.com> <39D0918E-F757-4205-9D27-882E4587F95A@vigilsec.com>
In-Reply-To: <39D0918E-F757-4205-9D27-882E4587F95A@vigilsec.com>
From: Brendan Moran <brendan.moran.ietf@gmail.com>
Date: Mon, 07 Nov 2022 11:03:43 +0000
Message-ID: <CAPmVn1N7brE5SsgTU9n3ubCY3NExZfrgobkubRx7671LbU5Tcg@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>, s.fluhrer@cisco.com
Cc: "Arciszewski, Scott" <scottarc@amazon.com>, "cose@ietf.org" <cose@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001c86c905ecdf61f6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/QlKzCO69SldRlpmrTkDSaFmGOs8>
Subject: Re: [COSE] COSE Support for AES-CTR and AES-CBC
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 11:03:57 -0000

I talked with Scott Fluhrer today about this use case and he’s pointed out
that GCM can be processed out of order.

Scott, would you be able to elaborate on this?

Best Regards,
Brendan

On Wed, 26 Oct 2022 at 22:51, Russ Housley <housley@vigilsec.com> wrote:

> Scott:
>
> Introducing AES-CTR and/or AES-CBC into COSE tokens that already support
> AES-GCM will open the GCM implementations to new security issues. Namely,
> potential padding oracle vulnerabilities.
>
>
> I think that adding a reference to the existing paragraph in the Security
> Considerations will address this concern:
>
>    With AES-CBC mode, implementers SHOULD perform integrity checks prior
>    to decryption to avoid padding oracle vulnerabilities [Vaudenay].
>
> At minimum, the Security Considerations section of
> draft-ietf-cose-aes-ctr-and-cbc-01 needs to call this risk out:
> Applications that encrypt or decrypt with AES-GCM *MUST NOT* support
> AES-GCM or AES-CTR with the same cryptographic materials, due to the
> existence of cross-protocol issues. One way to safeguard users from
> potential misuse is to use a separate "type" for keys used with
> unauthenticated encryption modes; similar to how COSE distinguishes MACs
> from Signatures.
>
>
> I suggest an addition paragraph in the Security Considerations:
>
>    To avoid cross-protocol concerns, implementations MUST NOT use the
>    same keying material with AES-CTR and AES-GCM.  Likewise,
>    implementations MUST NOT use the same keying material with AES-CTR
>    and AES-CCM.
>
> Additionally, I'd like to recommend sharing this draft with the CFRG
> mailing list to ensure it has the appropriate level of oversight from the
> IETF's cryptography experts.
>
>
> AES-CTR and AES-CBC are not new cryptographic modes.  New techniques
> deserve CFRG review, but AES-CTR and AES-CBC have been included in RFCs for
> many years.
>
> Russ
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose
>