Re: [openpgp] Summary v5 fingerprint proposal

Jon Callas <joncallas@icloud.com> Thu, 23 March 2017 18:55 UTC

Return-Path: <joncallas@icloud.com>
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 1E1F0129B81 for <openpgp@ietfa.amsl.com>; Thu, 23 Mar 2017 11:55:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com
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 81zv3CnqZxed for <openpgp@ietfa.amsl.com>; Thu, 23 Mar 2017 11:55:05 -0700 (PDT)
Received: from st13p27im-asmtp003.me.com (st13p27im-asmtp003.me.com [17.162.190.112]) (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 3911C129B6F for <openpgp@ietf.org>; Thu, 23 Mar 2017 11:55:05 -0700 (PDT)
Received: from process-dkim-sign-daemon.st13p27im-asmtp003.me.com by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0ONA0060073LB600@st13p27im-asmtp003.me.com> for openpgp@ietf.org; Thu, 23 Mar 2017 18:55:04 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1490295304; bh=nmmDyhtwvmwQxq7TcbvIo/pOQDQswgWDbUop0Wc4Jts=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=kLaxZI59zcxERIJtSrBqWnowrTYstN0N+KjnLPRMEfbfHYcr8Jyp67ntoVrko9P9G c6RDgdvX3tjQJQxY4w1WOtYh79GH41DIQSiT/lpLVQp+SPOT4259pvu0/bwrsTgzEZ k4ToLy2h/JHa5EXrcLa9cUHv45PhqTeVek8/EOZZHeTdTrv/skBZi16Ywcgr/WdX8r aLMFBvtnIYXx6xt+No4Mpph6kL9xamlfmmteeyFY0X7zchfKFwpjPua0viBczQUgni MH9C8BIQZz2MGCzWwSMWaEiuDPpznzlrjRRhQqG0nQQkoUxNjDGQSygPpDR2V+21dc Kd+iRre1EAZIw==
Received: from icloud.com ([127.0.0.1]) by st13p27im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0ONA00X0T77PT930@st13p27im-asmtp003.me.com>; Thu, 23 Mar 2017 18:55:04 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-23_18:,, signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1703230162
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Jon Callas <joncallas@icloud.com>
In-reply-to: <87poh8kkfi.fsf@wheatstone.g10code.de>
Date: Thu, 23 Mar 2017 11:55:00 -0700
Cc: Jon Callas <joncallas@icloud.com>, "HANSEN, TONY L" <tony@att.com>, "openpgp@ietf.org" <openpgp@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <35F1365E-C728-4925-BFB0-F31A3D8EC8FF@icloud.com>
References: <8737e4o2e4.fsf@wheatstone.g10code.de> <CAAu18hcEGGaDjKXtXpPbzxKm-8T4PWQBFq6AmbRXLUwi_z=0XQ@mail.gmail.com> <728801D2-CB96-4584-8A79-C93278B0437F@att.com> <87poh8kkfi.fsf@wheatstone.g10code.de>
To: Werner Koch <wk@gnupg.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/E0qV7P4PAm75hyQ9SbLeC6bBoKg>
Subject: Re: [openpgp] Summary v5 fingerprint proposal
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 23 Mar 2017 18:55:07 -0000

> On Mar 23, 2017, at 9:49 AM, Werner Koch <wk@gnupg.org> wrote:
> 
> On Thu, 23 Mar 2017 15:00, tony@att.com said:
> 
>> I’m with Jon on this one – if you’re going to do truncation, then use
>> a scheme that’s DESIGNED to generate a truncated value. And the only
>> one that’s been discussed that meets that criteria is SHA2-512/t.
> 
> OpenPGP has always used a truncated hash for the keyid.  The change is
> that with v5 we will use use the leftmost 64 bits instead of the
> rightmost 64 bit.
> 
> I explained in the original proposal the reasons why truncating certain
> uses of the fingerprint makes sense.

I don't have any objection to truncating the fingerprint to get the KeyID. The KeyID is merely a database key (as in key-value, not crypto) and has no security value. Implementations already need to consider the possibility that there could be a collision in the KeyID.

> 
> Jon's suggestion of using SHA2-512/t does not work: if we ever need to
> switch to the full fingerprint for the two signature subpackets, we
> would need to define a v6 key format because the fingerprint changes by
> using a different t with SHA2-512/t.

You don't need a new format, you'd just specify the new fingerprint. You can consider SHA512/t to be a family of hashes of output 't'.

If you're mentioning using SHA512/64 for a key id — no, no, that's just unnecessary.

> 
> What we put into the signature subpackets is an abbreviation of the
> fingerprint and this can be changed easily by introducing new signature
> subpackets.  This would be the same as our migration from the /Issuer/
> to the /Issuer Fingerprint/ subpacket.  This is an non-intrusive change
> to fix the problems with the use of the 64 bit truncated fingerprint in
> the /Issuer/ subpacket.
> 
>> But I also find Derek’s desire to use SHA2-256 to be compelling because of performance.
> 
> Noted.

For the record, I don't object to using SHA-256. I observe that there are a set of cases where someone finds problems in SHA2 that would have a longer runway for replacement if we're using SHA-512, and *that* is either a bug or a feature since arguably once someone finds some actual problem in SHA-256 (e.g. of the sort that has plagued SHA-1 since 2004), that should be the event that leads to tossing all of SHA2.

 I also observe that the performance issue is real, but hardly fatal — small devices will be with us always and fingerprints can be computed once and cached no matter what. This is why I didn't bring up the counter-argument which is that ARM64 is already sub- one euro per core.

The real reason to use a wider hash is that every time we've compromised on security for the sake of small devices, it bites us in the ass. This will also bite us in the ass. It's a small bite in the grand scheme of things, but it's going to happen and it will be inconvenient.

Do we have a meta-strategy for an upgrade? For example, if we know that you'd pick whatever hash at that time the cool kids recommend, change a couple of parameters (like simply bump the key version to v6 and go), that could be a recommendation in the RFC.

	Jon