From nobody Thu Aug 11 11:47:34 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B7712D60E for ; Thu, 11 Aug 2016 11:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 iJRpRsqWjJ-g for ; Thu, 11 Aug 2016 11:47:33 -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 4B64012D5CA for ; Thu, 11 Aug 2016 11:47:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4444EB8111E; Thu, 11 Aug 2016 11:47:33 -0700 (PDT) To: housley@vigilsec.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, paul.hoffman@vpnc.org, blaker@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160811184733.4444EB8111E@rfc-editor.org> Date: Thu, 11 Aug 2016 11:47:33 -0700 (PDT) Archived-At: Cc: quannguyen@google.com, rfc-editor@rfc-editor.org, smime@ietf.org Subject: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 18:47:34 -0000 The following errata report has been submitted for RFC5084, "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 -------------------------------------- Type: Technical Reported by: QUAN NGUYEN Section: 3.2 Original Text ------------- aes-ICVlen AES-GCM-ICVlen DEFAULT 12 A length of 12 octets is RECOMMENDED. Corrected Text -------------- aes-ICVlen AES-GCM-ICVlen DEFAULT 16 A length of 16 octets is RECOMMENDED. Notes ----- Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug to use 12 bytes authentication tag (aes-ICVlen) as default if the code path [1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, then 12 bytes authentication tag length has only 96 - 32 = 64 bits security which is not good enough nowadays. Furthermore, once a forgery happens then authentication is leaked. [1] In other code paths, all providers use 16 bytes authentication tag as default. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) -------------------------------------- Title : Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) Publication Date : November 2007 Author(s) : R. Housley Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Aug 13 10:03:55 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9712B00B for ; Sat, 13 Aug 2016 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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 Tl7rzgk71hyt for ; Sat, 13 Aug 2016 10:03:52 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43F012B005 for ; Sat, 13 Aug 2016 10:03:51 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 13 Aug 2016 10:15:34 -0700 From: Jim Schaad To: 'RFC Errata System' , , , , , References: <20160811184733.4444EB8111E@rfc-editor.org> In-Reply-To: <20160811184733.4444EB8111E@rfc-editor.org> Date: Sat, 13 Aug 2016 10:03:18 -0700 Message-ID: <027701d1f584$98da3320$ca8e9960$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHRaEVFPn+0uXujd3jpR3UjAM3696BINtMw Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: quannguyen@google.com, smime@ietf.org Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 17:03:53 -0000 The first half of this errata must be rejected. We do not change the ASN.1 for something like this under just about any circumstances. Changing the recommendation of a value should probably not be done by an erratum but by publishing a new document. We could make discuss and make the recommendation change in the new S/MIME document in the LAMPS group rather than in this document. Jim > -----Original Message----- > From: smime [mailto:smime-bounces@ietf.org] On Behalf Of RFC Errata System > Sent: Thursday, August 11, 2016 11:48 AM > To: housley@vigilsec.com; stephen.farrell@cs.tcd.ie; > Kathleen.Moriarty.ietf@gmail.com; paul.hoffman@vpnc.org; > blaker@gmail.com > Cc: quannguyen@google.com; rfc-editor@rfc-editor.org; smime@ietf.org > Subject: [smime] [Technical Errata Reported] RFC5084 (4774) > > The following errata report has been submitted for RFC5084, "Using AES-CCM > and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax > (CMS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 > > -------------------------------------- > Type: Technical > Reported by: QUAN NGUYEN > > Section: 3.2 > > Original Text > ------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 12 > > A length of 12 octets is RECOMMENDED. > > Corrected Text > -------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 16 > > A length of 16 octets is RECOMMENDED. > > Notes > ----- > Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug to > use 12 bytes authentication tag (aes-ICVlen) as default if the code path [1] uses > CMS. According to Ferguson's attack > (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC- > GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, then 12 > bytes authentication tag length has only 96 - 32 = 64 bits security which is not > good enough nowadays. Furthermore, once a forgery happens then > authentication is leaked. > > [1] In other code paths, all providers use 16 bytes authentication tag as default. > > 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 (IESG) can log in to change the status and edit the > report, if necessary. > > -------------------------------------- > RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) > -------------------------------------- > Title : Using AES-CCM and AES-GCM Authenticated Encryption in the > Cryptographic Message Syntax (CMS) > Publication Date : November 2007 > Author(s) : R. Housley > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From nobody Sat Aug 13 10:08:27 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4C4124281 for ; Sat, 13 Aug 2016 10:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 DewZ2Bn8ph93 for ; Sat, 13 Aug 2016 10:08:25 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 2E7EA120727 for ; Sat, 13 Aug 2016 10:08:25 -0700 (PDT) Received: from [192.168.114.1] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7DH8Gap029572 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2016 10:08:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "RFC Errata System" Date: Sat, 13 Aug 2016 10:08:15 -0700 Message-ID: In-Reply-To: <027701d1f584$98da3320$ca8e9960$@augustcellars.com> References: <20160811184733.4444EB8111E@rfc-editor.org> <027701d1f584$98da3320$ca8e9960$@augustcellars.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: quannguyen@google.com, smime@ietf.org, Jim Schaad , Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 17:08:26 -0000 On 13 Aug 2016, at 10:03, Jim Schaad wrote: > The first half of this errata must be rejected. We do not change the ASN.1 > for something like this under just about any circumstances. > > Changing the recommendation of a value should probably not be done by an > erratum but by publishing a new document. We could make discuss and make > the recommendation change in the new S/MIME document in the LAMPS group > rather than in this document. I fully agree with Jim on both counts. --Paul Hoffman From nobody Sat Aug 13 12:36:14 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3030E12D1D2 for ; Sat, 13 Aug 2016 12:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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 eT6vl-LICeNn for ; Sat, 13 Aug 2016 12:36:12 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D06A12D097 for ; Sat, 13 Aug 2016 12:36:12 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 13 Aug 2016 12:48:24 -0700 From: Jim Schaad To: Date: Sat, 13 Aug 2016 12:36:07 -0700 Message-ID: <029401d1f599$f1a57950$d4f06bf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdH1mb36078oKGZbSaG5jg4/QQdMvA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [smime] Implementations of ECDH key agreement X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 19:36:13 -0000 I am looking for anybody who has implemented the ECDH key agreement for the NIST curves. There is an issue dealing with how the public key is encoded in the originatorKey field vs how it is done in a certificate. Jim From nobody Sat Aug 13 14:34:24 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5112D5BE for ; Sat, 13 Aug 2016 14:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 5XGpMunFGUYA for ; Sat, 13 Aug 2016 14:34:21 -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 3106712D5B2 for ; Sat, 13 Aug 2016 14:34:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 15CF8B80D57; Sat, 13 Aug 2016 14:34:21 -0700 (PDT) To: turners@ieca.com, dbrown@certicom.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, paul.hoffman@vpnc.org, blaker@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160813213421.15CF8B80D57@rfc-editor.org> Date: Sat, 13 Aug 2016 14:34:21 -0700 (PDT) Archived-At: Cc: ietf@augustcellars.com, rfc-editor@rfc-editor.org, smime@ietf.org Subject: [smime] [Technical Errata Reported] RFC5753 (4777) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 21:34:22 -0000 The following errata report has been submitted for RFC5753, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5753&eid=4777 -------------------------------------- Type: Technical Reported by: Jim Schaad Section: 3.1.1 Original Text ------------- - originator MUST be the alternative originatorKey. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 7.1.2). The parameters associated with id-ecPublicKey MUST be absent, ECParameters, or NULL. The parameters associated with id-ecPublicKey SHOULD be absent or ECParameters, and NULL is allowed to support legacy implementations. The previous version of this document required NULL to be present. If the parameters are ECParameters, then they MUST be namedCurve. The originatorKey publicKey field MUST contain the DER encoding of the value of the ASN.1 type ECPoint (see Section 7.2), which represents the sending agent's ephemeral EC public key. The ECPoint in uncompressed form MUST be supported. Corrected Text -------------- - originator MUST be the alternative originatorKey. The originatorKey algorithm field MUST contain the id-ecPublicKey object identifier (see Section 7.1.2). The parameters associated with id-ecPublicKey MUST be absent, ECParameters, or NULL. The parameters associated with id-ecPublicKey SHOULD be absent or ECParameters, and NULL is allowed to support legacy implementations. The previous version of this document required NULL to be present. If the parameters are ECParameters, then they MUST be namedCurve. The originatorKey publicKey field MUST contain the encoded public key as defined in [X9.62]. The hybred form MUST NOT be used. The ECPoint in uncompressed form MUST be supported. This mirrors the same format used in public key certificates as defined in Section 2.2 of [RFC5480]. Notes ----- There is a problem in that for ECPoints, the public key is defined to be encoded differently in this document than it is in a public key certificate. The difference is the presence of the ASN.1 OCTET STRING wrapper. OpenSSL and BouncyCastle both use the unwrapped version per Dr. Stephen Henson note to me in mail. This error is also present in sections 3.1.2, 3.1.3, 3.2.1, 3.2.2, 7.2 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5753 (draft-ietf-smime-3278bis-09) -------------------------------------- Title : Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) Publication Date : January 2010 Author(s) : S. Turner, D. Brown Category : INFORMATIONAL Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Aug 13 14:47:26 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB06612D539 for ; Sat, 13 Aug 2016 14:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 J1l75pDiiUdG for ; Sat, 13 Aug 2016 14:47:24 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 48A9A12B051 for ; Sat, 13 Aug 2016 14:47:24 -0700 (PDT) Received: from [10.32.60.16] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7DLktUD043766 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2016 14:46:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.16] From: "Paul Hoffman" To: "RFC Errata System" Date: Sat, 13 Aug 2016 14:46:54 -0700 Message-ID: In-Reply-To: <20160813213421.15CF8B80D57@rfc-editor.org> References: <20160813213421.15CF8B80D57@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: smime@ietf.org, ietf@augustcellars.com, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: Re: [smime] [Technical Errata Reported] RFC5753 (4777) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 21:47:26 -0000 Please do not accept this errata until further discussion. Discussion: 1) I believe that the errata would be *much* clearer if the errata was only for the changed sentences, not the whole paragraph. Thus, I think the "Original Text" should start with "The originatorKey publicKey field MUST". If others agree, the submitter could turn in a new errata. 2) The submitter says "This error is also present in sections 3.1.2, 3.1.3, 3.2.1, 3.2.2, 7.2". That feels like it *might* be sufficient for the reader to understand, but it would be clearer if the errata included the change for each of those sections. If others agree, the submitter could turn in a new errata. --Paul Hoffman On 13 Aug 2016, at 14:34, RFC Errata System wrote: > The following errata report has been submitted for RFC5753, > "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic > Message Syntax (CMS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5753&eid=4777 > > -------------------------------------- > Type: Technical > Reported by: Jim Schaad > > Section: 3.1.1 > > Original Text > ------------- > - originator MUST be the alternative originatorKey. The > originatorKey algorithm field MUST contain the id-ecPublicKey > object identifier (see Section 7.1.2). The parameters > associated > with id-ecPublicKey MUST be absent, ECParameters, or NULL. The > parameters associated with id-ecPublicKey SHOULD be absent or > ECParameters, and NULL is allowed to support legacy > implementations. The previous version of this document required > NULL to be present. If the parameters are ECParameters, then > they > MUST be namedCurve. The originatorKey publicKey field MUST > contain the DER encoding of the value of the ASN.1 type ECPoint > (see Section 7.2), which represents the sending agent's > ephemeral > EC public key. The ECPoint in uncompressed form MUST be > supported. > > Corrected Text > -------------- > - originator MUST be the alternative originatorKey. The > originatorKey algorithm field MUST contain the id-ecPublicKey > object identifier (see Section 7.1.2). The parameters > associated > with id-ecPublicKey MUST be absent, ECParameters, or NULL. The > parameters associated with id-ecPublicKey SHOULD be absent or > ECParameters, and NULL is allowed to support legacy > implementations. The previous version of this document required > NULL to be present. If the parameters are ECParameters, then > they > MUST be namedCurve. The originatorKey publicKey field MUST > contain the encoded public key as defined in [X9.62]. The > hybred > form MUST NOT be used. The ECPoint in uncompressed form MUST be > supported. This mirrors the same format used in public key > certificates as defined in Section 2.2 of [RFC5480]. > > Notes > ----- > There is a problem in that for ECPoints, the public key is defined to > be encoded differently in this document than it is in a public key > certificate. The difference is the presence of the ASN.1 OCTET STRING > wrapper. > > OpenSSL and BouncyCastle both use the unwrapped version per Dr. > Stephen Henson note to me in mail. > > This error is also present in sections 3.1.2, 3.1.3, 3.2.1, 3.2.2, 7.2 > > 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 (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5753 (draft-ietf-smime-3278bis-09) > -------------------------------------- > Title : Use of Elliptic Curve Cryptography (ECC) > Algorithms in Cryptographic Message Syntax (CMS) > Publication Date : January 2010 > Author(s) : S. Turner, D. Brown > Category : INFORMATIONAL > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Sat Aug 13 15:00:22 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9912D603 for ; Sat, 13 Aug 2016 15:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 iKuFEtprPZuQ for ; Sat, 13 Aug 2016 15:00:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 EA7E412D0F1 for ; Sat, 13 Aug 2016 15:00:19 -0700 (PDT) Received: from [192.168.123.110] (unknown [75.83.2.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BB2F9509B8; Sat, 13 Aug 2016 18:00:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: Date: Sat, 13 Aug 2016 15:00:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BB5C07D-9368-4166-94A5-0E160CC80CEF@seantek.com> References: <20160811184733.4444EB8111E@rfc-editor.org> <027701d1f584$98da3320$ca8e9960$@augustcellars.com> To: Paul Hoffman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quannguyen@google.com, smime@ietf.org, Jim Schaad , Kathleen.Moriarty.ietf@gmail.com, RFC Errata System , stephen.farrell@cs.tcd.ie Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 22:00:21 -0000 > On Aug 13, 2016, at 10:08 AM, Paul Hoffman = wrote: >=20 > On 13 Aug 2016, at 10:03, Jim Schaad wrote: >=20 >> The first half of this errata must be rejected. We do not change the = ASN.1 >> for something like this under just about any circumstances. >>=20 >> Changing the recommendation of a value should probably not be done by = an >> erratum but by publishing a new document. We could make discuss and = make >> the recommendation change in the new S/MIME document in the LAMPS = group >> rather than in this document. >=20 > I fully agree with Jim on both counts. I also agree with Jim. Sean From nobody Mon Aug 15 11:36:11 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE8C12D620 for ; Mon, 15 Aug 2016 11:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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 oJx1XeMuvai7 for ; Mon, 15 Aug 2016 11:36:08 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A7712D5B9 for ; Mon, 15 Aug 2016 11:36:07 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 15 Aug 2016 11:47:55 -0700 From: Jim Schaad To: 'Paul Hoffman' , 'RFC Errata System' References: <20160813213421.15CF8B80D57@rfc-editor.org> In-Reply-To: Date: Mon, 15 Aug 2016 11:35:39 -0700 Message-ID: <043d01d1f723$d4acb760$7e062620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEzQ8+sRB9NCKosAWB6LnYE/qlN6QKIiwXboXN6+pA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: smime@ietf.org, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: Re: [smime] [Technical Errata Reported] RFC5753 (4777) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 18:36:11 -0000 I will be honest. I would be happier with an update of this document rather than just having the errata. I would be happy to look at this in a couple of days and see if I can make the text clearer than it currently is. I find the text that does the same thing in RFC5480 to be hard to decipher but the easiest thing might still just be to point to that document for how to do this. Jim > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Saturday, August 13, 2016 2:47 PM > To: RFC Errata System > Cc: turners@ieca.com; dbrown@certicom.com; stephen.farrell@cs.tcd.ie; > Kathleen.Moriarty.ietf@gmail.com; blaker@gmail.com; > ietf@augustcellars.com; smime@ietf.org > Subject: Re: [Technical Errata Reported] RFC5753 (4777) > > Please do not accept this errata until further discussion. > > Discussion: > > 1) I believe that the errata would be *much* clearer if the errata was only for > the changed sentences, not the whole paragraph. Thus, I think the "Original > Text" should start with "The originatorKey publicKey field MUST". If others > agree, the submitter could turn in a new errata. > > 2) The submitter says "This error is also present in sections 3.1.2, 3.1.3, 3.2.1, > 3.2.2, 7.2". That feels like it *might* be sufficient for the reader to understand, > but it would be clearer if the errata included the change for each of those > sections. If others agree, the submitter could turn in a new errata. > > --Paul Hoffman > > On 13 Aug 2016, at 14:34, RFC Errata System wrote: > > > The following errata report has been submitted for RFC5753, "Use of > > Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message > > Syntax (CMS)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5753&eid=4777 > > > > -------------------------------------- > > Type: Technical > > Reported by: Jim Schaad > > > > Section: 3.1.1 > > > > Original Text > > ------------- > > - originator MUST be the alternative originatorKey. The > > originatorKey algorithm field MUST contain the id-ecPublicKey > > object identifier (see Section 7.1.2). The parameters > > associated > > with id-ecPublicKey MUST be absent, ECParameters, or NULL. The > > parameters associated with id-ecPublicKey SHOULD be absent or > > ECParameters, and NULL is allowed to support legacy > > implementations. The previous version of this document required > > NULL to be present. If the parameters are ECParameters, then > > they > > MUST be namedCurve. The originatorKey publicKey field MUST > > contain the DER encoding of the value of the ASN.1 type ECPoint > > (see Section 7.2), which represents the sending agent's > > ephemeral > > EC public key. The ECPoint in uncompressed form MUST be > > supported. > > > > Corrected Text > > -------------- > > - originator MUST be the alternative originatorKey. The > > originatorKey algorithm field MUST contain the id-ecPublicKey > > object identifier (see Section 7.1.2). The parameters > > associated > > with id-ecPublicKey MUST be absent, ECParameters, or NULL. The > > parameters associated with id-ecPublicKey SHOULD be absent or > > ECParameters, and NULL is allowed to support legacy > > implementations. The previous version of this document required > > NULL to be present. If the parameters are ECParameters, then > > they > > MUST be namedCurve. The originatorKey publicKey field MUST > > contain the encoded public key as defined in [X9.62]. The > > hybred > > form MUST NOT be used. The ECPoint in uncompressed form MUST be > > supported. This mirrors the same format used in public key > > certificates as defined in Section 2.2 of [RFC5480]. > > > > Notes > > ----- > > There is a problem in that for ECPoints, the public key is defined to > > be encoded differently in this document than it is in a public key > > certificate. The difference is the presence of the ASN.1 OCTET STRING > > wrapper. > > > > OpenSSL and BouncyCastle both use the unwrapped version per Dr. > > Stephen Henson note to me in mail. > > > > This error is also present in sections 3.1.2, 3.1.3, 3.2.1, 3.2.2, 7.2 > > > > 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 (IESG) can log in to > > change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5753 (draft-ietf-smime-3278bis-09) > > -------------------------------------- > > Title : Use of Elliptic Curve Cryptography (ECC) > > Algorithms in Cryptographic Message Syntax (CMS) > > Publication Date : January 2010 > > Author(s) : S. Turner, D. Brown > > Category : INFORMATIONAL > > Source : S/MIME Mail Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG From nobody Mon Aug 15 13:55:41 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7964712D50E for ; Mon, 15 Aug 2016 13:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 fuZIvbrjZTj0 for ; Mon, 15 Aug 2016 13:55:37 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0C912D18A for ; Mon, 15 Aug 2016 13:55:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 784DE3005D8 for ; Mon, 15 Aug 2016 16:55:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L8hpgyaDo2DY for ; Mon, 15 Aug 2016 16:55:32 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 63020300430; Mon, 15 Aug 2016 16:55:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4D8DC90-B21C-4EB0-94B5-B72BBBE318BE" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 15 Aug 2016 16:55:35 -0400 Message-Id: References: <20160811184733.4444EB8111E@rfc-editor.org> To: Quan Nguyen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF SMIME , Paul Hoffman , Kathleen Moriarty , David McGrew , RFC Editor , Stephen Farrell Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 20:55:40 -0000 --Apple-Mail=_C4D8DC90-B21C-4EB0-94B5-B72BBBE318BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Quan: I do not think that we can change the DEFAULT value associated with = these OIDs. Changing the meaning of an absent aes-ICVlen will result in = too many interoperability problems. However, we could put out a very = short RFC that updates RFC 5084 to recommend the use of 16 octet = authentication tags in all situations. =20 Russ On Aug 11, 2016, at 2:49 PM, Quan Nguyen wrote: >=20 >=20 > On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC5084, > "Using AES-CCM and AES-GCM Authenticated Encryption in the = Cryptographic Message Syntax (CMS)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5084&eid=3D4774 >=20 > -------------------------------------- > Type: Technical > Reported by: QUAN NGUYEN >=20 > Section: 3.2 >=20 > Original Text > ------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 12 >=20 > A length of 12 octets is RECOMMENDED. >=20 > Corrected Text > -------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 16 >=20 > A length of 16 octets is RECOMMENDED. >=20 > Notes > ----- > Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a = bug to use 12 bytes authentication tag (aes-ICVlen) as default if the = code path [1] uses CMS. According to Ferguson's attack = (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fer= guson2.pdf), if a user encrypts 2^32 block length message, then 12 bytes = authentication tag length has only 96 - 32 =3D 64 bits security which is = not good enough nowadays. Furthermore, once a forgery happens then = authentication is leaked. >=20 > Sorry, I meant "authentication key" is leaked.=20 >=20 > [1] In other code paths, all providers use 16 bytes authentication tag = as default. >=20 > 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 (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) > -------------------------------------- > Title : Using AES-CCM and AES-GCM Authenticated = Encryption in the Cryptographic Message Syntax (CMS) > Publication Date : November 2007 > Author(s) : R. Housley > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG >=20 >=20 --Apple-Mail=_C4D8DC90-B21C-4EB0-94B5-B72BBBE318BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Quan:

I do not think that we can = change the DEFAULT value associated with these OIDs.  Changing the = meaning of an absent aes-ICVlen will result in too many interoperability = problems.  However, we could put out a very short RFC that updates = RFC 5084 to recommend the use of 16 octet authentication tags in all = situations. =  

Russ


On Aug 11, 2016, at 2:49 PM, Quan Nguyen <quannguyen@google.com> = wrote:



On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata = System <rfc-editor@rfc-editor.org> = wrote:
The following errata = report has been submitted for RFC5084,
"Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic = Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5= 084&eid=3D4774

--------------------------------------
Type: Technical
Reported by: QUAN NGUYEN <quannguyen@google.com>

Section: 3.2

Original Text
-------------
aes-ICVlen       AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is RECOMMENDED.

Corrected Text
--------------
aes-ICVlen       AES-GCM-ICVlen DEFAULT 16

A length of 16 octets is RECOMMENDED.

Notes
-----
Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug = to use 12 bytes authentication tag (aes-ICVlen) as default if the code = path [1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolkit/BCM/document= s/comments/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 = block length message, then 12 bytes authentication tag length has only = 96 - 32 =3D 64 bits security which is not good enough nowadays. = Furthermore, once a forgery happens then authentication is = leaked.

Sorry, I meant = "authentication key" is leaked. 

[1] In other code paths, all providers use 16 bytes authentication tag = as default.

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 (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03)
--------------------------------------
Title               : Using = AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic = Message Syntax (CMS)
Publication Date    : November 2007
Author(s)           : R. Housley
Category            : PROPOSED = STANDARD
Source              : S/MIME Mail = Security
Area                : = Security
Stream              : IETF
Verifying Party     : IESG



= --Apple-Mail=_C4D8DC90-B21C-4EB0-94B5-B72BBBE318BE-- From nobody Mon Aug 15 14:37:19 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D0C12D08F for ; Mon, 15 Aug 2016 14:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 mGS0D4TsPcx4 for ; Mon, 15 Aug 2016 14:37:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69417120727 for ; Mon, 15 Aug 2016 14:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4034F3005D7 for ; Mon, 15 Aug 2016 17:37:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cDWRmNSL1jM8 for ; Mon, 15 Aug 2016 17:37:12 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id CE52A3000E3; Mon, 15 Aug 2016 17:37:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8A8AAC23-E0FE-48D2-B952-778648994DB9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 15 Aug 2016 17:27:44 -0400 Message-Id: <5129C662-699A-447A-9767-1B6116B0B431@vigilsec.com> References: <20160811184733.4444EB8111E@rfc-editor.org> To: Quan Nguyen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF SMIME , Paul Hoffman , Kathleen Moriarty , David McGrew , RFC Editor , Stephen Farrell Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:37:17 -0000 --Apple-Mail=_8A8AAC23-E0FE-48D2-B952-778648994DB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Quan: > I do not think that we can change the DEFAULT value associated with = these OIDs. Changing the meaning of an absent aes-ICVlen will result in = too many interoperability problems. >=20 > Yeah, I'm aware of it and I understand your concern. > =20 > However, we could put out a very short RFC that updates RFC 5084 to = recommend the use of 16 octet authentication tags in all situations. =20 >=20 > Thanks for doing this :) It's SGTM. Are you willing to help write? Russ= --Apple-Mail=_8A8AAC23-E0FE-48D2-B952-778648994DB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Quan:

I do not think that we can change the = DEFAULT value associated with these OIDs.  Changing the meaning of = an absent aes-ICVlen will result in too many interoperability = problems.

Yeah, = I'm aware of it and I understand your concern.
 
 However, we could put out a very = short RFC that updates RFC 5084 to recommend the use of 16 octet = authentication tags in all situations.  

Thanks for doing this :) It's = SGTM.

Are you willing to help = write?

Russ
= --Apple-Mail=_8A8AAC23-E0FE-48D2-B952-778648994DB9-- From quannguyen@google.com Thu Aug 11 11:50:17 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B15512D7FF for ; Thu, 11 Aug 2016 11:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 O9AtlnBe2V9y for ; Thu, 11 Aug 2016 11:50:15 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 94E64127077 for ; Thu, 11 Aug 2016 11:50:15 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id n59so7374055uan.2 for ; Thu, 11 Aug 2016 11:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vj5bB4SOVRH7adfCJ6fPwP9eGngCJ2LPV5cvrisLJaE=; b=jQa5/ci3j99y6M5ZC4PHk9Cwc+FweRe+Uz4m2tea+xqsyTcufTtKau0RlDylkESlHe jkfs6X2o7Cf2YmNm/oVVgJDFyrzwLrRm7ia6SL2sFgywcOl1pI98Bc2nq5KFjUCG8KWk WuA1N2wKH4ts0mfEu1NYAMU6xjBXxnFnkX46jPLsMbKSKSe75B/0uUlbYY0vbXxsXmST XI750BwSZoyGVPv8cOqlga8l2dsyamJTRg4ctwrNMvuGocR3gvZDVCiVfKYbSyX899hv yG8ttGZ86PpYIjExPFGHeGDWRP6b1g0irHMjkqESfapRW8e8aBWfW8pGiZ/4saD2lzJD j5ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vj5bB4SOVRH7adfCJ6fPwP9eGngCJ2LPV5cvrisLJaE=; b=LoBmD85J5pC0zff+L0zNTEQ7D81YT8m1ZEZq797pwJKrQ/otoxLZhLy9jdj66RIfTj jjOJ8hz3MXZXylz3UZn1l/yv84ZxMnAU+rP5UCfJtTN2ObhiKTpgwxn2UfZHBSML/RZz VDqYELIfcBeZkUhEk2vklPr/IiBMrzyzaSSXOfCMwNtWSI21KYLa2euf3tJfZlQTMr4m soIfC36hwpwiDPFo8T8n9rycuw6XjcpfFdjloJo/E0WN33B031UI/Lt+qUTXmZmAjpNE P5NdqQQRMxrvKhMbEQkxVxM1+91L3wS4AMCZslndSqNKdvfvyDImESJpOl9184XZnpG/ RfZg== X-Gm-Message-State: AEkoouvHK/KYJ2WYojDkMrkioZTIbTeoplkjqBmi3XYmxd76UeWUW7hz6IE8AlrksRxRvvOeqFXGQ4nODskswmM4 X-Received: by 10.31.244.138 with SMTP id s132mr1225125vkh.49.1470941414645; Thu, 11 Aug 2016 11:50:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.151.197 with HTTP; Thu, 11 Aug 2016 11:49:54 -0700 (PDT) In-Reply-To: <20160811184733.4444EB8111E@rfc-editor.org> References: <20160811184733.4444EB8111E@rfc-editor.org> From: Quan Nguyen Date: Thu, 11 Aug 2016 11:49:54 -0700 Message-ID: To: RFC Errata System Content-Type: multipart/alternative; boundary=94eb2c1124f281d22c0539d03c73 Archived-At: X-Mailman-Approved-At: Mon, 15 Aug 2016 14:47:09 -0700 Cc: smime@ietf.org, paul.hoffman@vpnc.org, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 18:54:56 -0000 --94eb2c1124f281d22c0539d03c73 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > The following errata report has been submitted for RFC5084, > "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic > Message Syntax (CMS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 > > -------------------------------------- > Type: Technical > Reported by: QUAN NGUYEN > > Section: 3.2 > > Original Text > ------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 12 > > A length of 12 octets is RECOMMENDED. > > Corrected Text > -------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 16 > > A length of 16 octets is RECOMMENDED. > > Notes > ----- > Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug > to use 12 bytes authentication tag (aes-ICVlen) as default if the code path > [1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ > ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf), if a user > encrypts 2^32 block length message, then 12 bytes authentication tag length > has only 96 - 32 = 64 bits security which is not good enough nowadays. > Furthermore, once a forgery happens then authentication is leaked. > Sorry, I meant "authentication *key*" is leaked. > > [1] In other code paths, all providers use 16 bytes authentication tag as > default. > > 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 (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) > -------------------------------------- > Title : Using AES-CCM and AES-GCM Authenticated Encryption > in the Cryptographic Message Syntax (CMS) > Publication Date : November 2007 > Author(s) : R. Housley > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > --94eb2c1124f281d22c0539d03c73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System &= lt;rfc-edito= r@rfc-editor.org> wrote:
Th= e following errata report has been submitted for RFC5084,
"Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptograph= ic Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5084&eid=3D4774

--------------------------------------
Type: Technical
Reported by: QUAN NGUYEN <quann= guyen@google.com>

Section: 3.2

Original Text
-------------
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is RECOMMENDED.

Corrected Text
--------------
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 16

A length of 16 octets is RECOMMENDED.

Notes
-----
Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug to= use 12 bytes authentication tag (aes-ICVlen) as default if the code path [= 1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolk= it/BCM/documents/comments/CWC-GCM/Ferguson2.pdf), if a user e= ncrypts 2^32 block length message, then 12 bytes authentication tag length = has only 96 - 32 =3D 64 bits security which is not good enough nowadays. Fu= rthermore, once a forgery happens then authentication is leaked.

Sorry, I meant "authentication key&qu= ot; is leaked.=C2=A0

[1] In other code paths, all providers use 16 bytes authentication tag as d= efault.

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

--------------------------------------
RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Using AES-CCM= and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (= CMS)
Publication Date=C2=A0 =C2=A0 : November 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Housley
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Securi= ty
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG


--94eb2c1124f281d22c0539d03c73-- From nobody Mon Aug 15 14:47:14 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D9B12D73D for ; Mon, 15 Aug 2016 14:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 uK1S2HdETQPB for ; Mon, 15 Aug 2016 14:01:02 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 BDF7312D518 for ; Mon, 15 Aug 2016 14:01:01 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k90so91723371uak.1 for ; Mon, 15 Aug 2016 14:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w/TftVYSoMr33j5crcJKCdUNya7JWc3Uuf1UlL2NdeI=; b=WKnJQM5jC1RLyR3qFWxj8Q6XKcvnzZeMzfisnJQxQeX4cwAuapeHfJvuoiWNnrJr1D c4M2xRdqVROV5CV8qm9W95rgXi36updjiNNET80Mn1YPdYa0z1pt4ChgQl+BDkRGr1TV PI+TNqjpUDAcmi95qdwcUoyanERPWv4bVtnKhSBVOGGC/8e7t4x6hNG6hf7W1myAS1Pe 2rhhXuVtMsVP+5vaGaV7M2QyINkfaE+H8HYhJrCz2atuEBelciyKKHh84lW/ABbfO5fh EbjdTIRO+uXRtTEK+gOjwxU9ScNWi+OuTHr8Fab8ZblesKm1m1EKQsx9d91dg7f5Mp8J WOSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w/TftVYSoMr33j5crcJKCdUNya7JWc3Uuf1UlL2NdeI=; b=e3J9QcYKdHkn4yL8VAe7wDHJq3V2BWVBM59/HuX4wDVjSlTlYBhG1N6061vgnR5GQ0 Bk9RDvJcxJotp4TXmUZE/E3u+WekNjUVNiLU2DN3MuoP9aghSowvSL9iLxr6tun7ihHZ +//Ppc6HkCW7WpAOkgnOPTJo90KjQ0kHCxed8xCk8ZGGu+RJBx2nTEV446NskIptm7gK n7oeakq4Up34/Au3Jx8Vn7hdjF+dkTAnI5CKaWpnWRRudjMDQjIhVuRsz0NupO4E82nq Rj7J7pQVEmCQEqCsYJxOuOfJRHYOFFdRilOXibrpolM2AkMLmEb4Pk9t3hQQKNB9tgAk nSGg== X-Gm-Message-State: AEkoouvuuzTdVvyu+qoUhHutULQu9Rymarp+YYjFXtCHbTT2tVwsv1LvEWHK2qv4XYePcBQkPcHUJuUA24z++O0U X-Received: by 10.31.8.213 with SMTP id 204mr5837270vki.33.1471294860553; Mon, 15 Aug 2016 14:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.139.131 with HTTP; Mon, 15 Aug 2016 14:00:39 -0700 (PDT) In-Reply-To: References: <20160811184733.4444EB8111E@rfc-editor.org> From: Quan Nguyen Date: Mon, 15 Aug 2016 14:00:39 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a1142e6e8863615053a228743 Archived-At: X-Mailman-Approved-At: Mon, 15 Aug 2016 14:47:09 -0700 Cc: IETF SMIME , Paul Hoffman , Kathleen Moriarty , David McGrew , RFC Editor , Stephen Farrell Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:01:05 -0000 --001a1142e6e8863615053a228743 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley wrote: > Quan: > > I do not think that we can change the DEFAULT value associated with these > OIDs. Changing the meaning of an absent aes-ICVlen will result in too many > interoperability problems. > Yeah, I'm aware of it and I understand your concern. > However, we could put out a very short RFC that updates RFC 5084 to > recommend the use of 16 octet authentication tags in all situations. > Thanks for doing this :) It's SGTM. > > Russ > > > On Aug 11, 2016, at 2:49 PM, Quan Nguyen wrote: > > > > On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC5084, >> "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic >> Message Syntax (CMS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 >> >> -------------------------------------- >> Type: Technical >> Reported by: QUAN NGUYEN >> >> Section: 3.2 >> >> Original Text >> ------------- >> aes-ICVlen AES-GCM-ICVlen DEFAULT 12 >> >> A length of 12 octets is RECOMMENDED. >> >> Corrected Text >> -------------- >> aes-ICVlen AES-GCM-ICVlen DEFAULT 16 >> >> A length of 16 octets is RECOMMENDED. >> >> Notes >> ----- >> Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug >> to use 12 bytes authentication tag (aes-ICVlen) as default if the code path >> [1] uses CMS. According to Ferguson's attack ( >> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen >> ts/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, >> then 12 bytes authentication tag length has only 96 - 32 = 64 bits security >> which is not good enough nowadays. Furthermore, once a forgery happens then >> authentication is leaked. >> > > Sorry, I meant "authentication *key*" is leaked. > >> >> [1] In other code paths, all providers use 16 bytes authentication tag as >> default. >> >> 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 (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) >> -------------------------------------- >> Title : Using AES-CCM and AES-GCM Authenticated Encryption >> in the Cryptographic Message Syntax (CMS) >> Publication Date : November 2007 >> Author(s) : R. Housley >> Category : PROPOSED STANDARD >> Source : S/MIME Mail Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> > > --001a1142e6e8863615053a228743 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley <housley@vigilsec.com= > wrote:
Quan:

I do not think that we can chang= e the DEFAULT value associated with these OIDs.=C2=A0 Changing the meaning = of an absent aes-ICVlen will result in too many interoperability problems. =

Yeah, I'm aware of it and = I understand your concern.
=C2=A0
=C2=A0However, we could put o= ut a very short RFC that updates RFC 5084 to recommend the use of 16 octet = authentication tags in all situations. =C2=A0
=
Thanks for doing this :) It's SGTM.
=

Russ


On Aug 11, 2016, at 2:49 = PM, Quan Nguyen <quannguyen@google.com> wrote:



On Thu, Aug = 11, 2016 at 11:47 AM, RFC Errata System <rfc-editor@rfc-editor.org= > wrote:
The following erra= ta report has been submitted for RFC5084,
"Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptograph= ic Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D5084&eid=3D4774

--------------------------------------
Type: Technical
Reported by: QUAN NGUYEN <quannguyen@google.com>

Section: 3.2

Original Text
-------------
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is RECOMMENDED.

Corrected Text
--------------
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 16

A length of 16 octets is RECOMMENDED.

Notes
-----
Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug to= use 12 bytes authentication tag (aes-ICVlen) as default if the code path [= 1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolk= it/BCM/documents/comments/CWC-GCM/Ferguson2.pdf), if a user encryp= ts 2^32 block length message, then 12 bytes authentication tag length has o= nly 96 - 32 =3D 64 bits security which is not good enough nowadays. Further= more, once a forgery happens then authentication is leaked.

Sorry, I meant "authentication key" i= s leaked.=C2=A0

[1] In other code paths, all providers use 16 bytes authentication tag as d= efault.

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

--------------------------------------
RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Using AES-CCM= and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (= CMS)
Publication Date=C2=A0 =C2=A0 : November 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Housley
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Securi= ty
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG




--001a1142e6e8863615053a228743-- From nobody Mon Aug 15 14:47:16 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862AD12B05E for ; Mon, 15 Aug 2016 14:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 c_7-EugN5ACH for ; Mon, 15 Aug 2016 14:44:55 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 BDC6212B020 for ; Mon, 15 Aug 2016 14:44:54 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 97so93175228uav.3 for ; Mon, 15 Aug 2016 14:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vtaRC9gEcinItqpDWKZXteMb/b7INe1banyoY4gE+Cs=; b=LKtoklyHA/AI1D3S777vrhU3QU3zzBpBd9jAeuvOxYtA0/tACtb5g68mSr54eiJ00/ WfvvNrpoAvpiouDopVD9S25Ic0nW0jNcxwGNPIEsx9vRiXppBa85hm5OhdVltgFbtqMe DdtlsWaVxFF4wAugOo6FlxtwME3Ctu5czIUypbSL4pGP8FO11Ylu+aimh1aN4R4YQX9h eRieFyZK2+aGvJQrg7qCykzMAFFQvzWwLioJk8gh1JkReVw7NGot3jkwc+QP6JyJ/EIl XcWPCajwkhgMPGrmu4hFYcRt3lf4HMS4fgi1FaJiwRbEZcvMkVHJVQhAF5LJF9Sg2P6C U46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vtaRC9gEcinItqpDWKZXteMb/b7INe1banyoY4gE+Cs=; b=YnsVw2f8k/iiyoaMPLfnfvvfAu/gFyOYnKtAlLD8jhSsV8uyU2MVnlhxpaTlmjtTUX Bp8op6WbHb+fHE6VjxVQeOqWM9mOzg8K1i5JxnWThW+1iNgMGKo/Vyd1ncj2iSAooXPV Di6EFqqPHJacKCh9qX5y4/RtMbc9ZvKzWOnE2+upozaSFSw/qH7ve2ZpKM3JvJo6oyHj 6BFwBWt914jv3LU7fGTS2vbgskJYt00PbpGH2kSSgJCN00G7TFzVKry161ifLth9IYKm ZmdOZ0lbIaN+t6wZTu62mfY/HJOJdtT22mM/N3BkNiOaZBO1Z5oOEO3dkMc/D+dZF3gF TFlw== X-Gm-Message-State: AEkoouspJiQHyS5FSsJE+vKpQCAXl76Av+hSEPKUZihr75lot994sfPpkeMX5DGgt+apcUeIhDr8/CDa/KcNcC7m X-Received: by 10.31.155.194 with SMTP id d185mr12169059vke.98.1471297493745; Mon, 15 Aug 2016 14:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.139.131 with HTTP; Mon, 15 Aug 2016 14:44:33 -0700 (PDT) In-Reply-To: <5129C662-699A-447A-9767-1B6116B0B431@vigilsec.com> References: <20160811184733.4444EB8111E@rfc-editor.org> <5129C662-699A-447A-9767-1B6116B0B431@vigilsec.com> From: Quan Nguyen Date: Mon, 15 Aug 2016 14:44:33 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a1140f2d079a678053a232422 Archived-At: X-Mailman-Approved-At: Mon, 15 Aug 2016 14:47:09 -0700 Cc: IETF SMIME , Paul Hoffman , Kathleen Moriarty , David McGrew , RFC Editor , Stephen Farrell Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2016 21:44:56 -0000 --001a1140f2d079a678053a232422 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 15, 2016 at 2:27 PM, Russ Housley wrote: > Quan: > > I do not think that we can change the DEFAULT value associated with these >> OIDs. Changing the meaning of an absent aes-ICVlen will result in too many >> interoperability problems. >> > > Yeah, I'm aware of it and I understand your concern. > > >> However, we could put out a very short RFC that updates RFC 5084 to >> recommend the use of 16 octet authentication tags in all situations. >> > > Thanks for doing this :) It's SGTM. > > > Are you willing to help write? > If you need opinion or having (security-wised) questions, I'm here to answer yours. I can't help with writing because English is not my native language and I'm not good at writing English ( this is the skill that I'm trying to improve). > > Russ > --001a1140f2d079a678053a232422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 15, 2016 at 2:27 PM, Russ Housley <housley@vigilsec.com= > wrote:
Quan:
<= br class=3D"gmail-m_-3553694759156540188Apple-interchange-newline">
I do not think that we can change the DEFAULT value associated with= these OIDs.=C2=A0 Changing the meaning of an absent aes-ICVlen will result= in too many interoperability problems.

Yeah, I'm aware= of it and I understand your concern.
=C2=A0
=C2=A0However, we could put out a ve= ry short RFC that updates RFC 5084 to recommend the use of 16 octet authent= ication tags in all situations. =C2=A0

Thanks for doing thi= s :) It's SGTM.

Are you willing= to help write?

If you need opi= nion or having (security-wised)=C2=A0questions, I'm here to answer your= s. I can't help with writing because English is not my native language = and I'm not good at writing English ( this is the skill that I'm tr= ying to improve).

Russ

--001a1140f2d079a678053a232422-- From nobody Thu Aug 18 10:32:55 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8365712D9F3; Thu, 18 Aug 2016 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001] autolearn=no 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 nS9uT5lvzSMi; Thu, 18 Aug 2016 10:32:34 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 B113E12D9FB; Thu, 18 Aug 2016 10:30:28 -0700 (PDT) Received: from unk-426d04fb.adelphiacom.net (unknown [107.14.56.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A198122E255; Thu, 18 Aug 2016 13:30:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <20160818141051.15761.qmail@ary.lan> Date: Thu, 18 Aug 2016 10:30:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DC08C20-D22E-4024-A195-C79E1A1EA3DC@seantek.com> References: <20160818141051.15761.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Arnt Gulbrandsen , ietf-smtp@ietf.org, IETF SMIME Subject: Re: [smime] [ietf-smtp] Draft for compressing SMTP streams X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 17:32:38 -0000 +1 to smime@ > On Aug 18, 2016, at 7:10 AM, John Levine wrote: >=20 >> Or perhaps=20 >> not want compression at all. SMTP has different problems than IMAP,=20= >> which I think simple compression will not fix: Submit sees a single=20= >> message per connection, plain SMTP sees mostly spam. Why implement=20 >> compression, then? >=20 > I think the motivation is people sending around large documents in > formats like Word and Excel. Pictures and videos aren't very > compressible, but they're base64 encoded so compressing that tends to > get you back to the original size. (You don't have to tell me that > BINARYMIME and BDAT solve that particular problem better.) Modern Word and Excel files are in ZIP container formats. Therefore, = they are already compressed. [Looks like Paul Smith already posted about = this.] I would like to see implementations of SMTP compression, but more = important than that is binary SMTP (aka BINARYMIME / BDAT), RFC 3030. = The difficulty here in addition to general SMTP deployment issues, is = that storage has to be binary-clean, which has effects on POP and IMAP. = But that is an easy way to save 37%+ on bandwidth. If the entire payload is base64-encoded and is in standard form (72 = characters per line, no weird spaces, etc.), then it would be = straightforward to convert the base64 part (of which only 1 exists) to = binary, and then de-convert it back for storage. Servers that support EAI have to support 8-bit clean channels, except = for control characters and NULL. Therefore they can be seen as part of = the same (not-small) infrastructure upgrade. S/MIME supports compression, RFC 3274. It is not widely supported, but I = know of at least one mail client that supports it. It would be good to = support that as well, especially since end-to-end encrypted content will = not be further compressible. OpenPGP already supports compression widely = (standard algorithms: DEFLATE etc.). Sean >=20 > Early on people from Gmail experessed interest, but I haven't heard > from them for a while. >=20 > R's, > John >=20 > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp From nobody Thu Aug 18 11:39:43 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB5612D0C6 for ; Thu, 18 Aug 2016 11:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 pNj7JL1yRLIm for ; Thu, 18 Aug 2016 11:39:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FAF12D87A for ; Thu, 18 Aug 2016 11:39:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DAA0E3005C9 for ; Thu, 18 Aug 2016 14:39:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LnaVoc7-eQOT for ; Thu, 18 Aug 2016 14:39:32 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id AC0B8300289; Thu, 18 Aug 2016 14:39:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_69D2FBA7-86B3-4624-B996-194531C9CD43" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 18 Aug 2016 14:39:32 -0400 Message-Id: <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> References: <20160811184733.4444EB8111E@rfc-editor.org> To: Quan Nguyen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Kathleen Moriarty , IETF SMIME , David McGrew , Stephen Farrell Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 18:39:42 -0000 --Apple-Mail=_69D2FBA7-86B3-4624-B996-194531C9CD43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Quan: I just read the cited paper from Niels Ferguson = . Niels says: After 2^16 forgery attempts we can expect a successful forgery. And, then Niels talks about an encrypted voice environment where this = attack might lead to disastrous consequences. Also, Niels points out that the AES-GCM security proof is unbroken by = this attack. He is staying within the bounds of the proven security. It is hard to imagine a protocol environment that uses CMS where 2^16 = extra messages would be undetected. In addition RFC 5084 requires automated key management. This means that = a fresh AES-GCM key ought to be used for each of the messages. I = recognize that attackers do not follow the specification, but it means = that they cannot just use an existing implementation. These two observations make me wonder whether the is enough of a problem = to bother with an update to RFC 5084. What do you think? Russ > On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley = wrote: > Quan: >=20 > I do not think that we can change the DEFAULT value associated with = these OIDs. Changing the meaning of an absent aes-ICVlen will result in = too many interoperability problems. >=20 > Yeah, I'm aware of it and I understand your concern. > =20 > However, we could put out a very short RFC that updates RFC 5084 to = recommend the use of 16 octet authentication tags in all situations. =20 >=20 > Thanks for doing this :) It's SGTM. >=20 > Russ >=20 >=20 > On Aug 11, 2016, at 2:49 PM, Quan Nguyen = wrote: >=20 >>=20 >>=20 >> On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System = wrote: >> The following errata report has been submitted for RFC5084, >> "Using AES-CCM and AES-GCM Authenticated Encryption in the = Cryptographic Message Syntax (CMS)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5084&eid=3D4774 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: QUAN NGUYEN >>=20 >> Section: 3.2 >>=20 >> Original Text >> ------------- >> aes-ICVlen AES-GCM-ICVlen DEFAULT 12 >>=20 >> A length of 12 octets is RECOMMENDED. >>=20 >> Corrected Text >> -------------- >> aes-ICVlen AES-GCM-ICVlen DEFAULT 16 >>=20 >> A length of 16 octets is RECOMMENDED. >>=20 >> Notes >> ----- >> Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a = bug to use 12 bytes authentication tag (aes-ICVlen) as default if the = code path [1] uses CMS. According to Ferguson's attack = (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fer= guson2.pdf), if a user encrypts 2^32 block length message, then 12 bytes = authentication tag length has only 96 - 32 =3D 64 bits security which is = not good enough nowadays. Furthermore, once a forgery happens then = authentication is leaked. >>=20 >> Sorry, I meant "authentication key" is leaked.=20 >>=20 >> [1] In other code paths, all providers use 16 bytes authentication = tag as default. >>=20 >> 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 (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) >> -------------------------------------- >> Title : Using AES-CCM and AES-GCM Authenticated = Encryption in the Cryptographic Message Syntax (CMS) >> Publication Date : November 2007 >> Author(s) : R. Housley >> Category : PROPOSED STANDARD >> Source : S/MIME Mail Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >>=20 >>=20 >=20 >=20 --Apple-Mail=_69D2FBA7-86B3-4624-B996-194531C9CD43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Quan:

I just read the cited paper = from Niels Ferguson <http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/co= mments/CWC-GCM/Ferguson2.pdf>.  Niels = says:

   After 2^16 forgery attempts = we can expect a successful forgery.

And, then = Niels talks about an encrypted voice environment where this attack might = lead to disastrous consequences.

Also, Niels = points out that the AES-GCM security proof is unbroken by this attack. =  He is staying within the bounds of the proven = security.

It is hard to imagine a protocol = environment that uses CMS where 2^16 extra messages would be = undetected.

In addition RFC 5084 requires = automated key management.  This means that a fresh AES-GCM key = ought to be used for each of the messages.  I recognize that = attackers do not follow the specification, but it means that they cannot = just use an existing implementation.

These two = observations make me wonder whether the is enough of a problem to bother = with an update to RFC 5084.  What do you = think?

Russ


On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley = <housley@vigilsec.com> = wrote:
Quan:

I do not think = that we can change the DEFAULT value associated with these OIDs.  = Changing the meaning of an absent aes-ICVlen will result in too many = interoperability problems. =

Yeah, I'm aware of it and I = understand your concern.
 
 However,= we could put out a very short RFC that updates RFC 5084 to recommend = the use of 16 octet authentication tags in all situations. =  

Thanks for doing this :) = It's SGTM.

Russ


On Aug 11, 2016, at 2:49 = PM, Quan Nguyen <quannguyen@google.com> wrote:



On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata = System <rfc-editor@rfc-editor.org> = wrote:
The following errata = report has been submitted for RFC5084,
"Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic = Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5= 084&eid=3D4774

--------------------------------------
Type: Technical
Reported by: QUAN NGUYEN <quannguyen@google.com>

Section: 3.2

Original Text
-------------
aes-ICVlen       AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is RECOMMENDED.

Corrected Text
--------------
aes-ICVlen       AES-GCM-ICVlen DEFAULT 16

A length of 16 octets is RECOMMENDED.

Notes
-----
Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug = to use 12 bytes authentication tag (aes-ICVlen) as default if the code = path [1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolkit/BCM/document= s/comments/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 = block length message, then 12 bytes authentication tag length has only = 96 - 32 =3D 64 bits security which is not good enough nowadays. = Furthermore, once a forgery happens then authentication is = leaked.

Sorry, I meant = "authentication key" is leaked. 

[1] In other code paths, all providers use 16 bytes authentication tag = as default.

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 (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03)
--------------------------------------
Title               : Using = AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic = Message Syntax (CMS)
Publication Date    : November 2007
Author(s)           : R. Housley
Category            : PROPOSED = STANDARD
Source              : S/MIME Mail = Security
Area                : = Security
Stream              : IETF
Verifying Party     : IESG


=



= --Apple-Mail=_69D2FBA7-86B3-4624-B996-194531C9CD43-- From nobody Thu Aug 18 12:15:14 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1603512D5C9 for ; Thu, 18 Aug 2016 12:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 pluaeLn5aJAl for ; Thu, 18 Aug 2016 12:07:38 -0700 (PDT) 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 EEE4E12D616 for ; Thu, 18 Aug 2016 12:07:37 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 97so43849785uav.3 for ; Thu, 18 Aug 2016 12:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zxQqHrzGZad5+8WSgdAziioNnOpHC7RQXWwm+MuOEjI=; b=HzvJfY0HDJpSspvcQfUrgjUbsSmQl2/2ZE2hTLKYGg/tA1QZDNOA+tiMSR/EPL39F1 2amtf8NPlHNp2Ek1JrgsiJZNUN9KFeOQgrWKHw45gcKtFiT1tAc8Ue1zGH08wicgX1M3 oB5zDRCVTRle/aJ5BdgV0kJD1+1+OueXuCYxGPGJ7o4Jp+ql2spWtREcRRYbkxD/gJnn pmy69jpMBElGnBPHjUU/tUkyi2MWTRkH02/j4R0EdQmrsXc9QNQB+DpUwll5uiu/o6Ly bfv0YlupkwyxWOUFJB1TBLWMx8HHVEIPZMOhMeRD7U0U1y6eS4a4eiJEX+mSDlPmbf5P TPvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zxQqHrzGZad5+8WSgdAziioNnOpHC7RQXWwm+MuOEjI=; b=Fz1aCg2Cyh4HCSq+kUXyYCg755yYhK8szcBr9Ff3NzjJCmCxPT5fNVoqAyZlzO982U zfS25vnb3ATew38wvk32kIsJWKxsc5gaDu2XpTbwP/mDVmo3dr/tIRC0X+T/Rvdu7oBd YBSWuVDv+WAYg5VRtHE+Uw3iaD3gEucsM0XvebVuCL5SuknN4yMJG9m0QYxDQMDCiBJU KOtVkxHafM//YogSsqLLBgTMmlIn8LsUjqqOqLa709+cLkuNHPiSBJRX+YhIR7mmhmGl Ic/ksaJfcx/rigoiEgxehsykBlCXAbAwxw0UUJoiZkW7kf0WOgjnpJ5xvnKUT+Nqsg5o 4m6g== X-Gm-Message-State: AEkoousYp0fpKPbl8RFbdwtSq3aORX1gy1wH06xKANX6RpCemMGJLl67g1PBtE0/w2+1mS0hiz+nXp3OgKMF4mmN X-Received: by 10.176.69.168 with SMTP id u37mr1640527uau.16.1471547256957; Thu, 18 Aug 2016 12:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.139.131 with HTTP; Thu, 18 Aug 2016 12:07:16 -0700 (PDT) In-Reply-To: <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> References: <20160811184733.4444EB8111E@rfc-editor.org> <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> From: Quan Nguyen Date: Thu, 18 Aug 2016 12:07:16 -0700 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=94eb2c11c9e685d029053a5d4bd3 Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 12:15:12 -0700 Cc: Kathleen Moriarty , IETF SMIME , David McGrew , Stephen Farrell Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 19:07:41 -0000 --94eb2c11c9e685d029053a5d4bd3 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley wrote: > Quan: > > I just read the cited paper from Niels Ferguson < > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen > ts/CWC-GCM/Ferguson2.pdf>. Niels says: > > After 2^16 forgery attempts we can expect a successful forgery. > > And, then Niels talks about an encrypted voice environment where this > attack might lead to disastrous consequences. > > Also, Niels points out that the AES-GCM security proof is unbroken by this > attack. He is staying within the bounds of the proven security. > Yeah, but the proven security wasn't clear about the weakness/fragility of GCM. The attack explicitly showed how to exploit the weakness. > > It is hard to imagine a protocol environment that uses CMS where 2^16 > extra messages would be undetected. > > In addition RFC 5084 requires automated key management. This means that a > fresh AES-GCM key ought to be used for each of the messages. > Oh, this is interesting. The problem I saw with OpenJDK, BouncyCastle, Conscrypt is when Java Cipher (https://docs.oracle.com/ javase/7/docs/api/javax/crypto/Cipher.html) is initialized to use GCM mode: 1. In one case, if the parameter is ASN.1 encoded and aes-ICVlen is missing then it's interpreted as 12-byte. 2. In other case, they use 12-byte tag, citing RFC 5084 recommendation. For instance, see : https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/symmetric/AES.java#L497 Note that Cipher is a *general *crypto primitive which may be used to encrypt *multiple* messages. So there may be misunderstanding every now and then. It's worth to note that I had a hard time convincing developers to change because they cited RFC :( I recognize that attackers do not follow the specification, but it means > that they cannot just use an existing implementation. > > These two observations make me wonder whether the is enough of a problem > to bother with an update to RFC 5084. What do you think? > > Russ > > > On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley > wrote: > >> Quan: >> >> I do not think that we can change the DEFAULT value associated with these >> OIDs. Changing the meaning of an absent aes-ICVlen will result in too many >> interoperability problems. >> > > Yeah, I'm aware of it and I understand your concern. > > >> However, we could put out a very short RFC that updates RFC 5084 to >> recommend the use of 16 octet authentication tags in all situations. >> > > Thanks for doing this :) It's SGTM. > >> >> Russ >> >> >> On Aug 11, 2016, at 2:49 PM, Quan Nguyen wrote: >> >> >> >> On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System < >> rfc-editor@rfc-editor.org> wrote: >> >>> The following errata report has been submitted for RFC5084, >>> "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic >>> Message Syntax (CMS)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: QUAN NGUYEN >>> >>> Section: 3.2 >>> >>> Original Text >>> ------------- >>> aes-ICVlen AES-GCM-ICVlen DEFAULT 12 >>> >>> A length of 12 octets is RECOMMENDED. >>> >>> Corrected Text >>> -------------- >>> aes-ICVlen AES-GCM-ICVlen DEFAULT 16 >>> >>> A length of 16 octets is RECOMMENDED. >>> >>> Notes >>> ----- >>> Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug >>> to use 12 bytes authentication tag (aes-ICVlen) as default if the code path >>> [1] uses CMS. According to Ferguson's attack ( >>> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen >>> ts/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length >>> message, then 12 bytes authentication tag length has only 96 - 32 = 64 bits >>> security which is not good enough nowadays. Furthermore, once a forgery >>> happens then authentication is leaked. >>> >> >> Sorry, I meant "authentication *key*" is leaked. >> >>> >>> [1] In other code paths, all providers use 16 bytes authentication tag >>> as default. >>> >>> 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 (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) >>> -------------------------------------- >>> Title : Using AES-CCM and AES-GCM Authenticated Encryption >>> in the Cryptographic Message Syntax (CMS) >>> Publication Date : November 2007 >>> Author(s) : R. Housley >>> Category : PROPOSED STANDARD >>> Source : S/MIME Mail Security >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> >>> >> >> > > --94eb2c11c9e685d029053a5d4bd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley <housley@vigilsec.co= m> wrote:
Quan:

I just read = the cited paper from Niels Ferguson <http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments= /CWC-GCM/Ferguson2.pdf>.=C2=A0 Niels says:

= =C2=A0 =C2=A0After 2^16 forgery attempts we can expect a successful forgery= .

And, then Niels talks about an encrypted voice e= nvironment where this attack might lead to disastrous consequences.

Also, Niels points out that the AES-GCM security proof is= unbroken by this attack.=C2=A0 He is staying within the bounds of the prov= en security.

Yeah, but the prov= en security wasn't clear about the weakness/fragility of GCM. The attac= k explicitly showed how to exploit the weakness.

<= /div>
It is hard to imagine a protocol environment that uses CMS w= here 2^16 extra messages would be undetected.

In addition RFC 5084 requires automated key management.=C2=A0 This means = that a fresh AES-GCM key ought to be used for each of the messages.
<= /div>

Oh, this is interesting. The problem = I saw with=C2=A0OpenJDK, BouncyCastle, Con= scrypt=C2=A0is when Java Cipher (https://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html) is initialized to use GCM mode:

=C2=A0 =C2=A01. In one case, if the parameter is ASN.1 encode= d and=C2=A0aes-= ICVlen is missing=C2=A0then it'= s interpreted as 12-byte.
=C2=A0 =C2=A02. In other case, they use 12-byte tag, citing RFC 5084 recom= mendation. For instance, see :=C2=A0https://github.c= om/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/pro= vider/symmetric/AES.java#L497

Note that C= ipher is a general crypto primitive which may be used to encrypt = multiple messages. So there may be misunderstanding every now and then.= It's worth to note that I had a hard time convincing developers to cha= nge because they cited RFC :(

=C2=A0I recognize that attackers do n= ot follow the specification, but it means that they cannot just use an exis= ting implementation.

These two observations make m= e wonder whether the is enough of a problem to bother with an update to RFC= 5084.=C2=A0 What do you think?

Russ

On Mon, Aug 15, 2016 at 1:55 PM= , Russ Housley <housley@vigilsec.com> wrote:
Quan:

I do not think that we can change the DEFAULT va= lue associated with these OIDs.=C2=A0 Changing the meaning of an absent aes= -ICVlen will result in too many interoperability problems.

Yeah, I'm aware of it and I understand you= r concern.
=C2=A0
=C2=A0However, we could put out= a very short RFC that updates RFC 5084 to recommend the use of 16 octet au= thentication tags in all situations. =C2=A0

Thanks for doing this :) It's SGTM.

Russ


On Aug 11, 2016, at 2:49 PM, Quan Nguyen <quannguyen@google.com> wrote:



On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has been submitte= d for RFC5084,
"Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptograph= ic Message Syntax (CMS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D5084&eid=3D4774

--------------------------------------
Type: Technical
Reported by: QUAN NGUYEN <quannguyen@google.com>

Section: 3.2

Original Text
-------------
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is RECOMMENDED.

Corrected Text
--------------
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 16

A length of 16 octets is RECOMMENDED.

Notes
-----
Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug to= use 12 bytes authentication tag (aes-ICVlen) as default if the code path [= 1] uses CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolk= it/BCM/documents/comments/CWC-GCM/Ferguson2.pdf), if a user encryp= ts 2^32 block length message, then 12 bytes authentication tag length has o= nly 96 - 32 =3D 64 bits security which is not good enough nowadays. Further= more, once a forgery happens then authentication is leaked.

Sorry, I meant "authentication key" i= s leaked.=C2=A0

[1] In other code paths, all providers use 16 bytes authentication tag as d= efault.

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

--------------------------------------
RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Using AES-CCM= and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (= CMS)
Publication Date=C2=A0 =C2=A0 : November 2007
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Housley
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Securi= ty
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG






--94eb2c11c9e685d029053a5d4bd3-- From nobody Thu Aug 18 13:14:04 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B800612B03D for ; Thu, 18 Aug 2016 13:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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 1dyy8jvTbGkA for ; Thu, 18 Aug 2016 13:13:59 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6AC12D18D for ; Thu, 18 Aug 2016 13:13:58 -0700 (PDT) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 18 Aug 2016 13:25:41 -0700 From: Jim Schaad To: 'Quan Nguyen' , 'Russ Housley' References: <20160811184733.4444EB8111E@rfc-editor.org> <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> In-Reply-To: Date: Thu, 18 Aug 2016 13:13:20 -0700 Message-ID: <08c401d1f98c$f956ad80$ec040880$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C5_01D1F952.4CFFEBD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHRaEVFPn+0uXujd3jpR3UjAM369wKCkygFAa877t8CSLGCBwC9GFvaAhV+LwSgBd9O0A== Content-Language: en-us X-Originating-IP: [173.8.216.38] Archived-At: Cc: 'Stephen Farrell' , 'Kathleen Moriarty' , 'David McGrew' , 'IETF SMIME' Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 20:14:04 -0000 ------=_NextPart_000_08C5_01D1F952.4CFFEBD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I did a brief look at the code you pointed to and I would run screaming = from it for several reasons. =20 I do not have a problem if the tag is defaulted to a length of 12 bytes, = but I do not see any way to set it to a different length if desired. = There should be a version that allows for getting the tag length. At a = minimum the length of the tag should be parameterized. =20 This is making me want to fix the code, but not necessarily wanting to = fix the spec. In the context of the document the default is not = unreasonable. =20 Jim =20 =20 From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Quan Nguyen Sent: Thursday, August 18, 2016 12:07 PM To: Russ Housley Cc: Kathleen Moriarty ; IETF SMIME = ; David McGrew ; Stephen Farrell = Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) =20 =20 =20 On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley > wrote: Quan: =20 I just read the cited paper from Niels Ferguson = . Niels says: =20 After 2^16 forgery attempts we can expect a successful forgery. =20 And, then Niels talks about an encrypted voice environment where this = attack might lead to disastrous consequences. =20 Also, Niels points out that the AES-GCM security proof is unbroken by = this attack. He is staying within the bounds of the proven security. =20 Yeah, but the proven security wasn't clear about the weakness/fragility = of GCM. The attack explicitly showed how to exploit the weakness. =20 It is hard to imagine a protocol environment that uses CMS where 2^16 = extra messages would be undetected. =20 In addition RFC 5084 requires automated key management. This means that = a fresh AES-GCM key ought to be used for each of the messages.=20 =20 Oh, this is interesting. The problem I saw with OpenJDK, BouncyCastle, = Conscrypt is when Java Cipher = (https://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html) is = initialized to use GCM mode: =20 1. In one case, if the parameter is ASN.1 encoded and aes-ICVlen is = missing then it's interpreted as 12-byte. 2. In other case, they use 12-byte tag, citing RFC 5084 = recommendation. For instance, see : = https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bounc= ycastle/jcajce/provider/symmetric/AES.java#L497 =20 Note that Cipher is a general crypto primitive which may be used to = encrypt multiple messages. So there may be misunderstanding every now = and then. It's worth to note that I had a hard time convincing = developers to change because they cited RFC :( =20 I recognize that attackers do not follow the specification, but it = means that they cannot just use an existing implementation. =20 These two observations make me wonder whether the is enough of a problem = to bother with an update to RFC 5084. What do you think? =20 Russ =20 =20 On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley > wrote: Quan: =20 I do not think that we can change the DEFAULT value associated with = these OIDs. Changing the meaning of an absent aes-ICVlen will result in = too many interoperability problems.=20 =20 Yeah, I'm aware of it and I understand your concern. =20 However, we could put out a very short RFC that updates RFC 5084 to = recommend the use of 16 octet authentication tags in all situations. =20 =20 Thanks for doing this :) It's SGTM. =20 Russ =20 =20 On Aug 11, 2016, at 2:49 PM, Quan Nguyen > wrote: =20 =20 On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System = > wrote: The following errata report has been submitted for RFC5084, "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic = Message Syntax (CMS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5084 = = &eid=3D4774 -------------------------------------- Type: Technical Reported by: QUAN NGUYEN > Section: 3.2 Original Text ------------- aes-ICVlen AES-GCM-ICVlen DEFAULT 12 A length of 12 octets is RECOMMENDED. Corrected Text -------------- aes-ICVlen AES-GCM-ICVlen DEFAULT 16 A length of 16 octets is RECOMMENDED. Notes ----- Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug = to use 12 bytes authentication tag (aes-ICVlen) as default if the code = path [1] uses CMS. According to Ferguson's attack = (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Fe= rguson2.pdf), if a user encrypts 2^32 block length message, then 12 = bytes authentication tag length has only 96 - 32 =3D 64 bits security = which is not good enough nowadays. Furthermore, once a forgery happens = then authentication is leaked. =20 Sorry, I meant "authentication key" is leaked.=20 [1] In other code paths, all providers use 16 bytes authentication tag = as default. 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 (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) -------------------------------------- Title : Using AES-CCM and AES-GCM Authenticated Encryption = in the Cryptographic Message Syntax (CMS) Publication Date : November 2007 Author(s) : R. Housley Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG =20 =20 =20 =20 =20 ------=_NextPart_000_08C5_01D1F952.4CFFEBD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I did a = brief look at the code you pointed to and I would run screaming from it = for several reasons.

 

I do not = have a problem if the tag is defaulted to a length of 12 bytes, but I do = not see any way to set it to a different length if desired.=C2=A0 There = should be a version that allows for getting the tag length.=C2=A0 At a = minimum the length of the tag should be = parameterized.

 

This is = making me want to fix the code, but not necessarily wanting to fix the = spec.=C2=A0 In the context of the document the default is not = unreasonable.

 

Jim

 

 

From:<= /b> = smime [mailto:smime-bounces@ietf.org] On Behalf Of Quan = Nguyen
Sent: Thursday, August 18, 2016 12:07 PM
To: = Russ Housley <housley@vigilsec.com>
Cc: Kathleen = Moriarty <Kathleen.Moriarty.ietf@gmail.com>; IETF SMIME = <smime@ietf.org>; David McGrew <mcgrew@cisco.com>; Stephen = Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [smime] = [Technical Errata Reported] RFC5084 = (4774)

 

 

 

On Thu, = Aug 18, 2016 at 11:39 AM, Russ Housley <housley@vigilsec.com> = wrote:

Quan:

 

I = just read the cited paper from Niels Ferguson <http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/co= mments/CWC-GCM/Ferguson2.pdf>.  Niels = says:

 

   After 2^16 forgery attempts we can expect = a successful forgery.

 

And, then Niels talks about an encrypted voice = environment where this attack might lead to disastrous = consequences.

 

Also, Niels points out that the AES-GCM security proof = is unbroken by this attack.  He is staying within the bounds of the = proven security.

 

Yeah, but the proven security wasn't clear about the = weakness/fragility of GCM. The attack explicitly showed how to exploit = the weakness.

 

It is hard to imagine a protocol environment that uses = CMS where 2^16 extra messages would be = undetected.

 

In addition RFC 5084 requires automated key = management.  This means that a fresh AES-GCM key ought to be used = for each of the messages. =

 

Oh, this is interesting. The problem I saw = with OpenJDK, BouncyCastle, = Conscrypt is when Java Cipher (https://docs.oracle.com/javase/7/docs/api/javax/crypto/= Cipher.html) is initialized to use GCM = mode:

 

   1. In one = case, if the parameter is ASN.1 encoded and aes-ICVlen is = missing then it's = interpreted as 12-byte.

   2. In = other case, they use 12-byte tag, citing RFC 5084 recommendation. For = instance, see : https://github.c= om/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/p= rovider/symmetric/AES.java#L497

 

Note that Cipher is a = general crypto primitive which may be used to encrypt = multiple messages. So there may be misunderstanding every now and = then. It's worth to note that I had a hard time convincing developers to = change because they cited RFC :(

 

 I recognize that attackers do not follow the = specification, but it means that they cannot just use an existing = implementation.

 

These two observations make me wonder whether the is = enough of a problem to bother with an update to RFC 5084.  What do = you think?

 

Russ

 

 

On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley <housley@vigilsec.com> = wrote:

Quan:

 

I = do not think that we can change the DEFAULT value associated with these = OIDs.  Changing the meaning of an absent aes-ICVlen will result in = too many interoperability problems. =

 

Yeah, I'm aware of it and I understand your = concern.

 

 However, we could put out a very short RFC that = updates RFC 5084 to recommend the use of 16 octet authentication tags in = all situations.  

 

Thanks for doing this :) It's = SGTM.

 

Russ

 

 

On = Aug 11, 2016, at 2:49 PM, Quan Nguyen <quannguyen@google.com> = wrote:



 

 

On Thu, = Aug 11, 2016 at 11:47 AM, RFC Errata System <rfc-editor@rfc-editor.org> = wrote:

The = following errata report has been submitted for RFC5084,
"Using = AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic = Message Syntax = (CMS)".

--------------------------------------
You may = review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5084&= amp;eid=3D4774

--------------------------------------
Type:= Technical
Reported by: QUAN NGUYEN <quannguyen@google.com>

Section: = 3.2

Original Text
-------------
aes-ICVlen    =    AES-GCM-ICVlen DEFAULT 12

A length of 12 octets is = RECOMMENDED.

Corrected Text
--------------
aes-ICVlen  =      AES-GCM-ICVlen DEFAULT 16

A length of 16 = octets is RECOMMENDED.

Notes
-----
Many JCE providers = including OpenJDK, BouncyCastle, Conscrypt have a bug to use 12 bytes = authentication tag (aes-ICVlen) as default if the code path [1] uses = CMS. According to Ferguson's attack (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/co= mments/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length = message, then 12 bytes authentication tag length has only 96 - 32 =3D 64 = bits security which is not good enough nowadays. Furthermore, once a = forgery happens then authentication is = leaked.

 

Sorry, I meant "authentication key" = is leaked. 


[1] In other code paths, all = providers use 16 bytes authentication tag as = default.

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 = (IESG)
can log in to change the status and edit the report, if = necessary.

--------------------------------------
RFC5084 = (draft-ietf-smime-cms-aes-ccm-and-gcm-03)
----------------------------= ----------
Title              =  : Using AES-CCM and AES-GCM Authenticated Encryption in the = Cryptographic Message Syntax (CMS)
Publication Date    : = November 2007
Author(s)           : R. = Housley
Category            : PROPOSED = STANDARD
Source              : = S/MIME Mail Security
Area            =     : Security
Stream          =     : IETF
Verifying Party     : = IESG

 

 

 

 

 

------=_NextPart_000_08C5_01D1F952.4CFFEBD0-- From nobody Thu Aug 18 14:16:00 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D3512D091 for ; Thu, 18 Aug 2016 13:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 r1dGfnvToIR3 for ; Thu, 18 Aug 2016 13:33:52 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 2ED8D12DB4B for ; Thu, 18 Aug 2016 13:33:48 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 97so47543299uav.3 for ; Thu, 18 Aug 2016 13:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a1ZWZfLoLw78VTqUjkK6W8dAxY9oQXv9KZG6psbxdPs=; b=TIKAiSnGwyizjKdDcZvNl2c/V/tzDP51D8fnFrIUUd+/y7EG4FJPq5nsJH8jZUgFzF RnGWBhcVRqli3rzy6DfEFk0HkNSHsm9/mxhg2Ymdp6ecMUZveB79BTsSwCQ8Rk5J85OY ImGv9ivLLORscIYaeZ/NF97vc0MuTl8TaAIeLtUWfEHxofYrL8Lc5Os/j1m8KwCrkr6K x1I14kYCpxAYCY3O3TJBcWOhLxUT0RAjyivnqzR6U9kjpVJomQxhS5UfqF3CoyihhbQu 5UieMI/YCExBFbruijpe2MZbYZWV1Oe975j25wOq7uatu/4KFRES8nyzUX4+A/ttpAcJ w7ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a1ZWZfLoLw78VTqUjkK6W8dAxY9oQXv9KZG6psbxdPs=; b=kTpuX5Iw2GsjySxEZKEfE7xXgp2cI5vQUl3uognDdUnPubC4LU237JoO61g5RxLYCR /qWqokoHSoSqwDi30Gg4x9QzUxuiKm8F7dheSNfjSTuubwawHiErugm378iAtGDaa4kM M/CMWt/RcRzOlFeLazCCzngCDrXXPhTXkK7JHJ41zFFsM5pdPH3w2VCTf24jacUpE2rh IB47Sq9X1g6CPkY6hHav36yVLuZrOoYlX9TRJr9dfyPBF7fcDl5IwjxqQcBPKDnl9y/L cyFecacHVseO1ismzO+2mai0TPn9bM0PiSll6slSst/IzxigYKttr2hKSFAyJteMR5bK xGAg== X-Gm-Message-State: AEkoousxkqCv/lU6HzrEQLzdyw7RIHoSG5ShdIrvYrmneA1N8RLoSMthXZjwbdzXm9UOW7a1PB8l2V9yoiqkPiUY X-Received: by 10.176.82.33 with SMTP id i30mr1938071uaa.60.1471552427180; Thu, 18 Aug 2016 13:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.139.131 with HTTP; Thu, 18 Aug 2016 13:33:26 -0700 (PDT) In-Reply-To: <08c401d1f98c$f956ad80$ec040880$@augustcellars.com> References: <20160811184733.4444EB8111E@rfc-editor.org> <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> <08c401d1f98c$f956ad80$ec040880$@augustcellars.com> From: Quan Nguyen Date: Thu, 18 Aug 2016 13:33:26 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=94eb2c18fbaab11330053a5e7f0c Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 14:15:59 -0700 Cc: Stephen Farrell , Kathleen Moriarty , David McGrew , IETF SMIME Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 20:33:56 -0000 --94eb2c18fbaab11330053a5e7f0c Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad wrote: > I did a brief look at the code you pointed to and I would run screaming > from it for several reasons. > > > > I do not have a problem if the tag is defaulted to a length of 12 bytes, > Note that I were talking about Java Cipher which is used in different scenarios where some requires high-level of security. It's the library responsibility to choose a default safe option. Note that in general, all BouncyCastle, Conscrypt, OpenJDK use 16-bytes as default. The only place where they use/used 12-byte is where they cite/cited the RFC. > but I do not see any way to set it to a different length if desired. > There should be a version that allows for getting the tag length. At a > minimum the length of the tag should be parameterized. > There are different ways to initialize Java Cipher and some of them allow user to choose the authentication tag size. > > > This is making me want to fix the code, but not necessarily wanting to fix > the spec. In the context of the document the default is not unreasonable. > If it was designed specifically for your use-case and it uses key only once for decryption then I agree it's fine. I believe the core problem is people only looked at section 3.2 and then applied it for *general* usecase. Honestly, I don't know what to do in this situation. > > > Jim > > > > > > *From:* smime [mailto:smime-bounces@ietf.org] *On Behalf Of *Quan Nguyen > *Sent:* Thursday, August 18, 2016 12:07 PM > *To:* Russ Housley > *Cc:* Kathleen Moriarty ; IETF SMIME < > smime@ietf.org>; David McGrew ; Stephen Farrell < > stephen.farrell@cs.tcd.ie> > *Subject:* Re: [smime] [Technical Errata Reported] RFC5084 (4774) > > > > > > > > On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley > wrote: > > Quan: > > > > I just read the cited paper from Niels Ferguson < > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen > ts/CWC-GCM/Ferguson2.pdf>. Niels says: > > > > After 2^16 forgery attempts we can expect a successful forgery. > > > > And, then Niels talks about an encrypted voice environment where this > attack might lead to disastrous consequences. > > > > Also, Niels points out that the AES-GCM security proof is unbroken by this > attack. He is staying within the bounds of the proven security. > > > > Yeah, but the proven security wasn't clear about the weakness/fragility of > GCM. The attack explicitly showed how to exploit the weakness. > > > > It is hard to imagine a protocol environment that uses CMS where 2^16 > extra messages would be undetected. > > > > In addition RFC 5084 requires automated key management. This means that a > fresh AES-GCM key ought to be used for each of the messages. > > > > Oh, this is interesting. The problem I saw with OpenJDK, BouncyCastle, > Conscrypt is when Java Cipher (https://docs.oracle.com/javas > e/7/docs/api/javax/crypto/Cipher.html) is initialized to use GCM mode: > > > > 1. In one case, if the parameter is ASN.1 encoded and aes-ICVlen is > missing then it's interpreted as 12-byte. > > 2. In other case, they use 12-byte tag, citing RFC 5084 recommendation. > For instance, see : https://github.com/bcgit/bc- > java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/ > provider/symmetric/AES.java#L497 > > > > Note that Cipher is a *general *crypto primitive which may be used to > encrypt *multiple* messages. So there may be misunderstanding every now > and then. It's worth to note that I had a hard time convincing developers > to change because they cited RFC :( > > > > I recognize that attackers do not follow the specification, but it means > that they cannot just use an existing implementation. > > > > These two observations make me wonder whether the is enough of a problem > to bother with an update to RFC 5084. What do you think? > > > > Russ > > > > > > On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley > wrote: > > Quan: > > > > I do not think that we can change the DEFAULT value associated with these > OIDs. Changing the meaning of an absent aes-ICVlen will result in too many > interoperability problems. > > > > Yeah, I'm aware of it and I understand your concern. > > > > However, we could put out a very short RFC that updates RFC 5084 to > recommend the use of 16 octet authentication tags in all situations. > > > > Thanks for doing this :) It's SGTM. > > > > Russ > > > > > > On Aug 11, 2016, at 2:49 PM, Quan Nguyen wrote: > > > > > > > > On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > The following errata report has been submitted for RFC5084, > "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic > Message Syntax (CMS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 > > -------------------------------------- > Type: Technical > Reported by: QUAN NGUYEN > > Section: 3.2 > > Original Text > ------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 12 > > A length of 12 octets is RECOMMENDED. > > Corrected Text > -------------- > aes-ICVlen AES-GCM-ICVlen DEFAULT 16 > > A length of 16 octets is RECOMMENDED. > > Notes > ----- > Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug > to use 12 bytes authentication tag (aes-ICVlen) as default if the code path > [1] uses CMS. According to Ferguson's attack ( > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen > ts/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, > then 12 bytes authentication tag length has only 96 - 32 = 64 bits security > which is not good enough nowadays. Furthermore, once a forgery happens then > authentication is leaked. > > > > Sorry, I meant "authentication *key*" is leaked. > > > [1] In other code paths, all providers use 16 bytes authentication tag as > default. > > 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 (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) > -------------------------------------- > Title : Using AES-CCM and AES-GCM Authenticated Encryption > in the Cryptographic Message Syntax (CMS) > Publication Date : November 2007 > Author(s) : R. Housley > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > > > > > > > > > > --94eb2c18fbaab11330053a5e7f0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad <ietf@augustcellars.c= om> wrote:

I did a brief look at= the code you pointed to and I would run screaming from it for several reas= ons.

=C2=A0

I do not have a problem if the tag is defa= ulted to a length of 12 bytes,


=
Note that I were talking about Java Cipher which is used in diff= erent scenarios where some requires high-level of security. It's the li= brary responsibility to choose a default safe option. Note that in general,= all BouncyCastle, Conscrypt, OpenJDK use 16-bytes as default. The only pla= ce where they use/used 12-byte is where they cite/cited the RFC.

but I do not see any way to set it to a different len= gth if desired.=C2=A0 There should be a version that allows for getting the= tag length.=C2=A0 At a minimum the length of the tag should be parameteriz= ed.


There are differ= ent ways to initialize Java Cipher and some of them allow user to choose th= e authentication tag size.=C2=A0

=

=C2=A0

This is making me want to fix the code, but not necessar= ily wanting to fix the spec.=C2=A0 In the context of the document the defau= lt is not unreasonable.


<= div>If it was designed specifically for your use-case and it uses key only = once for=C2=A0decryption then I agree it's fine. I believe the core pro= blem is people only looked at section 3.2 and then applied it for genera= l usecase.

Honestly, I don't know what to = do in this situation.

<= /p>

=C2=A0

Jim

=C2=A0=

=C2=A0

From: smime [mailto:= smime-bounces@i= etf.org] On Behalf Of Quan Nguyen
Sent: Thursday,= August 18, 2016 12:07 PM
To: Russ Housley <housley@vigilsec.com>
= Cc: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; IET= F SMIME <smime@ietf.= org>; David McGrew <mcgrew@cisco.com>; Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774)=

=C2=A0

=C2=A0

=C2=A0<= /u>

On Thu, Aug 18, 2016 at 11:39 AM, Russ H= ousley <housle= y@vigilsec.com> wrote:

Quan:

=

=C2=A0

I just read the cited paper from Niels Ferguson <http://csrc.nist.gov/groups/ST/toolkit/BCM/= documents/comments/CWC-GCM/Ferguson2.pdf>.=C2=A0 Niels says:=

=C2=A0

=C2=A0 =C2=A0After 2^16 forgery attempts we= can expect a successful forgery.

=C2=A0

And, th= en Niels talks about an encrypted voice environment where this attack might= lead to disastrous consequences.

=C2=A0

Also, N= iels points out that the AES-GCM security proof is unbroken by this attack.= =C2=A0 He is staying within the bounds of the proven security.

=C2=A0<= /u>

Yeah, but the proven security wasn= 't clear about the weakness/fragility of GCM. The attack explicitly sho= wed how to exploit the weakness.

= =C2=A0

It is hard to imagi= ne a protocol environment that uses CMS where 2^16 extra messages would be = undetected.

=C2=A0

In addition RFC 5084 re= quires automated key management.=C2=A0 This means that a fresh AES-GCM key = ought to be used for each of the messages.

=C2=A0

<= p class=3D"MsoNormal">Oh, this is interesting. The problem I saw with=C2=A0= OpenJDK, BouncyCastle, Conscrypt=C2=A0is wh= en Java Cipher (https://docs.oracle.com/javase/7= /docs/api/javax/crypto/Cipher.html) is initialized to use GCM mode= :

=C2=A0

= =C2=A0 =C2=A01. In one case, if the parameter is ASN.1 encoded and=C2=A0aes-ICVlen is missing=C2= =A0then it's interpreted as 12-b= yte.

=C2=A0 =C2=A02. In other case, they use 12-byte tag, c= iting RFC 5084 recommendation. For instance, see :=C2=A0https://github.com= /bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jc= ajce/provider/symmetric/AES.java#L497

=C2=A0

Note that Cipher is a = general crypto primitive which may be used to encrypt multiple m= essages. So there may be misunderstanding every now and then. It's wort= h to note that I had a hard time convincing developers to change because th= ey cited RFC :(

<= u>=C2=A0

=C2=A0I recognize that attackers do = not follow the specification, but it means that they cannot just use an exi= sting implementation.

=C2=A0

These two observati= ons make me wonder whether the is enough of a problem to bother with an upd= ate to RFC 5084.=C2=A0 What do you think?

=C2=A0=

Russ=

= =C2=A0

=C2=A0

=
<= div>

On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley &l= t;housley@vigilse= c.com> wrote:

Quan:

=C2=A0

I do not think that we can change the DEFAULT value associated with these= OIDs.=C2=A0 Changing the meaning of an absent aes-ICVlen will result in to= o many interoperability problems.

=C2=A0

Yeah, I'm aware of it and I understand your concern.<= /u>

=C2=A0

=C2=A0However, we could put out a very short RFC that updates RFC 5= 084 to recommend the use of 16 octet authentication tags in all situations.= =C2=A0

= =C2=A0

Thanks for doing thi= s :) It's SGTM.

=C2=A0

Russ

=C2=A0

=C2=A0

On Aug 11= , 2016, at 2:49 PM, Quan Nguyen <quannguyen@google.com> wrote:

<= /div>



= =C2=A0

=C2=A0

<= p class=3D"MsoNormal">On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System &= lt;rfc-edito= r@rfc-editor.org> wrote:

The following errata repor= t has been submitted for RFC5084,
"Using AES-CCM and AES-GCM Authen= ticated Encryption in the Cryptographic Message Syntax (CMS)".

= --------------------------------------
You may review the report be= low and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D5084&eid=3D4774

-----------------= ---------------------
Type: Technical
Reported by: QUAN NGUYEN &= lt;quannguyen@go= ogle.com>

Section: 3.2

Original Text
-------------<= br>aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 12

A = length of 12 octets is RECOMMENDED.

Corrected Text
--------------=
aes-ICVlen=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 16

A= length of 16 octets is RECOMMENDED.

Notes
-----
Many JCE prov= iders including OpenJDK, BouncyCastle, Conscrypt have a bug to use 12 bytes= authentication tag (aes-ICVlen) as default if the code path [1] uses CMS. = According to Ferguson's attack (= http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC= -GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, then= 12 bytes authentication tag length has only 96 - 32 =3D 64 bits security w= hich is not good enough nowadays. Furthermore, once a forgery happens then = authentication is leaked.

=C2=A0

Sorry, I= meant "authentication key" is leaked.=C2=A0=


[1] In other code paths, all p= roviders use 16 bytes authentication tag as default.

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

--------------------------------------
RFC5084 (dra= ft-ietf-smime-cms-aes-ccm-and-gcm-03)
-----------------------------= ---------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographi= c Message Syntax (CMS)
Publication Date=C2=A0 =C2=A0 : November 2007
= Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Housley
Category= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Security
Are= a=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stre= am=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Part= y=C2=A0 =C2=A0 =C2=A0: IESG

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=

=C2=A0


--94eb2c18fbaab11330053a5e7f0c-- From nobody Thu Aug 18 16:51:34 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F8A12B04A for ; Thu, 18 Aug 2016 16:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 k6WsWaZS4vvI for ; Thu, 18 Aug 2016 16:51:29 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 59BCF12D5BF for ; Thu, 18 Aug 2016 16:51:29 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 97so54302934uav.3 for ; Thu, 18 Aug 2016 16:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u73kC2J00yRFxdw303RGum0fkggi06gLgcTaCufIgr0=; b=Q7HjyQ1ha4A8WGl0CzMGXo7Y0kcnUMKyZKR/wvPQKg+ASUO0OrVNa5aa72dAZB/3wS 0m/nElfQXnf2Juh8J1xc0hs7EhxvmZFGXvH8GrF/QOyuzp7QyeQCHDdpveO+hXxgqK+S t9s8g9KCGkFVUpLHt7yBJLwloaG4nGBQUWmRP54OeMXET8fFF6/HVhTWaZYwg/JsV6T7 aLDvJFguoTbHU0lO+MoFyxEOyo7wBUV1RLGmiVuUPZJEaBWgjpezQUfwu3ycKTbz3cDP k/4rFFIgtO+N6Q6jV8RZWKzfKU1Qd5Ue62jjEuapqg2hmEiTji8qUW+BYw2XYsvODZ+/ moEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u73kC2J00yRFxdw303RGum0fkggi06gLgcTaCufIgr0=; b=dozh1L1nk7PCM6Rc+MvF5xe5ZNBMNrX7GK0OwAsLgKRMN7XY++oNreBC4wSkm2UjB8 w6WdpNk8PzjOopME0KKvSIcacAsZ8BY1hDjSIz/dOcgP0sr8HBbbyphWr1a1UY0VqH1x scxnqM374j1nzFMCDOYkqjr/7gj3RBPd058pGKtUWmEIjnRv94JVdyEFrFaC8qsSlxX9 e82V1KOp1wm155W6qpXvhrZ/cGQCkOVVcO8BBIuFje6lvpgzMaaHNgJg46qxp/sP4gnt ZyiGUN2f4joW1VBYMUMa6PfhpGdB0Z1kLn+CIEIwGu56001wlEcQYfJA2Qdtla6WGRaB 1RTw== X-Gm-Message-State: AEkoouvYvYR1sv6EaC4TXsZm8QvQuAM1DRfG4n5L0tZxWYXlY94xCaV9ohy7ExBGPWPyE0nAIqvDynZ//dB53Tei X-Received: by 10.31.78.3 with SMTP id c3mr482369vkb.41.1471564288000; Thu, 18 Aug 2016 16:51:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.139.131 with HTTP; Thu, 18 Aug 2016 16:51:07 -0700 (PDT) In-Reply-To: References: <20160811184733.4444EB8111E@rfc-editor.org> <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> <08c401d1f98c$f956ad80$ec040880$@augustcellars.com> From: Quan Nguyen Date: Thu, 18 Aug 2016 16:51:07 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11484beea6f3b6053a614248 Archived-At: Cc: Stephen Farrell , Kathleen Moriarty , David McGrew , IETF SMIME Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 23:51:33 -0000 --001a11484beea6f3b6053a614248 Content-Type: text/plain; charset=UTF-8 FYI, BouncyCastle just fixed the default to 16 bytes a few hours ago: https://github.com/bcgit/bc-java/commit/fa25b67c91b1b8d1e9c25f05e198da99db6f1f1a On Thu, Aug 18, 2016 at 1:33 PM, Quan Nguyen wrote: > > > On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad > wrote: > >> I did a brief look at the code you pointed to and I would run screaming >> from it for several reasons. >> >> >> >> I do not have a problem if the tag is defaulted to a length of 12 bytes, >> > > Note that I were talking about Java Cipher which is used in different > scenarios where some requires high-level of security. It's the library > responsibility to choose a default safe option. Note that in general, all > BouncyCastle, Conscrypt, OpenJDK use 16-bytes as default. The only place > where they use/used 12-byte is where they cite/cited the RFC. > >> but I do not see any way to set it to a different length if desired. >> There should be a version that allows for getting the tag length. At a >> minimum the length of the tag should be parameterized. >> > > There are different ways to initialize Java Cipher and some of them allow > user to choose the authentication tag size. > >> >> >> This is making me want to fix the code, but not necessarily wanting to >> fix the spec. In the context of the document the default is not >> unreasonable. >> > > If it was designed specifically for your use-case and it uses key only > once for decryption then I agree it's fine. I believe the core problem is > people only looked at section 3.2 and then applied it for *general* > usecase. > > Honestly, I don't know what to do in this situation. > >> >> >> Jim >> >> >> >> >> >> *From:* smime [mailto:smime-bounces@ietf.org] *On Behalf Of *Quan Nguyen >> *Sent:* Thursday, August 18, 2016 12:07 PM >> *To:* Russ Housley >> *Cc:* Kathleen Moriarty ; IETF SMIME < >> smime@ietf.org>; David McGrew ; Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >> *Subject:* Re: [smime] [Technical Errata Reported] RFC5084 (4774) >> >> >> >> >> >> >> >> On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley >> wrote: >> >> Quan: >> >> >> >> I just read the cited paper from Niels Ferguson < >> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen >> ts/CWC-GCM/Ferguson2.pdf>. Niels says: >> >> >> >> After 2^16 forgery attempts we can expect a successful forgery. >> >> >> >> And, then Niels talks about an encrypted voice environment where this >> attack might lead to disastrous consequences. >> >> >> >> Also, Niels points out that the AES-GCM security proof is unbroken by >> this attack. He is staying within the bounds of the proven security. >> >> >> >> Yeah, but the proven security wasn't clear about the weakness/fragility >> of GCM. The attack explicitly showed how to exploit the weakness. >> >> >> >> It is hard to imagine a protocol environment that uses CMS where 2^16 >> extra messages would be undetected. >> >> >> >> In addition RFC 5084 requires automated key management. This means that >> a fresh AES-GCM key ought to be used for each of the messages. >> >> >> >> Oh, this is interesting. The problem I saw with OpenJDK, BouncyCastle, >> Conscrypt is when Java Cipher (https://docs.oracle.com/javas >> e/7/docs/api/javax/crypto/Cipher.html) is initialized to use GCM mode: >> >> >> >> 1. In one case, if the parameter is ASN.1 encoded and aes-ICVlen is >> missing then it's interpreted as 12-byte. >> >> 2. In other case, they use 12-byte tag, citing RFC 5084 >> recommendation. For instance, see : https://github.com/bcgit/bc- >> java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/ >> provider/symmetric/AES.java#L497 >> >> >> >> Note that Cipher is a *general *crypto primitive which may be used to >> encrypt *multiple* messages. So there may be misunderstanding every now >> and then. It's worth to note that I had a hard time convincing developers >> to change because they cited RFC :( >> >> >> >> I recognize that attackers do not follow the specification, but it means >> that they cannot just use an existing implementation. >> >> >> >> These two observations make me wonder whether the is enough of a problem >> to bother with an update to RFC 5084. What do you think? >> >> >> >> Russ >> >> >> >> >> >> On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley >> wrote: >> >> Quan: >> >> >> >> I do not think that we can change the DEFAULT value associated with these >> OIDs. Changing the meaning of an absent aes-ICVlen will result in too many >> interoperability problems. >> >> >> >> Yeah, I'm aware of it and I understand your concern. >> >> >> >> However, we could put out a very short RFC that updates RFC 5084 to >> recommend the use of 16 octet authentication tags in all situations. >> >> >> >> Thanks for doing this :) It's SGTM. >> >> >> >> Russ >> >> >> >> >> >> On Aug 11, 2016, at 2:49 PM, Quan Nguyen wrote: >> >> >> >> >> >> >> >> On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System < >> rfc-editor@rfc-editor.org> wrote: >> >> The following errata report has been submitted for RFC5084, >> "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic >> Message Syntax (CMS)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774 >> >> -------------------------------------- >> Type: Technical >> Reported by: QUAN NGUYEN >> >> Section: 3.2 >> >> Original Text >> ------------- >> aes-ICVlen AES-GCM-ICVlen DEFAULT 12 >> >> A length of 12 octets is RECOMMENDED. >> >> Corrected Text >> -------------- >> aes-ICVlen AES-GCM-ICVlen DEFAULT 16 >> >> A length of 16 octets is RECOMMENDED. >> >> Notes >> ----- >> Many JCE providers including OpenJDK, BouncyCastle, Conscrypt have a bug >> to use 12 bytes authentication tag (aes-ICVlen) as default if the code path >> [1] uses CMS. According to Ferguson's attack ( >> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen >> ts/CWC-GCM/Ferguson2.pdf), if a user encrypts 2^32 block length message, >> then 12 bytes authentication tag length has only 96 - 32 = 64 bits security >> which is not good enough nowadays. Furthermore, once a forgery happens then >> authentication is leaked. >> >> >> >> Sorry, I meant "authentication *key*" is leaked. >> >> >> [1] In other code paths, all providers use 16 bytes authentication tag as >> default. >> >> 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 (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5084 (draft-ietf-smime-cms-aes-ccm-and-gcm-03) >> -------------------------------------- >> Title : Using AES-CCM and AES-GCM Authenticated Encryption >> in the Cryptographic Message Syntax (CMS) >> Publication Date : November 2007 >> Author(s) : R. Housley >> Category : PROPOSED STANDARD >> Source : S/MIME Mail Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> >> >> >> >> >> >> >> >> >> > > --001a11484beea6f3b6053a614248 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI, BouncyCastle just fixed the default to 16 bytes a few= hours ago:=C2=A0https://github.com/bcgit/bc-java/commit/= fa25b67c91b1b8d1e9c25f05e198da99db6f1f1a

