[openpgp] Need to publish bis-05

Werner Koch <wk@gnupg.org> Tue, 24 July 2018 07:43 UTC

Return-Path: <wk@gnupg.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 79EB413103F for <openpgp@ietfa.amsl.com>; Tue, 24 Jul 2018 00:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 h-arAn72ko2c for <openpgp@ietfa.amsl.com>; Tue, 24 Jul 2018 00:43:47 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 2D8B9130E16 for <openpgp@ietf.org>; Tue, 24 Jul 2018 00:43:47 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fhryz-0005MC-C9 for <openpgp@ietf.org>; Tue, 24 Jul 2018 09:43:45 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fhrov-0005AD-NF for <openpgp@ietf.org>; Tue, 24 Jul 2018 09:33:21 +0200
From: Werner Koch <wk@gnupg.org>
To: openpgp@ietf.org
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: openpgp@ietf.org
Date: Tue, 24 Jul 2018 09:33:21 +0200
Message-ID: <87va95f5q6.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=security_lynch_Project_Monarch_Gazprom_Merlin_COSCO_TELINT_AMEMB_Rul"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/yan7x39PoDXsOmMXMvGmsR_6ReU>
Subject: [openpgp] Need to publish bis-05
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.27
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, 24 Jul 2018 07:43:50 -0000

Hi

-04 is about to expire.  These will be the changes in -05:

--8<---------------cut here---------------start------------->8---
** New key flag:

#  The second octet:

+  0x04 - This key may be used as an additional decryption subkey (ADSK).

# The idea is that implementations will also encrypt to a second subkey
# which for example is used on a second device.  I am not sure whether
# this is suitable solution and makes much sense so this is intended as a
# bait for discussion.

** Deprecation of Symmetrically Encrypted Data Packet

+ This packet is obsolete.  An implementation MUST not create this
+ packet.  An implementation MAY process such a packet but it MUST
+ return a clear diagnostic that a non-integrity protected packet has
+ been processed.  The implementation SHOULD also return an error in
+ this case and stop processing.

** Limit the chunk size of  AEAD packets:

  An implementation MUST support chunk size octets with values from 0 to
  56.  Chunk size octets with other values are reserved for future
+ extensions.  Implementations SHOULD NOT create data with a chunk size
+ octet value larger than 21 (128 MiB chunks) to facilitate buffering of
+ not yet authenticated plaintext.

** Explict warning reading the AEAD IV:

  A new random initialization vector MUST be used for each message.
+ Failure to do so for each message will lead to a catastrophic failure
+ depending on the used AEAD mode.

** More pressure to use AEAD:

-    This attack can be defeated by the use of Modification Detection,
+    This attack can be defeated by the use of modification detection,
     provided that the implementation does not let the user naively
-    return the data to the attacker.  An implementation MUST treat an MDC
-    failure as a security problem, not merely a data problem.
-
-    In either case, the implementation MAY allow the user access to the
-    erroneous data, but MUST warn the user as to potential security
-    problems should that data be returned to the sender.
+    return the data to the attacker.  The modification detection is
+    prefereabble implemented by using the AEAD Encrypted Data Packet
+    and only if the recipients don't supports this by use of the
+    Symmmetric Encrypted and Integrity Protected Data Packet.  An
+    implementation MUST treat an authentication or MDC failure as a
+    security problem, not merely a data problem.
+
+    In either case, the implementation SHOULD NOT allow the user
+    access to the erroneous data, and MUST warn the user as to
+    potential security problems should that data be returned to the
+    sender.

and changed the following suggestion to read

    permits someone to trick a user to decrypt a message.  Consequently,
    it is important that:

      1.  Implementers treat authentication errors, MDC errors,
          decompression failures or no use of MDC or AEAD as security
          problems.

      2.  Implementers implement AEAD with all due speed and encourage
          its spread.

      3.  Users migrate to implementations that support AEAD
          encryption with all due speed.


** Clarify / cleanup OCB section, add EAX and OCB test vectors
--8<---------------cut here---------------end--------------->8---


See also git@gitlab.com/openpgp-wg/rfc4880bis


Shalom-Salam,

   Werner


--
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.