Re: [openpgp] Deprecating SHA1

Paul Wouters <paul@nohats.ca> Fri, 23 October 2020 14:52 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1DD3A0EA8 for <openpgp@ietfa.amsl.com>; Fri, 23 Oct 2020 07:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 ewgOw_ijvBLx for <openpgp@ietfa.amsl.com>; Fri, 23 Oct 2020 07:52:43 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273303A0EA6 for <openpgp@ietf.org>; Fri, 23 Oct 2020 07:52:42 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CHnJm6Fy8zKJ8; Fri, 23 Oct 2020 16:52:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1603464760; bh=bXgxfUuQmCmeBIrg8Oj2dyEV/E3jFC6sWpXTCAAln0k=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=RLEN/f0AfIcD4a9dcqlCOySt1n8VQ0o8x8RCYOFA6D5FQ6mJcwNMY+V+3OgzZUYfD cQaxc3YHbAVipyEYGVinEV5RnE1cn5ltIa6Nmte28KrwFwXEHJ+FmgNIAqOs2cODd2 XGxddZ5mum0LxM/0doQ4TjbX1zOumhiaNXme/LZ4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2zxvNOndv2M6; Fri, 23 Oct 2020 16:52:38 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 23 Oct 2020 16:52:38 +0200 (CEST)
Received: from [193.110.157.220] (unknown [193.110.157.220]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 633B96029BA1; Fri, 23 Oct 2020 10:52:37 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Paul Wouters <paul@nohats.ca>
Mime-Version: 1.0 (1.0)
Date: Fri, 23 Oct 2020 10:52:35 -0400
Message-Id: <C68710C4-9A13-4BEC-A89A-E89663883022@nohats.ca>
References: <87sga5xg03.wl-neal@walfield.org>
Cc: openpgp@ietf.org
In-Reply-To: <87sga5xg03.wl-neal@walfield.org>
To: "Neal H. Walfield" <neal@walfield.org>
X-Mailer: iPhone Mail (18A393)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/XcvU0UyD-4PyRenXPpJ6w776J2I>
Subject: Re: [openpgp] Deprecating SHA1
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Oct 2020 14:52:46 -0000

Could you give implementers some guidance?

- don’t allow creating sha1 signatures 
- don’t allow verification with sha1 to pass for data time time stamped after 2020 (eg based on email headers or signature time stamps)
- allow verification of old data with sha1 to pass

Paul

Sent from my iPhone

> On Oct 23, 2020, at 08:51, Neal H. Walfield <neal@walfield.org> wrote:
> 
> Hi,
> 
> I'm turning to this mailing list to seek advice about how to deal with
> SHA1-based self signatures.  I have two concrete questions, which are
> at the bottom of the email.  But first, I want to present the concrete
> problem and my thoughts so far.
> 
> 
> Based on the "SHA-1 is a Shambles" paper [1] we decided to change
> Sequoia to reject signatures that use SHA1 by default [2].  This
> includes both signatures over data, as well as self signatures of all
> kinds including primary key binding signatures (aka backsigs).
> 
>  [1] https://sha-mbles.github.io/
>  [2] https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html#method.reject_hash_at
> 
> A Secure Drop developer recently contacted us, and indicated that our
> policy was too strict: some of the Secure Drop installations have
> offline keys that use SHA1, and the users have no easy way (or lack
> the will) to update those keys.
> 
> This prompted me to investigate the use of SHA1 in general.
> Unfortunately, it appears that many actively used certificates from
> technically sophisticated users still rely on SHA1.  The results of my
> investigation are here:
> 
>  https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
> 
> First, I found that Microsoft's "Security Notifications PGP Key" [3],
> which was created less than a year ago (Oct 2019) uses SHA-1.  Given
> the use of the preferred-email-encoding@pgp.com notation, I suspect
> that they are using a Symantec PGP product.
> 
>  [3] https://www.microsoft.com/en-us/msrc/pgp-key-security-notifications
> 
> Looking at the Debian Keyring, I found that:
> 
>  - 106 of the 884 certificate (12%) use SHA1 for all User ID binding
>    signatures and direct key signatures
> 
>  - 63 more (7%) use SHA1 to protect at least one non-revoked User ID.
> 
>  - 234 have a non-revoked, live signing capable subkey
> 
>    - 19 of those have binding signatures that use SHA1 in some way
>      (8%).
> 
>    - 9 use something stronger for the subkey binding signature, but
>      SHA1 for the backsig.  (This appears to be a bug in GnuPG, which
>      I reported [4].)
> 
>  [4] https://dev.gnupg.org/T5110
> 
> As Debian Developers are perhaps the most sophisticated OpenPGP users,
> this is pretty damning.
> 
> For Arch developers, the situation is worse: 2 of the 5 master ("CA")
> keys rely on SHA1.  Of the 72 developer keys, 26 (36%) use SHA1 for
> all User ID self signatures and direct key signatures.  Of the 46
> remaining certificates, 2 use SHA1 for a non-revoked, live
> signing-capable subkey.
> 
> Looking at the Fedora Project's signing Keys [5]: all 7 use SHA1
> exclusively.  When I spoke with the person responsible for this
> infrastructure, we discovered that this was due to a configuration
> error, which they promptly fixed.
> 
>  [5] https://getfedora.org/static/fedora.gpg
> 
> Given these results, we decided to reevaluate our bad listing of SHA1.
> As the SHA1 paper indicates that SHA1's preimage resistance is not
> broken, I thought that we might be able to accept SHA1 for self
> signatures, and not for documents [6].  But, Azul pointed out [7] that
> Mallory could create a collision for a document and a self-signature,
> and then convince Alice to sign the document.  This could work in
> practice because Mallory can predict everything in the signature, but
> the timestamp, and if Alice is an automated signing service, there is
> a good chance that Mallory would be able to get Alice to sign the
> document at the right time.
> 
>  [6] https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
>  [7] https://gitlab.com/sequoia-pgp/sequoia/-/issues/595#note_433768966
> 
> If the signature included a salt, Mallory would have had a much harder
> time coercing Alice to sign the document with the right metadata.  As
> such, we plan to include a salt in all signatures that Sequoia makes
> so that should, say, SHA256 suffer the same fate as SHA1, we can still
> rely on preimage resistance to allow us to continue to accept self
> signatures that use SHA256 for a while [8].
> 
>  [8] https://gitlab.com/sequoia-pgp/sequoia/-/issues/597
> 
> So, two questions:
> 
>  - Does anyone see a safe way to accept SHA1 self-signatures today?
>    Or (ouch!), if we want to be safe, do we have to convince ~10% of
>    the sophisticated OpenPGP users to re-sign or regenerate their
>    keys?
> 
>  - What do people think about including a salt in the hash to make
>    the content of the hash less predictable as described in [7]?
> 
> Thanks!
> 
> :) Neal
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp