Subject: Re: Password-based Encryption for S/MIME...

From: [email-masked] (Peter Gutmann)
Date: Fri, 19 Nov 1999 09:45:58 (NZDT)

Carlisle Adams <[email-masked]> writes:

>At the meeting last week, Russ solicited more comments on a few of the
>current drafts, prior to going to Last Call.  One of the specifically cited
>drafts was "Password-based Encryption for S/MIME".

I actually submitted a (mildly) updated version based on previous discussions
for the IETF meeting but it got bounced because it arrived about 5 minutes
after the cutoff time taken from some arbitrary time zone which is about 5am
for me :-(.  I'll submit a newer version based on current feedback.

>1) "Musts", "shoulds", etc., should be capitalized (this is not absolutely
>necessary, but it does help to make conformance requirements clear and
>easy-to-find).

Although I dislike shouting (unless it's about broken X.509 stuff :-), I'll
change the text.

>2) The Security Considerations section currently contains only the following
>sentence:  "The security of this recipient information type rests on the
>security of the underlying mechanisms employed, for which further information
>can be found in CMS and PKCS5v2."  I suggest adding a new paragraph along the
>following lines.
>
>"More importantly, however, the security of this information type rests on the
>entropy of the user-selected password, which is typically quite low. Pass
>phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, although it
>should be recognized that even with pass phrases it will be difficult to use
>this recipient information type to derive a KEK with sufficient entropy to
>properly protect a 128-bit (or higher) CEK."

Is it worth going into this sort of thing?  I deliberately avoided covering
this because it's very obvious (it's just stating "If you pick an easily-
guessed password, you're toast"), it's mentioned in virtually every security
text and tutorial, and it's not something an implementor has much control over
(that is, it's unlikely that end users will read the draft and note that it's
recommending they use a strong password).  If people think it's worth adding
I'm happy to add it, but it seemed like it wouldn't add any real value to me.

Vin McLellan <[email-masked]> writes:

>Pass phrases for cryptographic keys???  Simple static reusable passwords??!
>
>Suggesting a password-based S/MIME which does not take advantage of any of
>the well-documented and proven methods for safely expanding a small password
>into a cryptographically respectable key  sounds like the WG is proposing
>something like 40-bit  symmetric crypto as a future standard.  Are the IP
>issues so entangled that the WG is left with such a meager and
>embarrassingly fragile offering?

The title of the document is somewhat misleading, because it's ietf-smime the
documents are typically called "X for S/MIME" but it's actually "Password-based
Encryption for CMS", which is what the text refers to it as.  The expected use
is for encrypting things like disk files, private keys, data blobs, etc etc.  
In addition there are users who are using things like non-public-key-capable 
smart cards to handle KEK's (typically 128 or 192-bit values for IDEA or 3DES) 
which are hardly in the same class as "simple static reusable passwords".

Incidentally, the use of pre-shared passwords among (at least) PGP users isn't
unheard-of, I've used it myself occasionally when I've met people in person and
neither of us had anything other than pencil and paper handy - it's a good way
to bootstrap secure communications based on personal contact.  Using random
passwords as authenticators is also fairly common at PGP key-signing BOF's.

Peter.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 18 Nov 1999 15:23:06 -0800

At 09:45 AM 11/19/99 +0000, Peter Gutmann wrote:
>Is it worth going into this sort of thing?

Yes, it is. That's exactly what the security considerations section is for. 
Some of them are really pedantic, but that's OK. Novice implementors 
actually read those sections.

--Paul Hoffman, Director
--Internet Mail Consortium