[Curdle] [Technical Errata Reported] RFC8103 (5353)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 10 May 2018 02:44 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DD212D873 for <curdle@ietfa.amsl.com>; Wed, 9 May 2018 19:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 1j3L3us4qN_j for <curdle@ietfa.amsl.com>; Wed, 9 May 2018 19:44:50 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ED012D86F for <curdle@ietf.org>; Wed, 9 May 2018 19:44:50 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 2E353B80833; Wed, 9 May 2018 19:44:50 -0700 (PDT)
To: housley@vigilsec.com, kaduk@mit.edu, ekr@rtfm.com, daniel.migault@ericsson.com, rsalz@akamai.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: pleasestand@live.com, curdle@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180510024450.2E353B80833@rfc-editor.org>
Date: Wed, 09 May 2018 19:44:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/cx-TfYzRnAzCyGg7EZnWJZzw_8I>
Subject: [Curdle] [Technical Errata Reported] RFC8103 (5353)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 02:44:52 -0000

The following errata report has been submitted for RFC8103,
"Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5353

--------------------------------------
Type: Technical
Reported by: Kevin Israel <pleasestand@live.com>

Section: 6

Original Text
-------------
   The amount of encrypted data possible in a single invocation of
   AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
   the size of the block counter field in the ChaCha20 block function.
   This gives a total of 247,877,906,880 octets, which is likely to be
   sufficient to handle the size of any CMS content type.  Note that the
   ciphertext length field in the authentication buffer will accommodate
   2^64 octets, which is much larger than necessary.

Corrected Text
--------------
   The amount of encrypted data possible in a single invocation of
   AEAD_CHACHA20_POLY1305 is 2^32-1 blocks of 64 octets each, because of
   the size of the block counter field in the ChaCha20 block function.
   This gives a total of 274,877,906,880 octets, which is likely to be
   sufficient to handle the size of any CMS content type.  Note that the
   ciphertext length field in the authentication buffer will accommodate
   2^64 octets, which is much larger than necessary.

Notes
-----
The calculated total number of octets that can be encrypted in a single invocation is incorrect. See RFC Errata, Erratum ID 4858, RFC 7539.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8103 (draft-ietf-curdle-cms-chacha20-poly1305-06)
--------------------------------------
Title               : Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS)
Publication Date    : February 2017
Author(s)           : R. Housley
Category            : PROPOSED STANDARD
Source              : CURves, Deprecating and a Little more Encryption
Area                : Security
Stream              : IETF
Verifying Party     : IESG