Subject: [ietf-tls] AES Ciphersuites: Progress

From: Pete Chown <[email-masked]>
Date: Mon, 6 Nov 2000 14:46:38 +0000

Okay, here are the outstanding two issues (as I see it).  I will start
with the easy one:

1.  ADH ciphersuite
-------------------

There seems to be support for including this, and no opposition.  I
think a good case has been made for including it in the standard.
Further, it appears to me that it should *not* be regarded as
deprecated, unlike the ones in the original TLS RFC.

I will, however, include a note reminding implementors to implement
some other kind of authentication mechanism.

2.  Interoperability
--------------------

It would be nice if two implementations of the AES draft could always
negotiate an AES ciphersuite.  The problem with this is that it
reopens the issue about which ciphersuites ought to be mandatory.

One option, of course, is to forget about interoperability.  We just
define a collection of new ciphersuites, and say that implementors
really SHOULD provide two of them.

I mentioned another option in my last email (although it wasn't my
idea to begin with).  This would require servers to support both
ciphersuites, but clients could choose to support only one.  This
would provide a smoother path to interoperability.

I realised afterwards that it might make more sense to require clients
to support both ciphersuites, but only require servers to support
one.  This way, in the web scenario, servers get to decide the
tradeoff between forward secrecy and processing cost.

The other option would be to pick a single ciphersuite that everyone
MUST support.  I really don't like this option.  According to
Microsoft and Netscape, customers would not accept a forward secrecy
ciphersuite.

On the other hand, suppose your threat model requires forward secrecy.
If the static RSA suite was a MUST, what are you supposed to do if you
fail to negotiate EDH?  If you abort the connection you are
non-compliant with the AES draft.  If you don't abort the connection
you are communicating with an inappropriately low security level.

Please could you have a think about these options and decide which
would be acceptable.  If none of these can achieve consensus we will
(I suppose) just have to drop the idea of interoperability.  In this
situation we would just define a collection of new ciphersuites and
implementations can offer them or not as they choose.

Finally, just to reassure everyone, I am not trying to declare
anything non-compliant with TLS.  "MUST" only refers to compliance
with the AES draft.  An implementation which failed to implement such
a "MUST" clause might still be a conformant to TLS.

Nelson Bolyard wrote:

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

I agree, actually (with one slight caveat).  I confused everyone with
what I said.  "MUST" was supposed to refer to compliance with the AES
draft, not compliance with the TLS RFC.

You will still be able to write a perfectly good TLS implementation
that doesn't implement AES.  In fact, if you implemented, for example,
the ciphers in the TLS draft plus TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
you would be compliant with the TLS RFC but not the AES draft.
Obviously I wouldn't advise anyone to do this, but I just include it
as an example.

The caveat is that you can quite legitimately support AES as an option

along with other ciphersuites.  In this case, you may still need to
support certain ciphersuites in order to achieve compliance *with the
AES draft*.

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

I know.  I really didn't want to reopen this issue!  It would be nice,
though, to guarantee that two implementations of the AES draft could
interoperate (without falling back to pre-AES ciphersuites).

-- 
Pete

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

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 6 Nov 2000 10:11:28 EST

> Okay, here are the outstanding two issues (as I see it).  I will start

The note from RFC2246 Appendix F reads:
 
"Warning: Completely anonymous connections only provide protection
          against passive eavesdropping. Unless an independent tamper-
          proof channel is used to verify that the finished messages
          were not replaced by an attacker, server authentication is
          required in environments where active man-in-the-middle
          attacks are a concern."

This is in conflict with the deprecation statement in Appendix A.5:

"  The following cipher suites are used for completely anonymous
   Diffie-Hellman communications in which neither party is
   authenticated. Note that this mode is vulnerable to man-in-the-middle
   attacks and is therefore deprecated.

   CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
   CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
   CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
   CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
   CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };"

My understanding is that the IESG required the deprecation statement
because there were no applications that properly validated the
finished messages.  Now that there are, the deprecation clause should
be removed the next time RFC 2246 is revised.

                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * [email-masked]

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 9 Nov 2000 14:44:47 +0000

No one has expressed any views about my "Progress" email.  I guess
either no one has any strong views or I've bored you all into
submission!  :-)

I suggest, then, that I produce another version of the draft.  This
will have an ADH ciphersuite (not deprecated).  Also it will require
servers to support one of static RSA and EDH.  It will require clients
to support both.

By "require" I mean that an application must support those
ciphersuites in order to comply with the AES draft.  Applications
which do not support those ciphersuites may still be perfectly good
TLS implementations.

This will ensure that two implementations complying with the AES draft
will always be able to negotiate an AES ciphersuite.  At the same
time, it allows servers to determine the proper trade-off between
performance and forward secrecy.  Hopefully this will satisfy the
objections of Netscape and Microsoft (please let me know whether this
is the case).

-- 
Pete

---

---

From: Dr S N Henson <[email-masked]>
Date: Thu, 09 Nov 2000 16:36:13 +0000

> either no one has any strong views or I've bored you all into

Probably like me, everyone was waiting for everyone else :-)

> servers to support one of static RSA and EDH.  It will require clients

Good. Does anyone want anonymous RSA? Just a thought since it fits in
the "low powered client" category and currently there is no anonymous
RSA ciphersuite in TLS at all AFAICS.

> objections of Netscape and Microsoft (please let me know whether this

IMHO this needs some clarification. Does this mean if a particular
library has an option to disable certain ciphersuites (as many do) and a
particular client configuration disables one mandatory algorithm then it
is non compliant?

Also on the client side. I can see reasons why a user might want to
disable static RSA on the client side and only permit EDH on security
grounds. Similarly low powered clients might want to disable EDH because
it is unusably slow.

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.

---