From bounce-ietf-tls-3458737@lists.certicom.com Wed Nov 1 06:45:47 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 GAA21951 for ; Wed, 1 Nov 2000 06:45:45 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ciphersuite-01.txt Date: Wed, 01 Nov 2000 06:44:59 -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200011011144.GAA21664@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES Ciphersuites for TLS Author(s) : P. Chown Filename : draft-ietf-tls-ciphersuite-01.txt Pages : 7 Date : 31-Oct-00 At present, the symmetric ciphers supported by TLS are RC2, RC4, IDEA, DES and triple DES. The protocol would be enhanced by the addition of AES [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 RC4 algorithm itself is a trade secret. Ascom Systec Ltd owns a patent on the IDEA algorithm. 2. Triple DES is much less efficient than more modern ciphers. 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 therefore 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 forward secrecy. This document proposes two new ciphersuites, with the aim of over¡ coming these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ciphersuite-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ciphersuite-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001031132504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ciphersuite-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ciphersuite-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001031132504.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Wed Nov 1 21:56:56 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 VAA19665 for ; Wed, 1 Nov 2000 21:56:52 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Confusion with SSLv2 backward compatibility Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 01 Nov 2000 18:59:54 -0800 From: Eric Rescorla List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200011020259.SAA15041@romeo.rtfm.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net In Appendix E, RFC 2246 lists the following 7 cipher suites as "carryovers from SSL Version 2.0". -----snip----- The following cipher specifications are carryovers from SSL Version 2.0. These are assumed to use RSA for key exchange and authentication. V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 = { 0x04,0x00,0x80 }; V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; Cipher specifications native to TLS can be included in Version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by Version 2.0 servers. Clients sending any of the above V2CipherSpecs should also include the TLS equivalent (see Appendix A.5): ------snip----- Nw, it's not clear how to interpret this. One interpretation is that the server should IGNORE any SSLv2 cipher suites that aren't obviously TLS cipher suites, but then why bother to list these at all, especially as "carryovers"? Another possible interpretation is that a TLS implementation receiving one of these cipher suites should map it to its TLS equivalent. I seem to remember at one point seeing an implementation send an SSLv2 cipher suite but not its SSLv3 equivalent and one might expect a liberal server to negotiate that. However, this too is problematic because the RC2-128 cipher suite has no equivalent in TLS and the DES, 3DES, and IDEA cipher suites in TLS use SHA-1, which I would argue makes them not equivalent All in all, it's not obvious (at least to me) what to do. This issue should be clarified before we take TLS to draft. I would favor simply saying that TLS servers should ignore SSLv2 cipher suites which don't have a leading zero (and therefore aren't TLS cipher suites presented as cipher specs.). Does anyone depend on this behavior in any way? -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 Thu Nov 2 09:46:21 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 JAA08454 for ; Thu, 2 Nov 2000 09:46:20 -0500 (EST) Date: Thu, 2 Nov 2000 14:45:43 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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 timothy.wright@vf.vodafone.co.uk on Tue, Oct 31, 2000 at 02:30:53PM -0000 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: <20001102144543.K3483@hyena.skygate.co.uk> X-List-Host: SKYLIST.net timothy.wright@vf.vodafone.co.uk wrote: > This way inter-operability is guaranteed (which it isn't by Pete's current > formulation) ... Yes, that is an important point. I will have to address this in a new draft. Can anyone think of any other points that need to be considered at the same time? On this particular issue, then, I suggest that servers "MUST" support RSA and DHE_RSA and "MAY" support the others. Clients "MUST" support *one of* RSA and DHE_RSA and "MAY" support the others. -- 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 Thu Nov 2 10:15: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 KAA19709 for ; Thu, 2 Nov 2000 10:15:55 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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: 02 Nov 2000 07:19:28 -0800 In-Reply-To: Pete Chown's message of "Thu, 2 Nov 2000 14:45:43 +0000" Message-ID: Lines: 20 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: > timothy.wright@vf.vodafone.co.uk wrote: > > > This way inter-operability is guaranteed (which it isn't by Pete's current > > formulation) ... > > Yes, that is an important point. I will have to address this in a new > draft. Can anyone think of any other points that need to be > considered at the same time? > > On this particular issue, then, I suggest that servers "MUST" support > RSA and DHE_RSA and "MAY" support the others. Clients "MUST" support > *one of* RSA and DHE_RSA and "MAY" support the others. As I noted before, I don't beleive that we can impose new MUSTs here without also incrementing the version number. This would have the effect of making compliant implementations immediately noncompliant. -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 Thu Nov 2 10:41:33 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 KAA26864 for ; Thu, 2 Nov 2000 10:41:32 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES draft available Date: Thu, 2 Nov 2000 16:40:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <009301c044e3$3a5ef320$4c981b81@iaik.tugraz.ac.at> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit It is ok for me as it is, I just do not think there is much use in defining new static Diffie-Hellman ciphersuites (DH_RSA, DH_DSS) given the history of the existing ones (the only implementation that I know supports them is our Java SSL/TLS library). Now that the RSA patent expired there seems to be even less interest in DH certificates. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at -----Ursprüngliche Nachricht----- Von: "Pete Chown" An: "IETF Transport Layer Security WG" Gesendet: Freitag, 27. Oktober 2000 16:55 Betreff: [ietf-tls] New AES draft available > A new draft of the AES ciphersuite document is available from the > usual place: > > ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ > > The latest version is: > > ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-01a .txt > > The main change in this revision is that the document now provides AES > analogues for most of the original ciphersuites, including static RSA. > The exceptions are the "anon" and export ciphersuites. The first > group have been deprecated ever since the original TLS specification, > while recent legal changes have made the second group essentially > irrelevant. > > I have had an extensive discussion off-list with some of the people > who originally opposed this change. I believe (my apologies if I have > misunderstood anyone's position) that no one has serious objections to > us proceeding on this new basis. Of course, if this is not the case, > please send an email to me or the list. This is particularly > important because not everyone was involved in the off-list > discussion. > > (Note: the sequence of documents that led up to the draft published by > the IETF are now called 00a, 00b, 00c and so on. Hopefully the 01a > sequence will eventually become a document that will be numbered 01 by > the IETF.) > > -- > Pete > > --- > You are currently subscribed to ietf-tls as: Andreas.Sterbenz@iaik.at > 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 Nov 2 11:00:57 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 LAA02517 for ; Thu, 2 Nov 2000 11:00:56 -0500 (EST) Date: Thu, 2 Nov 2000 16:00:27 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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 ekr@rtfm.com on Thu, Nov 02, 2000 at 07:19:28AM -0800 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: <20001102160027.A4109@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Eric Rescorla wrote: > As I noted before, I don't beleive that we can impose new MUSTs here > without also incrementing the version number. This would have the > effect of making compliant implementations immediately noncompliant. If an implementation doesn't implement one of the MUSTs, I mean that it isn't compliant with my draft. I don't mean that it isn't compliant with TLS in general, or the original TLS RFC. I will make this clearer if you think it is going to give rise to confusion the way it is at the moment. -- 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 Thu Nov 2 11:10:32 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 LAA05255 for ; Thu, 2 Nov 2000 11:10:31 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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: 02 Nov 2000 08:14:01 -0800 In-Reply-To: Pete Chown's message of "Thu, 2 Nov 2000 16:00:27 +0000" Message-ID: Lines: 16 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: > Eric Rescorla wrote: > > > As I noted before, I don't beleive that we can impose new MUSTs here > > without also incrementing the version number. This would have the > > effect of making compliant implementations immediately noncompliant. > > If an implementation doesn't implement one of the MUSTs, I mean that > it isn't compliant with my draft. I don't mean that it isn't > compliant with TLS in general, or the original TLS RFC. I will make > this clearer if you think it is going to give rise to confusion the > way it is at the moment. Fair enough. This seems perfectly reasonable. -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 Thu Nov 2 11:11:36 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 LAA05535 for ; Thu, 2 Nov 2000 11:11:35 -0500 (EST) Date: Thu, 2 Nov 2000 08:10:57 -0800 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from ekr@rtfm.com on Thu, Nov 02, 2000 at 07:19:28AM -0800 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001102081057.V18991@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Thu, Nov 02, 2000 at 07:19:28AM -0800, Eric Rescorla wrote: > Pete Chown writes: > > > timothy.wright@vf.vodafone.co.uk wrote: > > > > > This way inter-operability is guaranteed (which it isn't by Pete's current > > > formulation) ... > > > > Yes, that is an important point. I will have to address this in a new > > draft. Can anyone think of any other points that need to be > > considered at the same time? > > > > On this particular issue, then, I suggest that servers "MUST" support > > RSA and DHE_RSA and "MAY" support the others. Clients "MUST" support > > *one of* RSA and DHE_RSA and "MAY" support the others. > As I noted before, I don't beleive that we can impose new MUSTs here > without also incrementing the version number. This would have the > effect of making compliant implementations immediately noncompliant. Yep. A major change like that requires a new version number. What's the reasoning for making DHE_RSA a MUST? Forward secrecy? If so, why require it? One of the goals of SSL was to enable users to select the level of security that they need without having a bewildering array of choices. Sometimes you don't need FS enough to want to do the extra crypto ops. (if this topic was covered recently, my apologies for bring it up again). -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5 --- 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 Nov 2 17:39:30 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 RAA11592 for ; Thu, 2 Nov 2000 17:39:29 -0500 (EST) Message-ID: Date: Thu, 02 Nov 2000 14:36:21 -0800 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [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: New AES ciphersuites I-d 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: <3A01EC65.C1663B3B@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I've been given a rare opportunity to speak on behalf of Netscape to say this: Netscape supports draft-ietf-tls-ciphersuite-01.txt as it is. -- Nelson Bolyard --- 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 Nov 2 20:01:30 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 UAA11541 for ; Thu, 2 Nov 2000 20:01:29 -0500 (EST) Message-ID: Date: Thu, 02 Nov 2000 17:01:10 -0800 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [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: Confusion with SSLv2 backward compatibility 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: <3A020E56.19290F9A@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > In Appendix E, RFC 2246 lists the following 7 cipher suites as > "carryovers from SSL Version 2.0". > > -----snip----- > The following cipher specifications are carryovers from SSL Version > 2.0. These are assumed to use RSA for key exchange and > authentication. > > V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; > V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 }; > V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 }; > V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5 > = { 0x04,0x00,0x80 }; > V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 }; > V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 }; > V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 }; > > Cipher specifications native to TLS can be included in Version 2.0 > client hello messages using the syntax below. Any V2CipherSpec > element with its first byte equal to zero will be ignored by Version > 2.0 servers. Clients sending any of the above V2CipherSpecs should > also include the TLS equivalent (see Appendix A.5): > ------snip----- > Nw, it's not clear how to interpret this. One interpretation is that > the server should IGNORE any SSLv2 cipher suites that aren't obviously > TLS cipher suites, but then why bother to list these at all, especially > as "carryovers"? A TLS server that supports client hellos in the SSLv2 format presumably does so because it wants to be compatible with clients that support SSLv2 as well as TLS. Such clients are likely to include both SSLv2 "cipherspecs" and TLS ciphersuites in the same client hello, so that they can interoperate with both SSLv2 servers and SSL3/TLS servers without having to know the capabilities of any server, a priori. If the client hello in SSLv2 format indicates that the client supports TLS, then IMO the TLS server should ignore the SSLv2 cipherspecs. If the client hello in SSLv2 format indicates that the client only understands SSLv2, then the server's response obviously depends on whether or not the server implements SSLv2. I suspect these cipher specs are listed in RFC 2246 because they were originally listed in the SSL 3.0 draft from which RFC 2246 evolved. (See appendix E in http://home.netscape.com/eng/ssl3/draft302.txt). I believe they were listed in the SSL 3.0 draft simply to set the SSL 3 developers' expectations for what might be present in the v2 client hello in addition to the SSLv3 ciphersuites. Listing them in the SSL 3.0 draft obviated a citation for the SSLv2 specification, which was even more controversial. > Another possible interpretation is that a TLS implementation receiving > one of these cipher suites should map it to its TLS equivalent. I seem > to remember at one point seeing an implementation send an SSLv2 cipher > suite but not its SSLv3 equivalent and one might expect a liberal server > to negotiate that. I believe it would be an error to negotiate a ciphersuite not listed explicitly in the client hello. I don't know of any servers that do that. > All in all, it's not obvious (at least to me) what to do. This issue > should be clarified before we take TLS to draft. Is anyone acting as editor for the purpose of taking TLS to draft? There are quite a number of such issues that have been raised in this mailing list in the last year or so. They've ranged from obvious, non-controversial things (e.g. the reference to SSL3's Sender.server and Sender.client, which are undefined in TLS, in section 7.4.9) to more difficult topics like the negotiation of different versions of SSL/TLS in handshakes subsequent to the first one on a TLS connection. But I've never seen a new draft of the TLS spec that incorporates any of the suggested changes. -- Nelson Bolyard 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 Thu Nov 2 21:16:56 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 VAA24821 for ; Thu, 2 Nov 2000 21:16:55 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Thu, 02 Nov 2000 21:17:12 -0500 From: Peter W X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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: <3A022028.60A089F7@JunkMailForbidden.usa.net> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Murray wrote: > What's the reasoning for making DHE_RSA a MUST? Forward > secrecy? If so, why require it? One of the goals of SSL was > to enable users to select the level of security that they need > without having a bewildering array of choices. Sometimes > you don't need FS enough to want to do the extra crypto ops. > (if this topic was covered recently, my apologies for > bring it up again). I think there's a general consensus on this mailing list that PFS, or at least some sort of improved FS, should be used if it's feasible. And there's a growing consensus that improved FS can be achieved without significant performance penalties. As for Pete requiring DHE on the server implementations but not the clients, I think that's an attempt to break the chicken-and-egg problem we have now, where the most popular servers and clients don't support FS suites. I would generally prefer to require FS suites on both sides, but I suspect Pete is acknowledging that some clients (like the anemic PalmOS devices many of us carry) may have have such seriously constrained resources that it wouldn't be fair to force even slightly more expensive suites on them. As for users selecting security levels: in my experience, precious few have any understanding of security implications beyond 128-bit > 56-bit > 40-bit. Everyone I've talked to about the lack of forward secrecy in the strong RSA suites has a reaction somewhere between moderate surprise and complete disbelief and utter dismay at the situation. Users don't want choices so much as they want strong security. Requiring server applications to implement better FS doesn't get us as far as some of us would like, but it's a good first step, and I am encouraged that Netscape has voiced its support of this proposal. That's a great sign. -Peter -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.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 Thu Nov 2 23:19:32 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 XAA19080 for ; Thu, 2 Nov 2000 23:19:31 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Confusion with SSLv2 backward compatibility 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: 02 Nov 2000 20:22:55 -0800 In-Reply-To: nelsonb@netscape.com's message of "Thu, 02 Nov 2000 17:01:10 -0800" Message-ID: Lines: 25 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: > > Nw, it's not clear how to interpret this. One interpretation is that > > the server should IGNORE any SSLv2 cipher suites that aren't obviously > > TLS cipher suites, but then why bother to list these at all, especially > > as "carryovers"? > > A TLS server that supports client hellos in the SSLv2 format presumably > does so because it wants to be compatible with clients that support SSLv2 > as well as TLS. Such clients are likely to include both SSLv2 "cipherspecs" > and TLS ciphersuites in the same client hello, so that they can interoperate > with both SSLv2 servers and SSL3/TLS servers without having to know the > capabilities of any server, a priori. Naturally. > If the client hello in SSLv2 format indicates that the client supports TLS, > then IMO the TLS server should ignore the SSLv2 cipherspecs. That's certainly the most obvious interpretation. > I believe it would be an error to negotiate a ciphersuite not listed > explicitly in the client hello. I don't know of any servers that do that. Ok. I'm all for not doing this (despite the fact that I had a brain fart and managed to say otherwise in the relevant section of my book :)) -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 Thu Nov 2 23:59:32 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 XAA28037 for ; Thu, 2 Nov 2000 23:59:31 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Thu, 02 Nov 2000 20:59:54 -0800 From: Tom Wu X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] draft-ietf-tls-ciphersuite-01a.txt suggestion 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: <3A02464A.EA4CA7B4@arcot.com> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > The main change in this revision is that the document now provides AES > analogues for most of the original ciphersuites, including static RSA. > The exceptions are the "anon" and export ciphersuites. The first > group have been deprecated ever since the original TLS specification, > while recent legal changes have made the second group essentially > irrelevant. I would like to have the anonymous ciphersuite(s) added back to the AES ciphersuite I-D. I've taken a look at the original TLS specification regarding ADH, which states: > Warning: Completely anonymous connections only provide protection > against passive eavesdropping. Unless an independent tamper- > proof channel is used to verify that the finished messages > were not replaced by an attacker, server authentication is > required in environments where active man-in-the-middle > attacks are a concern. Since the draft was published, newer applications have been developed that use anonymous key exchange and which validate the TLS Finished messages to prevent man-in-the-middle attacks and establish mutual authentication. The TLS-based Telnet security draft (draft-ietf-tn3270e-telnet-tls-05.txt) being developed by the tn3270e WG gives guidelines on how exactly to verify Finished messages, and it allows TLS to be used in situations where certificates are not being used, such as with strong password authentication techniques. Since SSL libraries like OpenSSL provide explicit hooks for verifying TLS Finished messages, "authenticated" anonymous TLS sessions fill a very useful need for transport security, and for technical reasons seem to be a very good fit for authentication methods that don't fit the PKI mold. As long as the Finished messages are verified securely, ADH should also offer forward secrecy for the TLS session. The same reasons for advocating AES over 3DES ciphersuites apply to ADH-AES as well. -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." --- 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 Nov 3 04:44:57 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 EAA14552 for ; Fri, 3 Nov 2000 04:44:56 -0500 (EST) Message-ID: Date: Fri, 03 Nov 2000 09:45:30 +0000 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.75 [en] (WinNT; U) MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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: <3A02893A.4305A63F@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Peter W wrote: > As for users selecting security levels: in my experience, precious few have any > understanding of security implications beyond 128-bit > 56-bit > 40-bit. Everyone > I've talked to about the lack of forward secrecy in the strong RSA suites has a > reaction somewhere between moderate surprise and complete disbelief and utter > dismay at the situation. Users don't want choices so much as they want strong > security. Well, the advent of RIP in the UK is changing that somewhat over here - it may not have trickled down to the average user yet, but it certainly has reached the consciousness of the less technical civil libertarians (who are mostly saying "you're kidding? SSL doesn't have PFS? Really???"). 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 --- 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 Nov 3 05:59:47 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 FAA06176 for ; Fri, 3 Nov 2000 05:59:46 -0500 (EST) Date: Fri, 3 Nov 2000 10:59:06 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d 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 peterw@usa.net on Thu, Nov 02, 2000 at 09:17:12PM -0500 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: <20001103105906.D22069@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Peter W wrote: > As for Pete requiring DHE on the server implementations but not the > clients, I think that's an attempt to break the chicken-and-egg > problem we have now ... Not altogether. The problem is ensuring that a client and a server which comply with the draft will interoperate. For this to be achieved they must have one ciphersuite in common. For the original TLS the "MUST" ciphersuite was TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. I do not feel that the AES analogue of this (TLS_DHE_DSS_WITH_AES_128_CBC_SHA) is the best choice. For one thing the RSA patent has expired so we might as well use the de facto standard RSA certificates. Also there has been opposition to requiring DHE ciphersuites. In theory we could just require static RSA, but what about applications where the threat model requires forward secrecy? If static RSA was a "MUST" we would in effect be saying that they have to carry on functioning even though they haven't achieved the required level of security. I hope this finds some sort of middle ground. It isn't perfect for everything but I am hoping it is a reasonable compromise. -- 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 Nov 3 07:14:08 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 HAA22712 for ; Fri, 3 Nov 2000 07:14:07 -0500 (EST) From: Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d Date: Fri, 3 Nov 2000 12:12:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > > On this particular issue, then, I suggest that servers "MUST" support > RSA and DHE_RSA and "MAY" support the others. Clients "MUST" support > *one of* RSA and DHE_RSA and "MAY" support the others. > > -- > Pete I support this suggestion tim --- 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 Nov 3 08:13: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 IAA05957 for ; Fri, 3 Nov 2000 08:13:08 -0500 (EST) Message-ID: Date: Fri, 03 Nov 2000 13:14:12 +0000 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: draft-ietf-tls-ciphersuite-01a.txt suggestion 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: <3A02BA24.6A7ADB00@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Tom Wu wrote: > > Pete Chown wrote: > > > > The main change in this revision is that the document now provides AES > > analogues for most of the original ciphersuites, including static RSA. > > The exceptions are the "anon" and export ciphersuites. The first > > group have been deprecated ever since the original TLS specification, > > while recent legal changes have made the second group essentially > > irrelevant. > > I would like to have the anonymous ciphersuite(s) added back to the AES > ciphersuite I-D. I've taken a look at the original TLS specification > regarding ADH, which states: > Yes I agree. I know of several people using anon DH with alternative authentication schemes. Andreas Sterbenz wrote: > > It is ok for me as it is, I just do not think there is much use in > defining new static Diffie-Hellman ciphersuites (DH_RSA, DH_DSS) given > the history of the existing ones (the only implementation that I know > supports them is our Java SSL/TLS library). > > Now that the RSA patent expired there seems to be even less interest in > DH certificates. > I also don't know of anyone using static DH ciphersuites but they may have a use. If used with short exponent DH they have the lowest server overhead of all the ciphersuites. In the older static DH ciphersuites I believe PKCS#3 DH certificates were used. Perhaps we could add the additional requirement that X9.42 DH certificates must be used. The main problem for public servers is getting a public CA to sign a DH certificate request. 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 Fri Nov 3 11:50:15 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 LAA03290 for ; Fri, 3 Nov 2000 11:50:14 -0500 (EST) Date: Fri, 3 Nov 2000 08:49:29 -0800 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from peterw@usa.net on Thu, Nov 02, 2000 at 09:17:12PM -0500 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001103084929.Z18991@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Thu, Nov 02, 2000 at 09:17:12PM -0500, Peter W wrote: > Eric Murray wrote: > > > What's the reasoning for making DHE_RSA a MUST? Forward > > secrecy? If so, why require it? One of the goals of SSL was > > to enable users to select the level of security that they need > > without having a bewildering array of choices. Sometimes > > you don't need FS enough to want to do the extra crypto ops. > > (if this topic was covered recently, my apologies for > > bring it up again). > > I think there's a general consensus on this mailing list that PFS, or at least some > sort of improved FS, should be used if it's feasible. And there's a growing > consensus that improved FS can be achieved without significant performance > penalties. > > As for Pete requiring DHE on the server implementations but not the clients, I > think that's an attempt to break the chicken-and-egg problem we have now, where the > most popular servers and clients don't support FS suites. I would generally prefer > to require FS suites on both sides, but I suspect Pete is acknowledging that some > clients (like the anemic PalmOS devices many of us carry) may have have such > seriously constrained resources that it wouldn't be fair to force even slightly > more expensive suites on them. > > As for users selecting security levels: in my experience, precious few have any > understanding of security implications beyond 128-bit > 56-bit > 40-bit. Everyone > I've talked to about the lack of forward secrecy in the strong RSA suites has a > reaction somewhere between moderate surprise and complete disbelief and utter > dismay at the situation. Users don't want choices so much as they want strong > security. The "users" of the TLS spec aren't your run of the mill end-users- they're the programmers who write TLS libraries, and the programmers who use those libraries in server and client projects. These users are expected to have some amount of knowledge of what they are doing and why, and to then write something that will have strong security for their end-users. We already give programmers the choice of using the anon_DH suites. Used improperly, those are much less secure than not having FS. Yet, as you can see from other messages that have been posted to the list recently, some programmers have managed to use them in a way that's secure and satisfies their needs. I agree with your reasoning for encouraging FS, but OTOH I don't want to put in an unnecessarily high barrier for implementers who knowledgably decide that they don't need FS. A spec that requires too much uneeded stuff winds up not being followed completely. Is there any way to encourage TLS implementers to implement DHE_RSA and programmers using TLS to include it, without making it a MUST? How about making DHE_RSA a "SHOULD" and including a paragraph encouraging it's use over plain RSA suites? -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5 --- 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 Nov 3 18:19:28 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 SAA26481 for ; Fri, 3 Nov 2000 18:19:23 -0500 (EST) Message-ID: Date: Fri, 03 Nov 2000 13:58:24 -0800 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [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: New AES ciphersuites I-d 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: <3A033500.1467AB73@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > The problem is ensuring that a client and a server > which comply with the draft will interoperate. For this to be > achieved they must have one ciphersuite in common. For the original > TLS the "MUST" ciphersuite was TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. But here is a case where market forces, not any standard, ensured interoperability via a common cipher suite. One that wasn't the one named in the standard. I think that situation will continue. Today, very few web sites use DES or 3DES, because of cost efficiency. It takes more hardware to handle a certain number of transactions per day with DES or 3DES than with ARCfour. The only web sites known to me that routinely use DES or 3DES are either (a) government/defense sites that cannot use ARCfour because it's not a FIPS, or (b) little non-commercial sites that really want the extra security and have a low transaction rate (that is, sites for whom the cost doesn't matter). In my opinion, (not speaking for anyone but myself), making ANY AES ciphersuite (regardless of its key exchange and authentication algorithms) a MUST is simply going to be ignored by most of the market. The sites that use AES will be those that are required to use it (i.e., that are required to use only FIPS algorithms), or that aren't concerned about the cost of using the more expensive algorithm (in terms of CPU cycles). So, perhaps it is worthwhile for a draft to state that SITES THAT ARE GOING TO USE ONLY AES ciphersuites MUST implement a particular one of them. But to state that offering a particular AES ciphersuite is a requisite of TLS compliance, or even a requisite of any server that offers any AES ciphersuite (in addition to non-AES suites), seems pointless to me. For servers that are going to implement/offer AES cipher suites in addition to others, I think the word "SHOULD" is the most reasonable word (adverb?) to use in this document. IMO, the absence of the word MUST was an important consideration in Netscape's decision to state support for draft-ietf-tls-ciphersuite-01a.txt . This is all just my personal opinion. -- 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 Fri Nov 3 20:02:20 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 UAA18875 for ; Fri, 3 Nov 2000 20:02:18 -0500 (EST) Date: Fri, 3 Nov 2000 17:01:28 -0800 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from nelsonb@netscape.com on Fri, Nov 03, 2000 at 01:58:24PM -0800 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001103170128.J18991@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Fri, Nov 03, 2000 at 01:58:24PM -0800, Nelson Bolyard wrote: > Pete Chown wrote: > > > > The problem is ensuring that a client and a server > > which comply with the draft will interoperate. For this to be > > achieved they must have one ciphersuite in common. For the original > > TLS the "MUST" ciphersuite was TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > > But here is a case where market forces, not any standard, ensured > interoperability via a common cipher suite. One that wasn't the one > named in the standard. I think that situation will continue. > > Today, very few web sites use DES or 3DES, because of cost efficiency. That's not what I found in my study- ~75% of the servers I surveyed supported DES ciphersuites. (http://www.lne.com/ericm/papers/ssl_server_stats.html) However many of those might support DES but prefer RC4 (supported by 99+%). I didn't record server preference. > It takes more hardware to handle a certain number of transactions per day > with DES or 3DES than with ARCfour. DES is very efficient in h/w. It's pretty easy to get crypto hardware that can do DES in 1 round/cycle. I have a set of specs here for a crypto processor that's either shipping now or about to which does twice the bandwidth in 3DES than it does RC4. [..] > In my opinion, (not speaking for anyone but myself), making ANY AES > ciphersuite (regardless of its key exchange and authentication algorithms) > a MUST is simply going to be ignored by most of the market. The sites > that use AES will be those that are required to use it (i.e., that are > required to use only FIPS algorithms), or that aren't concerned about the > cost of using the more expensive algorithm (in terms of CPU cycles). > > So, perhaps it is worthwhile for a draft to state that SITES THAT ARE GOING > TO USE ONLY AES ciphersuites MUST implement a particular one of them. > But to state that offering a particular AES ciphersuite is a requisite of > TLS compliance, or even a requisite of any server that offers any AES > ciphersuite (in addition to non-AES suites), seems pointless to me. > > For servers that are going to implement/offer AES cipher suites in addition > to others, I think the word "SHOULD" is the most reasonable word (adverb?) > to use in this document. Even though I disagree with some of your supporting arguments, I agree with your conclusion. Requiring too much encourages implementers to ignore parts of the standard. -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5 --- 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 Nov 3 20:46:47 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 UAA28521 for ; Fri, 3 Nov 2000 20:46:46 -0500 (EST) Message-ID: Date: Fri, 03 Nov 2000 17:46:30 -0800 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [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: New AES ciphersuites I-d 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: <3A036A76.8D9A4BEB@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Murray wrote: > > On Fri, Nov 03, 2000 at 01:58:24PM -0800, Nelson Bolyard wrote: > > Today, very few web sites use DES or 3DES, because of cost efficiency. > > That's not what I found in my study- ~75% of the servers I surveyed > supported DES ciphersuites. > (http://www.lne.com/ericm/papers/ssl_server_stats.html) > > However many of those might support DES but prefer RC4 (supported > by 99+%). I didn't record server preference. I think our positions are actually in agreement. I didn't say they don't _support_ it. I said they don't USE it. They may _support_ DES but don't USE it, that is don't negotiate it, unless a more preferred ciphersuite, e.g. one that uses ARCfour, is not mutually supported. And that almost never occurs. I agree that ARCfour is used more than 99% of the time. > > It takes more hardware to handle a certain number of transactions per day > > with DES or 3DES than with ARCfour. > > DES is very efficient in h/w. It's pretty easy to get crypto hardware > that can do DES in 1 round/cycle. I have a set of specs here for a crypto > processor that's either shipping now or about to which does twice the > bandwidth in 3DES than it does RC4. They can get special DES H/W, or they can just use more server systems in their server farm. Either way, it's more $$$ to achieve a certain transaction rate with DES or 3DES than with ARCfour. -- 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 Mon Nov 6 09:47:28 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 JAA13221 for ; Mon, 6 Nov 2000 09:47:27 -0500 (EST) Date: Mon, 6 Nov 2000 14:46:38 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] AES Ciphersuites: Progress Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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: <20001106144638.C313@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Okay, here are the outstanding two issues (as I see it). I will start with the easy one: 1. ADH ciphersuite ------------------- There seems to be support for including this, and no opposition. I think a good case has been made for including it in the standard. Further, it appears to me that it should *not* be regarded as deprecated, unlike the ones in the original TLS RFC. I will, however, include a note reminding implementors to implement some other kind of authentication mechanism. 2. Interoperability -------------------- It would be nice if two implementations of the AES draft could always negotiate an AES ciphersuite. The problem with this is that it reopens the issue about which ciphersuites ought to be mandatory. One option, of course, is to forget about interoperability. We just define a collection of new ciphersuites, and say that implementors really SHOULD provide two of them. I mentioned another option in my last email (although it wasn't my idea to begin with). This would require servers to support both ciphersuites, but clients could choose to support only one. This would provide a smoother path to interoperability. I realised afterwards that it might make more sense to require clients to support both ciphersuites, but only require servers to support one. This way, in the web scenario, servers get to decide the tradeoff between forward secrecy and processing cost. The other option would be to pick a single ciphersuite that everyone MUST support. I really don't like this option. According to Microsoft and Netscape, customers would not accept a forward secrecy ciphersuite. On the other hand, suppose your threat model requires forward secrecy. If the static RSA suite was a MUST, what are you supposed to do if you fail to negotiate EDH? If you abort the connection you are non-compliant with the AES draft. If you don't abort the connection you are communicating with an inappropriately low security level. Please could you have a think about these options and decide which would be acceptable. If none of these can achieve consensus we will (I suppose) just have to drop the idea of interoperability. In this situation we would just define a collection of new ciphersuites and implementations can offer them or not as they choose. Finally, just to reassure everyone, I am not trying to declare anything non-compliant with TLS. "MUST" only refers to compliance with the AES draft. An implementation which failed to implement such a "MUST" clause might still be a conformant to TLS. Nelson Bolyard wrote: > So, perhaps it is worthwhile for a draft to state that SITES THAT ARE GOING > TO USE ONLY AES ciphersuites MUST implement a particular one of them. > But to state that offering a particular AES ciphersuite is a requisite of > TLS compliance, or even a requisite of any server that offers any AES > ciphersuite (in addition to non-AES suites), seems pointless to me. I agree, actually (with one slight caveat). I confused everyone with what I said. "MUST" was supposed to refer to compliance with the AES draft, not compliance with the TLS RFC. You will still be able to write a perfectly good TLS implementation that doesn't implement AES. In fact, if you implemented, for example, the ciphers in the TLS draft plus TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, you would be compliant with the TLS RFC but not the AES draft. Obviously I wouldn't advise anyone to do this, but I just include it as an example. The caveat is that you can quite legitimately support AES as an option along with other ciphersuites. In this case, you may still need to support certain ciphersuites in order to achieve compliance *with the AES draft*. > IMO, the absence of the word MUST was an important consideration in > Netscape's decision to state support for draft-ietf-tls-ciphersuite-01a.txt . I know. I really didn't want to reopen this issue! It would be nice, though, to guarantee that two implementations of the AES draft could interoperate (without falling back to pre-AES ciphersuites). -- Pete --- You are currently subscribed to ietf-tls as: 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 Mon Nov 6 10:11:39 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 KAA20318 for ; Mon, 6 Nov 2000 10:11:38 -0500 (EST) Date: Mon, 6 Nov 2000 10:11:28 EST From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES Ciphersuites: Progress In-Reply-To: Your message of Mon, 6 Nov 2000 14:46:38 +0000 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > Okay, here are the outstanding two issues (as I see it). I will start > with the easy one: > > 1. ADH ciphersuite > ------------------- > > There seems to be support for including this, and no opposition. I > think a good case has been made for including it in the standard. > Further, it appears to me that it should *not* be regarded as > deprecated, unlike the ones in the original TLS RFC. > > I will, however, include a note reminding implementors to implement > some other kind of authentication mechanism. The note from RFC2246 Appendix F reads: "Warning: Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper- proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern." This is in conflict with the deprecation statement in Appendix A.5: " The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated. CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };" My understanding is that the IESG required the deprecation statement because there were no applications that properly validated the finished messages. Now that there are, the deprecation clause should be removed the next time RFC 2246 is revised. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Thu Nov 9 06:21: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 GAA11449 for ; Thu, 9 Nov 2000 06:21:43 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-kerb-00.txt Date: Thu, 09 Nov 2000 06:21:07 -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200011091121.GAA11209@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Kerberos Cipher Suites in Transport Layer Security (TLS) Author(s) : M. Hur, A. Medvinsky Filename : draft-ietf-tls-kerb-00.txt Pages : Date : 08-Nov-00 RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos [KERB] authentication within the TLS protocol [TLS]. This document extends RFC 2712 to support delegation of Kerberos credentials. In this way, a TLS server may obtain a Kerberos service ticket on behalf of the TLS client. Thus, a single client identity may be used for authentication within a multi-tier architecture. This draft also proposes a mechanism for a TLS server to indicate Kerberos-specific information to the client within the certificate request message in the initial exchange. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-kerb-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-kerb-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-kerb-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001108122233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-kerb-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-kerb-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108122233.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Thu Nov 9 06:22:18 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 GAA11727 for ; Thu, 9 Nov 2000 06:22:17 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" CC: ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com, nat@livingston.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-shukla-ipsec-nat-qos-compatible-security-00.txt Date: Thu, 09 Nov 2000 06:21:59 -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200011091122.GAA11588@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NGISec-NAT and QoS compatible End-to-End Secure Communication Author(s) : J. Shukla Filename : draft-shukla-ipsec-nat-qos-compatible-security-00.txt Pages : 15 Date : 08-Nov-00 This document outlines a new approach, called NGISec, for end-to-end secure communication system that is compatible with other networking protocols. Such a solution is needed because IPSec is incompatible with network address translation (NAT), ICMP, and QoS protocols such as differentiated services, RSVP, RED, and ECN. Most of the proposed solutions to mitigate or remove the incompatibility problems of IPSec only address a small sub-section of the problems, and proposed solutions have severe drawbacks. By using our proposed approach, one can achieve end-to-end secure communication in LANs, VPNs, and network-to-network connections. This approach can be viewed as an alternative to IPSec that solves the severe problems faced by IPSec and paves the way for simultaneous use of security and QoS services. While it is aimed to be an alternative to IPSec, it re-uses critical components of the IPSec infrastructure such as the Internet key exchange (IKE). An interesting aspect of the proposed protocol is that it also allows the use of SSL/TLS to build VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shukla-ipsec-nat-qos-compatible-security-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001108140603.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shukla-ipsec-nat-qos-compatible-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shukla-ipsec-nat-qos-compatible-security-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001108140603.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Thu Nov 9 09:45:38 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 JAA22572 for ; Thu, 9 Nov 2000 09:45:38 -0500 (EST) Date: Thu, 9 Nov 2000 14:44:47 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES Ciphersuites: Progress Message-ID: References: <20001106144638.C313@hyena.skygate.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001106144638.C313@hyena.skygate.co.uk>; from Pete.Chown@skygate.co.uk on Mon, Nov 06, 2000 at 02:46:38PM +0000 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: <20001109144447.A6515@hyena.skygate.co.uk> X-List-Host: SKYLIST.net No one has expressed any views about my "Progress" email. I guess either no one has any strong views or I've bored you all into submission! :-) I suggest, then, that I produce another version of the draft. This will have an ADH ciphersuite (not deprecated). Also it will require servers to support one of static RSA and EDH. It will require clients to support both. By "require" I mean that an application must support those ciphersuites in order to comply with the AES draft. Applications which do not support those ciphersuites may still be perfectly good TLS implementations. This will ensure that two implementations complying with the AES draft will always be able to negotiate an AES ciphersuite. At the same time, it allows servers to determine the proper trade-off between performance and forward secrecy. Hopefully this will satisfy the objections of Netscape and Microsoft (please let me know whether this is the case). -- Pete --- 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 Nov 9 11:36:13 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 LAA05461 for ; Thu, 9 Nov 2000 11:36:12 -0500 (EST) Message-ID: Date: Thu, 09 Nov 2000 16:36:13 +0000 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: AES Ciphersuites: Progress 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: <3A0AD27D.C369EC9F@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > No one has expressed any views about my "Progress" email. I guess > either no one has any strong views or I've bored you all into > submission! :-) > Probably like me, everyone was waiting for everyone else :-) > I suggest, then, that I produce another version of the draft. This > will have an ADH ciphersuite (not deprecated). Also it will require > servers to support one of static RSA and EDH. It will require clients > to support both. > Good. Does anyone want anonymous RSA? Just a thought since it fits in the "low powered client" category and currently there is no anonymous RSA ciphersuite in TLS at all AFAICS. > By "require" I mean that an application must support those > ciphersuites in order to comply with the AES draft. Applications > which do not support those ciphersuites may still be perfectly good > TLS implementations. > > This will ensure that two implementations complying with the AES draft > will always be able to negotiate an AES ciphersuite. At the same > time, it allows servers to determine the proper trade-off between > performance and forward secrecy. Hopefully this will satisfy the > objections of Netscape and Microsoft (please let me know whether this > is the case). > IMHO this needs some clarification. Does this mean if a particular library has an option to disable certain ciphersuites (as many do) and a particular client configuration disables one mandatory algorithm then it is non compliant? Also on the client side. I can see reasons why a user might want to disable static RSA on the client side and only permit EDH on security grounds. Similarly low powered clients might want to disable EDH because it is unusably slow. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: 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 Thu Nov 9 18:29:28 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 SAA15228 for ; Thu, 9 Nov 2000 18:29:27 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] ANNOUNCE: ssldump-0.9b1 Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 09 Nov 2000 13:09:21 -0800 From: Eric Rescorla List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200011092109.NAA78133@romeo.rtfm.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net ANNOUNCE: ssldump: an SSL protocol analyzer Version 0.9b1 http://www.rtfm.com/ssldump/ RTFM, Inc. is pleased to announce the availability of ssldump 0.9b1. ssldump is an SSLv3/TLS network protocol analyzer. It identifies TCP connections on the chosen network interface and attempts to interpret them as SSLv3/TLS traffic. When it identifies SSLv3/TLS traffic, it decodes the records and displays them in a textual form to stdout. If linked with OpenSSL and provided with the appropriate keying material, it will also decrypt the connections and display the application data traffic. ssldump is completely passive and thus allows you to analyze systems without interfering with them. You can also use it to read stored traffic collected with tcpdump. This release is version 0.9b1. The code quality is considered to be early Beta. It's been extensively tested internally and I've collected and integrated the first round of feedback. ssldump has now been tested on FreeBSD, Solaris, HP/UX, and Linux. It uses autoconf and should be portable to most Unix-based systems. CHANGES Since 0.9a2, the following things have changed Ported to Linux, Solaris, and HP/UX. Added decoding of printable characters when printing hex data. Man page cleanups Assorted other printing cleanups SAMPLE OUTPUT Here's a sample of ssldump output in quiet mode: New TCP connection #1: iromeo.rtfm.com(2539) <-> sr1.rtfm.com(4433) 1 1 0.0828 (0.0828) C>S SSLv2 compatible client hello 1 2 1.0378 (0.9549) S>C Handshake ServerHello 1 3 1.5707 (0.5329) S>C Handshake Certificate 1 4 2.0859 (0.5152) S>C Handshake ServerHelloDone 1 5 2.1256 (0.0396) C>S Handshake ClientKeyExchange 1 6 2.1256 (0.0000) C>S ChangeCipherSpec 1 7 2.1256 (0.0000) C>S Handshake 1 8 7.7635 (5.6378) S>C ChangeCipherSpec 1 9 9.3182 (1.5547) S>C Handshake 1 18.1578 (8.8395) C>S TCP FIN 1 19.2500 (1.0922) S>C TCP FIN And a message decoded in verbose mode: 1 2 1.0378 (0.9549) S>CV3.0(74) Handshake ServerHello Version 3.0 random[32]= 39 e7 7b be 44 ce 48 94 d8 00 de 98 54 42 43 0d 28 72 87 2d b0 95 5c d6 2a c8 24 f2 d4 b2 88 21 session_id[32]= 47 26 45 c9 ee 4f 66 56 88 c8 92 53 0d 84 2b eb 36 ac 44 ee c0 05 c8 dc 6c ed db 8e 1f bc ff fa cipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA compressionMethod NULL ssldump also provides a variety of flags for controlling the output at a finer level of granularity. ssldump is released under a BSD-style license and is available from http://www.rtfm.com/ssldump -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 Fri Nov 10 03:59: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 DAA08474 for ; Fri, 10 Nov 2000 03:59:18 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-175.dialup.zetnet.co.uk [194.247.40.222] claimed to be zetnet.co.uk Message-ID: Date: Fri, 10 Nov 2000 08:49:39 +0000 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: I-D ACTION:draft-ietf-tls-kerb-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A0BB6A3.2806F5D6@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Internet-Drafts@ietf.org wrote: > Title : Kerberos Cipher Suites in Transport Layer > Security (TLS) > Author(s) : M. Hur, A. Medvinsky > Filename : draft-ietf-tls-kerb-00.txt > Pages : > Date : 08-Nov-00 This references the KRB5 ciphersuites from RFC 2712, and adds three more: CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 }; CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 }; CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 }; CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 }; CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A }; CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B }; CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? }; TLS_KRB5_WITH_NULL_NULL is a really bad idea, and I cannot see any legitimate use for it. Note that *no* existing ciphersuites that can be negotiated have a NULL MAC, so adding such a ciphersuite is a significant protocol change that can only weaken security. (There is also little point in adding TLS_KRB5_WITH_NULL_MD5.) Something similar to the following note from RFC 2712 should be put in the text of the new draft, and extended to the 56-bit single DES ciphersuites (TLS_KRB5_WITH_DES_CBC_{SHA,MD5}). # IESG Note: # # The 40-bit ciphersuites defined in this memo are included only for # the purpose of documenting the fact that those ciphersuite codes have # already been assigned. 40-bit ciphersuites were designed to comply # with US-centric, and now obsolete, export restrictions. They were # never secure, and nowadays are inadequate even for casual # applications. Implementation and use of the 40-bit ciphersuites # defined in this document, and elsewhere, is strongly discouraged. IMHO the draft should say that the 40- and 56-bit ciphersuites SHOULD NOT be used. Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), is that this code is also assigned by [FKK96], for SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. The draft should also say that the KRB5 ciphersuites do not provide forward secrecy, and are vulnerable to off-line dictionary attacks [Wu99]. There's a technical change needed to the CertificateRequest message that the draft does not make clear: struct { ClientCertificateType certificate_types<1..2^8-1>; /* KeyExchangeAlgorithm is determined by ServerHello.ciphersuite */ select (KeyExchangeAlgorithm) { case krb5: KerbInfo kerberos_info; default: DistinguishedName certificate_authorities<3..2^16-1>; } } CertificateRequest; Also, the kerberos client certificate type MUST NOT be included in certificate_types for non-Kerberos ciphersuites, and other certificate types MUST NOT be included for Kerberos ciphersuites (this is needed to make the interpretation of CertificateRequest unambiguous). [FKK96] Alan O. Freier, Philip Karlton, Paul C. Kocher, "The SSL Protocol Version 3.0," Internet draft (work in progress, expired March 1997). draft-freier-ssl-version3-02.txt http://home.netscape.com/eng/ssl3/draft302.txt [Wu99] Thomas Wu, "A real world analysis of Kerberos password security," In Proceedings of the 1999 Internet Society Network and Distributed System Security Symposium. - -- 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 iQEVAwUBOgu2jDkCAxeYt5gVAQFOrwf/UVbWO+wliVKHSglYalz/dOBcKM65D8T2 sKaDwxMO5g51iow5mkWj9G9eZ7pYBHIjndAcpUPbRHp/An1fDgrnkqqdbdeidJDO rkCJws3AjRoeUfNeuqTSK6QeHbNP4LIop/8UfzDxAd3Z1DmDvMc3V/Cp4dFfHRur 6UWu/ro/irr3PMvC6R7cdtKK7dl6kzYHmwZh0A4oH9ba3fZPAdX0utRh6nC72Y2R molB6RGSM0CDXEKqVO0DrUFYFXRJZjf2cVGrUqZR31odXP8rP9tcdSfAvdxBcm9Q I5Ure4MDhkyvl3wGuSNooYBrEgPm6K699QFF0muA7SKv4f31q2V8eA== =bZN0 -----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 Nov 10 03:59: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 DAA08618 for ; Fri, 10 Nov 2000 03:59:37 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-175.dialup.zetnet.co.uk [194.247.40.222] claimed to be zetnet.co.uk Message-ID: Date: Fri, 10 Nov 2000 08:49:39 +0000 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: I-D ACTION:draft-ietf-tls-kerb-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A0BB6A3.2806F5D6@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Internet-Drafts@ietf.org wrote: > Title : Kerberos Cipher Suites in Transport Layer > Security (TLS) > Author(s) : M. Hur, A. Medvinsky > Filename : draft-ietf-tls-kerb-00.txt > Pages : > Date : 08-Nov-00 This references the KRB5 ciphersuites from RFC 2712, and adds three more: CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 }; CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 }; CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 }; CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 }; CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A }; CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B }; CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? }; TLS_KRB5_WITH_NULL_NULL is a really bad idea, and I cannot see any legitimate use for it. Note that *no* existing ciphersuites that can be negotiated have a NULL MAC, so adding such a ciphersuite is a significant protocol change that can only weaken security. (There is also little point in adding TLS_KRB5_WITH_NULL_MD5.) Something similar to the following note from RFC 2712 should be put in the text of the new draft, and extended to the 56-bit single DES ciphersuites (TLS_KRB5_WITH_DES_CBC_{SHA,MD5}). # IESG Note: # # The 40-bit ciphersuites defined in this memo are included only for # the purpose of documenting the fact that those ciphersuite codes have # already been assigned. 40-bit ciphersuites were designed to comply # with US-centric, and now obsolete, export restrictions. They were # never secure, and nowadays are inadequate even for casual # applications. Implementation and use of the 40-bit ciphersuites # defined in this document, and elsewhere, is strongly discouraged. IMHO the draft should say that the 40- and 56-bit ciphersuites SHOULD NOT be used. Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), is that this code is also assigned by [FKK96], for SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. The draft should also say that the KRB5 ciphersuites do not provide forward secrecy, and are vulnerable to off-line dictionary attacks [Wu99]. There's a technical change needed to the CertificateRequest message that the draft does not make clear: struct { ClientCertificateType certificate_types<1..2^8-1>; /* KeyExchangeAlgorithm is determined by ServerHello.ciphersuite */ select (KeyExchangeAlgorithm) { case krb5: KerbInfo kerberos_info; default: DistinguishedName certificate_authorities<3..2^16-1>; } } CertificateRequest; Also, the kerberos client certificate type MUST NOT be included in certificate_types for non-Kerberos ciphersuites, and other certificate types MUST NOT be included for Kerberos ciphersuites (this is needed to make the interpretation of CertificateRequest unambiguous). [FKK96] Alan O. Freier, Philip Karlton, Paul C. Kocher, "The SSL Protocol Version 3.0," Internet draft (work in progress, expired March 1997). draft-freier-ssl-version3-02.txt http://home.netscape.com/eng/ssl3/draft302.txt [Wu99] Thomas Wu, "A real world analysis of Kerberos password security," In Proceedings of the 1999 Internet Society Network and Distributed System Security Symposium. - -- 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 iQEVAwUBOgu2jDkCAxeYt5gVAQFOrwf/UVbWO+wliVKHSglYalz/dOBcKM65D8T2 sKaDwxMO5g51iow5mkWj9G9eZ7pYBHIjndAcpUPbRHp/An1fDgrnkqqdbdeidJDO rkCJws3AjRoeUfNeuqTSK6QeHbNP4LIop/8UfzDxAd3Z1DmDvMc3V/Cp4dFfHRur 6UWu/ro/irr3PMvC6R7cdtKK7dl6kzYHmwZh0A4oH9ba3fZPAdX0utRh6nC72Y2R molB6RGSM0CDXEKqVO0DrUFYFXRJZjf2cVGrUqZR31odXP8rP9tcdSfAvdxBcm9Q I5Ure4MDhkyvl3wGuSNooYBrEgPm6K699QFF0muA7SKv4f31q2V8eA== =bZN0 -----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 Nov 10 08:42:02 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 IAA27195 for ; Fri, 10 Nov 2000 08:42:01 -0500 (EST) Message-ID: From: "Hidenori Ohta" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] CipherSuite numbers Date: Fri, 10 Nov 2000 22:41:15 +0900 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <014c01c04b1b$e6210de0$32054a0a@crimefighter> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit All, I looked for the list of registered CipherSuite from the web page of IANA. But I cannot find any information about TLS. So I picked up the CipherSuite numbers from RFCs and I-Ds. --- defined CipherSuites --- TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 } RFC2246 TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 } RFC2246 TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 } RFC2246 TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 } RFC2246 TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 } RFC2246 TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 } RFC2246 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 } RFC2246 TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 } RFC2246 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 } RFC2246 TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 } RFC2246 TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A } RFC2246 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B } RFC2246 TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C } RFC2246 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D } RFC2246 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E } RFC2246 TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F } RFC2246 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 } RFC2246 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 } RFC2246 TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 } RFC2246 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 } RFC2246 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 } RFC2246 TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 } RFC2246 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 } RFC2246 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 } RFC2246 TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 } RFC2246 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 } RFC2246 TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A } RFC2246 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B } RFC2246 *** Reserved for Fortezza-based CS *** { 0x00,0x1C } RFC2246 *** Reserved for Fortezza-based CS *** { 0x00,0x1D } RFC2246 TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E } RFC2712 TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F } RFC2712 TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 } RFC2712 TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 } RFC2712 TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 } RFC2712 TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 } RFC2712 TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 } RFC2712 TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 } RFC2712 TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 } RFC2712 TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 } RFC2712 TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 } RFC2712 TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 } RFC2712 TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A } RFC2712 TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B } RFC2712 --- proposed CipherSuites --- 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_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x2F } TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x30 } TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x31 } TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x32 } TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x33 } TLS_DH_anon_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x34 } TLS_RSA_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x35 } TLS_DH_DSS_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x36 } TLS_DH_RSA_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x37 } TLS_DHE_DSS_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x38 } TLS_DHE_RSA_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x39 } TLS_DH_anon_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x3A } TLS_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x3B } TLS_DH_DSS_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x3C } TLS_DH_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x3D } TLS_DHE_DSS_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x3E } TLS_DHE_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x3F } TLS_DH_anon_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x40 } TLS_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0xXX } TLS_DH_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0xXX } TLS_DH_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0xXX } TLS_DHE_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0xXX } TLS_DHE_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0xXX } TLS_DH_anon_WITH_MISTY1_CBC_SHA = { 0x00,0xXX } TLS_KRB5_WITH_NULL_SHA = { 0x00,0x?? } TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x?? } TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? } As you know, some proposed CipherSuites have no number, and some numbers conflict. I think we must re-allocate and allocate the numbers for proposed CipherSuites. We have 2 possibilities of allocating method. 1: We will give high-priority to AES, and AES will be allocated lower numbers. 2: We will fix only the conflicted CipherSuites. There are the lists that follow the possibilities. List 1: TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2C } TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x2D } TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2E } TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x2F } TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x30 } TLS_RSA_WITH_SEED_CBC_MD5 = { 0x00,0x31 } TLS_RSA_WITH_SEED_CBC_SHA = { 0x00,0x32 } TLS_RSA_WITH_SEED_CBC_HAS160 = { 0x00,0x33 } TLS_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x34 } TLS_DH_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0x35 } TLS_DH_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x36 } TLS_DHE_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0x37 } TLS_DHE_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x38 } TLS_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x39 } TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3A } TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3B } TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3C } TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3D } TLS_RSA_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x3E } TLS_DH_DSS_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x3F } TLS_DH_RSA_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x40 } TLS_DHE_DSS_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x41 } TLS_DHE_RSA_WITH_CAMELLIA_CBC_192_SHA = { 0x00,0x42 } TLS_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x43 } TLS_DH_DSS_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x44 } TLS_DH_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x45 } TLS_DHE_DSS_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x46 } TLS_DHE_RSA_WITH_CAMELLIA_CBC_256_SHA = { 0x00,0x47 } TLS_KRB5_WITH_NULL_SHA = { 0x00,0x48 } TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x49 } [delete?] TLS_KRB5_WITH_NULL_NULL = { 0x00,0x4A } [delete?] List 2: 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 } [ following #'s are same as List 1] How do you think of them? regards -- Hidenori Ohta Mitsubishi Electric Corporation e-mail: hidenori@iss.isl.melco.co.jp --- 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 Nov 10 10:10:27 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 KAA00617 for ; Fri, 10 Nov 2000 10:10:26 -0500 (EST) Message-ID: Date: Fri, 10 Nov 2000 16:09:30 +0100 From: Mathieu Arnold Organization: http://www.mat.cc/ X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: CipherSuite numbers 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: <3A0C0FAA.79382204@club-internet.fr> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hidenori Ohta wrote: > > All, > > I looked for the list of registered CipherSuite from the web > page of IANA. But I cannot find any information about TLS. > So I picked up the CipherSuite numbers from RFCs and I-Ds. have a look at the 2246 RFC... Network Working Group T. Dierks Request for Comments: 2246 Certicom Category: Standards Track C. Allen Certicom January 1999 The TLS Protocol Version 1.0 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. -- Mathieu Arnold --- 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 Nov 10 10:23:07 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 KAA04874 for ; Fri, 10 Nov 2000 10:23:06 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-kerb-00.txt 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: 10 Nov 2000 07:26:42 -0800 In-Reply-To: David Hopwood's message of "Fri, 10 Nov 2000 08:49:39 +0000" Message-ID: Lines: 12 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 David Hopwood writes: > CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x?? }; > CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x?? }; > CipherSuite TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? }; > > > TLS_KRB5_WITH_NULL_NULL is a really bad idea, and I cannot see any > legitimate use for it. I agree. I suspect this is just a search and replace error. -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 Fri Nov 10 14:01:23 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 OAA23939 for ; Fri, 10 Nov 2000 14:01:22 -0500 (EST) Message-Id: X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Nov 2000 11:02:04 -0800 To: "IETF Transport Layer Security WG" From: Matthew Hur Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-kerb-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <4.3.2.7.2.20001110105134.00b97ce0@mira-sjc5-5.cisco.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thanks for the comments. Responses are below. --Matt At 08:49 AM 11/10/2000 +0000, David Hopwood wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Internet-Drafts@ietf.org wrote: > > Title : Kerberos Cipher Suites in Transport Layer > > Security (TLS) > > Author(s) : M. Hur, A. Medvinsky > > Filename : draft-ietf-tls-kerb-00.txt > > Pages : > > Date : 08-Nov-00 > >This references the KRB5 ciphersuites from RFC 2712, and adds three >more: > > CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; > CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; > CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; > CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; > CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; > CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; > CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; > CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; > > CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 }; > CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A }; > CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B }; > > CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x?? }; > CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x?? }; > CipherSuite TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? }; > > >TLS_KRB5_WITH_NULL_NULL is a really bad idea, and I cannot see any >legitimate use for it. Note that *no* existing ciphersuites that can be >negotiated have a NULL MAC, so adding such a ciphersuite is a significant >protocol change that can only weaken security. (There is also little >point in adding TLS_KRB5_WITH_NULL_MD5.) As Eric stated in his email, TLS_KRB5_WITH_NULL_NULL was a search and replace error. I will remove it. >Something similar to the following note from RFC 2712 should be put in >the text of the new draft, and extended to the 56-bit single DES >ciphersuites (TLS_KRB5_WITH_DES_CBC_{SHA,MD5}). > ># IESG Note: ># ># The 40-bit ciphersuites defined in this memo are included only for ># the purpose of documenting the fact that those ciphersuite codes have ># already been assigned. 40-bit ciphersuites were designed to comply ># with US-centric, and now obsolete, export restrictions. They were ># never secure, and nowadays are inadequate even for casual ># applications. Implementation and use of the 40-bit ciphersuites ># defined in this document, and elsewhere, is strongly discouraged. That note has already been included in the draft (see appendix B). >IMHO the draft should say that the 40- and 56-bit ciphersuites SHOULD >NOT be used. I'll add a note in the security considerations section. >Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), >is that this code is also assigned by [FKK96], for >SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. You are referring to an internet draft that expired in March 1997? >The draft should also say that the KRB5 ciphersuites do not provide >forward secrecy, and are vulnerable to off-line dictionary attacks [Wu99]. See the security considerations section. >There's a technical change needed to the CertificateRequest message that >the draft does not make clear: > > struct { > ClientCertificateType certificate_types<1..2^8-1>; > /* KeyExchangeAlgorithm is determined by ServerHello.ciphersuite */ > select (KeyExchangeAlgorithm) { > case krb5: > KerbInfo kerberos_info; > default: > DistinguishedName certificate_authorities<3..2^16-1>; > } > } CertificateRequest; > >Also, the kerberos client certificate type MUST NOT be included in >certificate_types for non-Kerberos ciphersuites, and other certificate >types MUST NOT be included for Kerberos ciphersuites (this is needed to >make the interpretation of CertificateRequest unambiguous). OK >[FKK96] Alan O. Freier, Philip Karlton, Paul C. Kocher, > "The SSL Protocol Version 3.0," > Internet draft (work in progress, expired March 1997). > draft-freier-ssl-version3-02.txt > http://home.netscape.com/eng/ssl3/draft302.txt > >[Wu99] Thomas Wu, > "A real world analysis of Kerberos password security," > In Proceedings of the 1999 Internet Society Network and > Distributed System Security Symposium. > >- -- >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 > >iQEVAwUBOgu2jDkCAxeYt5gVAQFOrwf/UVbWO+wliVKHSglYalz/dOBcKM65D8T2 >sKaDwxMO5g51iow5mkWj9G9eZ7pYBHIjndAcpUPbRHp/An1fDgrnkqqdbdeidJDO >rkCJws3AjRoeUfNeuqTSK6QeHbNP4LIop/8UfzDxAd3Z1DmDvMc3V/Cp4dFfHRur >6UWu/ro/irr3PMvC6R7cdtKK7dl6kzYHmwZh0A4oH9ba3fZPAdX0utRh6nC72Y2R >molB6RGSM0CDXEKqVO0DrUFYFXRJZjf2cVGrUqZR31odXP8rP9tcdSfAvdxBcm9Q >I5Ure4MDhkyvl3wGuSNooYBrEgPm6K699QFF0muA7SKv4f31q2V8eA== >=bZN0 >-----END PGP SIGNATURE----- > > >--- >You are currently subscribed to ietf-tls as: mhur@cisco.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 Fri Nov 10 14:09:49 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 OAA26774 for ; Fri, 10 Nov 2000 14:09:48 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-kerb-00.txt 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: 10 Nov 2000 11:13:27 -0800 In-Reply-To: Matthew Hur's message of "Fri, 10 Nov 2000 11:02:04 -0800" Message-ID: Lines: 11 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 Matthew Hur writes: > >Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), > >is that this code is also assigned by [FKK96], for > >SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. > > You are referring to an internet draft that expired in March 1997? True, but these cipher suites are in deployment, at least inside NSA. Since we've got enough cipher suite numbers to play around with... -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 Fri Nov 10 16:09:14 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 QAA07110 for ; Fri, 10 Nov 2000 16:09:13 -0500 (EST) Message-Id: X-Sender: mhur@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Nov 2000 12:24:17 -0800 To: "IETF Transport Layer Security WG" From: Matthew Hur Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-kerb-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <4.3.2.7.2.20001110122037.00b41cf0@mira-sjc5-5.cisco.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net OK - I'll blank out that ciphersuite, and we can re-assign a number to it if no one objects. --Matt At 11:13 AM 11/10/2000 -0800, you wrote: >Matthew Hur writes: > > >Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), > > >is that this code is also assigned by [FKK96], for > > >SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. > > > > You are referring to an internet draft that expired in March 1997? >True, but these cipher suites are in deployment, at least inside >NSA. Since we've got enough cipher suite numbers to play >around with... > >-Ekr > >--- >You are currently subscribed to ietf-tls as: mhur@cisco.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 Fri Nov 10 18:41:23 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 SAA18961 for ; Fri, 10 Nov 2000 18:41:22 -0500 (EST) Message-ID: Date: Fri, 10 Nov 2000 15:41:12 -0800 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [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: I-D ACTION:draft-ietf-tls-kerb-00.txt 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: <3A0C8798.CB0611ED@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Matthew Hur wrote: > At 08:49 AM 11/10/2000 +0000, David Hopwood wrote: > >Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), > >is that this code is also assigned by [FKK96], for > >SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. > > You are referring to an internet draft that expired in March 1997? Well, yes, it is an expired draft. It's also essentially THE spec for SSL3 as implemented in all Netscape browsers, and presumably most other browsers and clients that implement SSL3. All Netscape 4.x browsers implement and recognize (00,1E) as SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. I'd rather avoid having the value (00,1E) have different meaning in SSL3 than in TLS. BTW, while we're on this topic, would anyone object to the draft [FKK96] being submitted as a "historic" or "informational" RFC (not standards track) for the purpose of finally having a real IETF RFC that documents the existing practice of SSL3? -- 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 Fri Nov 10 18:46: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 SAA20015 for ; Fri, 10 Nov 2000 18:46:21 -0500 (EST) Date: Fri, 10 Nov 2000 18:46:09 EST From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-kerb-00.txt In-Reply-To: Your message of Fri, 10 Nov 2000 15:41:12 -0800 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > BTW, while we're on this topic, would anyone object to the draft [FKK96] > being submitted as a "historic" or "informational" RFC (not standards track) > for the purpose of finally having a real IETF RFC that documents the > existing practice of SSL3? I am attempting to argue in favor of something similar in the SSH community. I highly encourage that this be done BUT only with the following qualification: someone must write the pre-amble to this document that explains why it should not be used. otherwise, it is pointless to publish it as people will continue to implement SSL3 intead of TLS in their applications. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Sat Nov 11 01:26:45 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 BAA07599 for ; Sat, 11 Nov 2000 01:26:44 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-024.dialup.zetnet.co.uk [194.247.41.29] claimed to be zetnet.co.uk Message-ID: Date: Sat, 11 Nov 2000 00:44:47 +0000 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] Resubmitting the SSL3 draft (was draft-ietf-tls-kerb-00.txt) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A0C967F.914F2921@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Nelson Bolyard wrote: > BTW, while we're on this topic, would anyone object to the draft [FKK96] > being submitted as a "historic" or "informational" RFC (not standards > track) for the purpose of finally having a real IETF RFC that documents > the existing practice of SSL3? I think that would be a very good idea (with a pre-amble as suggested by Jeffrey Altman). It should probably note the Bleichenbacher attack on PKCS #1 (which is prevented in most newish versions of SSL3 servers), the { 0x00,0x1E } conflict, and possibly the 56-bit ciphersuites (which are also not currently documented in any RFC). It should also have the "export and single-DES ciphersuites are bad" notice. - -- 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 iQEVAwUBOgyWVTkCAxeYt5gVAQEu/gf/WcmrSC/xgfNMTojWsKW/p4jkdHDlooHT hhf3CbMkVB4Md6LPYw5JdilIwjrgVpIgXDPQDGSDmIqntHc0SqEUy590laHLEVA+ 3vOYC1YaNtSVDJ0WforBz4Jor1f7Qo4CL7p/2oo8AY/eKN1MZzZCZ6MJcJOQaPEw Oy1tQPRm7TIyYm9mci8PwjUgCIeIeqEnpi7esn1B8GEOxHZ2BLp9jNGtSkcTbGzb AFbpaB8YGI+wpeCsVbDxlorCLtMLyJnpPFZGa1R/c69Ui/Tsu99SMKPOTLvchilD A/Wclo78T+hrxLaDGNbDUyN4FZFC3H4oqzyR53qVhBkTwt5D9u9TLg== =25j3 -----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 Sat Nov 11 01:26: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 BAA07713 for ; Sat, 11 Nov 2000 01:26:55 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-024.dialup.zetnet.co.uk [194.247.41.29] claimed to be zetnet.co.uk Message-ID: Date: Sat, 11 Nov 2000 06:25:27 +0000 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: I-D ACTION:draft-ietf-tls-kerb-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A0CE657.28E267F8@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Matthew Hur wrote: > David Hopwood wrote: > >Another reason to deprecate { 0x00,0x1E } (TLS_KRB5_WITH_DES_CBC_SHA), > >is that this code is also assigned by [FKK96], for > >SSL_FORTEZZA_KEA_WITH_RC4_128_SHA. > > You are referring to an internet draft that expired in March 1997? It's the current specification of SSL 3.0, and is described as such on Netscape's site. All that the new draft really needs to do is note the conflict. In another article: > OK - I'll blank out that ciphersuite, and we can re-assign a number > to it if no one objects. Why bother, given that it's single DES? > >The draft should also say that the KRB5 ciphersuites do not provide > >forward secrecy, and are vulnerable to off-line dictionary attacks [Wu99]. > > See the security considerations section. Ah, for some reason I missed that. The first sentence of that section should probably be # Kerberos ciphersuites are subject to the security considerations of # both the TLS protocol, and the Kerberos 5 protocol [KERB]. A minor correction to my previous post: > struct { > ClientCertificateType certificate_types<1..2^8-1>; > /* KeyExchangeAlgorithm is determined by ServerHello.ciphersuite */ should be cipher_suite ^^^^^^^^^^^ > select (KeyExchangeAlgorithm) { > case krb5: > KerbInfo kerberos_info; > default: > DistinguishedName certificate_authorities<3..2^16-1>; > } > } CertificateRequest; I don't have any further comments. - -- 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 iQEVAwUBOgyRKDkCAxeYt5gVAQFIUAgAi/asVelzjh8aHRgMed9tUQ4DFPIezfWp GQdvM36sDx6/zHUlH1A3rsTIhFmDfZVglZ5BwY+nPRYe7b/BED++q7If2PjbM3RK nS2a3/JpWklftxoIcHY+V6RfyLYR2UKAwGxXZxG4cc75ZtvqaTBoHIne9Xgfraod ZCX9ie0EEDLVfUqpUf3s2rn1vch8QuMqPB4XOVHLcWdGHcTmaaz6hgPkt/IiVM5u xBEry+zlA0MDt+PLYerHB2z80amL7G61qsTGRZQHyOEnETIzK97Mcp4BEwV5L796 3B47wJ54IkhS2ZarUYck32OkQl+BvGWaeOKcaBnAf+QA2LbqPn41sA== =sI0O -----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 Wed Nov 15 11:36:18 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 LAA06524 for ; Wed, 15 Nov 2000 11:36:17 -0500 (EST) Date: Wed, 15 Nov 2000 16:35:06 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] New AES ciphersuites draft Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i 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: <20001115163506.B2108@hyena.skygate.co.uk> X-List-Host: SKYLIST.net I have made a new version of the AES ciphersuite draft available. It can currently be downloaded from: ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-02.txt In addition, the version on the IETF website should be updated soon. Please let me know any comments which you have. The major changes with this update are: 1. A ADH ciphersuite is now included (which is not deprecated), with an appropriate security warning at the end of the document. 2. The document now indicates what an implementation must do in order to be interoperable. Of course, any two TLS implementations should be interoperable, regardless of whether they implement AES. However, I want to ensure that two TLS implementations supporting AES can always negotiate an AES ciphersuite. -- 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 Thu Nov 16 06:30: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 GAA10328 for ; Thu, 16 Nov 2000 06:30:51 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ciphersuite-02.txt Date: Thu, 16 Nov 2000 06:28:45 -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200011161128.GAA09410@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES Ciphersuites for TLS Author(s) : P. Chown Filename : draft-ietf-tls-ciphersuite-02.txt Pages : 8 Date : 15-Nov-00 At present, the symmetric ciphers supported by TLS are RC2, RC4, IDEA, DES and triple DES. The protocol would be enhanced by the addition of AES [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 RC4 algorithm itself is a trade secret. Ascom Systec Ltd owns a patent on the IDEA algorithm. 2. Triple DES is much less efficient than more modern ciphers. 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 therefore 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 forward secrecy. This document proposes two new ciphersuites, with the aim of over¡ coming these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ciphersuite-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ciphersuite-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001115123523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ciphersuite-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ciphersuite-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001115123523.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Thu Nov 23 03:30:06 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 DAA12835 for ; Thu, 23 Nov 2000 03:30:02 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Reply-To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft Date: Thu, 23 Nov 2000 17:29:34 +0900 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200011230829.RAA07324@blue.h2np.net> X-List-Host: SKYLIST.net I'm a newcomer in TLS mailing list. I have a question about key length of symmetric cipher in proposals of TLS cipher suites. Pete Chown recommended AES with 128 bits key length in his new AES ciphersuites draft. Hidenori Ohta recommended Camellia 128,192,256 bits key length in his lists. I don't understand why they recommend 128 (or 192) bits key length. I know that Rijndael and Camellia have different rounds between 128. 192, 256 bits key length. But it's a small different for performance. From my point of view, there is no reason and no value to prepare 128,192,256 bits key length specification at same time. Shall we select only 256 bits key length which is most trusted one? -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- 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 Nov 23 06:59:53 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 GAA25840 for ; Thu, 23 Nov 2000 06:59:52 -0500 (EST) Date: Thu, 23 Nov 2000 11:59:01 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hironobu@h2np.net on Thu, Nov 23, 2000 at 05:29:34PM +0900 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: <20001123115901.F6925@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Hironobu SUZUKI wrote: > Pete Chown recommended AES with 128 bits key length in his new AES > ciphersuites draft. Hidenori Ohta recommended Camellia 128,192,256 > bits key length in his lists. > > I don't understand why they recommend 128 (or 192) bits key length. Originally I proposed 256 bits, but there is really nothing to be gained that I can see. If AES-128 was broken it would be such a massive advance in either hardware or cryptanalysis that we would have to rethink everything anyway. I wonder, actually, if AES-256 is meant to guard against a large advance in quantum computing. To provide security in this environment I believe you would need to double the key lengths of symmetric ciphers. However, at the same time, current public key cryptosystems would become unusably weak. TLS would therefore be useless... Presumably we would have to start using something more like Kerberos! The other point is that the public key cryptosystems would have to have ridiculously long keys to give the same resistance to attack that AES-256 would have. It is obvious that there is no benefit to fielding a PKI system where some elements are much stronger than others -- an attacker will always go for the weak link. > I know that Rijndael and Camellia have different rounds between > 128. 192, 256 bits key length. But it's a small different for > performance. It is a small difference, but IMHO it should be the deciding factor, because there is no reason to use a longer key. Incidentally there is also a theoretical issue with using longer keys, in that more entropy is consumed from the master secret. It is therefore theoretically possible that AES-256 could be less secure than AES-128. (I don't see this as a very important issue, but I thought I would explain the reasons underlying it.) -- 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 Thu Nov 23 21:41:20 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 VAA27172 for ; Thu, 23 Nov 2000 21:41:19 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft In-reply-to: Your message of "Thu, 23 Nov 2000 11:59:01 GMT." Date: Fri, 24 Nov 2000 11:41:04 +0900 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: <200011240241.LAA08388@blue.h2np.net> X-List-Host: SKYLIST.net > From: Pete Chown > Subject: [ietf-tls] Re: New AES ciphersuites draft > > Originally I proposed 256 bits, but there is really nothing to be > gained that I can see. If AES-128 was broken it would be such a > massive advance in either hardware or cryptanalysis that we would have > to rethink everything anyway. I'm sorry that I didn't read your original proposal. New cryptanalysis technique has appeared in every year. For example, Skipjack seems un-secure cipher today because Biham and Shamir developed new cryptanalysis. It took few year after Skipjack was opened. I know that Rijndael-128 is enough today. But after next 5 year, nobody knows new effective cryptanalysis will be appeared. In AES 3rd conference at NY, some people mentioned that Rijndael had few security margin and some people recommened to add 3 or more rounds. If new effective cryptoanalysis is appeared then we should add AES-192, AES-256 into new cipher-suites of TLS. Why not AES-256 first? > However, at the same time, current public key cryptosystems > would become unusably weak. TLS would therefore be useless... 100% agree with you if QC is appeared. First of all, an arithmetical public key system will be broken. Then we can add Okamoto's QC public key system into TLS. It seems good than an arithmetical public key system :-) > It is a small difference, but IMHO it should be the deciding factor, > because there is no reason to use a longer key. AES-256 has more security margin than AES-128. > > Incidentally there is also a theoretical issue with using longer keys, > in that more entropy is consumed from the master secret. It is > therefore theoretically possible that AES-256 could be less secure > than AES-128. I agree with you there is "POSSIBILITY" of master secret entropy problem. But also there is possible that total security of TLS is depended on entropy of master secret, isn't depended on key lentgh of symmetric cipher. Anyway, there is no proof. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- 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 Nov 24 05:50:36 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 FAA17801 for ; Fri, 24 Nov 2000 05:50:35 -0500 (EST) Message-ID: From: "Hidenori Ohta" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft Date: Fri, 24 Nov 2000 19:49:57 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <01f701c05604$49c85ea0$32054a0a@crimefighter> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hironobu-san, > Pete Chown recommended AES with 128 bits key length in his new AES > ciphersuites draft. Hidenori Ohta recommended Camellia 128,192,256 > bits key length in his lists. I just picked up the ciphersuites from the current Internet-Drafts and numbered them. ;-) On Fri, 06 Oct 2000 15:31:15 JST, Shiho MORIAI wrote: > * The number of ciphersuites > > Since Camellia supports three key sizes, 128, 192, and 256 bits, > similarly to the AES, I simply defined ciphersuites for Camellia with > each key size. So there are 18 ciphersuites in total. However, I > will define only necessary ciphersuites following the AES > ciphersuites. I also remove a DH-anon ciphersuite, since I just > followed the 3DES ciphersuites in RFC2246. I missed these sentences. Moriai-san will drop 192 and 256 bits when she will update the draft. So, here is a new list. 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_MISTY1_CBC_SHA = { 0x00,0x35 } TLS_DH_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0x36 } TLS_DH_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x37 } TLS_DHE_DSS_WITH_MISTY1_CBC_SHA = { 0x00,0x38 } TLS_DHE_RSA_WITH_MISTY1_CBC_SHA = { 0x00,0x39 } TLS_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3A } TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3B } TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3C } TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3D } TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA = { 0x00,0x3E } TLS_KRB5_WITH_NULL_SHA = { 0x00,0x3F } TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x40 } > Shall we select only 256 bits key length which is most trusted one? If we will select new public-key cyrptosystem which has the same strength as the strength of 256-bits secret-key cryptosystem, we should say yes. Regards. -- Hidenori Ohta --- 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 Nov 24 06:14:44 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 GAA25472 for ; Fri, 24 Nov 2000 06:14:43 -0500 (EST) Date: Fri, 24 Nov 2000 11:13:53 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hironobu@h2np.net on Fri, Nov 24, 2000 at 11:41:04AM +0900 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: <20001124111353.C8812@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Hironobu SUZUKI wrote: > New cryptanalysis technique has appeared in every year. For example, > Skipjack seems un-secure cipher today because Biham and Shamir > developed new cryptanalysis. It took few year after Skipjack was > opened. We are talking about different things here though. Skipjack's weakness doesn't really result from its short keys. Skipjack was declassified in June 1998 and serious weaknesses were discovered within only a few months. None of the AES finalists had anything like this level of vulnerability. > I know that Rijndael-128 is enough today. But after next 5 year, > nobody knows new effective cryptanalysis will be appeared. In AES 3rd > conference at NY, some people mentioned that Rijndael had few security > margin and some people recommened to add 3 or more rounds. So is your point that we should use AES-256 because it has more rounds rather than because it has longer keys? > 100% agree with you if QC is appeared. But at the moment quantum computing is the only possible hope for breaking a 128-bit key by brute force. Distributed.net is up to 30% of RC5-64 and is testing around around 140 billion keys per second. The search is likely to take a couple more years. Breaking a 128-bit key the same way and in the same time would take about 10**19 times as much processing power. > I agree with you there is "POSSIBILITY" of master secret entropy > problem. But also there is possible that total security of TLS is > depended on entropy of master secret, isn't depended on key lentgh of > symmetric cipher. Anyway, there is no proof. Which do you think is more likely? A mathematical problem with the entropy in the master secret or an increase in computing power by a factor of 10**19? -- 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 Nov 24 07:05:48 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 HAA11667 for ; Fri, 24 Nov 2000 07:05:47 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft In-reply-to: Your message of "Fri, 24 Nov 2000 11:13:53 GMT." Date: Fri, 24 Nov 2000 21:05:29 +0900 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: <200011241205.VAA09722@blue.h2np.net> X-List-Host: SKYLIST.net > So is your point that we should use AES-256 because it has more > rounds rather than because it has longer keys? Bacialy YES. And also more key space. > Breaking a 128-bit key the same way and in the same time would take > about 10**19 times as much processing power. I agree with you that 128-bit is safe in DESChall style situation, brute force attack. Cryptanalysis is not same as brute force attack. Cryptanalysis have been coming, differencal, liner, truncated-diff, boomerang, impossible-diff, slide, etc.etc.etc. In fact, DES was broke in 7 days with 20 workstations by Shimoyama's developed liner-diff attack in 1998. He didn't need EFF DES cracker and distribute.net. What's next? I don't know. Ross Anderson who is one of designer of SERPENT said "I recommend SERPENT-256 for AES" in 3rd AES conference. I agree with him. Rijndael/AES is also. There is very small different beetween 128, 192 and 256bit key length. Why not 256? Must I think about the master secret problem? -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- 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 Nov 24 07:24:15 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 HAA17478 for ; Fri, 24 Nov 2000 07:24:14 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] MISTY1 and CAMELLIA (Re: New AES ciphersuites draft ) In-reply-to: Your message of "Fri, 24 Nov 2000 19:49:57 +0900." Date: Fri, 24 Nov 2000 21:23:59 +0900 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: <200011241223.VAA09740@blue.h2np.net> X-List-Host: SKYLIST.net My technical point of view, I don't need Misty1 and Camellia at same time. I never mention about license/commercial/political thing. I talk only technical thing. I have thought that Camellia was builded on E2 and MISTY technology. This is my understanding as bellow. DES New sbox design technique Liner attack for chip/hardware study ---------->MISTY -----------------------------> Kasumi | sbox design and | simple key schedule V (FEAL ------->) E2 ---------------------------> Camellia Feistel AES style key/block length, structure network and pre/post-whiting study structure technique If I use/implement Camellia, I never use/implement MISTY1. PS. I don't need any patented algos any more. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- 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 Sun Nov 26 10:55: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 KAA07523 for ; Sun, 26 Nov 2000 10:55:25 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] Re: New AES ciphersuites draft In-reply-to: Your message of "Fri, 24 Nov 2000 21:05:29 JST." Date: Mon, 27 Nov 2000 00:55:06 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200011261555.AAA02148@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hironobu SUZUKI wrote: >Ross Anderson who is one of designer of SERPENT said "I recommend >SERPENT-256 for AES" in 3rd AES conference. I agree with him. >Rijndael/AES is also. There is very small different beetween 128, 192 >and 256bit key length. Why not 256? The TLS protocol is (and will be extensively) also used on low-end terminals such as mobile phones or hand-held terminals. Thinking of computing power provided by such terminals, we should have the ciphersuites for AES-128. However, if some people need a sense of greater security, we may add the ciphersuites for AES-192 and AES-256, too. Do many ciphersuites make implementation complicated? (I don't think so. I like a wide range of choices!) Basically, I think 128-bit key length is enough for use of next 10-20 years (as NIST says). However, I don't know whether AES-128 has a high security margin for use of next 10-20 years. IMHO, if a certain problem should be found in AES-128, AES-128 with more rounds would be used, instead of AES-192 or AES-256. (Then, more rounds would be added to AES-192 and AES-256, too.) Shiho Moriai --- 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 Sun Nov 26 19:44:47 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 TAA10448 for ; Sun, 26 Nov 2000 19:44:46 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] Re: New AES ciphersuites draft In-reply-to: Your message of "Mon, 27 Nov 2000 00:55:06 +0200." Date: Mon, 27 Nov 2000 09:44:29 +0900 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: <200011270044.JAA13441@blue.h2np.net> X-List-Host: SKYLIST.net > However, if some people need a sense of greater security, we may add > the ciphersuites for AES-192 and AES-256, too. I will agree with you if AES-192, AES-256 is added to TLS specs. I've got the "freedom of choice". DEVO! :-) And I'll use AES-256 as default cipher-suite. > > Do many ciphersuites make implementation complicated? Case by case. Rijndael's round structure is very simple "rounds loop" and is NOT required an additional code except loop branch codes in software implementation. Camellia is required addtional codes for 192/256( but cost is small as well as other AES finalist ). -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net --- 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 Sun Nov 26 20:04:11 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 UAA14581 for ; Sun, 26 Nov 2000 20:04:10 -0500 (EST) Message-ID: Date: Mon, 27 Nov 2000 01:10:31 +0000 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: New AES ciphersuites draft 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: <3A21B487.77BE3D25@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Since AES is also a variable block length cipher should we explicitly state the block length? I assume its 128 bits... 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 Sun Nov 26 21:03: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 VAA02168 for ; Sun, 26 Nov 2000 21:03:53 -0500 (EST) Date: Sun, 26 Nov 2000 21:03:41 -0500 (EST) From: Peter W X-Sender: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net At 9:44am Nov 27, 2000, Hironobu SUZUKI wrote: > > However, if some people need a sense of greater security, we may add > > the ciphersuites for AES-192 and AES-256, too. > > I will agree with you if AES-192, AES-256 is added to TLS specs. Is anyone really interested in AES-192 ? Or are AES-128 / AES-256 enough? -Peter --- 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 Sun Nov 26 21:06: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 VAA02922 for ; Sun, 26 Nov 2000 21:06:57 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: New AES ciphersuites draft In-reply-to: Your message of "Sun, 26 Nov 2000 21:03:41 EST." Date: Mon, 27 Nov 2000 11:06:47 +0900 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: <200011270206.LAA13518@blue.h2np.net> X-List-Host: SKYLIST.net > Is anyone really interested in AES-192 ? Or are AES-128 / AES-256 enough? Ya, you're right. --hironobu --- 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 Mon Nov 27 12:51: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 MAA01750 for ; Mon, 27 Nov 2000 12:51:36 -0500 (EST) Date: Mon, 27 Nov 2000 17:50:00 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Other AES key lengths Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hironobu@h2np.net on Fri, Nov 24, 2000 at 09:05:29PM +0900 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: <20001127175000.E29932@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Okay, it would be useful to have as many views as possible on this key length issue. This should hopefully help us arrive at a consensus. If you want AES-192 and/or AES-256, please could you also let us know which, and how you would like to see interoperability dealt with. Hironobu SUZUKI wrote: > Cryptanalysis is not same as brute force attack. Cryptanalysis have > been coming, differencal, liner, truncated-diff, boomerang, > impossible-diff, slide, etc.etc.etc. In fact, DES was broke in 7 days > with 20 workstations by Shimoyama's developed liner-diff attack in > 1998. He didn't need EFF DES cracker and distribute.net. On the other hand, even now the DES ciphersuites in TLS would normally deliver their design strength. None of the attacks on DES would work against TLS unless it was used in a rather artificial way. Hopefully the AES has drawn on the lessons of DES and provides better security. Would you feel happy using AES-256 if AES-128 had been broken in a significant way? I wouldn't. I think if there was an attack on AES-128 that was significant enough to work in a real world situation it would call the *whole* cipher into question. Shiho MORIAI wrote: > The TLS protocol is (and will be extensively) also used on low-end > terminals such as mobile phones or hand-held terminals. Thinking of > computing power provided by such terminals, we should have the > ciphersuites for AES-128. Fair enough. > Do many ciphersuites make implementation complicated? > (I don't think so. I like a wide range of choices!) Hmm. TLS is already complicated enough. Even if you don't mind the extra effort, there is much more scope for bugs if you add extra ciphersuites. Dr S N Henson wrote: > Since AES is also a variable block length cipher should we explicitly > state the block length? I assume its 128 bits... It is stated in the ciphersuite definitions -- do you feel it should be stated somewhere else as well? Finally, please could everyone have a think whether there is anything else that needs to be changed with the draft. That way I can make all the changes at once and we can hopefully get everything finished off. Of course, *I* am happy with everything in the draft, because I wrote it! But it is more important to get this right than to get it approved quickly -- the draft is already vastly improved on my original effort -- so please keep the suggestions coming. -- 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 Mon Nov 27 13:12:39 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 NAA10300 for ; Mon, 27 Nov 2000 13:12:38 -0500 (EST) Message-ID: Date: Mon, 27 Nov 2000 18:18:54 +0000 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: Other AES key lengths 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: <3A22A58E.DBB5DC86@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > > Dr S N Henson wrote: > > > Since AES is also a variable block length cipher should we explicitly > > state the block length? I assume its 128 bits... > > It is stated in the ciphersuite definitions -- do you feel it should > be stated somewhere else as well? > Is it? I can see several references to the key length being 128 bits but no reference to the block length being 128 bits, or have I missed something obvious? 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 Mon Nov 27 14:12:45 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 OAA03335 for ; Mon, 27 Nov 2000 14:12:43 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Other AES key lengths Date: Mon, 27 Nov 2000 20:12:21 +0100 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <00c501c058a5$f7d71510$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > Okay, it would be useful to have as many views as possible on this key > length issue. This should hopefully help us arrive at a consensus. > If you want AES-192 and/or AES-256, please could you also let us know > which, and how you would like to see interoperability dealt with. Obviously a 128 bit key for AES will be strong enough for the next decades, except if: (a) AES has a fundumental security flaw. Even if AES with 192 and 256 would remain secure in that case, people would soon stop using AES altogether. (b) quantum cryptography or another major cryptographic breakthrough happens. In that case TLS would most likely have to be reworked, in particular the MAC algorithms replaced and all root certificates deployed in software exchanged. Hence I am not be in favor of adding another 6 or 12 ciphersuites to TLS. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- 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 Mon Nov 27 14:23: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 OAA07013 for ; Mon, 27 Nov 2000 14:23:42 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] MISTY1 and CAMELLIA Ciphersuites Date: Mon, 27 Nov 2000 20:23:23 +0100 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <00f201c058a7$82c9a650$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit What is the general opinion about the proposed MISTY1 and CAMELLIA ciphersuites? Without having really studied the algorithms I do not quite see the advantages over existing TLS ciphers and AES, given that: (a) AES is available worldwide without any legal encumberings. This is not the case for MISTY1 and CAMELLIA. (b) MISTY1 and CAMELLIA will never receive the same cryptanalytic attention as AES. (c) AES will be implemented in virtually all future cryptographic software and hardware. Maybe the supporters can shed some light on this. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- 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 Nov 28 06:02:42 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 GAA05310 for ; Tue, 28 Nov 2000 06:02:41 -0500 (EST) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Tue, 28 Nov 2000 06:01:58 -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200011281101.GAA04963@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Wireless Extensions to TLS Author(s) : S. Blake-Wilson Filename : draft-ietf-tls-wireless-00.txt Pages : 13 Date : 27-Nov-00 This document suggests extensions to TLS designed to make TLS more amenable to use within wireless environments. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-wireless-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-wireless-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001127133424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-wireless-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-wireless-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001127133424.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Tue Nov 28 06:23:06 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 GAA15303 for ; Tue, 28 Nov 2000 06:23:05 -0500 (EST) Date: Tue, 28 Nov 2000 11:22:04 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Other AES key lengths Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drh@celocom.com on Mon, Nov 27, 2000 at 06:18:54PM +0000 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: <20001128112204.A8771@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Dr S N Henson wrote: > Is it? I can see several references to the key length being 128 bits but > no reference to the block length being 128 bits, or have I missed > something obvious? Oh! Sorry, I was so sure you ought to be talking about key length that I didn't read your message properly. :-) I'll add a clarification about this at the same time as I make whatever changes are agreed about key lengths. (For me, AES would imply 128-bit blocks, since that was the requirement of the AES process. However I agree that this should be spelled out.) -- 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 Tue Nov 28 06:23:53 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 GAA15654 for ; Tue, 28 Nov 2000 06:23:53 -0500 (EST) Date: Tue, 28 Nov 2000 11:23:07 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Other AES key lengths Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Andreas.Sterbenz@iaik.at on Mon, Nov 27, 2000 at 08:12:21PM +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: <20001128112307.B8771@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Andreas Sterbenz wrote: > Hence I am not be in favor of adding another 6 or 12 ciphersuites to TLS. Thanks. The views of people who agree with me are always the most welcome! :-) -- 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 Tue Nov 28 11:56:23 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 LAA29692 for ; Tue, 28 Nov 2000 11:56:22 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Tue, 28 Nov 2000 11:48:28 -0500 Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <852569A5.005CA908.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi folks, Magnus Nystrom and I posted this draft to try and get some discussion going about the possibility of extending TLS to make life easier for wireless clients. It seemed a little long to post straight to the mailing list ... We'd really appreciate positive and negative comments (well okay, we'd prefer positive comments, but ...) Best regards. Simon ---------------------- Forwarded by Simon Blake-Wilson/Certicom on 11/28/2000 11:43 AM --------------------------- Internet-Drafts@ietf.org on 11/28/2000 06:01:58 AM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: ietf-tls@lists.certicom.com (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Wireless Extensions to TLS Author(s) : S. Blake-Wilson Filename : draft-ietf-tls-wireless-00.txt Pages : 13 Date : 27-Nov-00 This document suggests extensions to TLS designed to make TLS more amenable to use within wireless environments. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-wireless-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-wireless-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. mailto:mailserv@ietf.org ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt --- You are currently subscribed to ietf-tls as: sblakewilson@certicom.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 Tue Nov 28 16:25: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 QAA22251 for ; Tue, 28 Nov 2000 16:25:17 -0500 (EST) Message-Id: X-Sender: rodney@limbo.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 28 Nov 2000 11:13:23 -0800 To: "IETF Transport Layer Security WG" From: Rodney Thayer Subject: [ietf-tls] Re: Other AES key lengths In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.0.25.2.20001128111102.02b64c10@limbo.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, stepping into this thread late. It seems to me you are saying "AES will not be broken therefore don't add other ciphersuites". Is that what you meant? I've been advocating, for a while now, that we need multiple ciphersuites in these protocols. Crypto, unlike protocol design, is "not known not to work". We cannot assume AES won't be broken tomorrow. That would be Architecturally Irresponsible(TM). Of course we don't expect this, but we should not be designing for this assumption. Of course, the current state of affairs, plus or minus AES, is that we have several ciphersuites anyway. At 08:12 PM 11/27/00 +0100, Andreas Sterbenz wrote: > > Okay, it would be useful to have as many views as possible on this key > > length issue. This should hopefully help us arrive at a consensus. > > If you want AES-192 and/or AES-256, please could you also let us know > > which, and how you would like to see interoperability dealt with. > >Obviously a 128 bit key for AES will be strong enough for the next decades, >except if: > >(a) AES has a fundumental security flaw. Even if AES with 192 and 256 would >remain secure in that case, people would soon stop using AES altogether. > >(b) quantum cryptography or another major cryptographic breakthrough >happens. In that case TLS would most likely have to be reworked, in >particular the MAC algorithms replaced and all root certificates deployed in >software exchanged. > >Hence I am not be in favor of adding another 6 or 12 ciphersuites to TLS. > > Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at > > > > >--- >You are currently subscribed to ietf-tls as: rodney@tillerman.to >To unsubscribe send a blank email to >leave-ietf-tls-3458737E@lists.certicom.com -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOiQD0z/0TyQ4fTjtEQLxdwCfSeYjno4GJIwb1o8CJOFTH97N7bUAoICB NbDcEQtPY7Py534Tt+uUm1kC =o7bt -----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 Tue Nov 28 21:30:53 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 VAA20391 for ; Tue, 28 Nov 2000 21:30:52 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Other AES key lengths In-reply-to: Your message of "Mon, 27 Nov 2000 17:50:00 GMT." Date: Wed, 29 Nov 2000 11:30:31 +0900 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: <200011290230.LAA16328@blue.h2np.net> X-List-Host: SKYLIST.net Pete Chown : > > Okay, it would be useful to have as many views as possible on this > key length issue. This should hopefully help us arrive at a > consensus. If you want AES-192 and/or AES-256, please could you > also let us know which, and how you would like to see > interoperability dealt with . I don't familiar with this TLS ML discussion. Anyway, I'd like to make a list of ciphersuites for AES 128/192/256 as below. 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_192_CBC_SHA = { 0x00,0x35 } TLS_DH_DSS_WITH_AES_192_CBC_SHA = { 0x00,0x36 } TLS_DH_RSA_WITH_AES_192_CBC_SHA = { 0x00,0x37 } TLS_DHE_DSS_WITH_AES_192_CBC_SHA = { 0x00,0x38 } TLS_DHE_RSA_WITH_AES_192_CBC_SHA = { 0x00,0x39 } TLS_DH_anon_WITH_AES_192_CBC_SHA = { 0x00,0x3A } TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x3B } TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x3C } TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x3D } TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x3E } TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x3F } TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x40 } > On the other hand, even now the DES ciphersuites in TLS would > normally deliver their design strength. None of the attacks on DES > would work against TLS unless it was used in a rather artificial > way. Your expression sounds unsuitable for secuirty. I never heard that TLS's ciphersuites which involved with DES_40 or RC4_40 was broken. So far, I can say that "None of the attacks on DES_40 and RC4_40 would work against TLS". But it might be wrong. Is there someone who believes it is safe? Nobody knows tomorrow. And I want to use better one. > Hmm. TLS is already complicated enough. Even if you don't mind the > extra effort, there is much more scope for bugs if you add extra > ciphersuites. Basically Yes. But the difference in AES_128/192/256 is only key length. Basically, AES_128/192/256 is used same codes in software implementation, no additional costs. We can get big advantage with tiny costs. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- 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 Nov 29 03:01:19 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 DAA27314 for ; Wed, 29 Nov 2000 03:01:16 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] Re: MISTY1 and CAMELLIA Ciphersuites In-reply-to: Your message of "Mon, 27 Nov 2000 20:23:23 +0100." Date: Wed, 29 Nov 2000 16:59:15 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200011290759.QAA21087@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I'd like to make some comments as a designer of Camellia and a writer of draft-ietf-tls-camellia-00.txt. Andreas Sterbenz wrote: >Without having really studied the algorithms I do not quite see the >advantages over existing TLS ciphers and AES, given that: > >(a) AES is available worldwide without any legal encumberings. This >is not the case for MISTY1 and CAMELLIA. (1) The intellectual property statement of Camellia regarding royalty-free license is now under review by NTT and Mitsubishi Electric Corporation. I hope the problem of worldwide royalty-free availability of Camellia will be solved by the end of this year. >(b) MISTY1 and CAMELLIA will never receive the same cryptanalytic >attention as AES. (2) Camellia was designed based on the experiences of the design and development of E2 and MISTY. E2 was published in 1998 and received much cryptanalytic attention as a candidate of the AES during the AES Round 1 process. MISTY was published in 1996 and has been received much cryptanalysis, too. Recently, 3GPP adopted a variant of MISTY1, which is called KASUMI, as the confidentiality and integrity algorithm for the W-CDMA mobile systems after the elaborate evaluation process. Camellia has been scrutinized during the design phase by the designers (including Matsui, who is the inventor of linear cryptanalysis), and also by external experts including some of the designers of the AES finalists. Their technical papers are available at http://info.isl.ntt.co.jp/camellia/. Moreover, Camellia was submitted to the NESSIE project (http://www.cryptonessiee.org/) and the CRYPTREC project (http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html) where the submitted cryptographic techniques will be evaluated. Camellia was announced in March 2000 for the first time, and presented at SAC2000 and CRYPTO2000 (rump session) this summer. The promising algorithms always receive cryptanalytic attention. >(c) AES will be implemented in virtually all future cryptographic >software and hardware. (3) I believe that TLS need backup/alternative algorithms to AES, i.e. block ciphers with the same block size and key sizes. We believe that Camellia can be a nice complement cipher to AES, because it has many advantages over AES (strictly speaking, Rijndael, as the proposed AES). * Efficiency in hardware implementations - Smaller hardware: 9.66 Kgates (0.35micron ASIC) - Better Throughput/Area: 21.9Mbit/(sec*Kgates) - Much more efficient in implementing BOTH encryption and decryption (Rijndael needs more additional area in implementing both encryption and decryption.) * Excellent Key Agility - Shorter key setup time Ex) 128bit key, for Encryption Camellia: 160 cycles [Pentium III, Assembly] 263 cycles [Pentium II, ANSI C] Rijndael: 305 cycles [Pentium Pro/II, Visual C++] by Gladman - Supports on-the-fly subkey computation for both encryption and decryption (Rijndael requires a one-time execution of the key schedule prior to the first decryption with a specific key.) * Symmetric Encryption and Decryption (because Camellia is a Feistel cipher) - Little additional area to implement both encryption and decryption in hardware - Little additional resources are favorable in restricted-space environments * Good JAVA Performance - Encryption Speed is 36Mbit/sec on Pentium II 300MHz. Compared with the AES finalists using Sterbenz and Lipp's data presented at the 3rd AES conference, Camellia is faster than Rijndael (and the second fastest among the AES finalists.) * Comparable performance on 8-bit CPUs e.g. Z80 Further detailed information about performance figures and comparison is available at the URL below. http://info.isl.ntt.co.jp/camellia/ Shiho Moriai --- 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 Nov 29 04:03: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 EAA25462 for ; Wed, 29 Nov 2000 04:03:24 -0500 (EST) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: MISTY1 and CAMELLIA Ciphersuites In-reply-to: Your message of "Wed, 29 Nov 2000 16:59:15 +0200." Date: Wed, 29 Nov 2000 18:02:21 +0900 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: <200011290902.SAA16700@blue.h2np.net> X-List-Host: SKYLIST.net > (1) The intellectual property statement of Camellia regarding > royalty-free license is now under review by NTT and Mitsubishi > Electric Corporation. I hope the problem of worldwide royalty-free > availability of Camellia will be solved by the end of this year. It's sounds great! But if Camellia royalty-free license is like as MISTY1, it's not enough for me and many people. I wrote MISTY1 C code and distributed it as GPL in 11 January 1998. URL: http://www.pp.iij4u.or.jp/~h2np MISTY1 free license is permitted for academic (non-profit) use. But it have been uncleared what academic (non-profit) is. And There is no obvious definition of "academic", "non-profit" and "commercial". MISTY1 situation made me very confused. I've thought that MISTY1 was the best choice in 1998 but legal issues was the worst. Could you make your optimized Camellia C/Java codes as GPL? GPL licensed codes is very clear to use as "royality-free" code. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- 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 Nov 29 07:47:48 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 HAA06699 for ; Wed, 29 Nov 2000 07:47:45 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Other AES key lengths Date: Wed, 29 Nov 2000 13:46:51 +0100 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <007601c05a02$725436d0$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > It seems to me you are saying "AES will not be broken therefore > don't add other ciphersuites". Is that what you meant? I've No, what I am saying is that AES with 256 bit keys is not a good backup for AES with 128 bit keys. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- 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 Nov 29 09:07: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 JAA04400 for ; Wed, 29 Nov 2000 09:07:07 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Wed, 29 Nov 2000 15:05:10 +0100 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <009601c05a0d$6313ca90$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I like the draft, here are my comments: . Although not related to wireless environments, I believe the initial set of extensions should include the DNSname extension. . Maximum record size extension: . The maximum record size for TLS is not 2^14 bytes, that is the maximum amount of application data per record. The maximum record size is header + plain data size + compression size increase + padding + mac. The wording should clarify this. . I think the server should be allowed to respond with a size different than that requested by the client. The client can still accept the size selected by the server of abort the handshake. . Some maximum record sizes (e.g. 256 bytes) may be smaller than some handshake messages (e.g. certificate message). This is not a problem during the initial handshake because the document specifies that the maximum record size does not take effect until after the change cipher spec messages have been sent. However, this may be a problem during a renegotiating handshake which needs to be addressed in some way. . Client certificate URL extension: . The document seems to imply that the URL points to a certificate chain in the usual TLS format although this is not explicitly said. This should be clarified. . It may also makes sense to make recommendations wrt the protocols for the URL (http, etc.) . There seems to be the assumption that the handshake is a full handshake. Although there seem to be no changes required for an abbreviated handshake this should be stated explicitly. . The document does not specify if the negotiated parameters, in particular max. record size and MAC truncation, are associated with this connection only or with the session. I.e. do the parameters have to be negotiated again for subsequent connections using the same master secret? . Truncated MACs may be better suited to the next TLS version, however, it may take some time before that arrives. . It should be more clearly defined what "clients MAY abort the handshake," etc. means, i.e. which alert is to be sent. That may include defining new alert messages. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----- Original Message ----- From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Sent: Tuesday, November 28, 2000 5:48 PM Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt > Hi folks, > > Magnus Nystrom and I posted this draft to try and get some discussion going > about the possibility of extending TLS to make life easier for wireless clients. > It seemed a little long to post straight to the mailing list ... > > We'd really appreciate positive and negative comments (well okay, we'd prefer > positive comments, but ...) > > Best regards. Simon --- 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 Nov 30 05:39:48 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 FAA21377 for ; Thu, 30 Nov 2000 05:39:46 -0500 (EST) Date: Thu, 30 Nov 2000 11:39:04 +0100 (MET) From: Magnus Nystrom Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: 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 FAA21377 Andreas, Thanks for your insightful comments. On Wed, 29 Nov 2000, Andreas Sterbenz wrote: > I like the draft, here are my comments: > > . Although not related to wireless environments, I believe the initial set > of extensions should include the DNSname extension. If there is a consensus on this, we could certainly include it (actually, this is the reason to reserve (0) in the ExtensionType enumeration...). > . Maximum record size extension: > . The maximum record size for TLS is not 2^14 bytes, that is the maximum > amount of application data per record. The maximum record size is header + > plain data size + compression size increase + padding + mac. The wording > should clarify this. Yes, will do. > . I think the server should be allowed to respond with a size different > than that requested by the client. The client can still accept the size > selected by the server of abort the handshake. Why? The client has indicated its maximum size, what would the reason be for the server to use a smaller size? > . Some maximum record sizes (e.g. 256 bytes) may be smaller than some > handshake messages (e.g. certificate message). This is not a problem during > the initial handshake because the document specifies that the maximum record > size does not take effect until after the change cipher spec messages have > been sent. However, this may be a problem during a renegotiating handshake > which needs to be addressed in some way. This is a good observation, but will it become a problem in practice? I.e. even if a 256-bit maximum record size has been negotiated, won't the effect (during a re-negotiation) b just less-than-optimal number of handshake messages? > . Client certificate URL extension: > . The document seems to imply that the URL points to a certificate chain > in the usual TLS format although this is not explicitly said. This should be > clarified. Actually, no. The intent is to point to _a_ client certificate. In this case, the server will have to do the chaining itself. > . It may also makes sense to make recommendations wrt the protocols for > the URL (http, etc.) True. And also the kind of schemes that must be supported by servers. We will include this in the next revision. > . There seems to be the assumption that the handshake is a full handshake. > Although there seem to be no changes required for an abbreviated handshake > this should be stated explicitly. Good point. > . The document does not specify if the negotiated parameters, in particular > max. record size and MAC truncation, are associated with this connection > only or with the session. I.e. do the parameters have to be negotiated again > for subsequent connections using the same master secret? That was not the intent. Basically, all negotiated parameters should be part of the state for the connection. We discussed whether or not to include a description of this in this version of the memo, but decided not to (perhaps a bad decision), while we realized that it must be done at some point. > . Truncated MACs may be better suited to the next TLS version, however, it > may take some time before that arrives. > > . It should be more clearly defined what "clients MAY abort the handshake," > etc. means, i.e. which alert is to be sent. That may include defining new > alert messages. Yes, will be done. Thanks, -- Magnus ----- Original Message ----- > From: "Simon Blake-Wilson" > To: "IETF Transport Layer Security WG" > Sent: Tuesday, November 28, 2000 5:48 PM > Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-wireless-00.txt > > > > Hi folks, > > > > Magnus Nystrom and I posted this draft to try and get some discussion > going > > about the possibility of extending TLS to make life easier for wireless > clients. > > It seemed a little long to post straight to the mailing list ... > > > > We'd really appreciate positive and negative comments (well okay, we'd > prefer > > positive comments, but ...) > > > > Best regards. Simon > > > > --- > You are currently subscribed to ietf-tls as: magnus@dynas.se > To unsubscribe send a blank email to leave-ietf-tls-3174482S@lists.certicom.com > -- Magnus Magnus Nyström RSA Security --- 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 Nov 30 12:31:50 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 MAA19510 for ; Thu, 30 Nov 2000 12:31:49 -0500 (EST) Date: Thu, 30 Nov 2000 12:30:58 EST From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Assignment of Numbers for Compression Algorithms in TLS Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net What is the status on assignment of numbers for use in TLS in general and specificly for the implementation of compression algorithms? Years ago Eric Young added RLE and ZLIB compression to his SSLeay package and I want to use them in OpenSSL. On some connections I have seen dramatic improvements in performance with the use of compression. The specific implementation is for TLS Telnet with X Windows Forwarding and TLS FTP. Have numbers been assigned? If so, what are they? If not, what is the approved method for allocation? I don't see any TLS related registration lists at the IANA site. Thanks. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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