Subject: Way Forward

From: Russ Housley <[email-masked]>
Date: Mon, 31 Jul 2000 17:04:52 -0400

At the face-to-face meeting today, we had a fair amount of discussion about 
the best way to proceed.  This message states each of the issues and the 
proposed way forward.  This message is intended to give everyone an 
opportunity to provide their input, even if they were unable to attend the 
meeting.

RFC 2630 Interoperability Testing

Issue:  Two implementations have been tested for EnvelopedData and 
SignedData.  These two data structures are required to implement S/MIME, so 
this is not surprising.  RFC 2630 includes other data structure that are 
MUST implement(EncryptedData, DigestedData, and AuthenticatedData).  We do 
not have two implementations for these data structures.

Proposed way forward:  Change the implementation requirements so that:
	- EnvelopedData and SignedData MUST be implemented; and
	- EncryptedData, DigestedData, and AuthenticatedData MAY be implemented.

Mandatory To Implement Algorithms

Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested 
that the RSA algorithm become the mandatory to implement algorithm for key 
management and signature.  It was pointed out that the current RSA key 
management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique 
should be employed instead.  While we were discussing algorithms, it was 
suggested that AES should be the mandatory to implement symmetric cipher 
instead of Triple-DES.  About half of the people thought that this was a 
good idea.  The other half was concerned that the AES has not been 
published yet.

Proposed way forward:  Change the mandatory to implement algorithm set to:
	One-way Hash:	SHA-1 (no change)
	Signature:	Both DSA and RSA (PKCS#1 v1.5)
	Key Mgmt:	RSA (OAEP)
	Eencryption:	Triple-DES in CBC mode

All comments on either of these proposals is most welcome.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: 01 Aug 2000 08:11:34 -0700

Russ Housley <[email-masked]> writes:
> should be employed instead.
I'm not sure what the rationale is for this and it seems to me to
present even more opportunities for incompatibility.  The
vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack
that requires order 2^20 messages to be processed by the recipient
with quite specific success or failure indications.  In most
applications, this isn't practical at all. Moreover, the attack is
easily countered with a simple set of checks.

-Ekr

[Eric Rescorla                                   [email-masked]]

---

From: [email-masked] (Terry Hayes)
Date: Tue, 01 Aug 2000 10:59:57 -0700

I agree with Eric.  It would be better to maintain compatibility with the
existing S/MIME v2 deployments by using the PKCS #1.5 version of RSA key
management.

If the vulnerability is the one Eric mentions, then it is not really
significant.  It relies on receiving a very specific error message that
indicates that the PKCS #1.5 formatting was incorrect.  It can be countered by
including this error with other types of decryption errors (such as DES padding
errors) or by allowing the decryption to proceed (with the wrong key) and
signaling failures in the integrity (signature or authentication) portion of the
message.  Netscape's version of SSL does exactly this - the SSL handshake fails
later in the sequence when the MAC calculation fails.

In fact, in S/MIME it is not likely that the sender would any sort of response
(error or otherwise) at all, which makes this attack impossible.  In addition
the requirement for 2^20 messages in an email environment makes it impractical
as well.

Again, I would like to see PKCS #1.5 included as the mandatory algorithm to
allow compatibility with existing deployments.

Terry Hayes
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Tue, 01 Aug 2000 16:11:00 -0400

Eric:

The attack is probably impossible to mount using S/MIME against a 
human-operated mail agent; however, I am not convinced that a mail list 
agent (or other automated mail agent) would be immune.  Further, CMS is 
being used in many environments, not just S/MIME, and some of those 
environments may have issues.

OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not 
think that it is immature.

Russ

---

From: Maxim Masiutin <[email-masked]>
Date: Tue, 1 Aug 2000 23:50:29 +0300

Hello Russ!

  I'm an author of The Bat!
  http://www.ritlabs.com/the_bat/

  This email client for Win32

  that has S/MIME implementation based on own codebase written from
  scratch on Delphi as well as the rest of The Bat!

  I would like The Bat! to pass interoperability testing while forum
  continues. Your help would be appreciated.

  The Bat! official releases do not have S/MIME support yet, but beta
  versions of The Bat! are S/MIME enabled.

  You may download The Bat! with S/MIME support from
  http://www.ritlabs.com/the_bat/beta.html

-- 
Maxim Masiutin,
Software Engineer
RIT Research Labs  http://www.ritlabs.com/

---

From: Eric Rescorla <[email-masked]>
Date: 01 Aug 2000 14:18:45 -0700

> environments may have issues.
Understood, but it's trivial to patch these S/MIME agents to
be completely immune to this attack without compromising compatibility.

> think that it is immature.
That's not the issue that I am concerned with. Rather, I'm concerned
with introducing gratuitous incompatibilities.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 01 Aug 2000 17:47:51 -0400

We would enjoy your participation.

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 1 Aug 2000 19:01:22 -0400

>with introducing gratuitous incompatibilities.

I'm with Eric on this one. We can add a note about how to avoid the 
problem *and* keep compatibility with the established S/MIME base. 
The proposal was prompted by S/MIME, not CMS.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Housley <[email-masked]>
Date: Wed, 02 Aug 2000 11:20:39 -0400

Eric:

I do not think that we are being gratuitous.  I think that it is good 
security practice to remove any toe-hold that an attacker has.  Further, I 
do not believe that the CMS layer in current S/MIME implementations exhibit 
the behavior (or lack thereof) necessary to be immune from the attack 
against RSA PKCS#1 v1.5.

Russ

---

From: [email-masked] (Bob Relyea)
Date: Wed, 02 Aug 2000 08:41:18 -0700

> the behavior (or lack thereof) necessary to be immune from the attack

I have to agree with Eric here. Protocols where are *MUCH* more vulnerable than
CMS or S/MIME were able to work around the attack. We know how to make out
toolkits  immune without sacrificing interoperability, we should do that.
Current implementations that don't exhibit the correct behavior to be immune,
still won't exhibit the correct behavior if you change the spec to OAEP.

If we were developing a new protocol from the ground up, then using OAEP would
be a no brainer. That is not the case here, though.

bob

---

From: Eric Rescorla <[email-masked]>
Date: 02 Aug 2000 09:08:38 -0700

> the behavior (or lack thereof) necessary to be immune from the attack 
I'm sorry, Russ, but I don't understand your point. It's well known
how to protect PKCS-1 implementations from this attack: If the PKCS-1
padding is wrong, instead of throwing an error you randomize the key
and then continue. In fact, this is what essentially all SSL
implementations do. While it may be the case that current S/MIME or
CMS implementations don't do this, it's a trivial change to make and
introduces no incompatibilities.

Since adding OAEP also requires changing the code _and_ introduces
incompatibilities, ISTM that just fixing one's PKCS-1 implementation
is the dominant option.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Wed, 02 Aug 2000 16:04:14 -0400

Eric:

One change or another is needed.  Either we need to adopt OAEP or we need 
to include the correct processing steps for use with PKCS#1 v1.5.

All:

As chairman, I am trying to figure out the consensus of the  work 
group.  If everyone has enough information from this thread, then I would 
like to hear from folks that have an opinion but have not spoken up yet.

Russ

---

From: Aram Perez <[email-masked]>
Date: Wed, 02 Aug 2000 14:12:04 -0700

Hi Russ,

[snip]
> like to hear from folks that have an opinion but have not spoken up yet.

My 2 centavos are: Keep PKCS#1.5 with appropriate notification on the known
attack(s) and recommended procedures to minimize their effect. As you
stated, there is already reference to OAEP for future versions.

Regards,
Aram Perez

[snip]

---

From: Eric Rescorla <[email-masked]>
Date: 02 Aug 2000 14:41:45 -0700

> to include the correct processing steps for use with PKCS#1 v1.5.
Agreed. I'm in favor of the latter, since they don't have any effect
on compatibility.

-Ekr

---

From: "John G Ross" <[email-masked]>
Date: Thu, 3 Aug 2000 00:31:20 +0100

As backward compatability is only an issue between versions of S/MIME. Would
a compromise be for CMS to keep to the existing mandatory algorithms as
specified in RFC 2630 (DH/DSA), but in the message specification RFC 2633
also mandate support for RSA, for backward compatinility reasons with S/MIME
v2.

I know this means that both sets of algorithms have to be implemented in
S/MIME, but is that really a big problem.

Regards
John Ross

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Aram Perez
> Sent: Wednesday, August 02, 2000 10:12 PM
> To: [email-masked]
> Subject: Re: Way Forward
>
>
> Hi Russ,
>
> [snip]
> >
> > All:
> >

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 03 Aug 2000 01:56:19 +0100

> like to hear from folks that have an opinion but have not spoken up yet.

I'm in favour of keeping PKCS#1 v1.5 

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: Sean Turner <[email-masked]>
Date: Thu, 03 Aug 2000 17:59:04 -0400

My two cents:  I think it's likely that we'll switch to AES when it's finalized, why
don't we wait to change until then?  Then we only have to change once.

Cheers,

spt

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 4 Aug 2000 09:12:05 -0400

>don't we wait to change until then?  Then we only have to change once.

It sounds like we need to better define our goals for changing the 
current RFCs. My goal is to have it reflect the reality of today's 
deployed base of S/MIME MUAs. Because of that, mandating either OEAP 
or AES would be much worse than leaving the current RFCs alone.

--Paul Hoffman, Director

---

From: Russ Housley <[email-masked]>
Date: Tue, 08 Aug 2000 12:39:01 -0400

Jim:

We encourage additional implementations to participate in the 
interoperability testing.

I understand the concern that you raise about changes in the 
mandatory-to-implement algorithms.  This is why we are having a discussion 
before any action is taken.  Other implementors support RSA and do not 
support D-H.  These folks would like to see S/MIME v2 and S/MIME v3 have an 
interoperable mandatory-to-implement algorithm.

Russ

At 02:51 PM 08/08/2000 +0100, Jim Davies wrote:
>Hi Russ
>
>I am a recipient of the mailings in this group - as someone with limited
>technical knowledge but a business interest in PKI - and S/MIME 3 standards
>in particular.  Please make allowances therefore if any of my questions or
>comments are totally off beam!
>
>I have been following the discussions prompted by the proposals below on RFC
>2630 - and also trying to tie them in with RFC 2632: S/MIME Version 3
>Certificate handling - and RFC 2633: S/MIME Version 3 Message specification.
>
>My project is currently based around a mail product called Reflex MailSafe
>(http://www.reflex-magnetics.com).  It offers full S/MIME 3 compatibility
>and can use either DH or RSA for generating key pairs.  A "cut down" 56 bit
>version is available at the web site - other than key length it is fully
>functional.  At present there is only a mail client - in due course it is
>planned to offer various network features.
>
>To my mind - the use of DH keys is preferable to RSA.  I had assumed that -
>as a result of using DH keys - S/MIME 2 products would not be able to read
>S/MIME 3 encrypted - and DSA signed - messages.
>
>I am concerned that what appears to be happening is a downgrading or
>watering down of S/MIME 3 in order to enable interoperability with S/MIME 2
>products.  It seems particularly curious when there is a mail client
>available that - so far as I can tell - provides the previously stated
>functionality.  I need to be able to make sound business planning
>decisions - and this debate has thrown me into a bit of a spin.
>
>Am I mis-reading what appears to be going on - or do I have a genuine need
>to re-consider my planning?  Also - were you aware of Reflex MailSafe -
>which I believe to be the first product available that offers full S/MIME 3
>compatibility?  If not - does any of the above have any impact on the
>proposed changes to the standards?
>
>As I said at the outset - please disabuse me if I have missed the point here
>completely - much of what is discussed quite frankly goes over my head!
>
>I look forward to hearing from you.
>
>Best wishes
>
>Jim
>
>Jim Davies
>Director - GPM Ltd.
>82 Dartmouth Park Hill
>London N19 5HU
>
>Tel.    +44 (0) 20 72810123
>Fax      +44 (0) 20 75611666
>Mobile  +44 (0)7958 523479
>Email   [email-masked]
>
>
>This e-mail transmission (and any attachment) is strictly confidential
>and intended solely for the person or organisation to whom it is
>addressed.  It may contain privileged and confidential information and
>if you are not the intended recipient, you must not copy, distribute or
>take any action in reliance on it. If you have received this e-mail in
>error, please notify us as soon as possible and delete it.
>
>
>
>
>
>[mailto:[email-masked]]On Behalf Of Russ Housley
>Sent: 31 July 2000 22:05
>To: [email-masked]
>Subject: Way Forward
>
>

---

From: "Jim Davies" <[email-masked]>
Date: Tue, 8 Aug 2000 21:05:27 +0100

Russ

Glad to get involved.  Unless I am missing a trick - Reflex MailSafe
implements both RSA and D-H - which enables it to be both backward
compatible if dealing with mail from S/MIME v2 users and forward compatible
for S/MIME v3.  My question was really - unless I am missing the point - why
therefore dilute the S/MIME v3 standard?

Best wishes

Jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: 08 August 2000 17:39
To: [email-masked]
Cc: [email-masked]
Subject: RE: Way Forward

Jim:

Russ