Re: [lamps] Does 6211 actually do what it claims to?

Russ Housley <housley@vigilsec.com> Wed, 02 June 2021 20:51 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35553A1ACA for <spasm@ietfa.amsl.com>; Wed, 2 Jun 2021 13:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level:
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 7bnBWI-nul3W for <spasm@ietfa.amsl.com>; Wed, 2 Jun 2021 13:51:09 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D3D3A1AA5 for <spasm@ietf.org>; Wed, 2 Jun 2021 13:51:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1CB72300BEB for <spasm@ietf.org>; Wed, 2 Jun 2021 16:51:08 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HAeeudnGIcJZ for <spasm@ietf.org>; Wed, 2 Jun 2021 16:51:02 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 94808300AB0; Wed, 2 Jun 2021 16:51:02 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CH0PR11MB57392493D228A338A78F7B619F3E9@CH0PR11MB5739.namprd11.prod.outlook.com>
Date: Wed, 02 Jun 2021 16:51:02 -0400
Cc: LAMPS <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B991DD7-BC2E-4C1F-A5DB-DDCEDAAE477B@vigilsec.com>
References: <CH0PR11MB57392493D228A338A78F7B619F3E9@CH0PR11MB5739.namprd11.prod.outlook.com>
To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>
X-Mailer: Apple Mail (2.3445.104.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ohACmIrswLDqLWcYcMD7TQJLUY4>
Subject: Re: [lamps] Does 6211 actually do what it claims to?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 20:51:22 -0000

Mike:

In CMS SignedData and AuthenticatedData, then algorithm identifiers are not covered by the signature or MAC, respectively.

RFC 6211 provides an signed attribute / authenticated attribute to provide this capability. 

      CMSAlgorithmProtection ::= SEQUENCE {
          digestAlgorithm         DigestAlgorithmIdentifier,
          signatureAlgorithm  [1] SignatureAlgorithmIdentifier OPTIONAL,
          macAlgorithm        [2] MessageAuthenticationCodeAlgorithm OPTIONAL }

In X.509 certificates, the signature algorithm appears twice.  One of them is covered by the issuer's signature.  RFC 6211 provides essentially the same thing.

Russ

> On Jun 1, 2021, at 5:26 PM, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> wrote:
> 
> This is maybe a dumb question coming from a relative PKIX newcomer.
> 
> RFC 6211 sets out to solve algorithm substitution attacks in CMS by including the digestAlgorithm, and either signatureAlgorithm or macAlgorithm in the digested-and-signed content.
> 
> Cheekily: does this actually solve algorithm substitution attacks?
> 
> Seems like a chicken-and-egg situation where, during signature verification, you are using the (currently unverified) content to tell you how to verify the content. In particular, 6211 puts the digest alg id inside the digest, and therefore it's fair game for manipulation during a hash collision attack. 
> 
> PKCS#1 v1.5 puts the digest alg id outside (ie next to) the digest in the signed data, which seems like it gets you out of the checken-and-egg situation because now you would need a collision in the signature primitive, not in the hash primitive (ie it's now the sig primitive protecting the hash primitive, rather than the hash primitive protecting itself). RSA-PSS internally does something that looks distinctly HMAC-y, so it's probably ok too but for different reasons.
> 
> 
> Furthermore, a quote from Kaliski, Burton, 2002, "On hash function firewalls in signature schemes":
> 
> "Note that identifying the hash function in the message itself is not enough; it is likely as easy for an opponent to control the identifier as any other part of a message when forging a signature." 
> 
> .. which seems exactly what 6211 has done.
> 
> 
> 
> So, am I missing something, or are hash function substitution attacks only really solvable via the construction of the signature primitive, and not at the protocol layer? In which case, 6211 does not actually solve the problem that it set out to solve?
> 
> 
> 
> PS: I also posted this to stack exchange: https://crypto.stackexchange.com/q/90318/24012
> 
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm