Re: [Technical Errata Reported] RFC5084 (4774)

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 protected]> wrote:

>
>
> On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad <[email protected]>
> wrote:
>
>> 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,
>>
>
> 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 protected]] *On Behalf Of *Quan Nguyen
>> *Sent:* Thursday, August 18, 2016 12:07 PM
>> *To:* Russ Housley <[email protected]>
>> *Cc:* Kathleen Moriarty <[email protected]>; IETF SMIME <
>> [email protected]>; David McGrew <[email protected]>; Stephen Farrell <
>> [email protected]>
>> *Subject:* Re: [smime] [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/javas
>> e/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