Re: [openpgp] Deprecating SHA1

"Neal H. Walfield" <neal@walfield.org> Fri, 23 October 2020 15:17 UTC

Return-Path: <neal@walfield.org>
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 1411A3A0EE6 for <openpgp@ietfa.amsl.com>; Fri, 23 Oct 2020 08:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vNmzDInChZaU for <openpgp@ietfa.amsl.com>; Fri, 23 Oct 2020 08:17:18 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637743A0EE0 for <openpgp@ietf.org>; Fri, 23 Oct 2020 08:17:17 -0700 (PDT)
Received: from pd9e79cc0.dip0.t-ipconnect.de ([217.231.156.192] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1kVyod-0004tx-W5; Fri, 23 Oct 2020 15:17:16 +0000
Received: from grit.huenfield.org ([192.168.20.9] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1kVyod-0001cg-FI; Fri, 23 Oct 2020 17:17:15 +0200
Date: Fri, 23 Oct 2020 17:17:15 +0200
Message-ID: <87o8ktx98k.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Paul Wouters <paul@nohats.ca>
Cc: openpgp@ietf.org
In-Reply-To: <C68710C4-9A13-4BEC-A89A-E89663883022@nohats.ca>
References: <87sga5xg03.wl-neal@walfield.org> <C68710C4-9A13-4BEC-A89A-E89663883022@nohats.ca>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
X-SA-Exim-Connect-IP: 192.168.20.9
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/nSEJ3PXRVyuBwp7YvTb0a-32asE>
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 15:17:20 -0000

Hi Paul,

Thanks for following up.

On Fri, 23 Oct 2020 16:52:35 +0200,
Paul Wouters wrote:
> Could you give implementers some guidance?
> 
> - don’t allow creating sha1 signatures 

I suspect that most implementations already do this.

> - 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

The Sequoia library does pretty much already what you are suggesting
(although we set the cutoff for SHA1 to 2013, not 2020): when an
application developer configures a policy, they can specify a
timestamp.  The timestamp is then used to select algorithms that were
safe as of the specified time.

  https://docs.sequoia-pgp.org/sequoia_openpgp/struct.Cert.html#method.with_policy

The difficulty for the application developer is to find a timestamp
and authenticate it.  Consider: Alice encrypts an email to Bob.  If
Bob's certificate uses SHA1 for all of the self signatures, should
Alice accept the self signatures?  She has no email headers to extract
a time stamp from (she's sending him a mail, not verifying a signature
in a message that Bob sent her).  As for the time stamp in the self
signature, it's not clear to me why it should be trusted.  Say Mallory
collides a document sig and a self sig for Alice, and gets Alice to
sign the document at the right time.  He can set the self sig's
timestamp to whatever he wants, including just far enough in the past
that it gets by your proposed filter.

Thanks for your thoughts,

Neal