Re: [smime] [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 <quannguyen(_at_)google(_dot_)com> 
wrote:

> On Thu, Aug 18, 2016 at 1:13 PM, Jim Schaad 
> <ietf(_at_)augustcellars(_dot_)com>
> 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:smime-bounces(_at_)ietf(_dot_)org] *On Behalf Of *Quan 
> > Nguyen
> > *Sent:* Thursday, August 18, 2016 12:07 PM
> > *To:* Russ Housley <housley(_at_)vigilsec(_dot_)com>
> > *Cc:* Kathleen Moriarty 
> > <Kathleen(_dot_)Moriarty(_dot_)ietf(_at_)gmail(_dot_)com>; IETF SMIME <
> > smime(_at_)ietf(_dot_)org>; David McGrew <mcgrew(_at_)cisco(_dot_)com>; 
> > Stephen Farrell <
> > stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
> > *Subject:* Re: [smime] [Technical Errata Reported] RFC5084 (4774)
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Aug 18, 2016 at 11:39 AM, Russ Housley 
> > <housley(_at_)vigilsec(_dot_)com>
> > 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 
> > <housley(_at_)vigilsec(_dot_)com>
> > 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 <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/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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime