Re: [lamps] [EXTERNAL] pre-hashing the OID in draft-ounsworth-pq-composite-sigs-10
Falko Strenzke <falko.strenzke@mtg.de> Tue, 21 November 2023 09:13 UTC
Return-Path: <falko.strenzke@mtg.de>
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 44BBCC14CF1F; Tue, 21 Nov 2023 01:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=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=mtg.de
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 se53Jfj5zhyB; Tue, 21 Nov 2023 01:13:23 -0800 (PST)
Received: from www.mtg.de (www.mtg.de [IPv6:2a02:b98:8:2::2]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 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 0C8CDC15107C; Tue, 21 Nov 2023 01:13:18 -0800 (PST)
Received: from minka.mtg.de (minka [IPv6:2a02:b98:8:1:0:0:0:9]) by www.mtg.de (8.17.2/8.17.2) with ESMTPS id 3AL9Cvib004713 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Tue, 21 Nov 2023 10:12:58 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mtg.de; s=mail201801; t=1700557978; bh=N2TlUAEk/ax3E73Md6e9AlU3a5Da9kun83mOmbaQpzY=; h=Date:Subject:To:References:From:In-Reply-To; b=KF1I8D4x1HPEH1L0mGHB/rAOb7TxoXdfTHJta/K9bbZOpxXoxyAWGat/MXs4Q1uhk 3aCf6EGl9faSSaIINdvXkINbGYC7yWR2DMGQ4raoI5a+aW2KO2UvBb+7vggAVcdtr5 rRGrzuFlxokuoMSnpbH9b8cZRFdivEJ4piD3WrPLCTpD165PAKvEF+Og3aBJB4zkwN WmO3vnPBs/H7OmmQxYOHyd2TI9a0CYxr62PH50dzXW2Gg5inQyrGRxvIFJ7jd9dUU2 5+8GntQ/E+jbyyBObdrM05B27kEjQztFFwJiMcSCtVwBSokdXshbw73pRXGLLvdO3J Aq/634KhE5Zwg==
Received: from [10.8.0.100] (vpn-10-8-0-100 [10.8.0.100]) by minka.mtg.de (8.17.2/8.17.2) with ESMTPS id 3AL9CtHk012102 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Tue, 21 Nov 2023 10:12:55 +0100
Message-ID: <b0466142-f8ae-4881-8f7f-3f61af960d66@mtg.de>
Date: Tue, 21 Nov 2023 10:12:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: "David A. Cooper" <david.cooper@nist.gov>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, Tim Hollebeek <tim.hollebeek@digicert.com>, "draft-ounsworth-pq-composite-sigs@ietf.org" <draft-ounsworth-pq-composite-sigs@ietf.org>, LAMPS WG <spasm@ietf.org>
References: <1bb726c7-9eec-4ed5-a76c-a58e512888be@mtg.de> <DM8PR11MB57361E757E8D6C1EA360368D9FB1A@DM8PR11MB5736.namprd11.prod.outlook.com> <cff23584-a9ed-491d-9d38-4fdc2cd46b7f@mtg.de> <SN7PR14MB649297DDC4CEFE81AC05C8EC83B7A@SN7PR14MB6492.namprd14.prod.outlook.com> <CH0PR11MB57392831B1DAF09E75D3CAEE9FB6A@CH0PR11MB5739.namprd11.prod.outlook.com> <CH0PR11MB5444A86B68A09106553851E0C1B5A@CH0PR11MB5444.namprd11.prod.outlook.com> <769f2109-3c0f-4bae-bb82-476cab7f6774@mtg.de> <53b8e54f-f70b-4a86-ac17-8f0a91f6380f@nist.gov>
From: Falko Strenzke <falko.strenzke@mtg.de>
In-Reply-To: <53b8e54f-f70b-4a86-ac17-8f0a91f6380f@nist.gov>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms060804020003010503090504"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/GTL1SpoOEZUupp08n4ZRgz8Trx4>
Subject: Re: [lamps] [EXTERNAL] pre-hashing the OID in draft-ounsworth-pq-composite-sigs-10
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: This is the mail list for the LAMPS Working Group <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: Tue, 21 Nov 2023 09:13:29 -0000
Hi David, Am 21.11.23 um 01:33 schrieb David A. Cooper: > Hello Falko, > > I am unclear about the concern you are raising and the proposed > solution. Is the concern specific to the proposed composite signature > scheme or would it apply whenever a message could be signed using > either a "pure" or "prehash" option? > > If I understand correctly, you're concern is that if message M could > be signed as either: > > -- sig = sigalg(K, M); or > -- sig = sigalg(K, OID || Hash(M)); or > > then an attacker could obtain a "pure" signature for "OID || Hash(M)" > by requesting a "prehash" signature for "M," and that this is a > concern regardless of how the "prehash" input to the signing function > is constructed, e.g., "OID || Hash(M)", " 'prehash sig' || OID || > Hash(M) ", etc. Is this correct? Yes, it applies whenever there is an ambiguity with respect to what is signed in the sense that anyone can come up with one or more further validly signed messages given a validly signed message from the signer. This is called an existential signature forgery vulnerability (signing M yields M' ≠ M which can be verified with the same signature (in a different context)). That this is referred to as an existential signature forgery is a fact, not my opinion or interpretation. And I think also that a protocol being vulnerable to such forgeries is considered flawed is common sense. > > If so, isn't this already an issue with CMS? Content can be signed > using CMS by either signing the content itself or by signing a set of > signed attributes, one of which is the hash of the content. An > attacker could present some content to the signed using CMS, with the > CMS message containing signedAttrs. The attacker could then construct > a new CMS message with no signed attributes for which the signedAttrs > from the original message was the content. Yes, true! I discovered that last week, too, and wrote the attached paper about it, which I was even planning to make subject to responsible disclosure to give library maintainers some time to implement the countermeasures. Now that you are pointing out the vulnerability yourself I publish it right away. (I hope you believe me and don't assume I wrote it now after your revelation ;-) Actually I sent it to Russ already yesterday before your message to hear his opinion.) I think this kind of principal weakness is a concern and so far I met no one who was aware of that problem. And I can well imagine that some vendors are now going to review or test their systems to preclude that they are vulnerable – no matter how unlikely a harmful result may be assumed. > > This also seems related to general concerns about cross-application > attacks, where an attacker attempts to obtain a signature in one > context to exploit in another context. (For example, if an attacker > could obtain a signature generated for TLS server authentication and > somehow use that signature to perform TLS client authentication, and > thus impersonate the server.) Yes, very related. And this should show how serious the concerns about signature forgery vulnerabilities should be taken. Who had thought that TLS application layer confusion attacks would be possible until https://alpaca-attack.com/ ? I don't think it is good idea to design something with unsound crypto and then wait until a team from Ruhr-Uni Bochum (it's just a fact, most of the real world vulnerable broken crypto research comes from there) takes a closer look at real world applications using the flawed protocol. Efail is of course another perfect example – until then, no one saw a reason for updating the long known vulnerable CBC and CFB encryption in S/MIME and OpenPGP. > > Could you explain more about how using a different hash function > addresses the problem? Are you envisioning that the signature > algorithm could be used as a black box and one would preform the > pre-hashing using a different hash algorithm or are you suggesting the > use of a different hash algorithm inside the signing algorithm? Unless > I am misunderstanding your concern, it seems that it can not be > addressed if the signing algorithm is treated as a black box. I wouldn't really say that I am envisioning one or the other, because I am not convinced those separability defences are ultimately necessary. But my initial proposal (when I first mentioned it in a reply to John Gray) was indeed to treat the signature algorithm as a black box with the implication that one then is committed to hash-and-sign. That means a composite signature would be computed as S_i = Sign_i(pubKey_i, comp_hash(M)) where comp_hash(M) = cSHAKE(M, "pkix-composite-signature-hash-domain-separation-label) /// whatever order of the arguments to cSHAKE makes sense here, I haven't given that any attention here/ Then S_i brought into the standalone scheme context would not be verifiable, because in the standalone context comp_hash() does not exist and thus no preimage can be found for the hash. Surely, it might be worth exploring what is possible when opening up the black box of the signature scheme. Then we wouldn't have to commit to hash-and-sign. But then the traditional algorithm would have to be redesigned, too, because non-separability would require both algorithms to be "protected". This topic comes up again under 1. below. Two further notes: 1. There is also generally a problem if a protocol that doesn't fulfil what I describe under 2. wants to enable for instance SLH-DSA in two the variants direct-signing and with pre-hashing. Then again the signature of the pre-hash scheme would be valid for the message that amounts to the value of the pre-hash in the direct-signing scheme. This can be solved in two ways: 1a) by a protocol with the features described under 2. 1b) by ensuring domain separation for the two variants direct-signing/pre-hash in the signature algorithm like it is done in RFC 8032 <https://datatracker.ietf.org/doc/html/rfc8032#section-5.1>. This is what we mean by "opening up the black box". Thus, to facilitate the support of the variants direct-signing/pre-hash, NIST could consider to include a domain separation flag like in RFC 8032. (However, this cannot be so easily used to address the non-separability concerns since for that we would need to open up the black box of the existing traditional schemes, which is probably undesired, as mentioned above already.) 2. A protocol that *already* feeds the signature algorithm (and ideally, further context information) in a non-ambiguous way to the message digest computation as context information doesn't face any of these problems (neither separability nor direct-signing/pre-hashing), because it can simply assign different algorithm identifiers in each case and thus automatically achieves domain separation. This is for instance the case for OpenPGP signatures <https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-computing-signatures>. But introducing the context into a protocol that as of yet doesn't feed any context information would again require some "cut-off" measure like domain separation through the hash in order to prevent the downgrade and thus signature forgery. - Falko > > Thanks, > > David > > On 11/19/23 9:53 PM, Falko Strenzke wrote: >> >> The point I was making is that for instance with a feasible >> computational effort of 2⁶³ hash evaluations on average, the attacker >> can control 8 bytes in the digest, if he can control a large enough >> portion of the signed message and predict the whole message. >> >> Anyway, this is an irrelevant and misleading discussion, a signature >> forgery is a signature forgery and the protocol is broken. >> >> - Falko >> >> Am 19.11.23 um 01:04 schrieb Scott Fluhrer (sfluhrer): >>> (Falko argued that it could be under total control if the attacker >>> had sufficient computational power; however if the attacker had >>> sufficient computational power, he could just break the public keys). >> -- >> >> *MTG AG* >> Dr. Falko Strenzke >> Executive System Architect >> -- *MTG AG* Dr. Falko Strenzke Executive System Architect Phone: +49 6151 8000 24 E-Mail: falko.strenzke@mtg.de Web: mtg.de <https://www.mtg.de> <https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false> Follow us ------------------------------------------------------------------------ <https://www.mtg.de/de/aktuelles/MTG-AG-erhaelt-Innovationspreis-des-Bundesverbands-IT-Sicherheit-e.V-00001.-TeleTrust/> <https://www.itsa365.de/de-de/companies/m/mtg-ag> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany Commercial register: HRB 8901 Register Court: Amtsgericht Darmstadt Management Board: Jürgen Ruf (CEO), Tamer Kemeröz Chairman of the Supervisory Board: Dr. Thomas Milde This email may contain confidential and/or privileged information. If you are not the correct recipient or have received this email in error, please inform the sender immediately and delete this email.Unauthorised copying or distribution of this email is not permitted. Data protection information: Privacy policy <https://www.mtg.de/en/privacy-policy>
- [lamps] pre-hashing the OID in draft-ounsworth-pq… Falko Strenzke
- Re: [lamps] pre-hashing the OID in draft-ounswort… Scott Fluhrer (sfluhrer)
- Re: [lamps] pre-hashing the OID in draft-ounswort… John Gray
- Re: [lamps] pre-hashing the OID in draft-ounswort… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: pre-hashing the OID in… John Gray
- Re: [lamps] pre-hashing the OID in draft-ounswort… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] Re: pre-hashing the OID in… David A. Cooper
- Re: [lamps] [EXTERNAL] Re: pre-hashing the OID in… John Gray
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… David A. Cooper
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Tim Hollebeek
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… John Gray
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Tim Hollebeek
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Seo Suchan
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Stephen Farrell
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] Re: pre-hashing the OID in… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Scott Fluhrer (sfluhrer)
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] pre-hashing the OID in draft-ounswort… Kampanakis, Panos
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Tim Hollebeek
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Markku-Juhani O. Saarinen
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Markku-Juhani O. Saarinen
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] pre-hashing the OID in draft-ounswort… John Gray
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Mike Ounsworth
- [lamps] Can CSR include issuer name? Wang Haiguang
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… JOHNSON Darren
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Falko Strenzke
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Markku-Juhani O. Saarinen
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Ilari Liusvaara
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… John Gray
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Mike Ounsworth
- Re: [lamps] [EXTERNAL] pre-hashing the OID in dra… Carl Wallace