Subject: Re: WG Last Call:draft-ietf-smime-rcek-01.txt

From: Russ Housley <[email-masked]>
Date: Sun, 11 Feb 2001 13:57:19 -0500

I have two concerns about this document.

1.  The default transformation from a CEK to a KEK is reversing the order 
of the bits.  For a DES or 3DES key, this will cause parity bits to become 
keying material.  I would prefer a default transformation that did not mix 
parity and keying material since 3DES in the S/MIME mandatory to implement 
cipher.  I propose a bitwise NOT.

2.  The document defines three related attributes.  It does not tell the 
implementor how to deal with the situation where some (but not all) of the 
attributes are implemented.  I suggest that a single attribute that 
includes some OPTIONAL fields might be preferable.  Perhaps:

    CEKReference ::= SEQUENCE {
       ref				OCTET STRING,
       maxDecrypts		INTEGER OPTIONAL,
       kekDerivationAlg		OBJECT IDENTIFIER DEFAULT id-alg-bitwise-not,
       kekDerivationParam	ANY DEFINED BY kekDerivationAlg OPTIONAL  }

In addition to making it straightforward to discuss the interactions 
between the fields, this approach allows other KEK Derivation algorithms to 
be specified in the future without any modification to the 
specification.  If the bit order reversal algorithm is needed, a simple OID 
assignment and statement that parameters are not needed completes the 
task.  The PKCS#5 KEK derivation is an OID assignment where parameters are 
required.

Comments?

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Feb 2001 10:57:32 +0000

Hi Russ,

> cipher.  I propose a bitwise NOT.

Good catch. However, you're caught yourself too!

The original reason to include bit reversal was: (raised by James Manger)

"One attack against this proposal springs to mind.  An attacker knowing some
of the plaintext (a prefix in a field for instance) can use the
corresponding ciphertext block as the next encrypted CEK, i.e. as
KEKRecipientInfo.encryptedKey.  Now the attacker know the next CEK.  [note.
this attacks may be unfair - by attacking something the proposal was not
claiming to protect - but I am unsure what others believe the proposal does
protect]"

And I'm afraid that with bitwise-NOT and the DES complementarity property
(thanks to William Whyte for spotting this), the original bad feature raises 
its head again (isn't key management fun:-).

William suggests byte reversal instead, which seems ok from both perspectives.

> attributes are implemented.  

Disagree. You MUST support CEKReference and CEKMaxDecrypts, and MAY support
KEKDerivationAlgorithm. (If that's not clear I will make it more so.)

CEKReference clearly has to be present or everything else is to be ignored.

CEKMaxDecrypts is only really a hint in any case, so if its not present the
recipient just keeps the CEKReference for a locally configured period (in
reality this'd be specified in some specification for the use case of this
trick).

KEKDerivationAlgorithm clearly has to be present if algorithms will change
for MSG2, otherwise not.

All in all, I disagreee that the implementer is left in limbo, but can add
text like the above if that helps.

> I suggest that a single attribute that
> includes some OPTIONAL fields might be preferable.  

I think this is a matter of taste - you prefer a single "structured" attribute,
my preference is for a set of "flat" attributes (I think its easier to code for
most ASN.1 handlers). 'Course, I'll switch if that's the concensus (i.e. if a
few other folks chip in on the subject).

> Perhaps:
 
> task.  The PKCS#5 KEK derivation is an OID assignment where parameters are

That last point is fair enough. OTOH, the current syntax also has the
required extensibility via the attribute OID for KEKDerivationAlgorithm
(which maybe should therefore be called PKCS5KEKDerivationAlgorithm?).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Feb 2001 15:13:32 -0500

>William suggests byte reversal instead, which seems ok from both perspectives.

Okay.  So, since bitwise-NOT and bit-reversal both have shortcomings, what 
are you going to use as the mandatory to implement transform?

>text like the above if that helps.

I would like to see the text.

>few other folks chip in on the subject).

I agree that this is a matter of taste.  I guess that I would like to hear 
from implementors to resolve this one.

>(which maybe should therefore be called PKCS5KEKDerivationAlgorithm?).

In general, I prefer to distribute keys with an algorithm identifier that 
tells the recipient how to use the key.  In this case, the CEK and the CEK 
algorithm are handled by CMS.  By default, the CEK and KEK will employ the 
same algorithm.  If not, then the transformation and the KEK algorithm 
should be part of the management information.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 19 Feb 2001 10:11:02 +0000

Hi Russ,

> are you going to use as the mandatory to implement transform?

Byte reversal, i.e. MSG2.KEK=byte-reverse(MSG1.CEK). If MSG1.CEK has N
bytes, then treated as 'C' arrays, MSG2.KEK[i] = MSG1.CEK[N-i].

> > > attributes are implemented.
[...]
> I would like to see the text.

How about a new section 5:

"5. Conformance.

This specification only applies to messages where the CEKReference
attribute is present. All attributes specified here SHOULD be ignored unless 
they are present in a message containing a valid, new or recognised, existing 
value of CEKReference. The CEKMaxDecrypts attribute is to be treated by the 
recipient as a hint, but MUST be honored by the originator. 

The optional to implement KEKDerivationAlgorithm attribute MUST only be present 
when MSG1.content-encryption-algorithm differs from MSG2.key-encryption-algorithm, 
in which case it MUST be present. Implementations which recognize this
attribute, but do not support the functionality SHOULD ignore the attribute.

Ignoring attributes as discussed above, will lead to decryption failures.
CMS implementations SHOULD be able to signal the particular reason for this
failure to the calling application."

> from implementors to resolve this one.

Agreed. I think its fair to assume that silence here is concensus not to
change the text? 

Cheers,
Stephen.