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

From: Bodo Moeller <[email-masked]>
Date: Fri, 1 Jun 2001 12:12:12 +0200

On Thu, May 31, 2001 at 11:35:43AM -0400, Housley, Russ wrote:

[...]
> On the other hand, RSA-OAEP is being used in many areas. [...]
> I am proposing a well studied, and reasonably well adopted technique as the 
> successor to PKCS#1 v1.5 for TLS.

RSA-OAEP is "well-studied" only as of the next CRYPTO conference.
The original security argument was recently found to be flawed [1], a
new proof relying on a stronger assumption was given later [2].
CRYPTO 2001 also has a paper "A Chosen Ciphertext Attack On RSA
Optimal Asymmetric Encryption Padding (OAEP) as Standardized In PKCS #1"
by James Manger.  I am not aware of any preprints of this one, or
of the details of the attack.  Anyone?

[1]  Victor Shoup: "OAEP Reconsidered". -- CRYPTO 2001, to appear.
     Preprint available from <URL: http://shoup.net/papers/> and
     <URL: http://eprint.iacr.org/2000/060/>.

[2]  Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval and Jacques Stern:
     "RSA-OAEP is Secure Under the RSA Assumption" -- CRYPTO 2001, to appear.
     Preprint available from <URL: http://eprint.iacr.org/2000/061/>.

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

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

---

From: Pete Chown <[email-masked]>
Date: Fri, 1 Jun 2001 13:11:00 +0100

Housley, Russ wrote:

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

It would be more "elegant" if the same mechanisms were used in all the
protocols.  It would also allow more code reuse.  Do you have other
reasons for supporting this?

You have convinced me that your idea is a good one, but only in the
sense of a long term goal.  I'm not sure why there is such a sense of
urgency about it.

> We have an opportunity 
> to adopt AES and RSA-OAEP across the entire IETF Security Area.  We should 
> not miss this opportunity.

Unfortunately for reasons of backwards compatibility, the RC4-128
ciphersuite is going to be in common use for the foreseeable future.
It is important to add AES because government work often requires it.
But (sadly) the AES ciphersuites are unlikely to be adopted overnight
by other people.  It won't be possible to get the majority of people
onto OAEP by piggybacking on the AES changes.

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

If you think that is a good approach, why not write a separate I-D?
That way, you could define OAEP versions of other ciphersuites, not
just AES.  Theoretically I could add those to my draft but I want it
to stay focused on AES rather than drifting into being a general TLS
revision document.

The other advantage of a separate I-D is that then the issues can be
debated separately.  If people object to the way AES is being
approached it won't hold up OAEP, and vice-versa.

(Of course, I'm not necessarily saying that I would support an OAEP
draft -- it would depend how the issue was approached.)

-- 
Pete

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Jun 2001 09:47:09 -0400

>reasons for supporting this?

No.  I believe that a set of well-studied algorithms can provide the core 
capabilities for IETF security protocols.  Of course, they will have to 
change over time to keep up with computing and analytical advances.  In the 
near future, I would like to see RSA-OAEP and AES as two of those core 
algorithms.

>sense of a long term goal.  I'm not sure why there is such a sense of

AES has created some momentum.  I would like to use that momentum to 
upgrade the rest of the core algorithms.  This can easily be done in a way 
that offers backward and forward compatibility, especially in a protocol 
like TLS where negotiation is built in.  It is more difficult in S/MIME 
where the originator has a large number of recipients to consider.

>onto OAEP by piggybacking on the AES changes.

I agree that adoption will be gradual and incremental.  If we do not 
include RSA-OAEP in the AES specification, then we are further delaying the 
start of that adoption process.

>approached it won't hold up OAEP, and vice-versa.

I would be willing to do so, but as I have already stated, I believe that 
it is important to take advantage of the momentum that AES has created.  My 
hope is that implementors will add RSA-OAEP and AES at the same 
time.  Then, as the implementations are deployed, the better algorithms see 
more use.

Russ

---

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 2 Jun 2001 02:55:28 (NZST)

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

>On the other hand, RSA-OAEP is being used in many areas.  

s/ignored/used/ 

(I guess you could also say that "OSI is being used in many areas" because
every book on networking and security I've ever seen has the mandatory picture
of the 7-layer model in it :-).

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

How many implementations of any of the above have you ever seen?  SET is
practically dead (except for a few Asian contries which don't have
Reg.E/Reg.Z), X9.44 may as well not exist for all the use it sees, and OAEP in
1363 isn't being used for much either.

>successor to PKCS#1 v1.5 for TLS.

The technique may be well-studied, but adoption is practically nonexistant.
That's not to say we shouldn't use it (requiring OAEP as part of the AES
upgrade sounds like a good move), but it's not a good argument for saying we
should use it.

Peter.

---

---

From: Eric Rescorla <[email-masked]>
Date: 01 Jun 2001 08:22:23 -0700

> >On the other hand, RSA-OAEP is being used in many areas.  
You mean s/used/ignored/, right? :)

> 1363 isn't being used for much either.
Even if SET were widely used, the OAEP in SET is reasonably different
from the OAEP we're using here, due to the need to pack the PAN into
the encryption block.

-Ekr

---

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 2 Jun 2001 03:28:21 (NZST)

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

>My hope is that implementors will add RSA-OAEP and AES at the same time.
>Then, as the implementations are deployed, the better algorithms see more use.

One thing which may be impeding this is that PKCS #1 is very easy to implement
while OAEP isn't.  Moving to AES is easy (grab Brian Gladman's reference
implementation and spend 10 minutes glueing into your existing code), however
there's no reference implementation for OAEP which means that everyone planning
to switch to it has to invest a considerable amount of effort into figuring out
what OAEP actually does (the P1363-style description is almost impenetrable to
anyone outside the P1363 WG) and then making sure that what they've implemented
is correct.  The lack of other implementations to test against doesn't help
(there are some test vectors floating around somewhere, although they're not
part of the PKCS #1 RFC so it's not even easy to check the code you've
written).

What could really help its adoption is a freely available reference
implementation to mirror the AES implementation.  Until then, with no installed
base, no easily-locatable test vectors, and a lot of work required to add it, I
can't see it taking off.

Peter (who started playing with an implementation ages ago but never finished
       it when he realised that doing so would be pretty pointless.  If I ever
       get time to finish it I'll make it freely available).

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Jun 2001 11:34:07 -0400

>of the 7-layer model in it :-).

I know of several implementations, but that is not really your 
point.  Interoperability is the point, and everyone uses PKCS#1 v1.5.  I 
would like to see us migrate to a better padding and encoding technique, 
one where the application does not need to include specific countermeasures 
to avoid the Million Message Attack.

I grant that PKCS#1 v1.5 with those countermeasures in the application is safe.

In my goal to see a common set of algorithms used in the IETF Security 
Area, I would like to select a symmetric key management algorithm that does 
not require each application developer to include application-specific 
countermeasures in their code.

I am asking for an evolution to the better padding and encoding technique...

>upgrade sounds like a good move), but it's not a good argument for saying we

Thanks for the support, I think...

Russ

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 01 Jun 2001 11:47:55 -0400

>base, no easily-locatable test vectors, and a lot of work required to add 

The current draft of X9.44 has several test vectors (in Annex D).  If we 
agree to go forward with RSA-OAEP, I will gladly repackage those test 
vectors into an Internet-Draft (to become an Informational RFC).

Russ

---

---

From: "Greg Stark" <[email-masked]>
Date: Fri, 1 Jun 2001 13:17:08 -0400

The OpenSSL project (www.openssl.org) has an implementation of RSA-OAEP.
It's available as a padding option to the RSA_public_encrypt() function in
the crypto library.

====================
Greg Stark
[email-masked]
====================

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: "IETF Transport Layer Security WG" <[email-masked]>
Sent: Saturday, June 02, 2001 3:28 AM
Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS"

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

---

---

From: Pete Chown <[email-masked]>
Date: Fri, 1 Jun 2001 18:29:22 +0100

Housley, Russ wrote:

> [ I wrote: ]

> near future, I would like to see RSA-OAEP and AES as two of those core 

I'm afraid I still don't see where the sense of urgency is coming
from.  There have been lots of ideas debated on this list over the
past year or so.  Some of them would be very beneficial, like the DNS
name extension.  However, the WG has limited time and so for better or
worse these ideas are "queued up" to be looked at in the future.

To be honest OAEP is not my top priority.  Sure, in an ideal world, we
would sort out a migration path, but there are far more important
things to worry about.  OAEP delivers no benefits to the end user.
Things like the DNS name extension would deliver an immediate tangible
benefit.  AES delivers a tangible benefit in a different way because
it allows TLS-based solutions to comply with government tenders.

> I would be willing to [ write a new I-D ], but as I have already
> stated, I believe that it is important to take advantage of the
> momentum that AES has created.

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.

It's taken nearly a year and a lot of frustration to get the AES draft
this far.  Of course, errors have to be corrected at any stage of the
process, but I don't think we should be adding extra material on.
People doing government contracts need AES ciphersuites ASAP.  So I
suggest we get AES through and consider other protocol enhancements
separately.

-- 
Pete

---

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 2 Jun 2001 06:07:43 (NZST)

Pete Chown <[email-masked]> writes:

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

Unfortunately what that means is that it's not going to be adopted (it's been
around (and ignored) for several years, without some incentive to adopt it this
won't change).  Russ' point is that if you're going to go through the trauma of
moving to AES you may as well switch to OAEP as well.  As an implementor I'm
not thrilled with having to put in a lot of work to implement something which
doesn't offer any practical advantages to what I've already got (the OpenSSL
implementation will help ease the pain), but like Y2K, the AES move is a good
excuse to upgrade various other bits and pieces at the same time.

Peter.

---

---

From: Eric Rescorla <[email-masked]>
Date: 01 Jun 2001 11:26:13 -0700

[email-masked] (Peter Gutmann) writes:

> Unfortunately what that means is that it's not going to be adopted
> (it's been around (and ignored) for several years, without some
> incentive to adopt it this won't change).  Russ' point is that if
> you're going to go through the trauma of moving to AES you may as
> well switch to OAEP as well.  As an implementor I'm not thrilled
> with having to put in a lot of work to implement something which
> doesn't offer any practical advantages to what I've already got (the
> OpenSSL implementation will help ease the pain), but like Y2K, the
> AES move is a good excuse to upgrade various other bits and pieces
> at the same time.
I agree with this in theory but it's going to be really irritating
if we add OAEP and then it turns out that there's some other thing
we need to replace it with. The title of Manger's paper as quoted
by Bodo thus makes me pretty nervous. I'd sure like to be certain
that OAEP was good before we shove it in.

-Ekr

---

---

From: Eric Murray <[email-masked]>
Date: Fri, 1 Jun 2001 12:04:52 -0700

> that OAEP was good before we shove it in.

Read Shoups paper ("OAEP Reconsidered", pointer was in
Bodo Moeller's email).  According to it, the OEAP security
proof has a hole in it.  He proposes an OEAP+ which has a better
proof.  If the only advantage to OAEP is it's proveable security
then it sounds like waiting would be a good idea.

I agree with Peter's post about implementing OAEP- it's a pain
in the ass especially with no test vectors.

Eric

---

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 04 Jun 2001 16:45:42 -0400

Bodo:

Optimal Asymmetric Encryption Padding (OAEP) can be combined with any 
trapdoor one-way function, not just the RSA function. However, it is 
typically combined with the RSA function, as in RSA-OAEP.

The original OAEP paper proved that OAEP provided a certain level of 
provable security, and conjectured that it provided a higher level of 
security. [1] shows that the conjecture does not hold for an arbitrary 
trapdoor one-way functions. [2] shows that the conjecture does hold when 
the trapdoor one-way function is RSA. The results to be presented at CRYPTO 
2001 thus confirm the security of RSA-OAEP. Please see 
http://www.rsalabs.com/rsa_algorithm/oaep_security.html for further discussion.

Manger's result confirms that an implementation of RSA-OAEP decryption must 
not reveal whether the first byte of the output of the RSA decryption 
primitive is 0. This point was previously observed in PKCS #1 v2.1 draft 2. 
The result is not an attack on RSA-OAEP itself as it does not affect 
correct implementations of RSA-OAEP. Manger has not released a preprint of 
his paper yet, but he has indicated in correspondence with RSA Laboratories 
that this synopsis may be shared with standards bodies.

Also, RSA-OAEP also does not raise any patent issues.

Russ

---

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 5 Jun 2001 14:39:00 +0200

On Mon, Jun 04, 2001 at 04:45:42PM -0400, Housley, Russ wrote:

> security.

Well, the original OAEP paper [3] showed that OAEP provides "plaintext
awareness" according to a certain definition that was changed by the
authors in later papers when they noticed that they had "forgotten to
supply the attacker with an [encryption] oracle" [4].  As Shoup [1]
showed, it is not likely that a similar security proof is possible
under the corrected definition of plaintext awareness.  (This problem
was overlooked by [4].)

[3] claims that

     [...] demanding awareness of a secure encryption scheme is asking
     a lot. In the random oracle model, we can show that a
     plaintext-aware scheme is non-malleable and also secure against
     chosen-ciphertext attack. We omit proofs of this, but the
     intuition is quite clear. For example, a chosen-ciphertext attack
     will not help because the adversary already "knows" the plaintext
     of any ciphertext y whose decryption she might request from an
     available decryption box.

Nothing of this (except for the fact that they omit proofs :-) is true
for the original definition of plaintext awareness used in [3].
The reason is quite simple: The OAEP paper uses a formalization of
"provable security" that does not really capture what the authors had
intended.  It is not as if they had just made a conjecture that turned
out not to be true.

As mentioned before, while the general security proof for OAEP is not
as much of a security proof as its authors had believed, RSA-OAEP was
recently rehabilitated by a new, more meaningful security proof [2].

[1]  Victor Shoup: "OAEP Reconsidered".  CRYPTO 2001, to appear.

[2]  Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval and Jacques Stern:
     "RSA-OAEP is Secure Under the RSA Assumption".  CRYPTO 2001, to appear.

[3]  Mihir Bellare, Phillip Rogaway:
     "Optimal Asymmetric Encryption -- How to Encrypt with RSA", 1994.

[4]  Mihir Bellare, Phillip Rogaway:
     "Minimizing the Use of Random Oracles in Authenticated Encryption
     Schemes", 1995.

> correct implementations of RSA-OAEP.

Thanks for the information on Manger's paper.

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Jun 2001 08:11:02 -0400

I think that this thread has gone off track.  I do not think that we should 
be discussing the level of study that a RSA-OAEP has received.  My any 
measure it exceeds the level of study that PKCS#1 v1.5 has received.

The countermeasures that are implemented around PKCS#1 v1.5 allow it to 
thwart the Million Message Attack.  This is great, as it allows the 
community to make a thoughtful transition instead of a hasty one.

The much discussed (on this thread) security proofs of RSA-OAEP illustrate 
that this algorithm has better properties than PKCS#1 v1.5.  It is my 
understanding that the structure of PKCS#1 v1.5 does lend itself to similar 
proofs.  Therefore RSA-OAEP is much more likely to remain safe in the face 
of a yet undiscovered attack.

I would like to see us be proactive.  Migrate to AES and RSA-OAEP together.

Russ

---

---

From: Eric Rescorla <[email-masked]>
Date: 08 Jun 2001 10:01:19 -0700

"Housley, Russ" <[email-masked]> writes:
> I think that this thread has gone off track.  I do not think that we
> should be discussing the level of study that a RSA-OAEP has
> received.  My any measure it exceeds the level of study that PKCS#1
> v1.5 has received.
> 
Russ,

My concern here is that in six months we'll be hearing from the
cryptographers that there's some new algorithm (NOAEP?)  that we
really should be using instead of OAEP.

As you say, the fact that we have countermeasures for 1.5 allows us to
make an orderly transition. Part of that orderly transition should be
convincing ourselves that there isn't something coming down the
pipeline that will force us to displace OAEP.

-Ekr

---

---

From: Mark Winstead <[email-masked]>
Date: Fri, 8 Jun 2001 13:26:54 -0400

> really should be using instead of OAEP.

Do OAEP, or don't do OAEP, but don't not do it because in six months there
might be a better algorithm. That's like saying you won't buy a computer
today because in a month or two you'll be able to get a faster, cheaper
computer. If you do that, you'll never replace that 100 MgHz 2 GB hard drive
machine on your desk. 

Mark Winstead
Senior Mathematician
NetOctave, Inc. 
P.O. Box 14824
RTP, NC 27709
919.463.9903 x328
[email-masked] <mailto:[email-masked]> 

---

---

From: Eric Rescorla <[email-masked]>
Date: 08 Jun 2001 10:55:41 -0700

Mark Winstead <[email-masked]> writes:

> Do OAEP, or don't do OAEP, but don't not do it because in six months
> there might be a better algorithm. That's like saying you won't buy
> a computer today because in a month or two you'll be able to get a
> faster, cheaper computer. If you do that, you'll never replace that
> 100 MgHz 2 GB hard drive machine on your desk.
This simply isn't a useful analogy.

We currently have something that does the job just fine (PKCS
#1). What OAEP offers over PKCS #1 is the claim that it's provably
secure. If that claim doesn't hold up then we shouldn't make the
replacement. Thus, we need to be reasonably confident that we're
not going to hear in 6 months that the OAEP security proofs are
flawed and that we need another construction.

-Ekr

---

---

From: Mark Winstead <[email-masked]>
Date: Fri, 8 Jun 2001 14:08:01 -0400

>flawed and that we need another construction.

But you've missed my point and reinforced it at the same time (and perhaps I
missed your original point). My point is rejection of a new algorithm
shouldn't be based on the possibility of a better algorithm later. The
criteria should lie elsewhere. 

I'm not arguing for OAEP. Just don't reject OAEP because of the possibility
of a better algorithm later. If the consensus is what we've got now gets the
job done and OAEP doesn't offer something making the bother of its inclusion
worthwhile, then don't add OAEP. 

Mark

---

---

From: Eric Rescorla <[email-masked]>
Date: 08 Jun 2001 11:39:38 -0700

Mark Winstead <[email-masked]> writes:
> But you've missed my point and reinforced it at the same time (and
> perhaps I missed your original point). My point is rejection of a
> new algorithm shouldn't be based on the possibility of a better
> algorithm later. The criteria should lie elsewhere.
>
> I'm not arguing for OAEP. Just don't reject OAEP because of the
> possibility of a better algorithm later. If the consensus is what
> we've got now gets the job done and OAEP doesn't offer something
> making the bother of its inclusion worthwhile, then don't add OAEP.
And my point is that I'm not yet convinced that OAEP is going
to do the job. I don't want to get half-way through OAEP standardization
and then hear from some cryptographer that OAEP isn't secure
and we have to go to some new algorithm. I'd rather take a little
more time and make sure that OAEP is going to do the job.

-Ekr

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Jun 2001 16:14:54 -0400

>pipeline that will force us to displace OAEP.

I certainly welcome the review.  And, I suggest that we roll out whatever 
is selected after that review at the same time that AES is rolled out.

Given the recent postings by Hugo, we might want to look at a mode of AES 
that provides confidentiality and integrity all in one.  Such a mode 
eliminates the concerns about the order of MAC and encrypt operations.

Russ

---

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 08 Jun 2001 17:16:49 -0400

Eric:

I asked Burt Kaliski to comment.  Here is his reply:

    The RSA-OAEP security proofs are fine. RSA-OAEP's proofs of security
    have _improved_ since 1993. The issues, if any, are with OAEP for
    non-RSA uses, and those are primarily of theoretical interest. Yes,
    something better may come along, but RSA-OAEP is already in other
    (draft) standards (IEEE 1363, PKCS #1 v2.0, ANSI X9.44), and also under
    evaluation by NESSIE, Japan Cryptrec, ISO 18033, whereas the
    alternatives have yet to settle.

    Yes, PKCS #1 does the job just fine for resisting MMA with appropriate
    countermeasures, but it has no proof of security. There won't be another
    good opportunity to upgrade like this one. Why keep it around longer
    than necessary?

Much of this has already been said on this thread.  Burt's point that the 
issues with the OAEP proof history apply to arbitrary public key 
algorithms, not RSA is relevant.

Maybe we can get Phil Rogaway to chime in ...

Russ

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 08 Jun 2001 20:15:32 +0100

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

"Housley, Russ" wrote:
> be discussing the level of study that a RSA-OAEP has received.

Why on earth not? Are you seriously suggesting adopting RSA-OAEP in TLS
*without* discussing the level of study it has received? Besides, I've
found the thread very interesting.

> My any measure it exceeds the level of study that PKCS#1 v1.5 has received.
>
> that this algorithm has better properties than PKCS#1 v1.5.

But what they don't show (and in fact it is false) is that RSA-OAEP has
better properties than PKCS#1 v1.5 with the RFC 2246 fix. If the TLS PRF
is treated as a random oracle, it's fairly easy to prove in the random
oracle model that PKCS#1 v1.5 with that fix is as secure, in the sense
required, as RSA-OAEP would be (the proof is much the same as that of
Simple-RSA in Victor Shoup's ISO proposal [Shoup01]).

> It is my understanding that the structure of PKCS#1 v1.5 does lend itself
> to similar proofs.

I assume you meant "does not lend itself". However, we're not discussing
pure PKCS#1 v1.5; everyone agrees that is subject to an attack. The systems
we're comparing are RSA-OAEP and PKCS#1 v1.5 with the RFC 2246 fix. The
latter *does* lend itself to a security proof (in fact a simpler one than
the corrected RSA-OAEP proof, with a tighter reduction).

> Therefore RSA-OAEP is much more likely to remain safe in the face

No, I believe that's simply false. If there is a further attack on the
RSA ciphersuites, it would have to be something that is outside the
model in which RSA-OAEP is proven 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: Hugo Krawczyk <[email-masked]>
Date: Sun, 10 Jun 2001 16:47:40 +0300 (IDT)

On Fri, 8 Jun 2001, Housley, Russ wrote:

[......]

> eliminates the concerns about the order of MAC and encrypt operations.

The need for such all-in-one mode is not implied or justified by my new
results since, as the paper shows, we already have SPECIFIC modes in TLS
that are SECURE. There is nothing more secure in the proposed AES
all-in-one modes than in the currently used CBC and stream cipher modes as
defined and used in TLS.  The main problem I point to is the lack of
generic security in the design of TLS, and this is certainly NOT addressed
by the all-in-one modes.  Indeed, these modes are essentially dependent on
CBC and do not apply to any other form of encryption.

Thus, you may want to discuss addition of such a new mode based on
performance considerations (even though something such as RC4 plus
HMAC-MD5 is probably already faster than the new modes, and non-CBC
authentication. e.g. UMAC, just gets faster) but even then I wouldn't
sacrifice the more general modularity built into the protocol that allows
for the use of different forms of encryption, and supports
authentication-only when encryption is not really needed.

Note also my remark in the paper (end of the Introduction) about the fact
that the all-in-one modes authenticate and encrypt the exact same
information while security protocols usually include under the
authentication un-encrypted information too. In particular, in the case of
TLS message sequence numbers (which are not transmitted at all) are
included (and rightly so!) under the authentication.

Hugo

---

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 11 Jun 2001 09:04:58 -0400

>included (and rightly so!) under the authentication.

I spent a fair amount of time with your paper over the weekend.  I need to 
spend more.

After the reading the Introduction, I was pretty clear on the path for the 
TLS working group.  Nothing later in the paper has altered my view.

You point out that a cipher that is secure against chosen-plaintext attacks 
is not sufficient to provide all of the security that we expect in a 
security protocol that uses the AtE construct (SSL, TLS, and many 
more).  However, block ciphers in CBC mode and stream ciphers do provide 
the expected security.

I suggest that the best course of action is to document what properties the 
cipher must have (including being secure against chosen-plaintext attacks) 
for use with TLS.  Such guidance should keep people from defining 
ciphersuites that do not provide the expected security.

Russ

---

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 11 Jun 2001 10:01:20 EDT

> Simple-RSA in Victor Shoup's ISO proposal [Shoup01]).

I think that the discussion in this thread misses the primary
motiviation of Russ' request.  As long as RSA-OAEP is at least as
secure as PKCS#1 v1.5, Russ' suggestion should be taken seriously.
The point is not to look solely at TLS, but instead to look at the
suite of protocols developed within the IETF Security Area.  Not all
protocols implement a common suite of crypto algorithms.  By adding
RSA-OAEP to all protocols we can acheive uniform security and avoid
the political difficulties of convincing all groups a common algorithm
that results in more work for some groups than for others.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 13 Jun 2001 02:11:50 +0300 (IDT)

Russ, I would like to get your feedback when you are done reading the
paper. In the meantime see below for some comments on your note.

> ciphersuites that do not provide the expected security.

If TLS would use the encrypt-then-mac approach then the guidelines could
be very general: just use an encryption function secure against
chosen-plaintext attacks and a MAC secure against chosen message attack
(all reasonably secure encryption and mac functions, including all
standarized modes, are secure in the above senses).

However, as long as TLS uses the current mac-then-encrypt approach then
such generic guidleines are notpossible. In this case we can only be sure
about the two SPECIFIC modes currently defined in TLS:

(1) CBC mode as currently specified in TLS: i.e., a single CBC pass made
on the whole concatenation of plaintext and MAC (just for comparison:
computing CBC encryption on the plaintext and MAC *separately*, i.e. with
independent IVs, is enough to break the security)

(2) stream ciphers where the plaintext (fragments) are DIRECTLY xor-ed
with a pseudo-random pad (just for comparison: a simple encoding of the 
plaintext before xoring may be enough to break the security)

These SPECIFIC modes and processing are proven in the paper.
Any change, addition or departure from this processing requires a new
specific analysis (and not just for the "theoretical interest"). 
This is what needs to be made clear in the TLS document.

Hugo

---

---

From: "Gabriel Belingueres" <[email-masked]>
Date: Wed, 13 Jun 2001 09:19:29 -0300

On Wed, 13 Jun 2001 02:11:50  
>plaintext before xoring may be enough to break the security)

if an encoding on the plaintext could break security, then:

1) remove the compression functionality from the TLS rfc.

or

2) add a note about the issues raised by encoding the plaintext before encription.

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

Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/

