Re: [openpgp] SHA3 algorithm ids.

ianG <iang@iang.org> Tue, 11 August 2015 12:29 UTC

Return-Path: <iang@iang.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 70ADE1A8931 for <openpgp@ietfa.amsl.com>; Tue, 11 Aug 2015 05:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 x2aquujL_tKU for <openpgp@ietfa.amsl.com>; Tue, 11 Aug 2015 05:29:02 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1271A1B14 for <openpgp@ietf.org>; Tue, 11 Aug 2015 05:29:01 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id A586F6D775; Tue, 11 Aug 2015 08:28:59 -0400 (EDT)
Message-ID: <55C9EAA2.8040500@iang.org>
Date: Tue, 11 Aug 2015 13:29:22 +0100
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: openpgp@ietf.org
References: <87y4hmi19i.fsf@vigenere.g10code.de> <7540C7A9-2830-4A63-8310-B684796DA279@nohats.ca> <55C681FC.9010100@iang.org> <sjma8tztbgo.fsf@securerf.ihtfp.org> <CAMm+Lwj7SxXTn+KD-eQSeZHwJB36tCgD1t0bodVsp3ovOaZ8mw@mail.gmail.com> <87si7qf84a.fsf@vigenere.g10code.de>
In-Reply-To: <87si7qf84a.fsf@vigenere.g10code.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/btuGUrjSQUizYICKHDGql-5QZzs>
Subject: Re: [openpgp] SHA3 algorithm ids.
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: Tue, 11 Aug 2015 12:29:03 -0000

On 11/08/2015 11:10 am, Werner Koch wrote:
...
> We have a lot of experience in how to deploy new algorithms and we are
> very conservative here.  My request for adding SHA3 algo ids does not
> mean in any way that I endorse its use or would even suggest that
> 4880bis should contain a SHOULD or MAY for implementing such an
> algorithm.  When we come to the point on deciding on algorithms I would
> suggest something like this:
>
>   - Implementations MUST implement SHA-1.  Implementations MAY implement
>   - other algorithms.  MD5 is deprecated.
>   + Implementations MUST implement SHA-1 and SHA2-FIXME.  Implementations
>   + MUST NOT implement MD5.  Implementations SHOULD NOT implement
>   + SHA3-xxxx.  Implementations MAY implement other algorithms.
>
> The algo ids are a different case and I would be fine with the RFC-7120
> method.  Iff the unexpected case happens that a severe weakness in SHA2
> is found, the pre-allocated SHA3 ids will allow us to quickly switch to
> SHA3.  Isn't that the whole point of SHA3 being plugin-in replacements
> for SHA2?
>
> I suggest to use a different thread for discussing algorithm selection
> because that is a different topic than assigning algorithm ids.



Hmmm... I understand that.  What I'm not convinced of is that at the 
current time we can sensibly allocate the numbers.

As far as I can see, to sensibly allocate the numbers, we'd want:

   * to choose which SHA3 we're going for.  This not only means 
addressing the additionals (like the 4 lengths) but also resolving the 
uncertainty (perhaps in my mind only) about SHAKES.

   * to build a more comprehensive alg-failure recovery strategy.  By 
this I mean, more than handwaving at SHA3 as a potential drop in; 
making it the actual drop in with a process by which we trigger that 
move and a series of events listed that we anticipate happening;  text 
in the draft that lays that out;  etc.

Otherwise, we're fortune gazing.

(It may sound like I'm engaging in waffly rhetoric again - but there is 
a known discipline for this.  It's called *disaster recovery* and it's a 
required component of many compliance programmes, taught and certified 
in various places.  There are many people who know how to do this stuff, 
it's just that it is a relatively new and/or infrequent delivery in the 
open source crypto world.)



iang