Jim:
I spent time this weekend carefully reading the two drafts looking at this
issue and what it does or does not mean.
1. Neither of the documents currently under consideration make any
statements dealing with the issue.
2. The text in RFC 3610 can be read somewhat ambiguously. The requirement
is placed on the Recipient not to release the until the content has been
validated.
3. The text in RFC 3610 does not state if there is a security flaw with
releasing the content or if it is just a desirable property of the code.
4. Unless there is a security issue with allowing the content to be passed
on, I think that CMS implementation should threat this the same way as an
invalid signature. The user application has the option of how to treat the
failure of validation on the decryption operation. My expectation would be
that this is to fail in some way w/o displaying the content but this cannot
be assured. This means no changes for either of the current documents.
5. I would like RFC 3610 to be amended to state if there is a security
issue in revealing the contents in the event of a validation failure. The
same thing should also be done for GCM.
People expect AES-CCM and AES-GCM to provide confidentiality and
integrity. If the plaintext is released and the authentication tag
check fails, then the integrity is not provided. Thus, the expected
services are not provided.
I also found the following issue that should probably be addressed:
In aes-ccm-and-gcm-01, there are a couple of things about section 2.
1. The heading uses "Automatic Key", but the text uses ""automated key" -
should these be the same?
Yep, it should be "automated."
2. The document states that new key management systems need to check
against the requirements of the automated key management system, but there
is no list of what these requirements are or a pointer to the requirements.
I think this needs to be inserted.
It should reference RFC 4107.
Russ