On Thu, Aug 18, 2016 at 1:33 PM, Quan Nguy= en <quannguyen@google.com> wrote:


On Thu, Aug 18, 2016 at 1:13 PM, Jim Sch= aad <ietf@augustcellars.com> wrote:

I did a brief look at the code you pointed = to and I would run screaming from it for several reasons.

=C2=A0

I do not have a problem if the tag is defaulted to a length of 1= 2 bytes,


Note= that I were talking about Java Cipher which is used in different scenarios= where some requires high-level of security. It's the library responsib= ility to choose a default safe option. Note that in general, all BouncyCast= le, Conscrypt, OpenJDK use 16-bytes as default. The only place where they u= se/used 12-byte is where they cite/cited the RFC.

but I do not see any way to se= t it to a different length if desired.=C2=A0 There should be a version that= allows for getting the tag length.=C2=A0 At a minimum the length of the ta= g should be parameterized.


There are different ways to initialize Java Cipher and some o= f them allow user to choose the authentication tag size.=C2=A0

=C2=A0

This is making me want to fix the code, but not necessarily want= ing to fix the spec.=C2=A0 In the context of the document the default is no= t unreasonable.


If it was designed specifically for your use-case and it uses key only o= nce for=C2=A0decryption then I agree it's fine. I believe the core prob= lem is people only looked at section 3.2 and then applied it for general= usecase.

Honestly, I don't know what to d= o in this situation.

=C2=A0

Jim<= /p>

=C2=A0

=C2=A0

From: smime [mailto:smime-bounces@ietf.org] On Behalf O= f Quan Nguyen
Sent: Thursday, August 18, 2016 12:07 PM
= To: Russ Housley <housley@vigilsec.com>
Cc: Kathleen Moriarty <Kathlee= n.Moriarty.ietf@gmail.com>; IETF SMIME <smime@ietf.org>; David McGrew <mcgrew@cisco.com>= ;; Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [smime= ] [Technical Errata Reported] RFC5084 (4774)

=

=C2=A0

<= /u>=C2=A0

=C2=A0

On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley <= ;housley@vigilsec= .com> wrote:

Quan:

=C2=A0

I just read the cited paper from Niels Ferguson <http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/= comments/CWC-GCM/Ferguson2.pdf>.=C2=A0 Niels says:

=C2=A0

<= p class=3D"MsoNormal">=C2=A0 =C2=A0After 2^16 forgery attempts we can expec= t a successful forgery.

= =C2=A0

And, then Niels t= alks about an encrypted voice environment where this attack might lead to d= isastrous consequences.

= =C2=A0

Also, Niels point= s out that the AES-GCM security proof is unbroken by this attack.=C2=A0 He = is staying within the bounds of the proven security.

=C2=A0

Yeah, but the proven security wasn't cle= ar about the weakness/fragility of GCM. The attack explicitly showed how to= exploit the weakness.

=C2=A0

It is hard to imagine a protoco= l environment that uses CMS where 2^16 extra messages would be undetected.<= u>

=C2=A0

In addition RFC 5084 requires autom= ated key management.=C2=A0 This means that a fresh AES-GCM key ought to be = used for each of the messages.

<= div>

=C2=A0

Oh, this is interesting. The problem I saw with=C2=A0OpenJDK, BouncyCastle, Conscrypt=C2=A0is when Java Cip= her (https://docs.oracle.com/javase/7/docs/api/j= avax/crypto/Cipher.html) is initialized to use GCM mode:=

=C2=A0

=C2=A0 =C2= =A01. In one case, if the parameter is ASN.1 encoded and=C2=A0aes-ICVlen is missing=C2=A0then it's interpreted as 12-byte.<= u>

=C2=A0 =C2=A02. In other case, they use 12-byte tag, citing RFC 508= 4 recommendation. For instance, see :=C2=A0https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/pro= vider/symmetric/AES.java#L497

<= p class=3D"MsoNormal">=C2=A0

Note that Cipher is a general c= rypto primitive which may be used to encrypt multiple messages. So t= here may be misunderstanding every now and then. It's worth to note tha= t I had a hard time convincing developers to change because they cited RFC = :(

=C2=A0<= u>

=C2=A0I recognize that attackers do not follow th= e specification, but it means that they cannot just use an existing impleme= ntation.

=C2=A0

These two observations make me w= onder whether the is enough of a problem to bother with an update to RFC 50= 84.=C2=A0 What do you think?

=C2=A0

Russ

=C2=A0

=C2=A0

On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley <housley@vigilsec.com> w= rote:

=

Quan:

=C2=A0

I do not thin= k that we can change the DEFAULT value associated with these OIDs.=C2=A0 Ch= anging the meaning of an absent aes-ICVlen will result in too many interope= rability problems.

=C2=A0

Ye= ah, I'm aware of it and I understand your concern.

=C2=A0

=C2=A0How= ever, we could put out a very short RFC that updates RFC 5084 to recommend = the use of 16 octet authentication tags in all situations. =C2=A0=

=C2=A0=

Thanks for doing this :) It's SGT= M.

= =C2=A0

Russ

=C2=A0

=C2=A0

On Aug 11, 2016, at 2:49= PM, Quan Nguyen <quannguyen@google.com> wrote:



=C2=A0

=C2=A0

On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <rfc-editor@rfc-editor.or= g> wrote:

The following errata report has been subm= itted for RFC5084,
"Using AES-CCM and AES-GCM Authenticated Encrypt= ion in the Cryptographic Message Syntax (CMS)".

---------------= -----------------------
You may review the report below and at:
= http://www.rfc-editor.org/errata_search.php= ?rfc=3D5084&eid=3D4774

--------------------------------------
Type: Technical
Reported by: QUAN NGUYEN <quannguyen@google.com>= ;

Section: 3.2

Original Text
-------------
aes-ICVlen= =C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 12

A length of 12 = octets is RECOMMENDED.

Corrected Text
--------------
aes-ICVle= n=C2=A0 =C2=A0 =C2=A0 =C2=A0AES-GCM-ICVlen DEFAULT 16

A length of 16= octets is RECOMMENDED.

Notes
-----
Many JCE providers includi= ng OpenJDK, BouncyCastle, Conscrypt have a bug to use 12 bytes authenticati= on tag (aes-ICVlen) as default if the code path [1] uses CMS. According to = Ferguson's attack (http://csrc.n= ist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson= 2.pdf), if a user encrypts 2^32 block length message, then 12 bytes aut= hentication tag length has only 96 - 32 =3D 64 bits security which is not g= ood enough nowadays. Furthermore, once a forgery happens then authenticatio= n is leaked.

<= /u>=C2=A0

Sorry, I meant "= authentication key" is leaked.=C2=A0


[1] In other code paths, all providers use = 16 bytes authentication tag as default.

Instructions:
-----------= --
This erratum is currently posted as "Reported". If necessar= y, please
use "Reply All" to discuss whether it should be veri= fied or
rejected. When a decision is reached, the verifying party (IESG)=
can log in to change the status and edit the report, if necessary.
<= br>--------------------------------------
RFC5084 (draft-ietf-smime= -cms-aes-ccm-and-gcm-03)
-------------------------------------= -
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Using AE= S-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syn= tax (CMS)
Publication Date=C2=A0 =C2=A0 : November 2007
Author(s)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Housley
Category=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : S/MIME Mail Security
Area=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2= =A0 =C2=A0: IESG

=C2=A0

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

=C2=A0



--001a11484beea6f3b6053a614248-- From nobody Mon Aug 22 12:04:38 2016 Return-Path: X-Original-To: smime@ietfa.amsl.com Delivered-To: smime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18212D798; Mon, 22 Aug 2016 12:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3mNRk_xNa5nZ; Mon, 22 Aug 2016 12:04:11 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 1D61312D5A5; Mon, 22 Aug 2016 12:04:10 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l2so89950829qkf.3; Mon, 22 Aug 2016 12:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=R46glwfuinuQEXLMMrmIX627Z2aZvla+rlJjE7vw5cg=; b=keaCnE+bLsLTjpdMBg/AcCyQ+V0QcBNJ149Y9ZYkfHmMjtapAB16idE5TDII9jRQaS q751gL+9farQVjEOVQZ0prfs+HHDMgGIzEue5e8enNuaYWj/FSn4enD5iS7RhqaaN/nv vbkgzpgtPaPylVBNWdtNgIv7mUR+WcS69KIEUZQeyi1nr30eC4vX9hz0XoxnaP9IYzrc OPJA6N+UQeMeJfMr05fYyzRnQ60jMINPEgyT4riD2w5PRR9KfAVQJo3pR4xlZq83RTaq VwtFaGJcMSlQruUC7wU6gmiJSbekod7q2pe0qjkU1m3gDJQn9D/ypqy3J0IxP3bFym8l UBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=R46glwfuinuQEXLMMrmIX627Z2aZvla+rlJjE7vw5cg=; b=aTxoNnjekXqRWwy9PzGll2tHJt/jh7STP+MblkQf1PRprKpjgDpsz83L7fA0R6f1j4 bLpbfWHxZdpf9DPYpFDFMK5nZgCt/VRXIe4DVIdgxeR+73jLuDJNF7MD27JGgh8UJERy i9mnYyLgbUFuzOQtzoZfKfluViMucW/ta4SaN1YZPyNqbPqwU785PyYofwPlZTANUuhJ d8qHo1KlRpRN0CyP28C8hOvUm1MDv7Utf1TzLDoPyRFSw79yrtV3MTY121rRzq+nUC0U 5L+Tj8z6iRQw1+efDmnnZxGLSofz/WQ/HtvIQ8Gk4fOaMXxzBHLOaOW6EdwEjXbDdmQN p3gg== X-Gm-Message-State: AEkoouvQKIC7CxVert2ulSeT/mmxwGoWbXVSWCReMY4p06hcAGt78jaCPp+vC9xvsFQVQxnlX/sM3cmHucPVxA== X-Received: by 10.55.99.195 with SMTP id x186mr25013950qkb.26.1471892649031; Mon, 22 Aug 2016 12:04:09 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.168.151 with HTTP; Mon, 22 Aug 2016 12:04:08 -0700 (PDT) From: Phillip Hallam-Baker Date: Mon, 22 Aug 2016 15:04:08 -0400 X-Google-Sender-Auth: 2E1H8l7X350QRopIPTuJz1XG-oU Message-ID: To: endymail , "cfrg@irtf.org" , IETF OpenPGP , IETF SMIME Content-Type: multipart/alternative; boundary=001a114d38227e3edd053aadb633 Archived-At: Subject: [smime] Proposal to use Proxy Re-Encryption in a messaging protocol X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:04:12 -0000 --001a114d38227e3edd053aadb633 Content-Type: text/plain; charset=UTF-8 NB: Please direct followups to endymail@ietf.org alone The draft is at: https://www.ietf.org/id/draft-hallambaker-mesh-recrypt-00.txt At the last IETF, I made a presentation on the use of Proxy Re-Encryption 'recryption' at the CFRG session=. I think that this is a very powerful technique that solves some real problems we are facing today that were probably not as apparent when it was first proposed. In particular, recryption allows end-to-end security to be preserved in situations where it would normally be lost. For example in a mailing list application or in a situation where Alice needs to read her email on multiple devices, some of which might be mobile devices that could get lost. Recryption also provides the ideal basis for Confidential Document Control which is an access control system that uses data level encryption, One slight holdup here is that there is a patent encumbrance that purports to claim the use of recyption for DRM applications but this will expire shortly, certainly before any project could get off the ground. I have written an Internet draft showing how Recryption might be implemented as a 'clean slate' protocol. Since we don't have anything like a CDC application yet (Plasma maybe), this is going to be a requirement for some situations. I am thinking we should probably try to build something and work out how to get that running before working out how best to fit these capabilities to S/MIME, OpenPGP, Jabber, etc. Contrary to my usual practice, there is no code so far, well no implementation code.I will be filling that in once I finish a few things ahead of this in the queue, specifically using the Mesh to manage SSH keys. The one technical holdup I see here is that if we are going to get people to use it, usability can't be 'OK' or 'not bad'. The only way to get a new crypto system off the ground is to design something that delivers usability that is iPhone level perfect. I think that the Mesh makes that possible of course but I will probably have to prove that with some demos. Which is why I want to get the Mesh to manage SSH keys. --001a114d38227e3edd053aadb633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
NB:= Please direct followups to endymail@i= etf.org alone


The draft is at:<= /div>

https://www.ietf.org/id/draft-hallambaker= -mesh-recrypt-00.txt


At the= last IETF, I made a presentation on the use of Proxy Re-Encryption 're= cryption' at the CFRG session=3D. I think that this is a very powerful = technique that solves some real problems we are facing today that were prob= ably not as apparent when it was first proposed.

In particular, recryption allows end-to-end securit= y to be preserved in situations where it would normally be lost. For exampl= e in a mailing list application or in a situation where Alice needs to read= her email on multiple devices, some of which might be mobile devices that = could get lost. Recryption also provides the ideal basis for Confidential D= ocument Control which is an access control system that uses data level encr= yption,

One slight holdup= here is that there is a patent encumbrance that purports to claim the use = of recyption for DRM applications but this will expire shortly, certainly b= efore any project could get off the ground.


I have written an Internet draft showing how Recryption might be= implemented as a 'clean slate' protocol. Since we don't have a= nything like a CDC application yet (Plasma maybe), this is going to be a re= quirement for some situations. I am thinking we should probably try to buil= d something and work out how to get that running before working out how bes= t to fit these capabilities to S/MIME, OpenPGP, Jabber, etc.

Contrary to my usual practice, there is= no code so far, well no implementation code.I will be filling that in once= I finish a few things ahead of this in the queue, specifically using the M= esh to manage SSH keys.

<= br>
The one tec= hnical holdup I see here is that if we are going to get people to use it, u= sability can't be 'OK' or 'not bad'. The only way to ge= t a new crypto system off the ground is to design something that delivers u= sability that is iPhone level perfect. I think that the Mesh makes that pos= sible of course but I will probably have to prove that with some demos. Whi= ch is why I want to get the Mesh to manage SSH keys.



--001a114d38227e3edd053aadb633--