[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Steve:

> 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.

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.

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

> 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.

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 would like to see the text.

> 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).

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

> 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.

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?).

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