headers
Eric Rescorla | 1 Aug 2000 17:11

Re: Way Forward

Russ Housley <housley <at> spyrus.com> writes:
> 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.
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                                   ekr <at> rtfm.com]
Permalink | Reply | 3 comments |
headers
David P. Kemp | 1 Aug 2000 18:24

Re: Way Forward


Russ,

Regarding data structures, http://www.ietf.org/ID-nits.html says:

  "For documents advancing in grade

   At least two complete, independent implementations must be tested and
   reported on, of each role (client/server/peer), and of each feature."

I believe this implies that EncryptedData, DigestedData, and
AuthenticatedData cannot be simply reduced to MAY status, but must be
moved to a different document if RFC 2630 is to proceed to Draft.  And
attractive as it might be to require AES instead of 3DES, this clause
precludes that option at this time.

Regarding RSA, if OAEP is specified for RSA key transport, should not
PSS be specified for signatures?  That said, I agree with Erik that
PKCS#1 v1.5 is sufficient for key transport, and if there are not two
independent implementations of X9.31, PKCS#1 is probably sufficient for
signatures.

Regarding key establishment, I believe it would be good engineering to
require a key agreement protocol such as DH, ECDH, a fully-public KEA,
or a future FIPS key agreement algorithm in CMS-based systems, in
addition to RSA key transport.  If someone proposed that both RSA and
X9.42 be mandatory, I would support that proposal if there were two
tested implementations of X9.42.  Are there?

Regarding terminology, I suggest that the term "Key Establishment" be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Terry Hayes | 1 Aug 2000 19:59
Picon

Re: Way Forward

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
thayes <at> netscape.com

Eric Rescorla wrote:

> Russ Housley <housley <at> spyrus.com> writes:
> > 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 1 Aug 2000 22:11

Re: Way Forward

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

At 08:11 AM 08/01/2000 -0700, Eric Rescorla wrote:
>Russ Housley <housley <at> spyrus.com> writes:
> > 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.
>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
>
(Continue reading)

Permalink | Reply | 10 comments |
headers
Maxim Masiutin | 1 Aug 2000 22:50
Favicon

Re[2]: Way Forward

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/
Permalink | Reply | 0 comments |
headers
Russ Housley | 1 Aug 2000 22:47

Re: Comments on draft-ietf-smime-cms-rsaes-oaep-01.txt

Jim:

>Section 1 Paragraph 4:  Spelling error on interactibe.

Fixed.

>Section 2 Paragraph 2: Remove last instance of "[CMS]" as it is not
>necessary.

Agree.

>Section 2.1 Paragraph 3: Delete or reword this paragraph as it is not
>correct.  originatorInfo may be present due to other recipient infos.

Agree.  The originatorInfo may be present if some other recipient is using 
a different key management protocol.

>Section 3 Paragraph 5 (maskGenFunc): MFG1 should be changed to MFG1SHA1 or
>all references to it using SHA1 should be replaced with references to it
>using a OWF.
>
>Section 3 Paragraph 5: Is SHA1 to be the one and only OWF supported here or
>are others permitted.  Text is not clear on this issue.

Okay.

>Section 3 Paragaraph 5 and 6:  Why are you requiring that incorrectly
>encoded (i.e. the default value is supplied) be recognized? "... recognize
>both id-sha1 and absent..."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 1 Aug 2000 23:18

Re: Way Forward

Russ Housley <housley <at> spyrus.com> writes:
> 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.
Understood, but it's trivial to patch these S/MIME agents to
be completely immune to this attack without compromising compatibility.

> OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not 
> think that it is immature.
That's not the issue that I am concerned with. Rather, I'm concerned
with introducing gratuitous incompatibilities.

-Ekr
Permalink | Reply | 1 comment |
headers
Russ Housley | 1 Aug 2000 23:47

Re[2]: Way Forward

We would enjoy your participation.

Russ

At 11:50 PM 08/01/2000 +0300, Maxim Masiutin wrote:
>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/
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 2 Aug 2000 01:01
Picon

Re: Way Forward

At 2:18 PM -0700 8/1/00, Eric Rescorla wrote:
>  > OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
>>  think that it is immature.
>That's not the issue that I am concerned with. Rather, I'm concerned
>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
Permalink | Reply | 0 comments |
headers
Linn, John | 2 Aug 2000 14:45

RE: Way Forward

OAEP's incremental value is particularly applicable to interactive uses of
CMS, many of which may not have S/MIME's established base concerns and which
should take other protocol countermeasures (perhaps implying more
security-relevant complexity and processing to be performed outside the
bounds of the security encapsulation layer) if OAEP isn't applied. I'd like
to recommend OAEP as at least a general SHOULD, making it the presumed mode
unless an application has specific need to profile otherwise; if there's an
S/MIME interoperability requirement for PKCS#1 v. 1.5, I'd suggest that the
scope of that MUST's applicability be confined to the S/MIME application. 

--jl

-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman <at> imc.org]
Sent: Tuesday, August 01, 2000 7:01 PM
To: ietf-smime <at> imc.org
Subject: Re: Way Forward

At 2:18 PM -0700 8/1/00, Eric Rescorla wrote:
>  > OAEP have been available for years.  PKCS#1 v2.0 includes it.  I do not
>>  think that it is immature.
>That's not the issue that I am concerned with. Rather, I'm concerned
>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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane