From bounce-ietf-tls-3458737@lists.certicom.com Tue Sep 26 11:44:46 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11324 for ; Tue, 26 Sep 2000 11:44:45 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] WG Last Call: Proposed New Charter for TLS Working Group Date: Tue, 26 Sep 2000 11:47:17 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200009261547.e8QFlH601591@cirocco.openmarket.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net 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 treese@acm.org --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Sep 26 13:02:01 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12559 for ; Tue, 26 Sep 2000 13:02:00 -0400 (EDT) Message-Id: Date: Tue, 26 Sep 2000 12:55:48 -0400 (EDT) From: "David P. Kemp" Reply-To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group To: "IETF Transport Layer Security WG" MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +nd3wFVfrH8xv9GkOa9Ttg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200009261644.MAA10349@roadblock.missi.ncsc.mil> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net 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" > From: Win Treese > Subject: [ietf-tls] WG Last Call: Proposed New Charter for TLS Working Group > Date: Tue, 26 Sep 2000 11:47:17 -0400 > List-Subscribe: > List-Owner: > X-List-Host: Certicom > X-Message-Id: <200009261547.e8QFlH601591@cirocco.openmarket.com> > X-List-Host: SKYLIST.net > > > 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 > treese@acm.org > > > --- > You are currently subscribed to ietf-tls as: dpkemp@missi.ncsc.mil > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Sep 26 13:10:52 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12759 for ; Tue, 26 Sep 2000 13:10:50 -0400 (EDT) Message-ID: Date: Tue, 26 Sep 2000 10:10:30 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <39D0D886.468D36C2@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Sep 26 13:32:26 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13091 for ; Tue, 26 Sep 2000 13:32:25 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 26 Sep 2000 10:35:28 -0700 In-Reply-To: nelsonb@netscape.com's message of "Tue, 26 Sep 2000 10:10:30 -0700" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net nelsonb@netscape.com (Nelson Bolyard) writes: > 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. 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Sep 27 04:56:58 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06729 for ; Wed, 27 Sep 2000 04:56:57 -0400 (EDT) Date: Wed, 27 Sep 2000 09:55:58 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from nelsonb@netscape.com on Tue, Sep 26, 2000 at 10:10:30AM -0700 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20000927095558.D2791@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Nelson Bolyard wrote: > 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? 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Sep 27 06:33:09 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07625 for ; Wed, 27 Sep 2000 06:33:08 -0400 (EDT) Message-ID: From: olli.immonen@nokia.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Wor king Group Date: Wed, 27 Sep 2000 13:23:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <0B3F42CA1FB6D2118FE50008C7894B0A04B625C3@eseis06nok> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I support defining an extension mechanism, and having it stated in the charter. Many kinds of functionality would benefit from an extension mechanism. E.g. those that require a sort of capability negotiation between client and server: - client saying in Client Hello "I would to use a certain feature" - server confirming in Server Hello "Yes, I support this feature" /Olli > -----Original Message----- > From: EXT David P. Kemp [mailto:dpkemp@missi.ncsc.mil] > Sent: 26. September 2000 19:56 > To: IETF Transport Layer Security WG > Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS > Working Group > > > 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" > > From: Win Treese > > Subject: [ietf-tls] WG Last Call: Proposed New Charter for > TLS Working Group > > Date: Tue, 26 Sep 2000 11:47:17 -0400 > > List-Subscribe: > > List-Owner: > > X-List-Host: Certicom > > X-Message-Id: <200009261547.e8QFlH601591@cirocco.openmarket.com> > > X-List-Host: SKYLIST.net > > > > > > 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 > > treese@acm.org > > > > > > --- > > You are currently subscribed to ietf-tls as: dpkemp@missi.ncsc.mil > > To unsubscribe send a blank email to > leave-ietf-tls-3458737E@lists.certicom.com > > > > > > > ************************************************************** > *************** > > This confirms that this email message has been swept by > > MIMEsweeper for the presence of computer viruses. > > > ************************************************************** > **************** > > > --- > You are currently subscribed to ietf-tls as: olli.immonen@nokia.com > To unsubscribe send a blank email to > leave-ietf-tls-3458737E@lists.certicom.com > --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Sep 27 08:15:25 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09847 for ; Wed, 27 Sep 2000 08:15:24 -0400 (EDT) Message-ID: Date: Wed, 27 Sep 2000 13:21:39 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <39D1E653.D27D6258@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > Nelson Bolyard wrote: > > > 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? > > 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. > 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: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Sep 27 08:19:37 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09963 for ; Wed, 27 Sep 2000 08:19:36 -0400 (EDT) Message-ID: From: "Jan Mikkelsen" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Date: Wed, 27 Sep 2000 23:14:18 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <003401c0287c$76568010$0901a8c0@haym.transactionsite.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David P. Kemp 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Sep 28 09:30:05 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19888 for ; Thu, 28 Sep 2000 09:30:03 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group In-reply-to: Message from Pete Chown of 27 Sep 2000 9:55:58 BST Date: Thu, 28 Sep 2000 09:24:39 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200009281324.e8SDOdA06933@cirocco.openmarket.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net 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 > Nelson Bolyard wrote: > > > 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? > > 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 > > --- > You are currently subscribed to ietf-tls as: win+ietf-tls@treese.org > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Sep 28 09:30:12 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19907 for ; Thu, 28 Sep 2000 09:30:11 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group In-reply-to: Message from Dr S N Henson of 27 Sep 2000 13:21:39 BST Date: Thu, 28 Sep 2000 09:23:05 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200009281323.e8SDN6A06923@cirocco.openmarket.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net 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 > Pete Chown wrote: > > > > Nelson Bolyard wrote: > > > > > 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? > > > > 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. > > > > 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: shenson@drh-consultancy.demon.co.uk > Senior crypto engineer, Celo Communications: http://www.celocom.com/ > Core developer of the OpenSSL project: http://www.openssl.org/ > Business Email: drh@celocom.com PGP key: via homepage. > > > --- > You are currently subscribed to ietf-tls as: win+ietf-tls@treese.org > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Sep 28 14:02:22 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28229 for ; Thu, 28 Sep 2000 14:02:21 -0400 (EDT) Date: Thu, 28 Sep 2000 19:01:54 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from treese@acm.org on Thu, Sep 28, 2000 at 09:24:39AM -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20000928190154.C25675@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Win Treese wrote: > 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. 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Sep 29 01:45:29 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16569 for ; Fri, 29 Sep 2000 01:45:27 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-025.dialup.zetnet.co.uk [194.247.41.31] claimed to be zetnet.co.uk Message-ID: Date: Fri, 29 Sep 2000 04:27:57 +0100 From: David Hopwood Reply-To: "IETF Transport Layer Security WG" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39D40C3D.BAB94339@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA16569 -----BEGIN PGP SIGNED MESSAGE----- Pete Chown wrote: > Win Treese wrote: > > > 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. > > 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 > Network Working Group Pete Chown > INTERNET DRAFT Skygate Technology > 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 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 -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOdQC8DkCAxeYt5gVAQF+OggAkTnGWXFw+a3soleI8XZMX4IZogNK7K2e 3yUur4PM9GYkhXvJxNOXeNse6lXxCM4Y60z1e0CCjWa4HAjvrWITQ//55ao8mjKb UeZ4ND50Zs3mXpEdA7Y8euV/ifIk/+FUL/tfyAY6W5T3efLjhDDxkSjgYLt5sWrh 2nyBnKwISrjiA/62lECvfFKePlsTi1/g5g4BTQgk/4ImxiFbJSaSYohtjd12DIuX MGTkHkGX6una5KXdfA9mvqitnUBd7VQExei+vxi0b38SUAiDDZdCvC2wFBik8d6i eLZ9lJB4ZD6ySmc8aV9lFmpcDiwKTD6OcQFtZMzx4PjcJB9av/0JJQ== =NQnN -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Sep 29 12:26:43 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02328 for ; Fri, 29 Sep 2000 12:26:42 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group In-reply-to: Message from "David P. Kemp" of 26 Sep 2000 12:55:48 EDT Date: Thu, 28 Sep 2000 13:43:24 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200009281743.e8SHhOH01025@cirocco.openmarket.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > 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 (tt 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. 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Sep 29 14:15:46 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04635 for ; Fri, 29 Sep 2000 14:15:40 -0400 (EDT) Date: Fri, 29 Sep 2000 19:15:03 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from hopwood@zetnet.co.uk on Fri, Sep 29, 2000 at 04:27:57AM +0100 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20000929191503.B1039@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit 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/ David Hopwood wrote: > > At present, the symmetric ciphers supported by TLS are RC2, RC4, > > IDEA and triple DES. > > and single DES. Fixed. > 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. Fixed. > 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. 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. > 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. 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. > 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. 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. > > 2. Triple DES is much less efficient than more modern ciphers. > > Significantly less efficient, yes. Much less efficient is a bit too strong, > IMHO. 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. > 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. Good point -- fixed. > > 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). 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? > > 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 }; 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. > 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 }; Good idea -- I copied the 3DES ones, which have fixed key lengths. Fixed. > > 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. 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. > This should include a reference to the IP statement for the AES winner > (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. > 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/). 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Sep 29 21:27:55 2000 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09112 for ; Fri, 29 Sep 2000 21:27:54 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call: Proposed New Charter for TLS Working Group Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 29 Sep 2000 18:30:49 -0700 In-Reply-To: Pete Chown's message of "Fri, 29 Sep 2000 19:15:03 +0100" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Pete Chown writes: > I've no particularly strong views on this -- does anyone (else) have > any comments? 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 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com