[Top] [All Lists]

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

2016-08-18 13:39:57

I just read the cited paper from Niels Ferguson 
  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?


On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley 
<housley(_at_)vigilsec(_dot_)com> wrote:

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.


On Aug 11, 2016, at 2:49 PM, Quan Nguyen <quannguyen(_at_)google(_dot_)com> 

On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System 
<rfc-editor(_at_)rfc-editor(_dot_)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:

Type: Technical
Reported by: QUAN NGUYEN <quannguyen(_at_)google(_dot_)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.

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

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

smime mailing list