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