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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smime(_at_)mail(_dot_)imc(_dot_)org] 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
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