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

From: RFC Errata System <[email-masked]>
Date: Thu, 11 Aug 2016 11:47:33 -0700 (PDT)

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 <[email-masked]>

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: Jim Schaad <[email-masked]>
Date: Sat, 13 Aug 2016 10:03:18 -0700

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:[email-masked]] On Behalf Of RFC Errata System
> Sent: Thursday, August 11, 2016 11:48 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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)".
> 
> 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.
> 
> 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.
> Title               : Using AES-CCM and AES-GCM Authenticated Encryption
in the
> Cryptographic Message Syntax (CMS)
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 13 Aug 2016 10:08:15 -0700

> rather than in this document.

I fully agree with Jim on both counts.

--Paul Hoffman

---

From: Sean Leonard <[email-masked]>
Date: Sat, 13 Aug 2016 15:00:32 -0700

> On Aug 13, 2016, at 10:08 AM, Paul Hoffman <[email-masked]> wrote:
> 

I also agree with Jim.

Sean

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Aug 2016 16:55:35 -0400

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 <[email-masked]> wrote:

> 
> 
> On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <[email-masked]> wrote:
> Sorry, I meant "authentication key" is leaked. 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Aug 2016 17:27:44 -0400

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

---

From: Quan Nguyen <[email-masked]>
Date: Thu, 11 Aug 2016 11:49:54 -0700

On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <
[email-masked]> wrote:

> 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.

> in the Cryptographic Message Syntax (CMS)

---

From: Quan Nguyen <[email-masked]>
Date: Mon, 15 Aug 2016 14:00:39 -0700

On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley <[email-masked]> 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.
>

>  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.
>

>> [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

---

From: Quan Nguyen <[email-masked]>
Date: Mon, 15 Aug 2016 14:44:33 -0700

> 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).

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Aug 2016 14:39:32 -0400

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.

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

---

From: Quan Nguyen <[email-masked]>
Date: Thu, 18 Aug 2016 12:07:16 -0700

On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley <[email-masked]> wrote:

> Quan:
>
> I just read the cited paper from Niels Ferguson <
> ts/CWC-GCM/Ferguson2.pdf>.  Niels says:
>
> 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.

> 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
>
>
>>> 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.
>>>
>>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 18 Aug 2016 13:13:20 -0700

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:[email-masked]] On Behalf Of Quan Nguyen
Sent: Thursday, August 18, 2016 12:07 PM
To: Russ Housley <[email-masked]>
Cc: Kathleen Moriarty <[email-masked]>; IETF SMIME <[email-masked]>; David McGrew <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [smime] [Technical Errata Reported] RFC5084 (4774)

On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley <[email-masked] <mailto:[email-masked]> > wrote:

Quan:

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

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.

Russ

On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley <[email-masked] <mailto:[email-masked]> > wrote:

Quan:

Russ

On Aug 11, 2016, at 2:49 PM, Quan Nguyen <[email-masked] <mailto:[email-masked]> > wrote:

On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <[email-masked] <mailto:[email-masked]> > wrote:

--------------------------------------
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 <[email-masked] <mailto:[email-masked]> >

Section: 3.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: Quan Nguyen <[email-masked]>
Date: Thu, 18 Aug 2016 13:33:26 -0700

On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad <[email-masked]> wrote:

> 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:[email-masked]] *On Behalf Of *Quan Nguyen
> *Sent:* Thursday, August 18, 2016 12:07 PM
> *To:* Russ Housley <[email-masked]>
> *Cc:* Kathleen Moriarty <[email-masked]>; IETF SMIME <
> [email-masked]>; David McGrew <[email-masked]>; Stephen Farrell <
> [email-masked]>
> *Subject:* Re: [smime] [Technical Errata Reported] RFC5084 (4774)
>
>
>
>
>
>
>
> Conscrypt is when Java Cipher (https://docs.oracle.com/javas
> e/7/docs/api/javax/crypto/Cipher.html) is initialized to use GCM mode:
>
>
>
> For instance, see : https://github.com/bcgit/bc-
> java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/
> provider/symmetric/AES.java#L497
>
>
>
> 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 :(
>
>
>

---

From: Quan Nguyen <[email-masked]>
Date: Thu, 18 Aug 2016 16:51:07 -0700

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 <[email-masked]> wrote:

>> 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.
>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>>    2. In other case, they use 12-byte tag, citing RFC 5084
>> recommendation. For instance, see : https://github.com/bcgit/bc-