Subject: [ietf-tls] Last call: AES ciphersuites for TLS

From: Win Treese <[email-masked]>
Date: Fri, 20 Jul 2001 00:33:29 -0400

This is a working group Last Call for draft-ietf-tls-ciphersuite-04.txt
to be submitted to the IESG for Proposed Standard. It incorporates the
changes to use OAEP for RSA.

Because there were no other unresolved issues on this draft in the
original Last Call, this is a one-week Last Call.

Thanks,

Win Treese
Chair, TLS working group
[email-masked]

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

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Jul 2001 09:53:46 -0400

TLS WG:

Since I will be out of the office for the bulk of this Last Call, I wanted 
to post a message supporting the adoption of RSA-OAEP for use with AES.  I 
think that it is a major step toward the selection of an IETF-wide crypto 
algorithm suite that includes RSA-OAEP for key management and AES for 
encryption.

Russ

At 12:33 AM 7/20/2001 -0400, Win Treese wrote:

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

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Jul 2001 10:25:02 -0400

I agree with Bodo's point. If the same private key is used with both 
RSA-OAEP and PKCS #1 v1.5, it can be attacked via the weaker 
method.  However, this is not a reason to delay the introduction of 
RSA-OAEP; eventually the server can support just AES with RSA-OAEP.

Russ

 >Date: Fri, 20 Jul 2001 13:27:11 +0200
 >From: Bodo Moeller <[email-masked]>
 >To: "IETF Transport Layer Security WG" <[email-masked]>
 >Subject: [ietf-tls] Re: Last call: AES ciphersuites for TLS
 >
 >On Fri, Jul 20, 2001 at 12:33:29AM -0400, Win Treese wrote:
 >
 >As explained in the follow-up to David Hopwood's message (Re: AES,
 >OAEP, and TLS), I object to adding RSA ciphersuites with OAEP.
 >Having both PKCS #1 v1.5 encryption and OAEP ciphersuites enabled
 >in the same server cannot provide any security advantage and in
 >fact is more likely to make the system *less* secure than always
 >using PKCS #1 v1.5.
 >
 >The above concern would be resolved by using independent RSA keys for
 >different ciphersuites.  However, this would mean servers would need
 >additional certificates just so that they can use AES.  This would
 >mean a lot of extra effort and provide no advantages whatsoever
 >because TLS with PKCS #1 v1.5 encryption and the Bleichenbacher attack
 >countermeasure described in RFC 2246 is cryptographically sound.
 >
 >Instead of introducing OAEP, the AES ciphersuites should use RSA
 >encryption similar to existing ciphersuites.
 >
 >
 >--
 >Bodo Möller <[email-masked]>

---

---

From: Eric Rescorla <[email-masked]>
Date: 20 Jul 2001 08:24:11 -0700

> RSA-OAEP; eventually the server can support just AES with RSA-OAEP.
The probability that this will happen in the foreseeable future
is negligible.

While I think it's a laudable goal to have future IETF protocols share
a common suite of algorithms, I fail to see that any particular benefit
is achieved by imposing that suite on current protocols. I'm against
this change.

-Ekr

---

---

From: [email-masked] (Terry Hayes)
Date: Fri, 20 Jul 2001 09:25:38 -0700

I object to the changes that require OAEP padding for the AES ciphersuite.

My previous email (12 July) outlines my reasons for this position.  The 
goal of this draft should be to define AES ciphersuites that can be 
deployed soon.  Coupling that goal with changes in the RSA padding will 
only delay implementations and cause interoperability problems without 
providing any increased security.

Terry Hayes
Netscape Communications Corp.

Win Treese wrote:

>You are currently subscribed to ietf-tls as: [email-masked]

---

---

From: Dr S N Henson <[email-masked]>
Date: Fri, 20 Jul 2001 18:40:58 +0100

I am also opposed to the change to making OAEP mandatory for AES
ciphersuites. I agree with many of the objections already raised.

I have an additional issue. Crypto hardware with some form of private
key protection will have varying degrees of difficulty with OAEP. How
bad this is depends on the hardware in use and I don't claim to be
familiar with all variants. 

However typical issues might be:

1. The firmware cannot be upgraded and it only supports PKCS#1 v1.5
internally. 

2. Upgrading the firmware can only be done if the existing hardware
protected keys are destroyed.

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: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Jul 2001 14:27:55 -0400

>protected keys are destroyed.

This is not always the case. I have personally used devices that allowed 
the firmware to be updated without wiping out certificates or private keys 
that were stored in them.

I am sorry to hear that some hardware vendors were short sighted in this area.

Russ

---

---