---

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 13 Jun 2001 10:57:50 -0400

>paper. In the meantime see below for some comments on your note.

I am having a busy week, so it will not happen as soon as I would like.

>This is what needs to be made clear in the TLS document.

SSL and TLS are widely deployed, and changing mac-then-encrypt to 
encrypt-then-mac is not a trivial change.  In my view, it creates a whole 
new protocol.  Therefore, I would like to avoid such a change if we can 
find a way to characterize the algorithms and modes that are safe with the 
current protocol (especially since the widely implemented algorithms are safe).

Russ

---

---

From: David Blaker <[email-masked]>
Date: Wed, 13 Jun 2001 11:14:53 -0400

Russ,

We agree with your assertion that changing the order of authentication and
encryption effectively creates a new data plane protocol. It would also
further complicate the task of creating high-performance network security
processors. This point lends weight to the notion that we should limit the
number of ciphersuites to decrease the chances of creating security
problems.
_________________________________________
David Blaker, CTO
NetOctave, Inc.
P.O. Box 14824
Research Triangle Park, NC 27709
Phone (919) 463-9903 x.206 / Fax (919) 463-9905
email mailto:[email-masked]
website http://www.netoctave.com

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Wednesday, June 13, 2001 10:58 AM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS"

current protocol (especially since the widely implemented algorithms are
safe).

Russ

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

---

---

From: David Hopwood <[email-masked]>
Date: Wed, 13 Jun 2001 21:36:05 +0100

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

Gabriel Belingueres wrote:
> >such generic guidleines are not possible. In this case we can only be sure
> 2) add a note about the issues raised by encoding the plaintext before
> encryption.

In TLS, compression is a completely separate layer to the encryption/MAC,
so the output of compression is the plaintext in Hugo's security proof. In
particular, the MAC is on the compressed text, not the plaintext before
compression. Also, TLS aborts immediately on the first authentication
failure, so we can rely on the context that the decompression algorithm
uses having been authenticated. There's no security problem here; Hugo's
point about encoding doesn't apply in this case.

> >This is what needs to be made clear in the TLS document.

I completely agree that this should be pointed out in the next revision,
although I don't think RFC 2246 needs to be revised right now because of
this.

- -- 

---

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 14 Jun 2001 19:43:55 +0300 (IDT)

Russ,

> current protocol (especially since the widely implemented algorithms are safe).

I have no problem with this view of yours.
Although my paper raises questions about the robustness and genericity
of the TLS design it also shows the current specification to be secure
(something that turned out to be much less obvious that one could think)

However, I do not have a simple characterization of the good algorithms
and modes as you ask for (it is actually an open question stated in the
paper to find such a simple and useful characterization). As I said
before: you can say that what is NOW in TLS is good. This is so as long 
as your block cipher is secure and your processing is exactly as
defined in TLS. Similarly, in the case of stream cipher, if all the
cipher does is to produce a secure pseudo-random pad and xor it with the
data (without further processing of the plaintext).

But if you want to change to a different mode, to a different proecessing
of the encryption, to random IV per-message, to an unauthenticated
encoding of the message, or who knows what other idea, then you have to
re-analyze the protocol.

Hugo

PS: An answer to some other message: there is no problem with TLS
compression. When I said that encoding of plaintext before encryption
may be problematic (as some examples show) I was referring to an
encoding that is part of the encryption algorithm and then not
authenticated under the MAC. An encoding that is done before the MAC is
applied (such as the case of compression) is fine.

---