Re: [smime] [Technical Errata Reported] RFC5084 (4774)
Quan Nguyen <quannguyen@google.com> Thu, 18 August 2016 23:51 UTC
Return-Path: <quannguyen@google.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 35F8A12B04A for <smime@ietfa.amsl.com>; 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 <smime@ietfa.amsl.com>; 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 <smime@ietf.org>; Thu, 18 Aug 2016 16:51:29 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id 97so54302934uav.3 for <smime@ietf.org>; 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: <CAKkgqz1HFHiWb8uLLSesSMnCCMs6b=MVJomk2A+o+dWpEwx_Og@mail.gmail.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> <08c401d1f98c$f956ad80$ec040880$@augustcellars.com> <CAKkgqz1HFHiWb8uLLSesSMnCCMs6b=MVJomk2A+o+dWpEwx_Og@mail.gmail.com>
From: Quan Nguyen <quannguyen@google.com>
Date: Thu, 18 Aug 2016 16:51:07 -0700
Message-ID: <CAKkgqz3Krs2z1iFjX7fUUbrF9r2UvS3+2de+a2nsSnMGSwn+oQ@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Content-Type: multipart/alternative; boundary="001a11484beea6f3b6053a614248"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/BH9s2DrfQsc-xgaDshogqeST5IQ>
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 23:51:33 -0000
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 <quannguyen@google.com> wrote: > > > On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad <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. >> >> >> >> 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 <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/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 <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=5084&eid=4774 >> >> -------------------------------------- >> 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/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 >> >> >> >> >> >> >> >> >> >> >> > >
- 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