Subject: RE: Last Call: Password-based Encryption for S/MIME to Proposed Standard

From: [email-masked] (Peter Gutmann)
Date: Thu, 5 Apr 2001 13:36:14 (NZST)

"Jim Schaad" <[email-masked]> writes:

>Comments on this draft:
>
>[Minor editing odds and ends]

Thanks.  The ASN.1 glitches came about mostly because it was originally done in
'94 and then edited from that back to '88 fairly late, which lead to a little
friction between the two versions.

>3. Section 1.2.1: Paragraph 1: The phrase "user-supplied password or
>previously agreed-upon key" is somewhat misleading.  KEK is the generally used
>agreed-upon key method for key managment.  Please delete the phrase "or
>previously agreed-upon key".  (Ditto for all subsequent references.)

It was originally just "user-supplied password", but then people popped up who
were using it slightly differently, for which "previously agreed-upon key"
fitted perfectly (for example a University in Germany somewhere is (or at least
was when it was written) using it with a PIC wafercard to do IDEA wrapping of
3DES or DES keys, I thought it was 3DES but thinking back it could have been
just DES, which would imply they're using it for Kerberos login... this makes a
good Uni project since you can fiddle with Kerberos or Sesame or whatever using
cheap, readily-available wafercards).  Anyway, you can't do this with CMS-KEK,
and what they're doing is effectively password-based encryption, they're just
replacing the (Kerberos/Sesame) password with a wafercard, thus "previously
agreed-upon key".

>4.  Section 1.2.1: In the event that two password recipient info's are
>present, how do I determine which is the one I am to use?

I'll answer that one in two parts:

1. What practical need is there for this?  Every password-based encryption
   program from crypt through to this morning's release of GPG, asks for a
   password and then encrypts data with it.  Although it is theoretically
   possible to use multiple passwords, the fact that after 20-odd years of
   password-based encryption utilities noone has seen any need to add this
   indicates that it's not a major issue.

2. How would you add support for this?  That is, how do you identify in the
   PWRI which password is being used?  The usual method - throw in an OCTET
   STRING hole and let people dump whatever they want in it - isn't much use
   because every implementor will choose something different, which means app A
   won't be able to do anything useful with a PWRI from app B.

The reason there's no provision for handling more than one PWRI is a
combination of the two above points, there doesn't seem to be any real demand
for it, and without real-world requirements it's not possible to determine what
should be done.  If a real-world demand does emerge in a years time (or
whenever), we can publish a v2 which addresses it, but trying to guess in
advance a solution to an unknown problem seems risky.

(Having said that, if you know of a good solution to this problem which doesn't
 involve OCTET STRING holes or a SEQUENCE OF everything-imaginable OPTIONAL
 (which is about the same thing) I'd love to hear it, if there really is a
 clear, precise solution I'll be happy to add it).

>6.  Section 1.2.1: Paragraph keyDerivationAlgorithm: Please justfy why this is
>optional.

See (3) above.

>8.  Section 2.2 & 2.3:  You have Key Encryption algorithms and Symmetric Key
>Encryption algorithms.  I don't understand the difference between these two
>groups as they both appear to be using symmetric keys, take a KEK and encrypt
>a CEK.  The only difference appears to be that the first are simple encrytion
>algorithms and the second are complex ones.

They're both completely standard, off-the-shelf algorithms (eg DES-CBC, 3DES-
CBC, whatever).  The only reason they're distinguished in the text is to allow
a description of the difference between a KEK and CEK, and because the KEK
algorithms (section 2.2) are tied to RFC 2898 while the CEK ones (section 2.3)
aren't.  Putting them in the same section would make it rather confusing, or at
least less unambiguous.

>10. Section 2.2:  Why is Triple-DES/CBC a MUST algorithm.  This appears to be
>reasonable for content encryption but is not a good idea for key encryption.

To guarantee interoperability?  You need at least one MUST, and 3DES seems to
be the most widely-accepted algorithm.  Why would you not have a standard
algorithm as a MUST?

>12.  Section 2.3.3: unwrap Item 2:  This does not appear to agree with the
>algorithm in section 2.3.2.  Should it not be "Set the IV to the decrypted
>content, decrypt the first 8 bytes."?

No, it's correct as it stands (because encryption is just two passes of
straight encryption, the IV for the outer encrypted layer is the last block of
the inner encrypted layer).  A number of people have created implementations
from that text without any problems.

>13.  Section 2.2: I am having a problem with what you are using for the
>KeyEncryptionAlgorithm.  I think that you need to use something other than the
>standard content-encryption algorithm OIDs in this location due to the fact
>that you are adding additional processing in the form of the wrapping
>algorithm.  I think that this issue alone is a killer for this document as it
>is presently set out.

I'm sorry, but I don't understand this comment.  One of the design goals of the
PWRI wrapping is that it uses completely standard algorithms and modes without
any need to invent new OIDs, encryption modes, mechanisms, or whatnot (you can
take any standard block cipher off the shelf with a standard OID and use it to
wrap the key).  What you're saying is that you want a series of gratuitously
incompatible OIDs used in order to make implementation difficult?  This would
lead to complete chaos, every time a new algorithm turns up you'd need to
either update the existing RFC or publish a new one just to define a new,
incompatible OID... it'd be a nightmare for implementors, you'd have to do a
new code release every month or so just to keep up with all the new OIDs you're
defininig, even though you're using completely standard algorithms.  In
contrast the current approach fits right in with any existing algorithm/OID
(for example although it was published long before AES came out, it's
automatically compatible with AES without having to publish a new RFC just to
define an AES-wrap OID).

