From tls-bounces@ietf.org Wed Apr 6 12:43:17 2005 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 MAA03518; Wed, 6 Apr 2005 12:43:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDl2-0005sz-Hm; Wed, 06 Apr 2005 12:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDbE-0002RI-3N; Wed, 06 Apr 2005 12:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDbB-0002P9-LU for tls@megatron.ietf.org; Wed, 06 Apr 2005 12:41: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 MAA03258 for ; Wed, 6 Apr 2005 12:41:46 -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 1DJDjZ-0005ox-6K for tls@ietf.org; Wed, 06 Apr 2005 12:50:29 -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 j36GfRP28890; Wed, 6 Apr 2005 19:41:27 +0300 (EET DST) X-Scanned: Wed, 6 Apr 2005 19:59:12 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j36GxCq8002251; Wed, 6 Apr 2005 19:59:12 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00BMxsKi; Wed, 06 Apr 2005 19:59:11 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 j36GfHU02793; Wed, 6 Apr 2005 19:41:17 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Apr 2005 19:41:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 6 Apr 2005 19:41:01 +0300 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2005 19:41:01 +0300 Message-ID: Thread-Topic: Review of draft-ietf-tls-psk-07.txt thread-index: AcU1trJVS4j6LKvyQYCATzfdgmn+LQFD+blw To: , X-OriginalArrivalTime: 06 Apr 2005 16:41:01.0161 (UTC) FILETIME=[6A9E9D90:01C53AC7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable Cc: gen-art@alvestrand.no, tls@ietf.org Subject: [TLS] RE: Review of draft-ietf-tls-psk-07.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: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable Thanks for your review, Lakshminath! Russ, could you check that you're happy with the suggested handling of these comments? (If so, I can submit a revised=20 I-D later this week.) > I am reviewing this I-D as part of the Gen-Art IETF LC review=20 > process. > > > Please include a table of contents. Ok, will be added. > 1. The motivation might need to be revised. The first reason > seems to be at odds with the RSA_PSK ciphersuites and DKE_PSK > ciphersuites. > > The second reason makes sense in that the proposed protocol > provides a solution for environments where PSKs are already in > place. The motivation text is before the three ciphersuite sets (PSK, DHE_PSK, RSA_PSK) have been introduced, and the text a couple=20 of paragraphs later does describe that only the PSK variants=20 are free of public-key operations.=20 But perhaps we should clarify it slightly by changing o First, TLS may be used in performance-constrained environments where the CPU power needed for public key operations is not available. to this? o First, using pre-shared keys can, depending on the ciphersuite, avoid the need for public key operations.=20 This is useful if TLS is used in performance-constrained environments with limited CPU power. > (On the issue of small devices and performance constraints, > with Moore's law, performance constraints of today might be > invalid in a few years. Of course, with Moore's law the > requisite key lengths etc., also increase. Then comes the > question of how PSKs compare with public key operations with > shorter keys. It might be worthwhile for this I-D, and the > eventual RFC to include such a discussion). I agree that performance issues change quickly. Most devices=20 get faster, but decreasing prices also enable new low-cost low-performance devices that were not economical earlier. But I'm not sure how useful it would be to include this kind of discussion in this document. The text would get old pretty fast, and a meaningful comparison of the performance differences of various TLS ciphersuites in different kinds of devices would easily take several pages. > 2. In the last paragraph of Section 1, delete with in "with > RSA_PSK key exchange algorithm" replace "mutual" with "client" Technically, "mutual" is correct (if not very elegant English): the server also proves to the client that it knows the PSK. (It certainly would have been possible to design the RSA_PSK ciphersuites so that the PSK is used only for client-to-server authentication, but that was not done.) > 3. The Applicability Statement needs work. Please rewrite the > applicability statement to clearly state the intended use > alone. The alternatives, self-signed certs and SRP > ciphersuites can go elsewhere, perhaps in the Security > Considerations section. > 9. As noted earlier, please suggest alternatives to PSKs in > Section 7.2 or in a separate subsection in Section 7. > > That section should say something along the lines of: PSKs > should only be used after other alternatives such as xx > (self-signed certs?) and yy (TLS-SRP?) have been ruled out > either due to performance constraints or deployment > constraints etc. Since the applicability statement is quite short (three paragraphs), I don't think splitting it to two subsections=20 would be helpful. Besides, discussing the other alternatives (e.g. self-signed certs and SRP) is one good way to describe when PSKs are and are not the best choice. (But if you have concrete suggestions on how this section should be rephrased, they're certainly welcome.) > 4. Replace all occurrences of "an uint16" with "a uint16" OK, will be done. > 5. On "See [8] for a more detailed rationale.": Considering > [8] is an email, please summarize the rationale in the I-D=20 > for completeness. Well, the rationale is IMHO not very interesting, and the choice was, to some degree, arbitrary: other alternatives would have been OK as well. How about changing note 2 from Note 2: Using zeroes for "other_secret" 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. =20 See [8] for a more detailed rationale. to this? Note 2: Using zeroes for "other_secret" 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.=20 This was considered more elegant from an analytical viewpoint than, for instance, using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See [8] for a more detailed rationale. > 6. In Page 6, please add the following to the second to last > paragraph. > > PreMaster Secret =3D length-of-Z-in-octets || Z || > length-of-PSK-in-octets || PSK > > where the "length" fields are of type unit16 > > or something like that. > > 7. In Section 4, the paragraph starting with "The > EncryptedPreMasterSecret ..." needs some work. > > Perhaps including a line similar to the one suggested above > might help. > > PreMasterSecret =3D length-of-EncryptedPreMasterSecret-in-octets > || EncryptedPreMasterSecrtet || length-of-PSK || PSK It seems the wording of these paragraphs has been fine-tuned in almost every revision of the document :-) The document already describes the premaster secret construction in two different ways, as plain English (concatenate this and that), and by using the "general structure" shown in TLS presentation language ("struct { .. }") in Section 2. I think a third way to describe the same thing would be a bit redundant... So unless you think the current descriptions are ambiguous (and would lead to interoperability problems), I'd suggest keeping them as they are. > 8. In Section 7.2, it might be worthwhile to include a > passphrase to PSK generation function for easy reference. Section 7.2 recommends providing functionality for generating a random PSK, but if the PSK is entered as an ASCII string (Section 5.4 requires management interface support for it),=20 it's used as entered. Or in other words, it's not run through anything like PKCS#5 PBKDF2 before being used. (If it was, TLS-PSK would also have to negotiate (or specify) the various parameters (like iteration count) needed by PBKDF2 to get any interoperability. There was=20 at some point also discussion about using PKCS#5 PBKDF2 for all=20 keys; Hugo's mail in [8] also has parts related to this.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Apr 7 11:50:15 2005 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 LAA07035; Thu, 7 Apr 2005 11:50:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZPR-00085l-NI; Thu, 07 Apr 2005 11:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZAA-0005ta-1v; Thu, 07 Apr 2005 11:43:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZA8-0005tU-HS for tls@megatron.ietf.org; Thu, 07 Apr 2005 11:43:20 -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 LAA06298 for ; Thu, 7 Apr 2005 11:43:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZIh-0007pw-Qt for tls@ietf.org; Thu, 07 Apr 2005 11:52:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2005 08:43:10 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j37Fh5gE028199; Thu, 7 Apr 2005 08:43:05 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 7 Apr 2005 08:46:31 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6904F9532E@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Draft update: TLS Session Resumption without Server-Side State Thread-Index: AcU7iH0BmhxLkDRIQZGoTkRh7nbn0w== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: pasi.eronen@nokia.com, hannes.tschofenig@siemens.com Subject: [TLS] Draft update: TLS Session Resumption without Server-Side State 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 Content-Transfer-Encoding: quoted-printable We have posted a new revision of the draft TLS Session Resumption without Server-Side State (http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-02.txt). We would appreciate feedback on the contents of the draft. We would also like to know if there is interest within the TLS working group to take this on as work item.=20 Thanks, Joe=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 8 15:43:32 2005 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 PAA01061; Fri, 8 Apr 2005 15:43:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzWy-0000fX-Sm; Fri, 08 Apr 2005 15:52:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzBH-0000Ly-LX; Fri, 08 Apr 2005 15:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzBC-0000Kh-EM; Fri, 08 Apr 2005 15:30:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26888; Fri, 8 Apr 2005 15:30:09 -0400 (EDT) Message-Id: <200504081930.PAA26888@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Apr 2005 15:30:08 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-09.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.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECC Cipher Suites For TLS Author(s) : V. Gupta, et al. Filename : draft-ietf-tls-ecc-09.txt Pages : 35 Date : 2005-4-8 This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-8160010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-8160010.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From tls-bounces@ietf.org Fri Apr 8 20:51:20 2005 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 UAA26147; Fri, 8 Apr 2005 20:51:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4Kt-0007yw-Uy; Fri, 08 Apr 2005 21:00:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4B2-0001si-U0; Fri, 08 Apr 2005 20:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4B0-0001sd-Gv for tls@megatron.ietf.org; Fri, 08 Apr 2005 20:50:19 -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 UAA26069 for ; Fri, 8 Apr 2005 20:50:17 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4Jr-0007sZ-SN for tls@ietf.org; Fri, 08 Apr 2005 20:59:28 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net[68.147.30.54] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1DK4Av3qN0-0003Ps; Sat, 09 Apr 2005 02:50:13 +0200 Received: by tau.local (Postfix, from userid 500) id 8663E319F4; Fri, 8 Apr 2005 16:47:18 -0600 (MDT) Date: Fri, 8 Apr 2005 16:47:18 -0600 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt Message-ID: <20050408224717.GA17110@tau.local> References: <20041023055852.90063718B@sierra.rtfm.com> <200410270758.20372.nmav@gnutls.org> <603AF135-2D30-11D9-B118-000A95C4D60E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 2.1 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: 2.1 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On Tue, Nov 02, 2004 at 04:48:02PM -0800, Eric Rescorla wrote: > Vipul Gupta writes: >> In fact, at least one of the authors of that draft didn't realize that >> the sentence would preclude Informational/Experimental >> RFCs from defining new TLS extensions. So I'd also favor changing >> the wording in RFC 3546. >> >> Who needs to approve such a change and if they do would you want >> us to remove the extensions in the ECC draft until the change is made >> or could it proceed to last call in parallel with the change to RFC >> 3546? > You'd need to create a new document to revise 3546 and get WG > consensus behind it. The documents should proceed in parallel. Hi Eric, I believe we are now ready for Last Call for both specifications: 1. draft-ietf-tls-rfc3546bis-00.txt (TLS Extensions) 2. draft-ietf-tls-ecc-09.txt (ECC Cipher Suites for TLS). The former is for Standards Track; the latter would be Informational. 1. Since November, we have draft-ietf-tls-rfc3546bis-00.txt by the same authors as RFC 3546, with the change described above. Core sentence: "ExtensionType values are to be assigned via IETF Consensus as defined in RFC 2434" Otherwise, the ID just clarifies the handling of TLS extensions with session resumption (now stating that "In general the specification of each extension type must include a discussion of the effect of the extension both during new sessions and during resumed sessions" instead of trying to give a general rule for all extensions). 2. The latest revision of the TLS-ECC draft is at http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-09.txt The draft uses extension to ensure that interoperability can be achieved (point compression can be used if desired, e.g. to accomodate fielded certificates that rely on point compression, but is forbidden if either party does not support it; the server may not pick an ECC ciphersuite unless the client's ECC capabilities as specified in the extensions are sufficient to successfully finish the handshake). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 8 21:46:49 2005 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 VAA29392; Fri, 8 Apr 2005 21:46:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5Ca-0001sN-D4; Fri, 08 Apr 2005 21:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK52l-0005Zb-SL; Fri, 08 Apr 2005 21:45:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK52j-0005ZW-L0 for tls@megatron.ietf.org; Fri, 08 Apr 2005 21:45:49 -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 VAA29352 for ; Fri, 8 Apr 2005 21:45:48 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5Ba-0001rE-MQ for tls@ietf.org; Fri, 08 Apr 2005 21:55:00 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 157A8170DF; Fri, 8 Apr 2005 18:52:15 -0700 (PDT) To: Bodo Moeller Subject: Re: [TLS] Next steps for draft-ietf-tls-ecc-XX.txt References: <20041023055852.90063718B@sierra.rtfm.com> <200410270758.20372.nmav@gnutls.org> <603AF135-2D30-11D9-B118-000A95C4D60E@sun.com> <20050408224717.GA17110@tau.local> From: Eric Rescorla Date: Fri, 08 Apr 2005 18:52:15 -0700 In-Reply-To: <20050408224717.GA17110@tau.local> (Bodo Moeller's message of "Fri, 8 Apr 2005 16:47:18 -0600") Message-ID: <86y8bsbttc.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.0 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: 2.0 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Bodo Moeller writes: > On Tue, Nov 02, 2004 at 04:48:02PM -0800, Eric Rescorla wrote: >> Vipul Gupta writes: > >>> In fact, at least one of the authors of that draft didn't realize that >>> the sentence would preclude Informational/Experimental >>> RFCs from defining new TLS extensions. So I'd also favor changing >>> the wording in RFC 3546. >>> >>> Who needs to approve such a change and if they do would you want >>> us to remove the extensions in the ECC draft until the change is made >>> or could it proceed to last call in parallel with the change to RFC >>> 3546? > >> You'd need to create a new document to revise 3546 and get WG >> consensus behind it. The documents should proceed in parallel. > > Hi Eric, > > I believe we are now ready for Last Call for both specifications: > > 1. draft-ietf-tls-rfc3546bis-00.txt (TLS Extensions) > 2. draft-ietf-tls-ecc-09.txt (ECC Cipher Suites for TLS). I agree. I'll issue a WG LC.. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 8 21:50:35 2005 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 VAA29580; Fri, 8 Apr 2005 21:50:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5GE-00020X-De; Fri, 08 Apr 2005 21:59:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK56R-0006kY-BJ; Fri, 08 Apr 2005 21:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK56P-0006kO-5C for tls@megatron.ietf.org; Fri, 08 Apr 2005 21:49:37 -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 VAA29540 for ; Fri, 8 Apr 2005 21:49:35 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5FG-0001za-CM for tls@ietf.org; Fri, 08 Apr 2005 21:58:47 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 2C73D284CC for ; Fri, 8 Apr 2005 19:21:21 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Fri, 08 Apr 2005 18:56:16 -0700 From: Eric Rescorla Message-Id: <20050409022121.2C73D284CC@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [TLS] WGLC for draft-ietf-tls-ecc 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: 79899194edc4f33a41f49410777972f8 This is a Working Group Last Call for draft-ietf-tls-ecc-09.txt The target status for this document is Information. Please send comments to the mailing list as followups to this message. The Last Call will last for two weeks, ending on April 22. Note: I will be out of e-mail contact for 2 weeks starting April 20th, so in practice I won't be able to deal with comments before May 5th. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Apr 8 21:55:13 2005 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 VAA00125; Fri, 8 Apr 2005 21:55:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5Kj-0002Ei-6Y; Fri, 08 Apr 2005 22:04:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK57F-0006xi-QJ; Fri, 08 Apr 2005 21:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK57F-0006xd-1G for tls@megatron.ietf.org; Fri, 08 Apr 2005 21:50:29 -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 VAA29572 for ; Fri, 8 Apr 2005 21:50:27 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5G6-00020J-8A for tls@ietf.org; Fri, 08 Apr 2005 21:59:39 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 3A7202851A for ; Fri, 8 Apr 2005 19:22:13 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Fri, 08 Apr 2005 18:57:08 -0700 From: Eric Rescorla Message-Id: <20050409022213.3A7202851A@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [TLS] WGLC for draft-ietf-tls-rfc3546bis-00.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: de4f315c9369b71d7dd5909b42224370 This is a Working Group Last Call for draft-ietf-tls-rfc3546bis-00.txt The target status for this document is Proposed Standard. Please send comments to the mailing list as followups to this message. The Last Call will last for two weeks, ending on April 22. Note: I will be out of e-mail contact for 2 weeks starting April 20th, so in practice I won't be able to deal with comments before May 5th. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 13 14:10:32 2005 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 OAA18894; Wed, 13 Apr 2005 14:10:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmTj-0006fl-GS; Wed, 13 Apr 2005 14:20:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmFs-0006xk-8d; Wed, 13 Apr 2005 14:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmFr-0006v4-2Z for tls@megatron.ietf.org; Wed, 13 Apr 2005 14: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 OAA18752 for ; Wed, 13 Apr 2005 14:05:57 -0400 (EDT) Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLmPG-0006bU-Ay for tls@ietf.org; Wed, 13 Apr 2005 14:16:08 -0400 Received: (qmail invoked by alias); 13 Apr 2005 18:05:40 -0000 Received: from d037031.adsl.hansenet.de (EHLO [80.171.37.31]) [80.171.37.31] by mail.gmx.net (mp005) with SMTP; 13 Apr 2005 20:05:40 +0200 X-Authenticated: #25888033 Message-ID: <425D5F90.7030003@gmx.net> Date: Wed, 13 Apr 2005 20:06:08 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc References: <20050409022121.2C73D284CC@sierra.rtfm.com> In-Reply-To: <20050409022121.2C73D284CC@sierra.rtfm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.1 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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.1 (++) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > This is a Working Group Last Call for draft-ietf-tls-ecc-09.txt > The target status for this document is Information. > > Please send comments to the mailing list as followups to this > message. some comments: > 5.1 Client Hello Extensions ... > enum { uncompressed (0), ansiX962_compressed (1), > ansiX962_hybrid (2), reserved (3 .. 255) > } ECPointFormat; > > struct { > ECPointFormat ec_point_format_list<1..28-1> > } ECPointFormatList; > > Three point formats are included in the definition of ECPointFormat > above. The uncompressed point format is the default format in that > implementations of this document MUST support it. The > ansiX962_compressed format reduces bandwidth by including only the > x-coordinate and a single bit of the y-coordinate of the point. The > ansiX962_hybrid format includes both the full y-coordinate and the > compressed y-coordinate to allow flexibility and improve efficiency > in some cases. Implementations of this document MAY support the > ansiX962_compressed and ansiX962_hybrid point formats. (These three > formats are described in [6].) Values 248 through 255 are reserved > for private use. what's the pratical value of including the hybrid format ? > Items in ec_point_format_list are ordered according to the client's > preferences (favorite choice first). > > A client that can parse only the uncompressed point format includes > an extension consisting of the following octets: > > 00 ?? 00 02 01 00 > > A client that prefers the use of the ansiX962_compressed format over > uncompressed may indicate that preference by including an extension > consisting of the following octets: > > 00 ?? 00 03 02 01 00 this is somewhat problematic: for example openssl (0.9.8-dev) should support every of the above mentioned named curves and it can handle compressed points for GF(p) as well (as the point compression algorithm for characteristic 2 is patented point compression for GF(2^m) curves is disabled by default in openssl). But there's no way in express this using the above extensions: one can either list every supported curve and offer no point compression or restrict the list of curves to "prime"-curves and offer point compression. ... > 5.3 Server Certificate ... > Actions of the sender: > > The server constructs an appropriate certificate chain and conveys it > to the client in the Certificate message. If the client has used a > Supported Elliptic Curves Extension, the public key in the server's > certificate MUST respect the client's choice of elliptic curves; in > particular, the public key MUST employ a named curve (not the same > curve as an explicit curve) unless the client has indicated support > for explicit curves of the appropriate type. If the client has used > a Supported Point Formats Extension, both the server's public key > point and (in the case of an explicit curve) the curve's base point every ec point appearing in the cert chain must adhere to the supported point format and not only the public key and the generator of the server certificate (otherwise the client might be unable to verify the cert chain). > MUST respect the client's choice of point formats. (A server that > cannot satisfy these requirements must not choose an ECC cipher suite > in its ServerHello message.) ... > > 5.9 Elliptic Curve Certificates > > X509 certificates containing ECC public keys or signed using ECDSA > MUST comply with [11] or another RFC that replaces or extends it. as no one knows what will be in future versions of these RFCs this might be challenging to implement ;-) > Clients SHOULD use the elliptic curve domain parameters recommended > in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. > > 5.10 ECDH, ECDSA and RSA Computations > > All ECDH calculations (including parameter and key generation as well > as the shared secret calculation) MUST be performed according to [5] > > > > Gupta, et al. Expires October 9, 2005 [Page 26] > > Internet-Draft ECC Cipher Suites for TLS April 2005 > > > using the ECKAS-DH1 scheme with the identity map as key derivation > function, so that the premaster secret is the x-coordinate of the > ECDH shared secret elliptic curve point, i.e. the octet string Z in > IEEE 1363 terminology. > > Note that a new extension may be introduced in the future to allow > the use of a different KDF during computation of the premaster > secret. In this event, the new KDF would be used in place of the > process detailed above. This may be desirable, for example, to > support compatibility with the planned NIST key agreement standard. > > All ECDSA computations MUST be performed according to ANSI X9.62 [6] > or its successors. Data to be signed/verified is hashed and the > result run directly through the ECDSA algorithm with no additional > hashing. The default hash function is SHA-1 [7] and sha_size (see > Section 5.4 and Section 5.8) is 20. However, an alternative hash > function, such as one of the new SHA hash functions specified in FIPS > 180-2 [7], may be used instead if the certificate containing the EC > public key explicitly requires use of another hash function. (The > mechanism for specifying the required hash function has not been > standardized but this provision anticipates such standardization and > obviates the need to update this document in response. Future PKIX > RFCs may choose, for example, to specify the hash function to be used > with a public key in the parameters field of subjectPublicKeyInfo.) the ability whether or not the client/server supports the new ecc asn.1 features should perhaps be indicated in yet another tls extension Cheers, Nils _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Apr 13 17:14:39 2005 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 RAA07797; Wed, 13 Apr 2005 17:14:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLpLx-0004eR-5D; Wed, 13 Apr 2005 17:24:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLp9C-0005ew-PT; Wed, 13 Apr 2005 17:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLp9B-0005dD-D2 for tls@megatron.ietf.org; Wed, 13 Apr 2005 17:11: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 RAA07661 for ; Wed, 13 Apr 2005 17:11:25 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLpIm-0004aN-Kk for tls@ietf.org; Wed, 13 Apr 2005 17:21:39 -0400 Received: from dhcp238.math.ucalgary.ca[136.159.61.238] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1DLp8s3zTn-0003et; Wed, 13 Apr 2005 23:11:22 +0200 Received: by tau.local (Postfix, from userid 500) id 0E5EB31A23; Wed, 13 Apr 2005 15:10:23 -0600 (MDT) Date: Wed, 13 Apr 2005 15:10:23 -0600 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc Message-ID: <20050413211023.GA14810@tau.local> References: <20050409022121.2C73D284CC@sierra.rtfm.com> <425D5F90.7030003@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425D5F90.7030003@gmx.net> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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: 1449ead51a2ff026dcb23465f5379250 On Wed, Apr 13, 2005 at 08:06:08PM +0200, Nils Larsch wrote: >> [...] draft-ietf-tls-ecc-09.txt > some comments: Thanks for the comments. All these are issues that I have previously considered. This does, of course, not necessarily mean that my answers as given below are the best ones, so you are certainly invited to argue against them :-) >> enum { uncompressed (0), ansiX962_compressed (1), >> ansiX962_hybrid (2), reserved (3 .. 255) >> } ECPointFormat; > what's the pratical value of including the hybrid format ? The practical value surely is very limited; support for hybrid format is mostly for completeness, given existing standards that allow it. (If someone has an ECC certificate that happens to use hybrid format, this allows them to use it for TLS.) These are small advantages, but then this is a simple thing to add to the protocol -- support for the hybrid format is completely optional, after all. >> A client that prefers the use of the ansiX962_compressed format over >> uncompressed may indicate that preference by including an extension >> consisting of the following octets: >> >> 00 ?? 00 03 02 01 00 > this is somewhat problematic: for example openssl (0.9.8-dev) should > support every of the above mentioned named curves and it can handle > compressed points for GF(p) as well (as the point compression algorithm > for characteristic 2 is patented point compression for GF(2^m) curves is > disabled by default in openssl). But there's no way in express this using > the above extensions: one can either list every supported curve and offer > no point compression or restrict the list of curves to "prime"-curves and > offer point compression. Yes, I am aware of this restriction. My reason for keeping the ECPointFormat type as above was that generally the default format, uncompressed, is a very good choice anyway (it means just a few more bytes and its use can usually save some computation time), and that the restriction keeps the protocol a little simpler and the TLS extensions a little shorter. Point formats other than uncompressed are most likely to be of use in closed environments, e.g. to accommodate specific certificates. In such scenarios, common parameters will have been somehow negotiated offline anyway, such as by deploying clients that support only a single curve in the first place. Then the online negotiation through TLS extensions would be just to confirm that the current handshake can really finish as expected (so that the server can switch to appropriate parameters, e.g. an RSA certificate, when an "outsider" client connects). On the other hand, servers meant to use ECC certificates with any ECC-capable client, friend or foe, will need certificates employing the uncompressed format anyway. Thus, point format negotiation has considerable less value in such open scenarios. So the short design rationale is as follows: - Point format negotiation can be important for some closed environments; - but point format negotiation is not important enough that we have to bother doing it in a perfectly flexible way. Now obviously this is just one way to view it. Would you prefer to have more fine-grained ECPointFormat values, such as uncompressed, ansiX962_compressed_prime, anxiX962_compressed_char2, ansiX962_hybrid_prime, ansiX962_hybrid_char2 ? This would't be too complicated either. And, possibly more importantly, this set of possibilities would be easier to explain :-) If this is preferred, I wouldn't mind changing the specification accordingly. >> 5.3 Server Certificate >> The server constructs an appropriate certificate chain and conveys it >> to the client in the Certificate message. If the client has used a >> Supported Elliptic Curves Extension, the public key in the server's >> certificate MUST respect the client's choice of elliptic curves; in >> particular, the public key MUST employ a named curve (not the same >> curve as an explicit curve) unless the client has indicated support >> for explicit curves of the appropriate type. If the client has used >> a Supported Point Formats Extension, both the server's public key >> point and (in the case of an explicit curve) the curve's base point > every ec point appearing in the cert chain must adhere to the supported > point format and not only the public key and the generator of the server > certificate (otherwise the client might be unable to verify the cert chain). I am aware of the possible certificate chain verification problem. The specification is meant to guarantee that the key exchange can proceed without problems, but not necessarily that certificate verification is always possible. Keep in mind that certificate verification can fail due to other reasons, notably due to an unknown root CA, or various features present in X.509 certificates (such as unknown extensions that are tagged critical). We cannot avoid all of these problems in general. If the client uses the trusted_ca_keys TLS extension from RFC 3546, then problem of encountering a totally unknown root CA can be avoided. But in this case, the problem of unsupported point formats (or unsupported curves, or various X.509 problems) can just as well be avoided through CA policies: As long as the CAs stick to uncompressed format as a good default, there will be no verification problems (apart from the usual X.509 nightmare). >> 5.9 Elliptic Curve Certificates >> >> X509 certificates containing ECC public keys or signed using ECDSA >> MUST comply with [11] or another RFC that replaces or extends it. > as no one knows what will be in future versions of these RFCs this > might be challenging to implement ;-) I am not sure about what the best wording would be here ... I think, however, that the current wording is reasonable (note that it's "or", not "and", so this does not tell you that you have to support future RFCs). >> All ECDSA computations MUST be performed according to ANSI X9.62 [6] >> or its successors. Data to be signed/verified is hashed and the >> result run directly through the ECDSA algorithm with no additional >> hashing. The default hash function is SHA-1 [7] and sha_size (see >> Section 5.4 and Section 5.8) is 20. However, an alternative hash >> function, such as one of the new SHA hash functions specified in FIPS >> 180-2 [7], may be used instead if the certificate containing the EC >> public key explicitly requires use of another hash function. (The >> mechanism for specifying the required hash function has not been >> standardized but this provision anticipates such standardization and >> obviates the need to update this document in response. Future PKIX >> RFCs may choose, for example, to specify the hash function to be used >> with a public key in the parameters field of subjectPublicKeyInfo.) > the ability whether or not the client/server supports the new ecc asn.1 > features should perhaps be indicated in yet another tls extension Possibly. But here the same reasoning applies as above in the comments for section 5.3: We cannot even hope to completely negotiate every feature that may affect certificate verification; sometimes authentication may fail because of this, but the handshake will proceed anyay. Any important additional details should be taken into account in CA policies. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Sat Apr 16 04:53:11 2005 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 EAA05669; Sat, 16 Apr 2005 04:53:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMjDE-00037m-5b; Sat, 16 Apr 2005 05:03:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMioP-0007Tb-G6; Sat, 16 Apr 2005 04:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMioN-0007TH-3A for tls@megatron.ietf.org; Sat, 16 Apr 2005 04:37:55 -0400 Received: from universe.uohyd.ernet.in (universe.uohyd.ernet.in [202.41.85.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05000 for ; Sat, 16 Apr 2005 04:36:47 -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 OAA06785 for ; Sat, 16 Apr 2005 14:00:51 -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 j3GE2D5G014295 for ; Sat, 16 Apr 2005 19:32:13 +0530 Received: (from apache@localhost) by ailab.uohyd.ernet.in (8.12.8/8.12.8/Submit) id j3GE2COF014293; Sat, 16 Apr 2005 19:32:12 +0530 X-Authentication-Warning: ailab.uohyd.ernet.in: apache set sender to hussam@localhost using -f Received: from 172.16.1.2 (proxying for 172.16.17.83) (SquirrelMail authenticated user hussam) by 172.16.17.2 with HTTP; Sat, 16 Apr 2005 19:32:12 +0530 (IST) Message-ID: <47192.172.16.1.2.1113660132.squirrel@172.16.17.2> Date: Sat, 16 Apr 2005 19:32:12 +0530 (IST) From: "Hussam Saeed" To: 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] Exportability 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 8bit Dear brothers, i really need to know what does exportable cipher means? how it affects security and performance? for example I want to know what does EXP-DHE-RSA-DES-CBC-SHA and EXP1024-RC4-SHA ciphers mean in the context of keys length? what is encrypted and what is sent in clear text? and why? what is the idea behind that? what is the difference between EXP ciphers and EXP1024 cihers? please i need answer for that. it is urgent Thanks _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Apr 16 21:39:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMylC-0005oD-Bh; Sat, 16 Apr 2005 21:39:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMBob-0006IV-DT for tls@megatron.ietf.org; Thu, 14 Apr 2005 17:23:57 -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 RAA01478 for ; Thu, 14 Apr 2005 17:23:48 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMByY-0004Ii-BM for tls@ietf.org; Thu, 14 Apr 2005 17:34:15 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3ELNGXO004764; Thu, 14 Apr 2005 14:23:16 -0700 (PDT) Received: from [129.46.75.63] (ldondeti.na.qualcomm.com [129.46.75.63]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j3ELNCfY003817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Apr 2005 14:23:12 -0700 (PDT) Message-ID: <425EDF40.9030102@gmail.com> Date: Thu, 14 Apr 2005 14:23:12 -0700 From: Lakshminath Dondeti User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 16 Apr 2005 21:39:40 -0400 Cc: tls@ietf.org, gen-art@alvestrand.no Subject: [TLS] Re: Review of draft-ietf-tls-psk-07.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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Pasi and all, Apologies for the delay in my reply to this. Please see inline for some additional thoughts. Pasi.Eronen@nokia.com wrote: >Thanks for your review, Lakshminath! > >Russ, could you check that you're happy with the suggested >handling of these comments? (If so, I can submit a revised >I-D later this week.) > > > > > > >>3. The Applicability Statement needs work. Please rewrite the >>applicability statement to clearly state the intended use >>alone. The alternatives, self-signed certs and SRP >>ciphersuites can go elsewhere, perhaps in the Security >>Considerations section. >> >> > > > >>9. As noted earlier, please suggest alternatives to PSKs in >>Section 7.2 or in a separate subsection in Section 7. >> >>That section should say something along the lines of: PSKs >>should only be used after other alternatives such as xx >>(self-signed certs?) and yy (TLS-SRP?) have been ruled out >>either due to performance constraints or deployment >>constraints etc. >> >> > >Since the applicability statement is quite short (three >paragraphs), I don't think splitting it to two subsections >would be helpful. Besides, discussing the other alternatives >(e.g. self-signed certs and SRP) is one good way to describe >when PSKs are and are not the best choice. > >(But if you have concrete suggestions on how this section >should be rephrased, they're certainly welcome.) > > > Applicability statement: +++++++++++++++ The ciphersuites defined in this document offer weak security properties and thus intended for constrained scenarios where stronger ciphersuites cannot be used due to deployment issues and performance constraints. If performance is not an issue, self-signed certificates with public key fingerprints might be more appropriate than TLS-PSK ciphersuites. The configuration complexity between self-signed certs with public key fingerprints is comparable, if not slightly more efficient, to shared secret configuration. Another alternative is to use Secure Remote Password (SRP) ciphersuites for shared secret authentication [4]. SRP was designed to be used with passwords, but incorporates protection against dictionary attacks, i.e., more secure compared to TLS-PSK ciphersuites. Self-signed certs based ciphersuites and SRP based ciphersuites require computationally expensive operations compared to TLS-PSK, and thus in computationally and battery power limited devices, TLS-PSK offers protection better than no security at all. Similarly, there are application scenarios, where a shared secret is already established between two parties, where at least one of them has computational limitations. Use of TLS-PSK ciphersuites is appropriate in such cases. Finally, the general guidance is for two communicating parties to rule out other other TLS ciphersuites before using TLS-PSK suites, and with the understanding that PSK based ciphersuites are vulnerable to dictionary attacks, and generally weak (i.e., a moderately motivated adversary has a good chance of impersonating one or both parties and read TLS protected traffic. +++++++++++++++++ Here is my first attempt at this (and no I don't want to spend cycles on revisions :-)). Please feel free to use portions of it or none at all. > snip> > >>5. On "See [8] for a more detailed rationale.": Considering >>[8] is an email, please summarize the rationale in the I-D >>for completeness. >> >> > >Well, the rationale is IMHO not very interesting, and the choice >was, to some degree, arbitrary: other alternatives would have >been OK as well. > >How about changing note 2 from > > Note 2: Using zeroes for "other_secret" 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 [8] for a more detailed rationale. > >to this? > > Note 2: Using zeroes for "other_secret" 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. > This was considered more elegant from an analytical viewpoint > than, for instance, using the same key for both the HMAC-MD5 > and HMAC-SHA1 parts. See [8] for a more detailed rationale. > > > That sounds ok. My main concern is that providing a reference to a mailing list posting probably might not be of help to a reader some 2 years from now. I think that this text should stand along, and any credits to Hugo should just go into the Acknowledgments section (References should be limited to some type of publication that is somewhat easily retrievable in the future. The RFC-Editor might complain about this). >>8. In Section 7.2, it might be worthwhile to include a >>passphrase to PSK generation function for easy reference. >> >> > >Section 7.2 recommends providing functionality for generating a >random PSK, but if the PSK is entered as an ASCII string >(Section 5.4 requires management interface support for it), >it's used as entered. > >Or in other words, it's not run through anything like PKCS#5 >PBKDF2 before being used. (If it was, TLS-PSK would also have to >negotiate (or specify) the various parameters (like iteration >count) needed by PBKDF2 to get any interoperability. There was >at some point also discussion about using PKCS#5 PBKDF2 for all >keys; Hugo's mail in [8] also has parts related to this.) > > > It might be worthwhile to have a separate small informational RFC on this. Russ might find a taker :-). best regards, Lakshminath >Best regards, >Pasi > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 18 10:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNX0m-00024i-Vq; Mon, 18 Apr 2005 10:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNX0j-00024K-J1; Mon, 18 Apr 2005 10:14:02 -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 KAA22397; Mon, 18 Apr 2005 10:13:59 -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 1DNXBW-0000aI-8S; Mon, 18 Apr 2005 10:25:12 -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 j3IEDqN19790; Mon, 18 Apr 2005 17:13:52 +0300 (EET DST) X-Scanned: Mon, 18 Apr 2005 17:11:56 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j3IEBuaa009035; Mon, 18 Apr 2005 17:11:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00PoOtNb; Mon, 18 Apr 2005 17:11:55 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 j3IEBnM07516; Mon, 18 Apr 2005 17:11:49 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 18 Apr 2005 17:11:42 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 18 Apr 2005 17:11:41 +0300 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Last call comments about DTLS (mostly editorial) Date: Mon, 18 Apr 2005 17:11:41 +0300 Message-ID: Thread-Topic: [TLS] Last call comments about DTLS (mostly editorial) thread-index: AcUv4gLbPadZy+exT3O5wbQqpb3EyAUPMmLg To: X-OriginalArrivalTime: 18 Apr 2005 14:11:41.0843 (UTC) FILETIME=[8B682E30:01C54420] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, iesg@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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Eric, I went through draft-rescorla-dtls-04 to see how my comments=20 were addressed, and there were a couple of instances were the fixes were not quite complete... 2) "Cookie cookie<0..32>;" in Sections 4.2.1 and 4.3=20 should be "opaque cookie<0..32>;"=20 15) Section 4.2.6 says that "the initial ClientHello=20 and HelloVerifyRequest MUST BE included in the Finished MAC"=20 while Section 4.2.1 says that they're not. 16) The state machine still does not have any way to leave=20 the FINISHED state, meaning HelloRequest messages can't work. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 18 22:30:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNiV4-0001ih-Kb; Mon, 18 Apr 2005 22:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdOX-0005Gw-Sa for tls@megatron.ietf.org; Mon, 18 Apr 2005 17:03:01 -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 RAA11907 for ; Mon, 18 Apr 2005 17:02:59 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdZP-0003VB-GR for tls@ietf.org; Mon, 18 Apr 2005 17:14:16 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 18 Apr 2005 14:03:07 -0700 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 18 Apr 2005 14:03:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:03:30 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Apr 2005 14:02:46 -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] WGLC for draft-ietf-tls-ecc Date: Mon, 18 Apr 2005 14:02:47 -0700 Message-ID: Thread-Topic: [TLS] WGLC for draft-ietf-tls-ecc thread-index: AcU8pq3+PwfaFiuQRDOoIXG2RrgD0gHsr/GA From: "Ari Medvinsky" To: "Eric Rescorla" , X-OriginalArrivalTime: 18 Apr 2005 21:02:46.0218 (UTC) FILETIME=[F88522A0:01C54459] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Apr 2005 22:30:04 -0400 Cc: Joshua Ball , Jeff Spelman , Stefan Santesson , Cristian Ilac 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I have a couple of questions/comments on this draft: 1) The cipher suites defined in section 6 all use SHA1. Although from a security standpoint the use of SHA1 (or MD5 for that matter) is not subject to the vulnerabilities that were recently discovered with these hash functions - it would still be a good idea to define the new cipher suites to use SHA 256 or SHA 512 . For example, this would be useful for compliance reasons (to eliminate all reliance on MD5/SHA1). 2) Some additional verbiage/clarification is needed when using ECDH_ECDSA & ECDHE_ECDSA. For a client or server certificate chain (e.g., length of chain is greater than 2) - do all the certificates in the chain have to be based on ECDSA? Or are mixed crypto certs (signed with RSA) allowed higher up in the chain?=20 Ari Medvinsky Program Manager Windows Security -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Eric Rescorla Sent: Friday, April 08, 2005 6:56 PM To: tls@ietf.org Subject: [TLS] WGLC for draft-ietf-tls-ecc This is a Working Group Last Call for draft-ietf-tls-ecc-09.txt The target status for this document is Information. Please send comments to the mailing list as followups to this message. The Last Call will last for two weeks, ending on April 22. Note: I will be out of e-mail contact for 2 weeks starting April 20th, so in practice I won't be able to deal with comments before May 5th. -Ekr _______________________________________________ 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@lists.ietf.org Mon Apr 18 22:30:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNiV5-0001jD-1e; Mon, 18 Apr 2005 22:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdkv-0000KR-9H for tls@megatron.ietf.org; Mon, 18 Apr 2005 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 RAA14339 for ; Mon, 18 Apr 2005 17:26:07 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdvo-0004Ii-A7 for tls@ietf.org; Mon, 18 Apr 2005 17:37:24 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:26:10 -0700 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 18 Apr 2005 14:26:22 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:26:41 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Apr 2005 14:25:55 -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] WGLC for draft-ietf-tls-ecc Date: Mon, 18 Apr 2005 14:25:56 -0700 Message-ID: Thread-Topic: [TLS] WGLC for draft-ietf-tls-ecc thread-index: AcU8pq3+PwfaFiuQRDOoIXG2RrgD0gHtm8vA From: "Ari Medvinsky" To: X-OriginalArrivalTime: 18 Apr 2005 21:25:55.0433 (UTC) FILETIME=[348E8590:01C5445D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Apr 2005 22:30:04 -0400 Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I have a couple of questions/comments on this draft: 1) The cipher suites defined in section 6 all use SHA1. Although from a security standpoint the use of SHA1 (or MD5 for that matter) is not subject to the vulnerabilities that were recently discovered with these hash functions - it would still be a good idea to define the new cipher suites to use SHA 256 or SHA 512 . For example, this would be useful for compliance reasons (to eliminate all reliance on MD5/SHA1). 2) Some additional verbiage/clarification is needed when using ECDH_ECDSA & ECDHE_ECDSA. For a client or server certificate chain (e.g., length of chain is greater than 2) - do all the certificates in the chain have to be based on ECDSA? Or are mixed crypto certs (signed with RSA) allowed higher up in the chain?=20 Ari Medvinsky Program Manager Windows Security=20 -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Eric Rescorla Sent: Friday, April 08, 2005 6:56 PM To: tls@ietf.org Subject: [TLS] WGLC for draft-ietf-tls-ecc This is a Working Group Last Call for draft-ietf-tls-ecc-09.txt The target status for this document is Information. Please send comments to the mailing list as followups to this message. The Last Call will last for two weeks, ending on April 22. Note: I will be out of e-mail contact for 2 weeks starting April 20th, so in practice I won't be able to deal with comments before May 5th. -Ekr _______________________________________________ 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@lists.ietf.org Tue Apr 19 13:54:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNwve-0005HQ-5N; Tue, 19 Apr 2005 13:54:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNwvc-0005HK-6F for tls@megatron.ietf.org; Tue, 19 Apr 2005 13:54: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 NAA01792 for ; Tue, 19 Apr 2005 13:54:26 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNx6f-0007lE-Ih for tls@ietf.org; Tue, 19 Apr 2005 14:05:54 -0400 Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DNwvZ-00007y-00; Tue, 19 Apr 2005 19:54:25 +0200 Received: from [68.147.30.54] (helo=tau.local) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1DNwvY-0007Xl-00; Tue, 19 Apr 2005 19:54:24 +0200 Received: by tau.local (Postfix, from userid 500) id 2C1DE30CAB; Tue, 19 Apr 2005 11:53:37 -0600 (MDT) Date: Tue, 19 Apr 2005 11:53:37 -0600 From: Bodo Moeller To: Ari Medvinsky Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc Message-ID: <20050419175337.GA11974@tau.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Jeff Spelman , Stefan Santesson , tls@ietf.org, Joshua Ball , Cristian Ilac 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Mon, Apr 18, 2005 at 02:02:47PM -0700, Ari Medvinsky wrote: > 1) The cipher suites defined in section 6 all use SHA1. Although > from a security standpoint the use of SHA1 (or MD5 for that matter) is > not subject to the vulnerabilities that were recently discovered with > these hash functions - it would still be a good idea to define the new > cipher suites to use SHA 256 or SHA 512 . For example, this would be > useful for compliance reasons (to eliminate all reliance on MD5/SHA1). This is of course a valid concern. My reason for not adressing this in draft-ietf-tls-ecc-09.txt was that this issue applies to all TLS ciphersuites equally (the main TLS specification defines a few with MD5 and many with SHA; various ciphersuites defined elsewehere use SHA). Additionally there's SHA-1 and MD5 in the TLS PRF (pseudo-random function) used to derive keys from the handshake secrets, and we can't define this away in the TLS-ECC specification without violating the modularity of the TLS protocol design. So my preferred solution to these issues would be to have a future version of the TLS protocol (TLS 1.2, maybe?) specificy - a new PRF not based on MD5 and SHA-1, and - the use of a different MAC whenever ciphersuites that were originally defined for TLS 1.0 said "use SHA-1". Then the hash issues won't have to be adressed independently for each set of ciphersuites. This way, we avoid allocating a huge number of additional ciphersuite identifiers (which would happen if additional spefications are written to define a SHA-256 version of each ciphersuite originally defined with SHA-1). > 2) Some additional verbiage/clarification is needed when using > ECDH_ECDSA & ECDHE_ECDSA. For a client or server certificate chain > (e.g., length of chain is greater than 2) - do all the certificates in > the chain have to be based on ECDSA? Or are mixed crypto certs (signed > with RSA) allowed higher up in the chain? Here the rationale is based on the observation that the main TLS specification does go into this level of detail either: It only says that for the DH_DSS key exchange algorithm, the "algorithm used to sign the certificate MUST be DSS"; similar for DH_RSA, it "MUST be RSA". Presumably chains would usually be consistent in the choice of signature algorithms: i.e. either all RSA, all DSA ("DSS"), or all ECDSA, with only the end-entity certificate possibly deviating. Other chains are not forbidden by the respective specification, they would just be less useful in practice because they increase the risk that certificates would not be accepted. This is something that CAs can take into account in their signing practice. If they don't, this means that certain chains might not be accepted by certain parties (but non-acceptance is a problem must be expected all the time if a party does not like a CA's signing practice). (Also, the parties can work around the problem sometimes by relying not just on root CAs for trust, but directly on intermediate CAs: If Alice as a CA signs the certificate for another CA Bob and Bob signs the certificate for Carol, then another party Dave can verify Carol's certificate either by accepting Alice's certificate as trustworthy or by accepting Bob's certificate as trustworthy. In the latter case, it does not matter what signing algorithm Alice has used.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 19 18:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO10F-0005Xj-CL; Tue, 19 Apr 2005 18:15:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO10D-0005Xc-FD for tls@megatron.ietf.org; Tue, 19 Apr 2005 18:15:29 -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 SAA02189 for ; Tue, 19 Apr 2005 18:15:24 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO1BG-0001t3-B8 for tls@ietf.org; Tue, 19 Apr 2005 18:26:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 15:16:41 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 19 Apr 2005 15:16:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 19 Apr 2005 15:15:46 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Apr 2005 15:16:01 -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] WGLC for draft-ietf-tls-ecc Date: Tue, 19 Apr 2005 15:15:56 -0700 Message-ID: Thread-Topic: [TLS] WGLC for draft-ietf-tls-ecc thread-index: AcVFCTjs1XvmI4DBRdmvGiBzqeM1rQAIx9Vg From: "Ari Medvinsky" To: "Bodo Moeller" , X-OriginalArrivalTime: 19 Apr 2005 22:16:01.0285 (UTC) FILETIME=[5E98E350:01C5452D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: Jeff Spelman , Stefan Santesson , Joshua Ball , Cristian Ilac 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Bodo, 1) SHA1 issue: Since we are defining new cipher suites I don't think that it makes sense to say that we should not use a stronger hash function just because there are existing cipher suites that already use Sha1 or Md5. The PRF problem needs to be addressed separately and should not be gaiting factor. Moreover, even if we are to wait until TLS 1.2, the approach to simply use SHA-256 whenever SHA1 is specified will not work for backward compatibility reasons. 2) Chaining with certs using mixed crypto (ECC/RSA) issue: I agree with your comments. However, the current version of the draft leaves this issue ambiguous. All that is needed is a couple of additional sentences which state that mixed chains are permitted (or not permitted) - it just needs to be explicit.=20 Ari Medvinsky Program Manager=20 Windows Security -----Original Message----- From: Bodo Moeller [mailto:bmoeller@acm.org]=20 Sent: Tuesday, April 19, 2005 10:54 AM To: Ari Medvinsky Cc: Eric Rescorla; tls@ietf.org; Joshua Ball; Jeff Spelman; Stefan Santesson; Cristian Ilac Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc On Mon, Apr 18, 2005 at 02:02:47PM -0700, Ari Medvinsky wrote: > 1) The cipher suites defined in section 6 all use SHA1. Although > from a security standpoint the use of SHA1 (or MD5 for that matter) is > not subject to the vulnerabilities that were recently discovered with=20 > these hash functions - it would still be a good idea to define the new > cipher suites to use SHA 256 or SHA 512 . For example, this would be=20 > useful for compliance reasons (to eliminate all reliance on MD5/SHA1). This is of course a valid concern. My reason for not adressing this in draft-ietf-tls-ecc-09.txt was that this issue applies to all TLS ciphersuites equally (the main TLS specification defines a few with MD5 and many with SHA; various ciphersuites defined elsewehere use SHA). Additionally there's SHA-1 and MD5 in the TLS PRF (pseudo-random function) used to derive keys from the handshake secrets, and we can't define this away in the TLS-ECC specification without violating the modularity of the TLS protocol design. So my preferred solution to these issues would be to have a future version of the TLS protocol (TLS 1.2, maybe?) specificy - a new PRF not based on MD5 and SHA-1, and - the use of a different MAC whenever ciphersuites that were originally defined for TLS 1.0 said "use SHA-1". Then the hash issues won't have to be adressed independently for each set of ciphersuites. This way, we avoid allocating a huge number of additional ciphersuite identifiers (which would happen if additional spefications are written to define a SHA-256 version of each ciphersuite originally defined with SHA-1). > 2) Some additional verbiage/clarification is needed when using > ECDH_ECDSA & ECDHE_ECDSA. For a client or server certificate chain=20 > (e.g., length of chain is greater than 2) - do all the certificates in > the chain have to be based on ECDSA? Or are mixed crypto certs (signed > with RSA) allowed higher up in the chain? Here the rationale is based on the observation that the main TLS specification does go into this level of detail either: It only says that for the DH_DSS key exchange algorithm, the "algorithm used to sign the certificate MUST be DSS"; similar for DH_RSA, it "MUST be RSA". Presumably chains would usually be consistent in the choice of signature algorithms: i.e. either all RSA, all DSA ("DSS"), or all ECDSA, with only the end-entity certificate possibly deviating. Other chains are not forbidden by the respective specification, they would just be less useful in practice because they increase the risk that certificates would not be accepted. This is something that CAs can take into account in their signing practice. If they don't, this means that certain chains might not be accepted by certain parties (but non-acceptance is a problem must be expected all the time if a party does not like a CA's signing practice). (Also, the parties can work around the problem sometimes by relying not just on root CAs for trust, but directly on intermediate CAs: If Alice as a CA signs the certificate for another CA Bob and Bob signs the certificate for Carol, then another party Dave can verify Carol's certificate either by accepting Alice's certificate as trustworthy or by accepting Bob's certificate as trustworthy. In the latter case, it does not matter what signing algorithm Alice has used.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Apr 19 23:44:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO68f-0005zA-Aw; Tue, 19 Apr 2005 23:44:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO68e-0005yc-50 for tls@megatron.ietf.org; Tue, 19 Apr 2005 23:44: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 XAA22441 for ; Tue, 19 Apr 2005 23:44:28 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO6Jm-0002bY-OP for tls@ietf.org; Tue, 19 Apr 2005 23:56:03 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net[68.147.30.54] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1DO68X3SR6-0005N6; Wed, 20 Apr 2005 05:44:25 +0200 Received: by tau.local (Postfix, from userid 500) id 5EC5E30CAB; Tue, 19 Apr 2005 21:43:36 -0600 (MDT) Date: Tue, 19 Apr 2005 21:43:36 -0600 From: Bodo Moeller To: Ari Medvinsky Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc Message-ID: <20050420034336.GA31857@tau.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Jeff Spelman , Stefan Santesson , tls@ietf.org, Joshua Ball , Cristian Ilac 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Tue, Apr 19, 2005 at 03:15:56PM -0700, Ari Medvinsky wrote: > 1) SHA1 issue: > > Since we are defining new cipher suites I don't think that it makes > sense to say that we should not use a stronger hash function just > because there are existing cipher suites that already use Sha1 or Md5. Existing ciphersuites using SHA-1 surely don't *force* us to use SHA-1 for new ciphersuites. It's just that sticking to SHA-1 for now allows us to use a harmonized approach to solve the problem for many ciphersuites to minimize differences between ciphersuites. If it was already precisely certain how the existing TLS ciphersuites would be fixed, then we'd have an example to follow -- but I don't think this is quite clear yet: A straightforward approach would be to simply plug in SHA-256 instead of SHA-1, thus introducing larger MAC tags. A disadvantage is that SHA-256 is slower, and obviously that MAC tags would be longer. The latter problem can be lessened by using SHA-192 instead (so that MAC tags would be just four bytes longer than they are now), or by truncating the MAC even more. But in any case, the newer SHAs are slower than SHA-1. The future preferred MAC function for TLS might end up being something different from any SHA-{1,192,256,...} HMAC; so by using SHA-192 or SHA-256 now, we possibly will create more confusion between different ciphersuites and protocol versions in the future. > The PRF problem needs to be addressed separately and should not be > gaiting factor. Moreover, even if we are to wait until TLS 1.2, the > approach to simply use SHA-256 whenever SHA1 is specified will not work > for backward compatibility reasons. Backward compatibility would be no problem: Protocol version negotiation can decide which MAC to use, just like SSL 3.0 ciphersuites uses a slightly different MAC construction than the same ciphersuites in TLS 1.0. (This time, the difference would be more significant.) Those who want to totally avoid SHA-1 would have to insist on the appropriate minimum protocol version. > 2) Chaining with certs using mixed crypto (ECC/RSA) issue: > > I agree with your comments. However, the current version of the draft > leaves this issue ambiguous. All that is needed is a couple of > additional sentences which state that mixed chains are permitted (or not > permitted) - it just needs to be explicit. Agreed. The approach that seems to make most sense here is to come up with a wording that can be added similarly both to draft-ietf-tls-rfc2246-bis-09.txt and to draft-ietf-tls-ecc-09.txt. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Apr 20 00:15:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO6cz-0000xM-3P; Wed, 20 Apr 2005 00:15:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO6cx-0000wO-1e for tls@megatron.ietf.org; Wed, 20 Apr 2005 00:15:51 -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 AAA24401 for ; Wed, 20 Apr 2005 00:15:47 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO6o5-0003Xb-8F for tls@ietf.org; Wed, 20 Apr 2005 00:27:22 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 374FD170DF; Tue, 19 Apr 2005 21:23:22 -0700 (PDT) To: Bodo Moeller Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc References: <20050420034336.GA31857@tau.local> From: Eric Rescorla Date: Tue, 19 Apr 2005 21:23:22 -0700 In-Reply-To: <20050420034336.GA31857@tau.local> (Bodo Moeller's message of "Tue, 19 Apr 2005 21:43:36 -0600") Message-ID: <861x96rs91.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) 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: Ari Medvinsky , Jeff Spelman , Stefan Santesson , tls@ietf.org, Joshua Ball , Cristian Ilac 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Bodo Moeller writes: > On Tue, Apr 19, 2005 at 03:15:56PM -0700, Ari Medvinsky wrote: > >> 1) SHA1 issue: >> >> Since we are defining new cipher suites I don't think that it makes >> sense to say that we should not use a stronger hash function just >> because there are existing cipher suites that already use Sha1 or Md5. > > Existing ciphersuites using SHA-1 surely don't *force* us to use SHA-1 > for new ciphersuites. It's just that sticking to SHA-1 for now allows > us to use a harmonized approach to solve the problem for many > ciphersuites to minimize differences between ciphersuites. Indeed. And given that there's as yet no evidence that the current problems with SHA-1 impact HMAC, I don't think it's really supercritical to rush this transition. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Apr 20 05:39:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOBg1-00047c-G9; Wed, 20 Apr 2005 05:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOBft-00046g-Ek for tls@megatron.ietf.org; Wed, 20 Apr 2005 05:39: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 FAA20186 for ; Wed, 20 Apr 2005 05:39:07 -0400 (EDT) Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOBr1-00049i-Ik for tls@ietf.org; Wed, 20 Apr 2005 05:50:44 -0400 Received: (qmail invoked by alias); 20 Apr 2005 09:38:57 -0000 Received: from c201039.adsl.hansenet.de (EHLO [213.39.201.39]) [213.39.201.39] by mail.gmx.net (mp020) with SMTP; 20 Apr 2005 11:38:57 +0200 X-Authenticated: #25888033 Message-ID: <42662407.6020608@gmx.net> Date: Wed, 20 Apr 2005 11:42:31 +0200 From: Nils Larsch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc References: <20050409022121.2C73D284CC@sierra.rtfm.com> <425D5F90.7030003@gmx.net> <20050413211023.GA14810@tau.local> In-Reply-To: <20050413211023.GA14810@tau.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 2.9 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: ... > The practical value surely is very limited; support for hybrid format > is mostly for completeness, given existing standards that allow it. with the same reasoning one could include curves with normal basis, but I guess no one really wants this > (If someone has an ECC certificate that happens to use hybrid format, > this allows them to use it for TLS.) These are small advantages, but > then this is a simple thing to add to the protocol -- support for the > hybrid format is completely optional, after all. I would prefer not to include this point format unless there a real use case for it (something I doubt) >>> A client that prefers the use of the ansiX962_compressed format over >>> uncompressed may indicate that preference by including an extension >>> consisting of the following octets: >>> >>> 00 ?? 00 03 02 01 00 > > >>this is somewhat problematic: for example openssl (0.9.8-dev) should >>support every of the above mentioned named curves and it can handle >>compressed points for GF(p) as well (as the point compression algorithm >>for characteristic 2 is patented point compression for GF(2^m) curves is >>disabled by default in openssl). But there's no way in express this using >>the above extensions: one can either list every supported curve and offer >>no point compression or restrict the list of curves to "prime"-curves and >>offer point compression. > > > Yes, I am aware of this restriction. My reason for keeping the > ECPointFormat type as above was that generally the default format, > uncompressed, is a very good choice anyway (it means just a few more > bytes and its use can usually save some computation time), and that > the restriction keeps the protocol a little simpler and the TLS > extensions a little shorter. yep, but the price for this is that point compression is nearly useless for open source software > Point formats other than uncompressed are most likely to be of use in > closed environments, e.g. to accommodate specific certificates. In I doubt that extensions are necessary in this case at all (as all parameters, like point compression, are fixed) ... > Now obviously this is just one way to view it. Would you prefer > to have more fine-grained ECPointFormat values, such as > > uncompressed, > ansiX962_compressed_prime, > anxiX962_compressed_char2, > ansiX962_hybrid_prime, > ansiX962_hybrid_char2 > > ? This would't be too complicated either. And, possibly more > importantly, this set of possibilities would be easier to explain :-) > > If this is preferred, I wouldn't mind changing the specification > accordingly. I would prefer the more fine grained point compression values >>>5.3 Server Certificate > > >>> The server constructs an appropriate certificate chain and conveys it >>> to the client in the Certificate message. If the client has used a >>> Supported Elliptic Curves Extension, the public key in the server's >>> certificate MUST respect the client's choice of elliptic curves; in >>> particular, the public key MUST employ a named curve (not the same >>> curve as an explicit curve) unless the client has indicated support >>> for explicit curves of the appropriate type. If the client has used >>> a Supported Point Formats Extension, both the server's public key >>> point and (in the case of an explicit curve) the curve's base point > > >>every ec point appearing in the cert chain must adhere to the supported >>point format and not only the public key and the generator of the server >>certificate (otherwise the client might be unable to verify the cert chain). > > > I am aware of the possible certificate chain verification problem. > The specification is meant to guarantee that the key exchange can > proceed without problems, but not necessarily that certificate > verification is always possible. if the cert verification fails a successful key exchange isn't that useful > Keep in mind that certificate > verification can fail due to other reasons, notably due to an unknown > root CA, or various features present in X.509 certificates (such as > unknown extensions that are tagged critical). We cannot avoid all of > these problems in general. of course not, but if the client/server explicitly states that it can handle only certain point compression format wouldn't it make sense to use this information for the cert validation as well ? Nils _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Apr 20 10:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGZg-0002Np-9v; Wed, 20 Apr 2005 10:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOGZe-0002NL-Do for tls@megatron.ietf.org; Wed, 20 Apr 2005 10:53: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 KAA16579 for ; Wed, 20 Apr 2005 10:53:04 -0400 (EDT) Received: from saria.randombit.net ([66.179.181.167] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOGkq-0005JY-Cn for tls@ietf.org; Wed, 20 Apr 2005 11:04:43 -0400 Received: by mail.randombit.net (Postfix, from userid 501) id E2175247C03A; Wed, 20 Apr 2005 08:53:00 -0600 (MDT) Date: Wed, 20 Apr 2005 08:53:00 -0600 From: Jack Lloyd To: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc Message-ID: <20050420145300.GC12131@randombit.net> Mail-Followup-To: tls@ietf.org References: <20050420034336.GA31857@tau.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420034336.GA31857@tau.local> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Tue, Apr 19, 2005 at 09:43:36PM -0600, Bodo Moeller wrote: > Backward compatibility would be no problem: Protocol version > negotiation can decide which MAC to use, just like SSL 3.0 > ciphersuites uses a slightly different MAC construction than the same > ciphersuites in TLS 1.0. (This time, the difference would be more > significant.) Those who want to totally avoid SHA-1 would have to > insist on the appropriate minimum protocol version. But if I feel that SHA-1 is fine with HMAC (which I do given the current results), and don't want the space and computational overhead of something like SHA-256 (I don't think it actually matters that much but some people seem to), I'm stuck using an older protocol version forever. We already have a mechanism which allows the two parties to negotiate which algorithms they would prefer to use, why not use that instead of overloading the protocol version when it's not necessary? If the ciphersuite system is really so broken that it's such a burden to add a set of 10-15 new ciphersuites which use SHA-256 for the HMAC, I think that is something which should be examined. -Jack _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Apr 20 16:18:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLe9-000513-B1; Wed, 20 Apr 2005 16:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLe7-00050b-GO for tls@megatron.ietf.org; Wed, 20 Apr 2005 16:18:03 -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 QAA14865 for ; Wed, 20 Apr 2005 16:18:01 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOLpN-00074b-9k for tls@ietf.org; Wed, 20 Apr 2005 16:29:43 -0400 Received: from dhcp238.math.ucalgary.ca[136.159.61.238] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1DOLdz1svv-00033f; Wed, 20 Apr 2005 22:17:55 +0200 Received: by tau.local (Postfix, from userid 500) id E554831A13; Wed, 20 Apr 2005 14:17:19 -0600 (MDT) Date: Wed, 20 Apr 2005 14:17:19 -0600 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc Message-ID: <20050420201719.GA2385@tau.local> References: <20050420034336.GA31857@tau.local> <20050420145300.GC12131@randombit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050420145300.GC12131@randombit.net> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 2.0 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Wed, Apr 20, 2005 at 08:53:00AM -0600, Jack Lloyd wrote: > On Tue, Apr 19, 2005 at 09:43:36PM -0600, Bodo Moeller wrote: >> Backward compatibility would be no problem: Protocol version >> negotiation can decide which MAC to use, just like SSL 3.0 >> ciphersuites uses a slightly different MAC construction than the same >> ciphersuites in TLS 1.0. (This time, the difference would be more >> significant.) Those who want to totally avoid SHA-1 would have to >> insist on the appropriate minimum protocol version. > But if I feel that SHA-1 is fine with HMAC (which I do given the current > results), and don't want the space and computational overhead of something like > SHA-256 (I don't think it actually matters that much but some people seem to), > I'm stuck using an older protocol version forever. Only if the future protocol version really switches to SHA-256. I did not mean to imply that this is what will definitely happen. Future TLS versions may use an entirely different, and possibly much more efficient, technique for message authentication (such as something based on universal hashing). > We already have a mechanism > which allows the two parties to negotiate which algorithms they would prefer to > use, why not use that instead of overloading the protocol version when it's not > necessary? If the ciphersuite system is really so broken that it's such a > burden to add a set of 10-15 new ciphersuites which use SHA-256 for the HMAC, I > think that is something which should be examined. An alternative to using the protocol version or the ciphersuite would be a new TLS extension for hash algorithm negotiation. And of course, defining new versions of the existing ciphersuites still remains a possibility if this is deemed advantageous. There are many options for how to proceed, and as we don't have to rush away from SHA-1 HMAC, it's really above all about keeping the options open for now. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Apr 20 16:42:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOM1O-0000Y4-MM; Wed, 20 Apr 2005 16:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOM1L-0000XX-Ik for tls@megatron.ietf.org; Wed, 20 Apr 2005 16:42:03 -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 QAA17889 for ; Wed, 20 Apr 2005 16:42:00 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOMCc-0007sw-C7 for tls@ietf.org; Wed, 20 Apr 2005 16:53:42 -0400 Received: from dhcp238.math.ucalgary.ca[136.159.61.238] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1DOM1E43cb-00015H; Wed, 20 Apr 2005 22:41:56 +0200 Received: by tau.local (Postfix, from userid 500) id 6E34D31A13; Wed, 20 Apr 2005 14:41:31 -0600 (MDT) Date: Wed, 20 Apr 2005 14:41:31 -0600 From: Bodo Moeller To: Nils Larsch Subject: Re: [TLS] WGLC for draft-ietf-tls-ecc Message-ID: <20050420204131.GB2385@tau.local> References: <20050409022121.2C73D284CC@sierra.rtfm.com> <425D5F90.7030003@gmx.net> <20050413211023.GA14810@tau.local> <42662407.6020608@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42662407.6020608@gmx.net> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Wed, Apr 20, 2005 at 11:42:31AM +0200, Nils Larsch wrote: > Bodo Moeller wrote: >> The practical value surely is very limited; support for hybrid format >> is mostly for completeness, given existing standards that allow it. > with the same reasoning one could include curves with normal basis, > but I guess no one really wants this The difference is that normal basis representations would require additional type specifications and explanations in the ECC-TLS specification. For hybrid format, it's just about saying how parties can negotiate this format if they want; so the additional complexity to the specification is marginal, given that the actual point format is defined elsewhere. (And hybrid format is purely optional, so the additional effort for implementors is marginal too.) What do others think on this? >>>> A client that prefers the use of the ansiX962_compressed format over >>>> uncompressed may indicate that preference by including an extension >>>> consisting of the following octets: >>>> >>>> 00 ?? 00 03 02 01 00 >>> this is somewhat problematic: for example openssl (0.9.8-dev) should >>> support every of the above mentioned named curves and it can handle >>> compressed points for GF(p) as well (as the point compression algorithm >>> for characteristic 2 is patented point compression for GF(2^m) curves is >>> disabled by default in openssl). But there's no way in express this using >>> the above extensions: one can either list every supported curve and offer >>> no point compression or restrict the list of curves to "prime"-curves and >>> offer point compression. >> Yes, I am aware of this restriction. My reason for keeping the >> ECPointFormat type as above was that generally the default format, >> uncompressed, is a very good choice anyway (it means just a few more >> bytes and its use can usually save some computation time), and that >> the restriction keeps the protocol a little simpler and the TLS >> extensions a little shorter. > yep, but the price for this is that point compression is nearly > useless for open source software But would you actually want to *use* point compression in the handshake, or would you use the uncompressed format as the preferred option anyway? I can see some scenarios where this complication could become a problem: A client supporting both prime fields and characteristic-2 fields talks to a server using an ECC certificate involving a prime field, with a point given in compressed coordinates. If the client supports point compression only for prime fields, it cannot let the server know that it does support point compression at all (because the current extension would also imply point compression support for characteristic-2 curves). So no ECC handshake would be possible. Hopefully, such scenarios wouldn't really occur in practice (why use a server certificate with point compression in the first place?). But adapting the protocol to this possibility may still be a good idea. >> Point formats other than uncompressed are most likely to be of use in >> closed environments, e.g. to accommodate specific certificates. In > I doubt that extensions are necessary in this case at all (as all > parameters, like point compression, are fixed) For such scenarios, the extensions would be used to find out that the current handshake is indeed taking place between parties that conform to the agreement from the close group. (The same client may also connect to outside servers, switching to RSA if necessary; or a server may also have connections from outside clients.) But it is certainly true that more fine-grained ECPointFormat values could be useful for such connections as well: >> uncompressed, >> ansiX962_compressed_prime, >> anxiX962_compressed_char2, >> ansiX962_hybrid_prime, >> ansiX962_hybrid_char2 >> >> ? This would't be too complicated either. And, possibly more >> importantly, this set of possibilities would be easier to explain :-) >> >> If this is preferred, I wouldn't mind changing the specification >> accordingly. > I would prefer the more fine grained point compression values OK. Does anyone else have an opinion on this? >>>> 5.3 Server Certificate >> I am aware of the possible certificate chain verification problem. >> The specification is meant to guarantee that the key exchange can >> proceed without problems, but not necessarily that certificate >> verification is always possible. > if the cert verification fails a successful key exchange isn't that > useful This depends. Sometimes verification is just about granting additional rights: If authentication fails, the other party can still get some business done, just with limitations. (E.g., SMTP servers will accept mail to local recipients from any sender; only mail relaying requires successful authentication.) >> Keep in mind that certificate >> verification can fail due to other reasons, notably due to an unknown >> root CA, or various features present in X.509 certificates (such as >> unknown extensions that are tagged critical). We cannot avoid all of >> these problems in general. > of course not, but if the client/server explicitly states that it > can handle only certain point compression format wouldn't it make > sense to use this information for the cert validation as well ? If the other party has options in building the certificate chain, then nothing in the specification prevents it from using this information. But if it does not have such options, then sending a chain where the root CA certificate or an intermediate CA certificate violates the constraints does not main that verification is doomed to fail! The verifying party will not be able to use these particular certificates for verification, due to its limitations. However, it is possible that the verifying party directly trusts a non-root CA occuring in the chain and thus does not have to bother to even look at the problematic root and intermediate CA certificates. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Apr 27 09:54:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQn09-0002ZR-9E; Wed, 27 Apr 2005 09:54:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQn04-0002Yp-Kb; Wed, 27 Apr 2005 09:54:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12254; Wed, 27 Apr 2005 09:54:46 -0400 (EDT) Message-Id: <200504271354.JAA12254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 27 Apr 2005 09:54:46 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-08.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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s) : P. Eronen, H. Tschofenig Filename : draft-ietf-tls-psk-08.txt Pages : 18 Date : 2005-4-26 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-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-psk-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-psk-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-27102816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-27102816.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Thu Apr 28 17:04:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRGBi-0004GG-Vk; Thu, 28 Apr 2005 17:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRGBg-0004G8-Hg for tls@megatron.ietf.org; Thu, 28 Apr 2005 17:04:44 -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 RAA24844 for ; Thu, 28 Apr 2005 17:04:42 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRGOb-00056I-2Z for tls@ietf.org; Thu, 28 Apr 2005 17:18:06 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j3SL4bCw021873 for ; Thu, 28 Apr 2005 23:04:37 +0200 Received: from pappel.asw.mchp.siemens.de ([139.25.160.30]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j3SL4RKT010223 for ; Thu, 28 Apr 2005 23:04:31 +0200 Received: by pappel.asw.mchp.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Apr 2005 23:04:27 +0200 Message-ID: From: "Franke, Markus" To: "TLS IETF (tls@ietf.org)" Date: Thu, 28 Apr 2005 19:54:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [TLS] Some questions regarding PSK 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi all. I have following questions regarding the PSK ciphersuites: 1. In chapter 3 is stated "the ServerKeyExchange message is always sent even if no PSK identity hint is provided". But how to not provide a identity hint? - Is it then empty (length = 00 00)? If so, what is then the difference between an empty identity hint in pure PSK ciphersuites? - Or is it an optional field? Then it may be better to flip the order of the fields psk_identity_hint and public. 2. The ServerKeyExchange message in RSA_PSK is - in opposite to EXPORT_RSA or DHE_RSA cipheruistes - not signed by the server's private key corresponding to the server certificate? Why? - For performance reasons on client side (no signature validation)? - Or because it is not considered to be necessary since proof-of-private-key-possession is done by successfully decrypting the pre_master_secret? - Or to prevent a RSA certificate that is to be used for signature and encryption at the same time? Maybe it's worth to spend some words on that. 3. Maybe it should be explicitly mentioned that for RSA_PSK ciphersuites the keyEncipherment bit has to be set (see chapter "7.4.2. Server certificate" in RFC 2246). Regards, Markus _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Apr 28 23:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMWK-0006pu-5l; Thu, 28 Apr 2005 23:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRMWH-0006pp-T8 for tls@megatron.ietf.org; Thu, 28 Apr 2005 23:50: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 XAA25277 for ; Thu, 28 Apr 2005 23:50:20 -0400 (EDT) Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRMjD-00052M-Pm for tls@ietf.org; Fri, 29 Apr 2005 00:03:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id C56B134783; Fri, 29 Apr 2005 15:50:10 +1200 (NZST) 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 10127-10; Fri, 29 Apr 2005 15:50:10 +1200 (NZST) 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 829703472D; Fri, 29 Apr 2005 15:50:05 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 21B8B3775B; Fri, 29 Apr 2005 15:50:05 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DRMW1-0005Po-00; Fri, 29 Apr 2005 15:50:09 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: markus.franke@siemens.com, tls@ietf.org Subject: Re: [TLS] Some questions regarding PSK In-Reply-To: Message-Id: Date: Fri, 29 Apr 2005 15:50:09 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org "Franke, Markus" writes: >1. In chapter 3 is stated "the ServerKeyExchange message is always >sent even if no PSK identity hint is provided". But how to not provide >a identity hint? I'd already complained about this weird requirement some time ago ("a message whose only purpose is to indicate that the page is intentionally left blank"), I thought this was fixed in more recent drafts but it seems like it's still there. The same with the other comments, a few months after the above I sent another comment: I have no idea what an "identity hint" could possibly be (the spec says it's optional, but I'd have no idea what to put in there in any case). If the field is used for something, what's it supposed to be used for? If not, perhaps it should be dropped. (Hmm, and I'll repeat my earlier gripe that apart from its use to convey this unknown quantity, there's no need to send the server keyex at all. In other words in 99.99% of cases it's just going to be code and message bloat). Can we finally get this fixed, or how many more times does it have to be brought up as a problem with the spec? The solution is to make the ServerKeyExchange optional (it's not needed in 99.99% of cases), and explain what the identity hint is and how it's used. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Apr 29 03:51:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQHW-0003ax-2q; Fri, 29 Apr 2005 03:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQHT-0003ap-AE for tls@megatron.ietf.org; Fri, 29 Apr 2005 03:51: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 DAA01586 for ; Fri, 29 Apr 2005 03:51:21 -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 1DRQUU-0006Fn-OH for tls@ietf.org; Fri, 29 Apr 2005 04:04: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 j3T7pAQ19190; Fri, 29 Apr 2005 10:51:10 +0300 (EET DST) X-Scanned: Fri, 29 Apr 2005 10:50:31 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j3T7oVRj012093; Fri, 29 Apr 2005 10:50:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00QpjwPN; Fri, 29 Apr 2005 10:49:47 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3T7nbd17847; Fri, 29 Apr 2005 10:49:37 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Apr 2005 10:49:31 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Apr 2005 10:49:31 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 10:49:31 +0300 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Some questions regarding PSK Date: Fri, 29 Apr 2005 10:49:30 +0300 Message-ID: Thread-Topic: [TLS] Some questions regarding PSK thread-index: AcVMNxLLSSw8paD3TlCxnlm9E4xUNAAVxLFQ To: , X-OriginalArrivalTime: 29 Apr 2005 07:49:31.0306 (UTC) FILETIME=[FA4928A0:01C54C8F] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Franke, Markus wrote: >=20 > Hi all. >=20 > I have following questions regarding the PSK ciphersuites: >=20 > 1. In chapter 3 is stated "the ServerKeyExchange message is=20 > always sent even if no PSK identity hint is provided". But=20 > how to not provide a identity hint?=20 > - Is it then empty (length =3D 00 00)? If so, what is then=20 > the difference between an empty identity hint in pure PSK=20 > ciphersuites? > - Or is it an optional field? Then it may be better to flip=20 > the order of the fields psk_identity_hint and public. The field is defined as "opaque psk_identity<0..2^16-1>;" so it's not optional. If there's no hint, it's left empty (length 0). (And yes, this means that application profile specs (see Section 5.2) can't realistically treat "no hint" and "zero-length hint" differently.) > 2. The ServerKeyExchange message in RSA_PSK is - in opposite=20 > to EXPORT_RSA or DHE_RSA cipheruistes - not signed by the server's=20 > private key corresponding to the server certificate? Why?=20 > - For performance reasons on client side (no signature validation)? > - Or because it is not considered to be necessary since=20 > proof-of-private-key-possession is done by successfully=20 > decrypting the pre_master_secret? > - Or to prevent a RSA certificate that is to be used for signature > and encryption at the same time? > Maybe it's worth to spend some words on that. RSA_PSK is based on the ordinary RSA ciphersuites that don't sign anything either: they're based on RSA encryption, not signatures. (And all the handshake messages are MAC'd in the Finished messages later). > 3. Maybe it should be explicitly mentioned that for RSA_PSK=20 > ciphersuites the keyEncipherment bit has to be set (see chapter=20 > "7.4.2. Server certificate" in RFC 2246). Ok, if we make another revision of the spec, we can mention this explicitly. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Apr 29 04:01:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQRU-0005v7-TA; Fri, 29 Apr 2005 04:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQRS-0005uz-JE for tls@megatron.ietf.org; Fri, 29 Apr 2005 04:01:43 -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 EAA02182 for ; Fri, 29 Apr 2005 04:01:40 -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 1DRQeT-0006eI-0K for tls@ietf.org; Fri, 29 Apr 2005 04:15:10 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3T81UM11217; Fri, 29 Apr 2005 11:01:31 +0300 (EET DST) X-Scanned: Fri, 29 Apr 2005 11:00:44 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j3T80iPe012694; Fri, 29 Apr 2005 11:00:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mHTZFD; Fri, 29 Apr 2005 10:57:31 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3T7aeM00757; Fri, 29 Apr 2005 10:36:40 +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); Fri, 29 Apr 2005 10:35:24 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Apr 2005 10:35:23 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Apr 2005 10:35:23 +0300 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Some questions regarding PSK Date: Fri, 29 Apr 2005 10:35:19 +0300 Message-ID: Thread-Topic: [TLS] Some questions regarding PSK thread-index: AcVMb0Ag6o3w8bynQ8yMNyrf5PQdXAAHbeGA To: , X-OriginalArrivalTime: 29 Apr 2005 07:35:23.0598 (UTC) FILETIME=[01032EE0:01C54C8E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Peter, Your complaint about ServerKeyExchange being sent even when it doesn't contain anything useful was already fixed in version -05 more than four months ago: Section 2 says that "If no hint is=20 provided, the ServerKeyExchange message is omitted." Markus's comment was about Section 3 (DHE_PSK), where we cannot omit the whole ServerKeyExchange message because it contains more than just the hint (server DH parameters). Newer versions also clarify what to do with the identity hint; see Section 5.2 in -08 version. Best regards, Pasi > -----Original Message----- > From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org]On > Behalf Of ext Peter Gutmann > Sent: Friday, April 29, 2005 6:50 AM > To: markus.franke@siemens.com; tls@ietf.org > Subject: Re: [TLS] Some questions regarding PSK >=20 >=20 > "Franke, Markus" writes: >=20 > > 1. In chapter 3 is stated "the ServerKeyExchange message is always > > sent even if no PSK identity hint is provided". But how to=20 > > not provide a identity hint? >=20 > I'd already complained about this weird requirement some time ago=20 > ("a message whose only purpose is to indicate that the page is=20 > intentionally left blank"), I thought this was fixed in more=20 > recent drafts but it seems like it's still there. The same with=20 > the other comments, a few months after the above I sent another=20 > comment: >=20 > I have no idea what an "identity hint" could possibly be=20 > (the spec says it's optional, but I'd have no idea what to=20 > put in there in any case). If the field is used for something,=20 > what's it supposed to be used for? If not, perhaps it should=20 > be dropped. >=20 > (Hmm, and I'll repeat my earlier gripe that apart from its=20 > use to convey this unknown quantity, there's no need to send=20 > the server keyex at all. In other words in 99.99% of cases=20 > it's just going to be code and message bloat). >=20 > Can we finally get this fixed, or how many more times does it=20 > have to be brought up as a problem with the spec? The solution=20 > is to make the ServerKeyExchange optional (it's not needed in=20 > 99.99% of cases), and explain what the identity hint is and=20 > how it's used. >=20 > Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Apr 29 04:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQcg-0008WQ-9b; Fri, 29 Apr 2005 04:13:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRQce-0008WD-76 for tls@megatron.ietf.org; Fri, 29 Apr 2005 04:13: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 EAA02923 for ; Fri, 29 Apr 2005 04:13:14 -0400 (EDT) Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRQpc-000780-Th for tls@ietf.org; Fri, 29 Apr 2005 04:26:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 7F3A03480B; Fri, 29 Apr 2005 20:13:08 +1200 (NZST) 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 04889-26; Fri, 29 Apr 2005 20:13:08 +1200 (NZST) 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 1B4C934597; Fri, 29 Apr 2005 20:13:08 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 16F2337744; Fri, 29 Apr 2005 20:13:08 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DRQcc-0005cV-00; Fri, 29 Apr 2005 20:13:14 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, pgut001@cs.auckland.ac.nz, tls@ietf.org Subject: RE: [TLS] Some questions regarding PSK In-Reply-To: Message-Id: Date: Fri, 29 Apr 2005 20:13:14 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com writes: >Your complaint about ServerKeyExchange being sent even when it >doesn't contain anything useful was already fixed in version -05 >more than four months ago: Section 2 says that "If no hint is >provided, the ServerKeyExchange message is omitted." Oh, sorry about that, from the message it had looked as if it was the same old thing coming up again. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls