Subject: [ietf-tls] RE: New AES ciphersuites I-d

From: Pete Chown <[email-masked]>
Date: Thu, 2 Nov 2000 14:45:43 +0000

[email-masked] wrote:

> This way inter-operability is guaranteed (which it isn't by Pete's current
> formulation) ...

Yes, that is an important point.  I will have to address this in a new
draft.  Can anyone think of any other points that need to be
considered at the same time?

On this particular issue, then, I suggest that servers "MUST" support
RSA and DHE_RSA and "MAY" support the others.  Clients "MUST" support
*one of* RSA and DHE_RSA and "MAY" support the others.

-- 
Pete

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

---

From: Eric Rescorla <[email-masked]>
Date: 02 Nov 2000 07:19:28 -0800

> *one of* RSA and DHE_RSA and "MAY" support the others.
As I noted before, I don't beleive that we can impose new MUSTs here
without also incrementing the version number. This would have the
effect of making compliant implementations immediately noncompliant.

-Ekr

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 2 Nov 2000 16:00:27 +0000

> effect of making compliant implementations immediately noncompliant.

If an implementation doesn't implement one of the MUSTs, I mean that
it isn't compliant with my draft.  I don't mean that it isn't
compliant with TLS in general, or the original TLS RFC.  I will make
this clearer if you think it is going to give rise to confusion the
way it is at the moment.

-- 
Pete

---

---

From: Eric Rescorla <[email-masked]>
Date: 02 Nov 2000 08:14:01 -0800

> this clearer if you think it is going to give rise to confusion the
Fair enough. This seems perfectly reasonable.

-Ekr

---

---

From: Eric Murray <[email-masked]>
Date: Thu, 2 Nov 2000 08:10:57 -0800

> effect of making compliant implementations immediately noncompliant.

Yep.   A major change like that requires a new version number.

What's the reasoning for making DHE_RSA a MUST?  Forward
secrecy?  If so, why require it?  One of the goals of SSL was
to enable users to select the level of security that they need
without having a bewildering array of choices.  Sometimes
you don't need FS enough to want to do the extra crypto ops.
(if this topic was covered recently, my apologies for
bring it up again).

-- 
  Eric Murray           Consulting Security Architect         SecureDesign LLC
  http://www.securedesignllc.com                            PGP keyid:E03F65E5

---

---

From: [email-masked] (Nelson Bolyard)
Date: Thu, 02 Nov 2000 14:36:21 -0800

I've been given a rare opportunity to speak on behalf of Netscape to say this:

Netscape supports draft-ietf-tls-ciphersuite-01.txt as it is.

--
Nelson Bolyard

---

---

From: Peter W <[email-masked]>
Date: Thu, 02 Nov 2000 21:17:12 -0500

> (if this topic was covered recently, my apologies for

I think there's a general consensus on this mailing list that PFS, or at least some
sort of improved FS, should be used if it's feasible. And there's a growing
consensus that improved FS can be achieved without significant performance
penalties.

As for Pete requiring DHE on the server implementations but not the clients, I
think that's an attempt to break the chicken-and-egg problem we have now, where the
most popular servers and clients don't support FS suites. I would generally prefer
to require FS suites on both sides, but I suspect Pete is acknowledging that some
clients (like the anemic PalmOS devices many of us carry) may have have such
seriously constrained resources that it wouldn't be fair to force even slightly
more expensive suites on them.

As for users selecting security levels: in my experience, precious few have any
understanding of security implications beyond 128-bit > 56-bit > 40-bit. Everyone
I've talked to about the lack of forward secrecy in the strong RSA suites has a
reaction somewhere between moderate surprise and complete disbelief and utter
dismay at the situation. Users don't want choices so much as they want strong
security.

Requiring server applications to implement better FS doesn't get us as far as some
of us would like, but it's a good first step, and I am encouraged that Netscape has
voiced its support of this proposal. That's a great sign.

-Peter

--
This fall, taxpaying American citizens will elect voting representatives to
the US Congress. Except for those in Washington, DC. http://www.dcvote.org/

---

---

From: Ben Laurie <[email-masked]>
Date: Fri, 03 Nov 2000 09:45:30 +0000

> dismay at the situation. Users don't want choices so much as they want strong

Well, the advent of RIP in the UK is changing that somewhat over here -
it may not have trickled down to the average user yet, but it certainly
has reached the consciousness of the less technical civil libertarians
(who are mostly saying "you're kidding? SSL doesn't have PFS?
Really???").

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: Pete Chown <[email-masked]>
Date: Fri, 3 Nov 2000 10:59:06 +0000

Peter W wrote:

> As for Pete requiring DHE on the server implementations but not the
> clients, I think that's an attempt to break the chicken-and-egg
> problem we have now ...

Not altogether.  The problem is ensuring that a client and a server
which comply with the draft will interoperate.  For this to be
achieved they must have one ciphersuite in common.  For the original
TLS the "MUST" ciphersuite was TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

I do not feel that the AES analogue of this
(TLS_DHE_DSS_WITH_AES_128_CBC_SHA) is the best choice.  For one thing
the RSA patent has expired so we might as well use the de facto
standard RSA certificates.  Also there has been opposition to
requiring DHE ciphersuites.

In theory we could just require static RSA, but what about
applications where the threat model requires forward secrecy?  If
static RSA was a "MUST" we would in effect be saying that they have to
carry on functioning even though they haven't achieved the required
level of security.

I hope this finds some sort of middle ground.  It isn't perfect for
everything but I am hoping it is a reasonable compromise.

-- 
Pete

---

---

From: <[email-masked]>
Date: Fri, 3 Nov 2000 12:12:41 -0000

> *one of* RSA and DHE_RSA and "MAY" support the others.

I support this suggestion

tim

---

---

From: Eric Murray <[email-masked]>
Date: Fri, 3 Nov 2000 08:49:29 -0800

> dismay at the situation. Users don't want choices so much as they want strong

The "users" of the TLS spec aren't your run of the mill end-users-
they're the programmers who write TLS libraries, and the programmers
who use those libraries in server and client projects.

These users are expected to have some amount of knowledge of what they
are doing and why, and to then write something that will have strong
security for their end-users.  We already give programmers the choice
of using the anon_DH suites.  Used improperly, those are much less
secure than not having FS.  Yet, as you can see from other messages that
have been posted to the list recently, some programmers have managed to
use them in a way that's secure and satisfies their needs.

I agree with your reasoning for encouraging FS, but OTOH
I don't want to put in an unnecessarily high barrier for implementers
who knowledgably decide that they don't need FS.  A spec that requires
too much uneeded stuff winds up not being followed completely.

Is there any way to encourage TLS implementers to implement DHE_RSA
and programmers using TLS to include it, without making it a MUST?
How about making DHE_RSA a "SHOULD" and including a paragraph encouraging
it's use over plain RSA suites?

---

---

From: [email-masked] (Nelson Bolyard)
Date: Fri, 03 Nov 2000 13:58:24 -0800

Pete Chown wrote:
> 
> The problem is ensuring that a client and a server

But here is a case where market forces, not any standard, ensured
interoperability via a common cipher suite. One that wasn't the one 
named in the standard.  I think that situation will continue.  

Today, very few web sites use DES or 3DES, because of cost efficiency.
It takes more hardware to handle a certain number of transactions per day
with DES or 3DES than with ARCfour.  The only web sites known to me that 
routinely use DES or 3DES are either (a) government/defense sites that 
cannot use ARCfour because it's not a FIPS, or (b) little non-commercial 
sites that really want the extra security and have a low transaction rate 
(that is, sites for whom the cost doesn't matter).

In my opinion, (not speaking for anyone but myself), making ANY AES 
ciphersuite (regardless of its key exchange and authentication algorithms) 
a MUST is simply going to be ignored by most of the market.  The sites 
that use AES will be those that are required to use it (i.e., that are 
required to use only FIPS algorithms), or that aren't concerned about the 
cost of using the more expensive algorithm (in terms of CPU cycles).

So, perhaps it is worthwhile for a draft to state that SITES THAT ARE GOING 
TO USE ONLY AES ciphersuites MUST implement a particular one of them. 
But to state that offering a particular AES ciphersuite is a requisite of 
TLS compliance, or even a requisite of any server that offers any AES 
ciphersuite (in addition to non-AES suites), seems pointless to me.

For servers that are going to implement/offer AES cipher suites in addition
to others, I think the word "SHOULD" is the most reasonable word (adverb?)
to use in this document.  

IMO, the absence of the word MUST was an important consideration in 
Netscape's decision to state support for draft-ietf-tls-ciphersuite-01a.txt .

This is all just my personal opinion.
--
Nelson Bolyard               Sun / Netscape Alliance
Disclaimer:                  I speak for myself, not for Netscape

---

---

From: Eric Murray <[email-masked]>
Date: Fri, 3 Nov 2000 17:01:28 -0800

> Today, very few web sites use DES or 3DES, because of cost efficiency.

That's not what I found in my study- ~75% of the servers I surveyed
supported DES ciphersuites. 
(http://www.lne.com/ericm/papers/ssl_server_stats.html)

However many of those might support DES but prefer RC4 (supported
by 99+%).  I didn't record server preference.

> with DES or 3DES than with ARCfour.

DES is very efficient in h/w.  It's pretty easy to get crypto hardware
that can do DES in 1 round/cycle.  I have a set of specs here for a crypto
processor that's either shipping now or about to which does twice the 
bandwidth in 3DES than it does RC4. 

[..]

> to others, I think the word "SHOULD" is the most reasonable word (adverb?)

Even though I disagree with some of your supporting arguments, I
agree with your conclusion.  Requiring too much encourages
implementers to ignore parts of the standard.

---

---

From: [email-masked] (Nelson Bolyard)
Date: Fri, 03 Nov 2000 17:46:30 -0800

> by 99+%).  I didn't record server preference.

I think our positions are actually in agreement.  
I didn't say they don't _support_ it.  I said they don't USE it. 

They may _support_ DES but don't USE it, that is don't negotiate it, unless a
more
preferred ciphersuite, e.g. one that uses ARCfour, is not mutually supported.
And that almost never occurs.  I agree that ARCfour is used more than 99% of the
time.

> bandwidth in 3DES than it does RC4.

They can get special DES H/W, or they can just use more server systems in their
server farm.  Either way, it's more $$$ to achieve a certain transaction rate
with DES or 3DES than with ARCfour.

---