Re: [Technical Errata Reported] RFC5084 (4774)

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


> On Mon, Aug 15, 2016 at 1:55 PM, Russ Housley <[email protected]> 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 <[email protected]> wrote:
> 
>> 
>> 
>> On Thu, Aug 11, 2016 at 11:47 AM, RFC Errata System <[email protected]> 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 <[email protected]>
>> 
>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/smime