Re: [openpgp] New fingerprint: to v5 or not to v5

Simon Josefsson <simon@josefsson.org> Mon, 21 September 2015 09:14 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5D1A877B for <openpgp@ietfa.amsl.com>; Mon, 21 Sep 2015 02:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.149
X-Spam-Level: *
X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 YwdKpvXmQ4eO for <openpgp@ietfa.amsl.com>; Mon, 21 Sep 2015 02:13:59 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 4C0461A035F for <openpgp@ietf.org>; Mon, 21 Sep 2015 02:13:58 -0700 (PDT)
Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t8L9Dnvo006394 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 21 Sep 2015 11:13:50 +0200
From: Simon Josefsson <simon@josefsson.org>
To: ianG <iang@iang.org>
References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150921:openpgp@ietf.org::4ohuFNmPcZfLDSDO:0fHd
X-Hashcash: 1:22:150921:iang@iang.org::Ah2RMaAsX0mwxoqV:55Sn
Date: Mon, 21 Sep 2015 11:13:48 +0200
In-Reply-To: <55FD7CF0.8030200@iang.org> (iang@iang.org's message of "Sat, 19 Sep 2015 16:19:12 +0100")
Message-ID: <87io742kz7.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/0tFYMu88LT-svpmZecKwHd-9s5U>
Cc: openpgp@ietf.org
Subject: Re: [openpgp] New fingerprint: to v5 or not to v5
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 21 Sep 2015 09:14:01 -0000

ianG <iang@iang.org>; writes:

> Hi Werner,
>
>
> On 17/09/2015 19:41 pm, Werner Koch wrote:
>> I'd like to get opinions on one specific aspect of a new fingerprint
>> format in 4880bis.
>>
>> In the past we bound the fingerprint format to the key packet version:
>> v3 keys used MD5 and v4 keys SHA-1 fingerprints.  This gained us the
>> benefit of having a bijective connection between fingerprint and key.
>
> I'm hugely on that side.  I'll always vote for that.  I even staked my
> rep on it :)
>
> http://iang.org/ssl/h1_the_one_true_cipher_suite.html
>
> Which came directly from the experience of hacking PGP & OpenPGP in
> Perl/Java as part of Cryptix.  The tears, the fears, the costs.
>
> So:  the only choice for me is which hash you pick for v5.  If you
> want another one, start planning for v6.

+1

I believe sub-negotiating in security protocol leads to obscure problems
and makes security evaluation harder.  If we can avoid that, and that
appears to be the case, I'm all for it.

Regarding which hash to use, SHA-256 is probably the simplest choice
From a practicallity and consensus point of view.  Are there any strong
reasons to favor something else?

What would be the relevant options be anyway?  SHA-256, BLAKE2,
SHA3-256, SHA-512, CubeHash?  Would there be value in being able to use
variable length SHAKE variants?

/Simon