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

From: Russ Housley <[email-masked]>
Date: Mon, 23 Apr 2007 15:04:35 -0400

That's why limited block sizes are very nice, but CMS does not have a 
maximum content size. The intent is for the overall hardware/software 
solution to only reveal plaintext after it is 
authenticated.  However, I recognize   a completely generic option 
with no limitations is desired.

Both AES-CCM and AES-GCM have requirements that require the integrity 
check to be performed before the plaintext is released.

Russ

At 01:02 AM 4/22/2007, Jim Schaad wrote:
>As the document is currently written, it is basically impossible to do
>streaming on a decode operation due to the following statement.
>
>The recipient MUST verify the integrity of the received content
>    before releasing any information, especially the plaintext of the
>    content.  If the integrity verification fails, the receiver MUST
>    destroy all of the plaintext of the content.
>
>My first reading of this assumed that the low-level decryption routine
>should be the one to take care of this statement.  But the real question is
>what is meant by "recipient".
>
>If one makes the statement that the low level decryption code is responsible
>for this, then making a hardware device to do the decryption becomes
>difficult unless it sets limits on the length of the data that can be
>decrypted. (The hardware would be required to buffer the contents on the
>chip until it had finished doing the validation operation.)
>
>If one makes the statement that the CMS code is responsible for this, code
>could not be said to be compliant to RFC 3610 since it has a similar
>statement in that document.
>
>I have to say that if I were to implement this code I would be very tempted
>to go ahead and do the decryption, stream the data out and return an error
>code of validation failed much as is currently done for the current
>EncryptedData and EnvelopedData structures.
>
>Why should this document handle this differently that a padding failure for
>those structures?  I propose removing that restriction.
>
>Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 29 Apr 2007 18:05:55 -0700

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.

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?

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.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: Monday, April 23, 2007 12:05 PM
> To: Jim Schaad
> Cc: Ietf-Smime
> Subject: Re: draft-ietf-smime-cms-auth and not streaming for decode
> 
>