>14.  Section 2.2: It is still my belief that the key wrap algorithm presented
>as part of RFC2460 should be the MUST key wrap algorithm (i.e. id-alg-
>CMS3DESwrap).  The CMS version will be implemented in software for CMS
>compatilibity and in all likely hood will also be done in hardware as well if
>KEK encryption ever becomes real common place. (For use with S/MIME symmetric
>key mailing lists if nothing else.) While I don't object to your offering a
>second key wrap algorithm I don't see a strong benifit for it over the already
>existing version in CMS.

The PWRI algorithm is a one-size-fits-all mechanism which works with any
cipher, including ones not yet invented (an example being AES, at the time the
draft was first written).  At the time of writing, the CMS KEK wrap only worked
for 3DES-in-3DES wrap and RC2-in-RC2 wrap, and nothing else.  In contrast the
PWRI wrap works for any algorithm, so you only have to implement the mechanism
once and it'll work for every future algorithm.  CMS KEK wrap has since been
extended via a string of extra RFCs to handle IDEA-in-IDEA wrap and CAST128-in-
CAST128 wrap, but it still doesn't handle anything else (for example it won't
handle the 3DES-in-IDEA or DES-in-IDEA wrap mentioned in (3) above, and it's
going to require yet another new RFC to handle AES).

While it would be possible to change the text to say something like "Use this
mechanism for everything but 3DES", all that'll do is lead to unnecessary
complexity and interop problems (not to mention thoughts of "What the..." from
anyone who's seeing that requirement for the first time :-).

In terms of hardware implementation, I haven't seen PKCS #11 vendors rushing to
implement CMS KEK.  OTOH since the PWRI wrap works with any standard cipher
with no special processing required, it's automatically supported in hardware
already.

Overall, the current draft just plain works, I don't see why it needs to be
artificially restricted or use incompatible OIDs whose only purpose seems to be
to make implementation a pain.

Peter.

(I'm heading out for the RSA conference tomorrow so it may take me awhile to
 reply to followups).

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 13 Apr 2001 14:47:22 -0700

Peter,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Thursday, April 05, 2001 1:36 PM
> To: "IETF-An"@above.proper.com; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Last Call: Password-based Encryption for S/MIME
> to Proposed
> Standard
>
>

When you get an updated ASN module(s), please send them to me for futher
verification.
> replacing the (Kerberos/Sesame) password with a wafercard,

I don't buy this argument anymore than the others, but I think we need to
just say we are going to forever disagree on this and skip it.

>    indicates that it's not a major issue.

Here is a use for this that I have at present.  There exists a dirth of good
algorithms to use for the AuthenticatedData structure.  At present the only
one that works is Static-Static DH (which is not a standard CMS algorithm).
THe problem is that with algorithms such as RSA and E-S DH there is no
method of authenticating the originator.  I could use the password protected
key for doing AuthenticatedData. (Thus proving that it originated with
somebody who could correctly compute the password.)  If I use it in this
senerio then I need some way for a server to determine which of the many
recipients originated this message and thus what password based key is
needed for validating of the AuthenticatedData structure.

>  clear, precise solution I'll be happy to add it).

You might not like octet holes, I might not octet holes (possibly for
different reasons) but they provide the simpliest solition to this problem.
I would suggest that the same identification structure is used for this as
is currently used for KEKRecipientInfo.  This is fairly general purpose.

> >6.  Section 1.2.1: Paragraph keyDerivationAlgorithm: Please

see (3) above.

> aren't.  Putting them in the same section would make it

While I could by that argument, section 2.3 is talking about Symetric KEY
encryption algorithms not CONTENT encryption algorithms.  Again what is the
difference between the two sections.

> automatically compatible with AES without having to publish a

What you want and what I want are not incompatable.  If you defined an
id-alg-pwri-kek-encryption OID, gave it the structure of AlgorithmIdentifier
then you and I could both be happy. I would have a seperate OID to
distingish between a KEK and a CEK algorithm (ie-alg-pwri-kek-encryption vs
des-3DES-CBC) and you would not need to define a new OID for every algorithm
under the sun.  The content encryption algorithm is the parameter to the key
wrap algorithm.  I cannot accept that des-3DES-CBC is a different algorithm
based soley on the location in the ASN that the OID is placed.

> with no special processing required, it's automatically

I have no method of verifying or disproving you statement at that it is
already in hardware, but I find it difficult to believe that id does not
require additional software above the hardware level to implement.  That
being the case I can make the exact same argument for the CMS key wrap, that
a software module operating above a standard card implementing the standard
content encryption algorithm can be used to implement CMS.  That in fact is
actually the first way that I impemented the CMS key wrap algorithm for test
purposes.

> (I'm heading out for the RSA conference tomorrow so it may

jim