Re: [smime] [Technical Errata Reported] RFC5084 (4774)
Jim Schaad <ietf@augustcellars.com> Thu, 18 August 2016 20:14 UTC
Return-Path: <ietf@augustcellars.com>
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 <smime@ietfa.amsl.com>; 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 <smime@ietfa.amsl.com>; 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 <smime@ietf.org>; 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 <ietf@augustcellars.com>
To: 'Quan Nguyen' <quannguyen@google.com>, 'Russ Housley' <housley@vigilsec.com>
References: <20160811184733.4444EB8111E@rfc-editor.org> <CAKkgqz0j3KwQi5ARRmOYf7+iw5W_6zo3qgLT0aoHiARYqUwjqA@mail.gmail.com> <EA5FD496-53AE-4902-A18F-556F954CD161@vigilsec.com> <CAKkgqz1sG_UyMiCEPgTgg9=gVMEpd7tCmEqL2qY0hN1HnOmMaw@mail.gmail.com> <9FDBF9D0-27CA-4A30-BD3B-C691618E4653@vigilsec.com> <CAKkgqz1P6Xfe4qiPoBaPDn_7UvyxyYStx+1d6Uuqq6QbVZYmaw@mail.gmail.com>
In-Reply-To: <CAKkgqz1P6Xfe4qiPoBaPDn_7UvyxyYStx+1d6Uuqq6QbVZYmaw@mail.gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/smime/1xh_rHuv2q9t0QfZ0tRLrxlYTmE>
Cc: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, 'Kathleen Moriarty' <Kathleen.Moriarty.ietf@gmail.com>, 'David McGrew' <mcgrew@cisco.com>, 'IETF SMIME' <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 <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2016 20:14:04 -0000
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. There should be a version that allows for getting the tag length. 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. In the context of the document the default is not unreasonable. Jim From: 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 <mailto:housley@vigilsec.com> > 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>. 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 <housley@vigilsec.com <mailto: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 <mailto:quannguyen@google.com> > wrote: On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <rfc-editor@rfc-editor.org <mailto: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 <http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774> &eid=4774 -------------------------------------- Type: Technical Reported by: QUAN NGUYEN <quannguyen@google.com <mailto: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/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
- Re: [smime] [Technical Errata Reported] RFC5084 (… Quan Nguyen
- Re: [smime] [Technical Errata Reported] RFC5084 (… Quan Nguyen
- Re: [smime] [Technical Errata Reported] RFC5084 (… Jim Schaad
- Re: [smime] [Technical Errata Reported] RFC5084 (… Quan Nguyen
- Re: [smime] [Technical Errata Reported] RFC5084 (… Russ Housley
- Re: [smime] [Technical Errata Reported] RFC5084 (… Quan Nguyen
- Re: [smime] [Technical Errata Reported] RFC5084 (… Quan Nguyen
- Re: [smime] [Technical Errata Reported] RFC5084 (… Quan Nguyen
- Re: [smime] [Technical Errata Reported] RFC5084 (… Russ Housley
- Re: [smime] [Technical Errata Reported] RFC5084 (… Russ Housley
- Re: [smime] [Technical Errata Reported] RFC5084 (… Sean Leonard
- Re: [smime] [Technical Errata Reported] RFC5084 (… Paul Hoffman
- Re: [smime] [Technical Errata Reported] RFC5084 (… Jim Schaad
- [smime] [Technical Errata Reported] RFC5084 (4774) RFC Errata System