ietf-smime
[Top] [All Lists]

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

2016-08-15 15:55:54
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 <quannguyen(_at_)google(_dot_)com> 
wrote:



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:
http://www.rfc-editor.org/errata_search.php?rfc=5084&eid=4774

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

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.

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



_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime