Re: [openpgp] New S2K specifiers?

"Neal H. Walfield" <neal@walfield.org> Tue, 02 April 2019 06:15 UTC

Return-Path: <neal@walfield.org>
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 ABD49120058 for <openpgp@ietfa.amsl.com>; Mon, 1 Apr 2019 23:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CEWwc9ERtwsf for <openpgp@ietfa.amsl.com>; Mon, 1 Apr 2019 23:15:15 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 1D37712001E for <openpgp@ietf.org>; Mon, 1 Apr 2019 23:15:14 -0700 (PDT)
Received: from p57b22663.dip0.t-ipconnect.de ([87.178.38.99] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1hBChM-0001mC-S0; Tue, 02 Apr 2019 06:15:04 +0000
Date: Tue, 02 Apr 2019 08:15:04 +0200
Message-ID: <878swtgcgn.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: vedaal@nym.hush.com
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, openpgp <openpgp@ietf.org>
In-Reply-To: <20190402014643.96606406B6@smtp.hushmail.com>
References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> <87k1gebu9o.fsf@fifthhorseman.net> <20190402014643.96606406B6@smtp.hushmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-2022-JP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/25fMv5OSk8-DoBvKLuFWEi8Mgoo>
Subject: Re: [openpgp] New S2K specifiers?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Apr 2019 06:15:18 -0000

On Tue, 02 Apr 2019 03:46:43 +0200,
vedaal@nym.hush.com wrote:
> 
> 
> 
> On 4/1/2019 at 12:03 AM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
> >
> >On Sun 2019-03-31 13:10:24 +0100, Damien Goutte-Gattat wrote:
> >> * Is there any interest for a “more modern” S2K, or is the
> >>   Iterated+Salted S2K still considered fine enough for 
> >RFC4880bis?
> >
> >I think having argon2i included in rfc4880bis would be concretely
> >useful; iterated+salted hasn't been the best practice for S2K for 
> >well
> >over a decade.
> >
> >The main argument i can imagine against it is if no OpenPGP
> >implementation has any plans or desire to implement it, or if 
> >there are
> >specific objections related to IPR.
> 
> =====
> 
> Will the new S2K be only for the V5 key format?
> Or will it also be used for Conventionally Encrypted messages?
> 
> If it will be used for Conventionally Encrypted messages too, then there can be backward incompatibility issues, 
> as well as intercompatibility issues with different implementations.
> 
> (I still think it's a good idea, but may be a really lot of extra work, so maybe only for V5 keys now).

s2k is also used for SK-ESKs (symmetric-key encrypted session keys)
[1].  When using SK-ESKs, we may not have a key as a reference point.
That is, it doesn't make sense to add a restriction of the form: only
use argon with v5 keys, as there may not be any keys when we want to
use argon!

I agree with Jon that the implementations can figure out when to phase
it in.  That's at least something that we have experience with.

  [1] https://tools.ietf.org/html/rfc4880#section-5.3