Re: [Technical Errata Reported] RFC5084 (4774)

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

> Quan:
>
> I just read the cited paper from Niels Ferguson <
> http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/commen
> ts/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.
>

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

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

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

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime