Re: [openpgp] V5 Fingerprint again

Thijs van Dijk <schnabbel@inurbanus.nl> Thu, 02 March 2017 13:13 UTC

Return-Path: <schnabbel@inurbanus.nl>
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 E82D412945A for <openpgp@ietfa.amsl.com>; Thu, 2 Mar 2017 05:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inurbanus.nl
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 CUT71zDeFiiC for <openpgp@ietfa.amsl.com>; Thu, 2 Mar 2017 05:13:43 -0800 (PST)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 A9C7C129464 for <openpgp@ietf.org>; Thu, 2 Mar 2017 05:13:43 -0800 (PST)
Received: by mail-ua0-x22e.google.com with SMTP id c11so26258023uaa.0 for <openpgp@ietf.org>; Thu, 02 Mar 2017 05:13:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7I7d+aANnPUJiW5+6gFBufsR1AVppOtsCNG8aMPxyCQ=; b=V0jIFahZ83kyfIzoZogtkW7Pa/9OVnzjLlcWVoWtRO7mc9gFI7tSRUIcdYgE6v2ayR 1tWaOmA6BKmG9A7brgdtz+pttxU1AN7jU5oPmorNKgnKQpBJZdlxArNSVFRiRMqSwS7T rXaMCEFvPyzRbKPXPuIrlDwarGxzwhTg/qd8Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7I7d+aANnPUJiW5+6gFBufsR1AVppOtsCNG8aMPxyCQ=; b=f++66uCKv60px6hnNF6EXVFuRCtwjMuEm3fHVTdmVtZdfxb2A+NlOtMYCfPpUAo+Xi iddXmz8ZuE1zHjLyhJ8sGLHdaRKF/YzDryw8VmnywPWxzWVuoHOHo/VHtHu+Fpk/IHSM NXimbIUlkQX5uXcTyWgfRPbrxyeYOfZzEtFI9cLfd4x+3zM6q14slfOdHpmNJSbuPeuX 86nAc3Shg263KEyKQlhLRXzBcQMqmaQ2Tz/HAC8SRvSqyB5aTTjIw16OHMSJyZUQgdKd JxX6LcnAW0Cyjl5p0UPZApez1QZEcDLTWsz/C9yRwpXY9xZ4OlLbxJUD9e+KOBjBtcNF Ni1A==
X-Gm-Message-State: AMke39kdk+PWF7g7XJUmzWi1HjmCGxKtVIkyK/RlievXN01wi1r5Lwj1sjuvp4kA72uBSTsHi3rs1MzEmZz8KQ==
X-Received: by 10.159.37.144 with SMTP id 16mr6771813uaf.80.1488460422268; Thu, 02 Mar 2017 05:13:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.102.3 with HTTP; Thu, 2 Mar 2017 05:13:41 -0800 (PST)
In-Reply-To: <9E0B568A-6BFB-402B-A445-C1B31FF4D9A6@my.amazin.horse>
References: <CAMm+Lwju5i5xHt=ma6Ush4_4dfZNwOi2=2km+6Qja+sDbkvbxg@mail.gmail.com> <CADGaDpFoBt1=eZHxo4q=Yb24NYyy1sudFn_h=MTZE3_wiRVXJw@mail.gmail.com> <87lgsoah35.fsf@wheatstone.g10code.de> <9E0B568A-6BFB-402B-A445-C1B31FF4D9A6@my.amazin.horse>
From: Thijs van Dijk <schnabbel@inurbanus.nl>
Date: Thu, 02 Mar 2017 14:13:41 +0100
Message-ID: <CADGaDpE-OzPafDO89=JB-6X=EER3AUnrGbCGi96vaN9E0vyydg@mail.gmail.com>
To: Vincent Breitmoser <look@my.amazin.horse>
Content-Type: multipart/alternative; boundary="001a1139ba66bb64200549bf327c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/oyuEfMyxzkSgaO_JitqnQAeZWZg>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] V5 Fingerprint again
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 02 Mar 2017 13:13:45 -0000

>
> I think we can go slightly further here for depreciation in implementation
> logic: if a primary key is self signed with a stronger algorithm, a sha1
> signature can be considered a security error. This avoids a downgrade
> scenario and catches misconfigurations but should have little potential for
> false positives.
>

Interesting. How do you envision handling an updated selfsig (e.g. to move
the expiration date forward) with a stronger hash than before?
To me, this seems like the most obvious upgrade path (i.e. a way for users
to force moving to a stronger hash), but when taken literally we've just
retroactively revoked all previous signatures.


> The only scenario I can think of where this heuristic is off, is when the
> sender doesn't create their key themselves and isn't itself capable of
> stronger hashes. Not sure if that ever happens?


One could have a gnuk or yubikey generate the key, and if the user agent
*defaults* to sha1 (regardless of whether or not it can support stronger
hashes) you'll have triggered this scenario.

-Thijs