Re: [openpgp] Wording/meaning (draft-06, 5.13.1)

Justus Winter <justus@sequoia-pgp.org> Sun, 17 July 2022 19:50 UTC

Return-Path: <justus@sequoia-pgp.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 40EF5C157902 for <openpgp@ietfa.amsl.com>; Sun, 17 Jul 2022 12:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSNgNCGjdjCn for <openpgp@ietfa.amsl.com>; Sun, 17 Jul 2022 12:50:43 -0700 (PDT)
Received: from harrington.uberspace.de (harrington.uberspace.de [185.26.156.85]) (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 2AAAEC14F75F for <openpgp@ietf.org>; Sun, 17 Jul 2022 12:50:42 -0700 (PDT)
Received: (qmail 13296 invoked by uid 500); 17 Jul 2022 19:50:39 -0000
Authentication-Results: harrington.uberspace.de; auth=pass (plain)
From: Justus Winter <justus@sequoia-pgp.org>
To: Bruce Walzer <bwalzer@59.ca>, openpgp@ietf.org
In-Reply-To: <YtMgfznF78Fb7KJC@ohm.59.ca>
References: <YtMgfznF78Fb7KJC@ohm.59.ca>
Date: Sun, 17 Jul 2022 21:50:07 +0200
Message-ID: <874jzf4iz4.fsf@sequoia-pgp.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Rspamd-Bar: ----
X-Rspamd-Report: BAYES_HAM(-2.048579) MIME_GOOD(-0.2) SIGNED_PGP(-2)
X-Rspamd-Score: -4.248579
Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Sun, 17 Jul 2022 21:50:39 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/4tQfNiCvg1TV0aLNafztGlYn_00>
Subject: Re: [openpgp] Wording/meaning (draft-06, 5.13.1)
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 17 Jul 2022 19:50:44 -0000

Bruce Walzer <bwalzer@59.ca> writes:

> At the end of section 5.13.1, at the end of the "NON-NORMATIVE
> EXPLANATION" is the following text:
>
>>However, no update will be needed because the MDC has been replaced
>>by the AEAD encryption described in this document.
>
> Which seems to refer to the previous text somehow but it is not clear
> how as there is no discussion of any sort of an update in the
> previous text.

The text with a little bit of context is:

  Note also that unlike nearly every other OpenPGP subsystem, there are
  no parameters in the MDC system. It hard-defines SHA-1 as its hash
  function. This is not an accident. It is an intentional choice to
  avoid downgrade and cross-grade attacks while making a simple, fast
  system. (A downgrade attack would be an attack that replaced SHA2-256
  with SHA-1, for example. A cross-grade attack would replace SHA-1 with
  another 160-bit hash, such as RIPEMD-160, for example.)

  However, no update will be needed because the MDC has been replaced by
  the AEAD encryption described in this document.

The text talking about not needing to update refers to the fact that the
MDC system is not parameterized.

Previously, in RFC4880, the paragraph you quoted read:

      However, given the present state of hash function cryptanalysis
      and cryptography, it may be desirable to upgrade the MDC system to
      a new hash function.  See Section 13.11 in the "IANA
      Considerations" for guidance.

Does that clear things up?  Maybe you can suggest some text to make this
clearer?

Best,
Justus