Subject: RE: draft-ietf-smime-cms-auth and not streaming for decode

From: Russ Housley <[email-masked]>
Date: Tue, 01 May 2007 16:33:20 -0400

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