Subject: [ietf-tls] WG Last Call for "AES Ciphersuites for TLS"

From: Win Treese <[email-masked]>
Date: Wed, 30 May 2001 09:36:00 -0400

This is LAST CALL for comments on advancing the draft "AES
Ciphersuites for TLS" to Proposed Standard. The last call period is
two weeks for the working group. 

The current draft is draft-ietf-tls-ciphersuite-03.txt and is at
http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt
ftp://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt

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: Wed, 30 May 2001 12:00:08 -0400

On the 8th of May, I requested that RSA-OAEP be used with AES.  The 
proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like 
to see this changed.

I have spoken at the SAAG to encourage a common set of algorithms and modes 
throughout the IETF Security Area.  I realize that such a lofty goal cannot 
be archived overnight, but I do believe that we can make steady incremental 
improvement.  Here is one opportunity.  The S/MIME working group is on 
track to mandate the use of RSA-OAEP with AES, so we have a real 
opportunity to achieve significant commonality.

Again, I urge the TLS working group to the use of RSA-OAEP with AES.

Russ

---

---

From: David Hopwood <[email-masked]>
Date: Thu, 31 May 2001 00:38:36 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like

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.

The disadvantage of switching to OAEP, is that firmware for TLS hardware
accelerators would probably have to be changed. For that reason I would not
be in favour of switching, at least for the AES ciphersuites. Instead, the
RSA AES ciphersuites should say that the method in section 7.4.7.1 of
RFC 2246 MUST be followed.

(Note that currently, not all TLS implementations use that method. For
example, last time I looked, OpenSSL just checked for additional redundancy,
which makes Bleichenbacher's attack more difficult, but is not provably
secure.)

[Shoup01] Victor Shoup,
          "A Proposal for an ISO Standard for Public Key Encryption,"
          February 13, 2001.
          Available from http://www.shoup.net/papers/ or
          http://citeseer.nj.nec.com/shoup01proposal.html

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: Dean Povey <[email-masked]>
Date: Thu, 31 May 2001 16:24:39 +1000

>> proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like

<David's discussion snipped>

I have been lurking so I may have missed all the issues. Isn't the simplest
solution to just consider RSA-OAEP a different algorithm to RSA (w/PKCS#1 pad),
keep the existing identifiers and add the following:

CipherSuite TLS_RSA_OAEP_WITH_AES_128_CBC_SHA      = { 0x00, 0xXX };
CipherSuite TLS_DH_RSA_OAEP_WITH_AES_128_CBC_SHA   = { 0x00, 0xXX };
CipherSuite TLS_DHE_RSA_OAEP_WITH_AES_128_CBC_SHA  = { 0x00, 0xXX };
CipherSuite TLS_RSA_OAEP_WITH_AES_256_CBC_SHA      = { 0x00, 0xXX };
CipherSuite TLS_DH_RSA_OAEP_WITH_AES_256_CBC_SHA   = { 0x00, 0xXX };
CipherSuite TLS_DHE_RSA_OAEP_WITH_AES_256_CBC_SHA  = { 0x00, 0xXX };

And so on..

This means you can have a path to migrate software over from PKCS#1 padding
to OAEP as they see fit.  When products catch up, you can quietly deprecate
the PKCS#1 padding.

Just a thought.
--
Dean Povey,         | e-m: [email-masked] | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120   | uPKI: C PKI toolkit for embedded
Security Unit, DSTC | fax: +61 7 3864 1282   |       systems
Brisbane, Australia | www: security.dstc.com | 

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 31 May 2001 13:54:11 +0100

David Hopwood wrote:

> 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).

Yes.  If the existing TLS padding scheme was vulnerable to attack I
would agree that it should be updated immediately.  As it is I don't
see any real urgency although it is something that we should aim
towards.  For that reason I tend to favour switching for TLS 1.1, but
not doing anything specifically for AES.

> The disadvantage of switching to OAEP, is that firmware for TLS
> hardware accelerators would probably have to be changed. For that
> reason I would not be in favour of switching, at least for the AES
> ciphersuites.

This is a good point.  I think I would still favour switching for TLS
1.1 though.  Standardising the way RSA is used does make things more
elegant, although IMHO it is a fairly low priority.

-- 
Pete

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 31 May 2001 16:18:53 +0100

Dean Povey wrote:

> I have been lurking so I may have missed all the issues. Isn't the
> simplest solution to just consider RSA-OAEP a different algorithm to
> RSA (w/PKCS#1 pad), keep the existing identifiers and add the
> following:

Yes this would work I guess.  This would probably be done best with a
separate RFC, since there is no reason to restrict ourselves to OAEP
with AES.  OAEP variants could be defined for any ciphersuites that we
were interested in.

-- 
Pete

---

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 31 May 2001 11:35:43 -0400

David:

I fear that you are missing the point of my posting.

I strongly believe that the IETF Security Area should be moving toward a 
common set of security mechanisms.  I gave a presentation at the August 
2000 SAAG meeting with this same message.

To add support for AES, all vendors must open up their crypto software, so 
this provides a unique opportunity to adjust other algorithms in the 
ciphersuite.

I am not disputing the countermeasures that make PKCS#1 v1.5 safe.

I am not advocating new techniques.  The recent work by Victor Shoup is 
very interesting, and it might become a standard.  However, I would not 
recommend adopting it until the ISO working group has finished their 
work.  As we all know, a sound submission to a standards development 
process usually gets altered in some way.

On the other hand, RSA-OAEP is being used in many areas.  VISA and Master 
Card were probably the early adopters in SET.  Since then, there has been 
considerable activity involving RSA-OAEP.  IEEE Std 1363-2000 includes 
RSA-OAEP.  The current draft of ANSI X9.44 includes RSA-OAEP. Japan's 
Cryptrec project is reviewing RSA-OAEP.  There are probably others that I 
am not ware of.

I am proposing a well studied, and reasonably well adopted technique as the 
successor to PKCS#1 v1.5 for TLS.

I am proposing an evolution to a stronger mechanism, in the same way that 
we are evolving to the stronger symmetric cipher.  We have an opportunity 
to adopt AES and RSA-OAEP across the entire IETF Security Area.  We should 
not miss this opportunity.

Russ

---

---

From: Eric Rescorla <[email-masked]>
Date: 31 May 2001 10:00:17 -0700

David Hopwood <[email-masked]> writes:
> accelerators would probably have to be changed.
David,

Due to the need to check the TLS version number and the SSLv2-rollback
protection padding, don't most implementations simply do a raw
RSA operation and then unpad in software? Do you know of an
accelerator that forbids this?

-Ekr

---

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 31 May 2001 14:10:12 -0400

>elegant, although IMHO it is a fairly low priority.

Since you believe that RSA-OAEP should be used in the future, why not 
define both PKCS#1 v1.5 and OAEP now, and warn implementors that the switch 
is coming.  This will allow a transition period.

Russ

---

---

From: David Hopwood <[email-masked]>
Date: Thu, 31 May 2001 17:59:14 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Dean Povey wrote:
> >> proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I
> >> would like to see this changed.
> 
> RSA (w/PKCS#1 pad), keep the existing identifiers and add the following:
> 

The DH[E]_RSA ciphersuites use RSA signing, not encryption. (There are
theoretical security problems with the RSA signing used in TLS, especially
with respect to resistance to compromise of hardware-based implementations,
but that's an entirely different issue, that I think should probably be
fixed in TLS 1.1.)

In any case, I don't see the point of adding TLS_RSA_OAEP_*. From a provable
security point of view, I re-iterate that RSA-OAEP in TLS would be no more
secure than PKCS #1 v1.5 with the fix from section 7.4.7.1 of RFC 2246.

- -- 

---