Re: [openpgp] New S2K specifiers?

vedaal@nym.hush.com Tue, 02 April 2019 18:20 UTC

Return-Path: <vedaal@nym.hush.com>
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 E5CF0120167 for <openpgp@ietfa.amsl.com>; Tue, 2 Apr 2019 11:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai
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 8KutOuzx9-Ri for <openpgp@ietfa.amsl.com>; Tue, 2 Apr 2019 11:20:30 -0700 (PDT)
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (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 62AC812013F for <openpgp@ietf.org>; Tue, 2 Apr 2019 11:20:30 -0700 (PDT)
Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 56EDDE0A6B for <openpgp@ietf.org>; Tue, 2 Apr 2019 18:20:29 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=KfNmrac54ooVdNcnQxISxe8MRjrRbRGkUrEfDUjc+gw=; b=NaUrEderriXMkHAPwnXEy12HrcxbrUMAUjEnH/bOHI/7wW3CJN2eGFMYbkBBqJnXUbQTfwAVsEHSDfXdMGJY6PgEDHDBzD+sVnnFNdpI+tIErKORj5ZSRk3jZ+RgzYqr7Lk272kbzj2O6d5QcSpjh15+0cIfcmxokUpYE88aO9U0lWllVDaXmG8kDcSoTwprxiJeJ7LaVuBaxk0IHS8J4jBb0p6xp2zpCfOjFuLi8YYHZvWKilTCVLArXtScyZZp8UGOInKHFEkN3YngGPpsNJ7GyKwmr2C0mQZ6ce8pmfiT/trVfLqSrnP+5R7TuEgFywGS/DQS9Wt6klF+s6+ccA==
Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Tue, 2 Apr 2019 18:20:28 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id B7D3BE073E; Tue, 2 Apr 2019 18:20:28 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 02 Apr 2019 14:20:28 -0400
To: "Neal H. Walfield" <neal@walfield.org>, openpgp <openpgp@ietf.org>
From: vedaal@nym.hush.com
In-Reply-To: <878swtgcgn.wl-neal@walfield.org>
References: <20190331121024.cgta3emx6vefex6x@aurora.local.incenp.org> <87k1gebu9o.fsf@fifthhorseman.net> <20190402014643.96606406B6@smtp.hushmail.com> <878swtgcgn.wl-neal@walfield.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190402182028.B7D3BE073E@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/RY0lnuHUXG6f5JpR7EAkv_a8zZ8>
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 18:20:34 -0000

On 4/2/2019 at 2:15 AM, "Neal H. Walfield" <neal@walfield.org> wrote:

>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

=====

The issue is, that if it is not expressly implemented otherwise, the S2K used for the V4 or V5 key private key, 
will be the one that automatically defaults to the S2K for SK-ESK

(reasonable behavior, actually:
The most important security choice for the user is how to protect the user's private key, 
and presumably the user would like to give ESK's the same protection. This is also why the symmetric encryption algorithm choice for the private key, becomes the default algorithm for the ESK).

Current Implementations already do this by default, 
and implementers need to be aware to actively 'undo' it once the new S2K is adopted.


vedaal