Re: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)

Stefan Santesson <stefan@aaa-sec.com> Wed, 17 July 2019 07:46 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55074120111 for <pkix@ietfa.amsl.com>; Wed, 17 Jul 2019 00:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 SQ_oUClCG9yT for <pkix@ietfa.amsl.com>; Wed, 17 Jul 2019 00:46:34 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5D312009C for <pkix@ietf.org>; Wed, 17 Jul 2019 00:46:33 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 9A3F01F165EE for <pkix@ietf.org>; Wed, 17 Jul 2019 09:46:30 +0200 (CEST)
Received: from s498.loopia.se (unknown [172.21.200.36]) by s554.loopia.se (Postfix) with ESMTP id 7BD6779537F; Wed, 17 Jul 2019 09:46:30 +0200 (CEST)
Received: from s472.loopia.se (unknown [172.22.191.5]) by s498.loopia.se (Postfix) with ESMTP id 77F424707A3; Wed, 17 Jul 2019 09:46:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s500.loopia.se ([172.22.191.5]) by s472.loopia.se (s472.loopia.se [172.22.190.12]) (amavisd-new, port 10024) with LMTP id jqW8S1vylBbT; Wed, 17 Jul 2019 09:46:29 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 85.235.7.89
Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s500.loopia.se (Postfix) with ESMTPSA id B414A1E1462B; Wed, 17 Jul 2019 09:46:29 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/10.1a.0.190609
Date: Wed, 17 Jul 2019 09:46:28 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Niklas Matthies <pkix@nmhq.net>, "pkix@ietf.org" <pkix@ietf.org>
Message-ID: <0A77452C-112C-4326-A5DA-661DBD4DDD69@aaa-sec.com>
Thread-Topic: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)
References: <20190712200549.2kgzjqodj5afnxlt@nmhq.net> <0FDBEEC9-0FBA-4C47-BD04-EE7F6053426D@aaa-sec.com> <1563269533626.58560@cs.auckland.ac.nz> <218E69B7-036E-45FF-AD3B-9F017FCAF40E@aaa-sec.com> <1563334087967.97714@cs.auckland.ac.nz>
In-Reply-To: <1563334087967.97714@cs.auckland.ac.nz>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/DhUapQPTxSTuKN9MGPkckzscEEs>
Subject: Re: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2019 07:46:36 -0000

The spec says: Don't match hash to a real document if the hash value is A, but ignore matching for any hash values other than A.
(A = all zero in this case).

That (quite obviously) may lead to security vulnerabilities if matching is important for security and implementers don't get it right.
Example: An implementer gets this wrong and only test if the first byte of the hash (he forgot to increment the index counter). I can then cause this implementation to skip matching if I produce a hash with first byte set to 0x00.

All I'm saying is that a safer design is to say "Don't match if value is absent". Implementers are more likely to get that right, but there are no guarantees.

Stefan Santesson 

´╗┐On 2019-07-17, 05:28, "Peter Gutmann" <pgut001@cs.auckland.ac.nz>; wrote:

    Stefan Santesson <stefan@aaa-sec.com>; writes:
    
    >To assign a specific meaning to one out of all possible but syntactically
    >valid hash values, is exactly the type of specification work that leads to
    >implementation errors and security vulnerabilities.
    
    How would it lead to implementation errors and security vulns?  It's a value
    that's guaranteed to not match anything while requiring zero changes to
    existing code, what sort of implementation error would it lead to?
    
    Peter.