Subject: [ietf-tls] draft-ietf-tls-ntru-00.txt CipherSuite conflict

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Tue, 10 Jul 2001 11:46:34 +0100

I notice that there is a conflict in the CipherSuite namespace between the 
NTRU draft and the expired 
draft-ietf-tls-56bit-ciphersiutes-00.txt - dated April 13th 1999.

The new Draft defines:

   CipherSuite TLS_NTRU_NSS_WITH_RC4_128_SHA           = { 0x00, 0x61 } 
   CipherSuite TLS_NTRU_NSS_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x62 } 
   CipherSuite TLS_NTRU_NSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x63 } 
   CipherSuite TLS_NTRU_NSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x64 } 
   CipherSuite TLS_NTRU_RSA_WITH_RC4_128_SHA           = { 0x00, 0x65 } 
   CipherSuite TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x66 } 
   CipherSuite TLS_NTRU_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x67 } 
   CipherSuite TLS_NTRU_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x68 } 

The expired one defines:

   CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA     = { 0x00,0x62 };
   CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA      = { 0x00,0x64 };
   CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 };
   CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA  = { 0x00,0x65 };
   CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA            = { 0x00,0x66 };

I guess that this in itself is not an issue, however, OpenSSL has these 
defined in its' code

/* Additional TLS ciphersuites from 
draft-ietf-tls-56-bit-ciphersuites-00.txt
 * (available if TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES is defined, see
 * s3_lib.c).  We actually treat them like SSL 3.0 ciphers, which we 
probably
 * shouldn't. */
#define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5          0x03000060
#define TLS1_CK_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5      0x03000061
#define TLS1_CK_RSA_EXPORT1024_WITH_DES_CBC_SHA         0x03000062
#define TLS1_CK_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA     0x03000063
#define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_SHA          0x03000064
#define TLS1_CK_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA      0x03000065
#define TLS1_CK_DHE_DSS_WITH_RC4_128_SHA                0x03000066 

to compound this, the following line is just above

#define TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES    1

and. indeed, a vanilla openssl install returns the following from the "$ 
openssl ciphers -cipherlist EXPORT1024" command

EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EXP1024-RC4-MD5

Apart from any procedural issues about implementing drafts etc... I think 
there are two questions:

1) can we move the NTRU specs out of conflict ?
2) is publishing an RFC really the best way to reserve CipherSuite specs ?

Cheers,
Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
[email-masked]
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

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

---

From: Dr S N Henson <[email-masked]>
Date: Tue, 10 Jul 2001 12:43:11 +0100

> draft-ietf-tls-56bit-ciphersiutes-00.txt - dated April 13th 1999.
[stuff deleted]
> EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EXP1024-RC4-MD5

Its not just OpenSSL that implements these. They are also implemented in
Netscape and MSIE.

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: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Tue, 10 Jul 2001 14:08:44 +0100

Dr Stephen Henson Wrote:

>Its not just OpenSSL that implements these. They are also 
>implemented in Netscape and MSIE.

I wasn't trying to point a finger, just trying to explain that this wasn't 
an academic discussion, as there already was a major player in the SSL/TLS 
world which had ciphersuites enabled that conflict directly with a draft 
just published by the tls w/g.

(BTW my IE and NS seem to only advertise 62 and 64 from this list)

It seems to me that the act of registering number(s) for a ciphersuite 
should be more port number-esque.  Having seemingly sensible values in 
Internet Drafts can only cause confusion, no matter how many disclaimers 
are above or below.  Especially in cases like this, where the draft 
(draft-ietf-tls-56-bit-ciphersuites-00.txt) died so long ago  (is there 
any reason why it didn't become Informational ?) but has been widely 
implemented.

Cheers,
Paul

---

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 10 Jul 2001 09:44:05 -0400

Given the wide deployment, it seems that an Informational RFC is appropriate.

Russ

---

---

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Tue, 10 Jul 2001 15:09:21 +0100

>Given the wide deployment, it seems that an Informational RFC 

There's a copy here:

http://www.ford-hutchinson.com/~fh-1-pfh/draft-ietf-tls-56-bit-ciphersuites-00.txt

if anyone wants to adopt/revive it.

Cheers,
Paul

---

---

From: Win Treese <[email-masked]>
Date: Tue, 10 Jul 2001 14:43:56 -0400

Thanks for the notes about the 56-bit ciphersuites--I missed that
draft on my latest summary of assigned numbers.

We'll assign new ones for the NTRU draft, and I would like to see the
56-bit draft resurrected so we can take a look at it again.

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

---

---

From: "David Taylor" <[email-masked]>
Date: Wed, 11 Jul 2001 19:46:57 +1000

> #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5          0x03000060

draft-ietf-tls-srp-01.txt also uses 0x00 0x60:

CipherSuite   TLS_SRP_WITH_RC4_128_SHA          = { 0x00,0x5C };
CipherSuite   TLS_SRP_WITH_IDEA_CBC_SHA         = { 0x00,0x5D };
CipherSuite   TLS_SRP_WITH_3DES_EDE_CBC_MD5     = { 0x00,0x5E };
CipherSuite   TLS_SRP_WITH_RC4_128_MD5          = { 0x00,0x5F };
CipherSuite   TLS_SRP_WITH_IDEA_CBC_MD5         = { 0x00,0x60 };

I wrote about this a few months back, but didn't seem to get any concrete
answer on how to allocate cipher suite numbers in drafts.

You have to put something in there while it's in draft form, otherwise
implementations won't necessarily work together.

Regards,
David.

---

---

From: "Paul V Ford-Hutchinson" <[email-masked]>
Date: Wed, 11 Jul 2001 12:08:19 +0100

>implementations won't necessarily work together.

sure, and draft-ietf-tls-camellia-01.txt and draft-ietf-tls-ecc-01.txt 
both allocate 'x47' thru 'x4C'

The purist view is that nothing should be set in stone until it goes RFC. 
Clearly this approach is broken. 

- there could be a process, like IANA port registration, where the 
reservation of a number is separate to the specification of the use of 
that number.  This should ensure that there is no realistic probability of 
number re-use.

-  there could be a process where someone (Win ?) has to vet any draft 
that defines new CipherSuites (is it even possible to fit that into the 
I-D process ?)  and Win has a master list .  (this is pretty similar to 
the approach above - but with Win instead of IANA)

- there could be an agreement that all drafts specify private ciphersuites 
(xFF xhh) until they get published as RFC (My guess is that we would lose 
the concept of private ciphersuites pretty quickly).

- there could be an agreement that no draft specify any ciphersuite 
numbers.  But I think that would lead to even greater confusion.

- or we could decide that, after this heads-up, the problem is 
sufficiently well known by the groups that matter (NS, IE, OpenSSL, RSA, 
anyone else ?) that this won't happen again.

Paul

---

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Jul 2001 19:59:55 +0100

> anyone else ?) that this won't happen again.

Guess what? OpenSSL doesn't use the same numbers twice. But how does
that help?

It seems to me that you have two realistic alternatives:

a) Register all numbers, regardless of their status

b) Only allow experimental numbers that are _guaranteed_ to be reused
for experimental ciphersuites.

I vote for a), but it may require an address space extension, or at
least a future provision for one.

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: Eric Rescorla <[email-masked]>
Date: 10 Jul 2001 07:18:21 -0700

> if anyone wants to adopt/revive it.
I'd be willing to volunteer if noone elese wants to.

-Ekr

---