From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 07:18:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00587 for ; Mon, 2 Apr 2001 07:18:36 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ecc-01.txt Date: Mon, 02 Apr 2001 07:17:54 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200104021117.HAA00496@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECC Cipher Suites For TLS Author(s) : S. Blake-Wilson, T. Dierks, C. Hawk Filename : draft-ietf-tls-ecc-01.txt Pages : 22 Date : 30-Mar-01 This document describes additions to TLS to support Elliptic Curve Cryptography (ECC). In particular it defines new key exchange algorithms which use the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme (ECDH), and it defines how to perform client authentication with ECDSA and ECDH. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010330140024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330140024.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 10:23:08 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11448 for ; Mon, 2 Apr 2001 10:23:07 -0400 (EDT) X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to moeller@cdc.informatik.tu-darmstadt.de using -f Date: Mon, 2 Apr 2001 16:22:33 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from Internet-Drafts@ietf.org on Mon, Apr 02, 2001 at 07:17:54AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010402162233.D2087@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Apr 02, 2001 at 07:17:54AM -0400, Internet-Drafts@ietf.org wrote: > Title : ECC Cipher Suites For TLS > Author(s) : S. Blake-Wilson, T. Dierks, C. Hawk > Filename : draft-ietf-tls-ecc-01.txt > Pages : 22 > Date : 30-Mar-01 > http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-01.txt Before looking at several details, let me note that the following complaint about draft-ietf-tls-ecc-00.txt (March 1998) still applies: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Date: Mon, 19 Mar 2001 14:39:49 +0100 From: Bodo Moeller To: IETF Transport Layer Security WG Subject: Re: [ietf-tls] Re: I-D cipher suite numbers Message-ID: <20010319143949.A11640@cdc.informatik.tu-darmstadt.de> Lines: 207 [...] If a client announces in its ClientHello message that it supports one particular ciphersuite of those defined in draft-ietf-tls-ecc-00.txt (TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, say), then with the draft as it is now the client must be prepared to be faced with curve definitions over any of GF(p) or GF(2^m) with ONBs or GF(2^m) with 'trinomial' basis representation or GF(2^m) with 'pentanomial' basis representation. The server can do with implementing just one of these -- after all, it is the server that gets to choose the curve --, but the client must be able to handle all of these to ensure interoperability. There is no way for the client to say 'I can do ECDH_ECDSA, but only with curves over GF(p)' or 'only using normal bases', and this makes draft-ietf-tls-ecc-00.txt pretty useless for weak clients. [...] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (For ideas on what to do about this, see that message.) < 2. Elliptic Curve Key Exchange Algorithms < Key < Exchange < Algorithm Description Key size limit < < ECDH_ECDSA ECDH with ECDSA signatures None < ECDH_ECDSA_EXPORT ECDH with ECDSA signatures ECDH=163 bits, < ECDSA=none < ECDH_RSA ECDH with RSA signatures None < ECDH_RSA_EXPORT ECDH with RSA signatures ECDH=163 bits, < RSA = none < ECDH_anon Anonymous ECDH, no signatures None < ECDH_anon_EXPORT Anonymous ECDH, no signatures ECDH=163 bits < < Table 2: Key exchange algorithms None of the new key exchange methods provides both forward secrecy and authentication. The new draft uses ephemeral ECDH only for anonymous ciphersuites; otherwise, the server's DH share must be in its certificate. Forward secrecy is a desireable property (and comes at almost no additional cost for clients when RSA signatures are used since RSA signature verification is very fast), so there really should be ECDHE_ECDSA and ECDHE_RSA ciphersuites. Defining ECDHE_RSA ciphersuites has the additional practical advantage that many servers already have RSA certificates; i.e., they could start to use ECC ciphersuites without having to obtain additional certificates. < 4.2. Server Key Exchange < struct { < opaque point <1..2^8-1>; < } ECPoint; < < point < This is the byte string representation of an elliptic curve point < following the conversion routine in [X9.62], section 4.3.6. Use of the definite article suggests that there is a single byte string representation for a given elliptic curve point. This is not the case; there are three forms to choose from (compressed, uncompressed, and hybrid). The specification should clarify which forms may be used (all three of them?) and possibly which one is recommended (uncompressed?). < 4.1. Server Certificate < [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in < X.509 certificates. Servers SHOULD use the elliptic curve domain < parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 < [FIPS186-2], and SEC 2 [SEC2]. [...] < 4.4. Client Certificate < [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in < X.509 certificates. Clients SHOULD use the elliptic curve domain < parameters recommended in ANSI X9.62 [ANSIX962], FIPS 186-2 < [FIPS186-2], and SEC 2 [SEC2]. [...] Readers might think that these "SHOULD"s apply to those curves that are present in *all* of these specifications, whereas the intended meaning presumably is that any curve recommended by any one of them is OK. If it is in the scope of the ECC-TLS specification to recommend particular curves for public keys in X.509 certificates, then the specification probably should also explicitly recommend the use of a "namedCurve" (where available) rather then explicit "ecParameters" in certificates for ECC keys. Thus the above portions might be changed as follows: [PKIX-ALG] specifies how ECC keys and ECDSA signatures are placed in X.509 certificates. Servers SHOULD use elliptic curve domain parameters recommended in at least one of ANSI X9.62 [ANSIX962], FIPS 186-2 [FIPS186-2], and SEC 2 [SEC2]. If elliptic curve domain parameters are used for which a "named curve" definition exists in ANSI X9.62 [ANSIX962] or SEC 2 [SEC2], then these parameters SHOULD not be included explicitly. [...] (Accordingly for clients.) < 4.2. Server Key Exchange < enum { explicit_prime (1), explicit_char2 (2), < named_curve (3), (255) } ECCurveType; [...] < named_curve < Indicates that a named curve will be used. The use of this option is < strongly recommended. Why not use the RFC 2119 keyword "SHOULD" here as well? < 4.5. Client Key Exchange < enum { yes, no } EphemeralPublicKey; This should be enum { yes(0), no(1) } EphemeralPublicKey; (or rather "no(0), yes(1)", which appears more natural). The RFC 2246 syntax requires explicit numbering. (Exception: "For enumerateds that are never converted to external representation, the numerical information may be omitted." Obviously this does not apply here.) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 10:29:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11925 for ; Mon, 2 Apr 2001 10:29:46 -0400 (EDT) X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to moeller@cdc.informatik.tu-darmstadt.de using -f Date: Mon, 2 Apr 2001 16:29:34 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from moeller@cdc.informatik.tu-darmstadt.de on Mon, Apr 02, 2001 at 04:22:33PM +0200 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010402162934.F2087@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Apr 02, 2001 at 04:22:33PM +0200, Bodo Moeller wrote: > Before looking at several details, let me note that the following > complaint about draft-ietf-tls-ecc-00.txt (March 1998) still applies: [...] Not literally, of course -- there are no ONBs on draft-ietf-tls-ecc-01.txt, and the example ciphersuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA does not exist in the current draft. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 10:37:50 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12316 for ; Mon, 2 Apr 2001 10:37:47 -0400 (EDT) Message-ID: From: Mark Winstead To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-ecc-01.txt Date: Mon, 2 Apr 2001 10:06:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <49B96FCC784BC54F9675A6B558C3464E17CE91@MAIL.netoctave.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net There is a small error in this document. There is a bibliography reference on page 3 to [LEN], but there is no [LEN] in the bibliography. Of course, I reserve the right to make more comments later :) Mark Winstead (Insert job title here) NetOctave, Inc RTP, NC www.netoctave.com mark.winstead@netoctave.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, April 02, 2001 7:18 AM To: IETF Transport Layer Security WG Cc: ietf-tls@lists.certicom.com Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ecc-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECC Cipher Suites For TLS Author(s) : S. Blake-Wilson, T. Dierks, C. Hawk Filename : draft-ietf-tls-ecc-01.txt Pages : 22 Date : 30-Mar-01 This document describes additions to TLS to support Elliptic Curve Cryptography (ECC). In particular it defines new key exchange algorithms which use the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme (ECDH), and it defines how to perform client authentication with ECDSA and ECDH. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 12:33:15 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18974 for ; Mon, 2 Apr 2001 12:33:15 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Mon, 2 Apr 2001 12:31:52 -0400 Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-ecc-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A22.005AE049.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thanks Mark. The reference should be: "[LEN] A. Lenstra and E. Verhuel. Selecting cryptographic key sizes. Available at: www.cryptosavvy.com." I've added it to the draft so it will appear in the next rev. Best regards. Simon Mark Winstead on 04/02/2001 10:06:09 AM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-ecc-01.txt There is a small error in this document. There is a bibliography reference on page 3 to [LEN], but there is no [LEN] in the bibliography. Of course, I reserve the right to make more comments later :) Mark Winstead (Insert job title here) NetOctave, Inc RTP, NC www.netoctave.com mark.winstead@netoctave.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, April 02, 2001 7:18 AM To: IETF Transport Layer Security WG Cc: ietf-tls@lists.certicom.com Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ecc-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECC Cipher Suites For TLS Author(s) : S. Blake-Wilson, T. Dierks, C. Hawk Filename : draft-ietf-tls-ecc-01.txt Pages : 22 Date : 30-Mar-01 This document describes additions to TLS to support Elliptic Curve Cryptography (ECC). In particular it defines new key exchange algorithms which use the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Elliptic Curve Diffie-Hellman Key Agreement Scheme (ECDH), and it defines how to perform client authentication with ECDSA and ECDH. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --- You are currently subscribed to ietf-tls as: sblakewilson@certicom.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 12:45:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19868 for ; Mon, 2 Apr 2001 12:45:29 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Date: Mon, 2 Apr 2001 18:43:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <025601c0bb93$fca089e0$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Not being much of an ECC guy, some general comments from me. I do not quite understand the rationale for including exportable ciphersuites. I was under the impression that they have become obsolete with the new U.S. export policies. Also, ECDH_ECDSA and ECDH_RSA define exportable ciphersuites for RC4_40 and RC4_56, but ECDH_anon for DES_40 and RC4_40. Is that discrepancy intentional? A different issue are the client certificate types in the certificate request message. I would suggest skipping values 5 and 6 to avoid interoperability problems with SSL 3.0, which defined those values with different semantics. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 13:23:58 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21955 for ; Mon, 2 Apr 2001 13:23:57 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Mon, 2 Apr 2001 13:23:32 -0400 Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A22.005F84E0.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi Andreas, Thanks for the comments. Responses embedded below. Best regards. Simon I do not quite understand the rationale for including exportable ciphersuites. I was under the impression that they have become obsolete with the new U.S. export policies. SBW> The only rationale was that I don't understand export restrictions but would like to include cipher suites which allow as broad use as possible. What's the current WG policy on export cipher suites> Also, ECDH_ECDSA and ECDH_RSA define exportable ciphersuites for RC4_40 and RC4_56, but ECDH_anon for DES_40 and RC4_40. Is that discrepancy intentional? SBW> Discrepancy not intentional. I'll fix in the appropriate way based on the answer to the question above. A different issue are the client certificate types in the certificate request message. I would suggest skipping values 5 and 6 to avoid interoperability problems with SSL 3.0, which defined those values with different semantics. SBW> Will do. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 13:27:07 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22135 for ; Mon, 2 Apr 2001 13:27:06 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Date: Mon, 2 Apr 2001 18:43:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <025601c0bb93$fca089e0$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Not being much of an ECC guy, some general comments from me. I do not quite understand the rationale for including exportable ciphersuites. I was under the impression that they have become obsolete with the new U.S. export policies. Also, ECDH_ECDSA and ECDH_RSA define exportable ciphersuites for RC4_40 and RC4_56, but ECDH_anon for DES_40 and RC4_40. Is that discrepancy intentional? A different issue are the client certificate types in the certificate request message. I would suggest skipping values 5 and 6 to avoid interoperability problems with SSL 3.0, which defined those values with different semantics. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 2 13:41:00 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22773 for ; Mon, 2 Apr 2001 13:40:59 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Mon, 2 Apr 2001 13:05:29 -0400 Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A22.005DE51F.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thanks for the comments! Some responses embedded below. Best regards. Simon [...] If a client announces in its ClientHello message that it supports one particular ciphersuite of those defined in draft-ietf-tls-ecc-00.txt (TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, say), then with the draft as it is now the client must be prepared to be faced with curve definitions over any of GF(p) or GF(2^m) with ONBs or GF(2^m) with 'trinomial' basis representation or GF(2^m) with 'pentanomial' basis representation. The server can do with implementing just one of these -- after all, it is the server that gets to choose the curve --, but the client must be able to handle all of these to ensure interoperability. There is no way for the client to say 'I can do ECDH_ECDSA, but only with curves over GF(p)' or 'only using normal bases', and this makes draft-ietf-tls-ecc-00.txt pretty useless for weak clients. [...] SBW> Please note that the 01 draft was already finished when you sent the email ... and thanks for raising the point again. SBW> I'd argue that this concern is addressed to a large extent by curve recommendations ... provided the server follows the "SHOULD" about what curves to use, and the client implements the curves, everything will work fine. I believe, for example, that Certicom have implementations for constrained devices that support all the recommended curves None of the new key exchange methods provides both forward secrecy and authentication. The new draft uses ephemeral ECDH only for anonymous ciphersuites; otherwise, the server's DH share must be in its certificate. Forward secrecy is a desireable property (and comes at almost no additional cost for clients when RSA signatures are used since RSA signature verification is very fast), so there really should be ECDHE_ECDSA and ECDHE_RSA ciphersuites. Defining ECDHE_RSA ciphersuites has the additional practical advantage that many servers already have RSA certificates; i.e., they could start to use ECC ciphersuites without having to obtain additional certificates. SBW> I agree forward secrecy is a desirable attribute, but it does come at an additional cost - basically an ephemeral key pair gen for servers and a sig verify for clients. SBW> The decision to leave out ECDHE suites was based on a desire expressed by a number of people I've spoken to keep the number of cipher suites small. If the consensus is to add them back, it's fine with me. SBW> How would you feel about the following compromise - no ECDHE cipher suites, but a recommendation for servers that want FS to perform an authenticated handshake followed by an anon handshake over the secured record layer? (This would provide FS wouldn't it?) Use of the definite article suggests that there is a single byte string representation for a given elliptic curve point. This is not the case; there are three forms to choose from (compressed, uncompressed, and hybrid). The specification should clarify which forms may be used (all three of them?) and possibly which one is recommended (uncompressed?). SBW> Good point ... will do. Readers might think that these "SHOULD"s apply to those curves that are present in *all* of these specifications, whereas the intended meaning presumably is that any curve recommended by any one of them is OK. SBW> Good point ... will clarify. If it is in the scope of the ECC-TLS specification to recommend particular curves for public keys in X.509 certificates, then the specification probably should also explicitly recommend the use of a "namedCurve" (where available) rather then explicit "ecParameters" in certificates for ECC keys. SBW> I was planning to leave this to the PKIX group, but will add if you think it's appropriate. < named_curve < Indicates that a named curve will be used. The use of this option is < strongly recommended. Why not use the RFC 2119 keyword "SHOULD" here as well? SBW> Will do. < 4.5. Client Key Exchange < enum { yes, no } EphemeralPublicKey; This should be enum { yes(0), no(1) } EphemeralPublicKey; (or rather "no(0), yes(1)", which appears more natural). The RFC 2246 syntax requires explicit numbering. (Exception: "For enumerateds that are never converted to external representation, the numerical information may be omitted." Obviously this does not apply here.) SBW> Forgive my ignorance ... when is this info converted to external representation? (I know it affects what is sent in the client key exchange message, but from a quick inspection, I don't see where it is communicated ... instead it is implied from the key exchange method and client auth method, isn't it?.) --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Apr 3 03:52:02 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24806 for ; Tue, 3 Apr 2001 03:52:01 -0400 (EDT) X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to moeller@cdc.informatik.tu-darmstadt.de using -f Date: Tue, 3 Apr 2001 09:51:14 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <20010402162934.F2087@cdc.informatik.tu-darmstadt.de>; from moeller@cdc.informatik.tu-darmstadt.de on Mon, Apr 02, 2001 at 04:29:34PM +0200 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010403095114.A2973@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Apr 02, 2001 at 04:29:34PM +0200, Bodo Moeller wrote: > On Mon, Apr 02, 2001 at 04:22:33PM +0200, Bodo Moeller wrote: >> Before looking at several details, let me note that the following >> complaint about draft-ietf-tls-ecc-00.txt (March 1998) still applies: > [...] > > Not literally, of course -- there are no ONBs on draft-ietf-tls-ecc-01.txt, This again is not quite true: While draft-ietf-tls-ecc-01.txt does not specify ONBs for the ECCurve type (which is used for ephemeral DH), it does not forbid using ONBs for other EC cryptography (ECDSA, or certificate-based ECDH). -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Apr 3 06:12:58 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25624 for ; Tue, 3 Apr 2001 06:12:49 -0400 (EDT) X-Authentication-Warning: cdc-ws1.cdc.informatik.tu-darmstadt.de: moeller set sender to moeller@cdc.informatik.tu-darmstadt.de using -f Date: Tue, 3 Apr 2001 11:33:56 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Cc: IETF Transport Layer Security WG Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from sblakewilson@certicom.com on Mon, Apr 02, 2001 at 01:05:29PM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010403113356.C2954@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Apr 02, 2001 at 01:05:29PM -0400, Simon Blake-Wilson wrote: >> [...] If a client announces in its ClientHello message that it >> supports one particular ciphersuite of those defined in >> draft-ietf-tls-ecc-00.txt (TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, >> say), then with the draft as it is now the client must be prepared to >> be faced with curve definitions over any of GF(p) or GF(2^m) with ONBs >> or GF(2^m) with 'trinomial' basis representation or GF(2^m) with >> 'pentanomial' basis representation. [...] > Please note that the 01 draft was already finished when you > sent the email ... and thanks for raising the point again. > > I'd argue that this concern is addressed to a large extent > by curve recommendations ... provided the server follows the > "SHOULD" about what curves to use, and the client implements the > curves, everything will work fine. I believe, for example, that > Certicom have implementations for constrained devices that support > all the recommended curves *All* of them, including those based on ONBs? X9.62 defines curves using ONBs, but SEC 2 doesn't (and I hear that several people have problems even to verify that the purported generators of those X9.62 curves actually lie on the curve). But even if the server can be expected to restrict itself to SEC 2 curves, the client will have to implement different kinds of field arithmetics and different kinds of EC operations to guarantee interoperability. This makes it impossible for clients to rely on specialized hardware circuits. As far as implementation effort is concerned, I'd say the difference between TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA with GF(p) curves and the same ciphersuite with GF(2^m) curves is more significant than, for example, the difference between TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA and TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (with curves of the same type for these two ciphersuites). But while a client can instruct the server that it supports just 3DES and not AES, it cannot express that it supports just GF(2^m) and not GF(p) or just GF(p) and not GF(2^m). There's nothing inherently wrong about clients that don't support all kinds of curves, so why not specify the protocol such that the client hello contains enough information for the server to decide how to proceed without risking handshake failures? (Instead of defining additional ciphersuites, a client hello extension as defined in draft-ietf-tls-wireless-00.txt could be used for additional information on supported curves.) >> None of the new key exchange methods provides both forward secrecy and >> authentication. The new draft uses ephemeral ECDH only for anonymous >> ciphersuites; otherwise, the server's DH share must be in its >> certificate. Forward secrecy is a desireable property (and comes at >> almost no additional cost for clients when RSA signatures are used >> since RSA signature verification is very fast), so there really should >> be ECDHE_ECDSA and ECDHE_RSA ciphersuites. >> >> Defining ECDHE_RSA ciphersuites has the additional practical advantage >> that many servers already have RSA certificates; i.e., they could >> start to use ECC ciphersuites without having to obtain additional >> certificates. > I agree forward secrecy is a desirable attribute, but it does > come at an additional cost - basically an ephemeral key pair gen > for servers and a sig verify for clients. The server does not actually have to generate a new key pair for each new session. Typically it will be acceptable to keep the key pair for, say, an hour (or any other interval that is sufficiently shorter than the lifetime of a session). More of an issue is the necessity for the server to sign its parameters during each new handshake. If ECDSA signatures are used, this should mean less than 20% overhead per handshake (using a moderate amount of precomputation). If RSA signatures are used, the server overhead is more noticeable. At the client side, RSA signature verification is very cheap, so ECDHE_RSA won't be a problem even for slow clients. > The decision to leave out ECDHE suites was based on a desire > expressed by a number of people I've spoken to keep the number of > cipher suites small. If the consensus is to add them back, it's > fine with me. > > How would you feel about the following compromise - no ECDHE > cipher suites, but a recommendation for servers that want FS to > perform an authenticated handshake followed by an anon handshake > over the secured record layer? (This would provide FS wouldn't it?) This would provide forward secrecy, but at a higher cost (increased latency, and in many cases additional public-key operations). If there were a necessity to avoid adding more ciphersuites, I'd say replace all TLS_ECDH_RSA_... ciphersuites by TLS_ECDHE_RSA_... ciphersuites. This would impose nearly no additional computational effort on clients, and would insure that existing RSA certificates can be used with ECC ciphersuites (more efficiently than with the current TLS_DHE_RSA_... ciphersuites). There is actually no need to have TLS_ECDHE_*_WITH_NULL_* ciphersuites: You cannot hope for forward secrecy if you don't encrypt in the first place. Also it may turn out that the EXPORT ciphersuites are not needed (are there any actual export regulations defining a 163-bit limit for ECC?). So we are not talking about a huge list of additional ciphersuites: CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } >> If it is in the scope of the ECC-TLS specification to recommend >> particular curves for public keys in X.509 certificates, then the >> specification probably should also explicitly recommend the use of a >> "namedCurve" (where available) rather then explicit "ecParameters" in >> certificates for ECC keys. > I was planning to leave this to the PKIX group, but will add if > you think it's appropriate. I'm not sure if this should be just in the PKIX specs or here as well. (draft-ietf-pkix-ipki-pkalgs-02.txt says that In general, use of "well-known" curves, such as the "named curves" from ANSI X9.62 is a sound strategy, but does not actually specificy that in this case "namedCurve" parameters should be employed. Also draft-ietf-pkix-ipki-pkalgs-02.txt does not reference SEC 2.) But if we say that certain parameters "SHOULD" be used in certificates, then why not provide the additional recommendation to avoid explicit "ecParameters" when possible? Of course we can leave this to the PKIX specification, but in that case why not leave curve recommendations for certificates to it as well? >> < 4.5. Client Key Exchange >> < enum { yes, no } EphemeralPublicKey; >> >> This should be >> enum { yes(0), no(1) } EphemeralPublicKey; > Forgive my ignorance ... when is this info converted > to external representation? You are right, it is never converted to external representation (it only appears in a "select()"). So the definition in the draft is sufficient. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Apr 5 12:00:31 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06311 for ; Thu, 5 Apr 2001 12:00:30 -0400 (EDT) From: Simon Wilkinson To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RFC2712 KerberosWrapper encoding Date: Thu, 5 Apr 2001 17:00:17 +0100 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Message-Id: Content-Transfer-Encoding: 8bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <0104051700170F.06777@loki.dcs.ed.ac.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit Has anyone implemented, or is anyone aware of implementations of RFC2712? (I'm aware of kssl) I'm having some trouble understanding what is meant by the presentation language description of the KerberosWrapper. From the RFC: | struct | { | opaque Ticket; | opaque authenticator; /* optional */ | opaque EncryptedPreMasterSecret; /* encrypted with the session key | which is sealed in the ticket */ | } KerberosWrapper; /* new addition */ I'm not sure what is meant by the opaques here. The TLS RFC never uses opaque without explicitly stating a length. Are these fixed length, or variable length vectors? If they're variable length, then how many bytes are used to encode the length? My current implementation is using variable length, represented by 2 bytes - I was wondering what others have done. In particular I understand there was once a reference implementation Of course, all this becomes moot once draft-ietf-tls-kerb-00.txt becomes standardised (incidentally, I note that this draft uses, but does not define, KerbEncryptedPreMasterSecret ) Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk "If you can't be a good example, then you'll just have to be a horrible warning" -- Catherine Aird --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Apr 6 15:03:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17535 for ; Fri, 6 Apr 2001 15:03:12 -0400 (EDT) Message-ID: Date: Fri, 06 Apr 2001 12:02:51 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: RFC2712 KerberosWrapper encoding Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3ACE12DB.795FF413@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Simon Wilkinson wrote: > I'm having some trouble understanding what is meant by the presentation > language description of the KerberosWrapper. > > From the RFC: > | struct > | { > | opaque Ticket; > | opaque authenticator; /* optional */ > | opaque EncryptedPreMasterSecret; /* encrypted with the session key > | which is sealed in the ticket */ > | } KerberosWrapper; /* new addition */ > > I'm not sure what is meant by the opaques here. The TLS RFC never uses opaque > without explicitly stating a length. Right. A TLS opaque is a byte. If the above struct is interpreted according to the TLS presentation language, each of those is strictly one byte. Obviously that doesn't work in practice. > Are these fixed length, or variable length vectors? If they're variable > length, then how many bytes are used to > encode the length? RFC 2712 says "The ticket and authenticator are encoded per RFC1510 (ASN.1 encoding)." so, presumably the author intended for the opaques above to be variable length data whose length is determined from the ASN.1 encoding. IMO, that is an unfortunate choice because it means that the length of the KerberosWrapper cannot be determined without fully ASN.1 parsing the three members of that struct. TLS avoids doing that, and always explicitly gives the length of the ASN.1 encoded struct. E.g. in TLS's Certificate struct, we find each cert declared opaque ASN.1Cert<1..2^24-1> which means that the length of the cert is explicitly encoded in 3 bytes prior to the cert itself. Also, it's unclear to me how the recipient is supposed to know whether the "optional" authenticator is present or not. > My current implementation is using variable length, represented by 2 bytes - It sounds like your implemented the following structure (using TLS's presentation language): struct { opaque Ticket<1..2^16-1>; opaque authenticator<0..2^16-1>; opaque EncryptedPreMasterSecret<1..2^16-1>; /* encrypted with the session key which is sealed in the ticket */ } KerberosWrapper; /* new addition */ Is that what you did? That seems to me like the right thing to do. It also solves the question about the "optional" authenticator. A zero length authenticator is one not supplied. > I was wondering what others have done. In particular I understand there was > once a reference implementation > > Of course, all this becomes moot once draft-ietf-tls-kerb-00.txt becomes > standardised (incidentally, I note that this draft uses, but does not define, > KerbEncryptedPreMasterSecret ) Yes, that's another problem. I don't think interoperable implementations can be produced based strictly on RFC 2712 as it now stands. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Apr 6 15:33:36 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18342 for ; Fri, 6 Apr 2001 15:33:35 -0400 (EDT) From: Simon Wilkinson To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: RFC2712 KerberosWrapper encoding Date: Fri, 6 Apr 2001 20:33:23 +0100 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" In-Reply-To: Cc: nelsonb@netscape.com MIME-Version: 1.0 Message-Id: Content-Transfer-Encoding: 8bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <0104062033230J.06777@loki.dcs.ed.ac.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Friday 06 April 2001 20:02, Nelson Boyard wrote: > Also, it's unclear to me how the recipient is supposed to know whether the > "optional" authenticator is present or not. This was one of the motiviating factors for the assumptions I made to arrive at: > > My current implementation is using variable length, represented by 2 > > bytes - > > It sounds like your implemented the following structure (using TLS's > presentation language): [snip] > Is that what you did? Yes, I think that this works in all situations. > > Of course, all this becomes moot once draft-ietf-tls-kerb-00.txt becomes > > standardised (incidentally, I note that this draft uses, but does not > > define, KerbEncryptedPreMasterSecret ) > > Yes, that's another problem. Both 2712 and the later draft almost define it: the pre-master secret structure is the same as that used in the RSA case; it is encrypted under the Kerberos session key However, they provide no information as to the on-the-wire encoding. This is hard, because I'm not convinced that there's any guarantee that the encrypted PMS will always be the same length, as it depends on the block size of the underlying Kerberos encryption algorithm. I'm currently using a variable vector here as well. > I don't think interoperable implementations > can be produced based strictly on RFC 2712 as it now stands. I'm inclined to agree strongly here, after corresponding with the author of the 2712 support in OpenSSL as well. Cheers, Simon. -- Simon Wilkinson http://www.sxw.org.uk "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 16 13:57:54 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09981 for ; Mon, 16 Apr 2001 13:57:52 -0400 (EDT) Message-ID: From: Patrick Germain To: "IETF Transport Layer Security WG" Subject: [ietf-tls] TSL and TN : How to ? Date: Mon, 16 Apr 2001 13:56:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3BBF7A56CD8CD4118008000629131B450CFC94@mail.farabi.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi all Is there somewhere a document (RFC , dratf , anything) that explains how to concretely implement TLS for a TN connection ? Thanks -------------------------------------------- Patrick GERMAIN Product Development Manager Farabi Technology Corp. +1 (514) 332 34 55 (Ext 233) patrickg@farabi.com -------------------------------------------- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 16 14:09:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10281 for ; Mon, 16 Apr 2001 14:09:10 -0400 (EDT) Date: Mon, 16 Apr 2001 14:08:56 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: TSL and TN : How to ? In-Reply-To: Your message of Mon, 16 Apr 2001 13:56:22 -0400 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > > Hi all > > Is there somewhere a document (RFC , dratf , anything) that explains > how to concretely implement TLS for a TN connection ? Do you mean a Telnet connection? If so, the protocol is described in the TN3270 working group (Telnet over TLS) --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Apr 24 11:43:16 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09564 for ; Tue, 24 Apr 2001 11:43:14 -0400 (EDT) Message-ID: From: Maureen.Stillman@nokia.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] What is the Status of Extensions to TLS? Date: Tue, 24 Apr 2001 10:42:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Back in November and December of 2000 there was debate on the mailing list of an Internet-Draft: ----------------------------------------------------------------------- Title : Wireless Extensions to TLS Author(s) : S. Blake-Wilson Filename : draft-ietf-tls-wireless-00.txt Pages : 13 Date : 27-Nov-00 This document suggests extensions to TLS designed to make TLS more amenable to use within wireless environments. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt ---------------------------------------------------------------------------- ------------------------------------------------------------------- It was proposed to add a general extension mechanism to TLS in general and drop the term "wireless". Some other extensions to TLS were suggested during the course of the debate. Maybe I missed something, but I haven't heard anything about this recently. What is the current status of extensions to TLS? Alive or not? Consensus reached? Will a new I-D be issued, etc.? Thanks. -- maureen Maureen Stillman Nokia Member of Scientific Staff Voice: (607)273-0724 x62 Internet Commerce Enhancement Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman@nokia.com www.nokia.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Apr 24 15:01:58 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12782 for ; Tue, 24 Apr 2001 15:01:57 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Tue, 24 Apr 2001 14:37:56 -0400 Subject: [ietf-tls] Re: What is the Status of Extensions to TLS? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A38.006862C6.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi Maureen, Magnus and I are in the process of updating the draft. We should be posting an update shortly. Best regards. Simon Maureen.Stillman@nokia.com on 04/24/2001 11:42:02 AM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] What is the Status of Extensions to TLS? Back in November and December of 2000 there was debate on the mailing list of an Internet-Draft: ----------------------------------------------------------------------- Title : Wireless Extensions to TLS Author(s) : S. Blake-Wilson Filename : draft-ietf-tls-wireless-00.txt Pages : 13 Date : 27-Nov-00 This document suggests extensions to TLS designed to make TLS more amenable to use within wireless environments. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt ---------------------------------------------------------------------------- ------------------------------------------------------------------- It was proposed to add a general extension mechanism to TLS in general and drop the term "wireless". Some other extensions to TLS were suggested during the course of the debate. Maybe I missed something, but I haven't heard anything about this recently. What is the current status of extensions to TLS? Alive or not? Consensus reached? Will a new I-D be issued, etc.? Thanks. -- maureen Maureen Stillman Nokia Member of Scientific Staff Voice: (607)273-0724 x62 Internet Commerce Enhancement Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman@nokia.com www.nokia.com --- You are currently subscribed to ietf-tls as: sblakewilson@certicom.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Apr 26 04:22:17 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26063 for ; Thu, 26 Apr 2001 04:22:17 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" cc: ietf-tls@lists.certicom.com Message-ID: Date: Wed, 25 Apr 2001 23:28:09 -0400 Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A3A.002755B2.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi, Thanks for the feedback ... sorry for the slow turn around. My thoughts embedded below. >> I'd argue that this concern is addressed to a large extent >> by curve recommendations ... provided the server follows the >> "SHOULD" about what curves to use, and the client implements the >> curves, everything will work fine. I believe, for example, that >> Certicom have implementations for constrained devices that support >> all the recommended curves > > *All* of them, including those based on ONBs? X9.62 defines curves > using ONBs, but SEC 2 doesn't (and I hear that several people have > problems even to verify that the purported generators of those X9.62 > curves actually lie on the curve). SBW> I believe all SEC2 and FIPS186-2 curves. > But even if the server can be expected to restrict itself to SEC 2 > curves, the client will have to implement different kinds of field > arithmetics and different kinds of EC operations to guarantee > interoperability. This makes it impossible for clients to rely on > specialized hardware circuits. SBW> Specialized hardware that supports a range of field sizes should be fine. Specialized hardware that supports only one field seems like a tough sell for ECC in TLS with or without this functionality unless you can convince servers to go out and get a bunch of certificates. > There's nothing inherently wrong about clients that don't support all > kinds of curves, so why not specify the protocol such that the client > hello contains enough information for the server to decide how to > proceed without risking handshake failures? (Instead of defining > additional ciphersuites, a client hello extension as defined in > draft-ietf-tls-wireless-00.txt could be used for additional > information on supported curves.) SBW> I have no problem with the idea of defining additional hints in a hello extension. I think it would be good to write up a draft about this ... the issue seems to me to be more general than ECC ... for example it would be good to also allow hints about min and max key sizes for DH, DSA, and RSA, especially with AES around creating a desire to use commeasurate key sizes. > So we are not talking about a huge list of additional ciphersuites: > > CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_RSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } > CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } SBW> I can live with adding these as optional cipher suites, but then I'm not one of the strongest proponents of minimizing the number of new cipher suites. I'll add them to the draft unless anyone cares to speak up against. Thanks again for the feedback. Best regards. Simon --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Apr 26 05:23:58 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26709 for ; Thu, 26 Apr 2001 05:23:57 -0400 (EDT) Date: Thu, 26 Apr 2001 11:23:42 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ecc-01.txt Message-ID: References: <85256A3A.002755B2.00@smtpmail.certicom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: <85256A3A.002755B2.00@smtpmail.certicom.com>; from sblakewilson@certicom.com on Wed, Apr 25, 2001 at 11:28:09PM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010426112342.B6562@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Wed, Apr 25, 2001 at 11:28:09PM -0400, Simon Blake-Wilson wrote: [...] >> But even if the server can be expected to restrict itself to SEC 2 >> curves, the client will have to implement different kinds of field >> arithmetics and different kinds of EC operations to guarantee >> interoperability. This makes it impossible for clients to rely on >> specialized hardware circuits. > Specialized hardware that supports a range of field sizes should be fine. > Specialized hardware that supports only one field seems like a tough sell for > ECC in TLS with or without this functionality unless you can convince servers to > go out and get a bunch of certificates. We can expect typical servers to have RSA certificates as a fallback given that most clients don't support anything else. Similarly, typical clients will support RSA ciphersuites as well given that most servers have an RSA certificate only. Only in closed world scenarios you can do without RSA (and then it shouldn't be a problem to require everyone to support a specific curve). Also the curve is not always defined by a certificate; consider the ECDH_anon/ECDHE family of ciphersuites. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Apr 30 11:42:01 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15868 for ; Mon, 30 Apr 2001 11:41:59 -0400 (EDT) X-Lotus-FromDomain: HNS From: dillon@hns.com Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Message-ID: Date: Mon, 30 Apr 2001 11:41:15 -0400 Subject: [ietf-tls] Low-Response Time Secure Web Browsing Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A3E.00565FAC.00@ngw2.hns.com> X-List-Host: SKYLIST.net Colleagues, I'm interested in having HTTPS provide low-response time web browsing over long latency links, such as Satellite. As you know, the extra handshakes required by TLS tend to increase the response time. As such, some colleagues and I have put together a test bed and are looking at sniffer traces from various browser/web server combinations to see whether implementations are using the best features of HTTP and TLS to achieve low response time. I see that there is already an informational RFC (2818) regarding the use of HTTP over TLS, but that this document does not address performance issues. Would anyone on this working group be interested in seeing the results of our testing? Would anyone be interested in reviewing/contributing to an informational RFC recommending best practice for low response time? Doug..................... --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com