Subject: Re: AES and PKCS #1 v1.5 Issue

From: [email-masked] (Peter Gutmann)
Date: Wed, 17 Jul 2002 18:20:49 +1200 (NZST)

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

>The face-to-face meeting was presented with the following choices:
>
>1.  Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
>document.
>2.  Remove the ban, but allow the author to present a diatribe on why
>it's a bad idea.
>3.  Remove the ban entirely and force an update to SMimeCapabilities to
>allow for products to advise that the combination is not acceptable.

Didn't we go through all this (endlessly) ages ago, and more or less
resolve to let people use PKCS #1 if they wanted to?

[pause]

Oh, sorry, that was ietf-tls which looked at it.  The conclusion there
was:

>If people are interested in seeing OAEP adopted it won't need to use the
>momentum AES has created.  If people aren't interested then it won't get
>adopted, but that's the way it should be.

ietf-tls also looked into simple-RSA, the general opinion was that if
any change is made, simple-RSA would be a better choice since there's no
OAEP deployed base to be compatible with.

Given that every S/MIME implementation around already does AES with 
PKCS #1 (is there anyone who hasn't added AES support yet?), mandating
OAEP is just going to be another X9.42 - everyone pretends to do it
but does PKCS #1 instead.  This is going to sound somewhat cavalier :-), 
but as far as I'm concerned the RFC can really say whatever it wants.
Option 1 will be ignored entirely, 2 will be read but ignored, and 3
would be the pragmatic solution (or do 2+3, which seems the obvious 
one - tell people it's a bad thing, and provide an SMimeCap to allow
OAEP if people want it).

Peter.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Jul 2002 15:26:38 +0900

Peter, 

There is one large difference between TLS and CMS.  The TLS protocol has
already been modified to deal with the attacks on PKCS#1 v1.5, CMS has
not been modified to deal with these attacks.  Therefore I do not
necessarily think that the TLS conclusion on this is sufficient.

Jim

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]] 
> Sent: Wednesday, July 17, 2002 3:21 PM
> To: [email-masked]; [email-masked]
> Subject: Re: AES and PKCS #1 v1.5 Issue
> 
>

---

From: Dean Povey <[email-masked]>
Date: Wed, 17 Jul 2002 17:11:02 +1000

>necessarily think that the TLS conclusion on this is sufficient.

Well strictly speaking there was no modification to the TLS protocol
per se, only how implementations handle PKCS#1 padding failures... er well I 
guess that kind of is a modification to the protocol.

Besides that, I agree with Peter.  The side-channel attacks in CMS have to
be addressed anyway, because people will support PKCS#1 for backwards
interoperability with existing implementations.  There is no problem with 
S/MIME (as you have no random oracle), and the same is most likely true 
for any other CMS based application.

It would be much better to make OAEP a SHOULD and give the appropriate
recommendations to avoid side-channel attacks for the PKCS#1 stuff (and any
of the various other side-channel attacks e.g. timing analysis, Vaudenay
attack on CBC, etc).  There is a lot of infrastructure already heavily
invested in PKCS#1, some of which (like hardware accelerators for example)
will take a while to change.

Dean.

-- 
Dean Povey,             |em: [email-masked]|JCSI: Java security toolkit
Wedgetail Communications|ph:  +61 7 3023 5139   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: +61 7 3864 1282   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures