Subject: [ietf-tls] I-D cipher suite numbers

From: David Taylor <[email-masked]>
Date: Thu, 15 Mar 2001 22:44:23 +1100

Looking through the cipher RFCs and I-Ds for TLS, there are some conflicts in the numbering of the cipher suites.

The TLS standard uses the number up to 0x00,0x1D. The Kerberos cipher suites are next using 0x00,0x1E to 0x00,0x2B. Now, the AES and CAMELLIA cipher suites conflict, both starting at 0x00,0x2F. The AES cipher suites go to 0x00,0x34 while the CAMELLIA cipher suites go to 0x00,0x40. The CAMELLIA and MISTY cipher suites clash from 0x00,0x3B - 0x00, 0x40.

I suggest we renumber the cipher suites as follows (based on I-D date):

Base TLS as is
Kerberos as is
Camellia is as 
AES 0x00,0x41 - 0x00,0x46
MISTY 0x00,0x47 - 0x00,0x4C
SRP 0x00,0x4D - 0x00,0x53

How does that look?

Regards,
David.

---
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, 16 Mar 2001 11:40:34 +0000

> I suggest we renumber the cipher suites as follows (based on I-D date):

I would rather not revise the AES draft at the current time.  The
reason is that Win is currently looking at the mailing list exchanges
with a view to issuing a working group last call.  If the draft has to
be revised it is a nuisance.  It makes more work for Win, and it
causes delay because drafts cannot advance until they have been around
for a certain period of time.

(Actually the TLS draft predates the Camellia one; it has just been
revised more recently.  Not that this is an important consideration.)

BTW, I remember a while ago that there was concern about whether the
AES ciphersuites would comply with the FIPS.  I have looked at the
draft FIPS and as far as I can see the draft is compliant.

-- 
Pete

---

---

From: "Hidenori Ohta" <[email-masked]>
Date: Sat, 17 Mar 2001 00:04:32 +0900

David,

> SRP 0x00,0x4D - 0x00,0x53

When I updated my MISTY draft, I assumed the following:

TLS_RSA_WITH_SEED_CBC_MD5             = { 0x00,0x2C }
TLS_RSA_WITH_SEED_CBC_SHA             = { 0x00,0x2D }
TLS_RSA_WITH_SEED_CBC_HAS160          = { 0x00,0x2E }

TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F }
TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 }
TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 }
TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 }
TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 }
TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 }

TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x35 }
TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 }
TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 }
TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 }
TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 }
TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A }

TLS_RSA_WITH_MISTY1_CBC_SHA           = { 0x00,0x3B }
TLS_DH_DSS_WITH_MISTY1_CBC_SHA        = { 0x00,0x3C }
TLS_DH_RSA_WITH_MISTY1_CBC_SHA        = { 0x00,0x3D }
TLS_DHE_DSS_WITH_MISTY1_CBC_SHA       = { 0x00,0x3E }
TLS_DHE_RSA_WITH_MISTY1_CBC_SHA       = { 0x00,0x3F }
TLS_DH_anon_WITH_MISTY1_CBC_SHA       = { 0x00,0x40 }

TLS_RSA_WITH_CAMELLIA_CBC_128_SHA     = { 0x00,0x41 }
TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x42 }
TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x43 }
TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x44 }
TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x45 }
TLS_DH_anon_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x46 }

TLS_RSA_WITH_CAMELLIA_CBC_256_SHA     = { 0x00,0x47 }
TLS_DH_DSS_WITH_CAMELLIA_CBC_256_SHA  = { 0x00,0x48 }
TLS_DH_RSA_WITH_CAMELLIA_CBC_256_SHA  = { 0x00,0x49 }
TLS_DHE_DSS_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x4A }
TLS_DHE_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x4B }
TLS_DH_anon_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x4C }

TLS_KRB5_WITH_NULL_SHA                = { 0x00,0x4D }
TLS_KRB5_WITH_NULL_MD5                = { 0x00,0x4E }.

It contains SEED and CAMELLIA_256.  SEED's draft has been expired,
and CAMELLIA_256 does not appear in the draft yet.  And I remove
TLS_KRB5_WITH_NULL_NULL according to the discussion of the mailing
list.

But, I think the numbers themselves are not important whenever they do not
conflict with each other.

Regards,
--
Hidenori Ohta

---

---

From: David Taylor <[email-masked]>
Date: Sat, 17 Mar 2001 06:24:53 +1100

>for a certain period of time.

Well, given the number of cipher suites probably won't change right now I'll give the SRP ones the numbers I put in the last e-mail, and the others can swap around later if they want.

And you're saying this is a bad time to update the SRP draft? Or it won't matter for that one because its so new?

Regards,
David.

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Sun, 18 Mar 2001 22:30:58 -0500

Hi David,

I know it's a while back, but an old I-D specified ECC in TLS and used in
particular 47 through 5A. I know we've implemented some of these suites and I
wonder if  others may have as well. Since we've got a fair few numbers to play
with, and no-one else has actually claimed these numbers yet in a draft, I'd
like to suggest leaving a gap here to avoid the possibility of interop problems.

(I also submitted an updated ECC in TLS draft just before seeing your email that
uses these numbers so it'd save me having to go back and change!)

Is this possible?

(I also think it would be good to pin down the suite registration process to
avoid this kind of thing happening in the future ... for example a rule like "no
cipher suite numbers for new drafts til they reach RFC?)

Best regards. Simon

David Taylor <[email-masked]> on 03/15/2001 06:44:23 AM

Please respond to "IETF Transport Layer Security WG"
      <[email-masked]>

To:   "IETF Transport Layer Security WG" <[email-masked]>
cc:    (bcc: Simon Blake-Wilson/Certicom)
Subject:  [ietf-tls] I-D cipher suite numbers

Looking through the cipher RFCs and I-Ds for TLS, there are some conflicts in
the numbering of the cipher suites.

The TLS standard uses the number up to 0x00,0x1D. The Kerberos cipher suites are
next using 0x00,0x1E to 0x00,0x2B. Now, the AES and CAMELLIA cipher suites
conflict, both starting at 0x00,0x2F. The AES cipher suites go to 0x00,0x34
while the CAMELLIA cipher suites go to 0x00,0x40. The CAMELLIA and MISTY cipher
suites clash from 0x00,0x3B - 0x00, 0x40.

Base TLS as is
Kerberos as is
Camellia is as

How does that look?

Regards,
David.

---
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: Mon, 19 Mar 2001 11:23:34 +0000

David Taylor wrote:

> And you're saying this is a bad time to update the SRP draft? Or it
> won't matter for that one because its so new?

I only know about my own draft.  If others are in the same situation
then obviously I will be flexible about ciphersuite numbers.  What I
meant was that if AES is being finalised first, it makes sense for its
ciphersuite numbers to stay the same.

-- 
Pete

---

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 19 Mar 2001 14:39:49 +0100

> uses these numbers so it'd save me having to go back and change!)

I don't particularly like that old TLS-ECC draft (draft-ietf-tls-ecc-00.txt,
March 1998).  I'll first explain some of the things that I don't like
and then propose for consideration an approach that could help
avoid these problems.

First of all, do we really need all those ECC based key exchange
methods?  (draft-ietf-tls-ecc-00.txt defines ECES_ECDSA, ECES_ECNRA,
ECDHE_ECDSA, ECDHE_ECDSA_EXPORT, ECDHE_ECNRA, ECDHE_ECNRA_EXPORT,
ECDH_ECDSA, ECDH_ECNRA, ECMQV_ECDSA, ECMQV_ECNRA, ECDH_anon, and
ECDH_anon_EXPORT.)  Are there compelling reasons for keeping the
ECES_* and non-ephemeral ECDH_* methods (none of which can provide
forward secrecy) and for using two different ECC-based signature
schemes, ECDSA and ECNRA?

Removing ECES_*, ECDH_*, *_ECNRA and the EXPORT cipher suites would
leave us with ECDHE_ECDSA, ECMQV_ECDSA, and ECDH_anon.  In addition to
these, for practical reasons we really should have an ECDHE_RSA key
exchange method: First, everyone already has RSA certificates (... for
'historical reasons'?); and second, nothing beats RSA in terms of
signature verification efficiency, so ECDHE_RSA would be a quite
attractive key exchange method for weak clients.

Second -- and this is one of my reasons for trying to trim down the
number of key exchange methods defined in draft-ietf-tls-ecc-00.txt --
the ECC key exchange methods need to be defined with higher
granularity.  If a client announces in its ClientHello message that it
supports one particular ciphersuite of those defined in
draft-ietf-tls-ecc-00.txt (TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
say), then with the draft as it is now the client must be prepared to
be faced with curve definitions over any of GF(p) or GF(2^m) with ONBs
or GF(2^m) with 'trinomial' basis representation or GF(2^m) with
'pentanomial' basis representation.  The server can do with
implementing just one of these -- after all, it is the server that
gets to choose the curve --, but the client must be able to handle all
of these to ensure interoperability.  There is no way for the client
to say 'I can do ECDH_ECDSA, but only with curves over GF(p)' or 'only
using normal bases', and this makes draft-ietf-tls-ecc-00.txt pretty
useless for weak clients.

And if we add a curve type attribute to the cipher suite
specification, then the number of cipher suites grows by a factor of
four or so; and there still would not be a way for a client to say
that it can handle curves over GF(p), but only those where p is one of
the NIST primes.  (And what about new symmetric algorithms -- AES, the
new SHA variants?  We have only 16 bits for specifying a cipher suite,
and that's not much.)

This brings me to my proposal: What about defining 'a la carte' cipher
suites defined to use, e.g., *some* DH-style key agreement scheme with
parameters signed with *some* signature scheme; *some* symmetric
encryption algorithm; and *some* MAC algorithm, with a detailed list of
supported algorithms for each of these areas given in a
Hello extension, using the Hello extension framework defined by the
'wireless' draft?  If we use OIDs for specifying algorithms and
further details, such as fields and bases or even specific curves for
ECC-based algorithms, the TLS protocol immediately gains in
flexibility and extensibility.  (We still have to specify details
for individual algorithms, but algorithms defined in different
specifications can easily be combined: using ECC with AES does not
require an additional specification as it would now.)

We have to assign a couple of new ExtensionType values (in addition
to those already assigned by draft-ietf-tls-wireless-00.txt):

     ...
     key_agreement_algorithms(6),
     signature_algorithms(7),
     symmetric_encryption_algorithms(8),
     mac_algorithms(9),
     ...

The 'unknown-extension' fields for all of these extensions might
look like this:

     struct {
         AlgorithmSpec algorithm_spec_list<1..2^16-1>;
     } Algorithms;

     struct {
         opaque algorithm_oid<1..2^8-1>;
         AlgorithmAttribute algorithm_attribute_list<0..2^16-1>
     } AlgorithmSpec

     struct {
         opaque attribute<1..2^8-1>;
     } AlgorithmAttribute

In the easiest case, the algorithm_attribute_list field remains empty.
For algorithms such as ECDSA (identified by the usual ecdsa-with-SHA1
OID in the algorithm_oid field [in DER encoding, if this isn't
obvious]) or ECDH (is there a canonical OID for this yet?), we'd
specify that it may be left empty to indicate that any kind of curve
is OK; otherwise, it is a list of OIDs, where the 'prime-field' or
'characteristic-two' OIDs indicates that any curve over a prime field
or characteristic two field, respectively, is OK, where the 'gnBasis',
'tpBasis', and 'ppBasis' OID indicate that the client can handle
characteristic two curves of these specific kinds, and where curve
name OIDs indicate that the client can handle the respective curves.

For example, a client could use the 'prime-field' and 'c2tnb191v1'
OIDs (from X9.62) if it can handle any curve defined over GF(p), plus
the curve defined in App. J.4.3 of X9.62.

Some changes could be done to the above definitions to avoid
redundancy between attributes for key_agreement_algorithms
and signature_algorithms (e.g., ECDH and ECDSA -- likely
a client will support the same set of curves for both of these;
it should not have to send its list of curves twice).

The ServerKeyExchange message for ECDH should probably contain
a DER-encoded X9.62 'Parameters' object.  ASN.1:

Parameters ::= CHOICE {
    ecParameters ECParameters,
    namedCurve CURVES.&id({CurveNames}),
    implicitlyCA NULL
}

(I don't think we should allow 'implicitlyCA here'.  In any case, if
the server picked a specific curve that the client offered, then the
server should be required to specify this curve as a 'namedCurve'
instead of giving explicit 'ecParameters'.)

Proposal for TLS:

       struct {
           select (KeyExchangeAlgorithm) {
               case diffie_hellman:
                   ServerDHParams params;
                   Signature signed_params;
               case rsa:
                   ServerRSAParams params;
                   Signature signed_params;
               case a_la_carte:
                   opaque params<1..2^16-1>;
                   Signature signed_params;
           };
       } ServerKeyExchange;

    select (SignatureAlgorithm)
    {   case anonymous: struct { };
        case rsa:
                opaque md5_hash[16];
                opaque sha_hash[20];
            };
        case dsa:
            digitally-signed struct {
                opaque sha_hash[20];
            };
        case a_la_carte:
            opaque digitially-signed-struct<1.2^16-1>;
    } Signature;

There's no need for using DER for the server's public ECDH share, it's
just an OCTET STRING after all.  So 'params' could be either the
concatenation of the DER-encoded 'Parameters' with the point, or the
concatenation of the DER-encoded 'Parameters' with the DER-encoded
point, or maybe the former with an additional TLS 'opaque' layer
around the two components -- i.e., a length prefix for for each of
these two values.  The latter has the advantage that implementations
that support only specific curves can treat the OIDs of those as
blobs, thus avoiding the need to parse DER (at least in anon cipher
suites where there are no certificates to verify, or if certain
signature algorithm OIDs are used for indicating non-X.509 methods).

The above obviously is not yet a complete specification, but I think
the general idea should have become clear.  Example cipher suite
definitions for the above framework:

                           signature
                           algorithm                            
                               v

    CipherSuite TLS_alacarte_alacarte_WITH_alacarte_alacarte  = { 0xFF,0x00 };
    CipherSuite TLS_alacarte_anon_WITH_alacarte_alacarte      = { 0xFF,0x01 };

                      ^                    ^         ^
                key agreement           symmetric   MAC
                  algorithm             encryption

Comments?

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

---

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 19 Mar 2001 17:48:39 -0500

Hi Bodo,

Thanks for the ECC comments ... I hadn't realised a post about cipher suite
numbers would jump straight into ECC technical details!

As I said, I've posted an updated ECC draft in the last few days ... I hope it
addresses many of your concerns ... it should appear on the TLS WG page early
next week I believe. Please let me know if you agree or disagree!

On the extensions issue, I'd personally be in favour of using extensions to give
additional info about cipher suite support ... for example min & max key sizes
for DH/DSA, ECC, RSA. I'm not so convinced about the "template cipher suite"
suggestion where the actual algorithms are defined in an extension ... I think
we should leave the algorithm ids to the cipher suite itself.

Best regards. Simon

Bodo Moeller <[email-masked]> on 03/19/2001 08:39:49 AM

To:   "IETF Transport Layer Security WG" <[email-masked]>
cc:    (bcc: Simon Blake-Wilson/Certicom)
Subject:  [ietf-tls] Re: I-D cipher suite numbers

     ...

     struct {

     struct {

     struct {

Parameters ::= CHOICE {

Proposal for TLS:

       struct {

                           signature
                           algorithm
                               v

                      ^                    ^         ^

Comments?

--
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: David Hopwood <[email-masked]>
Date: Tue, 20 Mar 2001 05:58:33 +0000

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

Simon Blake-Wilson wrote:
> (I also think it would be good to pin down the suite registration process
> to avoid this kind of thing happening in the future ... for example a rule
> like "no cipher suite numbers for new drafts til they reach RFC?)

IMHO, this should be: "no cipher suite numbers until what is expected to be
the last draft before RFC".

- -- 
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: Ben Laurie <[email-masked]>
Date: Tue, 20 Mar 2001 09:50:34 +0000

> the last draft before RFC".

This makes interoperability testing more difficult, of course - it
should probably be "no non-experimental ciphersuite numbers..."

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

ApacheCon 2001! http://ApacheCon.com/

---