Subject: Re: comments on draft-ietf-smime-cms-auth-enveloped-02

From: Russ Housley <[email-masked]>
Date: Mon, 19 Mar 2007 05:47:34 -0400

Jim:

>Here is the first round of comments on this draft.

Thanks for your review.

>1.  I would like to see all information about padding out to a block size
>moved from this document to the algorithm documents.  This allows for each
>algorithm to specify if padding is needed and what type of padding is
>required.
>
>As an example, the CCM algorithm already as a padding technique built in and
>therefore the padding is not needed, or is it?  I cannot tell from the
>current documents if the data is supposed to be padded before it is passed
>in or not.  Padding is properly a part of the algorithm processing and not
>the superstructure processing.

The point is that some ciphers require the input to be a multiple of 
a block size.  AES-CBC is one such cipher.  We require that all such 
ciphers use the same padding mechanism in EnvelopedData.  I thin that 
we want similar consistency in AuthEnvelopedDtata.

>2.  If I implement a "stream" version of the decoder for authenticated data,
>am I permitted to pass the decrypted data along prior to doing the
>authentication step or not?   I raise the question because the CCM document
>states
>
>    The recipient MUST verify the CBC-MAC before releasing any
>    information such as the plaintext.  If the CBC-MAC verification
>    fails, the receiver MUST destroy all information, except for the fact
>    that the CBC-MAC verification failed.
>
>Which implies to me that until the validation is finished the decryption
>code should not pass on any data but buffer it.

You read it correctly.  Are you suggesting a change?  I think that 
the current document is consistent with the AES-CCM and AES-GCM 
cipher descriptions.

>3.  Just for clarity I think you need to state that you are not doing the
>"change the '1' to Set" mess before passing the authenticated attributes
>into the authentication algorithm.

I assume that this comment is about the tag.  If so, please propose 
text for a "Note that ..." paragraph.

>4.  Need to add text to state that each authenticated attribute must be
>internally DER encoded as well as the set of attributes.

Since attributes doe not use the "octet hole" syntax, I am not sure 
why this is needed.  Please explain.

>5.  There is actually a downside to including the message-digest attribute.
>It should be stated that this attribute MUST NOT be included.

These may be a performance downside, but I do not see a security 
one.  Do you?  If not, then I do not want to include a MUST NOT statement.

>6.  I am having a problem understanding the text ins section 3 para 4.  When
>using the symmetric key-encryption keys (and passwords) the actual AEK is
>wrapped by the original key and thus would be a "one-time-use" key with just
>as much certainty as for the key-transport method.  A better description of
>the problem is needed here in order to fully justify what you are saying.

Yep, the current text is muddled.  I propose:

Fortunately, the CMS authenticated-enveloped-data content type 
provides all of the tools needed to avoid misuse of counter 
mode.  All of the existing key management techniques permit a fresh 
content-encryption key to be generated for each content.  In 
addition, existing authenticated encryption algorithms that make use 
of counter mode support the use of an unpredictable nonce value in 
the counter block.  This unpredictable nonce value (sometimes called 
a "salt") should be carried in an algorithm identifier parameter.

>7.  IANA section is missing

Ack.  I'll add one.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 19 Mar 2007 15:53:08 +0100

Russ,

> we want similar consistency in AuthEnvelopedDtata.

I understand completely that some ciphers require padding.  However I
disagree that we want all ciphers to use the same padding mechanism.  I
strongly feel that we should remove the padding from EnvelopedData and place
it in the algorithm definitions.  I lost that argument solely on the grounds
of backwards compatibility.  My code has all of the padding done in the low
level encryption code, not in the CMS EnvelopedData code.  I think that this
means that the specification of the padding needs to be specified by the
algorithm not CMS.  

In any event you still need to specify if the AD data needs to be padded for
CCM since the algorithm definition has a padding algorithm and thus does not
need to be padded?

> the current document is consistent with the AES-CCM and AES-GCM

I think that this needs to be explicitly stated in this document, otherwise
I would not implement this buffering required for this.

> text for a "Note that ..." paragraph.

I guess the first question is are you going to do this in the same way that
SignedAttributes are done for compatibility or not?

> why this is needed.  Please explain.

Same reason that it is needed in the SignedData case.  If you place an
attribute in that I do not have a coder/decoder for, it needs to already be
DER encoded so that I can validate it.

> one.  Do you?  If not, then I do not want to include a MUST NOT

I think that if you place the message-digest of the un-encrypted data in
then I can track the un-encrypted data being sent.  I can also do candidate
looking based on the hash value.

> a "salt") should be carried in an algorithm identifier parameter.

Yes looks better.

Jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 20 Mar 2007 07:11:23 -0400

>CCM since the algorithm definition has a padding algorithm and thus does not

I think that using the same padding is desirable.  I do not see why 
it matters to the specification where in your code the padding is applied.

The algorithm spec needs to specify whether padding is needed.  When 
it is needed, I think that the padding needs to use the usual padding 
technique.  This is essentially the same approach that is taken with AES-CBC.

> > >authentication step or not?   I raise the question because the CCM
> > >document states
> > >

Okay.  How about:

    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.

>SignedAttributes are done for compatibility or not?

I think that is the best way forward.

>DER encoded so that I can validate it.

How about:

    AuthAttributes MUST be DER encoded, even if the rest of the
    AuthEnvelopedData structure is BER encoded.

>looking based on the hash value.

Yes, this is possible.  If we add a SHOULD NOT and we describe this 
consequence, are you satisfied?

Russ