Subject: [ietf-tls] RSA-OAEP in draft-ietf-tls-ciphersuite-04

From: [email-masked] (Terry Hayes)
Date: Thu, 12 Jul 2001 11:19:05 -0700

Netscape would prefer that the current (PKCS #1 v1.5) RSA encryption 
mechanism is used in any new AES-based TLS ciphersuite.  We do not think 
it is appropriate to change the algorithm at this late stage (at final 
call of the draft).  The text from version -03 should be reinstated in 
this document.

The current RSA encryption mechanism should be retained for the 
following reasons:

1. Deploying AES-based ciphersuites is the primary goal

The AES block cipher provides a step up in security  from 3DES including 
true 128 bit (and larger) keys, and a larger block size.  At the same 
time, it provides increased performance across a wide set of platforms.  

The definitions of the AES ciphersuites should introduce only the new 
block cipher, not additional protocol or cryptographic mechanisms that 
would complicate or delay deployment of AES.  If OAEP has benefits for 
TLS it should be introduced as a separate ciphersuite using an existing 
and established encryption mechanism such as 3DES.

2. RSA-OAEP is not required for security

In message to this list on 31 May, David Hopwood said:

"Using OAEP with TLS makes effectively no difference to the provable security
properties of the RSA ciphersuites, assuming that the method described in
section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is replaced
with a random value whenever the PKCS #1 v1.5 block is invalid).

The effect of that method is to prevent chosen ciphertext attacks in much
the same way as the "Simple RSA" scheme described in [Shoup01], which has
a tighter reduction from the RSA problem than OAEP does. To get the same
tightness of reduction when using OAEP in TLS, you would still have to
require that no information is leaked about whether the decryption of the
premaster secret succeeds or not."

So it seems that OAEP adds no benefit for TLS, since the suggested 
method from RFC 2246 must be used in any case.

3. Adding RSA-OAEP adds complexity

Requiring RSA-OAEP for the AES ciphersuites means that implementations 
will need to provide both RSA padding schemes.  In some situations the 
extra code space and complexity won't be a problem, but some memory or 
performance contrained devices would be better off without both 
implemenations.  It is unlikely that AES-only deployments will be 
possible in the near term, so devices will need to implement both old 
and new methods for interoperability reasons.

4. Adding RSA-OAEP delays implementation

This requirement will delay the availability of the new ciphersuites for 
two reasons. First, the time to implement the OAEP padding will delay 
the availability of products with this capability.  Second, testing 
independantly developed products will take longer since the 
interoperability of both OAEP and the AES cipher will need to be tested.

5. Adding RSA-OAEP delays adoption of AES in hardware devices

Many services that use TLS rely on hardware devices to improve the 
performance of TLS or to provide additional security.  These hardware 
devices will need to be updated to provide both the AES cipher, and the 
new RSA-OAEP encryption mechanism.  Hardware updates are typically less 
frequent than updates for software packages, and

6. Alternatives to RSA (PKCS #1 v1.5) are available

The current ID proposes ciphersuites that use either static or ephemeral 
Diffie-Hellman for key exchange.  If a user is particularly concerned 
about attacks on PKCS #1 v1.5 (even though most experts agree that 
appropriate measures have already been taken), they can use one of the 
DH key exchange ciphersuites and avoid the question altogether.

For these reasons, Netscape would prefer to use the existing PKCS #1 
v1.5 padding for AES ciphersuites.

Terry Hayes
[email-masked] <mailto:[email-masked]>

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]