Re: [openpgp] SHA3 algorithm ids.

Werner Koch <wk@gnupg.org> Tue, 11 August 2015 10:15 UTC

Return-Path: <wk@gnupg.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 6CBEA1A6FF6 for <openpgp@ietfa.amsl.com>; Tue, 11 Aug 2015 03:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] 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 Q4rNq5qVvLTg for <openpgp@ietfa.amsl.com>; Tue, 11 Aug 2015 03:15:34 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B1E1A6FF0 for <openpgp@ietf.org>; Tue, 11 Aug 2015 03:15:34 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1ZP6ah-0005wg-MS for <openpgp@ietf.org>; Tue, 11 Aug 2015 12:15:31 +0200
Received: from wk by vigenere.g10code.de with local (Exim 4.84 #3 (Debian)) id 1ZP6W5-0007oW-6k; Tue, 11 Aug 2015 12:10:45 +0200
From: Werner Koch <wk@gnupg.org>
To: Phillip Hallam-Baker <phill@hallambaker.com>
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>
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=F2AD85AC1E42B367; url=finger:wk@g10code.com
Mail-Followup-To: Phillip Hallam-Baker <phill@hallambaker.com>, Derek Atkins <derek@ihtfp.com>, IETF OpenPGP <openpgp@ietf.org>, ianG <iang@iang.org>
Date: Tue, 11 Aug 2015 12:10:45 +0200
In-Reply-To: <CAMm+Lwj7SxXTn+KD-eQSeZHwJB36tCgD1t0bodVsp3ovOaZ8mw@mail.gmail.com> (Phillip Hallam-Baker's message of "Mon, 10 Aug 2015 16:50:32 -0400")
Message-ID: <87si7qf84a.fsf@vigenere.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/uQbMp5HhvHsJb_I83XMIOanCT6g>
Cc: IETF OpenPGP <openpgp@ietf.org>, Derek Atkins <derek@ihtfp.com>, ianG <iang@iang.org>
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 10:15:36 -0000

On Mon, 10 Aug 2015 22:50, phill@hallambaker.com said:

> Given that email recipients tend to end up having to implement all the code
> points in a cipher suite because they can't really control what is sent, I

That is not the case with OpenPGP.  If you encrypt and sign the key
gives you a list of hash algorithms supported by the recipient.  Only
those may be used.   In a signature only case there is no point in an using
extravagant hash algorithm because most recipients won't be able to
verify such a signature.

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.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.