Re: [smime] [Technical Errata Reported] RFC5084 (4774)
Quan Nguyen <quannguyen@google.com> Thu, 18 August 2016 19:07 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 1603512D5C9 for <smime@ietfa.amsl.com>; 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 <smime@ietfa.amsl.com>; 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 <smime@ietf.org>; Thu, 18 Aug 2016 12:07:37 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id 97so43849785uav.3 for <smime@ietf.org>; 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> <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>
From: Quan Nguyen <quannguyen@google.com>
Date: Thu, 18 Aug 2016 12:07:16 -0700
Message-ID: <CAKkgqz1P6Xfe4qiPoBaPDn_7UvyxyYStx+1d6Uuqq6QbVZYmaw@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="94eb2c11c9e685d029053a5d4bd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/phLXVTeaD3rfmm8PgpnzS8E_gR4>
X-Mailman-Approved-At: Thu, 18 Aug 2016 12:15:12 -0700
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)
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 19:07:41 -0000
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/ 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> > 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