From tls-bounces@lists.ietf.org Tue May 31 21:37:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdIAo-0001Ig-AH; Tue, 31 May 2005 21:37:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdIAm-0001Ib-LV for tls@megatron.ietf.org; Tue, 31 May 2005 21:37: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 VAA16562 for ; Tue, 31 May 2005 21:37:30 -0400 (EDT) Received: from sam.opera.com ([193.69.113.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdIUU-0002Hz-FO for tls@ietf.org; Tue, 31 May 2005 21:57:55 -0400 Received: from rowan.invalid.invalid (cm-80.111.163.008.chello.no [80.111.163.8]) (authenticated bits=0) by sam.opera.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j511bFWf016646 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 1 Jun 2005 01:37:16 GMT Date: Wed, 01 Jun 2005 03:38:58 +0200 From: "Yngve N. Pettersen (Developer Opera Software ASA)" To: EKR Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-11.txt References: <200505181951.PAA01480@ietf.org> <86fyw3sziy.fsf@raman.networkresonance.com> Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: In-Reply-To: <86fyw3sziy.fsf@raman.networkresonance.com> User-Agent: Opera M2/7.54 (Win32, build 3929) X-Scanned-By: MIMEDefang 2.39 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sam.opera.com id j511bFWf016646 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable 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 Tue, 31 May 2005 17:15:33 -0700, EKR wrote: > "Yngve Nysaeter Pettersen" writes: > >> Hello all, >> >> A couple of question and comments: >> >> Sec. 6 says "If a TLS implementation receives a record type it does no= t >> understand, it SHOULD just ignore it." >> >> If such a record is received after the parties have started encrypting >> the records, should it try to decrypt the data, or should the >> implementation throw the record away immediately? > > Well, for RC4 you have to at least skip ahead to the next > section of keystream. With the block ciphers in TLS 1.1 you > can just discard the record. Otherwise, I think it's implementation > dependent. OK. >> About compatibility: Back in August/September 2004 Opera Software >> performed a test where we released a Technology Preview version of >> Opera with TLS 1.1 and TLS Extensions enabled. During this test our >> users identified more than 120 services (including major banks) that >> did not interoperate with a client using either TLS 1.1 or TLS >> Extensions, or both. I have so far not been able to find out what is >> causing the problem. > > You mean aside from noone actually implementing them? :) > > Was there some other problem? Yes. The mentioned servers (or their surround support systems) did not =20 tolerate clients that used TLS 1.1, or TLS extensions, or both. The most = =20 common response (but not the only one) to a Client Hello including one or= =20 both of them is to shut down the connection, without any alert messages =20 whatsoever. There are a number of variations, some servers would accept either, but =20 not both; others would accept TLS 1.1 and extensions, but not TLS 1.0 wit= h =20 extensions, and so on. I classified 5 major types of problems. Some minor variations also existed: One TLS 1.0 capable server actually =20 negotiated SSL v3 when the client asked for TLS 1.1. Another used an =20 incorrect version number (the negotiated) when checking the RSA Premaster= =20 Secret. In one case I saw one server that initially only cut the connection when = a =20 TLS 1.1 Hello was sent change to also cutting the connection when TLS =20 Extensions were used, a few weeks later. See the top post in =20 http://my.opera.com/forums/showthread.php?s=3D&threadid=3D65055 for more = =20 examples. For those interested, Opera 8.0 ships with TLS 1.1 (it still support =20 export ciphers) and TLS Server Name Extension support, both controlled by= =20 the TLS 1.1 setting, which is disabled by default. --=20 Sincerely, Yngve N. Pettersen =A0 ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 02 12:16:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsM5-0001Ca-C8; Thu, 02 Jun 2005 12:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsM3-00019Y-Dy for tls@megatron.ietf.org; Thu, 02 Jun 2005 12:15:35 -0400 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03285 for ; Thu, 2 Jun 2005 12:15:32 -0400 (EDT) Received: by mail.ca.certicom.com (Postfix) id 74C9E100A8; Thu, 2 Jun 2005 12:15:04 -0400 (EDT) Delivered-To: ietf-tls@lists.certicom.com Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 405DD100C5 for ; Thu, 2 Jun 2005 12:15:04 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21733-22 for ; Thu, 2 Jun 2005 12:14:51 -0400 (EDT) Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by mail.ca.certicom.com (Postfix) with ESMTP id 35097100A8 for ; Thu, 2 Jun 2005 12:14:50 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 1D0A428571; Thu, 2 Jun 2005 09:47:38 -0700 (PDT) To: ietf-tls@lists.certicom.com, cryptography@metzdowd.com X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 02 Jun 2005 09:25:33 -0700 From: Eric Rescorla Message-Id: <20050602164738.1D0A428571@sierra.rtfm.com> Cc: Subject: [TLS] ANNOUNCE: PureTLS 0.9b5 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 ANNOUNCE: PureTLS version 0.9b5 Copyright (C) 1999-2005 Claymore Systems, Inc. http://www.rtfm.com/puretls DESCRIPTION PureTLS is a free Java-only implementation of the SSLv3 and TLSv1 (RFC2246) protocols. PureTLS was developed by Eric Rescorla for Claymore Systems, Inc, but is being distributed for free because we believe that basic network security is a public good and should be a commodity. PureTLS is licensed under a Berkeley-style license, which basically means that you can do anything you want with it, provided that you give us credit. This is a beta release of PureTLS. Although it has undergone a fair amount of testing and is believed to operate correctly, it no doubt contains significant bugs, which this release is intended to shake out. Please send any bug reports to the author at . CHANGES FROM B4 * SECURITY: Zero OPTIONAL values before parsing. This prevents bleedthrough of those values from previously parsed certificates into certificates where they are missing. This is a workaround for a bug in the Cryptix ASN.1 kit. The only relevant values are Extensions and Algorithm.Parameters. In practice this should not be a problem with Algorithm.Parameters Since they're NULL in RSA certificates and always present in real DSA certificates. If you rely on Extensions you should upgrade as soon as possible. Note: extensions processing is still only partially tested (see below). * Trim all leading zeros from DH shared keys. This fixes a rare compatibility problem. * Fix handling of pathLen constraints. We were off by one, causing some valid certificates to be rejected. We believe that this is the best version of PureTLS available. Users are advised to upgrade as soon as possible. In particular, if you rely on X.509 extension processing you should upgrade as soon as possible. This will most likely be the last release of PureTLS distributed as a standalone package by Claymore Systems. We have given the BouncyCastle (http://www.bouncycastle.org) permission to integrate the PureTLS source code with their library and we expect them to deliver an integrated system in the future. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 02 13:14:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdtHP-0002mC-3b; Thu, 02 Jun 2005 13:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdtHN-0002lW-B9 for tls@megatron.ietf.org; Thu, 02 Jun 2005 13:14:49 -0400 Received: from sierra.rtfm.com (sierra.rtfm.com [198.144.203.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08177 for ; Thu, 2 Jun 2005 13:14:45 -0400 (EDT) Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 5BA2528442 for ; Thu, 2 Jun 2005 10:47:06 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 02 Jun 2005 10:25:01 -0700 From: Eric Rescorla Message-Id: <20050602174706.5BA2528442@sierra.rtfm.com> Cc: Subject: [TLS] ANNOUNCE: PureTLS 0.9b5 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 ANNOUNCE: PureTLS version 0.9b5 Copyright (C) 1999-2005 Claymore Systems, Inc. http://www.rtfm.com/puretls DESCRIPTION PureTLS is a free Java-only implementation of the SSLv3 and TLSv1 (RFC2246) protocols. PureTLS was developed by Eric Rescorla for Claymore Systems, Inc, but is being distributed for free because we believe that basic network security is a public good and should be a commodity. PureTLS is licensed under a Berkeley-style license, which basically means that you can do anything you want with it, provided that you give us credit. This is a beta release of PureTLS. Although it has undergone a fair amount of testing and is believed to operate correctly, it no doubt contains significant bugs, which this release is intended to shake out. Please send any bug reports to the author at . CHANGES FROM B4 * SECURITY: Zero OPTIONAL values before parsing. This prevents bleedthrough of those values from previously parsed certificates into certificates where they are missing. This is a workaround for a bug in the Cryptix ASN.1 kit. The only relevant values are Extensions and Algorithm.Parameters. In practice this should not be a problem with Algorithm.Parameters Since they're NULL in RSA certificates and always present in real DSA certificates. If you rely on Extensions you should upgrade as soon as possible. Note: extensions processing is still only partially tested (see below). * Trim all leading zeros from DH shared keys. This fixes a rare compatibility problem. * Fix handling of pathLen constraints. We were off by one, causing some valid certificates to be rejected. We believe that this is the best version of PureTLS available. Users are advised to upgrade as soon as possible. In particular, if you rely on X.509 extension processing you should upgrade as soon as possible. This will most likely be the last release of PureTLS distributed as a standalone package by Claymore Systems. We have given the BouncyCastle (http://www.bouncycastle.org) permission to integrate the PureTLS source code with their library and we expect them to deliver an integrated system in the future. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 03 13:57:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGQe-00042q-NN; Fri, 03 Jun 2005 13:57:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGQd-00042l-7A for tls@megatron.ietf.org; Fri, 03 Jun 2005 13:57:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18911 for ; Fri, 3 Jun 2005 13:57:53 -0400 (EDT) Received: from mx2.cryptopro.ru ([213.59.158.218]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeGks-0001q8-Hj for tls@ietf.org; Fri, 03 Jun 2005 14:18:52 -0400 Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(5.0.2195.6713); Fri, 3 Jun 2005 22:00:01 +0400 Message-ID: <00ef01c56866$10276fa0$0644a8c0@cp.ru> From: "Gregory S. Chudov" To: , , References: Subject: Re: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Date: Fri, 3 Jun 2005 22:00:01 +0400 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 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 03 Jun 2005 18:00:01.0792 (UTC) FILETIME=[10370000:01C56866] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Greetings. Unfortunately, TLS does not allow a ciphersuite to choose a different PRF. Quote from rfc2246: HMAC can be used with a variety of different hash algorithms. TLS uses it in the handshake with two different algorithms: MD5 and SHA- 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, data). Additional hash algorithms can be defined by cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for this version of the protocol. So adding a cipher suite, which uses different PRF means breaking a protocol. Such cipher suites will not be "legitimate" without the support and analysis from this working group. Good luck! Greg Chudov ----- Original Message ----- From: To: ; Sent: Monday, May 30, 2005 8:58 AM Subject: RE: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Hi, It does seem that having a way to use some other PRF than the standard one would be useful in some (very limited) circumstances. However, I'm not so sure about the usefulness of adding a new negotiation mechanism for it. It was proposed earlier that we could simply define the PRF (and the hash used when calculating Finished messages) to be part of the ciphersuite; this sounds like a reasonable and simple approach to me. (Of course, for those ciphersuites that don't say anything about the PRF, it would be the standard TLS-PRF, so there's no need to have this included in 2246bis.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 03 14:14:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGcb-0006kb-Ll; Fri, 03 Jun 2005 14:10:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeGcZ-0006jo-QF for tls@megatron.ietf.org; Fri, 03 Jun 2005 14:10:15 -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 OAA19776 for ; Fri, 3 Jun 2005 14:10:14 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeGwo-00026t-Ms for tls@ietf.org; Fri, 03 Jun 2005 14:31:13 -0400 Received: from jurassic.eng.sun.com ([129.146.226.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j53IA7FF020703; Fri, 3 Jun 2005 11:10:07 -0700 (PDT) Received: from [129.146.109.175] (d-mpk17-109-175.SFBay.Sun.COM [129.146.109.175]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j53IA6sJ870510; Fri, 3 Jun 2005 11:10:07 -0700 (PDT) Message-ID: <42A09CF9.4040703@Sun.COM> Date: Fri, 03 Jun 2005 11:10:01 -0700 From: Kais Belgaied User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20050502 X-Accept-Language: ar-eg, en-us, en, ar, ar-dz, ar-bh, ar-iq, ar-jo, ar-kw, ar-lb, ar-ly, ar-ma, ar-om, ar-qa, ar-sa, ar-sy, ar-tn, ar-ae, ar-ye MIME-Version: 1.0 To: "Gregory S. Chudov" Subject: Re: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt References: <00ef01c56866$10276fa0$0644a8c0@cp.ru> In-Reply-To: <00ef01c56866$10276fa0$0644a8c0@cp.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kais.Belgaied@Sun.COM 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 Gregory S. Chudov wrote: > Greetings. > Unfortunately, TLS does not allow a ciphersuite to choose a different PRF. > > Quote from rfc2246: > > HMAC can be used with a variety of different hash algorithms. TLS > uses it in the handshake with two different algorithms: MD5 and SHA- > 1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, > data). Additional hash algorithms can be defined by cipher suites and > used to protect record data, but MD5 and SHA-1 are hard coded into > the description of the handshaking for this version of the protocol. > > So adding a cipher suite, which uses different PRF means breaking a > protocol. or introduce the new/negotiated PRF with a new minor version number of the protocol: TLS1.1 Kais. > Such cipher suites will not be "legitimate" without the support and analysis > from > this working group. > > Good luck! > Greg Chudov > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 03 15:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIJw-00028P-OF; Fri, 03 Jun 2005 15:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeIJt-00027L-GM; Fri, 03 Jun 2005 15:59:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00092; Fri, 3 Jun 2005 15:59:03 -0400 (EDT) Message-Id: <200506031959.PAA00092@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, 03 Jun 2005 15:59:03 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-12.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 : The TLS Protocol Version 1.1 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc2246-bis-12.txt Pages : 91 Date : 2005-6-3 This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-12.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-rfc2246-bis-12.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-rfc2246-bis-12.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-6-3162950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc2246-bis-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc2246-bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-3162950.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 Mon Jun 06 07:23:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfFhW-0005oU-UC; Mon, 06 Jun 2005 07:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfFhV-0005oP-4x for tls@megatron.ietf.org; Mon, 06 Jun 2005 07:23:25 -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 HAA20162 for ; Mon, 6 Jun 2005 07:23:23 -0400 (EDT) Received: from decibel.pvv.ntnu.no ([129.241.210.179]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfG2J-0006W6-G7 for tls@ietf.org; Mon, 06 Jun 2005 07:44:56 -0400 Received: (qmail 19828 invoked by uid 32454); 6 Jun 2005 11:23:19 -0000 To: EKR Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-09.txt References: <200412082120.QAA04428@ietf.org> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Mon, 06 Jun 2005 13:23:19 +0200 In-Reply-To: (Eric Rescorla's message of "Wed, 15 Dec 2004 11:10:00 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Eric Rescorla writes: > Jostein Tveit writes: > >> Section 6.3: >>> Implementation note: >>> The currently defined which requires the most material is >>> AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte >> >> I think "cipher spec" is missing from this sentence. > > Thanks. This typo is still present in draft-ietf-tls-rfc2246-bis-12.txt. Regards, -- Jostein Tveit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 06 07:42:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfG0P-0007A7-UR; Mon, 06 Jun 2005 07:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfG0O-00078r-M2 for tls@megatron.ietf.org; Mon, 06 Jun 2005 07:42:56 -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 HAA21203 for ; Mon, 6 Jun 2005 07:42:55 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfGLD-0006zs-Nm for tls@ietf.org; Mon, 06 Jun 2005 08:04:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j56BgnP0005037; Mon, 6 Jun 2005 14:42:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 14:42:50 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jun 2005 14:42:49 +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] draft-chudov-cryptopro-tlsprfneg-00.txt Date: Mon, 6 Jun 2005 14:42:48 +0300 Message-ID: Thread-Topic: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Thread-Index: AcVoZenvLv/VeIyLQT+DDuaUHWS4kACJMjEA To: , , X-OriginalArrivalTime: 06 Jun 2005 11:42:49.0586 (UTC) FILETIME=[DD9BAD20:01C56A8C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Gregory S. Chudov wrote: >=20 > Greetings. > Unfortunately, TLS does not allow a ciphersuite to choose a=20 > different PRF. >=20 > Quote from rfc2246: >=20 > HMAC can be used with a variety of different hash algorithms.=20 > TLS uses it in the handshake with two different algorithms:=20 > MD5 and SHA-1, denoting these as HMAC_MD5(secret, data)=20 > and HMAC_SHA(secret, data). Additional hash algorithms can=20 > be defined by cipher suites and used to protect record data,=20 > but MD5 and SHA-1 are hard coded into the description of the=20 > handshaking for this version of the protocol. >=20 > So adding a cipher suite, which uses different PRF means=20 > breaking a protocol. Such cipher suites will not be "legitimate"=20 > without the support and analysis from this working group. I fully agree: a ciphersuite cannot (and definitely should not) just decide by itself to change that part of RFC 2246. But if=20 we (TLS WG) decide to work on alternative PRFs, we will anyway=20 need a document that updates this part of RFC 2246/2246bis=20 somehow.=20 The main alternatives seem to be defining PRF to be a property that can be negotiated separately from the ciphersuite (and thus we need a new negotiation mechanism, as proposed in your draft), or defining PRF to be associated with the ciphersuite (so we can use the existing ciphersuite negotiation, as I proposed in my previous email). Both work, but both also change RFC 2246;=20 IMHO the latter approach might be a bit simpler... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 06 07:55:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfGC5-00089E-Qs; Mon, 06 Jun 2005 07:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfGC4-000896-Ry for tls@megatron.ietf.org; Mon, 06 Jun 2005 07:55:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22197 for ; Mon, 6 Jun 2005 07:54:59 -0400 (EDT) Received: from decibel.pvv.ntnu.no ([129.241.210.179]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DfGWu-0007DA-0o for tls@ietf.org; Mon, 06 Jun 2005 08:16:33 -0400 Received: (qmail 2760 invoked by uid 32454); 6 Jun 2005 11:54:58 -0000 To: tls@ietf.org Subject: Re: [TLS] whither draft-salowey-tls-ticket-02.txt? References: <20050520011624.BD2028A02C@laser.networkresonance.com> <42969F7B.9040804@bolyard.com> From: Jostein Tveit Organization: Norwegian University of Science and Technology Date: Mon, 06 Jun 2005 13:54:58 +0200 In-Reply-To: <42969F7B.9040804@bolyard.com> (Nelson B. Bolyard's message of "Thu, 26 May 2005 21:18:03 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 "Nelson B. Bolyard" writes: > EKR wrote: > >> Is there interest in the TLS WG in pursuing this as a WG item? >> Please send comments/discussion on this topic by May 31. > > Yes, I believe that this proposed enhancement to TLS is worthy of > our group's pursuit. It would potentially enable TLS server solutions > to scale to multiple server-system (box) solutions more cheaply than is > commonly done today, I think. Even though I am a bit late for the May 31 deadline for this discussion, I believe that this draft is in interest of the TLS WG. So I agree with Bolyard. Regards, -- Jostein Tveit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 07 14:58:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjHg-000726-CJ; Tue, 07 Jun 2005 14:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjHd-000720-W8 for tls@megatron.ietf.org; Tue, 07 Jun 2005 14:58:42 -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 OAA21793 for ; Tue, 7 Jun 2005 14:58:40 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfjck-0002Ha-Iw for tls@ietf.org; Tue, 07 Jun 2005 15:20:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 11:58:32 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 11:58:31 -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.1830); Tue, 7 Jun 2005 11:58:31 -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, 7 Jun 2005 11:58:31 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 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] I-D ACTION:draft-ietf-tls-ecc-10.txt Date: Tue, 7 Jun 2005 11:58:30 -0700 Message-ID: Thread-Topic: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt thread-index: AcVmGzwSMGHtOhyPRgOh15+emjJlZgFduxWg From: "Ari Medvinsky" To: , , , X-OriginalArrivalTime: 07 Jun 2005 18:58:31.0228 (UTC) FILETIME=[E5A76FC0:01C56B92] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: Joshua Ball , Jeff Spelman , Virginia Robbins , 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 =20 I have a question about the elliptic curve extension. Lets say in the hello msg the client sends several curves to the server (e.g., secp256r1, secp384rl, secp384rl) and specifies that it supports several ECC cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA). Does this mean that for each of the above cipher suites the client MUST support every curve sent in the elliptic curve extension? (secp256r1, secp384rl, secp384rl) Is there a way to specify via the proposed extension mechanism that for TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA the client only supports secp256r1 curve and for the TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA the client only supports secp384rl and secp384rl curves ? Ari Medvinsky Program Manager Windows Security -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, May 31, 2005 12:54 PM To: i-d-announce@ietf.org Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.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) : V. Gupta, et al. Filename : draft-ietf-tls-ecc-10.txt Pages : 35 Date : 2005-5-31 =09 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-10.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. =20 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-10.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-10.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 07 15:11:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjU3-0000uJ-N1; Tue, 07 Jun 2005 15:11:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfjU1-0000uD-Iy for tls@megatron.ietf.org; Tue, 07 Jun 2005 15:11: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 PAA23314 for ; Tue, 7 Jun 2005 15:11:27 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfjp6-0002Yi-NS for tls@ietf.org; Tue, 07 Jun 2005 15:33:18 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.30.54] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML21M-1DfjTm2jrv-0001LU; Tue, 07 Jun 2005 21:11:14 +0200 Received: by tau.local (Postfix, from userid 500) id E2AE63627A; Tue, 7 Jun 2005 13:11:04 -0600 (MDT) Date: Tue, 7 Jun 2005 13:11:04 -0600 From: Bodo Moeller To: Ari Medvinsky Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt Message-ID: <20050607191104.GA10877@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: 8abaac9e10c826e8252866cbe6766464 Cc: Jeff Spelman , tls@ietf.org, Joshua Ball , Virginia Robbins , 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, Jun 07, 2005 at 11:58:30AM -0700, Ari Medvinsky wrote: > I have a question about the elliptic curve extension. Lets say in the > hello msg the client sends several curves to the server (e.g., > secp256r1, secp384rl, secp384rl) and specifies that it supports several > ECC cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA). > > Does this mean that for each of the above cipher suites the client MUST > support every curve sent in the elliptic curve extension? (secp256r1, > secp384rl, secp384rl) Yes. > Is there a way to specify via the proposed extension mechanism that for > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA the client only supports secp256r1 > curve and for the TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA the client > only supports secp384rl and secp384rl curves ? No. Can you motivate a scenario where this would be needed? I wouldn't think that such a requirement would come up frequently enough to warrant the extra complication to the protocol for a more fine-grained curve negotiation. There is, of course, always a possibility to work around this problem with some protocol overhead, namely by using multiple connection attempts with appropriately restricted parameters. (Also, with the TrustedAuthority client hello extension, a client that supports only secp256r1 for ECDSA may avoid being offered an EC server certificate using secp384r1 if different CA names are used to issue EC certificates.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 07 16:27:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfkfv-0007jL-LR; Tue, 07 Jun 2005 16:27:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfkft-0007i0-UN for tls@megatron.ietf.org; Tue, 07 Jun 2005 16:27: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 QAA08527 for ; Tue, 7 Jun 2005 16:27:47 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfl10-0007Mm-Uk for tls@ietf.org; Tue, 07 Jun 2005 16:49:39 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 13:27:39 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 13:27:38 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Jun 2005 13:27:37 -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); Tue, 7 Jun 2005 13:27:37 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 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] I-D ACTION:draft-ietf-tls-ecc-10.txt Date: Tue, 7 Jun 2005 13:27:37 -0700 Message-ID: Thread-Topic: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt thread-index: AcVrlLGaOHQEA+pySxOEjjTXOg8osgACkaMg From: "Ari Medvinsky" To: "Bodo Moeller" X-OriginalArrivalTime: 07 Jun 2005 20:27:37.0478 (UTC) FILETIME=[58447260:01C56B9F] X-Spam-Score: 2.0 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: Jeff Spelman , tls@ietf.org, Joshua Ball , Virginia Robbins , 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 The scenario is if you have a pluggable/extensible TLS provider where third parties can implement and plug in their own cipher suites. A third party may be a hardware vendor that offers perf improvements for the ecc cipher suites. Using my previous example, by default the TLS provider might support: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA with curves: secp256r1, secp384rl, secp384rl TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA with curves: secp256r1, secp384rl, secp384rl Lets say the third party plugs in: TLS_ECDH_ECDSA_WITH_RC4_128_SHA with curves: sect163k1, sect163rl, sect163r2 Given the way the current draft is defined, there is no way for me to send all three cipher suites in the same message because there is no intersection between the curves. I would suggest to modify the draft so that the new extension specifies each ecc cipher suite (in the hello msg) with a list of supported curves. E.g. info contained in the modified extension: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: secp256r1, secp384rl, secp384rl TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: secp256r1, secp384rl, secp384rl TLS_ECDH_ECDSA_WITH_RC4_128_SHA: sect163k1, sect163rl, sect163r2=20 Ari Medvinsky Program Manager Windows Security -----Original Message----- From: Bodo Moeller [mailto:bmoeller@acm.org]=20 Sent: Tuesday, June 07, 2005 12:11 PM To: Ari Medvinsky Cc: tls@ietf.org; vipul.gupta@sun.com; sblakewilson@bcisse.com; Joshua Ball; Jeff Spelman; Cristian Ilac; Virginia Robbins Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt On Tue, Jun 07, 2005 at 11:58:30AM -0700, Ari Medvinsky wrote: > I have a question about the elliptic curve extension. Lets say in the > hello msg the client sends several curves to the server (e.g.,=20 > secp256r1, secp384rl, secp384rl) and specifies that it supports=20 > several ECC cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA). >=20 > Does this mean that for each of the above cipher suites the client=20 > MUST support every curve sent in the elliptic curve extension?=20 > (secp256r1, secp384rl, secp384rl) Yes. > Is there a way to specify via the proposed extension mechanism that=20 > for TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA the client only supports=20 > secp256r1 curve and for the=20 > TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA the client only supports secp384rl and secp384rl curves ? No. Can you motivate a scenario where this would be needed? I wouldn't think that such a requirement would come up frequently enough to warrant the extra complication to the protocol for a more fine-grained curve negotiation. There is, of course, always a possibility to work around this problem with some protocol overhead, namely by using multiple connection attempts with appropriately restricted parameters. (Also, with the TrustedAuthority client hello extension, a client that supports only secp256r1 for ECDSA may avoid being offered an EC server certificate using secp384r1 if different CA names are used to issue EC certificates.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jun 07 18:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfmAG-0004Fr-Pp; Tue, 07 Jun 2005 18:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfmAE-0004Bn-6n for tls@megatron.ietf.org; Tue, 07 Jun 2005 18:03: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 SAA17836 for ; Tue, 7 Jun 2005 18:03:11 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfmVG-0001zH-5U for tls@ietf.org; Tue, 07 Jun 2005 18:25:04 -0400 Received: from dhcp238.math.ucalgary.ca [136.159.61.238] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwh2-1Dfm9y3rli-00034h; Wed, 08 Jun 2005 00:02:58 +0200 Received: by tau.local (Postfix, from userid 500) id C53F73627A; Tue, 7 Jun 2005 16:02:27 -0600 (MDT) Date: Tue, 7 Jun 2005 16:02:27 -0600 From: Bodo Moeller To: Ari Medvinsky Subject: Ciphersuite specific extensions (was: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt) Message-ID: <20050607220227.GA11744@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.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Jeff Spelman , tls@ietf.org, Joshua Ball , Virginia Robbins , 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, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote: > The scenario is if you have a pluggable/extensible TLS provider where > third parties can implement and plug in their own cipher suites. I see. I have argued for a general mechanism for ciphersuite-dependent TLS extensions in the past. That is, instead of having individual specifications defining TLS extensions provide means of restricting certain extensions to certain ciphersuites, it would make sense to have a mechanism that can be applied to all extensions, preferably defined in the successor of RFC 3456. For example, extension type 65535 in the client hello could indicate an extension with content struct { ExtensionRestriction restriction_list<7..2^16-1>; } RestrictedExtensions; where struct { CipherSuite cipher_suites<2..2^16-1>; Extension extension_list<1..2^16-1>; } ExtensionRestriction; This would indicate that for each ExtensionRestriction, the listed extensions apply to the listed ciphersuites only. (The server would collect applicable extensions from those that appear directly in the client_hello_extension_list field of ClientHello, and those that appear in an ExtensionRestriction naming the respective ciphersuite.) With pluggable ciphersuites, use of the trusted_ca_keys extension would likely be restricted to certain ciphersuites as well (if only one of the plug-ins can make sense of a certain trusted CA certificate, then you wouldn't want to offer it as a trusted authority for other ciphersuites). And certainly the client_certificate_url extension would be ciphersuite-specific. What do you (and others, of course) think of this approach? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 08 12:42:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg3d1-0003Ek-0V; Wed, 08 Jun 2005 12:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg3cB-0002z7-P4 for tls@megatron.ietf.org; Wed, 08 Jun 2005 12:41: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 MAA15605 for ; Wed, 8 Jun 2005 12:41:12 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg3xT-0000bW-QG for tls@ietf.org; Wed, 08 Jun 2005 13:03:16 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jun 2005 09:41:05 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jun 2005 09:40:55 -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.1830); Wed, 8 Jun 2005 09:40:55 -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); Wed, 8 Jun 2005 09:40:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ciphersuite specific extensions (was: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt) Date: Wed, 8 Jun 2005 09:40:54 -0700 Message-ID: Thread-Topic: Ciphersuite specific extensions (was: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt) thread-index: AcVrrLcwL50lyxikRWqd3VFUFhHZ7QAmoXtw From: "Ari Medvinsky" To: "Bodo Moeller" X-OriginalArrivalTime: 08 Jun 2005 16:40:54.0791 (UTC) FILETIME=[D6D8E170:01C56C48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Jeff Spelman , tls@ietf.org, Joshua Ball , Virginia Robbins , 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 like this idea, I think it covers well the ecc cipher suite/curve mapping problem. Are you proposing then to modify the ecc draft to take a dependency on the next rev of rfc3546? =20 -----Original Message----- From: Bodo Moeller [mailto:bmoeller@acm.org]=20 Sent: Tuesday, June 07, 2005 3:02 PM To: Ari Medvinsky Cc: tls@ietf.org; vipul.gupta@sun.com; sblakewilson@bcisse.com; Joshua Ball; Jeff Spelman; Cristian Ilac; Virginia Robbins Subject: Ciphersuite specific extensions (was: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt) On Tue, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote: > The scenario is if you have a pluggable/extensible TLS provider where=20 > third parties can implement and plug in their own cipher suites. I see. I have argued for a general mechanism for ciphersuite-dependent TLS extensions in the past. That is, instead of having individual specifications defining TLS extensions provide means of restricting certain extensions to certain ciphersuites, it would make sense to have a mechanism that can be applied to all extensions, preferably defined in the successor of RFC 3456. For example, extension type 65535 in the client hello could indicate an extension with content struct { ExtensionRestriction restriction_list<7..2^16-1>; } RestrictedExtensions; where struct { CipherSuite cipher_suites<2..2^16-1>; Extension extension_list<1..2^16-1>; } ExtensionRestriction; This would indicate that for each ExtensionRestriction, the listed extensions apply to the listed ciphersuites only. (The server would collect applicable extensions from those that appear directly in the client_hello_extension_list field of ClientHello, and those that appear in an ExtensionRestriction naming the respective ciphersuite.) With pluggable ciphersuites, use of the trusted_ca_keys extension would likely be restricted to certain ciphersuites as well (if only one of the plug-ins can make sense of a certain trusted CA certificate, then you wouldn't want to offer it as a trusted authority for other ciphersuites). And certainly the client_certificate_url extension would be ciphersuite-specific. What do you (and others, of course) think of this approach? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 08 13:48:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg4fg-0007oM-Kt; Wed, 08 Jun 2005 13:48:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg4fe-0007oH-Qa for tls@megatron.ietf.org; Wed, 08 Jun 2005 13:48:54 -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 NAA20814 for ; Wed, 8 Jun 2005 13:48:53 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg50v-00024T-4R for tls@ietf.org; Wed, 08 Jun 2005 14:10:55 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.30.54] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML29c-1Dg4fU1Ik0-0003OV; Wed, 08 Jun 2005 19:48:44 +0200 Received: by tau.local (Postfix, from userid 500) id 47BDF36274; Wed, 8 Jun 2005 11:48:42 -0600 (MDT) Date: Wed, 8 Jun 2005 11:48:42 -0600 From: Bodo Moeller To: tls@ietf.org Subject: Re: Ciphersuite specific extensions (was: Re: [TLS] I-D ACTION:draft-ietf-tls-ecc-10.txt) Message-ID: <20050608174841.GA25125@tau.local> 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: 4b800b1eab964a31702fa68f1ff0e955 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, Jun 08, 2005 at 09:40:54AM -0700, Ari Medvinsky wrote: > I like this idea, I think it covers well the ecc cipher suite/curve > mapping problem. Are you proposing then to modify the ecc draft to take > a dependency on the next rev of rfc3546? Yes. I hope that it is agreed to change the TLS Extensions specification like this or similar. The TLS-ECC specification should cite the successor of RFC 3546, thus resolving the issue. (Actually, the TLS-ECC specification already *has* to cite the successor of RFC 3546 because TLS-ECC, if published as an Informational RFC, couldn't define it's own TLS extensions according to RFC 3546. draft-ietf-tls-rfc3546bis-##.txt has weaker requirements so that an Informational RFC can define new extensions.) Bodo [I have copied this message to the other authors of draft-ietf-tls-rfc3546bis-01.txt as well (this is a separate mailing to tls@ietf.org which otherwise complains about "too many recipients"). I'd really like to hear more opinions!] > From: Bodo Moeller [mailto:bmoeller@acm.org] > Sent: Tuesday, June 07, 2005 3:02 PM > To: Ari Medvinsky > Cc: tls@ietf.org; vipul.gupta@sun.com; sblakewilson@bcisse.com; Joshua > Ball; Jeff Spelman; Cristian Ilac; Virginia Robbins > Subject: Ciphersuite specific extensions (was: Re: [TLS] I-D > ACTION:draft-ietf-tls-ecc-10.txt) [...] > I have argued for a general mechanism for ciphersuite-dependent TLS > extensions in the past. That is, instead of having individual > specifications defining TLS extensions provide means of restricting > certain extensions to certain ciphersuites, it would make sense to have > a mechanism that can be applied to all extensions, preferably defined in > the successor of RFC 3456. > > For example, extension type 65535 in the client hello could indicate an > extension with content > > struct { > ExtensionRestriction restriction_list<7..2^16-1>; > } RestrictedExtensions; > > where > > struct { > CipherSuite cipher_suites<2..2^16-1>; > Extension extension_list<1..2^16-1>; > } ExtensionRestriction; > > This would indicate that for each ExtensionRestriction, the listed > extensions apply to the listed ciphersuites only. (The server would > collect applicable extensions from those that appear directly in the > client_hello_extension_list field of ClientHello, and those that appear > in an ExtensionRestriction naming the respective ciphersuite.) > > With pluggable ciphersuites, use of the trusted_ca_keys extension would > likely be restricted to certain ciphersuites as well (if only one of the > plug-ins can make sense of a certain trusted CA certificate, then you > wouldn't want to offer it as a trusted authority for other > ciphersuites). And certainly the client_certificate_url extension would > be ciphersuite-specific. > > What do you (and others, of course) think of this approach? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jun 08 18:24:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg8yj-00050U-Kx; Wed, 08 Jun 2005 18:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg8yi-00050M-6l; Wed, 08 Jun 2005 18:24:52 -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 SAA25169; Wed, 8 Jun 2005 18:24:48 -0400 (EDT) Received: from smtp-out1.blueyonder.co.uk ([195.188.213.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg9JY-0004cC-Mu; Wed, 08 Jun 2005 18:46:25 -0400 Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out1.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Wed, 8 Jun 2005 23:24:21 +0100 Message-ID: <42A76FE4.9020009@blueyonder.co.uk> Date: Wed, 08 Jun 2005 23:23:32 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org, ietf@ietf.org References: <20050608171752.GA24676@tau.local> In-Reply-To: <20050608171752.GA24676@tau.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2005 22:24:21.0599 (UTC) FILETIME=[D1763EF0:01C56C78] X-Spam-Score: 2.1 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: Subject: [TLS] Ciphersuite specific extensions (Last Call comment on draft-ietf-tls-rfc3546bis) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tls@ietf.org, ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org [The following exchange on the TLS WG list , comments on and . Since the latter is in IETF-wide Last Call, it should have been cc:d to . As one of the authors of RFC3546bis, I'm correcting that oversight now. I'll make my own comments separately. Technically, the deadline for comments on RFC3546bis was 2005-06-02. However, note that the only motivation for RFC3546bis is to make a change needed to support draft-ietf-tls-ecc (allowing extensions to be defined by Informational RFCs). It was arguably an oversight to put RFC3546bis into Last Call before draft-ietf-tls-ecc.] Ari Medvinsky wrote: > I have a question about the elliptic curve extension. Lets say in the > hello msg the client sends several curves to the server (e.g., > secp256r1, secp384rl, secp384rl) and specifies that it supports several > ECC cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, > TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA). > > Does this mean that for each of the above cipher suites the client MUST > support every curve sent in the elliptic curve extension? (secp256r1, > secp384rl, secp384rl) [The answer is yes.] > Is there a way to specify via the proposed extension mechanism that for > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA the client only supports secp256r1 > curve and for the TLS_ECDHE_RSA_WITH_AES_256_WITH_AES_256_SHA the client > only supports secp384rl and secp384rl curves? Bodo Moeller replied: > No. Can you motivate a scenario where this would be needed? > I wouldn't think that such a requirement would come up frequently enough > to warrant the extra complication to the protocol for a more > fine-grained curve negotiation. > > There is, of course, always a possibility to work around this problem > with some protocol overhead, namely by using multiple connection > attempts with appropriately restricted parameters. (Also, with the > TrustedAuthority client hello extension, a client that supports only > secp256r1 for ECDSA may avoid being offered an EC server certificate > using secp384r1 if different CA names are used to issue EC > certificates.) Ari Medvinsky: > The scenario is if you have a pluggable/extensible TLS provider where > third parties can implement and plug in their own cipher suites. A > third party may be a hardware vendor that offers perf improvements for > the ecc cipher suites. Using my previous example, by default the TLS > provider might support: > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA with curves: secp256r1, secp384rl, > secp384rl > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA with curves: secp256r1, secp384rl, > secp384rl > > Lets say the third party plugs in: > TLS_ECDH_ECDSA_WITH_RC4_128_SHA with curves: sect163k1, sect163rl, > sect163r2 > > Given the way the current draft is defined, there is no way for me to > send all three cipher suites in the same message because there is no > intersection between the curves. > > I would suggest to modify the draft so that the new extension specifies > each ecc cipher suite (in the hello msg) with a list of supported > curves. E.g. info contained in the modified extension: > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: secp256r1, secp384rl, secp384rl > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: secp256r1, secp384rl, secp384rl > TLS_ECDH_ECDSA_WITH_RC4_128_SHA: sect163k1, sect163rl, sect163r2 Bodo Moeller: > I see. > > I have argued for a general mechanism for ciphersuite-dependent TLS > extensions in the past. That is, instead of having individual > specifications defining TLS extensions provide means of restricting > certain extensions to certain ciphersuites, it would make sense to have > a mechanism that can be applied to all extensions, preferably defined in > the successor of RFC 3456. > > For example, extension type 65535 in the client hello could indicate an > extension with content > > struct { > ExtensionRestriction restriction_list<7..2^16-1>; > } RestrictedExtensions; > > where > > struct { > CipherSuite cipher_suites<2..2^16-1>; > Extension extension_list<1..2^16-1>; > } ExtensionRestriction; > > This would indicate that for each ExtensionRestriction, the listed > extensions apply to the listed ciphersuites only. (The server would > collect applicable extensions from those that appear directly in the > client_hello_extension_list field of ClientHello, and those that appear > in an ExtensionRestriction naming the respective ciphersuite.) > > With pluggable ciphersuites, use of the trusted_ca_keys extension would > likely be restricted to certain ciphersuites as well (if only one of the > plug-ins can make sense of a certain trusted CA certificate, then you > wouldn't want to offer it as a trusted authority for other > ciphersuites). And certainly the client_certificate_url extension would > be ciphersuite-specific. > > What do you (and others, of course) think of this approach? Ari Medvinsky: > I like this idea, I think it covers well the ecc cipher suite/curve > mapping problem. Are you proposing then to modify the ecc draft to take > a dependency on the next rev of rfc3546? Bodo Moeller: > Yes. I hope that it is agreed to change the TLS Extensions > specification like this or similar. The TLS-ECC specification should > cite the successor of RFC 3546, thus resolving the issue. > > (Actually, the TLS-ECC specification already *has* to cite the > successor of RFC 3546 because TLS-ECC, if published as an > Informational RFC, couldn't define it's own TLS extensions > according to RFC 3546. draft-ietf-tls-rfc3546bis-##.txt > has weaker requirements so that an Informational RFC can > define new extensions.) > > Bodo > > [This time I am copying to the other authors of > draft-ietf-tls-rfc3546bis-01.txt as well, I'd really like to hear more > opinions!] -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 09 18:28:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgVW8-0006W9-Oj; Thu, 09 Jun 2005 18:28:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgVW7-0006W4-C8 for tls@megatron.ietf.org; Thu, 09 Jun 2005 18:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26019 for ; Thu, 9 Jun 2005 18:28:48 -0400 (EDT) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgVre-0004N8-Al for tls@ietf.org; Thu, 09 Jun 2005 18:51:07 -0400 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 91C38100A8; Thu, 9 Jun 2005 18:28:31 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21065-91; Thu, 9 Jun 2005 18:28:20 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 3EC3910084; Thu, 9 Jun 2005 18:28:20 -0400 (EDT) Received: from ce00182.certicom.com ([10.0.2.59]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005060918275965-5812 ; Thu, 9 Jun 2005 18:27:59 -0400 Received: from ce00182.certicom.com (localhost.certicom.com [127.0.0.1]) by ce00182.certicom.com (8.12.11/8.12.11) with ESMTP id j59MSIsw082350; Thu, 9 Jun 2005 18:28:18 -0400 (EDT) (envelope-from bminard@certicom.com) Received: (from bminard@localhost) by ce00182.certicom.com (8.12.11/8.12.11/Submit) id j59MGZhE082255; Thu, 9 Jun 2005 18:16:35 -0400 (EDT) (envelope-from bminard@certicom.com) X-Authentication-Warning: ce00182.certicom.com: bminard set sender to bminard@certicom.com using -f Date: Thu, 9 Jun 2005 18:16:35 -0400 From: Brian Minard To: Eric Rescorla Subject: Re: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Message-ID: <20050609221634.GN51022@certicom.com> References: <20050526150054.B5C7428441@sierra.rtfm.com> Mime-Version: 1.0 In-Reply-To: <20050526150054.B5C7428441@sierra.rtfm.com> User-Agent: Mutt/1.4.2.1i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 06/09/2005 06:27:59 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 06/09/2005 06:28:00 PM, Serialize complete at 06/09/2005 06:28:00 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Hi, On Thu, May 26, 2005 at 07:37:31AM -0700, Eric Rescorla wrote: > G. Chudov has just posted draft-chudov-cryptopro-tlsprfneg-00.txt, > which describes a scheme for PRF negotiation for TLS. The major > motivation for this is to enable GOST use in TLS, because for > regulatory reasons GOST cannot be used with non-GOST hash functions. > This would be a major technical change to TLS. > > Is this work that the TLS WG wants to take on? Introducing alternative PRFs capable of using the new hash functions (SHA-224 and up) is worthwhile. My thinking is in line with Pasi's on the issue of PRF negotiation. Thanks, Brian _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 10 01:53:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgcSj-0001hJ-Qu; Fri, 10 Jun 2005 01:53:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgcSh-0001h7-QK; Fri, 10 Jun 2005 01:53:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25456; Fri, 10 Jun 2005 01:53:43 -0400 (EDT) Received: from chico.itss.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgcoG-0007zG-1X; Fri, 10 Jun 2005 02:16:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id BEB093542C; Fri, 10 Jun 2005 17:53:29 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24960-20; Fri, 10 Jun 2005 17:53:29 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 72F0634671; Fri, 10 Jun 2005 17:53:29 +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 4D39C37747; Fri, 10 Jun 2005 17:53:29 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DgcSU-0002SZ-00; Fri, 10 Jun 2005 17:53:34 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hartmans-ietf@mit.edu, tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-psk and identity In-Reply-To: Message-Id: Date: Fri, 10 Jun 2005 17:53:34 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 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 Sam Hartman writes: >As one of the people reviewing the draft, I have two questions I'd like to >ask. Apologies for making this a bit of an RTFM reply, but this was discussed at some length on the list (so it's really an RTFL). Rather than rehashing it (and because I argued against it so I'm not really in a position to be too objective) see http://www.imc.org/ietf-tls/mail-archive/maillist.html, the thread is "ACTION:draft-ietf-tls-psk-03.txt". http://www.imc.org/ietf-tls/mail-archive/msg04402.html starts the debate. There are also earlier comments in "TLS-PSK WGLC comments", e.g. http://www.imc.org/ietf-tls/mail-archive/msg04389.html, and in "WG Last Call for draft-ietf-tls-psk-02.txt" at e.g. http://www.imc.org/ietf-tls/mail-archive/msg04374.html. Uhh, so as that collection shows, we really have thought about it :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jun 10 07:40:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dghrw-00072j-MX; Fri, 10 Jun 2005 07:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dghru-000725-UW; Fri, 10 Jun 2005 07:40:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10920; Fri, 10 Jun 2005 07:40:09 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgiDZ-0004XN-CO; Fri, 10 Jun 2005 08:02:33 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5ABbfi3032047; Fri, 10 Jun 2005 14:37:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jun 2005 14:40:07 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Jun 2005 14:40:06 +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] draft-ietf-tls-psk and identity Date: Fri, 10 Jun 2005 14:40:06 +0300 Message-ID: Thread-Topic: [TLS] draft-ietf-tls-psk and identity Thread-Index: AcVtMOZrKvGJ97a4QjC4pyOHn6bxNAAgButQ To: , X-OriginalArrivalTime: 10 Jun 2005 11:40:06.0432 (UTC) FILETIME=[26035A00:01C56DB1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: 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 Sam Hartman wrote: > Hi. The PSK draft is now before the IESG for final approval. >=20 > As one of the people reviewing the draft, I have two questions > I'd like to ask. > > The first is why is the identity not labeled. In other cases > where we've had a lot of name spaces, we have chosen to label > the identity with which name space it comes from. Why did you > choose to just have an opaque string? How frequent will it be > that identities from one namespace might be confused with > identities from another namespace. It seems like for example > NAIs and email addresses might be confused. These seem like > they might both be commonly used. Other identities look > similar to email addresses. > > What would the costs of labeling be? Would it be worth the cost? As Peter already responded, labeling the identity with its namespace/type was discussed several times during the design=20 process, as was using different encodings for different=20 namespaces (IPv4 addresses as four octets, X.500 DNs as=20 DER-encoded, etc.).=20 There were arguments both for and against labeling. I've summarized below some of these arguments (not totally objectively, as I supported the alternatively that was=20 chosen -- but I think it's fair to say that both alternatives=20 have good arguments for them, so the choice is some kind of=20 trade-off). The choice was largely motivated by the question "given two administrators who agree on what identity and key to use, which design is going to result in less interoperability problems?" There were several reasons that seemed to suggest the answer would be "no labels": - If labels are used, different implementations will support=20 different sets of namespaces. This certainly increases the=20 chances of problems, even though they can be reduced by=20 specifying which namespaces implementations MUST/SHOULD/MAY=20 support. - It is almost certainly necessary to have a label for opaque=20 identities (like ID_KEY_ID in IKEv2) since we can't anticipate=20 all possible namespaces. Basically, this opaque namespace inherits all the weaknesses in the "no labels" approach or even worse (e.g. IKEv2 leaves ID_KEY_ID as vendor-specific octet stream, so don't even know whether it's supposed to=20 be ASCII, let alone UTF-8 or stringprep-processed) - Labels are one more thing the endpoints need to agree on: for instance, should "joe@example.com" be labeled as a NAI, email address, opaque, or something else? Or is "steve.jobs"=20 a NAI, FQDN, opaque, or something else? - The confusion between namespaces was not considered important, e.g., it was not considered realistic that a single TLS=20 server would have different keys for the NAI "steve.jobs"=20 and FQDN "steve.jobs".=20 - Labels can increase implementation complexity, especially if different namespaces use different encodings. There are certainly other valid questions you could ask, and arguments for using labels and different encodings: - Some identity types are "nicer" to encode in some other=20 format than UTF-8 string (e.g. IPv6 address as 16 octets, X.500 DNs as DER) - Some have several different string formats (e.g. "::1" vs=20 "0:0:0:0:0:0:0:1" for IPv6 addrsses). This is one more thing the endpoints have to agree about (but if at least=20 one of the endpoints allows entering arbitrary strings in the management interface, the administrators can simply=20 agree on this: it's not possible that the other endpoint would not support this namespace type or encoding). - Identities may have more semantics than just selecting the right key to use (e.g. authenticating with key identified=20 as "joe@example.com" allows you to access email stored=20 in /var/mail/joe). However, this are largely a local issue,=20 and does not have to be visible in the on-the-wire encoding in TLS protocol. - Identities may come from somewhere else than human-operated management interfaces. (But this is probably the same place=20 the keys come from; so we're talking about some key distribution=20 system here... and presumably that system anyway specifies in more detail what identities look like in that system.) How much weight each of these arguments carries depends a lot on=20 what kind of scenario you have in your mind (e.g. administrators configuring things manually in some management interface vs.=20 something else). > Secondly, I'm concerned about internationalization. Scetion > 5.4 says that an appropriate stringprep profile should be used > but does not say what this profile is. >=20 > The PSK draft seems to want client management interface to be > able to take arbitrary identity forms without knowing about > these identity forms. However the preparation and > normalization strategy the IETF has adopted assume that the > entity processing an ID needs to apply ID-form-specific > normalization to that ID. > What alternatives have been considered for > internationalization? Who has reviewed the > internationalization concerns of this draft? Different stringprep profiles are appropriate for different identity types (e.g Nameprep for FQDN, SASLprep for usernames). No formal review of the i18n concerns has been done. > Would things work better if the client management interface > preserved the ID and never normalized, requiring that the > server use some stringprep (and possibly other) normalization/ > canonicalization after determing the appropriate ID form? =20 I like your suggestion. The important part is that stringprep processing is done before the identity is used, and the server knows better how it's going to use the identity (e.g. if the identity is FQDN, the lookup to find the right key might be case-insensitive, so it'll do some processing anyway). How about changing this text in 5.4: o Entering PSK identities consisting of up to 128 printable Unicode characters. Supporting as wide character repertoire and as long identities as feasible is RECOMMENDED, as is processing the character string with an appropriate stringprep [10] profile. to this: o Entering PSK identities consisting of up to 128 printable Unicode characters. Supporting as wide character repertoire and as long identities as feasible is RECOMMENDED. And adding this text just before Section 5.1? This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives. For instance, if the identity is a domain name, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that before looking up the key, the server processes the PSK identity with a stringprep profile [10] appropriate for the identity in question (such as Nameprep [NAMEPREP] for domain names or SASLprep for usernames [SASLPREP]). On the other hand, it's not clear that this would be a very big improvement, so I'm fine with leaving the text as is as well... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jun 16 19:08:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj3T2-0008Ib-KT; Thu, 16 Jun 2005 19:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuBe-00063I-B1; Mon, 13 Jun 2005 15:01:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10082; Mon, 13 Jun 2005 15:01:28 -0400 (EDT) Received: from stratton-three-sixty-six.mit.edu ([18.187.6.111] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhuXy-0003e3-5q; Mon, 13 Jun 2005 15:24:35 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 55783E0065; Mon, 13 Jun 2005 15:01:12 -0400 (EDT) To: Subject: Re: [TLS] draft-ietf-tls-psk and identity References: From: Sam Hartman Date: Mon, 13 Jun 2005 15:01:12 -0400 In-Reply-To: (Pasi Eronen's message of "Fri, 10 Jun 2005 14:40:06 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Thu, 16 Jun 2005 19:08:10 -0400 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 I think your proposed text is a significant improvement. If the working group is OK with this proposed change I'd be happy to clear my discuss. You have certainly convinced me you have carefully considered the issue of identity tagging. There is one minor error in your text: the nameprep profile of stringprep is applied to domain name components not domain names. How about the following as a replacement new paragraph: This document does not specify how the server stores the keys and identities, or how exactly it finds the key corresponding to the identity it receives. For instance, if the identity is a domain name, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that before looking up the key, the server processes the PSK identity with a stringprep profile [10] appropriate for the identity in question (such as Nameprep [NAMEPREP] for components of domain names or SASLprep for usernames [SASLPREP]). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jun 19 11:42:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk1wd-0006t1-On; Sun, 19 Jun 2005 11:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dk1wc-0006sw-Fy for tls@megatron.ietf.org; Sun, 19 Jun 2005 11:42:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14533 for ; Sun, 19 Jun 2005 11:42:43 -0400 (EDT) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dk2K8-0007VZ-Sp for tls@ietf.org; Sun, 19 Jun 2005 12:07:06 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 05B8D1E8C54; Sun, 19 Jun 2005 08:42:28 -0700 (PDT) To: Bodo Moeller References: <20050607220227.GA11744@tau.local> From: EKR Date: Sun, 19 Jun 2005 08:42:27 -0700 In-Reply-To: <20050607220227.GA11744@tau.local> (Bodo Moeller's message of "Tue, 7 Jun 2005 16:02:27 -0600") Message-ID: <86oea2s68s.fsf@raman.networkresonance.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ari Medvinsky , Jeff Spelman , tls@ietf.org, Joshua Ball , Virginia Robbins , Cristian Ilac Subject: [TLS] Re: Ciphersuite specific extensions 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, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote: > >> The scenario is if you have a pluggable/extensible TLS provider where >> third parties can implement and plug in their own cipher suites. > > I see. > > I have argued for a general mechanism for ciphersuite-dependent TLS > extensions in the past. That is, instead of having individual > specifications defining TLS extensions provide means of restricting > certain extensions to certain ciphersuites, it would make sense to > have a mechanism that can be applied to all extensions, preferably > defined in the successor of RFC 3456. [...] > What do you (and others, of course) think of this approach? This is a big change and I don't want to make this a gating factor for advancing the ECC draft. WG members: I'd like to come to some resolution on the basic issue of whether curves should be negotiable on a per-cipher-suite basis. My intuition is that the case Ari mentions is kind of a corner case--most SSL/TLS implementations aren't assembled pluggably like this. But, I'm happy to listen to arguments that I'm wrong here... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 20 13:34:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQA3-00072H-Fq; Mon, 20 Jun 2005 13:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQA1-000729-6l for tls@megatron.ietf.org; Mon, 20 Jun 2005 13:34:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21636 for ; Mon, 20 Jun 2005 13:34:12 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQXk-0007w9-14 for tls@ietf.org; Mon, 20 Jun 2005 13:58:46 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 10:33:57 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 10:33:56 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 10:33:56 -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, 20 Jun 2005 10:34:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jun 2005 10:33:51 -0700 Message-ID: Thread-Topic: Ciphersuite specific extensions thread-index: AcV05YGeE7ZtgMriReS2u50zY2LaUAA1aaQg From: "Ari Medvinsky" To: "EKR" , "Bodo Moeller" X-OriginalArrivalTime: 20 Jun 2005 17:34:03.0367 (UTC) FILETIME=[4057F770:01C575BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: Joshua Ball , Jeff Spelman , Virginia Robbins , tls@ietf.org, Cristian Ilac Subject: [TLS] RE: Ciphersuite specific extensions 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 agree that relying on a general purpose mech. to be defined in the successor of RFC 3456 may introduce a long delay before the ECC draft is finalized into an RFC. However, allowing third parties to plug in their cipher suites is an important scenario as it facilitates security vendors to provide a significant value add (in terms of perf. + cipher suites that adhere to local crypto standards). =20 It is possible to address the cipher suite/curve mapping directly in the ECC draft (without dependencies on a general purpose mech) as I suggested in the earlier msg. Thanks, Ari Medvinsky Program Manager Windows Security -----Original Message----- From: EKR [mailto:ekr@networkresonance.com]=20 Sent: Sunday, June 19, 2005 8:42 AM To: Bodo Moeller Cc: Ari Medvinsky; Jeff Spelman; tls@ietf.org; Joshua Ball; Virginia Robbins; Cristian Ilac Subject: Re: Ciphersuite specific extensions Bodo Moeller writes: > On Tue, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote: > >> The scenario is if you have a pluggable/extensible TLS provider where >> third parties can implement and plug in their own cipher suites. > > I see. > > I have argued for a general mechanism for ciphersuite-dependent TLS=20 > extensions in the past. That is, instead of having individual=20 > specifications defining TLS extensions provide means of restricting=20 > certain extensions to certain ciphersuites, it would make sense to=20 > have a mechanism that can be applied to all extensions, preferably=20 > defined in the successor of RFC 3456. [...] > What do you (and others, of course) think of this approach? This is a big change and I don't want to make this a gating factor for advancing the ECC draft.=20 WG members: I'd like to come to some resolution on the basic issue of whether curves should be negotiable on a per-cipher-suite basis. My intuition is that the case Ari mentions is kind of a corner case--most SSL/TLS implementations aren't assembled pluggably like this. But, I'm happy to listen to arguments that I'm wrong here... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 20 13:59:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQYV-0001po-4r; Mon, 20 Jun 2005 13:59:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQYT-0001pj-U8 for tls@megatron.ietf.org; Mon, 20 Jun 2005 13:59:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24101 for ; Mon, 20 Jun 2005 13:59:28 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQwD-0000Bc-Vx for tls@ietf.org; Mon, 20 Jun 2005 14:24:02 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.30.54] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1DkQYK3wKE-0005LR; Mon, 20 Jun 2005 19:59:20 +0200 Received: by tau.local (Postfix, from userid 500) id 6C8FE3627E; Mon, 20 Jun 2005 11:59:16 -0600 (MDT) Date: Mon, 20 Jun 2005 11:59:16 -0600 From: Bodo Moeller To: Ari Medvinsky Message-ID: <20050620175916.GA23029@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: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Jeff Spelman , Joshua Ball , Virginia Robbins , Cristian Ilac , tls@ietf.org Subject: [TLS] Re: Ciphersuite specific extensions 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, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: >>> I have argued for a general mechanism for ciphersuite-dependent TLS >>> extensions in the past. That is, instead of having individual >>> specifications defining TLS extensions provide means of restricting >>> certain extensions to certain ciphersuites, it would make sense to >>> have a mechanism that can be applied to all extensions, preferably >>> defined in the successor of RFC 3456. >> This is a big change and I don't want to make this a gating factor for >> advancing the ECC draft. >> >> WG members: I'd like to come to some resolution on the basic issue of >> whether curves should be negotiable on a per-cipher-suite basis. >> My intuition is that the case Ari mentions is kind of a corner >> case--most SSL/TLS implementations aren't assembled pluggably like this. >> But, I'm happy to listen to arguments that I'm wrong here... > I agree that relying on a general purpose mech. to be defined in the > successor of RFC 3456 may introduce a long delay before the ECC draft is > finalized into an RFC. However, allowing third parties to plug in their > cipher suites is an important scenario as it facilitates security > vendors to provide a significant value add (in terms of perf. + cipher > suites that adhere to local crypto standards). > > It is possible to address the cipher suite/curve mapping directly in the > ECC draft (without dependencies on a general purpose mech) as I > suggested in the earlier msg. I think doing this directly in the TLS-ECC specification is not the best option because - this would mean reinventing the wheel when other ciphersuites need similar mechanisms, adding some complexity to each of the affected specifications individually; and - it already fails to take into account trusted_ca_keys (an extension defined in RFC 3456, which appears destined for ciphersuite-dependent use in the context of plug-ins). Let me point out that one alternative for how to proceed is to pass the TLS Extensions and TLS-ECC specifications without provisions for ciphersuite-dependent negotiation, but standardize a TLS extension for ciphersuite-dependent TLS extensions later in a separate document ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't be made a "MUST" then, so for best interoperability ciphersuite-dependent TLS extensions could be defined so as to allow them to extend the list of ciphersuites given in the "cipher_suites filed" of the Client Hello message -- i.e., clients can make ciphersuites invisible from servers that do not support TLS-CD-Ext. This will keep the basic protocols simple, but optionally provide the desired flexibility. At first, while TLS-CD-Ext is used only in the context of TLS-ECC, the implementation overhead might be slightly higher for putting this directly into the TLS-ECC specification (which would, however, omit ciphersuite-dependent use of the trusted_ca_keys extension); but as soon as some other set of ciphersuites has use for TLS-CD-Ext, this more general approach should become easier to handle. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 20 14:24:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQwI-0004vb-8F; Mon, 20 Jun 2005 14:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkQwG-0004vW-Gy for tls@megatron.ietf.org; Mon, 20 Jun 2005 14:24:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26027 for ; Mon, 20 Jun 2005 14:24:03 -0400 (EDT) Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRK1-0000pU-23 for tls@ietf.org; Mon, 20 Jun 2005 14:48:38 -0400 Received: from simon ([70.51.158.237]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050620182351.HQQF19894.tomts20-srv.bellnexxia.net@simon>; Mon, 20 Jun 2005 14:23:51 -0400 From: "Simon Blake-Wilson" To: "'EKR'" , "'Bodo Moeller'" Subject: RE: [TLS] Re: Ciphersuite specific extensions Date: Mon, 20 Jun 2005 14:23:21 -0400 Message-ID: <008e01c575c5$23ac51f0$0200a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <86oea2s68s.fsf@raman.networkresonance.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 'Ari Medvinsky' , 'Jeff Spelman' , tls@ietf.org, 'Joshua Ball' , 'Virginia Robbins' , '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: , Content-Type: multipart/mixed; boundary="===============0743196568==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0743196568== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008A_01C575A3.9C3A6980" This is a multi-part message in MIME format. ------=_NextPart_000_008A_01C575A3.9C3A6980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm concerned that defining cipher-suite specific extensions is headed towards "over specification". It seems like the examples are unusual enough that performing two handshakes, one with the "plugged cipher suites" and a second if necessary with the "native cipher suites" might be a reasonable solution. Just my 2c. Of course as an author of both drafts I'm baised towards minimal changes! Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of EKR > Sent: Sunday, June 19, 2005 11:42 AM > To: Bodo Moeller > Cc: Ari Medvinsky; Jeff Spelman; tls@ietf.org; Joshua Ball; > Virginia Robbins; Cristian Ilac > Subject: [TLS] Re: Ciphersuite specific extensions > > > Bodo Moeller writes: > > > On Tue, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote: > > > >> The scenario is if you have a pluggable/extensible TLS > provider where > >> third parties can implement and plug in their own cipher suites. > > > > I see. > > > > I have argued for a general mechanism for ciphersuite-dependent TLS > > extensions in the past. That is, instead of having individual > > specifications defining TLS extensions provide means of restricting > > certain extensions to certain ciphersuites, it would make sense to > > have a mechanism that can be applied to all extensions, preferably > > defined in the successor of RFC 3456. > [...] > > What do you (and others, of course) think of this approach? > > This is a big change and I don't want to make this a gating > factor for advancing the ECC draft. > > WG members: I'd like to come to some resolution on the basic > issue of whether curves should be negotiable on a > per-cipher-suite basis. My intuition is that the case Ari > mentions is kind of a corner case--most SSL/TLS > implementations aren't assembled pluggably like this. But, > I'm happy to listen to arguments that I'm wrong here... > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_008A_01C575A3.9C3A6980 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA2MjAxODIzMjFaMCMGCSqGSIb3 DQEJBDEWBBQu+dXURBSbxcAH+qjsjoQtz2w48jBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgDUc1fgP2HO6zlQPVae2vWXJOAFoRT7/rJyUyLn4VW8R9KKlzwNP18x1 b6/GLM0sq+ViRdVKyUPpKmD2Ks8bSkjGomXUYllsUi/kMahmJUtaS6gj1Ih8VPw04+/rTSmKRWz7 9eYcoh2AAneOuEpNG4OHMYJpn+HPmzkd7c0kP59dAAAAAAAA ------=_NextPart_000_008A_01C575A3.9C3A6980-- --===============0743196568== 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 --===============0743196568==-- From tls-bounces@lists.ietf.org Mon Jun 20 15:00:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRV6-0000r2-PS; Mon, 20 Jun 2005 15:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkRV4-0000qO-TZ for tls@megatron.ietf.org; Mon, 20 Jun 2005 15:00:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28405 for ; Mon, 20 Jun 2005 15:00:01 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkRsq-0001g1-BJ for tls@ietf.org; Mon, 20 Jun 2005 15:24:36 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 11:59:50 -0700 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 11:59:49 -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.1830); Mon, 20 Jun 2005 11:59:49 -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, 20 Jun 2005 11:59:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Re: Ciphersuite specific extensions Date: Mon, 20 Jun 2005 11:59:44 -0700 Message-ID: Thread-Topic: [TLS] Re: Ciphersuite specific extensions thread-index: AcV1xTTMi0vXnxhaQfizNyQyXGgSnwAA0zRw From: "Ari Medvinsky" To: "Simon Blake-Wilson" , "EKR" , "Bodo Moeller" X-OriginalArrivalTime: 20 Jun 2005 18:59:56.0945 (UTC) FILETIME=[401D9010:01C575CA] X-Spam-Score: 2.0 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: Joshua Ball , Jeff Spelman , Virginia Robbins , tls@ietf.org, 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 Simon Blake-Wilson writes: >>>> I'm concerned that defining cipher-suite specific extensions is headed >>>> towards "over specification". Hmmm ... The ECC draft as it stands, already introduces a new ECC specific extension message, so according to the above view it is already "over specified". =20 I am advocating that since the draft already defines a new curve extension msg, lets make this message explicit enough to identify which curve pertains to which ECC cipher suite. Ari Medvinsky Program Manager Windows Security -----Original Message----- From: Simon Blake-Wilson [mailto:sblakewilson@bcisse.com]=20 Sent: Monday, June 20, 2005 11:23 AM To: 'EKR'; 'Bodo Moeller' Cc: Ari Medvinsky; Jeff Spelman; tls@ietf.org; Joshua Ball; Virginia Robbins; Cristian Ilac Subject: RE: [TLS] Re: Ciphersuite specific extensions I'm concerned that defining cipher-suite specific extensions is headed towards "over specification". It seems like the examples are unusual enough that performing two handshakes, one with the "plugged cipher suites" and a second if necessary with the "native cipher suites" might be a reasonable solution. Just my 2c. Of course as an author of both drafts I'm baised towards minimal changes! Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of EKR > Sent: Sunday, June 19, 2005 11:42 AM > To: Bodo Moeller > Cc: Ari Medvinsky; Jeff Spelman; tls@ietf.org; Joshua Ball; Virginia=20 > Robbins; Cristian Ilac > Subject: [TLS] Re: Ciphersuite specific extensions > > > Bodo Moeller writes: > > > On Tue, Jun 07, 2005 at 01:27:37PM -0700, Ari Medvinsky wrote: > > > >> The scenario is if you have a pluggable/extensible TLS > provider where > >> third parties can implement and plug in their own cipher suites. > > > > I see. > > > > I have argued for a general mechanism for ciphersuite-dependent TLS=20 > > extensions in the past. That is, instead of having individual=20 > > specifications defining TLS extensions provide means of restricting=20 > > certain extensions to certain ciphersuites, it would make sense to=20 > > have a mechanism that can be applied to all extensions, preferably=20 > > defined in the successor of RFC 3456. > [...] > > What do you (and others, of course) think of this approach? > > This is a big change and I don't want to make this a gating factor for > advancing the ECC draft. > > WG members: I'd like to come to some resolution on the basic issue of=20 > whether curves should be negotiable on a per-cipher-suite basis. My=20 > intuition is that the case Ari mentions is kind of a corner case--most > SSL/TLS implementations aren't assembled pluggably like this. But, I'm > happy to listen to arguments that I'm wrong here... > > -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 Wed Jun 22 15:50:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEd-0007k0-5X; Wed, 22 Jun 2005 15:50:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlBEa-0007il-1X for tls@megatron.ietf.org; Wed, 22 Jun 2005 15:50:04 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23248 for ; Wed, 22 Jun 2005 15:50:01 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlBEX-0004Xh-VQ; Wed, 22 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Jun 2005 15:50:01 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-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@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-09.txt Pages : 19 Date : 2005-6-22 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-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-psk-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-psk-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-6-22145237.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-22145237.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 Jun 23 15:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXi9-0004WL-B8; Thu, 23 Jun 2005 15:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXi8-0004WA-76 for tls@megatron.ietf.org; Thu, 23 Jun 2005 15:50:04 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21202 for ; Thu, 23 Jun 2005 15:50:02 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlXi5-0008Hf-Rv; Thu, 23 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Jun 2005 15:50:01 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc2246-bis-13.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 : The TLS Protocol Version 1.1 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc2246-bis-13.txt Pages : 91 Date : 2005-6-23 This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-13.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-rfc2246-bis-13.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-rfc2246-bis-13.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-6-23145449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc2246-bis-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc2246-bis-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-23145449.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 Fri Jun 24 15:00:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltPb-0004KS-0b; Fri, 24 Jun 2005 15:00:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DltPX-0004Ji-EU for tls@megatron.ietf.org; Fri, 24 Jun 2005 15:00:19 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03129 for ; Fri, 24 Jun 2005 15:00:18 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DltPT-0001Q8-BC; Fri, 24 Jun 2005 15:00:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 24 Jun 2005 15:00:15 -0400 Cc: Internet Architecture Board , tls mailing list , RFC Editor Subject: [TLS] Protocol Action: 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)' to Proposed Standard 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 The IESG has approved the following document: - 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) ' as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-09.txt Technical Summary This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared symmetric keys. 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. Working Group Summary The TLS Working Group reached consensus on this document. Protocol Quality This document was reviewed by Russ Housley for the IESG. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 27 00:35:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmlLY-00071x-2O; Mon, 27 Jun 2005 00:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmlLV-00071s-QP for tls@megatron.ietf.org; Mon, 27 Jun 2005 00:35:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15537 for ; Mon, 27 Jun 2005 00:35:42 -0400 (EDT) Received: from cdc-info.cdc.informatik.tu-darmstadt.de ([130.83.167.3] helo=mail.cdc.informatik.tu-darmstadt.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmlkZ-0006UI-Nf for tls@ietf.org; Mon, 27 Jun 2005 01:01:41 -0400 Received: from cdc-ultra5.cdc.informatik.tu-darmstadt.de (cdc-ultra5 [130.83.167.9]) by mail.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id F20922C97; Mon, 27 Jun 2005 06:35:31 +0200 (MET DST) Received: (from moeller@localhost) by cdc-ultra5.cdc.informatik.tu-darmstadt.de (8.11.7p1+Sun/8.11.7) id j5R4ZV118176; Mon, 27 Jun 2005 06:35:31 +0200 (MEST) Date: Mon, 27 Jun 2005 06:35:30 +0200 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] draft-chudov-cryptopro-tlsprfneg-00.txt Message-ID: <20050627063530.A18120@cdc.informatik.tu-darmstadt.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pasi.Eronen@nokia.com on Mon, Jun 06, 2005 at 02:42:48PM +0300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Mon, Jun 06, 2005 at 02:42:48PM +0300, Pasi.Eronen@nokia.com wrote: > I fully agree: a ciphersuite cannot (and definitely should not) > just decide by itself to change that part of RFC 2246. But if > we (TLS WG) decide to work on alternative PRFs, we will anyway > need a document that updates this part of RFC 2246/2246bis > somehow. > > The main alternatives seem to be defining PRF to be a property > that can be negotiated separately from the ciphersuite (and thus > we need a new negotiation mechanism, as proposed in your draft), > or defining PRF to be associated with the ciphersuite (so we can > use the existing ciphersuite negotiation, as I proposed in my > previous email). Both work, but both also change RFC 2246; > IMHO the latter approach might be a bit simpler... My take on this would be that explicit PRF negotiation is probably not worth the protocol complication. The Hash/PRF negotiation ID already points out the potential danger of rollback attacks if a server allows too much flexibility. Sometimes, in rare cases, the standard TLS approach does quite not work for the specific needs of an individual ciphersuite (e.g. for the pre-shared key setting). The best way here is, in my opinion, to format the data in such a way that it can be fed into the standard TLS PRF. Actually I don't really like the current TLS PRF design too much. But the correct upgrade path to me is to replace the PRF in a future version of the TLS protocol, and to do so in an identical way for all ciphersuites. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jun 27 14:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyYV-00013J-5k; Mon, 27 Jun 2005 14:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmyYS-00012V-GI; Mon, 27 Jun 2005 14:42:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22937; Mon, 27 Jun 2005 14:41:58 -0400 (EDT) Received: from smtp-out6.blueyonder.co.uk ([195.188.213.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmyxd-0002XI-Px; Mon, 27 Jun 2005 15:08:03 -0400 Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Jun 2005 19:42:32 +0100 Message-ID: <42C0486C.3010301@blueyonder.co.uk> Date: Mon, 27 Jun 2005 19:41:48 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iesg@ietf.org References: <200562793918.342771@bbprime> In-Reply-To: <200562793918.342771@bbprime> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 18:42:32.0215 (UTC) FILETIME=[FA4CAA70:01C57B47] X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: ietf-pkix@imc.org, ietf@ietf.org, tls@ietf.org Subject: [TLS] Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk 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 Re: http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-03.txt Dave Crocker wrote: >> - 'Required functions of User Interface for the Internet X.509 Public Key >> Infrastructure ' >> as an Informational RFC > > RFC document titles should not carry language that states or implies that their > contents mandate conformans. > > Hence, the word "Required" should be removed from this document title. > > The issue is only exacerbated by the fact that it is seeking non-standards > status. Also, the document has received no review in Working Groups for which it is relevant, such as TLS and PKIX (there are references to its existence in the PKIX archives, but no discussion). It seems to have been in desperate need of such review: # Compatibility shall be accomplished for using one certificate to many # PKI applications. Generally, PKI application such as the Internet # Banking or E-mail application defines the user's certificate and # private key location by their own way. Thereby, when using those # applications, users are at a loss whenever receiving a question where # their certificates are. Most users do not know the answer, and they # want to use different PKI programs with their own certificate without # answering the question. It comes true as a certificate sharing # function and transfer function that mainly aim for increasing # certificate compatibility, which benefits the user's convenience. The grammar here, and elsewhere in the document is bad enough to obscure the meaning. More importantly, the argument given is inadequate motivation for "using one certificate [for] many PKI applications": - the described usability problem could be solved even with multiple certificates - it is not clear that, in the situations where user certificates are typically used, implicitly selecting a certificate rather than prompting the user to select one would be a good thing - there are privacy implications of using a certificate for multiple applications, which are not discussed in the document - different relying parties may have requirements, for example on the algorithms used and on optional cert fields, that cannot be met by a single certificate - using a single certificate ensures that loss or compromise of one private key necessarily implies loss or compromise of the user's identity for many different applications. (This problem is not solved just by using multiple certificates, but at least it is not precluded from being solved.) # For example, a common storage location of a user's certificate and # private key in HARD DISK driver of different operating systems can be # assigned to be: # # - MS Windows : C:Program Files/IETF/PKIX # - Linux/Unix : (User Account)/IETF/PKIX # - Mac OS X : (Hard disk label):Library/IETF/PKIX Is this a joke? It ignores, at least, the fact that MS Windows and Mac OS X are multi-user operating systems, and existing conventions for where user certificates are stored. # Lastly, the user interface shall contain certificate management # commands as followings; # # - Integrity verification function of trust anchor : defined in # [2.2.1] # - Import and export : defined in [2.1.2] # - Certificate verification : when a user wants to know whether # his or her certificate is valid or not Valid for what purpose? User software *cannot* validate the cert in a way that is guaranteed to match the validation result of any relying party; it doesn't have enough information. The Security Considerations section is totally inadequate. As an example, consider this statement: # The PKI client software must provide a secure method to update PKI # client software and trust anchor's certificate. This document defines # it as automatic update function, which makes user involvement # minimized. which has security considerations that are left entirely unaddressed. (Just saying "a secure method" doesn't mean anything: How should it be secured? Who should be trusted? What happens if keys are compromised?) In summary, the document is not of adequate quality for publication as an Informational RFC. It is not clear that anything useful is salvageable from it. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls