From mailman-bounces@ietf.org Fri Oct 1 05:42:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11019 for ; Fri, 1 Oct 2004 05:42:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDK4A-0002t1-Sp for tls-archive@ietf.org; Fri, 01 Oct 2004 05:51:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJRz-0004Fs-A5 for tls-archive@ietf.org; Fri, 01 Oct 2004 05:11:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: tls-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:01:56 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for tls-archive@ietf.org: List Password // URL ---- -------- tls@lists.ietf.org akviiw https://www1.ietf.org/mailman/options/tls/tls-archive%40ietf.org From tls-bounces@ietf.org Tue Oct 5 05:05:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05183; Tue, 5 Oct 2004 05:05:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CElOQ-0006Io-LQ; Tue, 05 Oct 2004 05:14:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEl8q-0002h2-B8; Tue, 05 Oct 2004 04:57:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEl72-0002Iw-Sd for tls@megatron.ietf.org; Tue, 05 Oct 2004 04:56:00 -0400 Received: from universe.uohyd.ernet.in ([202.41.85.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04250 for ; Tue, 5 Oct 2004 04:55:56 -0400 (EDT) Received: from ailab.uohyd.ernet.in (ailab.uohyd.ernet.in [202.41.85.117]) by universe.uohyd.ernet.in (8.9.0/8.9.0) with ESMTP id OAA02094 for ; Tue, 5 Oct 2004 14:22:41 -0500 (GMT) Received: from ailab.uohyd.ernet.in (ailab [127.0.0.1]) by ailab.uohyd.ernet.in (8.12.8/8.12.8) with ESMTP id i958tZtm017881 for ; Tue, 5 Oct 2004 14:25:35 +0530 Received: (from apache@localhost) by ailab.uohyd.ernet.in (8.12.8/8.12.8/Submit) id i958tY30017879; Tue, 5 Oct 2004 14:25:34 +0530 X-Authentication-Warning: ailab.uohyd.ernet.in: apache set sender to hussam@localhost using -f Received: from 202.41.85.20 (proxying for 202.41.85.116) (SquirrelMail authenticated user hussam) by 202.41.85.117 with HTTP; Tue, 5 Oct 2004 14:25:34 +0530 (IST) Message-ID: <52691.202.41.85.20.1096966534.squirrel@202.41.85.117> Date: Tue, 5 Oct 2004 14:25:34 +0530 (IST) From: "Hussam Saeed" To: In-Reply-To: <200409301605.i8UG4ZQk006038@uohyd.ernet.in> References: <200409301605.i8UG4ZQk006038@uohyd.ernet.in> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [TLS] optional session X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 8bit what is the optional session has been made to reduce the number of connections in TLS? why we are XORing the plaintext with the output generated from PRF in the stream cipher encryption? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 07:22:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16313; Tue, 5 Oct 2004 07:22:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEnY7-0000c9-A6; Tue, 05 Oct 2004 07:32:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnJv-0000jb-6Y; Tue, 05 Oct 2004 07:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnGa-0000Gu-Az for tls@megatron.ietf.org; Tue, 05 Oct 2004 07:14:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15646 for ; Tue, 5 Oct 2004 07:13:57 -0400 (EDT) Received: from ray.idi.ntnu.no ([129.241.107.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEnPr-0007dZ-38 for tls@ietf.org; Tue, 05 Oct 2004 07:23:35 -0400 Received: from vier.idi.ntnu.no (vier.idi.ntnu.no [129.241.107.65]) by ray.idi.ntnu.no (8.12.10/8.12.10) with ESMTP id i95BDr4a011926 for ; Tue, 5 Oct 2004 13:13:53 +0200 (MEST) Received: (from josteitv@localhost) by vier.idi.ntnu.no (8.12.10/8.12.9/Submit) id i95BDqsS008008; Tue, 5 Oct 2004 13:13:52 +0200 (MEST) X-Authentication-Warning: vier.idi.ntnu.no: josteitv set sender to Jostein.Tveit@idi.ntnu.no using -f To: Subject: Re: [TLS] optional session References: <200409301605.i8UG4ZQk006038@uohyd.ernet.in> <52691.202.41.85.20.1096966534.squirrel@202.41.85.117> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Tue, 05 Oct 2004 13:13:52 +0200 In-Reply-To: <52691.202.41.85.20.1096966534.squirrel@202.41.85.117> (Hussam Saeed's message of "Tue, 5 Oct 2004 14:25:34 +0530 (IST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.4 required=1 X-Virus-Scanned: by amavisd-new-IDI X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab "Hussam Saeed" writes: > what is the optional session has been made to reduce the number of > connections in TLS? Do you mean optional session caching? Session caching is a mechanism to reduce the cost of establishing a new SSL connection. You can read about session caching in RFC2246 or "SSL and TLS" by Eric Rescorla. > why we are XORing the plaintext with the output generated from PRF in the > stream cipher encryption? To encrypt the plaintext :) -- Jostein Tveit (Jostein.Tveit@idi.ntnu.no) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 08:38:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22169; Tue, 5 Oct 2004 08:38:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEojW-0004O1-5I; Tue, 05 Oct 2004 08:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEoYi-0002G4-9x; Tue, 05 Oct 2004 08:36:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEoUD-0001Y9-8J for tls@megatron.ietf.org; Tue, 05 Oct 2004 08:32:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21833 for ; Tue, 5 Oct 2004 08:32:08 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEodU-00037L-0Y for tls@ietf.org; Tue, 05 Oct 2004 08:41:45 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i95CW6h19678 for ; Tue, 5 Oct 2004 15:32:06 +0300 (EET DST) X-Scanned: Tue, 5 Oct 2004 15:31:56 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i95CVumq001676 for ; Tue, 5 Oct 2004 15:31:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00Mb9vdM; Tue, 05 Oct 2004 15:31:54 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i95CVrY14818 for ; Tue, 5 Oct 2004 15:31:53 +0300 (EET DST) Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Oct 2004 15:31:48 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Oct 2004 15:31:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Straw poll on draft-ietf-tls-ecc-* Date: Tue, 5 Oct 2004 15:31:45 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD17835E@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Straw poll on draft-ietf-tls-ecc-* Thread-Index: AcSlsq1OCbfvtIsYSU6vl+zIdxzIIgFIlTBQ To: X-OriginalArrivalTime: 05 Oct 2004 12:31:46.0426 (UTC) FILETIME=[474EE5A0:01C4AAD7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable I vote for "A", too. No matter what other opinions I may have about these ciphersuites, this work is clearly something that some=20 people want to use, and thus I believe the document=20 should be published as RFC.=20 Option "B" would seem to quite unnecessarily remove=20 functionality from the protcol, and while "C" would be a=20 possible choice too, I think "A" is the most straightforward way to go forward. Best regards, Pasi > -----Original Message----- > From: Eric Rescorla > Sent: Wednesday, September 29, 2004 1:56 AM > To: tls@ietf.org > Subject: [TLS] Straw poll on draft-ietf-tls-ecc-* >=20 >=20 > This is a Straw Poll in the fate of draft-ietf-tls-ecc-*. >=20 > Please register your support for one of the following three > options, explained in a previous message. >=20 > A. Advance draft-ietf-tls-ecc-* to Proposed Standard. > B. Advance draft-ietf-tls-ecc-* as Informational and remove > the extensions. > C. Advance draft-ietf-tls-ecc-* as Informational with the > extensions. Amend RFC 3456 to allow extensions without > a Standards Action. >=20 > This Straw Poll will run for the next week (through Tuesday > October 5th.) Please register your opinion by then, either > to me or to the list. >=20 > -Ekr >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 14:32:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23248; Tue, 5 Oct 2004 14:32:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEuGN-0006Wl-PV; Tue, 05 Oct 2004 14:42:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEu5u-0006RS-G9; Tue, 05 Oct 2004 14:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEtts-0004mW-5g for tls@megatron.ietf.org; Tue, 05 Oct 2004 14:19:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22217 for ; Tue, 5 Oct 2004 14:18:58 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEu3B-0004Uw-Kx for tls@ietf.org; Tue, 05 Oct 2004 14:28:39 -0400 Received: from phys-ha14sca-1.sfbay.sun.com ([129.145.155.210]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i95IIs4d024531 for ; Tue, 5 Oct 2004 11:18:54 -0700 (PDT) Received: from [192.18.148.102] by ha14sca-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Jul 26 2004)) with ESMTPA id <0I5400CWPIVGIX90@ha14sca-mail1.sfbay.sun.com> for tls@ietf.org; Tue, 05 Oct 2004 11:18:52 -0700 (PDT) Date: Tue, 05 Oct 2004 11:18:54 -0700 From: Julien Pierre Subject: Re: [TLS] Straw poll on draft-ietf-ecc-tls-* (Explanation) In-reply-to: <20040928230824.D41B1717F@sierra.rtfm.com> To: Eric Rescorla Message-id: <4162E58E.4090704@sun.com> MIME-version: 1.0 X-Accept-Language: en-us, en References: <20040928230824.D41B1717F@sierra.rtfm.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040518 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1905071505==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is a cryptographically signed message in MIME format. --===============1905071505== Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms040500050101060504070002 This is a cryptographically signed message in MIME format. --------------ms040500050101060504070002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric, Eric Rescorla wrote: >A. Advance draft-ietf-tls-ecc-* to Proposed Standard. > > I vote for A . --------------ms040500050101060504070002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJmzCC AygwggKRoAMCAQICAwv7oDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzI0MDAxODUwWhcNMDUwMzI0MDAxODUw WjCBgzEPMA0GA1UEBBMGUGllcnJlMQ8wDQYDVQQqEwZKdWxpZW4xFjAUBgNVBAMTDUp1bGll biBQaWVycmUxJDAiBgkqhkiG9w0BCQEWFWp1bGllbi5waWVycmVAc3VuLmNvbTEhMB8GCSqG SIb3DQEJARYSbWFkYnJhaW5AcmF3YncuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAlMOsQ/xqNZoyx8JLvLTtJbTt6SzU51d7HXToZZpHhcv1xgx8SgQ/6eoUl+FtDxOc tPIA2XyS24dKs1HLEA1J1vjiYRsfZeUg4bJviiqrdoUh5c6KABbWHXy16KV5t1l79liR7kHb Ly6duyJbXESFwvsCp/4UH22j53KXm2N7sBYP0EpZbKp86daeanxYhS23cC1oCkX5IPWh/u9S athibwQ8glrUUCSttjSgDS6eXV8eTOcaqM+qdLNzBd1s6P9rpua4dRfFw3xrTesdyMF6mTW/ A7a1ZwCUpWV+9PmKlnNejDFnA9knTfSP/QIMreSR4lP0jv7z0T4sxq37xQeO0QIDAQABo0Yw RDA0BgNVHREELTArgRVqdWxpZW4ucGllcnJlQHN1bi5jb22BEm1hZGJyYWluQHJhd2J3LmNv bTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADKA44fOhod3uCz/gkPinacRYbAV 3t/xsbMm1oF3Xbk2243tgEMEiS8leIg7J2ly+Rdc4KKmDmlZONvDU55WCUWM4UP5PSnTGTRI EPQr2X5wN15g7WCS3C3uKvDpgvmofCsNZcM9deBWXpKd0qIEW6euo96ikQzDTXd5vMmiJVLf MIIDKDCCApGgAwIBAgIDC/ugMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAzMjQwMDE4NTBaFw0wNTAzMjQwMDE4 NTBaMIGDMQ8wDQYDVQQEEwZQaWVycmUxDzANBgNVBCoTBkp1bGllbjEWMBQGA1UEAxMNSnVs aWVuIFBpZXJyZTEkMCIGCSqGSIb3DQEJARYVanVsaWVuLnBpZXJyZUBzdW4uY29tMSEwHwYJ KoZIhvcNAQkBFhJtYWRicmFpbkByYXdidy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCUw6xD/Go1mjLHwku8tO0ltO3pLNTnV3sddOhlmkeFy/XGDHxKBD/p6hSX4W0P E5y08gDZfJLbh0qzUcsQDUnW+OJhGx9l5SDhsm+KKqt2hSHlzooAFtYdfLXopXm3WXv2WJHu QdsvLp27IltcRIXC+wKn/hQfbaPncpebY3uwFg/QSllsqnzp1p5qfFiFLbdwLWgKRfkg9aH+ 71Jq2GJvBDyCWtRQJK22NKANLp5dXx5M5xqoz6p0s3MF3Wzo/2um5rh1F8XDfGtN6x3IwXqZ Nb8DtrVnAJSlZX70+YqWc16MMWcD2SdN9I/9Agyt5JHiU/SO/vPRPizGrfvFB47RAgMBAAGj RjBEMDQGA1UdEQQtMCuBFWp1bGllbi5waWVycmVAc3VuLmNvbYESbWFkYnJhaW5AcmF3Yncu Y29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAMoDjh86Gh3e4LP+CQ+KdpxFh sBXe3/GxsybWgXdduTbbje2AQwSJLyV4iDsnaXL5F1zgoqYOaVk428NTnlYJRYzhQ/k9KdMZ NEgQ9CvZfnA3XmDtYJLcLe4q8OmC+ah8Kw1lwz114FZekp3SogRbp66j3qKRDMNNd3m8yaIl Ut8wggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEW HHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2 MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9 zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPP K9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGj gZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEB BQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9 reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo0 5RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwv7oDAJBgUrDgMCGgUAoIIBpzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMDUxODE4NTRa MCMGCSqGSIb3DQEJBDEWBBSKcTd+ehQUBkQ3yLZcBi9N8crGPTBSBgkqhkiG9w0BCQ8xRTBD MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDC/ugMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwv7oDANBgkqhkiG9w0B AQEFAASCAQBdRvGEqRUhrmTNvHmOlGamtr8VvNTaggYdbMX1eO63RL0q/VQPBLnonUX/9OXq JyJOqav7VRzop+yIfcneOxoH1Hc51EuVo5nYsisXaHSlwzcw1yIdkuQlDqin5UEKnATR+FYG 3w4KSPWpa8jBiH/aMztgNSZR/FQRyHE654tsM5pPE0d/mWLafD25V+NtzyfTqh3rRDuDWO6s oOwDuuw0ix01vKad5sFr/qEnxeZ13JTb5Bus4CFZVrmnq61ngUMxW6bIIMy46MkXaCrG8POv JFZa7elztt1s4lQgIYFimMpeAUK41faEzroI5+Rt0X4eGgM/P2lflS8Yw2TI/cXQAAAAAAAA --------------ms040500050101060504070002-- --===============1905071505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1905071505==-- From tls-bounces@ietf.org Tue Oct 5 15:34:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00450; Tue, 5 Oct 2004 15:34:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEvEi-0007c1-6i; Tue, 05 Oct 2004 15:44:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEv0d-0008Pj-P8; Tue, 05 Oct 2004 15:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEuq4-0000EK-4R for tls@megatron.ietf.org; Tue, 05 Oct 2004 15:19:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28485 for ; Tue, 5 Oct 2004 15:19:06 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEuzN-0005Gb-Fa for tls@ietf.org; Tue, 05 Oct 2004 15:28:48 -0400 Received: from scholes.stanford.edu (Scholes.Stanford.EDU [171.64.78.72]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id i95JIWbJ016141 for ; Tue, 5 Oct 2004 12:18:32 -0700 Received: (qmail 16306 invoked by uid 1000); 5 Oct 2004 19:12:32 -0000 To: tls@ietf.org Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* References: <20040928231022.9FCD1717F@sierra.rtfm.com> <415B67B0.80500@eecs.berkeley.edu> From: Hovav Shacham In-Reply-To: <415B67B0.80500@eecs.berkeley.edu> Date: 05 Oct 2004 12:12:32 -0700 Message-ID: <87wty53rof.fsf@scholes.stanford.edu> Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Bodo Moeller writes: > I vote for option A ("Advance draft-ietf-tls-ecc-* to Proposed > Standard"). I vote B, informational. > we know that attacks against RSA and DH have subexponential > complexity, while attacking ECC requires exponential time (around > 2^k steps for ECC over (2k)-bit fields). Except when it doesn't; consider the talks by Pierrick Gaudry and Claus Diem at ECC a few weeks ago. > Increasing keylengths to improve security has a more noticeable > effect on performance for RSA and DH than for ECC (with its > exponential complexity of known attacks). Yes; but, barring significant advances in factoring or discrete log, the ECC ciphersuites provide only moderate throughput improvement, at the cost of protocol complexity. This seems to me to be an unwise bet against Moore's Law. -- Hovav Shacham hovav@hovav.net "Rightly looked at there is no laughable thing under the sun." _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 16:39:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09503; Tue, 5 Oct 2004 16:39:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEwEz-0001bF-PN; Tue, 05 Oct 2004 16:48:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvnS-0001lH-EI; Tue, 05 Oct 2004 16:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvgo-00058F-S3 for tls@megatron.ietf.org; Tue, 05 Oct 2004 16:13:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05620 for ; Tue, 5 Oct 2004 16:13:36 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEvq6-0005tj-G0 for tls@ietf.org; Tue, 05 Oct 2004 16:23:19 -0400 Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CEvgh-0000Go-00; Tue, 05 Oct 2004 22:13:31 +0200 Received: from [136.152.196.194] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CEvgg-0004cF-00; Tue, 05 Oct 2004 22:13:31 +0200 Received: from eecs.berkeley.edu (localhost [127.0.0.1]) by tau.local (Postfix) with ESMTP id 822D72EEC4; Tue, 5 Oct 2004 13:11:24 -0700 (PDT) Message-ID: <4162FFEC.6090407@eecs.berkeley.edu> Date: Tue, 05 Oct 2004 13:11:24 -0700 From: Bodo Moeller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hovav Shacham Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* References: <20040928231022.9FCD1717F@sierra.rtfm.com> <415B67B0.80500@eecs.berkeley.edu> <87wty53rof.fsf@scholes.stanford.edu> In-Reply-To: <87wty53rof.fsf@scholes.stanford.edu> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hovav Shacham wrote: > Bodo Moeller writes: >> we know that attacks against RSA and DH have subexponential >> complexity, while attacking ECC requires exponential time (around >> 2^k steps for ECC over (2k)-bit fields). > Except when it doesn't; consider the talks by Pierrick Gaudry and > Claus Diem at ECC a few weeks ago. Yes, obviously. This was an oversimplification (sort of like "factoring integers is hard"). More precisely, as long as you don't try to cut corners by using composite fields or other special curves, then if you choose elliptic curves with the usual cryptographic properties described in the standards (notably, existence of a large prime-order subgroup), you can very reasonably hope to achieve attack resistance as claimed above. >> Increasing keylengths to improve security has a more noticeable >> effect on performance for RSA and DH than for ECC (with its >> exponential complexity of known attacks). > Yes; but, barring significant advances in factoring or discrete log, > the ECC ciphersuites provide only moderate throughput improvement, at > the cost of protocol complexity. This depends on the hardware (and use of the protocol) that you are considering. For example, with unauthenticated clients, there's ephemeral DH with RSA signatures (which is in pretty wide use for TLS-protected SMTP) vs. ephemeral ECDH with RSA signatures. For weak hardware, this can make a great deal of a difference. If you see TLS as a general security protocol for data streams, then this matters. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 17:33:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14112; Tue, 5 Oct 2004 17:33:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEx53-0000vQ-Hc; Tue, 05 Oct 2004 17:42:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEwqJ-0003x8-Au; Tue, 05 Oct 2004 17:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEwoz-0003jz-SO for tls@megatron.ietf.org; Tue, 05 Oct 2004 17:26:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13728 for ; Tue, 5 Oct 2004 17:26:07 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.193] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEwyM-00085h-Cw for tls@ietf.org; Tue, 05 Oct 2004 17:35:50 -0400 Received: by mproxy.gmail.com with SMTP id 80so2335583rnk for ; Tue, 05 Oct 2004 14:25:19 -0700 (PDT) Received: by 10.38.206.80 with SMTP id d80mr290280rng; Tue, 05 Oct 2004 14:25:19 -0700 (PDT) Received: by 10.38.8.25 with HTTP; Tue, 5 Oct 2004 14:25:19 -0700 (PDT) Message-ID: Date: Tue, 5 Oct 2004 17:25:19 -0400 From: Tim Dierks To: Eric Rescorla Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* In-Reply-To: <20040928231022.9FCD1717F@sierra.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040928231022.9FCD1717F@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@dierks.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Tue, 28 Sep 2004 15:55:39 -0700, Eric Rescorla wrote: > This is a Straw Poll in the fate of draft-ietf-tls-ecc-*. > > A. Advance draft-ietf-tls-ecc-* to Proposed Standard. > B. Advance draft-ietf-tls-ecc-* as Informational and remove > the extensions. > C. Advance draft-ietf-tls-ecc-* as Informational with the > extensions. Amend RFC 3456 to allow extensions without > a Standards Action. I vote option B. I don't think curve negotiation is of substantial practical value. - Tim _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 18:31:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18654; Tue, 5 Oct 2004 18:31:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CExzV-0007np-R0; Tue, 05 Oct 2004 18:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExkI-0003QK-W2; Tue, 05 Oct 2004 18:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CExhf-0002rp-NW for tls@megatron.ietf.org; Tue, 05 Oct 2004 18:22:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18049 for ; Tue, 5 Oct 2004 18:22:36 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CExr2-0006Rr-1s for tls@ietf.org; Tue, 05 Oct 2004 18:32:20 -0400 Received: from eecs.berkeley.edu (visitor.CS.Berkeley.EDU [128.32.153.228]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i95MMYBm023919; Tue, 5 Oct 2004 15:22:34 -0700 (PDT) Message-ID: <41631EA9.9050501@eecs.berkeley.edu> Date: Tue, 05 Oct 2004 15:22:33 -0700 From: Bodo Moeller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tim@dierks.org Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* References: <20040928231022.9FCD1717F@sierra.rtfm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Tim Dierks wrote: > I don't think curve negotiation is of substantial > practical value. The ECC TLS draft uses two extensions: "supported elliptic curves", and "supported point formats". The latter arguably would be easy to get rid of if necessary (make the uncompressed point format not only the default and a "MUST support", but also a "MUST use"). But "supported elliptic curves" serves an important practical purpose beyond merely providing an optimization like "supported point formats" does: Without curve negotiation, clients and servers would have to support both prime field curves and binary curves to be able to use ECC ciphersuites without risking non-interoperability. The way the handshake works, the server has to decide about the type of curve to use for ECDH when sending the ServerKeyExchange message; the client has to follow this lead (i.e. use the same group) in the ClientKeyExchange. The concern is mostly about small clients with limited capabilities: With the "supported elliptic curves" extension, clients that support, say, only prime fields or even just a specific one of the well-known curves will be able to finish the handshake for ECC ciphersuites without problems (under the usually reasonable assumption that the servers are less limited). Without this extension, such clients could only hope that the server will pick a curve that works for them. A general solution to this and similar problems might be to define ciphersuite-specific extensions: By RFC 3546, we have struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension; enum { server_name(0), max_fragment_length(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5), (65535) } ExtensionType; What about using struct { ExtensionType extension_type; select (MSB(extension_type)) { case 0: opaque extension_data<0..2^16-1>; case 1: CipherSuite cipher_suites<2..2^16-1>; opaque extension_data<0..2^16-1>; } Extension; instead where all extension types with the MSB set are valid only for the ciphersuites listed for them and thus don't require a single global specification? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 20:16:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29399; Tue, 5 Oct 2004 20:16:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEzcx-0007Sb-SF; Tue, 05 Oct 2004 20:25:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEzRR-0001yF-Qh; Tue, 05 Oct 2004 20:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEzPi-0001Dv-9I for tls@megatron.ietf.org; Tue, 05 Oct 2004 20:12:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28748 for ; Tue, 5 Oct 2004 20:12:12 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.206] helo=mproxy.gmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEzZ5-0006wR-GG for tls@ietf.org; Tue, 05 Oct 2004 20:21:56 -0400 Received: by mproxy.gmail.com with SMTP id v18so3750586rnb for ; Tue, 05 Oct 2004 17:12:10 -0700 (PDT) Received: by 10.38.1.72 with SMTP id 72mr2375761rna; Tue, 05 Oct 2004 17:12:10 -0700 (PDT) Received: by 10.38.8.25 with HTTP; Tue, 5 Oct 2004 17:12:10 -0700 (PDT) Message-ID: Date: Tue, 5 Oct 2004 17:12:10 -0700 From: Tim Dierks To: Bodo Moeller Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* In-Reply-To: <41631EA9.9050501@eecs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040928231022.9FCD1717F@sierra.rtfm.com> <41631EA9.9050501@eecs.berkeley.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tim@dierks.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Tue, 05 Oct 2004 15:22:33 -0700, Bodo Moeller wrote: > Tim Dierks wrote: > > > I don't think curve negotiation is of substantial > > practical value. I based this entirely on my experience with ECC TLS, which is substantial (I'm a former CTO of Certicom). In my experience, 100% of the use of ECC TLS has been in closed-interoperability environments: everyone participating in the network already knows with whom they're going to need to speak, and the algorithm space is reduced to a sub-specification of the TLS spec. In reality, this generally means everyone uses a single curve, to say nothing of field or point format. I don't see any reason this is going to change any time soon, so I don't think it's worth standardizing the extension portion of the draft. - Tim _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 20:52:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02604; Tue, 5 Oct 2004 20:52:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF0CV-0004OI-9K; Tue, 05 Oct 2004 21:02:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF01C-0007sz-Gp; Tue, 05 Oct 2004 20:50:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF00u-0007ke-Hd for tls@megatron.ietf.org; Tue, 05 Oct 2004 20:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02381 for ; Tue, 5 Oct 2004 20:50:39 -0400 (EDT) Received: from host66.okiok.com ([207.61.238.66] helo=mail.okiok.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF0AJ-0003vu-07 for tls@ietf.org; Tue, 05 Oct 2004 21:00:23 -0400 Received: from p1166mobile (modemcable022.23-131-66.mc.videotron.ca [66.131.23.22]) by mail.okiok.com (Postfix) with ESMTP id 91852B4085 for ; Tue, 5 Oct 2004 20:50:07 -0400 (EDT) From: "Anton Stiglic" To: Date: Tue, 5 Oct 2004 20:50:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcSrOeEGVvgM7YX+RNOtHAgd6AEvcwABGihQ Message-Id: <20041006005007.91852B4085@mail.okiok.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [TLS] NIST recommendations for TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit For those who have not seen it yet: http://csrc.nist.gov/publications/drafts.html#sp800-52 --Anton _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 5 21:00:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03369; Tue, 5 Oct 2004 21:00:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF0Je-0005hM-Vm; Tue, 05 Oct 2004 21:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF08n-0000iT-5a; Tue, 05 Oct 2004 20:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF071-0000PN-Al for tls@megatron.ietf.org; Tue, 05 Oct 2004 20:56:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03045 for ; Tue, 5 Oct 2004 20:56:57 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.173]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF0GO-0005FO-Hr for tls@ietf.org; Tue, 05 Oct 2004 21:06:42 -0400 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CF06v-0000XG-00; Wed, 06 Oct 2004 02:56:53 +0200 Received: from [128.32.153.61] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CF06v-0006Y0-00; Wed, 06 Oct 2004 02:56:53 +0200 Received: from eecs.berkeley.edu (localhost [127.0.0.1]) by tau.local (Postfix) with ESMTP id 2A53B2E366; Tue, 5 Oct 2004 17:54:22 -0700 (PDT) Message-ID: <4163423E.2090601@eecs.berkeley.edu> Date: Tue, 05 Oct 2004 17:54:22 -0700 From: Bodo Moeller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tim@dierks.org Subject: Re: [TLS] Straw poll on draft-ietf-tls-ecc-* References: <20040928231022.9FCD1717F@sierra.rtfm.com> <41631EA9.9050501@eecs.berkeley.edu> In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Tim Dierks wrote: >> Tim Dierks wrote: >>> I don't think curve negotiation is of substantial >>> practical value. > I based this entirely on my experience with ECC TLS, which is > substantial (I'm a former CTO of Certicom). In my experience, 100% of > the use of ECC TLS has been in closed-interoperability environments: > everyone participating in the network already knows with whom they're > going to need to speak, and the algorithm space is reduced to a > sub-specification of the TLS spec. In reality, this generally means > everyone uses a single curve, to say nothing of field or point format. > I don't see any reason this is going to change any time soon, [...] The old draft-ietf-tls-ecc-01.txt specification, which you co-authored while you were with Certicom, only had ciphersuites that required ECDH in the *certificates* (apart from anonymous ECDH, which does not have any ceritificates in the first place). This naturally only lends itself to closed environments as you describe them. The ECC TLS drafts now, since draft-ietf-tls-ecc-02.txt (August 2002), have a ECDHE_RSA key exchange algorithm, which lets ECC TLS work outside such closed worlds: Everyone can continue to use their RSA certificates (which makes signature verification faster anyway); ECDH is used just in the key exchange messages. Obviously there are still ciphersuites requiring ECC-enabled certificates, which would only be used in closed-interoperability environments at first (and may catch on later). But there are now ciphersuites that ensure unhindered interoperability without requiring closed networks -- all that is needed is curve negotiation. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 7 02:44:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15139; Thu, 7 Oct 2004 02:44:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFSAF-0004Sm-QI; Thu, 07 Oct 2004 02:54:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFRyQ-0008Uf-Eh; Thu, 07 Oct 2004 02:41:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFRxI-0008DK-Ns for tls@megatron.ietf.org; Thu, 07 Oct 2004 02:40:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14927 for ; Thu, 7 Oct 2004 02:40:47 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFS6w-0004PX-4B for tls@ietf.org; Thu, 07 Oct 2004 02:50:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i976eiC28485 for ; Thu, 7 Oct 2004 09:40:44 +0300 (EET DST) X-Scanned: Thu, 7 Oct 2004 09:40:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i976eWdK010059 for ; Thu, 7 Oct 2004 09:40:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00vXrk6G; Thu, 07 Oct 2004 09:40:32 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i976eVY29313 for ; Thu, 7 Oct 2004 09:40:31 +0300 (EET DST) Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 09:40:27 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 09:40:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Oct 2004 09:40:27 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178362@esebe056.ntc.nokia.com> Thread-Topic: Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt Thread-Index: AcSsOIfJELPSCLSDRG2D2x45eYVS3Q== To: X-OriginalArrivalTime: 07 Oct 2004 06:40:27.0400 (UTC) FILETIME=[880E4880:01C4AC38] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Subject: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable (No protocol changes, only some clarifications based on comments we've received -- see Appendix A for a change log.) ---------- Forwarded message ---------- Date: Wed, 06 Oct 2004 15:41:46 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-tls-psk-02.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 : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s) : P. Eronen, H. Tschofenig Filename : draft-ietf-tls-psk-02.txt Pages : 14 Date : 2004-10-6 =09 This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-02.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sat Oct 9 13:56:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29120; Sat, 9 Oct 2004 13:56:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLcr-0002hj-1c; Sat, 09 Oct 2004 14:07:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLRW-0002vF-63; Sat, 09 Oct 2004 13:55:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGLOS-0002GK-VG for tls@megatron.ietf.org; Sat, 09 Oct 2004 13:52:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28981 for ; Sat, 9 Oct 2004 13:52:31 -0400 (EDT) Received: from mailhost.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGLYb-0002dS-VP for tls@ietf.org; Sat, 09 Oct 2004 14:03:02 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id E07583526D; Sun, 10 Oct 2004 06:51:44 +1300 (NZDT) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21447-09; Sun, 10 Oct 2004 06:51:44 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id A47AF35258; Sun, 10 Oct 2004 06:51:44 +1300 (NZDT) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A64B337742; Sun, 10 Oct 2004 06:51:53 +1300 (NZDT) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CGLNp-0000zU-00; Sun, 10 Oct 2004 06:51:53 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, tls@ietf.org Subject: Re: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178362@esebe056.ntc.nokia.com> Message-Id: Date: Sun, 10 Oct 2004 06:51:53 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Pasi.Eronen@nokia.com writes: >(No protocol changes, only some clarifications based on comments we've >received -- see Appendix A for a change log.) D'oh, just after I finally got round to typing up some comments: TLS_PSK_WITH_RC4_128_SHA TLS_DHE_PSK_WITH_RC4_128_SHA TLS_DHE_PSK_WITH_RC4_128_SHA Is there a need for this SSLv2-era legacy cipher? The only reason it's present in current implementations (and hardware) is for backwards- compatibility. In addition it's not a FIPS algorithm, so it can't be used in environments where certification is required. I can see that it'd be useful in low-resource environments (one of the main motivations for PSK TLS), but wouldn't AES take care of that? (note that if no hint is provided, a ServerKeyExchange message is still sent) Wouldn't it be better to omit this message than to send a message whose only purpose is to indicate that the page is intentionally left blank? Note: This effectively means that only the HMAC-SHA1 part (but not the HMAC- MD5 part) of the TLS PRF is used when constructing the master secret. See [7] for a more detailed rationale. Argh, no, this is just wrong! Even if using half the PRF is considered secure, it's just bad engineering practice to take a security mechanism with fail-safe redundancy built in and throw away the redundancy (this was exactly what my draft initially did, and it was flagged as a flaw by people commenting on it). The MD5 calculation is being performed anyway, so you're not saving anything by doing this. The calculation should use both parts of the PRF, to match its usage everywhere else in TLS. The premaster secret is formed as follows: concatenate the value produced by the Diffie-Hellman exchange (with leading zero bytes stripped as in other Diffie-Hellman based ciphersuites) and the PSK, in this order. Wouldn't it be better to concat: opaque dhValue<0..2^16-1>; opaque psk<0..2^16-1>; rather than the raw components? Otherwise you get a pile of key-equivalents depending on where you draw the line between the DH value and the PSK. So [ DH-value...XX || YY ] is equivalent to [ DH-value || XX YY ]. Now admittedly this shouldn't be much of an issue because DH-value will always change by a large amount each time, but it'd still be better to define a uniform premaster generation process that takes as input the existing secret value (whether it be generated via RSA, DH, or anything else) as a vector and concatenates the PSK as a vector. This is a universal mechanism that applies to any key exchange algorithm that may be used (Fortezza, etc etc). (This depends on whether this document is published before or after TLS 1.1.) Can we get this sorted out? After I published my PSK draft I had a number of requests from people who wanted to get a shared-key mechanism into production as quickly as possible, at the moment with everything listed as TBD you can't even do a test implementation from it. In fact why do the cipher suites depend on when TLS 1.1 is published? Unless they're going to be defined in the TLS 1.1 spec, there's only one form of the text that's required. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Oct 11 06:28:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21260; Mon, 11 Oct 2004 06:28:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxaC-0004QO-BD; Mon, 11 Oct 2004 06:39:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGxMz-0006oC-NV; Mon, 11 Oct 2004 06:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGxGB-0005rA-UH for tls@megatron.ietf.org; Mon, 11 Oct 2004 06:18:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20558 for ; Mon, 11 Oct 2004 06:18:29 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxQh-0004GB-GB for tls@ietf.org; Mon, 11 Oct 2004 06:29:24 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BAINW26706; Mon, 11 Oct 2004 13:18:23 +0300 (EET DST) X-Scanned: Mon, 11 Oct 2004 13:18:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9BAIDJw026637; Mon, 11 Oct 2004 13:18:13 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00U1nRZG; Mon, 11 Oct 2004 13:18:10 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9BAI9S13942; Mon, 11 Oct 2004 13:18:09 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 13:17:54 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 13:17:55 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 11 Oct 2004 13:17:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt Date: Mon, 11 Oct 2004 13:17:53 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD1C@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt Thread-Index: AcSuKM0YVjORuTrlQLSI9I+dkqurmwBUqBRg To: , X-OriginalArrivalTime: 11 Oct 2004 10:17:54.0184 (UTC) FILETIME=[92328880:01C4AF7B] X-Spam-Score: 1.3 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Peter Gutmann writes: > > D'oh, just after I finally got round to typing up some comments: Thanks for your comments, Peter! > TLS_PSK_WITH_RC4_128_SHA > TLS_DHE_PSK_WITH_RC4_128_SHA > TLS_DHE_PSK_WITH_RC4_128_SHA >=20 > Is there a need for this SSLv2-era legacy cipher? The only reason > it's present in current implementations (and hardware) is for > backwards-compatibility. In addition it's not a FIPS algorithm, > so it can't be used in environments where certification is required. =20 > I can see that it'd be useful in low-resource environments (one=20 > of the main motivations for PSK TLS), but wouldn't AES take care=20 > of that? Practically all TLS implementations have it, and in some libraries (e.g. Crypto++ and OpenSSL) RC4 is over twice as fast as AES. Your mileage may, of course, vary, but I don't see any harm in including=20 it either. > (note that if no hint is provided, a ServerKeyExchange=20 > message is still sent) >=20 > Wouldn't it be better to omit this message than to send a message > whose only purpose is to indicate that the page is intentionally > left blank? Maybe less alternatives in the code path (or fewer transitions=20 in a "state machine" like implementation)? But it probably=20 doesn't matter that much either way... > Note: This effectively means that only the HMAC-SHA1 part=20 > (but not the HMAC-MD5 part) of the TLS PRF is used when=20 > constructing the master secret. See [7] for a more detailed=20 > rationale. >=20 > Argh, no, this is just wrong! Even if using half the PRF is > considered secure, it's just bad engineering practice to take a > security mechanism with fail-safe redundancy built in and throw away > the redundancy (this was exactly what my draft initially did, and=20 > it was flagged as a flaw by people commenting on it). The MD5 > calculation is being performed anyway, so you're not saving anything > by doing this. The calculation should use both parts of the PRF, > to match its usage everywhere else in TLS. I agree there's no saving in CPU costs; it was done this way=20 because when Hugo Krawczyk commented your draft in January,=20 he suggested that it should be done this way. (http://www.imc.org/ietf-tls/mail-archive/msg04098.html) But I'm open to changing this if the WG thinks so (one=20 likely alternative would be to use "PSK || PSK"). > The premaster secret is formed as follows: concatenate the=20 > value produced by the Diffie-Hellman exchange (with leading=20 > zero bytes stripped as in other Diffie-Hellman based ciphersuites)=20 > and the PSK, in this order. >=20 > Wouldn't it be better to concat: >=20 > opaque dhValue<0..2^16-1>; > opaque psk<0..2^16-1>; >=20 > rather than the raw components? Otherwise you get a pile of > key-equivalents depending on where you draw the line between the DH > value and the PSK. So [ DH-value...XX || YY ] is equivalent to=20 > [ DH-value || XX YY ]. Now admittedly this shouldn't be much of an > issue because DH-value will always change by a large amount each > time, but it'd still be better to define a uniform premaster > generation process that takes as input the existing secret value > (whether it be generated via RSA, DH, or anything else) as a vector > and concatenates the PSK as a vector. This is a universal mechanism > that applies to any key exchange algorithm that may be used > (Fortezza, etc etc). I see your point... though I don't see any advantage doing this for RSA_PSK, since the first part is always 48 octets. And even in DH, the DH-value has always almost the same=20 length as p. (Any other opinions on this? Should we add a length field here?) > (This depends on whether this document is published before=20 > or after TLS 1.1.) >=20 > Can we get this sorted out? After I published my PSK draft I had > a number of requests from people who wanted to get a shared-key > mechanism into production as quickly as possible, at the moment with > everything listed as TBD you can't even do a test implementation > from it. In fact why do the cipher suites depend on when TLS 1.1 is > published? Unless they're going to be defined in the TLS 1.1 spec, > there's only one form of the text that's required. If this draft is published after TLS 1.1, the ciphersuite numbers=20 have to be assigned by IANA... (though the current version of=20 2246bis doesn't actually say when this happens; it probably=20 should say "Standards Action" for the 0..191 range) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Oct 11 21:27:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18805; Mon, 11 Oct 2004 21:27:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHBcw-0001YA-37; Mon, 11 Oct 2004 21:38:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHBMM-0005L0-TE; Mon, 11 Oct 2004 21:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHBFu-0003ak-UI for tls@megatron.ietf.org; Mon, 11 Oct 2004 21:15:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17315 for ; Mon, 11 Oct 2004 21:15:08 -0400 (EDT) Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHBQK-0001Hh-Cd for tls@ietf.org; Mon, 11 Oct 2004 21:26:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id CDDDBF7972 for ; Tue, 12 Oct 2004 03:14:51 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12804-02-35 for ; Tue, 12 Oct 2004 03:14:51 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id B1CCEF7929 for ; Tue, 12 Oct 2004 03:14:51 +0200 (IST) (envelope-from hugo@ee.technion.ac.il) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id i9C1HsWp006622; Tue, 12 Oct 2004 03:17:54 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id i9C1HqVj006617; Tue, 12 Oct 2004 03:17:52 +0200 (IST) Date: Tue, 12 Oct 2004 03:17:52 +0200 (IST) From: Hugo Krawczyk To: Pasi.Eronen@nokia.com Subject: RE: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt In-Reply-To: <125EA890549C8641A72F3809CB80DCCD16FD1C@esebe056.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 >From a purely analytical point of view using 0||PSK is better than PSK||PSK (as explained in my January's message referenced below). Heuristically, your guess is as good as mine. Hugo > > > Note: This effectively means that only the HMAC-SHA1 part > > (but not the HMAC-MD5 part) of the TLS PRF is used when > > constructing the master secret. See [7] for a more detailed > > rationale. > > > > Argh, no, this is just wrong!Even if using half the PRF is > > considered secure, it's just bad engineering practice to take a > > security mechanism with fail-safe redundancy built in and throw away > > the redundancy (this was exactly what my draft initially did, and > > it was flagged as a flaw by people commenting on it).The MD5 > > calculation is being performed anyway, so you're not saving anything > > by doing this.The calculation should use both parts of the PRF, > > to match its usage everywhere else in TLS. > > I agree there's no saving in CPU costs; it was done this way > because when Hugo Krawczyk commented your draft in January, > he suggested that it should be done this way. > (http://www.imc.org/ietf-tls/mail-archive/msg04098.html) > > But I'm open to changing this if the WG thinks so (one > likely alternative would be to use "PSK || PSK"). > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Oct 11 21:52:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19868; Mon, 11 Oct 2004 21:52:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHC0o-0001v8-4n; Mon, 11 Oct 2004 22:03:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHBmD-0004L1-CW; Mon, 11 Oct 2004 21:48:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHBhV-0001mF-Fp for tls@megatron.ietf.org; Mon, 11 Oct 2004 21:43:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19366 for ; Mon, 11 Oct 2004 21:43:39 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHBs6-0001kX-Bo for tls@ietf.org; Mon, 11 Oct 2004 21:54:41 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.196); Mon, 11 Oct 2004 18:42:39 -0700 Received: from RED-MSG-30.redmond.corp.microsoft.com ([157.54.47.230]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 18:43:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt Date: Mon, 11 Oct 2004 18:42:25 -0700 Message-ID: Thread-Topic: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt Thread-Index: AcSv+q78yCdza3cDRJeSM7drkf7RvwAAUZdA From: "Dan Simon" To: X-OriginalArrivalTime: 12 Oct 2004 01:43:52.0497 (UTC) FILETIME=[ED885210:01C4AFFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable I believe I'm the guy who originally suggested the current parallel construction of the PRF. At the time, I explicitly stated that the whole business of using two fixed hash functions (instead of a single function specified in the ciphersuite) was a stupid idea, and that I was only proposing the parallel construction because certain people were absolutely dead-set on the idea of using both MD5 and SHA1 in the PRF. So naturally I'm all in favor of Hugo's proposal. Perhaps one day we can get rid of the MD5 half altogether, and then make the hash function used in the second half depend on the ciphersuite, so that SHA1 will become replaceable, if necessary, merely by defining a new set of ciphersuites. Dan -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Hugo Krawczyk Sent: Monday, October 11, 2004 6:18 PM To: Pasi.Eronen@nokia.com Cc: tls@ietf.org Subject: RE: [TLS] Fwd: I-D ACTION:draft-ietf-tls-psk-02.txt >From a purely analytical point of view using 0||PSK is better than PSK||PSK (as explained in my January's message referenced below). Heuristically, your guess is as good as mine. Hugo > > > Note: This effectively means that only the HMAC-SHA1 part (but not=20 > > the HMAC-MD5 part) of the TLS PRF is used when constructing the=20 > > master secret. See [7] for a more detailed rationale. > > > > Argh, no, this is just wrong!Even if using half the PRF is=20 > > considered secure, it's just bad engineering practice to take a=20 > > security mechanism with fail-safe redundancy built in and throw away > > the redundancy (this was exactly what my draft initially did, and it > > was flagged as a flaw by people commenting on it).The MD5=20 > > calculation is being performed anyway, so you're not saving anything > > by doing this.The calculation should use both parts of the PRF, to=20 > > match its usage everywhere else in TLS. > > I agree there's no saving in CPU costs; it was done this way because=20 > when Hugo Krawczyk commented your draft in January, he suggested that=20 > it should be done this way. > (http://www.imc.org/ietf-tls/mail-archive/msg04098.html) > > But I'm open to changing this if the WG thinks so (one > likely alternative would be to use "PSK || PSK"). > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Oct 18 18:42:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01942; Mon, 18 Oct 2004 18:42:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgOp-0003X2-ES; Mon, 18 Oct 2004 18:54:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJflv-000463-Am; Mon, 18 Oct 2004 18:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfPl-00038k-90 for tls@megatron.ietf.org; Mon, 18 Oct 2004 17:51:37 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27330 for ; Mon, 18 Oct 2004 17:51:29 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 1E405718F for ; Mon, 18 Oct 2004 15:08:56 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 18 Oct 2004 14:51:00 -0700 From: Eric Rescorla Message-Id: <20041018220856.1E405718F@sierra.rtfm.com> Subject: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 This is a formal WG Last Call for draft-ietf-tls-psk-02.txt. This document is intended for Proposed Standard status. This WGLC will last two weeks. Please send any comments to the mailing list by Nov 1, 2004. -Ekr P.S. Peter Gutmann, your issues have already been noted and I will treat them as Last Call comment. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Oct 18 19:56:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07534; Mon, 18 Oct 2004 19:56:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJhZ9-0005KH-CN; Mon, 18 Oct 2004 20:09:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJhDL-00059D-4J; Mon, 18 Oct 2004 19:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJh4X-0002it-9I for tls@megatron.ietf.org; Mon, 18 Oct 2004 19:37:49 -0400 Received: from turtle.tue.nl (b87036.upc-b.chello.nl [212.83.87.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06281 for ; Mon, 18 Oct 2004 19:37:40 -0400 (EDT) Received: from nmav by turtle.tue.nl with local (Exim 4.34) id 1CJh3j-0001ce-0H for tls@lists.ietf.org; Tue, 19 Oct 2004 01:36:59 +0200 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Date: Tue, 19 Oct 2004 01:36:58 +0200 User-Agent: KMail/1.7 References: <20041018220856.1E405718F@sierra.rtfm.com> In-Reply-To: <20041018220856.1E405718F@sierra.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410190136.58818.nmav@gnutls.org> Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit On Monday 18 October 2004 23:51, Eric Rescorla wrote: > This is a formal WG Last Call for draft-ietf-tls-psk-02.txt. > This document is intended for Proposed Standard status. > This WGLC will last two weeks. > Please send any comments to the mailing list by Nov 1, 2004. Hello, I suddenly felt anxious about it! Too few time given I think. Anyway some comments (I may be repeating some). -1. Introduction: - The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm) - use a PSK to authenticate a Diffie-Hellman exchange. These - ciphersuites protect against dictionary attacks by passive I don't think that here "dictionary attacks" is appropriate. PSK is not supposed to be a password based authentication (as also stated in section 1.1), so dictionary attacks do not apply. Could be replaced by "brute force attacks", although I think that only "provide Perfect Forward Secrecy (PFS)" would do. - The third set of ciphersuites (with RSA_PSK key exchange algorithm), - defined in Section 4, combine public key based authentication of the - server (using RSA and certificates) with mutual authentication using Why do certificate authentication of the server? I can understand it for SRP where there is no shared key but a password that may leak. For a preshared key I don't know how usefull is that. And also why are the certificate authenticated ciphersuites are restricted to RSA only? If one wants PSK with certificates and RSA, he might also want PSK with certificates and DHE so he has perfect forward secrecy as well. (actually I wouldn't want either :) Also the name selection does not help. TLS_DHE_PSK* ciphersuites are not cert. authenticated and TLS_RSA_PSK* are, so they cannot be directly recognised by the name (especially if in later draft TLS_DHE_PSK with certificates is defined). I'd suggest to rename RSA_PSK to RSA_CPSK or something in order to make clear that this is a certificate authenticated ciphersuite. -2. PSK key exchange algorithm - This document does not specify the format of the PSK identity or PSK - identity hint; neither is specified how exactly the client uses the - hint (if it uses it at all). (here I am repeating myself --sorry:) I believe that the above is unacceptable for a standard. Although below there is some recommended behaviour, I think that this will cause problems. I don't want to reverse engineer other implementations to see how they use this field, in order to be compatible. I'm for restricting this field only to UTF-8. If implementations are supposed to use other encodings/string types than the recommended UTF-8 then a type tag has to be added. Otherwise there is no way to distinguish data stored in that field. The same comment applies about the psk_identity in the client hello. PS. Are there now any implementations of this draft? -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Tue Oct 19 21:57:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14793; Tue, 19 Oct 2004 21:57:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5v9-0002w5-U9; Tue, 19 Oct 2004 22:09:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK40g-0007Xv-PF; Tue, 19 Oct 2004 20:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJutv-000167-Og for tls@megatron.ietf.org; Tue, 19 Oct 2004 10:23:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29621 for ; Tue, 19 Oct 2004 10:23:40 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJv63-0006jl-HP for tls@ietf.org; Tue, 19 Oct 2004 10:36:20 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9JENWh28603; Tue, 19 Oct 2004 17:23:32 +0300 (EET DST) X-Scanned: Tue, 19 Oct 2004 17:22:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9JEMV4V027365; Tue, 19 Oct 2004 17:22:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 007JEQjO; Tue, 19 Oct 2004 17:22:31 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9JEMOa26993; Tue, 19 Oct 2004 17:22:24 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 17:22:18 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 19 Oct 2004 17:22:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Date: Tue, 19 Oct 2004 17:22:17 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> Thread-Topic: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Thread-Index: AcS1b4EdIX9xtf1tRjyTS85yNqZ35gAblMnw To: , X-OriginalArrivalTime: 19 Oct 2004 14:22:17.0853 (UTC) FILETIME=[09BADAD0:01C4B5E7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Nikos Mavrogiannopoulos writes: > > Hello, >=20 > I suddenly felt anxious about it! Too few time given I think.=20 > Anyway some comments (I may be repeating some). Thanks for your comments, Nikos! > -1. Introduction: > - The ciphersuites in Section 3 (with DHE_PSK key exchange=20 > - algorithm) use a PSK to authenticate a Diffie-Hellman=20 > - exchange. These ciphersuites protect against dictionary=20 > - attacks by passive > > I don't think that here "dictionary attacks" is appropriate.=20 > PSK is not supposed to be a password based authentication=20 > (as also stated in section 1.1), so dictionary attacks do=20 > not apply. Could be replaced by "brute force attacks",=20 > although I think that only "provide Perfect Forward=20 > Secrecy (PFS)" would do. The text simply acknowledges the fact that, in reality, PSKs=20 may sometimes be selected by humans, and PSKs selected by=20 humans tend to contain less unpredictability than purely=20 random strings of the same length. (This is, of course, no different from many other protocols that can use shared secrets, e.g. IKE.) "Dictionary attack" is IMHO a reasonably common and well- understood word for that... though perhaps something like "...against brute force attacks by passive eavesdroppers=20 (but not active attackers) that exploit the possible lack of unpredictability in the PSK (e.g., the PSK is relatively short, or was chosen by a human and thus may contain less unpredictability than its length would imply), and ..." might be technically more accurate (but probably less understandable :-)? > - The third set of ciphersuites (with RSA_PSK key exchange=20 > - algorithm), defined in Section 4, combine public key based=20 > - authentication of the server (using RSA and certificates)=20 > - with mutual authentication using >=20 > Why do certificate authentication of the server? I can=20 > understand it for SRP where there is no shared key but a password=20 > that may leak. For a preshared key I don't know how usefull is that.=20 > And also why are the certificate authenticated ciphersuites are=20 > restricted to RSA only? If one wants PSK with certificates and RSA,=20 > he might also want PSK with certificates and DHE so he has perfect=20 > forward secrecy as well. (actually I wouldn't want either :) I'm not totally convinced about the usefulness of the RSA_PSK ciphersuites myself (but certainly if you don't want to use them, you don't have to implement them :-). Any opinions from other WG members? > Also the name selection does not help. TLS_DHE_PSK* ciphersuites =20 > are not cert. authenticated and TLS_RSA_PSK* are, so they cannot=20 > be directly recognised by the name (especially if in later draft=20 > TLS_DHE_PSK with certificates is defined). I'd suggest to rename=20 > RSA_PSK to RSA_CPSK or something in order to make clear > that this is a certificate authenticated ciphersuite.=20 I think the naming is reasonably consistent with other TLS ciphersuites: "RSA" tells that certificates are used, and=20 "DHE" tells that whatever follows the "DHE" part is used=20 to authenticate the ephemeral DH parameters. > -2. PSK key exchange algorithm > - This document does not specify the format of the PSK=20 > - identity or PSK identity hint; neither is specified how=20 > - exactly the client uses the hint (if it uses it at all). =20 >=20 > (here I am repeating myself --sorry:) > I believe that the above is unacceptable for a standard. > Although below there is some recommended behaviour, I think=20 > that this will cause problems. I don't want to reverse=20 > engineer other implementations to see how they use this field,=20 > in order to be compatible.=20 >=20 > I'm for restricting this field only to UTF-8. If implementations=20 > are supposed to use other encodings/string types than the=20 > recommended UTF-8 then a type tag has to be added. Otherwise=20 > there is no way to distinguish data stored in that field.=20 > The same comment applies about the psk_identity in the client=20 > hello. Note that there are many types of identifiers that are not naturally composed of Unicode characters (e.g., IPv4/v6=20 addresses, IEEE 802 MAC addresses, X.500 Distinguished Names,=20 even DNS names). All of those can, of course, be converted to=20 character strings (e.g., instead of 32-bit IPv4 address, use the=20 dotted decimal ASCII string) and then UTF-8 encoded back to bytes. In many cases, that might be a good idea even if we did not mandate it; that's why it already says "RECOMMENDED".=20 But perhaps we should change this to MUST? Any other comments=20 from the WG about this?=20 > PS. Are there now any implementations of this draft? No, not to my knowledge. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Oct 20 03:03:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06337; Wed, 20 Oct 2004 03:03:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKAhh-0001Aa-AA; Wed, 20 Oct 2004 03:16:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK97K-0007ta-2s; Wed, 20 Oct 2004 01:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK64d-0003s3-Ts for tls@megatron.ietf.org; Tue, 19 Oct 2004 22:19:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16863 for ; Tue, 19 Oct 2004 22:19:28 -0400 (EDT) Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6Gr-0003WW-Ik for tls@ietf.org; Tue, 19 Oct 2004 22:32:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 218C83456C; Wed, 20 Oct 2004 15:19:21 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28649-11; Wed, 20 Oct 2004 15:19:21 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 0884E33FBA; Wed, 20 Oct 2004 15:19:19 +1300 (NZDT) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D3A6F37748; Wed, 20 Oct 2004 15:19:19 +1300 (NZDT) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CK64R-0007Yz-00; Wed, 20 Oct 2004 15:19:23 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nmav@gnutls.org, Pasi.Eronen@nokia.com, tls@ietf.org Subject: RE: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt In-Reply-To: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> Message-Id: Date: Wed, 20 Oct 2004 15:19:23 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Pasi.Eronen@nokia.com writes: >I'm not totally convinced about the usefulness of the RSA_PSK ciphersuites >myself (but certainly if you don't want to use them, you don't have to >implement them :-). Any opinions from other WG members? I think they're quite useful, every server already does RSA with certs (even if it's just a self-signed one), so I'd regard this is the second-most useful suite after the basic PSK suites. >>PS. Are there now any implementations of this draft? > >No, not to my knowledge. There can't be any implementations because the suite values aren't defined. Providing values to use would probably help increase the number of implementations (see my earlier message on this). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Oct 20 09:00:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00294; Wed, 20 Oct 2004 09:00:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGHD-0008TP-Eg; Wed, 20 Oct 2004 09:13:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF4W-0008Rq-AR; Wed, 20 Oct 2004 07:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEQB-00088h-QU for tls@megatron.ietf.org; Wed, 20 Oct 2004 07:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22477 for ; Wed, 20 Oct 2004 07:14:15 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEcT-00067N-Tf for tls@ietf.org; Wed, 20 Oct 2004 07:27:07 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9KALEh17838; Wed, 20 Oct 2004 13:21:15 +0300 (EET DST) X-Scanned: Wed, 20 Oct 2004 13:19:14 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9KAJEGZ020339; Wed, 20 Oct 2004 13:19:14 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00m3F691; Wed, 20 Oct 2004 13:19:12 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9KAJCS03719; Wed, 20 Oct 2004 13:19:12 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 20 Oct 2004 13:18:54 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 20 Oct 2004 13:18:50 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Date: Wed, 20 Oct 2004 13:18:52 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD17837E@esebe056.ntc.nokia.com> Thread-Topic: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Thread-Index: AcS2S2UdOzhGkIe8QKeM9h9C8ih4zgAQOtfQ To: , , X-OriginalArrivalTime: 20 Oct 2004 10:18:50.0423 (UTC) FILETIME=[316FAC70:01C4B68E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Peter Gutmann writes: >>> PS. Are there now any implementations of this draft? >> >> No, not to my knowledge. >=20 > There can't be any implementations because the suite values=20 > aren't defined. Providing values to use would probably help=20 > increase the number of implementations (see my earlier message=20 > on this). I agree. Since there is no IANA registry for those numbers=20 yet, I guess we just have to pick some numbers at some point (taking extra care to avoid collisions...). Eric, do you have any opinion when this should be done?=20 In the version that handles the issues raised at WGLC and=20 will be sent to IESG? Or only after IESG evaluation and=20 IETF last call? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Oct 20 11:33:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14940; Wed, 20 Oct 2004 11:33:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIfU-00039R-GR; Wed, 20 Oct 2004 11:46:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHnZ-0002Cr-KN; Wed, 20 Oct 2004 10:50:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHCb-0006UO-0L for tls@megatron.ietf.org; Wed, 20 Oct 2004 10:12:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05192 for ; Wed, 20 Oct 2004 10:12:30 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHOz-0001LT-Nl for tls@ietf.org; Wed, 20 Oct 2004 10:25:23 -0400 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 9A1D771AE; Wed, 20 Oct 2004 07:29:52 -0700 (PDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id 25AE944AB0; Wed, 20 Oct 2004 07:11:54 -0700 (PDT) To: Subject: Re: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt References: <125EA890549C8641A72F3809CB80DCCD17837E@esebe056.ntc.nokia.com> From: Eric Rescorla Date: Wed, 20 Oct 2004 07:11:53 -0700 In-Reply-To: <125EA890549C8641A72F3809CB80DCCD17837E@esebe056.ntc.nokia.com> (Pasi Eronen's message of "Wed, 20 Oct 2004 13:18:52 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 writes: > Peter Gutmann writes: >> There can't be any implementations because the suite values >> aren't defined. Providing values to use would probably help >> increase the number of implementations (see my earlier message >> on this). > > I agree. Since there is no IANA registry for those numbers > yet, I guess we just have to pick some numbers at some point > (taking extra care to avoid collisions...). > > Eric, do you have any opinion when this should be done? Yes. Pick the next X unallocated values out of the Proposed registry, being careful not to collide with any in the other pending TLS WG drafts. We'll hold these open till this draft is finished... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Oct 20 23:17:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19029; Wed, 20 Oct 2004 23:17:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKTeV-0004NI-OJ; Wed, 20 Oct 2004 23:30:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIdZ-0003Bg-Bz; Wed, 20 Oct 2004 11:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKI95-00088h-M2 for tls@megatron.ietf.org; Wed, 20 Oct 2004 11:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13387 for ; Wed, 20 Oct 2004 11:12:51 -0400 (EDT) Received: from b87036.upc-b.chello.nl ([212.83.87.36] helo=turtle.tue.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKILP-0002jT-Mz for tls@ietf.org; Wed, 20 Oct 2004 11:25:45 -0400 Received: from nmav by turtle.tue.nl with local (Exim 4.34) id 1CKGtb-0000Sz-32 for tls@ietf.org; Wed, 20 Oct 2004 15:52:55 +0200 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Date: Wed, 20 Oct 2004 15:52:54 +0200 User-Agent: KMail/1.7 References: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410201552.54978.nmav@gnutls.org> X-Spam-Score: 2.6 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Tuesday 19 October 2004 16:22, you wrote: > I'm not totally convinced about the usefulness of the RSA_PSK > ciphersuites myself (but certainly if you don't want to use > them, you don't have to implement them :-). Any opinions > from other WG members? Certainly but my point also is, if certificate authenticated RSA ciphersuites are added, then why the DHE_RSA/DHE_DSS are not added as well? A server with a DSS only certificate can only use DHE_DSS, so is not entitled to use certificate authenticated PSK. > > Also the name selection does not help. TLS_DHE_PSK* ciphersuites > > are not cert. authenticated and TLS_RSA_PSK* are, so they cannot > > be directly recognised by the name (especially if in later draft > > TLS_DHE_PSK with certificates is defined). I'd suggest to rename > > RSA_PSK to RSA_CPSK or something in order to make clear > > that this is a certificate authenticated ciphersuite. > I think the naming is reasonably consistent with other TLS > ciphersuites: "RSA" tells that certificates are used, and > "DHE" tells that whatever follows the "DHE" part is used > to authenticate the ephemeral DH parameters. Yes you're right. I got confused here. > Note that there are many types of identifiers that are not > naturally composed of Unicode characters (e.g., IPv4/v6 > addresses, IEEE 802 MAC addresses, X.500 Distinguished Names, > even DNS names). Maybe tagging it would help then. So clients and servers can use the tags to distinguish data in that field. Otherwise there is no way to support all of these schemes, and we end up with clients and servers that use X.509 DN, and others that use IP addresses, and others that use just UTF-8, and no interoperation between them is possible. > Best regards, > Pasi -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 08:38:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17814; Thu, 21 Oct 2004 08:38:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcQ2-0000A7-Pk; Thu, 21 Oct 2004 08:51:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbHM-0007ss-FA; Thu, 21 Oct 2004 07:38:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKULS-0007sC-Pv for tls@megatron.ietf.org; Thu, 21 Oct 2004 00:14:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22687 for ; Thu, 21 Oct 2004 00:14:26 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKUXs-0005Sl-EJ for tls@ietf.org; Thu, 21 Oct 2004 00:27:27 -0400 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 3033271A6; Wed, 20 Oct 2004 21:31:52 -0700 (PDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id E706444AB0; Wed, 20 Oct 2004 21:13:52 -0700 (PDT) To: Nikos Mavrogiannopoulos Subject: Re: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt References: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> <200410201552.54978.nmav@gnutls.org> From: Eric Rescorla Date: Wed, 20 Oct 2004 21:13:52 -0700 In-Reply-To: <200410201552.54978.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 20 Oct 2004 15:52:54 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Nikos Mavrogiannopoulos writes: > On Tuesday 19 October 2004 16:22, you wrote: > >> I'm not totally convinced about the usefulness of the RSA_PSK >> ciphersuites myself (but certainly if you don't want to use >> them, you don't have to implement them :-). Any opinions >> from other WG members? > Certainly but my point also is, if certificate authenticated RSA ciphersuites > are added, then why the DHE_RSA/DHE_DSS are not added as well? A server > with a DSS only certificate can only use DHE_DSS, so is not entitled to use > certificate authenticated PSK. How common are DSS-only servers? Does anyone even issue DSS certs? > Maybe tagging it would help then. So clients and servers can use the > tags to distinguish data in that field. Otherwise there is no way to support > all of these schemes, and we end up with clients and servers that use X.509 > DN, and others that use IP addresses, and others that use just UTF-8, and no > interoperation between them is possible. I'm not sure this is a problem since the keys are manually configured anyway... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 08:48:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19924; Thu, 21 Oct 2004 08:48:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcZh-0000k4-0r; Thu, 21 Oct 2004 09:01:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbNg-0004fk-Jj; Thu, 21 Oct 2004 07:45:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKY3L-0005OP-SN for tls@megatron.ietf.org; Thu, 21 Oct 2004 04:12:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20427 for ; Thu, 21 Oct 2004 04:12:00 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKYFm-0000vB-FS for tls@ietf.org; Thu, 21 Oct 2004 04:25:02 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9L8Bse17452 for ; Thu, 21 Oct 2004 11:11:55 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 11:11:46 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9L8BkS4010903 for ; Thu, 21 Oct 2004 11:11:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00cIPwsH; Thu, 21 Oct 2004 11:10:08 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9L8A8S24777 for ; Thu, 21 Oct 2004 11:10:08 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 11:02:57 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 11:02:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 11:02:57 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178380@esebe056.ntc.nokia.com> Thread-Topic: Numbers used in TLS (AKA IANA considerations) Thread-Index: AcS3RGAMccSA90nJTDG3aV+xTGb3EQ== To: X-OriginalArrivalTime: 21 Oct 2004 08:02:57.0449 (UTC) FILETIME=[604C5190:01C4B744] X-Spam-Score: 2.3 (++) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Content-Transfer-Encoding: quoted-printable Subject: [TLS] Numbers used in TLS (AKA IANA considerations) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Content-Transfer-Encoding: quoted-printable Hi everyone, Since Eric urged me to pick some numbers for TLS-PSK soon, I decided to update the list of numbers currently in use (or at least proposed somewhere) from my earlier email in April. The list now contains more historical information; most of that work is presumably dead, and does not need to prevent future allocation of those numbers. (Corrections and additions are of course welcome!) Based on this, I'd suggest that TLS-PSK should use ciphersuite numbers=20 starting from 0x8A (there are some unused holes before that, though), and alert number 115. Any objections or comments to that? While doing this, I also noticed some collisions: - TLS extension number 6 is used by both draft-ietf-tls-ecc-06=20 and draft-ietf-tls-srp-08. - TLS extension number 7 is used both by draft-ietf-tls-ecc-06 and draft-ietf-tls-openpgp-keys-05. - Ciphersuites 0x60-0x65 are proposed in draft-lee-tls-seed-00, but these numbers are used by "RSA1024" ciphersuites which are quite widely implemented. - Ciphersuites 0x50-0x58 are used in draft-ietf-tls-srp-08, but=20 some OpenSSL versions use those for ECC (and these were also used in earlier versions of draft-ietf-tls-ecc). - Ciphersuites 0x77 and 0x78 are used in draft-ietf-openpgp-keys-05, but some OpenSSL versions use those for ECC. Best regards, Pasi -------------------------------------------------------------------------= -- TLS numbers used in various places Pasi Eronen Last updated: October 21st, 2004 TLS CIPHERSUITE NUMBERS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 00,00 TLS_NULL_WITH_NULL_NULL [RFC2246] 00,01 TLS_RSA_WITH_NULL_MD5 [RFC2246] 00,02 TLS_RSA_WITH_NULL_SHA [RFC2246] 00,03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC2246] 00,04 TLS_RSA_WITH_RC4_128_MD5 [RFC2246] 00,05 TLS_RSA_WITH_RC4_128_SHA [RFC2246] 00,06 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 [RFC2246] 00,07 TLS_RSA_WITH_IDEA_CBC_SHA [RFC2246] 00,08 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA [RFC2246] 00,09 TLS_RSA_WITH_DES_CBC_SHA [RFC2246] 00,0A TLS_RSA_WITH_3DES_EDE_CBC_SHA [RFC2246] 00,0B TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA [RFC2246] 00,0C TLS_DH_DSS_WITH_DES_CBC_SHA [RFC2246] 00,0D TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA [RFC2246] 00,0E TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA [RFC2246]=20 00,0F TLS_DH_RSA_WITH_DES_CBC_SHA [RFC2246] 00,10 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA [RFC2246] 00,11 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA [RFC2246] 00,12 TLS_DHE_DSS_WITH_DES_CBC_SHA [RFC2246] 00,13 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [RFC2246] 00,14 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA [RFC2246] 00,15 TLS_DHE_RSA_WITH_DES_CBC_SHA [RFC2246] 00,16 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA [RFC2246] 00,17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC2246] 00,18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC2246] 00,19 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA [RFC2246] 00,1A TLS_DH_anon_WITH_DES_CBC_SHA [RFC2246] 00,1B TLS_DH_anon_WITH_3DES_EDE_CBC_SHA [RFC2246] 00,1C (permanently reserved) [ssl3] 00,1D (permanently reserved) [ssl3] 00,1E TLS_KRB5_WITH_DES_CBC_SHA [RFC2712], [*1] 00,1F TLS_KRB5_WITH_3DES_EDE_CBC_SHA [RFC2712]=20 00,20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712]=20 00,21 TLS_KRB5_WITH_IDEA_CBC_SHA [RFC2712]=20 00,22 TLS_KRB5_WITH_DES_CBC_MD5 [RFC2712]=20 00,23 TLS_KRB5_WITH_3DES_EDE_CBC_MD5 [RFC2712]=20 00,24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712]=20 00,25 TLS_KRB5_WITH_IDEA_CBC_MD5 [RFC2712]=20 00,26 TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA [RFC2712]=20 00,27 TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA [RFC2712]=20 00,28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712]=20 00,29 TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 [RFC2712]=20 00,2A TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 [RFC2712]=20 00,2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712]=20 00,2C 00,2D 00,2F TLS_RSA_WITH_AES_128_CBC_SHA [RFC3268] 00,30 TLS_DH_DSS_WITH_AES_128_CBC_SHA [RFC3268] 00,31 TLS_DH_RSA_WITH_AES_128_CBC_SHA [RFC3268] 00,32 TLS_DHE_DSS_WITH_AES_128_CBC_SHA [RFC3268] 00,33 TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC3268] 00,34 TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC3268] 00,35 TLS_RSA_WITH_AES_256_CBC_SHA [RFC3268] 00,36 TLS_DH_DSS_WITH_AES_256_CBC_SHA [RFC3268] 00,37 TLS_DH_RSA_WITH_AES_256_CBC_SHA [RFC3268] 00,38 TLS_DHE_DSS_WITH_AES_256_CBC_SHA [RFC3268] 00,39 TLS_DHE_RSA_WITH_AES_256_CBC_SHA [RFC3268] 00,3A TLS_DH_anon_WITH_AES_256_CBC_SHA [RFC3268] 00,3B [*10] 00,3C [*10] 00,3D [*10] 00,3E [*10] 00,3F [*10] 00,40 [*10] 00,41 (reserved for ongoing work) [camellia-05] 00,42 (reserved for ongoing work) [camellia-05] 00,43 (reserved for ongoing work) [camellia-05] 00,44 (reserved for ongoing work) [camellia-05] 00,45 (reserved for ongoing work) [camellia-05] 00,46 (reserved for ongoing work) [camellia-05] 00,47 [*2] 00,48 [*2] 00,49 [*2] 00,4A [*2] 00,4B [*2] 00,4C [*2] 00,4D [*2] 00,4E [*2] 00,4F [*2] 00,50 (reserved for ongoing work) [srp-08], [*3] 00,51 (reserved for ongoing work) [srp-08], [*3] 00,52 (reserved for ongoing work) [srp-08], [*3] 00,53 (reserved for ongoing work) [srp-08], [*3] 00,54 (reserved for ongoing work) [srp-08], [*3] 00,55 (reserved for ongoing work) [srp-08], [*3] 00,56 (reserved for ongoing work) [srp-08], [*3] 00,57 (reserved for ongoing work) [srp-08], [*3] 00,58 (reserved for ongoing work) [srp-08], [*3] 00,59 [*2]=20 00,5A [*2] 00,5B [*2] 00,5C [*2] 00,5D 00,5E 00,5F 00,60 TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 [*4,7] 00,61 TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 [*4,7,12] 00,62 TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA [56bit] [*7,12] 00,63 TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA [56bit] [*7,12] 00,64 TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA [56bit] [*7,12] 00,65 TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA [56bit] [*7,12] 00,66 TLS_DHE_DSS_WITH_RC4_128_SHA [56bit] [*12] 00,67 [*12] 00,68 [*12] 00,69 00,6A 00,6B 00,6C 00,6D 00,6E 00,6F 00,70 [*16] 00,71 [*16] 00,72 (reserved for ongoing work) [openpgp-05] = [*16] 00,73 (reserved for ongoing work) [openpgp-05] = [*16] 00,74 (reserved for ongoing work) [openpgp-05] = [*16] 00,75 [*16] 00,76 [*16] 00,77 (reserved for ongoing work) [openpgp-05] = [*3,16] 00,78 (reserved for ongoing work) [openpgp-05] = [*3,16] 00,79 (reserved for ongoing work) [openpgp-05] = [*16] 00,7A 00,7B 00,7C (reserved for ongoing work) [openpgp-05] 00,7D (reserved for ongoing work) [openpgp-05] 00,7E (reserved for ongoing work) [openpgp-05] 00,7F 00,80 (reserved for ongoing work) [cptls-01] 00,81 (reserved for ongoing work) [cptls-01] 00,82 (reserved for ongoing work) [cptls-01] 00,83 (reserved for ongoing work) [cptls-01] 00,84 (reserved for ongoing work) [camellia-05] 00,85 (reserved for ongoing work) [camellia-05] 00,86 (reserved for ongoing work) [camellia-05] 00,87 (reserved for ongoing work) [camellia-05] 00,88 (reserved for ongoing work) [camellia-05] 00,89 (reserved for ongoing work) [camellia-05] 01,01 [*14] 01,02 [*14] 01,03 [*14] 01,04 [*14] 01,05 [*14] 01,06 [*14] 01,10 [*14] 01,20 [*14] 01,21 [*14] 01,22 [*14] 01,23 [*14] 01,24 [*14] 01,25 [*14] 01,F0 [*14] FF,E0 (reserved) [fips] FF,E1 (reserved) [fips] FE,FE (reserved) [fips] FE,FF (reserved) [fips] TLS CONTENT TYPES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 20 change_cipher_spec [RFC2246] 21 alert [RFC2246] 22 handshake [RFC2246] 23 application_data [RFC2246] 24 [*9] TLS HANDSHAKE TYPES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0 hello_request [RFC2246] 1 client_hello [RFC2246] 2 server_hello [RFC2246] =20 3 [*5] 4 [*5] 11 certificate [RFC2246] 12 server_key_exchange [RFC2246] 13 certificate_request [RFC2246] 14 server_hello_done [RFC2246] 15 certificate_verify [RFC2246] 16 client_key_exchange [RFC2246] 20 finished [RFC2246] 21 certificate_url [RFC3546] 22 certificate_status [RFC3546] 78 [ia-00] 79 [ia-00] TLS ALERT DESCRIPTIONS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0 close_notify [RFC2246] 10 unexpected_message [RFC2246] 20 bad_record_mac [RFC2246] 21 decryption_failed [RFC2246] 22 record_overflow [RFC2246] 30 decompression_failure [RFC2246] 40 handshake_failure [RFC2246] 41 (permanently reserved) [ssl3], [*13] 42 bad_certificate [RFC2246] 43 unsupported_certificate [RFC2246] 44 certificate_revoked [RFC2246] 45 certificate_expired [RFC2246] 46 certificate_unknown [RFC2246] 47 illegal_parameter [RFC2246] =20 48 unknown_ca [RFC2246] 49 access_denied [RFC2246] 50 decode_error [RFC2246] 51 decrypt_error [RFC2246] 60 export_restriction [RFC2246] 70 protocol_version [RFC2246] 71 insufficient_security [RFC2246] 80 internal_error [RFC2246] 90 user_canceled [RFC2246] 100 no_renegotiation [RFC2246] 110 unsupported_extension [RFC3546] [*13] 111 certificate_unobtainable [RFC3546] [*13] 112 unrecognized_name [RFC3546] [*13] 113 bad_certificate_status_response [RFC3546] [*13] 114 bad_certificate_hash_value [RFC3546] 120 (reserved for ongoing work) [srp-08] [*13] 121 (reserved for ongoing work) [srp-08] 122 (reserved for ongoing work) [srp-08] 208 [ia-00] [*6] TLS CLIENT CERTIFICATE TYPES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 1 rsa_sign [RFC2246] 2 dss_sign [RFC2246] 3 rsa_fixed_dh [RFC2246] 4 dss_fixed_dh [RFC2246] 5 (permanently reserved) [ssl3] [*16] 6 (permanently reserved) [ssl3] [*15] 7 [*15] 8 [*11,15] 9 [*11,15] 20 (permanently reserved) [ssl3] 21 (reserved for ongoing work) [cptls-01] 22 (reserved for ongoing work) [cptls-01] TLS EXTENSION TYPES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 0 server_name [RFC3546] 1 max_fragment_length [RFC3546] 2 client_certificate_url [RFC3546] 3 trusted_ca_keys [RFC3546] 4 truncated_hmac [RFC3546] 5 status_request [RFC3546] 6 (reserved for ongoing work) [srp-08], [ecc-06], [*5,13] 7 (reserved for ongoing work) [openpgp-05], [ecc-06], [*5] 8 [express-00] [*6] 9 [exchange-00], [*6,8] 35 [fast-00] [*6] 37703 [ia-00] [*6] 60000 [cptls-01] [*6] REFERENCES AND NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [camellia-05] Shiho Moriai, Akihiro Kato, and Masayuki Kanda, "Addition of Camellia Ciphersuites to Transport Layer Security (TLS)", draft-ietf-tls-camellia-05, October 2004. [ecc-06] Vipul Gupta, Simon Blake-Wilson, Bodo Moeller, Chris Hawk, and Nelson Bolyard, "ECC Cipher Suites For TLS", draft-ietf-tls-ecc-06, May 2004. [openpgp-05] Nikos Mavroyanopoulos, "Using OpenPGP keys for TLS authentication", draft-ietf-tls-openpgp-keys-05, April 2004. [srp-08] David Taylor, Tom Wu, Nikos Mavroyanopoulos, and Trevor Perrin, "Using SRP for TLS Authentication", draft-ietf-tls-srp-08, August 2004. [cptls-01] Grigorij Chudov and Serguei Leontiev, "Addition of GOST Ciphersuites to Transport Layer Security (TLS)", draft-chudov-cryptopro-cptls-01, April 2004. [seed-00] Hyangjin Lee, Jaeho Yoon, and Jaeil Lee, "Addition of SEED Ciphersuites to Transport Layer Security (TLS)", draft-lee-tls-seed-00, September 2004. [express-00] Mohamad Badra, Ahmed Serhrouchni, and Pascal Urien, "TLS Express", draft-badra-tls-express-00, June 2004. [exchange-00] Mohamad Badra, Omar Cherkaoui, Ibrahim Hajjeh, and Ahmed Serhrouchni, "Pre-Shared-Key key Exchange methods for TLS", draft-badra-tls-key-exchange-00, August 2004. [fast-00] Nancy Cam-Winget, David McGrew, Joseph Salowey, and Hao Zhou, "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-00, February 2004. [ia-00] Paul Funk, Simon Blake-Wilson, Ned Smith, and Hannes Tschofenig, "TLS Inner Application Extension (TLS/IA)", October 2004. [ssl3] Alan O. Freier, Philip Karlton, and Paul C. Kocher, "The SSL Protocol Version 3.0", expired I-D (draft-freier-ssl-version3-02.txt), November 1996. [56bit] John Banes and Richard Harrington, "56-bit Export Cipher Suites For TLS", expired Internet-Draft draft-ietf-tls-56-bit-ciphersuites-01.txt, July 2001. Although this document was never published as RFC, these ciphersuites are implemented by several vendors. [fips] FIPS SSL CipherSuites, http://www.mozilla.org/projects/ security/pki/nss/ssl/fips-ssl-ciphersuites.html [*1] This number was previously used for=20 SSL_FORTEZZA_KEA_WITH_RC4_128_SHA in [ssl3] [*2] Some versions of OpenSSL have used these numbers for elliptic curve ciphersuites. [*3] Some versions of OpenSSL have used these numbers for elliptic curve ciphersuites, but the same numbers are used for other purposes, too. [*4] These two ciphersuites were not defined in [56bit],=20 but are implemented by several vendors. [*5] These numbers were used in draft-shacham-tls-fast-track-00 (Hovav Shacham and Dan Boneh, "TLS Fast-Track Session Establishment", September 2001), but presumably this work is dead, and the numbers can be used for other purposes. [*6] These drafts do not appear to be intended for standards track; therefore, they should not define new TLS extensions or alert numbers, at least according to [RFC3546]. [*7] These numbers are proposed in [seed-00], but they are widely used for other purposes. [*8] It is expected that [exchange-00] will be=20 superceded by draft-ietf-tls-psk (which does not need a TLS extension number), so this entry may be deleted soon in the future. [*9] This number was in draft-ietf-tls-delegation-01=20 (Keith Jackson, Steven Tuecke, and Doug Engert, "TLS Delegation Protocol", February 2002), but presumably this work is dead and the number can be reused for other purposes. [*10] These numbers were used in draft-ietf-tls-misty1-01 (Hidenori Ohta and Hirosato Tsuji, "Addition of MISTY1 to TLS", March 2001), but presumably this work is dead and the numbers can be reused for other purposes. [*11] These numbers were used in draft-ietf-tls-ntru-00 (Ari Singer, "NTRU Cipher Suites for TLS", July 2001), but presumably this work is dead and the numbers can be reused for other purposes. [*12] These numbers were used in draft-ietf-tls-ntru-00, but presumably this work is dead, and and many of=20 the numbers are widely used for other purposes anyway. [*13] These numbers were used in draft-ietf-tls-pathsec-00 (Joseph Hui, "TLS Pathsec Protocol", September 2001), but presumably this work is dead, and the numbers can be used for other purposes. [*14] These numbers were used in draft-ietf-tls-openpgp-02 (Will Price and Michael Elkins, "Extensions to TLS for OpenPGP keys", February 2002), but presumably this work is dead, and the numbers can be used for other purposes. [*15] These numbers were used in draft-madhu-tls-spki-00 (H. S. Madhusudhana and V. R. Ramachandran, "SPKI Certificate Integration with Transport Layer Security (TLS) for Client Authentication and Authorization", July 2001), but presumably this work is dead, and the numbers can be used for other purposes. [*16] These numbers were used in draft-ietf-tls-kerb-01 (Matthew Hur, Joseph Salowey, and Ari Medvinsky, "Kerberos Cipher Suites in Transport Layer Security (TLS)", November 2001), but presumably this work is dead, and the numbers can be used for other purposes. =20 -------------------------------------------------------------------------= - _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 08:57:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21314; Thu, 21 Oct 2004 08:57:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKci7-00013P-0Z; Thu, 21 Oct 2004 09:10:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbOE-0004wJ-H0; Thu, 21 Oct 2004 07:45:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKZdr-00061o-J3 for tls@megatron.ietf.org; Thu, 21 Oct 2004 05:53:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24747 for ; Thu, 21 Oct 2004 05:53:47 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKZqN-0002GD-7Z for tls@ietf.org; Thu, 21 Oct 2004 06:06:51 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9L9rjo15598; Thu, 21 Oct 2004 12:53:45 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 12:53:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9L9rVSL023651; Thu, 21 Oct 2004 12:53:31 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00uuYW4Y; Thu, 21 Oct 2004 12:52:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9L9qQa15083; Thu, 21 Oct 2004 12:52:26 +0300 (EET DST) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 12:52:13 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 12:52:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Date: Thu, 21 Oct 2004 12:52:12 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD178382@esebe056.ntc.nokia.com> Thread-Topic: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Thread-Index: AcS3HN71TuT91G0lTHalVmBiS/Iu8AANcOSg To: , X-OriginalArrivalTime: 21 Oct 2004 09:52:12.0452 (UTC) FILETIME=[A3626640:01C4B753] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Nikos Mavrogiannopoulos writes: > > > > I'm not totally convinced about the usefulness of the RSA_PSK > > ciphersuites myself (but certainly if you don't want to use > > them, you don't have to implement them :-). Any opinions > > from other WG members? > > Certainly but my point also is, if certificate authenticated=20 > RSA ciphersuites are added, then why the DHE_RSA/DHE_DSS are > not added as well? A server with a DSS only certificate can=20 > only use DHE_DSS, so is not entitled to use certificate=20 > authenticated PSK.=20 Simply to avoid unnecessary complexity: if there's real need for those, they can always be defined in a separate document later. (The document does not have DH_DSS_PSK, DH_RSA_PSK, ECDH_ECDSA_PSK, ECDHE_ECDSA_PSK, ECDH_RSA_PSK, ECDHE_RSA_PSK,=20 or ECDHE_PSK versions either :-) > > Note that there are many types of identifiers that are not > > naturally composed of Unicode characters (e.g., IPv4/v6 > > addresses, IEEE 802 MAC addresses, X.500 Distinguished Names, > > even DNS names).=20 > > Maybe tagging it would help then. So clients and servers can use=20 > the tags to distinguish data in that field. Otherwise there is no=20 > way to support all of these schemes, and we end up with clients=20 > and servers that use X.509 DN, and others that use IP addresses,=20 > and others that use just UTF-8, and no interoperation between=20 > them is possible. There's no way around that problem, though: if one end sends an=20 X.500 DN and other end expects an IP address, it doesn't matter=20 whether that's tagged or UTF-8 encoded. The situations we'd like to avoid are (1) both ends are using, e.g., Distinguished Names, but encode them in a different way,=20 or (2) an implementation does not allow an administrator to=20 enter the identifier the other end is expecting.=20 Adding a "type tag" would most likely only make the situation=20 worse and increase complexity. But your first proposal=20 (mandating UTF-8 encoded character strings) would seem to handle both situations quite nicely. Given this, I propose changing this: "This document does not specify the format of the PSK identity or PSK identity hint; neither is specified how exactly the client uses the hint (if it uses it at all). The parties have to agree on the identities when the shared secret is configured (however, see Section 6 for related security considerations). In situations where the identity is entered by a person, it is RECOMMENDED that the input is processed using an appropriate stringprep [9] profile and encoded in octets using UTF-8 encoding [14]. One possible stringprep profile is described in [8]." To this: "It is expected that different types of identities are useful for different applications running over TLS. This document does not therefore mandate the use of any particular type of identity (such as IPv4 address or FQDN) or identity hint; neither is specified how exactly the client uses the hint=20 (if it uses it at all). To increase the chances for succesful interoperation between applications that do agree on what type of identity is used, the identity MUST be first converted to a character string,=20 and then encoded to octets using UTF-8 [UTF8]. For instance, o IPv4 addresses are sent as dotted-decimal strings (e.g., "192.0.1.2"), not as 32-bit integers in=20 network byte order. o Domain names are sent in their usual text form (e.g., "www.example.com" or "embedded\.dot.example.net"), not in DNS protocol wire format. o X.500 Distinguished Names are sent in their string representation [draft-ietf-ldapbis-dn-14], not as BER-encoded ASN.1. In situations where the identity is entered by a person, processing the character string with an appropriate=20 stringprep [9] profile is RECOMMENDED." Would this be more acceptable? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 14:56:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05734; Thu, 21 Oct 2004 14:56:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiJy-0003MY-49; Thu, 21 Oct 2004 15:09:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmE-00057l-DA; Thu, 21 Oct 2004 14:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhba-000080-7D for tls@megatron.ietf.org; Thu, 21 Oct 2004 14:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02384 for ; Thu, 21 Oct 2004 14:24:03 -0400 (EDT) Received: from b87036.upc-b.chello.nl ([212.83.87.36] helo=turtle.tue.nl) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKho4-0002LP-FH for tls@ietf.org; Thu, 21 Oct 2004 14:37:11 -0400 Received: from nmav by turtle.tue.nl with local (Exim 4.34) id 1CKhaS-0001Hg-6K for tls@ietf.org; Thu, 21 Oct 2004 20:22:56 +0200 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt Date: Thu, 21 Oct 2004 20:22:56 +0200 User-Agent: KMail/1.7 References: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> <200410201552.54978.nmav@gnutls.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410212022.56187.nmav@gnutls.org> X-Spam-Score: 2.6 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Thursday 21 October 2004 06:13, Eric Rescorla wrote: > > Certainly but my point also is, if certificate authenticated RSA > > ciphersuites are added, then why the DHE_RSA/DHE_DSS are not added as > > well? A server with a DSS only certificate can only use DHE_DSS, so is > > not entitled to use certificate authenticated PSK. > How common are DSS-only servers? Does anyone even issue DSS certs? In HTTP servers RSA is the only algorithm used. But since PSK is not for them there is no reason to prohibit it. > -Ekr -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 16:44:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22883; Thu, 21 Oct 2004 16:44:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKk0A-0007qn-80; Thu, 21 Oct 2004 16:57:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiur-00032t-Ot; Thu, 21 Oct 2004 15:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKilW-0002Cq-CZ for tls@megatron.ietf.org; Thu, 21 Oct 2004 15:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11299 for ; Thu, 21 Oct 2004 15:38:24 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiyB-0004Ob-LM for tls@ietf.org; Thu, 21 Oct 2004 15:51:32 -0400 Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CKilT-0007Sv-00; Thu, 21 Oct 2004 21:38:23 +0200 Received: from [128.32.153.61] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1CKilT-0003sf-00; Thu, 21 Oct 2004 21:38:23 +0200 Received: from eecs.berkeley.edu (localhost [127.0.0.1]) by tau.local (Postfix) with ESMTP id B0A182ED97; Thu, 21 Oct 2004 12:38:54 -0700 (PDT) Message-ID: <4178104E.8070709@eecs.berkeley.edu> Date: Thu, 21 Oct 2004 12:38:54 -0700 From: Bodo Moeller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Numbers used in TLS (AKA IANA considerations) References: <125EA890549C8641A72F3809CB80DCCD178380@esebe056.ntc.nokia.com> In-Reply-To: <125EA890549C8641A72F3809CB80DCCD178380@esebe056.ntc.nokia.com> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > TLS CIPHERSUITE NUMBERS > ======================= > 00,47 [*2] [......] > 00,4F [*2] > 00,50 (reserved for ongoing work) [srp-08], [*3] [......] > 00,58 (reserved for ongoing work) [srp-08], [*3] > 00,59 [*2] [......] > 00,5C [*2] > 00,77 (reserved for ongoing work) [openpgp-05] [*3,16] > 00,78 (reserved for ongoing work) [openpgp-05] [*3,16] > [*2] Some versions of OpenSSL have used these numbers > for elliptic curve ciphersuites. > > [*3] Some versions of OpenSSL have used these numbers > for elliptic curve ciphersuites, but the same > numbers are used for other purposes, too. Thanks for preparing the long list of ciphersuite and other numbers! There is no actual *version* of OpenSSL using these ciphersuites, just daily snapshots of work in progress; and because the ECC ciphersuites are not yet official, they are disabled by default. In the current TLS ECC draft, the rule for computing the premaster secret is incompatible with the earliest drafts. The OpenSSL development snapshosts currently implement the intermediate drafts, which are compatible with the earliest drafts and a Certicom implementation for smaller curves, and with the current draft for large curves. Once the TLS ECC specification is assigned actual ciphersuite numbers, the OpenSSL implementation can be updated accordingly. There is no reason to keep the ciphersuite numbers that are found in earlier TLS ECC drafts or in OpenSSL development snapshots because the ciphersuites will not interoperate anyway. So the footnote could read "Used by some OpenSSL development snapshots; obsoleted by [ecc-06]". _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 21:23:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22517; Thu, 21 Oct 2004 21:23:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoLs-0000Py-BG; Thu, 21 Oct 2004 21:36:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlY3-0003lE-JV; Thu, 21 Oct 2004 18:36:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkxO-0006pV-FM for tls@megatron.ietf.org; Thu, 21 Oct 2004 17:58:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08248 for ; Thu, 21 Oct 2004 17:58:47 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKlA5-000438-KD for tls@ietf.org; Thu, 21 Oct 2004 18:11:58 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i9LLwnNH009543 for ; Thu, 21 Oct 2004 15:58:49 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I5Y0036DFQ0Y3@edgemail1.Central.Sun.COM> for tls@ietf.org; Thu, 21 Oct 2004 15:58:48 -0600 (MDT) Received: from [129.146.72.241] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0I5Y004ZBFPZN2@mail.sun.net> for tls@ietf.org; Thu, 21 Oct 2004 15:58:48 -0600 (MDT) Date: Thu, 21 Oct 2004 14:59:31 -0700 From: Vipul Gupta Subject: Re: [TLS] Numbers used in TLS (AKA IANA considerations) In-reply-to: <4178104E.8070709@eecs.berkeley.edu> To: tls@ietf.org Message-id: <41783143.4010701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) References: <125EA890549C8641A72F3809CB80DCCD178380@esebe056.ntc.nokia.com> <4178104E.8070709@eecs.berkeley.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7BIT X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7BIT Bodo's comments are also true for another open source cryptographic library (NSS: Netscape Security Services) which powers the Mozilla/Firefox/Netscape browsers. NSS versions 3.8 and 3.9 implement the same ECC ciphersuites as the OpenSSL snapshots but ECC support in NSS is also turned off by default. Once the ECC in TLS draft is finalized, the ECC code in NSS will be updated accordingly. So the footnote could be further modified to read: "Used by some OpenSSL development snapshots and NSS 3.8/3.9, obsoleted by [ecc-06]" vipul Bodo Moeller wrote: > Pasi.Eronen@nokia.com wrote: > >> TLS CIPHERSUITE NUMBERS >> ======================= > > >> 00,47 [*2] > > [......] > >> 00,4F [*2] >> 00,50 (reserved for ongoing work) [srp-08], [*3] > > [......] > >> 00,58 (reserved for ongoing work) [srp-08], [*3] >> 00,59 [*2] > > [......] > >> 00,5C [*2] > > >> 00,77 (reserved for ongoing work) [openpgp-05] >> [*3,16] >> 00,78 (reserved for ongoing work) [openpgp-05] >> [*3,16] > > >> [*2] Some versions of OpenSSL have used these numbers >> for elliptic curve ciphersuites. >> >> [*3] Some versions of OpenSSL have used these numbers >> for elliptic curve ciphersuites, but the same >> numbers are used for other purposes, too. > > > > Thanks for preparing the long list of ciphersuite and other numbers! > > There is no actual *version* of OpenSSL using these ciphersuites, > just daily snapshots of work in progress; and because the ECC > ciphersuites are not yet official, they are disabled by default. > > In the current TLS ECC draft, the rule for computing the premaster > secret is incompatible with the earliest drafts. The OpenSSL > development snapshosts currently implement the intermediate drafts, > which are compatible with the earliest drafts and a Certicom > implementation for smaller curves, and with the current draft for > large curves. Once the TLS ECC specification is assigned actual > ciphersuite numbers, the OpenSSL implementation can be updated > accordingly. There is no reason to keep the ciphersuite numbers that > are found in earlier TLS ECC drafts or in OpenSSL development snapshots > because the ciphersuites will not interoperate anyway. > > So the footnote could read "Used by some OpenSSL development snapshots; > obsoleted by [ecc-06]". > > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Oct 21 21:53:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28106; Thu, 21 Oct 2004 21:53:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKopI-00021W-7B; Thu, 21 Oct 2004 22:06:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoGo-00010A-Nk; Thu, 21 Oct 2004 21:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmwp-00009X-24 for tls@megatron.ietf.org; Thu, 21 Oct 2004 20:06:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07280 for ; Thu, 21 Oct 2004 20:06:20 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKn9W-0004R1-P4 for tls@ietf.org; Thu, 21 Oct 2004 20:19:31 -0400 Received: from romeo.rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 69C2472CF; Thu, 21 Oct 2004 17:24:07 -0700 (PDT) Received: by romeo.rtfm.com (Postfix, from userid 556) id F107844AB0; Thu, 21 Oct 2004 17:05:48 -0700 (PDT) To: Nikos Mavrogiannopoulos Subject: Re: [TLS] WG Last Call for draft-ietf-tls-psk-02.txt References: <125EA890549C8641A72F3809CB80DCCD17837C@esebe056.ntc.nokia.com> <200410201552.54978.nmav@gnutls.org> <200410212022.56187.nmav@gnutls.org> From: Eric Rescorla Date: Thu, 21 Oct 2004 17:05:48 -0700 In-Reply-To: <200410212022.56187.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 21 Oct 2004 20:22:56 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Nikos Mavrogiannopoulos writes: > On Thursday 21 October 2004 06:13, Eric Rescorla wrote: > >> > Certainly but my point also is, if certificate authenticated RSA >> > ciphersuites are added, then why the DHE_RSA/DHE_DSS are not added as >> > well? A server with a DSS only certificate can only use DHE_DSS, so is >> > not entitled to use certificate authenticated PSK. >> How common are DSS-only servers? Does anyone even issue DSS certs? > > In HTTP servers RSA is the only algorithm used. But since PSK is not for them > there is no reason to prohibit it. It's not a matter of prohibiting it. It's a matter of whether our policy is to provide the combinatoric explosion of all algorithms every time we introduce something new. I consider that a bad policy. So, if DSS isn't widely used, then I don't think it's particularly important to provide a cipher suite number. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sat Oct 23 01:50:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15205; Sat, 23 Oct 2004 01:50:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLF0o-0006TW-0s; Sat, 23 Oct 2004 02:04:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLEkT-0003d8-UU; Sat, 23 Oct 2004 01:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLEeK-0001IV-Ll for tls@megatron.ietf.org; Sat, 23 Oct 2004 01:41:08 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14967 for ; Sat, 23 Oct 2004 01:41:06 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 90063718B for ; Fri, 22 Oct 2004 22:58:52 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Fri, 22 Oct 2004 22:40:32 -0700 From: Eric Rescorla Message-Id: <20041023055852.90063718B@sierra.rtfm.com> Subject: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a I have tallied the results of the straw poll on progressing draft-ietf-tls-ecc-XX.txt. The results are below: A (Proposed Standard): 12 B (Informational w/o extensions): 7 (including both chairs) C (Informational w/ extensions): 1 Win and I have consulted with the ADs and we believe that this does not represent a WG consensus to progress the document at Proposed Standard. Accordingly, we will be progressing the document at Informational. Authors: Please prepare a version of the document that removes the extensions and submit it as an I-D. Once you have done that, I intend to proceed immediately to WGLC on the document. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sat Oct 23 15:09:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16118; Sat, 23 Oct 2004 15:09:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRTw-0002HV-LH; Sat, 23 Oct 2004 15:23:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLREs-0006Td-QB; Sat, 23 Oct 2004 15:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRDf-00056z-WB for tls@megatron.ietf.org; Sat, 23 Oct 2004 15:06:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15703 for ; Sat, 23 Oct 2004 15:06:25 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLRQi-0002Eb-8Y for tls@ietf.org; Sat, 23 Oct 2004 15:19:59 -0400 Received: (qmail 13614 invoked by uid 0); 23 Oct 2004 19:06:17 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.33.150) by woodstock.binhost.com with SMTP; 23 Oct 2004 19:06:17 -0000 Message-Id: <6.1.2.0.2.20041023145812.044fa270@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 23 Oct 2004 15:06:03 -0400 To: "Dan Simon" , tls@ietf.org From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [TLS] PRF Negotiation X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f The PRF is not currently negotiated as part of the cipher suite. However, the draft-ietf-tls-gost-00.txt draft proposes a way to negotiate the PRF, but it is done independently from the rest of the algorithm negotiations. Given that at least one person other than the GOST algorithm specification authors is interested in PRF negotiation, I would like to see a discussion about this topic. Have the GOST algorithm specification authors done this in the best possible way? What are the alternatives? The GOST algorithm specification authors' proposal also has an impact on the Finished message. This leads to other questions. Can one negotiate which hash function to use when that hash function is in turn used to protect the integrity of the whole algorithm negotiation process? Russ At 09:42 PM 10/11/2004, Dan Simon wrote: >I believe I'm the guy who originally suggested the current parallel >construction of the PRF. At the time, I explicitly stated that the >whole business of using two fixed hash functions (instead of a single >function specified in the ciphersuite) was a stupid idea, and that I was >only proposing the parallel construction because certain people were >absolutely dead-set on the idea of using both MD5 and SHA1 in the PRF. >So naturally I'm all in favor of Hugo's proposal. Perhaps one day we >can get rid of the MD5 half altogether, and then make the hash function >used in the second half depend on the ciphersuite, so that SHA1 will >become replaceable, if necessary, merely by defining a new set of >ciphersuites. > > Dan _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Oct 25 19:58:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20677; Mon, 25 Oct 2004 19:57:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEwS-0004uJ-MG; Mon, 25 Oct 2004 20:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMETF-0000BV-DZ; Mon, 25 Oct 2004 19:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMD8W-0005SQ-Eb for tls@megatron.ietf.org; Mon, 25 Oct 2004 18:16:20 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27972 for ; Mon, 25 Oct 2004 18:16:16 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id C67DB7227 for ; Mon, 25 Oct 2004 15:34:23 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 25 Oct 2004 15:15:45 -0700 From: Eric Rescorla Message-Id: <20041025223423.C67DB7227@sierra.rtfm.com> Subject: [TLS] Finalizing TLS 1.1 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad I'm incorporating Pasi Eronen's Last Call comments. Pasi suggests that we should have IANA Registries for Alert Numbers, Record Content Types, and Handshake Message Types. I think this is a reasonable suggestion and I intend to implement it. Unless anyone objects strongly, I'm going to make all of these require RFC 2434 Standards Action. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Oct 27 02:02:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10969; Wed, 27 Oct 2004 02:02:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMh7R-0005q8-FR; Wed, 27 Oct 2004 02:17:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMgrb-0002j3-Hf; Wed, 27 Oct 2004 02:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMgq4-0001xT-6M for tls@megatron.ietf.org; Wed, 27 Oct 2004 01:59:16 -0400 Received: from amsfep14-int.chello.nl (nl-ams-slo-l4-01-pip-5.chellonetwork.com [213.46.243.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07798 for ; Wed, 27 Oct 2004 01:59:11 -0400 (EDT) Received: from [192.168.0.190] (really [212.83.87.36]) by amsfep14-int.chello.nl (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041027055840.MNNL10693.amsfep14-int.chello.nl@[192.168.0.190]> for ; Wed, 27 Oct 2004 07:58:40 +0200 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt User-Agent: KMail/1.7 References: <20041023055852.90063718B@sierra.rtfm.com> In-Reply-To: <20041023055852.90063718B@sierra.rtfm.com> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 27 Oct 2004 07:58:20 +0200 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Message-Id: <200410270758.20372.nmav@gnutls.org> Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Saturday 23 October 2004 07:40, Eric Rescorla wrote: (in my previous posting I used a different e-mail address and it did not appear, so I resend it) > The results are below: > A (Proposed Standard): 12 > B (Informational w/o extensions): 7 (including both chairs) > C (Informational w/ extensions): 1 > Win and I have consulted with the ADs and we believe that this does not > represent a WG consensus to progress the document at Proposed > Standard. Accordingly, we will be progressing the document at > Informational. I don't really find it usefull to have this as an informational RFC without the extensions. Especially the removal of "the Supported Elliptic Curves" extension may harm interoperation. Other than that, by not allowing this informational rfc to define extensions, this will prohibit any other proposed additions to TLS, that do not end up as proposed standard, from using TLS extensions. For example the SRP draft and the openpgp-keys, if end up as informational, they will be completely useless. They heavily depend on the TLS extensions. Given that there is no important reason for removing them except for the wording of the extensions rfc, I'd suggest to change the wording instead. PS. I disagree with the choice of the extension numbers in the ecc draft though, since they overlap with other extensions in the above drafts. -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Oct 27 09:49:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04164; Wed, 27 Oct 2004 09:49:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoPA-0005aM-Ke; Wed, 27 Oct 2004 10:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMo7E-0007eU-MP; Wed, 27 Oct 2004 09:45:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMo1O-0006TJ-5i for tls@megatron.ietf.org; Wed, 27 Oct 2004 09:39:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03748 for ; Wed, 27 Oct 2004 09:39:23 -0400 (EDT) Received: from tomts16-srv.bellnexxia.net ([209.226.175.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoF0-0005PH-0L for tls@ietf.org; Wed, 27 Oct 2004 09:53:46 -0400 Received: from simon ([64.231.79.110]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20041027133844.LNGK15612.tomts16-srv.bellnexxia.net@simon>; Wed, 27 Oct 2004 09:38:44 -0400 From: "Simon Blake-Wilson" To: "'Nikos Mavrogiannopoulos'" , Subject: RE: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt Date: Wed, 27 Oct 2004 09:38:40 -0400 Message-ID: <020c01c4bc2a$45656de0$c500a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <200410270758.20372.nmav@gnutls.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1276679955==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 This is a multi-part message in MIME format. --===============1276679955== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0208_01C4BC08.BDE8D710" This is a multi-part message in MIME format. ------=_NextPart_000_0208_01C4BC08.BDE8D710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree that it is desirable to keep the extensions. As one of the 12 in category A, if I'd had the choice between only B and C, I would have gone for C. I wonder if the others in A feel the same way. It seems to me that we have a couple of ways to achieve C: - Keep ECC in TLS as a single Informational draft and update the extensions RFC. - Split ECC in TLS into two - an informational RFC specifying the crypto, and a Proposed Standard specifying the extensions Is the second option (ie a Proposed Standard with a normative reference to an Informational RFC) allowed under IETF rules? Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Nikos > Mavrogiannopoulos > Sent: Wednesday, October 27, 2004 1:58 AM > To: tls@ietf.org > Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt > > > On Saturday 23 October 2004 07:40, Eric Rescorla wrote: > > (in my previous posting I used a different e-mail address and > it did not appear, so I resend it) > > > The results are below: > > A (Proposed Standard): 12 > > B (Informational w/o extensions): 7 (including both chairs) > > C (Informational w/ extensions): 1 > > > Win and I have consulted with the ADs and we believe that this does > > not represent a WG consensus to progress the document at Proposed > > Standard. Accordingly, we will be progressing the document at > > Informational. > > I don't really find it usefull to have this as an > informational RFC without the extensions. Especially the > removal of "the Supported Elliptic Curves" extension may harm > interoperation. > > Other than that, by not allowing this informational rfc to > define extensions, > this will prohibit any other proposed additions to TLS, that > do not end up as > proposed standard, from using TLS extensions. For example the > SRP draft and > the openpgp-keys, if end up as informational, they will be completely > useless. They heavily depend on the TLS extensions. > > Given that there is no important reason for removing them > except for the > wording of the extensions rfc, I'd suggest to change the > wording instead. > > > > PS. I disagree with the choice of the extension numbers in > the ecc draft > though, since they overlap with other extensions in the above drafts. > > -- > Nikos Mavrogiannopoulos > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_0208_01C4BC08.BDE8D710 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKJDCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggR5MIID4qADAgECAhBQvP6CEfX+K7FeZPKFUBttMA0GCSqGSIb3 DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDIyNTAwMDAw MFoXDTA1MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCh81iFspBl ua1ZyvbQpRCm13CI/+nUsztcRWpIVVcKLknRA2btu394xi3q/Qmw+hW2QkZmaeVsvULMrNXr171x s/jkxJ4noM8Xx1HPtMKZOeLr1A3IcSpZO5ZNePAoPPLAjGYxb3wJemzG3dBDhZ/BUWiwIMqMhju5 gG4TQoytKwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEF BQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkg cmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMG A1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZI hvcNAQEEBQADgYEAFDIEV02jprRnMwLnqOhTeQxHgtI/UHiybRDLo4dba4laCyzJHboTBDSrAs6f LD1+LfBYAgKgAgfTtFPezb2+qQP9uw/5JwnzXE9GlQKX73bafTHJ1qqDhUTQQK80CRxDrvX3y/qt VZDFPONmFhoxMWE9dzQRrknPZVEqCu5KikExggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAbbTAJBgUrDgMCGgUAoIICsjAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMjcxMzM4NDBaMCMGCSqG SIb3DQEJBDEWBBRF8RegGJtvY63OnAqRVEGKxSR6SjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhBQvP6CEfX+K7FeZPKFUBttMIH0BgsqhkiG9w0BCRACCzGB 5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5k aXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQULz+ghH1/iuxXmTyhVAb bTANBgkqhkiG9w0BAQEFAASBgHcFkreBhf6msk8yxA6LG226LBLCtNxOF9gQRF5SM0wkiQFGGZnE uZeQpRVTcwuwOCO25G1yV8JzTfjItgH/VnAfUCXHtChVPdEHcq64mtenGSdd0bcWSXYNBjpQu9IH +Kz7nL/1jwlqjQXwcbz79hUTLuWxHyfTkwgHmIQlO12NAAAAAAAA ------=_NextPart_000_0208_01C4BC08.BDE8D710-- --===============1276679955== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1276679955==-- From tls-bounces@ietf.org Thu Oct 28 05:57:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25119; Thu, 28 Oct 2004 05:57:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN7G6-00059V-HE; Thu, 28 Oct 2004 06:11:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN70T-00082M-71; Thu, 28 Oct 2004 05:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN700-0007uJ-SN for tls@megatron.ietf.org; Thu, 28 Oct 2004 05:55:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25026 for ; Thu, 28 Oct 2004 05:55:14 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN7E2-00057B-JF for tls@ietf.org; Thu, 28 Oct 2004 06:09:48 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9S9t9l14128; Thu, 28 Oct 2004 12:55:09 +0300 (EET DST) X-Scanned: Thu, 28 Oct 2004 12:54:35 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i9S9sZ0p017190; Thu, 28 Oct 2004 12:54:35 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00wU46LI; Thu, 28 Oct 2004 12:54:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9S9sXS15705; Thu, 28 Oct 2004 12:54:33 +0300 (EET DST) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 12:54:33 +0300 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 28 Oct 2004 12:54:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Numbers used in TLS (AKA IANA considerations) Date: Thu, 28 Oct 2004 12:54:33 +0300 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FD74@esebe056.ntc.nokia.com> Thread-Topic: [TLS] Numbers used in TLS (AKA IANA considerations) Thread-Index: AcS3uTJtfjc88uxnSj20ywEuMmpAkgFGsqow To: , X-OriginalArrivalTime: 28 Oct 2004 09:54:33.0644 (UTC) FILETIME=[206ED6C0:01C4BCD4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Thanks! I've updated the list and placed it at=20 Best regards, Pasi > -----Original Message----- > From: ext Vipul Gupta [mailto:Vipul.Gupta@Sun.COM] > Sent: Friday, October 22, 2004 1:00 AM > To: tls@ietf.org > Cc: Eronen Pasi (Nokia-NRC/Helsinki) > Subject: Re: [TLS] Numbers used in TLS (AKA IANA considerations) >=20 >=20 > Bodo's comments are also true for another open source > cryptographic library (NSS: Netscape Security Services) > which powers the Mozilla/Firefox/Netscape browsers. > NSS versions 3.8 and 3.9 implement the same ECC ciphersuites > as the OpenSSL snapshots but ECC support in NSS is also > turned off by default. Once the ECC in TLS draft is > finalized, the ECC code in NSS will be updated accordingly. >=20 > So the footnote could be further modified to read: >=20 > "Used by some OpenSSL development snapshots and NSS 3.8/3.9, > obsoleted by [ecc-06]" >=20 > vipul >=20 > Bodo Moeller wrote: > > Pasi.Eronen@nokia.com wrote: > >=20 > >> TLS CIPHERSUITE NUMBERS > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > >=20 > >> 00,47 [*2] > >=20 > > [......] > >=20 > >> 00,4F [*2] > >> 00,50 (reserved for ongoing work) =20 > [srp-08], [*3] > >=20 > > [......] > >=20 > >> 00,58 (reserved for ongoing work) =20 > [srp-08], [*3] > >> 00,59 [*2]=20 > >=20 > > [......] > >=20 > >> 00,5C [*2] > >=20 > >=20 > >> 00,77 (reserved for ongoing work) =20 > [openpgp-05]=20 > >> [*3,16] > >> 00,78 (reserved for ongoing work) =20 > [openpgp-05]=20 > >> [*3,16] > >=20 > >=20 > >> [*2] Some versions of OpenSSL have used these numbers > >> for elliptic curve ciphersuites. > >> > >> [*3] Some versions of OpenSSL have used these numbers > >> for elliptic curve ciphersuites, but the same > >> numbers are used for other purposes, too. > >=20 > >=20 > >=20 > > Thanks for preparing the long list of ciphersuite and other numbers! > >=20 > > There is no actual *version* of OpenSSL using these ciphersuites, > > just daily snapshots of work in progress; and because the ECC > > ciphersuites are not yet official, they are disabled by default. > >=20 > > In the current TLS ECC draft, the rule for computing the premaster > > secret is incompatible with the earliest drafts. The OpenSSL > > development snapshosts currently implement the intermediate drafts, > > which are compatible with the earliest drafts and a Certicom > > implementation for smaller curves, and with the current draft for > > large curves. Once the TLS ECC specification is assigned actual > > ciphersuite numbers, the OpenSSL implementation can be updated > > accordingly. There is no reason to keep the ciphersuite=20 > numbers that > > are found in earlier TLS ECC drafts or in OpenSSL=20 > development snapshots > > because the ciphersuites will not interoperate anyway. > >=20 > > So the footnote could read "Used by some OpenSSL=20 > development snapshots; > > obsoleted by [ecc-06]". _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls