Re: DEADBEEF vs SHA1

Ian G <iang@iang.org> Thu, 17 February 2011 23:56 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HNuTCM038182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 16:56:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p1HNuTKP038181; Thu, 17 Feb 2011 16:56:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HNuSnx038173 for <ietf-openpgp@imc.org>; Thu, 17 Feb 2011 16:56:28 -0700 (MST) (envelope-from iang@iang.org)
Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id AF676406C2; Thu, 17 Feb 2011 23:56:26 +0000 (UTC)
Message-ID: <4D5DB5A9.9040509@iang.org>
Date: Fri, 18 Feb 2011 10:56:25 +1100
From: Ian G <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110123 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: David Shaw <dshaw@jabberwocky.com>
CC: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
Subject: Re: DEADBEEF vs SHA1
References: <D8E81788-AF18-448F-BA39-56185C1F0672@jabberwocky.com>
In-Reply-To: <D8E81788-AF18-448F-BA39-56185C1F0672@jabberwocky.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 18/02/11 6:12 AM, David Shaw wrote:
...
> In terms of the issue that originally started this thread, the proposal to include and compare the complete fingerprint resolves this attack as well (slightly better in this case, in fact, since a V3 fingerprint can't even accidentally collide with a V4 one).
...
> That said, however, (and switching over to implementation thoughts here) given how easy it is to make a V3 DEADBEEF key that collides with a real V4 key, I wonder if it would also be useful for implementations to simply refuse (or at least give the option to refuse) to import any V3 keys.  That might not have been feasible 10 years ago, but nowadays, I suspect most people would not even notice.  Standards-wise, that is fine as 4880 does not require V3 (discourages it, in fact: MUST NOT create, and only MAY accept).

Two thoughts.  One is that we're not only dealing with code, we're also 
dealing with data:

   * People have stored files encrypted to V3 keys (this is to conflate 
storage security with transport security, but that was common thinking 
in PGP world).
   * typically, people have expected things like digital signatures 
masquerading as human signatures to survive a long time.
   * some standards require 30 years of technology lifetime.

Secondly, isn't the argument more about ditching the Key ID approach? 
If we set up the new way to use only full fingerprints, then any 
imported V3 keys can be indexed on that basis.


iang

PS: I agree with the "must not generate V3 keys" part.  Is it possible 
to widen that with "must not sign or export or encrypt using V3 keys." 
And possibly offer an upgrade mode  "implementations may re-package V3 
keys in V5 format."  Dunno, just whiteboarding here...