Subject: [ietf-tls] WG Last Call: Proposed New Charter for TLS Working Group

From: Win Treese <[email-masked]>
Date: Tue, 26 Sep 2000 11:47:17 -0400

This is a Working Group Last Call on the proposed new charter for the
TLS working group. The Last Call period will close in one week, on
Tuesday, October 3, 2000. If there are no significant objections, I
will then forward it to the IESG.

Since there has been little discussion of the new charter proposal
since it was originally posted, it seems acceptable to the working group.

Note that if we find the need to make incompatible or substantial
changes for sound technical reasons, we will cycle the specification
in grade at Proposed Standard. The milestone below indicates that we
are driving to Draft, but that will change if needed. I am not aware
of any such changes in the works, however.

Here again is the proposed charter:

    The TLS Working Group was established in 1996 to standardize a
    "transport layer" security protocol. The workking group began with SSL
    version 3.0, and in 1999, RFC 2246, TLS Protocol Version 1.0 was
    published as a Proposed Standard. The working group has also published
    RFC 2712, Addition of Kerberos Cipher Suites to Transport Layer
    Security (TLS) as a Proposed Standard, and two RFCs on the use of TLS
    with HTTP.

    The primary purpose of the working group is to advance the TLS
    Protocol to Internet Standard. In addition, the working group will
    publish documents defining new ciphersuites for use with TLS as
    needed.

    Milestones

    Nov 2000	First revised draft of TLS specification
    April 2001	Submit specification to IESG for consideration as
		Draft Standard

Win Treese
TLS WG chair
[email-masked]

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

---

From: "David P. Kemp" <[email-masked]>
Date: Tue, 26 Sep 2000 12:55:48 -0400 (EDT)

Is there not a plan to develop (under charter) a general-purpose TLS
extension mechanism?  Extensions are a long-term good because they
isolate the base specification from many (but not all) "substantial
changes for sound technical reasons".

If the addition of an extension mechanism is itself reason to cycle
back to Proposed, and if the mechanism is eventually needed, then it
would be better to define it sooner rather than later.

Dave

> To: "IETF Transport Layer Security WG" <[email-masked]>
> From: Win Treese <[email-masked]>
> Subject: [ietf-tls] WG Last Call: Proposed New Charter for TLS Working Group
> Date: Tue, 26 Sep 2000 11:47:17 -0400
> List-Subscribe: <mailto:[email-masked]>
> List-Owner: <mailto:[email-masked]>
> X-List-Host: Certicom <http://www.certicom.com/>
> X-Message-Id: <[email-masked]>
> X-List-Host: SKYLIST.net <http://www.SKYLIST.net/>
> 
> 
> You are currently subscribed to ietf-tls as: [email-masked]
> To unsubscribe send a blank email to 
[email-masked]
> 
> 
> *****************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> ******************************************************************************

---

---

From: [email-masked] (Nelson Bolyard)
Date: Tue, 26 Sep 2000 10:10:30 -0700

How about also driving the numerous new ciphersuites that are now
defined only in internet drafts (some of which are expired, IIRC)
to Internet Standard RFCs?

We now have a situation where numerous products (e.g. a couple of 
well known browsers from different companies) implement some of 
those draft-only ciphersuites (e.g. the 56-bit ciphersuites).  

It seems desirable for TLS to avoid falling into the same trap that
beset SSL, namely where no true standard exists that documents the 
widely implemented practice.  The way to do that is to keep the 
standards producing process in sync with the deployments, IMO.

--
Nelson Bolyard               Sun / Netscape Alliance
Disclaimer:                  I speak for myself, not for Netscape

---

---

From: Eric Rescorla <[email-masked]>
Date: 26 Sep 2000 10:35:28 -0700

> standards producing process in sync with the deployments, IMO.
The 56-bit cipher suite strike me as a special case, since
they're no longer really necessary. I'm not sure it's worth
taking them to RFC.

That said, I agree with your general point, with the caveat
that the cipher suites we standardize should be those for
which there is a lot of interest. I'm not particularly interested
in seeing a lot of proliferation of RFCs for cipher suites
that are only used internally by a few organizations.

-Ekr

---

---

From: Pete Chown <[email-masked]>
Date: Wed, 27 Sep 2000 09:55:58 +0100

> to Internet Standard RFCs?

Following the advice of people on the list, I am waiting for the AES
process to finish before I try to push my draft forward to the next
stage.  However, I agree that this should be an objective.

I'm wondering actually if the draft should only define new
ciphersuites for the AES winner; in other words no Blowfish and none
of the other AES finalists.  Hopefully something smaller, like this,
would make it easier to get the necessary consensus.

-- 
Pete

---

---

From: Dr S N Henson <[email-masked]>
Date: Wed, 27 Sep 2000 13:21:39 +0100

> would make it easier to get the necessary consensus.

Does the current draft include a blowfish cipher suite if so where can
I download it? 

I'm in favour of including blowfish. In the OpenSSL groups at least
there is considerable demand for one.

Some organisations avoid certain symmetric ciphers which have trademark
or patent issues, that is RC2, RC4 and IDEA. Currently AFAICS the only
official symmetric ciphers left are DES and 3DES with 3DES being the
only strong cipher. Not ideal and they'd like something else as well.

AES would indeed fit the bill when the winner is announced and when
enough implementations exist. 

However restricting the available cipher suites available forces those
who wish to use non standard ciphers to use "experimental" versions
which are painful when two independent implementations want to interop.

IMHO its better to have a standard for such things even if they are
rarely used.

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: "Jan Mikkelsen" <[email-masked]>
Date: Wed, 27 Sep 2000 23:14:18 +1100

David P. Kemp <[email-masked]> wrote:

> ... Extensions are a long-term good ...

I (naturally) agree.  (I have not forgotten the changes to the extension
mechanism;  I'll write those up over the next week.)

Jan Mikkelsen

---

---

From: Win Treese <[email-masked]>
Date: Thu, 28 Sep 2000 09:24:39 -0400

What I'd like to do is get the AES ciphersuites defined and moving
on the standards track as soon as possible. We can do something
with the other finalists (as with any other ciphersuite) separately.

     - Win Treese

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

---

---

From: Win Treese <[email-masked]>
Date: Thu, 28 Sep 2000 09:23:05 -0400

There is no I-D specifying a Blowfish cipher suite yet. 

If one is submitted, at some point we'll decide whether to progress
it on the standards track or publish it as an Informational RFC.

   - Win Treese

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 28 Sep 2000 19:01:54 +0100

> with the other finalists (as with any other ciphersuite) separately.

Okay, thanks for that pointer.  I have adjusted my original draft so
that it only refers to the AES.  It is available from:

ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-aes.txt

Please let me know what you think.  Constructive and destructive
criticism always welcome...  :-)

Note that the document is written as though the AES process had
already finished, and it assumes that there will only be one winner.
For these reasons, I think it would be inappropriate to move it to RFC
status until a winner is announced.  Presumably this will be very
soon, however, if NIST keep to their timetable.

In case anyone wants to compare, the original draft is also available
in the tls-aes-drafts directory.

-- 
Pete

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 29 Sep 2000 04:27:57 +0100

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

> Network Working Group                                         Pete Chown
> INTERNET DRAFT                                        Skygate Technology
> <draft-ietf-tls-ciphersuite-00.txt>                    28 September 2000
> 
>                         AES Ciphersuites for TLS
> 
> Status of this Memo
[snip]
> 
> Overview
> 
>      At present, the symmetric ciphers supported by TLS are RC2, RC4,
>      IDEA and triple DES.

and single DES.

>      The protocol would be enhanced by the addition of AES ciphersuites,
>      for the following reasons:
> 
>      1.  RC2, RC4 and IDEA are all subject to intellectual property
>          claims.  RSA Security Inc has trademark rights in the names RC2
>          and RC4, and claims that the algorithms themselves are trade
>          secrets.  Ascom Systec Ltd owns a patent on the IDEA algorithm.

RC2 has been published (RFC 2268), so it would be more accurate to say:

>                   RSA Security Inc has trademark rights in the names RC2
>          and RC4, and claims that the RC4 algorithm itself is a trade
>          secret.

However, the trademarks are hardly relevant, since they don't prevent
anyone from implementing these algorithms (note that MD5 is also a
trademark). Also, the fact that RC4 has not been published as such is
not particularly important, because those ciphersuites can be defined in
terms of alleged-RC4, which is obviously not a trade secret.

A better reason for not considering RC2 sufficient is that it is only
used in export (40-bit and 56-bit) ciphersuites. A better reason for not
considering RC4 sufficient, is that the public cryptographic community has
more experience in analysing the security of block ciphers than stream
ciphers.

Despite that, I think it would be a good idea to also include

       CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00, 0x66 };
       CipherSuite TLS_DHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x67 };

in the draft. The first of these was defined at the same time as the 56-bit
ciphersuites (although it is not an export ciphersuite). The second is new;
it's just the same thing for RSA signing keys.

>      2.  Triple DES is much less efficient than more modern ciphers.

Significantly less efficient, yes. Much less efficient is a bit too strong,
IMHO.

>      3.  Now the AES process is completed there will be commercial pres
>          sure to use the selected cipher.  The AES is efficient and has
>          withstood extensive cryptanalytic efforts.  The AES is there
>          fore a desirable choice.
> 
>      4.  Currently the DHE ciphersuites only allow triple DES (along
>          with some ``export'' variants which offer reduced key lengths).
>          At the same time the DHE ciphersuites are the only ones to
>          offer perfect forward secrecy.

There's an argument for calling this just "forward secrecy". Normally
"perfect" implies security against a computationally unbounded attacker,
which doesn't apply in this case.

>      This document proposes two new ciphersuites, with the aim of over
>      coming these problems.
> 
> Rationale
[snip; I agree with making these DHE ciphersuites]
> 
> Cipher Usage
> 
>      The new ciphersuites proposed here are very similar to the follow
>      ing, defined in [TLS].
> 
>      TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> 
>      and
> 
>      TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> 
>      Both the ciphersuites proposed in this document use either RSA or
>      DSS certificates.  They use the AES in cipher block chaining (CBC)
>      mode.  Furthermore, they use SHA-1 in an HMAC construction as
>      described in section 5 of [TLS].  (Although the TLS ciphersuite
>      names include the text ``SHA'', this actually refers to the modi
>      fied SHA-1 version of the algorithm.)
> 
>      The AES supports key lengths of 128, 192 and 256 bits.  At the pre
>      sent time, all of these are believed to be secure against even the
>      best equipped attackers.  The overall strength of TLS is such that
>      there is no gain from using a key length longer than 128 bits.

OTOH, there is no loss of speed from using 256-bit keys either (except
in the case of Rijndael). I'll have to have a look at the AES candidate
key schedules more closely, to see whether there would be any advantage
in using 256-bit keys (brute force attacks aren't significant for these
key lengths, but other attacks might be).

>      Accordingly the AES will use 128 bit keys.
> 
>      The new ciphersuites will have the following definitions:
> 
>      CipherSuite TLS_DHE_DSS_WITH_AES_CBC_SHA = { 0x00, 0x1C };
>      CipherSuite TLS_DHE_RSA_WITH_AES_CBC_SHA = { 0x00, 0x1D };

Those are already assigned (in [SSL3]):

       CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA         = { 0x00, 0x1C };
       CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00, 0x1D };

[SSL3] A. Frier, P. Karlton, and P. Kocher,
       "The SSL 3.0 Protocol",
       Netscape Communications Corp., Nov 18, 1996.
       http://www.netscape.com/eng/ssl3/

Note that SSL and TLS must share the same ciphersuite code space in order
for fallback from TLS to SSL to work correctly. The currently assigned
ciphersuite codes (all with 0x00 for the first byte) are 0x00..0x2B, and
0x62..0x66. (OpenSSL also implements 0x60 and 0x61 from the first draft
of the Microsoft 56-bit ciphersuite spec, even though those were never
standardised.)

Another minor nit is that for other ciphers with variable key lengths, the
key length (in bits) is included in the ciphersuite name. Therefore, I
suggest:

>      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x2C };
>      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2D };

Incidentally, had anyone noticed that TLS_KRB5_WITH_DES_CBC_SHA clashes with
SSL_FORTEZZA_KEA_WITH_RC4_128_SHA? They both have the code { 0x00, 0x1E }.

>      TLS implementations SHOULD implement the AES ciphersuites.

I'll discuss that in another long article I'm writing about how ciphersuite
negotiation affects security. It's quite complicated, because including more
than one key exchange algorithm in a client hello ciphersuites list can
only weaken security, whereas including more symmetric cipher/MAC combinations
may strengthen it in some cases.

> Security Considerations
> 
>      It is not believed that adding these ciphersuites will ever reduce
>      security.  The AES is believed to be secure, and it has withstood
>      extensive cryptanalytic attack.  The ephemeral Diffie-Hellman
>      ciphersuites provide perfect forward secrecy without any reduction
>      in security in other areas.
> 
> Copyright
[snip]
> Intellectual Property

This should include a reference to the IP statement for the AES winner
(available from NIST's website).

> References
> 
>      [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0" RFC-2246.
>      January, 1999.

and references for the AES winner should also be added (some are
listed for each of the candidates at
http://www.users.zetnet.co.uk/hopwood/crypto/scan/).

- -- 
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: Win Treese <[email-masked]>
Date: Thu, 28 Sep 2000 13:43:24 -0400

> isolate the base specification from many (tt not all) "substantial

There is not such a plan right now, although the proposed charter
doesn't rule it out. The charter is focused on advancing TLS on the
standards track, so now is the time for concrete proposals.

	  - Win Treese

---

---

From: Pete Chown <[email-masked]>
Date: Fri, 29 Sep 2000 19:15:03 +0100

David, thank you for spending so much time going through the
document.  I have made some changes in the light of your comments, and
produced a new version of the draft.  I have also altered the naming
on the FTP site to use the filename given in the document itself.  The
URL is:

ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/

> >      At present, the symmetric ciphers supported by TLS are RC2, RC4,

Fixed.

> >          and RC4, and claims that the RC4 algorithm itself is a trade

Fixed.

> terms of alleged-RC4, which is obviously not a trade secret.

This is true, but large companies may feel uneasy about getting
involved with these issues.  I agree that this is not a particularly
big deal though.

> more experience in analysing the security of block ciphers than stream

Hmm, that's an interesting one.  I've often thought myself that RC4 is
too simple to be really secure...  IMHO this type of comment does not
belong in the RFC, though.  I just want to explain briefly why the new
ciphersuites are desirable.

> it's just the same thing for RSA signing keys.

I think these ciphersuites make sense, along with Blowfish ones.
Unfortunately the goal at the moment seems to be to give the AES
ciphersuites priority.  I think once these ciphersuites are dealt with
it might make sense to create a new draft for others.

> Significantly less efficient, yes. Much less efficient is a bit too strong,

According to:

http://www.adfa.edu.au/~lpb/papers/auug98/

there is a factor of twelve between RC4 and triple-DES.  There is a
factor of nearly eight between Blowfish and triple-DES.  (The Blowfish
key setup is particularly slow though.)

It would be interesting to know what the comparative speeds would be
with carefully optimised versions of each algorithm.  This paper does
not really address this issue.

> which doesn't apply in this case.

Good point -- fixed.

> key lengths, but other attacks might be).

I've kicked this one backwards and forwards in my own mind.  My old
draft had 256-bit keys, but then I changed my mind when I thought
about the security of the rest of the system.

As far as I can see, 256-bit keys only become worthwhile if quantum
computing really takes off.  Then public key systems would be
essentially useless, and symmetric key systems would need twice the
key length.  Of course, this would destroy the security of TLS in any
case.

The other possibility is that the algorithm contains some weakness
that reduces the effective key length by some fixed amount.  In this
case longer keys might save the day.

I've no particularly strong views on this -- does anyone (else) have
any comments?

>        CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00, 0x1D };

I'm glad you spotted this one!  I've moved the new ciphersuites to
0x2F and 0x30.  This way they also avoid clashing with the the SEED
and HAS-160 draft.

> >      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2D };

Good idea -- I copied the 3DES ones, which have fixed key lengths.
Fixed.

> I'll discuss that in another long article I'm writing about how
> ciphersuite negotiation affects security. It's quite complicated,
> because including more than one key exchange algorithm in a client
> hello ciphersuites list can only weaken security, whereas including
> more symmetric cipher/MAC combinations may strengthen it in some
> cases.

I was asked before to make the new ciphersuites MUST, but following an
unrelated discussion on ietf-tls I realised that this wouldn't work.
We can't suddenly declare that existing TLS implementations are
non-compliant.  The other option would be for the AES ciphersuites to
be MAY, but the AES offers such a performance boost over the current
ciphers that (IMHO) this would be understating the case.

> (available from NIST's website).

Good point; I will add that once the winner has been announced.  The
latest draft contains a placeholder for this information.

> http://www.users.zetnet.co.uk/hopwood/crypto/scan/).

Again, I have added a placeholder for this information that will be
filled in later.

Apparently the AES winner is to be announced on Monday.  Should be a
stressful weekend for everyone who is in the final...  :-)

-- 
Pete

---

---

From: Eric Rescorla <[email-masked]>
Date: 29 Sep 2000 18:30:49 -0700

> I've no particularly strong views on this -- does anyone (else) have
Given the size of the asymmetric keys we're using 128 bits is
already massive overkill.

If you believe Lenstra's results (http://www.cryptosavvy.com/table.htm)
101 bits of symmetric key is equivalent to over 3000 bits of symmetric
key. 

I don't see any virtue in recommending 256-bit keys.

-Ekr

---