Re: [smime] [Technical Errata Reported] RFC5084 (4774)

Quan Nguyen <quannguyen@google.com> Mon, 15 August 2016 21:01 UTC

MIME-Version: 1.0
In-Reply-To: <EA5FD496-53AE-4902-A18F-556F954CD161@vigilsec.com>
References: <20160811184733.4444EB8111E@rfc-editor.org> <CAKkgqz0j3KwQi5ARRmOYf7+iw5W_6zo3qgLT0aoHiARYqUwjqA@mail.gmail.com> <EA5FD496-53AE-4902-A18F-556F954CD161@vigilsec.com>
From: Quan Nguyen <quannguyen@google.com>
Date: Mon, 15 Aug 2016 14:00:39 -0700
Message-ID: <CAKkgqz1sG_UyMiCEPgTgg9=gVMEpd7tCmEqL2qY0hN1HnOmMaw@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="001a1142e6e8863615053a228743"
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/wYO3244y2AcUIH7tvbOSZm6NDmI>
Cc: IETF SMIME <smime@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, David McGrew <mcgrew@cisco.com>, RFC Editor <rfc-editor@rfc-editor.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774)
Precedence: list

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