From: Eric Rescorla <[email-masked]>
Date: 20 Jul 2001 11:52:51 -0700

> I am sorry to hear that some hardware vendors were short sighted in this area.
I'm not sure I consider this shortsighted. One of the claimed invariants
of such hardware is that the key cannot leave the device. Allowing
the firmware to be upgraded potentially violates this invariant. [0]

-Ekr

[0] Yes, I know you can have signed firmware and the like but you're
then depending on the future security of the signing key, among other
things.

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Jul 2001 15:57:03 -0400

Eric:

>the firmware to be upgraded potentially violates this invariant.
>
>Yes, I know you can have signed firmware and the like but you're

Interesting security policy.  However, it is quite difficult to repair a 
bug in this situation.  If I had a root key stored in such a device I would 
be quite upset if there was no way to repair a bug in the firmware without 
destroying the root key.

Russ

---

---

From: Ben Laurie <[email-masked]>
Date: Fri, 20 Jul 2001 21:35:15 +0100

> be quite upset if there was no way to repair a bug in the firmware without

How upset would you be if your root key became available to an attacker
because the "upgraded" the firmware?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 20 Jul 2001 17:41:20 -0400

>because the "upgraded" the firmware?

As Eric pointed out, there are ways to ensure that the firmware comes from 
the device manufacturer.

This discussion has gone way off topic.  We should talk about the TLS 
protocol and associated algorithms.  I will stop here.

Russ

---

---

From: Eric Rescorla <[email-masked]>
Date: 20 Jul 2001 15:01:29 -0700

> As Eric pointed out, there are ways to ensure that the firmware comes from 
Right, but imagine that the manufacturer makes two different kinds
of firmware, one of which permits key export and one of which does
not. Clearly you wouldn't want the "key export" firmware loaded
onto your previously secure box.

So, now we need some way of differentiating various kinds of 
firmware, which means that you need different hardware, some
of which can only run certain firmware.

This is getting pretty complicated.
-Ekr

---

---

From: Eric Rescorla <[email-masked]>
Date: 20 Jul 2001 14:48:21 -0700

> be quite upset if there was no way to repair a bug in the firmware without 
I agree that this is unfortunate, however it's consistent with 
what seems to me to be the general philosophy behind such hardware
crypto devices, namely that just about any amount of inconvenience 
is acceptable if it renders the system more secure.

-Ekr

---

---

From: Dr S N Henson <[email-masked]>
Date: Sat, 21 Jul 2001 01:27:48 +0100

> because the "upgraded" the firmware?

There's also the possibility of the manufacturer being forced to extract
keys from boxes via legal sanction. In this scenario the "attacker"
would be the manufacturer.

Some manufacturers, and indeed some customers, would want to be ultra
safe and have hardware from which keys cannot be extracted under any
(known) circumstances.

Steve.

---

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 21 Jul 2001 11:51:29 +0200 (CEST)

> the firmware to be upgraded potentially violates this invariant. [...]

As separate RSA keys should be used for RSA OAEP and RSA PKCS #1 v1.5
decryption (otherwise any OAEP "provable security" is void, anyway),
there would not be a need to upgrade the firmware used with existing
keys.  The simplest sound solution would be simply not to implement
those AES ciphersuites that require OAEP decryption.  (This leaves
availabe AES ciphersuites using RSA signatures.)

It would be a matter of minutes to implement OAEP-based ciphersuites
in OpenSSL such that a single RSA key is used for different styles of
RSA decryption; but I won't do this because it can make security only
worse, not better.  Using multiple RSA keys would be OK, but it's
hardly worth the implementation effort because few server operators
would bother to obtain an additional certificate for the additional
key.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 21 Jul 2001 13:46:33 +1200 (NZST)

"Housley, Russ" <[email-masked]> writes:

>This is not always the case. I have personally used devices that allowed the
>firmware to be updated without wiping out certificates or private keys that
>were stored in them.
>

That's not short-sighted, that's a good security precaution (in fact I'd be
rather suspicious of a device which allowed the firmware to be upgraded without
zeroising the cryptovariables).  What happens if I upgrage the firmware to a
new version which leaks the private key(s)?

(Some of the papers covering the IBM 4758 design go into this problem, and how
to avoid it, in some detail).

Peter.

---

---

From: Eric Rescorla <[email-masked]>
Date: 21 Jul 2001 07:36:33 -0700

Bodo Moeller <[email-masked]> writes:

> keys.
I was more thinking that one might have hardware which could supported
multiple keys and didn't wish to buy a separate piece of hardware. 
You'd need to upgrade the firmware in order to do OAEP at all but
you could then enforce the key separation in software.

-Ekr

---