From tls-bounces@lists.ietf.org Fri May 04 08:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjwz3-0007xx-7j; Fri, 04 May 2007 08:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjwz1-0007xo-Ke for tls@ietf.org; Fri, 04 May 2007 08:33:59 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjwz0-0004SL-6y for tls@ietf.org; Fri, 04 May 2007 08:33:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l44CXdIG022521; Fri, 4 May 2007 15:33:56 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 15:33:47 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 15:33:47 +0300 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] Will CAs decide server signing algorithms in TLS 1.2? Date: Fri, 4 May 2007 15:33:47 +0300 Message-ID: In-Reply-To: <87slao8y4b.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Will CAs decide server signing algorithms in TLS 1.2? Thread-Index: AceHMSJNWGLD3R6RQPacGAMdVBq26wHFnhyg References: <87slao8y4b.fsf@mocca.josefsson.org> From: To: , X-OriginalArrivalTime: 04 May 2007 12:33:47.0196 (UTC) FILETIME=[7601AFC0:01C78E48] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: tls-bounces@lists.ietf.org Hi Simon, This issue was discussed in Prague, and I think the conclusion was that the current text needs to be changed. In other words: if the client tells it supports RSA+SHA256, the server can use it even if the CA used RSA+SHA1 to sign the server cert (unless the certificate has an extension or something=20 explicitly prohibits it -- there's some work in PKIX that may be relevant). Best regards, Pasi > -----Original Message----- > From: ext Simon Josefsson [mailto:simon@josefsson.org]=20 > Sent: 25 April, 2007 14:58 > To: tls@ietf.org > Subject: [TLS] Will CAs decide server signing algorithms in TLS 1.2? >=20 > The Signature structure has changed, and the current text in section > 7.4.3 says: >=20 > If the SignatureAlgorithm being used to sign the ServerKeyExchange > message is DSA, the hash function used MUST be SHA-1. If the > SignatureAlgorithm it must be the same hash function used in the > ^^^^^^^^^^^^^^^^ > signature of the server's certificate (found in the Certificate) > message. This algorithm is denoted Hash below. Hash.length is the > length of the output of that algorithm. >=20 > I can't parse the second sentence here. What is the intention here? >=20 > I'm assuming that the intention is to say that the SignatureAlgorithm > must be the same as the signing algorithm in the server certificate. > > It seems weird that the CA who signs the server certificate will > implicitly decide which signature algorithm is used inside TLS=20 > between all servers and clients. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 04 11:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzhz-0008BL-AM; Fri, 04 May 2007 11:28:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzhy-0008BG-Mq for tls@ietf.org; Fri, 04 May 2007 11:28:34 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjzhx-00029v-Db for tls@ietf.org; Fri, 04 May 2007 11:28:34 -0400 Received: by ug-out-1314.google.com with SMTP id 72so559933ugd for ; Fri, 04 May 2007 08:28:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EYWSIoZkIqeD5wqc+jA6iNZgCoqNnW9JYzBgBF7y+1xuXwHJfQWCzvyYI6wmJuVBV90pk9pVyv06lfWLCSdcugujhBq//3SoSfwHW6BYuyGDHNI5k0ewCVvXLIV74N6CzH35R11RQhvNhwkjncg5ifbGH+WeMgMtxPOq+CHwOds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cqF2m9oGrs5j9NSOLrq4vWbgWLHpTqivhBiUiPRVt1gDKUYAtyAX82b0mAlELGQSRASr78CI0cap6RZDTtyvvgfAKoXegL1F0B7jK+6tPA8awgrZEDIPMWYoq+YO6Fz+cM8McMbiEhNNL7zUsg0deAdV/7ZuAsSSqXO6ZdS559U= Received: by 10.82.123.16 with SMTP id v16mr6704252buc.1178292512470; Fri, 04 May 2007 08:28:32 -0700 (PDT) Received: by 10.82.187.15 with HTTP; Fri, 4 May 2007 08:28:32 -0700 (PDT) Message-ID: <8637da890705040828w307fe725h506136db3296a493@mail.gmail.com> Date: Fri, 4 May 2007 08:28:32 -0700 From: "Wan-Teh Chang" To: tls@ietf.org Subject: Re: [TLS] Will CAs decide server signing algorithms in TLS 1.2? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87slao8y4b.fsf@mocca.josefsson.org> 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: , Errors-To: tls-bounces@lists.ietf.org On 5/4/07, Pasi.Eronen@nokia.com wrote: > Hi Simon, > > This issue was discussed in Prague, and I think the conclusion > was that the current text needs to be changed. In other words: > if the client tells it supports RSA+SHA256, the server can > use it even if the CA used RSA+SHA1 to sign the server cert How does the client tells the server that it supports RSA+SHA256? By overloading the "Cert Hash Types" hello extension or adding a new extension specifically for this purpose? There is a corresponding issue for the client's signature in the CertificateVerify message. Another related issue is the longer DSA variants defined in Draft FIPS 186-3, which aren't hardcoded to use SHA-1. Wan-Teh _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 11 11:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWvZ-0001kl-QK; Fri, 11 May 2007 11:21:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWvX-0001kf-Uk; Fri, 11 May 2007 11:21:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HmWvW-0008Kl-L5; Fri, 11 May 2007 11:21:03 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 8A9D4175F6; Fri, 11 May 2007 15:20:32 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1HmWv2-0000zx-AR; Fri, 11 May 2007 11:20:32 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: tsbsg17@itu.int, xiaoya.yang@itu.int, sebek@itu.int From: Pasi Eronen (IETF TLS WG) Message-Id: Date: Fri, 11 May 2007 11:20:32 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tim.polk@nist.gov, hartmans-ietf@mit.edu, sob@harvard.edu, tls@ietf.org Subject: [TLS] New Liaison Statement, "Response to "Request to reserve TLS extension type for ITU-T draft Recommendation X.tsm-1"" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pasi Eronen , Eric Rescorla 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: , Errors-To: tls-bounces@lists.ietf.org Title: Response to "Request to reserve TLS extension type for ITU-T draft Recommendation X.tsm-1" Submission Date: 2007-05-11 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=328 From: Pasi Eronen(IETF TLS WG) To: ITU-T SG 17(tsbsg17@itu.int, xiaoya.yang@itu.int, sebek@itu.int) Cc: tim.polk@nist.gov hartmans-ietf@mit.edu sob@harvard.edu ekr@networkresonance.com tls@ietf.org Reponse Contact: Technical Contact: Purpose: In response Body: I have understood that Yoshiaiki Isobe contacted Harald Alvestrand and Thomas Narten about this topic in December 2006; at that time, Harald provided advice similar to the following. RFC 4366 Section 5 defines the procedures for assigning a new TLS extension type. TLS extension types are assigned to Internet-Drafts that have been approved by the IESG. So, you need to publish your extension as an Internet-Draft and seek review of your draft. Once you have built a sufficient consensus behind your draft, you can propose that your draft be adopted by the TLS working group or published as an Area Director (AD) sponsored submission. Sections 3.2 and 4 of RFC 4775 provide more details on the procedures for an SDO working with the IETF to extend an IETF protocol in this way. Note that because of the requirements of RFC 4366, only the first option discussed in Section 4 is available in this instance. The TLS working group chairs and security ADs will be happy to answer any process questions you may have as you attempt to build consensus behind your draft. Best regards, Pasi Eronen TLS working group co-chair Attachment(s): No document has been attached _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 14 03:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnVCe-0008QL-NT; Mon, 14 May 2007 03:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnVCc-0008QF-Lu for tls@lists.ietf.org; Mon, 14 May 2007 03:42:42 -0400 Received: from sam.opera.com ([213.236.208.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnVCb-0002yj-7U for tls@lists.ietf.org; Mon, 14 May 2007 03:42:42 -0400 Received: from nimisha.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4E7gY2Z011175 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 14 May 2007 07:42:39 GMT Date: Mon, 14 May 2007 09:41:59 +0200 To: tls@lists.ietf.org From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.20 (Win32) X-Virus-Scanned: ClamAV 0.90.1/3242/Mon May 14 04:57:51 2007 on sam.opera.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sam.opera.com id l4E7gY2Z011175 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [TLS] Short Ephermal Diffie-Hellman keys 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: , Errors-To: tls-bounces@lists.ietf.org Hello all, I have recently started to see an increasing number of reports about =20 SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases =20 very short ones. Opera's SSL/TLS client will display warnings to users if the server is =20 using RSA/DH/DSA keys shorter than (currently) 900 bits. All keys used in= =20 the chain, including the CA certificates are included in this evaluation,= =20 as well as the ephermal key, if the server selects a cipher with an =20 ephermal key. The short DHE keys I have seen have usually been 512 bits, but I have see= n =20 servers sending keys as short as 256 bits. I have seen these keys on both normal webservers and mail servers, but I = =20 have an impression that there are more reports about the mail servers. I think it might be an idea for TLS specification to include =20 recommendations about how such keys should be selected. My preference for such a recommendation is that the ephermal key should b= e =20 as long, or as strong, as the key used to sign the ephermal key. I don't = =20 think the specification should mention specific keylengths, because what = =20 is secure is likely to change over time. Comments? As far as Opera is concerned, I am considering a few options, including =20 automatically disabling the ephermal ciphersuites or re-sorting the ciphe= r =20 suite list toplace them last, and renegotiate the connection. --=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 Mon May 14 12:35:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndVq-0005I1-PS; Mon, 14 May 2007 12:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndVo-0005Hw-R3 for tls@lists.ietf.org; Mon, 14 May 2007 12:35:04 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HndVn-0006Tw-Kx for tls@lists.ietf.org; Mon, 14 May 2007 12:35:04 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 1B251EAE52 for ; Mon, 14 May 2007 12:35:25 -0400 (EDT) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id D8A27E939C for ; Mon, 14 May 2007 12:35:24 -0400 (EDT) Message-ID: <46488F24.4020304@pobox.com> Date: Mon, 14 May 2007 09:32:36 -0700 From: Mike User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 Cc: tls@lists.ietf.org Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: tls-bounces@lists.ietf.org > I have recently started to see an increasing number of reports about > SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases > very short ones. > > The short DHE keys I have seen have usually been 512 bits, but I have > seen servers sending keys as short as 256 bits. This is probably the result of an administrator not wanting to wait the extra 30 seconds to generate a strong key. If the server is set up to generate a key on startup, it may not start listening for connections until it has completed the task. I recall (hopefully correctly) that a 1536 bit D-H key provides the equivalent of about 90-120 bits of security. I would guess that a 512-bit or 256-bit key is down in the EXPORT category of security. This is a terrible trend. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 14 14:47:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnfa0-0006FR-6J; Mon, 14 May 2007 14:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnfZz-0006FJ-4D for tls@lists.ietf.org; Mon, 14 May 2007 14:47:31 -0400 Received: from smtpout1464.sc1.he.tucows.com ([64.97.157.164] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnfZw-0008Mf-Se for tls@lists.ietf.org; Mon, 14 May 2007 14:47:31 -0400 Received: from [192.168.0.2] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 4630CC6B002F56C0; Mon, 14 May 2007 18:47:03 +0000 Message-ID: <4648AEA2.3020506@bolyard.com> Date: Mon, 14 May 2007 11:46:58 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070422 SeaMonkey/1.5a MIME-Version: 1.0 To: "Yngve N. Pettersen" Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org Yngve N. Pettersen (Developer Opera Software ASA) wrote: > Hello all, > > I have recently started to see an increasing number of reports about > SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases > very short ones. > > Opera's SSL/TLS client will display warnings to users if the server is > using RSA/DH/DSA keys shorter than (currently) 900 bits. Do you mean the length of the public value? or the length of the prime P? Do you really wish to disallow public values that are low numeric values even when the prime P is adequately large? -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 14 16:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnh0Y-00067N-OB; Mon, 14 May 2007 16:19:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnh0W-00064e-At for tls@lists.ietf.org; Mon, 14 May 2007 16:19:00 -0400 Received: from sam.opera.com ([213.236.208.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnh0U-0006t1-SC for tls@lists.ietf.org; Mon, 14 May 2007 16:19:00 -0400 Received: from nimisha.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4EKIpRS000330 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 14 May 2007 20:18:51 GMT Date: Mon, 14 May 2007 22:18:50 +0200 To: "Nelson B Bolyard" Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <4648AEA2.3020506@bolyard.com> Message-ID: In-Reply-To: <4648AEA2.3020506@bolyard.com> User-Agent: Opera Mail/9.20 (Win32) X-Virus-Scanned: ClamAV 0.90.1/3243/Mon May 14 10:49:49 2007 on sam.opera.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sam.opera.com id l4EKIpRS000330 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org Hello Nelson, On Mon, 14 May 2007 20:46:58 +0200, Nelson B Bolyard = =20 wrote: > Yngve N. Pettersen (Developer Opera Software ASA) wrote: >> Hello all, >> >> I have recently started to see an increasing number of reports about >> SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some case= s >> very short ones. >> >> Opera's SSL/TLS client will display warnings to users if the server is >> using RSA/DH/DSA keys shorter than (currently) 900 bits. > > Do you mean the length of the public value? or the length of the prime= =20 > P? > > Do you really wish to disallow public values that are low numeric value= s > even when the prime P is adequately large? The keysize used by Opera for DH keys is calculated using OpenSSL's =20 DH_size function, which returns the number of bytes in the "P" element of= =20 the DH (dh_st) structure, which is then multiplied by 8 (so the real size= =20 may be 7 bits lower than stated; should probably use a more low level =20 call). Background: EVP_PKEY_bits does not return anything about DH keys, = =20 which is why DH_size is used. --=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 Tue May 15 03:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrFx-0007zg-5k; Tue, 15 May 2007 03:15:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnrFv-0007xb-DB for tls@lists.ietf.org; Tue, 15 May 2007 03:15:35 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnrFt-0005EV-V0 for tls@lists.ietf.org; Tue, 15 May 2007 03:15:35 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4F7F4QG012462; Tue, 15 May 2007 10:15:31 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:15:22 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:15:22 +0300 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] Short Ephermal Diffie-Hellman keys Date: Tue, 15 May 2007 10:15:20 +0300 Message-ID: In-Reply-To: <46488F24.4020304@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Short Ephermal Diffie-Hellman keys Thread-Index: AceWReRvnxAkaq6HRdqM4OdnT0nyVQAdrMyQ References: <46488F24.4020304@pobox.com> From: To: X-OriginalArrivalTime: 15 May 2007 07:15:22.0165 (UTC) FILETIME=[CD108E50:01C796C0] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org Mike wrote: > This is probably the result of an administrator not wanting to > wait the extra 30 seconds to generate a strong key. If the > server is set up to generate a key on startup, it may not start > listening for connections until it has completed the task. Generating a 1024-bit DH key on a modern PC takes less=20 than 30 _milli_seconds, so I doubt this is the real reason=20 (unless the implementation is really, really stupid). > I recall (hopefully correctly) that a 1536 bit D-H key provides > the equivalent of about 90-120 bits of security. I would guess > that a 512-bit or 256-bit key is down in the EXPORT category of > security. This is a terrible trend. RFC 3766 puts 1536 bit DH at around 90 bits. Factoring a 256-bit number on a single PC takes only couple of hours, so if discrete logs are approximately the same difficulty, 256-bit DH would be even less secure than the old EXPORT ciphersuites. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 08:11:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnvrx-0003B8-03; Tue, 15 May 2007 08:11:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnvrv-0003B2-5u for tls@lists.ietf.org; Tue, 15 May 2007 08:11:07 -0400 Received: from anchor-post-30.mail.demon.net ([194.217.242.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnvrq-00068S-RM for tls@lists.ietf.org; Tue, 15 May 2007 08:11:07 -0400 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1Hnvrd-000H9B-1t for tls@lists.ietf.org; Tue, 15 May 2007 12:10:51 +0000 Message-ID: <4649A374.8040805@drh-consultancy.demon.co.uk> Date: Tue, 15 May 2007 13:11:32 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys References: <46488F24.4020304@pobox.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > Mike wrote: > >> This is probably the result of an administrator not wanting to >> wait the extra 30 seconds to generate a strong key. If the >> server is set up to generate a key on startup, it may not start >> listening for connections until it has completed the task. > > Generating a 1024-bit DH key on a modern PC takes less > than 30 _milli_seconds, so I doubt this is the real reason > (unless the implementation is really, really stupid). > The 30 seconds reference should be for DH _parameter_ generation (which some servers perform on start up) rather than key generation. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 08:58:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwbg-0005M3-Rv; Tue, 15 May 2007 08:58:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwbe-0005LC-Sl for tls@lists.ietf.org; Tue, 15 May 2007 08:58:23 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HnwbW-0002lR-KM for tls@lists.ietf.org; Tue, 15 May 2007 08:58:22 -0400 Received: from mocca.josefsson.org ([83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4FCw2NM005750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 May 2007 14:58:06 +0200 From: Simon Josefsson To: Dr Stephen Henson References: <46488F24.4020304@pobox.com> <4649A374.8040805@drh-consultancy.demon.co.uk> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070515:tls@lists.ietf.org::R2hFKkPz+peeSYmA:9yCU X-Hashcash: 1:22:070515:lists@drh-consultancy.demon.co.uk::jXfsmoKE0blsbcvN:OoP6 Date: Tue, 15 May 2007 14:58:01 +0200 In-Reply-To: <4649A374.8040805@drh-consultancy.demon.co.uk> (Stephen Henson's message of "Tue\, 15 May 2007 13\:11\:32 +0100") Message-ID: <87y7jqckh2.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@lists.ietf.org Subject: [TLS] Re: Short Ephermal Diffie-Hellman keys 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: , Errors-To: tls-bounces@lists.ietf.org Dr Stephen Henson writes: > Pasi.Eronen@nokia.com wrote: >> Mike wrote: >> >>> This is probably the result of an administrator not wanting to >>> wait the extra 30 seconds to generate a strong key. If the >>> server is set up to generate a key on startup, it may not start >>> listening for connections until it has completed the task. >> >> Generating a 1024-bit DH key on a modern PC takes less >> than 30 _milli_seconds, so I doubt this is the real reason >> (unless the implementation is really, really stupid). >> > > The 30 seconds reference should be for DH _parameter_ generation (which > some servers perform on start up) rather than key generation. Furthermore, getting the entropy needed to generate DH parameters can be the bottleneck, especially on servers that also consume entropy for incoming connections. Some applications that use GnuTLS (I believe Exim is an example) have a separate script invoked once every day (or similar) to re-generate the DH parameters. This approach works fine even if getting the entropy is a bottle-neck, since it allows servers to continue to run using the earlier DH parameters until the new parameters have been generated. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 09:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnwlA-0004Zq-Cn; Tue, 15 May 2007 09:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwl9-0004Zl-0u for tls@lists.ietf.org; Tue, 15 May 2007 09:08:11 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnwl7-0002nY-Kc for tls@lists.ietf.org; Tue, 15 May 2007 09:08:11 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2xA-1Hnwl31fIu-0000oK; Tue, 15 May 2007 15:08:05 +0200 Received: by tau.invalid (Postfix, from userid 1000) id CF8611C28F; Tue, 15 May 2007 15:08:04 +0200 (CEST) Date: Tue, 15 May 2007 15:08:04 +0200 From: Bodo Moeller To: Nelson B Bolyard Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys Message-ID: <20070515130804.GA15682@tau.invalid> References: <4648AEA2.3020506@bolyard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4648AEA2.3020506@bolyard.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX197qp+xF1wELem1tP2bzHTB5H51jkaptvFq2wB Fj5Nv4xptbTygsBK/UYuBowoNnQxJtaTUqy5IxvVYPbvXtafTA 8FJ7vw0J8p6sVYJ5JhpuQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org On Mon, May 14, 2007 at 11:46:58AM -0700, Nelson B Bolyard wrote: > Yngve N. Pettersen (Developer Opera Software ASA) wrote: >> I have recently started to see an increasing number of reports about >> SSL/TLS servers using short Ephermal Diffie-Hellman keys, in some cases >> very short ones. >> >> Opera's SSL/TLS client will display warnings to users if the server is >> using RSA/DH/DSA keys shorter than (currently) 900 bits. > Do you mean the length of the public value? or the length of the prime P? > > Do you really wish to disallow public values that are low numeric values > even when the prime P is adequately large? While this really is about the prime P and not the public value, it wouldn't be wrong to disallow small public values. In practice the public value won't be too much shorter than the public value unless something weird (and presumably insecure) is going on. It's only shorter secret values (DH exponents) that can be used in a secure way. But then the client coudn't easily reject these anyway. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 09:14:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwrd-0007qK-Dx; Tue, 15 May 2007 09:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwrb-0007qD-JK for tls@lists.ietf.org; Tue, 15 May 2007 09:14:51 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnwra-0006FW-2f for tls@lists.ietf.org; Tue, 15 May 2007 09:14:51 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI3006X53FHJM@szxga03-in.huawei.com> for tls@lists.ietf.org; Tue, 15 May 2007 21:14:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JI300BZI3FG6L@szxga03-in.huawei.com> for tls@lists.ietf.org; Tue, 15 May 2007 21:14:05 +0800 (CST) Received: from [127.0.0.1] ([10.18.18.99]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JI300IXG3FEQZ@szxml03-in.huawei.com> for tls@lists.ietf.org; Tue, 15 May 2007 21:14:04 +0800 (CST) Date: Tue, 15 May 2007 18:44:01 +0530 From: jimmy Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-reply-to: <20070515130804.GA15682@tau.invalid> To: Bodo Moeller Message-id: <4649B219.9080207@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: [snip] > > While this really is about the prime P and not the public value, it > wouldn't be wrong to disallow small public values. In practice the > public value won't be too much shorter than the public value unless you meant 'public value won't be too much shorter than the prime' right? > something weird (and presumably insecure) is going on. > > It's only shorter secret values (DH exponents) that can be used in a > secure way. But then the client coudn't easily reject these anyway. > > Bodo -jb -- The biggest problem with communication is the illusion that it has occurred. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 09:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwt9-00004u-J4; Tue, 15 May 2007 09:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnwt8-0008WU-EH for tls@lists.ietf.org; Tue, 15 May 2007 09:16:26 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnwt7-0006pB-2j for tls@lists.ietf.org; Tue, 15 May 2007 09:16:26 -0400 Received: from [134.147.40.246] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Hnwt33byr-0006Fe; Tue, 15 May 2007 15:16:22 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 6EB1B1C28F; Tue, 15 May 2007 15:16:21 +0200 (CEST) Date: Tue, 15 May 2007 15:16:21 +0200 From: Bodo Moeller To: jimmy Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys Message-ID: <20070515131621.GA15990@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649B219.9080207@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4649B219.9080207@huawei.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+KU06houdHi4cTc5hPaC6HUDIMS/0KtHxFfoj ZXQ9zEi0nX08EWK19LcqV3J27dmUxuXuvkP1LY00FxArc+v1d/ ofPXSPGaKoB07NFgtQaEw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org On Tue, May 15, 2007 at 06:44:01PM +0530, jimmy wrote: >> While this really is about the prime P and not the public value, it >> wouldn't be wrong to disallow small public values. In practice the >> public value won't be too much shorter than the public value unless > you meant 'public value won't be too much shorter than the prime' right? Oops -- er, yes! Thanks for the correction. >> something weird (and presumably insecure) is going on. >> >> It's only shorter secret values (DH exponents) that can be used in a >> secure way. But then the client coudn't easily reject these anyway. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 09:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxQ2-0003qB-Hx; Tue, 15 May 2007 09:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnxQ0-0003p2-EK for tls@lists.ietf.org; Tue, 15 May 2007 09:50:24 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnxPy-0006QY-VB for tls@lists.ietf.org; Tue, 15 May 2007 09:50:24 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4FDo1Zp030250; Tue, 15 May 2007 16:50:14 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 16:50:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 16:50:14 +0300 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: Short Ephermal Diffie-Hellman keys Date: Tue, 15 May 2007 16:50:13 +0300 Message-ID: In-Reply-To: <87y7jqckh2.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Short Ephermal Diffie-Hellman keys Thread-Index: AceW8MBDUflNK2N8TuWjS/DDI/ZxNAABqxrQ References: <46488F24.4020304@pobox.com><4649A374.8040805@drh-consultancy.demon.co.uk> <87y7jqckh2.fsf@mocca.josefsson.org> From: To: , X-OriginalArrivalTime: 15 May 2007 13:50:14.0256 (UTC) FILETIME=[F6A6BF00:01C796F7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > Some applications that use GnuTLS (I believe Exim is an example) > have a separate script invoked once every day (or similar) to > re-generate the DH parameters. This approach works fine even if > getting the entropy is a bottle-neck, since it allows servers to > continue to run using the earlier DH parameters until the new > parameters have been generated. BTW, why do you generate new DH parameters in the first place? Earlier I suggested that TLS 1.2 spec should probably recommend just hardcoding some of the groups from RFC 3526 (i.e., recommend against generating DH parameters). This would simplify code and provide less opportunities for getting things wrong (e.g. very small primes seen by Yngve; small subgroup attacks; etc.). http://www1.ietf.org/mail-archive/web/tls/current/msg01115.html Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 11:34:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnz2Z-0003kC-Nq; Tue, 15 May 2007 11:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnz2Y-0003k4-NT for tls@lists.ietf.org; Tue, 15 May 2007 11:34:18 -0400 Received: from anchor-post-31.mail.demon.net ([194.217.242.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnz2V-0002jm-CY for tls@lists.ietf.org; Tue, 15 May 2007 11:34:18 -0400 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1Hnz2A-000HYc-3J for tls@lists.ietf.org; Tue, 15 May 2007 15:33:56 +0000 Message-ID: <4649D2FD.2020309@drh-consultancy.demon.co.uk> Date: Tue, 15 May 2007 16:34:21 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> In-Reply-To: <20070515130804.GA15682@tau.invalid> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > It's only shorter secret values (DH exponents) that can be used in a > secure way. But then the client coudn't easily reject these anyway. > Speaking of which what do people think about including the sub prime value (aka "q") as an optional value in DH parameters in a TLS 1.2 handshake? Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 11:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnz3y-0005Yi-Pm; Tue, 15 May 2007 11:35:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnz3x-0005Yd-47 for tls@ietf.org; Tue, 15 May 2007 11:35:45 -0400 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnz3u-0002yU-Ov for tls@ietf.org; Tue, 15 May 2007 11:35:45 -0400 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.85.3; Tue, 15 May 2007 16:35:41 +0100 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by dub-exhub-c302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 15 May 2007 16:35:40 +0100 From: Stefan Santesson To: "tls@ietf.org" Date: Tue, 15 May 2007 16:35:42 +0100 Thread-Topic: Further development of GSS-TLS Thread-Index: AceT4EI1HoCN9TIxThOk3LK8NmAdLADJJ1nQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Pasi Eronen Subject: [TLS] Further development of GSS-TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953948962==" Errors-To: tls-bounces@lists.ietf.org --===============0953948962== Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29taW5nIGJhY2sgb24gdGhlIGlzc3VlIG9mIEdTUy1UTFMgcmVsYXRlZCB0byB0aGUgcHJvcG9z ZWQgZHJhZnQgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc2FudGVz c29uLXRscy1nc3NhcGktMDEudHh0DQoNCkkgaGF2ZSBub3QgYmVlbiBhY3RpdmUgb24gdGhpcyBk aXNjdXNzaW9uIGxhcmdlbHkgYmVjYXVzZSBvZiB0aGUgZ3JlYXQgYW1vdW50IG9mIGZlZWRiYWNr IEkgaGF2ZSByZWNlaXZlZC4NCkl0IHdhcyBvYnZpb3VzIHRvIG1lIGFmdGVyIGxhc3QgSUVURiB0 aGF0IHdlIGhhZCBtb3JlIG9yIGxlc3MgYSBkZWFkbG9jayBvbiB0aGlzIGRyYWZ0Lg0KDQpTZXZl cmFsIG9mIHRoZSBwcm9wb3NhbHMgb2YgdGhpcyBkcmFmdCBzZWVtcyB0byBiZSB0b3RhbGx5IHVu YWNjZXB0YWJsZSB0byBzb21lIG1lbWJlcnMgb2YgdGhpcyBsaXN0Lg0KT24gdGhlIG90aGVyIGhh bmQsIG5vbmUgb2YgdGhlIGFsdGVybmF0aXZlIHByb3Bvc2FscyBwcm92aWRlIHRoZSBmdW5jdGlv bmFsaXR5IHRoYXQgd2Ugc2V0IG91dCB0byBzb2x2ZS4NCg0KVGhpcyBkaXNjdXNzaW9uIGhhcyB0 aGVyZWZvcmUgdHJpZ2dlcmVkIGEgcGVyaW9kIG9mIHJlY29uc2lkZXJhdGlvbi4gQmVmb3JlIEkg Z28gYW55IGZ1cnRoZXIgdG8gdGFrZSBvbiB0aGUgaGFyZCB0YXNrIHRvIHRyeSB0byBnZXQgd2lk ZSBhY2NlcHRhbmNlIEkgbmVlZCB0byBiZSBzdXJlIHRoYXQgdGhlIHByb3Bvc2VkIGRyYWZ0IHJl cHJlc2VudCB0aGUgYWJzb2x1dGUgcHJlZmVycmVkIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLiBU b2RheSBJJ20gbm90IHN1cmUuIEF0IGxlYXN0IG5vdCB0byB0aGUgZGVncmVlIHdoZXJlIEknbSBy ZWFkeSB0byBwdXNoIGZvciBhbnkgc3BlY2lmaWMgc29sdXRpb24uDQoNClVudGlsIHRoYXQgdGlt ZSBjb21lcywgaWYgaXQgY29tZXMsIEkgd2lsbCBzaW1wbHkgdGFrZSBhIHN0ZXAgYmFjayBhbmQg bGV0IHRoZSBjdXJyZW50IGRyYWZ0IGV4cGlyZS4NCkkgd2lsbCBiZSBoYXBweSB0byBwYXJ0aWNp cGF0ZSBpbiBhbnkgZGlzY3Vzc2lvbiwgYnV0IEkgd2lsbCBub3QgYXQgdGhpcyBtb21lbnQgdHJ5 IHRvIHB1c2ggZm9yIGFueSBzcGVjaWZpYyBzb2x1dGlvbiB0byB0aGlzIGNvbXBsZXggcHJvYmxl bS4NCg0KDQoNCg0KU3RlZmFuIFNhbnRlc3Nvbg0KU2VuaW9yIFByb2dyYW0gTWFuYWdlcg0KV2lu ZG93cyBTZWN1cml0eSwgU3RhbmRhcmRzDQoNCg== --===============0953948962== 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 --===============0953948962==-- From tls-bounces@lists.ietf.org Tue May 15 12:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnze5-000344-T9; Tue, 15 May 2007 12:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnze3-00033m-Mz for tls@lists.ietf.org; Tue, 15 May 2007 12:13:03 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnze2-0002d6-7y for tls@lists.ietf.org; Tue, 15 May 2007 12:13:03 -0400 Received: from mocca.josefsson.org ([83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4FGCoo9007430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 May 2007 18:12:57 +0200 From: Simon Josefsson To: References: <46488F24.4020304@pobox.com> <4649A374.8040805@drh-consultancy.demon.co.uk> <87y7jqckh2.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070515:tls@lists.ietf.org::AGOZ24R6cM2lKKxs:1lWv X-Hashcash: 1:22:070515:pasi.eronen@nokia.com::4Ai+2aulNt9bxdaL:7UMT Date: Tue, 15 May 2007 18:12:50 +0200 In-Reply-To: (Pasi Eronen's message of "Tue\, 15 May 2007 16\:50\:13 +0300") Message-ID: <877iraawvx.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@lists.ietf.org Subject: [TLS] Re: Short Ephermal Diffie-Hellman keys 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: , Errors-To: tls-bounces@lists.ietf.org writes: > Simon Josefsson wrote: > >> Some applications that use GnuTLS (I believe Exim is an example) >> have a separate script invoked once every day (or similar) to >> re-generate the DH parameters. This approach works fine even if >> getting the entropy is a bottle-neck, since it allows servers to >> continue to run using the earlier DH parameters until the new >> parameters have been generated. > > BTW, why do you generate new DH parameters in the first place? GnuTLS doesn't -- external applications, notably Exim, do it. However, I have not idea why they do it. There are some discussion about this behaviour in section 2.2.3 of: http://pkg-exim4.alioth.debian.org/README/README.Debian.html#id224002 Frankly, I'm not sure I really understand what they are doing or why. > Earlier I suggested that TLS 1.2 spec should probably recommend just > hardcoding some of the groups from RFC 3526 (i.e., recommend against > generating DH parameters). This would simplify code and provide less > opportunities for getting things wrong (e.g. very small primes seen by > Yngve; small subgroup attacks; etc.). > > http://www1.ietf.org/mail-archive/web/tls/current/msg01115.html I think we would need solid support from the cryptographic community to change this. Regenerating new DH parameters appear to me, if they are computed correctly, to potentially offer one additional wall of protection. The risk is if the parameters are not computed correctly. But that risk have to be weighted against the risk of someone exploiting the fact that many D-H exchanges on the Internet uses the same parameters, and does so over a multi-year time period. Personally, I'm leaning towards reviewing the code to generate D-H parameters, and to recommend administrators to re-generate parameters every X days. Instead of putting all trust in one D-H parameter. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 12:44:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho08Z-0004MJ-8E; Tue, 15 May 2007 12:44:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho08Y-0004ME-0v for tls@lists.ietf.org; Tue, 15 May 2007 12:44:34 -0400 Received: from smtpout1484.sc1.he.tucows.com ([64.97.157.184] helo=n034.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho08W-000251-Cj for tls@lists.ietf.org; Tue, 15 May 2007 12:44:33 -0400 Received: from [192.168.0.5] (24.6.51.98) by n034.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 4630CE3D00329963; Tue, 15 May 2007 16:44:24 +0000 Message-ID: <4649E35B.4030809@bolyard.com> Date: Tue, 15 May 2007 09:44:11 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070418 SeaMonkey/1.5a MIME-Version: 1.0 To: Dr Stephen Henson Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> In-Reply-To: <4649D2FD.2020309@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org Dr Stephen Henson wrote: > Bodo Moeller wrote: >> It's only shorter secret values (DH exponents) that can be used in a >> secure way. But then the client coudn't easily reject these anyway. > > Speaking of which what do people think about including the sub prime > value (aka "q") as an optional value in DH parameters in a TLS 1.2 > handshake? How does that help the recipient? How does the recipient use that info? Safe primes (where (P-1)/2 is also prime) are commonly used for DH primes. Is sending Q helpful for such primes? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 16:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho3cO-0003sw-86; Tue, 15 May 2007 16:27:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho3cN-0003sl-2M for tls@lists.ietf.org; Tue, 15 May 2007 16:27:35 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho3cL-0008TH-Lr for tls@lists.ietf.org; Tue, 15 May 2007 16:27:35 -0400 Received: from [80.142.184.190] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Ho3cG1zlE-0006tu; Tue, 15 May 2007 22:27:29 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 362A01C298; Tue, 15 May 2007 22:27:27 +0200 (CEST) Date: Tue, 15 May 2007 22:27:26 +0200 From: Bodo Moeller To: Nelson B Bolyard Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys Message-ID: <20070515202726.GA24732@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4649E35B.4030809@bolyard.com> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX18sGhWYs0w2WdMQUx0NAXAJiN2FygRzPhIwCYt cRZxz9DFbuzmnqTZlN9lpphDmFqWpFuOhvyALQGftV5ZDpoebs ieURbZ22hJ+YNDXu/VW6g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org On Tue, May 15, 2007 at 09:44:11AM -0700, Nelson B Bolyard wrote: > Dr Stephen Henson wrote: >> Bodo Moeller wrote: >>> It's only shorter secret values (DH exponents) that can be used in a >>> secure way. But then the client coudn't easily reject these anyway. >> Speaking of which what do people think about including the sub prime >> value (aka "q") as an optional value in DH parameters in a TLS 1.2 >> handshake? Yes, this definitely should be done! > How does that help the recipient? How does the recipient use that info? This would tell the recipient that it only needs to generate an exponent in the 0 ... q-1 range. The subgroup order q can be much shorter than the modulus p, so this can save a lot of time for the exponentiation. Think of DSA-style parameters (actually Schnorr-style, reused for DSA) where p has 2048 bits, say, and the matching size of q is just 224 bits. Currently such parameters can be used to make the server side run faster for ephemeral-DH TLS ciphersuites, but the client side cannot benefit from them. With q included in the ServerKeyExchange message, the client side can benefit from short q too. > Safe primes (where (P-1)/2 is also prime) are commonly used for DH primes. > Is sending Q helpful for such primes? It doesn't really help for such primes regarding the optimization mentioned above. So I guess when using safe primes, it would be reasonable to simply omit q if it is introduced into the ServerKeyExchange message as optional information. The client *might* use the information that p is a safe prime, though. (This is implied by seeing that the length of q is just one less than the length of p, both counted in bits, assuming that the specification requires q to actually be a prime.) The scenario where this would be relevant is arguably somewhat to bizarre to explain, though. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 18:00:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho53w-0006qy-GI; Tue, 15 May 2007 18:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho53v-0006qt-7i for tls@lists.ietf.org; Tue, 15 May 2007 18:00:07 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ho53u-0004Oy-0n for tls@lists.ietf.org; Tue, 15 May 2007 18:00:07 -0400 Received: (qmail 5560 invoked by uid 0); 15 May 2007 21:59:58 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.14.186) by woodstock.binhost.com with SMTP; 15 May 2007 21:59:58 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 May 2007 17:54:27 -0400 To: Bodo Moeller From: Russ Housley Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-Reply-To: <20070515202726.GA24732@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Bodo: > >> Speaking of which what do people think about including the sub prime > >> value (aka "q") as an optional value in DH parameters in a TLS 1.2 > >> handshake? > >Yes, this definitely should be done! RFC 2412 does not seem use "q" this way. Does anyone every use Oakley groups with TLS? If so, then you probably need some more general way to indicate the size of the subgroup. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 18:44:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5kU-0003cX-As; Tue, 15 May 2007 18:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5kS-0003cS-FT for tls@lists.ietf.org; Tue, 15 May 2007 18:44:04 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho5kQ-0000Jt-2i for tls@lists.ietf.org; Tue, 15 May 2007 18:44:04 -0400 Received: from [80.142.184.190] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Ho5kG2B32-0002iE; Wed, 16 May 2007 00:43:55 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 619921C298; Wed, 16 May 2007 00:43:51 +0200 (CEST) Date: Wed, 16 May 2007 00:43:51 +0200 From: Bodo Moeller To: Russ Housley Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys Message-ID: <20070515224351.GA27872@tau.invalid> References: <4648AEA2.3020506@bolyard.com> <20070515130804.GA15682@tau.invalid> <4649D2FD.2020309@drh-consultancy.demon.co.uk> <4649E35B.4030809@bolyard.com> <20070515202726.GA24732@tau.invalid> <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0MKu60-1Ho53w3DRn-0003jg@mx.kundenserver.de> User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX19anh4vg0dLSoCKpBP5prqCXEa1luv4Qo6QmIP 9P6IEz3GjAveK65Kw+CArEHXUEDzjRAPkuYhHSqyyl1zoo4/Bf VqmDXyGqOasAKfD+HpS9A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@lists.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: , Errors-To: tls-bounces@lists.ietf.org On Tue, May 15, 2007 at 05:54:27PM -0400, Russ Housley wrote: > Bodo: >>>> Speaking of which what do people think about including the sub prime >>>> value (aka "q") as an optional value in DH parameters in a TLS 1.2 >>>> handshake? >> Yes, this definitely should be done! > RFC 2412 does not seem use "q" this way. Does anyone every use > Oakley groups with TLS? If so, then you probably need some more > general way to indicate the size of the subgroup. For the Oakley well-known groups, the generator actually is a generator of a prime-order subgroup, so specifying a 'q' value is no problem. (It doesn't help much in this case, though, since 'q' is just one bit shorter than 'p'.) In general, Oakley-style group specifications include a "group order largest prime factor" field, which is pretty useless for implementations. It only helps to estimate the security that can be obtained using such a group when doing Diffie-Hellman *properly*, which is something for which you *don't* need this piece of information (and for which you shouldn't rely too much on Appendix D of RFC 2412). What you do need for implementations is the group order, and (if you want to use the short-exponent trick suggested in RFC 2412 App. D) information on whether the group order is prime (which is *not* part of Oakley-style group specifications). I'd suggest stating in the TLS specification that 'q' can only be included in the ServerKeyExchange message for the case of prime-order subgroups. These are what you'd usually use, except sometimes if the DH subgroup is nearly as large as 'p', which is a case where knowing 'q' doesn't provide significant benefits anyhow. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 15 23:50:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoAWR-0006vE-M9; Tue, 15 May 2007 23:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoAWQ-0006v8-4F for tls@lists.ietf.org; Tue, 15 May 2007 23:49:54 -0400 Received: from larry.its.auckland.ac.nz ([130.216.10.122] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoAWN-0004AL-O9 for tls@lists.ietf.org; Tue, 15 May 2007 23:49:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 033E41841E; Wed, 16 May 2007 15:49:48 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B45oJG9eSIO1; Wed, 16 May 2007 15:49:47 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DAF3B183FF; Wed, 16 May 2007 15:49:47 +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 3D9D751400E; Wed, 16 May 2007 15:49:47 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HoAWN-0000vl-00; Wed, 16 May 2007 15:49:51 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: lists@drh-consultancy.demon.co.uk, tls@lists.ietf.org Subject: Re: [TLS] Short Ephermal Diffie-Hellman keys In-Reply-To: <4649D2FD.2020309@drh-consultancy.demon.co.uk> Message-Id: Date: Wed, 16 May 2007 15:49:51 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: , Errors-To: tls-bounces@lists.ietf.org Dr Stephen Henson writes: >Speaking of which what do people think about including the sub prime value >(aka "q") as an optional value in DH parameters in a TLS 1.2 handshake? It's a good idea, I've been wanting that for awhile (SSH should be doing this as well). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 16 04:04:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEUm-00046n-Ki; Wed, 16 May 2007 04:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEUl-00046g-Ct for tls@lists.ietf.org; Wed, 16 May 2007 04:04:27 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoEUj-00067G-UM for tls@lists.ietf.org; Wed, 16 May 2007 04:04:27 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4G83qdx024456; Wed, 16 May 2007 11:04:17 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 11:04:11 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 11:04:11 +0300 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: Wed, 16 May 2007 11:04:09 +0300 Message-ID: In-Reply-To: <877iraawvx.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Short Ephermal Diffie-Hellman keys Thread-Index: AceXC+60vProEiVUSDyag8soNLouZAAgzGHA References: <46488F24.4020304@pobox.com><4649A374.8040805@drh-consultancy.demon.co.uk><87y7jqckh2.fsf@mocca.josefsson.org> <877iraawvx.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 16 May 2007 08:04:11.0569 (UTC) FILETIME=[C989E210:01C79790] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@lists.ietf.org Subject: [TLS] RE: Short Ephermal Diffie-Hellman keys 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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > > Earlier I suggested that TLS 1.2 spec should probably recommend just > > hardcoding some of the groups from RFC 3526 (i.e., recommend against > > generating DH parameters). This would simplify code and provide less > > opportunities for getting things wrong (e.g. very small=20 > > primes seen by Yngve; small subgroup attacks; etc.). > > > > http://www1.ietf.org/mail-archive/web/tls/current/msg01115.html >=20 > I think we would need solid support from the cryptographic=20 > community to change this. Current TLS specs already allow implementations to do this; also=20 many existing protocols (IKE/IKEv2, MIKEY, HIP) do this. So I don't=20 think that this is very controversial (especially if we keep this as a recommendation, not a MUST). (BTW, even with TLS, I think FIPS/Suite B compliance would prohibit generating new DH parameters in the ECDH case.) > Regenerating new DH parameters appear to me, if they are computed > correctly, to potentially offer one additional wall of protection. >=20 > The risk is if the parameters are not computed correctly. But that > risk have to be weighted against the risk of someone exploiting the > fact that many D-H exchanges on the Internet uses the same > parameters, and does so over a multi-year time period. IKE has done exactly this over a multi-year time period, and I haven't heard of any concerns over that... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From haruko258@eyou.com Sat May 19 09:42:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpPCU-0008SS-QP for tls-archive@lists.ietf.org; Sat, 19 May 2007 09:42:26 -0400 Received: from [58.236.15.183] (helo=SPK04) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpPCU-0000cQ-BL for tls-archive@lists.ietf.org; Sat, 19 May 2007 09:42:26 -0400 Received: by SPK04 (Postfix, from userid 48) id 278BB369DCD; Sat, 19 May 2007 21:36:04 +0900 (KST) To: tls-archive@lists.ietf.org Subject: =?ISO-2022-JP?B?GyRCQ084NSROJSolUCU1JXMkckp6JC0kPyQkJEckOSQrISklbCVZGyhC?= =?ISO-2022-JP?B?GyRCJWskT0RjJCQkRyQ5JCwzTjxCJEtKeiQxJF4kOSRoGyhCISE=?= From: Resent-Sender: haruko258@eyou.com Message-ID: <20070519213604.75774@eyou.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Resent-Message-Id: <20070519130607.278BB369DCD@SPK04> Resent-Date: Sat, 19 May 2007 21:36:04 +0900 (KST) Resent-From: haruko258@eyou.com (Apache) X-Spam-Score: 3.4 (+++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 $B!&!&!&!E!E!D!D(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!D!D!E!E!&!&!&(B $BFyBN4X78@lLg%3%_%e%K%F%#!<(B!$B:#$9$0CO85$N%[%F%k$XD>9T3Ne@lMQ!@!!(B $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $BEv%5%$%H$O(B40$BBe!A(B50$BBe$NFyBN4X78$r5a$a$F$$$k?M:J!&=O=w(B $B$,=8$^$kF|K\:GBg$NFyBN4X78%3%_%e%K%F%#!<%5%$%H$G$9!#(B $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $B!T$4MxMQ$K4X$7$F$N$4Cm0U!U(B $B-!!!$4MxMQ$OCK=w6&$K(B40$B:P0J>e$NJ}$N$_$H$5$;$FD:$-$^$9!#(B $B-"!!CK=w6&$K$*Aj$NCO0h!&%a!<%k%"%I%l%9!&%Q%9%o!<%I$r(B $B@_Dj$7$FD:$-$^$9!#(B $B-"!!$9$k$*Aj%"%I%l%9$,I=<($5$l$F$*$j$^$9$N$G(B $B$=$N;~E@$GD>@\$4O"Mm$r$7$FD:$$$F$b7k9=$G$9$7!"(B $B%5%$%HFb$+$i%a!<%k$K$FO"Mm$rD$7$F2<$5$$!#(B $B!ZCm0U![<+8J(BPR$BFb$KO"Mm@h$NI=<($,L5$$?M:J!&=O=w$5$s$O(B $B!!!!!!!!8r>D$,@.N)$7FyBN4X78Cf$G$9$N$GO"Mm@h$NI=<($,(B $B!!!!!!!!I|3h8e!":FEY8r>D$r$*4j$$CW$7$^$9!#(B $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $B!|K\F|!"CO85$N%*%P%5%s$HFyBN4X78$r4uK>$5$l$kCK@-$O(B $B!!(Bhttp://cjbjj.com:112/ddd/40-navi-04/ $B!|K\F|!"2P>H$C$?BN$rK~$?$7$FM_$7$$%*%P%5%s$O(B $B!!(Bhttp://cjbjj.com:112/ddd/40-navi-04/ $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $B!zBT9g$o$;$N>l=j$r%j%"%k%?%$%`$G$d$j Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqt5G-0000kT-6E; Wed, 23 May 2007 11:49:06 -0400 Received: from [222.160.106.60] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hqt5E-0007yi-6E; Wed, 23 May 2007 11:49:06 -0400 To: =?iso-2022-jp?B?YWtpa280Njc1QHlhaG9vLmNvLmpw?=<> From: =?iso-2022-jp?B?YWtpa28=?= Subject: =?iso-2022-jp?B?GyRCQ084NSROJSolUCU1JXMkckp6JC0kPyQkJEckOSQrISklbCVZJWskT0RjJCQkRyQ5JCwzTjxCJEtKeiQxJF4kOSRoGyhCISE=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 $B!&!&!&!E!E!D!D(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,!D!D!E!E!&!&!&(B $BFyBN4X78@lLg%3%_%e%K%F%#!<(B!$B:#$9$0CO85$N%[%F%k$XD>9T3Ne@lMQ!@!!(B $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $BEv%5%$%H$O(B40$BBe!A(B50$BBe$NFyBN4X78$r5a$a$F$$$k?M:J!&=O=w(B $B$,=8$^$kF|K\:GBg$NFyBN4X78%3%_%e%K%F%#!<%5%$%H$G$9!#(B $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $B!T$4MxMQ$K4X$7$F$N$4Cm0U!U(B $B-!!!$4MxMQ$OCK=w6&$K(B40$B:P0J>e$NJ}$N$_$H$5$;$FD:$-$^$9!#(B $B-"!!CK=w6&$K$*Aj$NCO0h!&%a!<%k%"%I%l%9!&%Q%9%o!<%I$r(B $B@_Dj$7$FD:$-$^$9!#(B $B-"!!$9$k$*Aj%"%I%l%9$,I=<($5$l$F$*$j$^$9$N$G(B $B$=$N;~E@$GD>@\$4O"Mm$r$7$FD:$$$F$b7k9=$G$9$7!"(B $B%5%$%HFb$+$i%a!<%k$K$FO"Mm$rD$7$F2<$5$$!#(B $B!ZCm0U![<+8J(BPR$BFb$KO"Mm@h$NI=<($,L5$$?M:J!&=O=w$5$s$O(B $B!!!!!!!!8r>D$,@.N)$7FyBN4X78Cf$G$9$N$GO"Mm@h$NI=<($,(B $B!!!!!!!!I|3h8e!":FEY8r>D$r$*4j$$CW$7$^$9!#(B $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $B!|K\F|!"CO85$N%*%P%5%s$HFyBN4X78$r4uK>$5$l$kCK@-$O(B $B!!(Bhttp://cjbjj.com:112/ddd/40-navi-ln012345/ $B!|K\F|!"2P>H$C$?BN$rK~$?$7$FM_$7$$%*%P%5%s$O(B $B!!(Bhttp://cjbjj.com:112/ddd/40-navi-ln012345/ $B(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(,(!(B $B!zBT9g$o$;$N>l=j$r%j%"%k%?%$%`$G$d$j Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrAdc-0007Bp-Af; Thu, 24 May 2007 06:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrAda-0007Bk-Je for tls@ietf.org; Thu, 24 May 2007 06:33:42 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrAdY-00010Q-OK for tls@ietf.org; Thu, 24 May 2007 06:33:42 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4OAXOj6002454 for ; Thu, 24 May 2007 13:33:38 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 13:33:33 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 13:33:32 +0300 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: Thu, 24 May 2007 13:33:32 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw poll on TLS SRP status Thread-Index: Aced7voYZ5MYEVUXSdeC1iQ2lFtbaQ== From: To: X-OriginalArrivalTime: 24 May 2007 10:33:32.0925 (UTC) FILETIME=[FA3A4AD0:01C79DEE] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [TLS] Straw poll on TLS SRP status 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: , Errors-To: tls-bounces@lists.ietf.org Folks, The one remaining issue with TLS SRP is its intended status (Proposed Standard, Informational, or Experimental). I and Eric think we need more data to determine consensus here, so this message starts a two-week straw poll on this issue. (Our apologies that this has=20 taken so long; this poll should have been some time ago already.) The question is: Do you support advancing draft-ietf-tls-srp as=20 Proposed Standard?=20 [ ] Yes. [ ] I think Informational/Experimental is better. [ ] I don't care about the status, just get it published. [ ] Something else, please state: You may reply either on the list, or privately to the chairs. Some points you may wish to consider, summarizing some of the arguments made earlier: - The document describing SRP-3 (not exactly the same=20 algorithm as here), RFC 2945, is Proposed Standard. - At least the following IPR disclosures may be relevant: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D25 https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D31 https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D63 - Previously some WG members have argued that documents that=20 have IPR with non-royalty-free terms should go Informational or Experimental. We have at least one such IPR disclosure=20 (the last one listed above). - There are several implementations of the draft: see e.g. http://www1.ietf.org/mail-archive/web/tls/current/msg01228.html - Regardless of what status will be chosen, the RFC will=20 not be compatible with any of those implementations (since the TLS extension number will change). Note that we need rough consensus to go for Proposed Standard;=20 if there's significant disagreement, we go Informational or Experimental. Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 07:19:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrBM2-0001Gj-1L; Thu, 24 May 2007 07:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrBM1-0001Gd-2H for tls@ietf.org; Thu, 24 May 2007 07:19:37 -0400 Received: from curly.its.auckland.ac.nz ([130.216.10.123] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrBLz-0002BP-Lh for tls@ietf.org; Thu, 24 May 2007 07:19:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1A6699C4F1; Thu, 24 May 2007 23:19:34 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6hnuRgyeWPL; Thu, 24 May 2007 23:19:34 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 019139C4EC; Thu, 24 May 2007 23:19:34 +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 86EDCD14CFA; Thu, 24 May 2007 23:19:33 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HrBM5-0005EZ-00; Thu, 24 May 2007 23:19:41 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: Message-Id: Date: Thu, 24 May 2007 23:19:41 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: tls-bounces@lists.ietf.org writes: >The question is: Do you support advancing draft-ietf-tls-srp as Proposed >Standard? > > [ ] Yes. > [X] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: > >You may reply either on the list, or privately to the chairs. I'll reply publicly in order to provide a rationale: Arguments against it becoming a full standard are that this spec has been around for six years now without any significant implementations appearing (apologies to the authors of GnuTLS and TLS Lite :-). Arguments for it being a full standard are that given that we've got things like Camellia cipher suites (which have even less mainstream support than SRP) moving forward as full standards, you can't really count SRP out on that basis. More to the point, the trend with WG items seems to be to make everything a full standards rather than experimental/informational. So really the only deciding factor is the IP status. The Lucent and especially the Phoenix IPR statements will be, in my experience, sufficient to scare off any commercial users (and by extension non-commercial users who have to worry about lawyers). So although it'd be nice to see SRP deployed, I don't think the IP encumbrance will get it past Informational. If it wasn't for that, my vote would be "Just get it published". Can we revisit this in 2012 (or 13, or whenever the patents expire)? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 07:28:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrBUx-0001oe-O2; Thu, 24 May 2007 07:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrBUw-0001oK-H0 for tls@ietf.org; Thu, 24 May 2007 07:28:50 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrBUw-00052Z-2V for tls@ietf.org; Thu, 24 May 2007 07:28:50 -0400 Received: from mocca.josefsson.org ([83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4OBSZ9k024083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 May 2007 13:28:41 +0200 From: Simon Josefsson To: References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070524:tls@ietf.org::B/nRUE7JGY9genIE:GZqC X-Hashcash: 1:22:070524:pasi.eronen@nokia.com::0d2XXhcTPnSmM9Uh:cu06 Date: Thu, 24 May 2007 13:28:35 +0200 In-Reply-To: (Pasi Eronen's message of "Thu\, 24 May 2007 13\:33\:32 +0300") Message-ID: <87bqga1mvw.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tls@ietf.org Subject: [TLS] Re: Straw poll on TLS SRP status 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: , Errors-To: tls-bounces@lists.ietf.org writes: > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: [X] Something else: Get more information about the patent status of this technology, possibly asking the patent owner to chime in. I don't think we have enough information to decide right now. While you cite a few IPR disclosures: > - At least the following IPR disclosures may be relevant: > > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=25 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=31 > https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=63 If these would apply to this particular document, I would feel that we shouldn't put this document on the standards track. But those disclosures aren't about this document. And we have several free software implementations out there and there haven't been any problems. I think we must evaluate whether these patents are still relevant. It would help if the patent owner could declare what they think about people implementing TLS-SRP. Do the owner consider TLS-SRP infringement? Is the owner willing to improve the patent license to something that is more acceptable to the community? [1] Further, what guarantees do we have that the patent owner doesn't change their minds? > - Regardless of what status will be chosen, the RFC will > not be compatible with any of those implementations > (since the TLS extension number will change). I think that is a flaw with the TLS core specification that we should fix. It should be simple to get protocol numbers allocated to avoid collisions. I will maintain the old protocol numbers in GnuTLS for a long while, and I suspect other implementers will do the same, to avoid breaking backwards compatibility. /Simon [1] For hints on how to write a patent license that is more friendly towards the free software community subset of the IETF community, see: http://www.ietf.org/internet-drafts/draft-josefsson-free-standards-howto-00.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 07:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrBvh-0002xV-DK; Thu, 24 May 2007 07:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrBvh-0002xQ-2S for tls@ietf.org; Thu, 24 May 2007 07:56:29 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrBvf-0003YT-K5 for tls@ietf.org; Thu, 24 May 2007 07:56:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4OBttuH014608; Thu, 24 May 2007 14:56:25 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 14:56:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 14:56:13 +0300 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: Thu, 24 May 2007 14:56:08 +0300 Message-ID: In-Reply-To: <87bqga1mvw.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw poll on TLS SRP status Thread-Index: Aced9sGv69K4dnrTRxO5PsEj/p9imQAAoKwQ References: <87bqga1mvw.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 24 May 2007 11:56:13.0322 (UTC) FILETIME=[86DACEA0:01C79DFA] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org Subject: [TLS] RE: Straw poll on TLS SRP status 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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > [X] Something else: Get more information about the patent status=20 > of this technology, possibly asking the patent owner to chime in. I believe several attempts have been made over the years to get=20 more detailed IPR disclosures about SRP, but without much results. In fact, this case is given as one example in RFC 3669. > If these would apply to this particular document, I would feel that > we shouldn't put this document on the standards track. But those > disclosures aren't about this document. And we have several free > software implementations out there and there haven't been any > problems. I think we must evaluate whether these patents are still > relevant. One of the basic principles of IETF IPR is that "the IETF will=20 make no determination about the validity of any particular IPR claim" (see e.g. RFC 3979 and RFC 2026). You, as an individual participant, are of course free to form opinions about particular IPR claims (based on whatever evaluation you wish), and express those opinions. But "we" as TLS WG will not make such a determination. In other words: we're not supposed to decide whether the IPRs are valid or not; just whether this document is going Proposed Standard or Informational/Experimental. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 08:16:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrCEf-0007LJ-SF; Thu, 24 May 2007 08:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrCEe-0007L1-BU for tls@ietf.org; Thu, 24 May 2007 08:16:04 -0400 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrCEc-0002QP-UX for tls@ietf.org; Thu, 24 May 2007 08:16:04 -0400 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id OAA1052768 for ; Thu, 24 May 2007 14:14:23 +0100 Message-ID: <465581F0.4020908@isima.fr> Date: Thu, 24 May 2007 14:15:44 +0200 From: badra User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 Subject: Re: [TLS] RE: Straw poll on TLS SRP status References: <87bqga1mvw.fsf@mocca.josefsson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id OAA1052768 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com a =E9crit : >> If these would apply to this particular document, I would feel that >> we shouldn't put this document on the standards track. But those >> disclosures aren't about this document. And we have several free >> software implementations out there and there haven't been any >> problems. I think we must evaluate whether these patents are still >> relevant. >> =20 > > One of the basic principles of IETF IPR is that "the IETF will=20 > make no determination about the validity of any particular IPR > claim" (see e.g. RFC 3979 and RFC 2026). > > You, as an individual participant, are of course free to form opinions > about particular IPR claims (based on whatever evaluation you wish), > and express those opinions. But "we" as TLS WG will not make such a > determination. > > In other words: we're not supposed to decide whether the IPRs > are valid or not; just whether this document is going Proposed > Standard or Informational/Experimental. > > =20 [X] Yes. IMHO, it is better to don't argue on the patent itself since the current=20 document is not the first and will not be the last IETF document to be=20 published as Standard Track with the presence of a particular IPR claim. Best regards, Badra --=20 Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 09:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDBR-0005QC-BF; Thu, 24 May 2007 09:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrDBQ-0005Q7-VW for tls@ietf.org; Thu, 24 May 2007 09:16:48 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrDBP-0000Vm-IX for tls@ietf.org; Thu, 24 May 2007 09:16:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 434A5480225; Fri, 25 May 2007 01:16:36 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4qsINNJFbhJ; Fri, 25 May 2007 01:16:36 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 29C56480205; Fri, 25 May 2007 01:16:36 +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 26ABCD14CFA; Fri, 25 May 2007 01:16:35 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HrDBM-0007E0-00; Fri, 25 May 2007 01:16:44 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, simon@josefsson.org Subject: Re: [TLS] RE: Straw poll on TLS SRP status In-Reply-To: Message-Id: Date: Fri, 25 May 2007 01:16:44 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: tls-bounces@lists.ietf.org writes: >In other words: we're not supposed to decide whether the IPRs are valid or >not; just whether this document is going Proposed Standard or >Informational/Experimental. I agree that it's not the WG's job to try and figure out the patent status. It is up to us to consider what the effect of the IPRs on deployment will be though, and the effect for any commercial user is that they'll run screaming. Just because someone says they're only using it in free software won't help either, look at what happened with GIF once Unisys started trying to enforce their patent on LZW. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 12:07:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFq2-0006qN-PX; Thu, 24 May 2007 12:06:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFq0-0006q8-Ns for tls@ietf.org; Thu, 24 May 2007 12:06:53 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrFpz-0003z9-Ad for tls@ietf.org; Thu, 24 May 2007 12:06:52 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4OG6oPk015452 for ; Thu, 24 May 2007 16:06:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JIJ00601Z0H3K00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Thu, 24 May 2007 10:06:50 -0600 (MDT) Received: from [10.0.1.21] (216-165-236-126.championbroadband.com [216.165.236.126]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIJ00G3SZFAO210@mail-amer.sun.com>; Thu, 24 May 2007 10:06:50 -0600 (MDT) Date: Thu, 24 May 2007 09:06:45 -0700 From: Chris Newman Subject: Re: [TLS] Straw poll on TLS SRP status In-reply-to: To: Pasi.Eronen@nokia.com, tls@ietf.org Message-id: <07218C52A88620B12CA9BF4C@[10.0.1.21]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote on 5/24/07 13:33 +0300: > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: [X] I think Informational/Experimental is better. It's my technical opinion that adding new user-level authentication mechanisms to the TLS layer is not a good idea in general. TLS APIs are already quite complex and can be difficult to use. Client certificate authentication has been there long enough that it's a known quantity how to dig the necessary details out of the TLS layer for an application to consume, however more traditional user-level authentication is a different beast. As GSSAPI and SASL APIs have shown, designing general-purpose user-level authentication APIs is very difficult, by itself tends to create APIs most people can't understand, and it's not clear to me it's a good idea to add all that complexity to the existing TLS APIs. I'd much rather keep user-level authentication as a separate subsystem and promote channel bindings on the standards track instead. What do others on the list think about this issue? - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 13:31:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrHAH-0000qv-LR; Thu, 24 May 2007 13:31:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrHAG-0000qq-8Y for tls@ietf.org; Thu, 24 May 2007 13:31:52 -0400 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrHAD-0001uF-Vi for tls@ietf.org; Thu, 24 May 2007 13:31:52 -0400 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-2.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HrHAC-0003Ni-W4 for tls@ietf.org; Thu, 24 May 2007 10:31:49 -0700 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1HrHAC-0001jO-9Y for tls@ietf.org; Thu, 24 May 2007 10:31:48 -0700 Date: Thu, 24 May 2007 10:31:48 -0700 (PDT) From: Tom Wu To: tls@ietf.org Subject: Re: [TLS] RE: Straw poll on TLS SRP status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-2.Stanford.EDU X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 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: , Errors-To: tls-bounces@lists.ietf.org > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [X] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: Proposed Standard is the best fit given the current situation. There have been quite a few interoperating implementations of the SRP ciphersuites, both open-source and commercial (which I can attest to directly as a consultant on some of the projects), so it meets the IPR test of "at least two interoperating implementations arising from separate license exercise" by a wide margin. Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 14:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrHmL-0007Id-GZ; Thu, 24 May 2007 14:11:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrHmK-0007IY-Hr for tls@ietf.org; Thu, 24 May 2007 14:11:12 -0400 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrHmJ-0001nw-9U for tls@ietf.org; Thu, 24 May 2007 14:11:12 -0400 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.4.571.23) with ESMTP id ; Thu, 24 May 2007 11:11:01 -0700 X-Modus-ReverseDNS: OK X-Modus-BlackList: 24.219.24.139=OK;trevp@trevp.net=OK X-Modus-RBL: 24.219.24.139=Excluded X-Modus-Trusted: 24.219.24.139=NO X-Modus-Audit: TRUE;30;-1;128270706616750000 Message-ID: <4655D534.2040709@trevp.net> Date: Thu, 24 May 2007 11:11:00 -0700 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Straw poll on TLS SRP status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > Folks, > > The one remaining issue with TLS SRP is its intended status (Proposed > Standard, Informational, or Experimental). I and Eric think we need > more data to determine consensus here, so this message starts a > two-week straw poll on this issue. (Our apologies that this has > taken so long; this poll should have been some time ago already.) > > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: [1] Yes. [2] I don't care about the status, just get it published. Rationale for [1] - - Stanford IPR is royalty-free - SPEKE IPR is non-relevant - Dunno about Lucent EKE - AFAICT, their lawyers avoid making definite statements on principle (sigh). But in the 9-year history of SRP they've never bothered anyone about it. Also, the patent expires in 3 years, so it will be a moot point soon enough. Trevor _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 15:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrJSX-0002kL-7N; Thu, 24 May 2007 15:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrJSW-0002jq-Hc for tls@ietf.org; Thu, 24 May 2007 15:58:52 -0400 Received: from machshav.com ([198.180.150.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrJSU-00073J-9v for tls@ietf.org; Thu, 24 May 2007 15:58:52 -0400 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 00334B553; Thu, 24 May 2007 19:58:49 +0000 (GMT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id C15237666B1; Thu, 24 May 2007 15:58:42 -0400 (EDT) Date: Thu, 24 May 2007 15:58:42 -0400 From: "Steven M. Bellovin" To: Trevor Perrin Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <4655D534.2040709@trevp.net> References: <4655D534.2040709@trevp.net> Organization: Columbia University X-Mailer: Claws Mail 2.9.2 (GTK+ 2.10.12; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20070524195842.C15237666B1@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, 24 May 2007 11:11:00 -0700 Trevor Perrin wrote: > - Dunno about Lucent EKE - AFAICT, their lawyers avoid making > definite statements on principle (sigh). But in the 9-year history > of SRP they've never bothered anyone about it. Also, the patent > expires in 3 years, so it will be a moot point soon enough. > Well, 4 years -- 20 years from the October 2, 1991 filing date, since that's later than 17 years from the August 31, 1993 issue date. Anyway -- you're never going to get a definitive "no" from Lucent. There's absolutely no reason why they should bother -- if they say that EKE doesn't apply to SRP, it gives them very little leverage to license EKE. If they say "yes", they have to do something about it, or no one will take them seriously. Besides, saying "yes" convincingly is a lot of work; it would involve a fair amount of detailed study of the claims in EKE and seeing how they match against what particular implementations of SRP do. This analysis includes understanding the definitions in the (hard to understand) claims. For example, claim 1 speaks of "forming an outgoing signal by encrypting at least a portion of an excitation signal with a second symmetric key cryptosystem using a key based on said authentication signal, said excitation signal being based on a first signal, R.sub.A". What is an "excitation signal"? Coming up with suitable definitions is a major part of patent litigation, and takes a significant amount of time and effort. Why should Lucent do that, if the FUD is working just as well? Disclaimer: I'm one of the inventors of EKE. But I haven't worked for the patent owner since 1996, and back then they weren't interested in my ideas about making it royalty-free for open source use, and charging only for-profit users of the patent. I have no idea if, when, to whom, or how often Lucent has actually managed to license the patent. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 24 17:06:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrKVm-0003Kq-U2; Thu, 24 May 2007 17:06:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrKVl-0003Kl-T2 for tls@ietf.org; Thu, 24 May 2007 17:06:17 -0400 Received: from smtpout1463.sc1.he.tucows.com ([64.97.157.163] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrKVk-0004uT-Ko for tls@ietf.org; Thu, 24 May 2007 17:06:17 -0400 Received: from [192.168.0.5] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 4630CC6B004C7E95; Thu, 24 May 2007 21:06:00 +0000 Message-ID: <4655FE30.8000500@bolyard.com> Date: Thu, 24 May 2007 14:05:52 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070418 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > Folks, > > The one remaining issue with TLS SRP is its intended status (Proposed > Standard, Informational, or Experimental). I and Eric think we need > more data to determine consensus here, so this message starts a > two-week straw poll on this issue. (Our apologies that this has > taken so long; this poll should have been some time ago already.) > > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [x] Something else, please state: I think the WG must be consistent about whether or not IPR (other than royalty-free IPR) forces an RFC into Informational/Experimental status. That decision should not be revisited for each and every RFC that may encounter it. RFC 4492, the ECC-in-TLS RFC, was forced into Informational because the IPR status was uncertain to some WG members, even though there are two major browsers that offer it (one open source), servers from several vendors that offer it, and it is implemented in at least TWO different open source TLS implementations. I think that's sufficient precedent. Note that I don't think that "Informational/Experimental is better." but rather that it is what the WG has done in the past, and the WG should remain consistent, or else the chairs should explain why they insisted on it before and are now not doing so. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 07:04:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXae-0000cA-TR; Fri, 25 May 2007 07:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrXad-0000c3-QX for tls@ietf.org; Fri, 25 May 2007 07:04:11 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrXac-0004pi-Cl for tls@ietf.org; Fri, 25 May 2007 07:04:11 -0400 Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4PB41Mx005113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 May 2007 13:04:03 +0200 From: Simon Josefsson To: Nelson B Bolyard References: <4655FE30.8000500@bolyard.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070525:nelson@bolyard.com::5JDq9v587RfeLzF1:L+VL X-Hashcash: 1:22:070525:tls@ietf.org::NqmJFoozGyNg+Wc5:XGIy Date: Fri, 25 May 2007 13:04:00 +0200 In-Reply-To: <4655FE30.8000500@bolyard.com> (Nelson B. Bolyard's message of "Thu\, 24 May 2007 14\:05\:52 -0700") Message-ID: <87irahxizj.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org Subject: [TLS] Re: Straw poll on TLS SRP status 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: , Errors-To: tls-bounces@lists.ietf.org Nelson B Bolyard writes: > I think the WG must be consistent about whether or not IPR (other than > royalty-free IPR) forces an RFC into Informational/Experimental status. > That decision should not be revisited for each and every RFC that may > encounter it. > > RFC 4492, the ECC-in-TLS RFC, was forced into Informational because the > IPR status was uncertain to some WG members, even though there are two > major browsers that offer it (one open source), servers from several > vendors that offer it, and it is implemented in at least TWO different > open source TLS implementations. I think that's sufficient precedent. > > Note that I don't think that "Informational/Experimental is better." > but rather that it is what the WG has done in the past, and the WG > should remain consistent, or else the chairs should explain why they > insisted on it before and are now not doing so. I agree with this. I think it would be useful if the WG could develop some simple criteria related to patents, i.e., when a specific technology can and cannot go to the Standards Track. There may be exceptional situations when such simple criteria aren't applicable -- and, alas, one could argue that both TLS-SRP and TLS-ECC are complex enough not to fit under simple guidelines -- but then the WG can discuss per-case what the answer should be. The WG criterias can be updated after such incidents. Having simple guidelines written down would make the procedures appear more open and would encourage consistency. Right now the process seems arbitrary, and is open to hijacking by those who shout the strongest at the moment, and further, can easily be FUDed by referencing patents whose relevance have not been established. I volunteer to help such an effort or document. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 09:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZQs-00009O-Rm; Fri, 25 May 2007 09:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZQs-00009J-B9 for tls@ietf.org; Fri, 25 May 2007 09:02:14 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrZQq-0001AH-Sw for tls@ietf.org; Fri, 25 May 2007 09:02:14 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4PD1tFV032363; Fri, 25 May 2007 16:02:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 16:02:05 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 May 2007 16:02:06 +0300 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] Straw poll on TLS SRP status Date: Fri, 25 May 2007 16:02:06 +0300 Message-ID: In-Reply-To: <4655FE30.8000500@bolyard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll on TLS SRP status Thread-Index: AceeR2tum2p7g3sNROGaQgMwY0C5FQAgoPtQ References: <4655FE30.8000500@bolyard.com> From: To: , X-OriginalArrivalTime: 25 May 2007 13:02:06.0152 (UTC) FILETIME=[E5568C80:01C79ECC] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Errors-To: tls-bounces@lists.ietf.org Nelson B Bolyard wrote: > I think the WG must be consistent about whether or not IPR (other > than royalty-free IPR) forces an RFC into Informational/Experimental > status. That decision should not be revisited for each and every > RFC that may encounter it. I actually think quite the opposite; that decision *should* be revisited for each and every RFC.=20 The decision cannot depend only on the existence of IPR claims. =20 Not all IPR claims and license terms are equal. And IPR claims=20 anyway usually cover only IPR held by those contributing to the=20 work; it's even likely that other IPR might be found later,=20 after the document has been published. But most importantly, not all documents are equal. There are some things we probably want on standards track even though there is other-than-royalty-free IPR (IPsec is one obvious example). Other documents could be better off Informational/Experimental even in the absence of any IPR. > Note that I don't think that "Informational/Experimental is better." > but rather that it is what the WG has done in the past, and the WG > should remain consistent, or else the chairs should explain why they > insisted on it before and are now not doing so. That decision was not made by the chairs (*): there was a straw poll, the result of which was that there was no WG consensus to publish it as PS, so it went Informational. We're having a similar straw poll right now, so I think we are being consistent -- the decisions are made by rough WG consensus, not formal rules. (*) Disclaimer: I wasn't chair back then, and I supported PS. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 13:43:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrdoU-000248-VC; Fri, 25 May 2007 13:42:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrdoT-000243-T4 for tls@ietf.org; Fri, 25 May 2007 13:42:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrdoS-0005nP-G8 for tls@ietf.org; Fri, 25 May 2007 13:42:53 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4PHgmpC020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2007 10:42:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4655FE30.8000500@bolyard.com> References: <4655FE30.8000500@bolyard.com> <4655FE30.8000500@bolyard.com> Date: Fri, 25 May 2007 10:42:36 -0700 To: Nelson B Bolyard , tls@ietf.org, From: Paul Hoffman Subject: Re: [TLS] Straw poll on TLS SRP status Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: tls-bounces@lists.ietf.org At 2:05 PM -0700 5/24/07, Nelson B Bolyard wrote: > > [x] Something else, please state: > >I think the WG must be consistent about whether or not IPR (other than >royalty-free IPR) forces an RFC into Informational/Experimental status. >That decision should not be revisited for each and every RFC that may >encounter it. > >RFC 4492, the ECC-in-TLS RFC, was forced into Informational because the >IPR status was uncertain to some WG members, even though there are two >major browsers that offer it (one open source), servers from several >vendors that offer it, and it is implemented in at least TWO different >open source TLS implementations. I think that's sufficient precedent. > >Note that I don't think that "Informational/Experimental is better." >but rather that it is what the WG has done in the past, and the WG >should remain consistent, or else the chairs should explain why they >insisted on it before and are now not doing so. Fully agree. And I think it is appropriate to delay the decision on tls-srp until we have made that decision. Such a delay will not affect developers significantly. FWIW, I'm fine with us saying "they can get on standards track just as well as if there were no IPR issues", but I'm equally fine with "they can only be published as Informational". At 4:02 PM +0300 5/25/07, wrote: >The decision cannot depend only on the existence of IPR claims. >Not all IPR claims and license terms are equal. And IPR claims >anyway usually cover only IPR held by those contributing to the >work; it's even likely that other IPR might be found later, >after the document has been published. If more than a small handful of TLS WG members think that a properly-published IPR claim is likely to be valid enough to be held against them, that is a high enough bar to put the proposal in the "IPR-affected" bucket. >But most importantly, not all documents are equal. There are some >things we probably want on standards track even though there is >other-than-royalty-free IPR (IPsec is one obvious example). This is irrelevant. We are talking about TLS extensions, not TLS itself. >Other >documents could be better off Informational/Experimental even in the >absence of any IPR. This is also irrelevant. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 14:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hre5x-0002px-TA; Fri, 25 May 2007 14:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hre5v-0002gm-Sc for tls@ietf.org; Fri, 25 May 2007 14:00:56 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hre5u-0002x1-C5 for tls@ietf.org; Fri, 25 May 2007 14:00:55 -0400 Received: from pc6 (1Cust89.tnt21.lnd4.gbr.da.uu.net [62.188.150.89]) by galaxy.systems.pipex.net (Postfix) with SMTP id 1230AE00044E; Fri, 25 May 2007 19:00:50 +0100 (BST) Message-ID: <001101c79eed$b6e5cde0$0601a8c0@pc6> From: "tom.petch" To: "Chris Newman" , , References: <07218C52A88620B12CA9BF4C@[10.0.1.21]> Subject: Re: [TLS] Straw poll on TLS SRP status Date: Fri, 25 May 2007 12:03:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" 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: , Errors-To: tls-bounces@lists.ietf.org ----- Original Message ----- From: "Chris Newman" To: ; Sent: Thursday, May 24, 2007 6:06 PM Subject: Re: [TLS] Straw poll on TLS SRP status > Pasi.Eronen@nokia.com wrote on 5/24/07 13:33 +0300: > > The question is: Do you support advancing draft-ietf-tls-srp as > > Proposed Standard? > > > > [ ] Yes. > > [ ] I think Informational/Experimental is better. > > [ ] I don't care about the status, just get it published. > > [ ] Something else, please state: > > > It's my technical opinion that adding new user-level authentication mechanisms > to the TLS layer is not a good idea in general. TLS APIs are already quite > complex and can be difficult to use. Client certificate authentication has > been there long enough that it's a known quantity how to dig the necessary > details out of the TLS layer for an application to consume, however more > traditional user-level authentication is a different beast. As GSSAPI and SASL > APIs have shown, designing general-purpose user-level authentication APIs is > very difficult, by itself tends to create APIs most people can't understand, > and it's not clear to me it's a good idea to add all that complexity to the > existing TLS APIs. I'd much rather keep user-level authentication as a > separate subsystem and promote channel bindings on the standards track instead. > > What do others on the list think about this issue? > > - Chris > I agree with you; we are making a complex technical situation (ignoring legal issues such as IPR) yet more complex which leads me to [X] Something else, please state: Do not publish this as an RFC. If this is a single transferrable preference system (I just love Irish general elections, voting was yesterday) then my second preference is [X] I think Informational/Experimental is the next less bad Tom Petch _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 14:09:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HreEe-0001vh-8v; Fri, 25 May 2007 14:09:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HreEd-0001vX-LZ for tls@ietf.org; Fri, 25 May 2007 14:09:55 -0400 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HreEc-0005xK-D4 for tls@ietf.org; Fri, 25 May 2007 14:09:55 -0400 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-2.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HreEa-0004Hx-Ov for tls@ietf.org; Fri, 25 May 2007 11:09:54 -0700 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1HreEa-0005ql-1S for tls@ietf.org; Fri, 25 May 2007 11:09:52 -0700 Date: Fri, 25 May 2007 11:09:52 -0700 (PDT) From: Tom Wu To: tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <001101c79eed$b6e5cde0$0601a8c0@pc6> Message-ID: References: <07218C52A88620B12CA9BF4C@[10.0.1.21]> <001101c79eed$b6e5cde0$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-2.Stanford.EDU X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, 25 May 2007, tom.petch wrote: > I agree with you; we are making a complex technical situation (ignoring legal > issues such as IPR) yet more complex which leads me to Given that the SRP-TLS draft does a fairly good job of containing that complexity, as evidenced by the success of its interoperating implementations, it seems this concern would be more than counterbalanced by the overall utility of having a handy solution to the password authentication+transport security problem. Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 15:16:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrfHC-0008Jp-Rn; Fri, 25 May 2007 15:16:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrfHB-0008Jk-N6 for tls@ietf.org; Fri, 25 May 2007 15:16:37 -0400 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrfHA-0003ME-F6 for tls@ietf.org; Fri, 25 May 2007 15:16:37 -0400 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.4.571.23) with ESMTP id ; Fri, 25 May 2007 12:16:35 -0700 X-Modus-ReverseDNS: OK X-Modus-BlackList: 24.219.24.139=OK;trevp@trevp.net=OK X-Modus-RBL: 24.219.24.139=Excluded X-Modus-Trusted: 24.219.24.139=NO X-Modus-Audit: TRUE;30;-1;128271609951020000 Message-ID: <46573612.7000306@trevp.net> Date: Fri, 25 May 2007 12:16:34 -0700 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [TLS] Straw poll on TLS SRP status References: <4655FE30.8000500@bolyard.com> <4655FE30.8000500@bolyard.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Errors-To: tls-bounces@lists.ietf.org Paul Hoffman wrote: > At 2:05 PM -0700 5/24/07, Nelson B Bolyard wrote: [...] >> Note that I don't think that "Informational/Experimental is better." >> but rather that it is what the WG has done in the past, and the WG >> should remain consistent, or else the chairs should explain why they >> insisted on it before and are now not doing so. > > Fully agree. And I think it is appropriate to delay the decision on > tls-srp until we have made that decision. Such a delay will not affect > developers significantly. It will, since we'd like to get IANA numbers assigned soon. I think the IPR situation is as clear as it's going to get, and the chairs are doing the best they can in polling the WG. As Pasi say, these issues are complex and situtation-dependent. It would be nice to have a clear, mechanical policy to apply, but I don't know of any WG or Standards Body with such a thing. This draft has languished long enough, let's just get rough consensus and move on. Trevor _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 25 21:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrlCa-000078-CR; Fri, 25 May 2007 21:36:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrlCZ-000072-AT for tls@ietf.org; Fri, 25 May 2007 21:36:15 -0400 Received: from larry.its.auckland.ac.nz ([130.216.10.122] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrlCX-00044M-Tn for tls@ietf.org; Fri, 25 May 2007 21:36:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D0EB4182DA; Sat, 26 May 2007 13:36:07 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cttazdFeQsM; Sat, 26 May 2007 13:36:07 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B7CE8182D7; Sat, 26 May 2007 13:36:07 +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 06D921280A1; Sat, 26 May 2007 13:36:05 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HrlCS-0008KX-00; Sat, 26 May 2007 13:36:08 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: paul.hoffman@vpnc.org Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <46573612.7000306@trevp.net> Message-Id: Date: Sat, 26 May 2007 13:36:08 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: tls-bounces@lists.ietf.org "Chris Newman" writes: > Client certificate authentication has been there long enough that it's a > known quantity how to dig the necessary details out of the TLS layer for an > application to consume And we all know how well client certs haved worked out in practice. The abject failure of TLS client-cert authentication is probably the strongest argument in favour of providing new authentication mechanisms that do actually work. > I'd much rather keep user-level authentication as a separate subsystem and > promote channel bindings on the standards track instead. >From a very abstract protocol point of view that sounds good. From a UI point of view it's terrible: You need to integrate mutual authentication directly into the crypto handshake, not have it as a separate layer. If you don't, you fall into the "connect to anything listening on the appropriate port, then hand over your credentials" trap that makes HTTP-over-TLS the phisher's best friend. A TLS handshake can have only two possibile outcomes, "connected with both sides authenticated" or "not connected". Anything else and you're just providing substrate for phishing attacks. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun May 27 04:41:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsEJZ-0005Hh-LW; Sun, 27 May 2007 04:41:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsEJY-0005HT-0Q for tls@ietf.org; Sun, 27 May 2007 04:41:24 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsEJR-0006vg-RP for tls@ietf.org; Sun, 27 May 2007 04:41:23 -0400 Received: from [172.31.21.18] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l4R8f9FB027976; Sun, 27 May 2007 11:41:09 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <259E4054-FD64-4062-A663-86EBB5942A6A@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Sun, 27 May 2007 11:41:09 +0300 To: tls@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: tls-bounces@lists.ietf.org I agree about the need to implement authentication systems that work in practice (passwords, token cards, OTP) into TLS. But still, I think the IPR issue is important here. I think it will deter all browser makers, both commercial and open source. If our goal is to allow passwords for authenticating SSL, this is not the way. So I'm going to go with [X] I think Informational/Experimental is better. Disclaimer: my opinion is somewhat biased. I'm one of the authors of http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt and I really think you should give the user the choice between IPR-laden methods (such as EAP-SRP) and IPR-free methods such as EAP-MD5. On May 26, 2007, at 4:36 AM, Peter Gutmann wrote: > "Chris Newman" writes: > >> Client certificate authentication has been there long enough that >> it's a >> known quantity how to dig the necessary details out of the TLS >> layer for an >> application to consume > > And we all know how well client certs haved worked out in > practice. The > abject failure of TLS client-cert authentication is probably the > strongest > argument in favour of providing new authentication mechanisms that > do actually > work. > >> I'd much rather keep user-level authentication as a separate >> subsystem and >> promote channel bindings on the standards track instead. > >> From a very abstract protocol point of view that sounds good. >> From a UI point > of view it's terrible: You need to integrate mutual authentication > directly > into the crypto handshake, not have it as a separate layer. If you > don't, you > fall into the "connect to anything listening on the appropriate > port, then > hand over your credentials" trap that makes HTTP-over-TLS the > phisher's best > friend. A TLS handshake can have only two possibile outcomes, > "connected with > both sides authenticated" or "not connected". Anything else and > you're just > providing substrate for phishing attacks. > > Peter. > > _______________________________________________ > 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 Sun May 27 05:11:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsEmB-0000rn-Lp; Sun, 27 May 2007 05:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsEmB-0000ri-5R for tls@ietf.org; Sun, 27 May 2007 05:10:59 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsEm9-0007J5-Ng for tls@ietf.org; Sun, 27 May 2007 05:10:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D7C9F480259; Sun, 27 May 2007 21:10:43 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEEGttoyKsLq; Sun, 27 May 2007 21:10:43 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id BF419480240; Sun, 27 May 2007 21:10:43 +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 947BA514001; Sun, 27 May 2007 21:10:43 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HsEm2-0002Mc-00; Sun, 27 May 2007 21:10:50 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tls@ietf.org, ynir@checkpoint.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <259E4054-FD64-4062-A663-86EBB5942A6A@checkpoint.com> Message-Id: Date: Sun, 27 May 2007 21:10:50 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir writes: >I'm one of the authors of >http://www.ietf.org/internet-drafts/draft-nir-tee-pm-00.txt and I really >think you should give the user the choice between IPR-laden methods (such as >EAP-SRP) and IPR-free methods such as EAP-MD5. Interesting draft [0]! However, I'd never heard of this until now, and it's not listed in the drafts on the TLS WG page either. Peter. [0] Disclaimer: I haven't read through it thoroughly yet, I'm sure I'll find something to gripe about presently :-). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun May 27 18:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsRPt-0003W6-92; Sun, 27 May 2007 18:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsRPr-0003Vq-Gc for tls@ietf.org; Sun, 27 May 2007 18:40:47 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsRPq-00071d-7u for tls@ietf.org; Sun, 27 May 2007 18:40:47 -0400 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-1.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HsRPp-0006Oe-0f for tls@ietf.org; Sun, 27 May 2007 15:40:45 -0700 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1HsRPo-0006P8-Of for tls@ietf.org; Sun, 27 May 2007 15:40:44 -0700 Date: Sun, 27 May 2007 15:40:44 -0700 (PDT) From: Tom Wu To: tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 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: , Errors-To: tls-bounces@lists.ietf.org > I really think you should give the user the choice between IPR-laden methods (such as EAP-SRP) and IPR-free methods such as EAP-MD5. As you indicate, your bias affects how you frame the issue and what premises you accept. In actuality, your point is ironically a good one in favor of making TLS-SRP Proposed, precisely because it's a good thing to have a choice between a strong password solution (TLS-SRP) and a weaker one (EAP-MD5?) in TLS. And given that SRP's licensing terms have made it the most widespread of the various strong password techniques, it's the only viable candidate for Proposed status, if you believe that it is to the benefit of the greater good to have a strong (against passive and active dictionary attack), well-tested, and standardized mechanism for password authentication over TLS. Then let the market decide. Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 28 14:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsk7y-0004pR-Qo; Mon, 28 May 2007 14:39:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsk7y-0004mx-86 for tls@ietf.org; Mon, 28 May 2007 14:39:34 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hsk7w-0001lg-U0 for tls@ietf.org; Mon, 28 May 2007 14:39:34 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2E07E33C1A for ; Mon, 28 May 2007 11:38:51 -0700 (PDT) Date: Mon, 28 May 2007 11:38:51 -0700 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070528183851.2E07E33C1A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] Comments on draft-housley-tls-authz-extns-07 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: , Errors-To: tls-bounces@lists.ietf.org Folks, We have a request from the IESG re draft-housley-tls-authz-extns-07. The IESG is considering publication of this document as a Proposed Standard. The IESG has requested that the TLS WG provide input (positive or negative) on this proposal. Please post comments to the list before Monday June 11. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 04:06:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HswiM-00024o-MP; Tue, 29 May 2007 04:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HswiL-000245-4n for tls@ietf.org; Tue, 29 May 2007 04:05:57 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HswiJ-0000dR-M2 for tls@ietf.org; Tue, 29 May 2007 04:05:57 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4T85QE0028478 for ; Tue, 29 May 2007 11:05:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 11:05:43 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 11:05:43 +0300 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] Straw poll on TLS SRP status Date: Tue, 29 May 2007 11:05:45 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll on TLS SRP status Thread-Index: Acee9CLAhmXXiXtpQdalM7rMmrcD/QC0xFKQ References: <4655FE30.8000500@bolyard.com> <4655FE30.8000500@bolyard.com> From: To: X-OriginalArrivalTime: 29 May 2007 08:05:43.0909 (UTC) FILETIME=[27F29950:01C7A1C8] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: tls-bounces@lists.ietf.org Paul Hoffman wrote: > >Note that I don't think that "Informational/Experimental is better." > >but rather that it is what the WG has done in the past, and the WG > >should remain consistent, or else the chairs should explain why they > >insisted on it before and are now not doing so. >=20 > Fully agree. And I think it is appropriate to delay the decision on=20 > tls-srp until we have made that decision. Such a delay will not=20 > affect developers significantly. While it's relatively easy to sort documents to "IPR-affected" and=20 "no significant IPR issues known" buckets, do you have any suggestions about what kinds of rules you would want for sorting documents=20 to "Standards Track" and "Informational/Experimental" buckets? In doing so, we have to follow RFC 2026 (which defines the different maturity levels) -- but at least I cannot see how any mechanical rule could be used to get that result, beyond asking WG members to exercise their judgement (i.e. what we have done so far). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 06:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HszA8-0005Fk-1o; Tue, 29 May 2007 06:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HszA7-0005Ct-3M for tls@ietf.org; Tue, 29 May 2007 06:42:47 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HszA5-0005AA-Jw for tls@ietf.org; Tue, 29 May 2007 06:42:47 -0400 Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4TAgUMU004657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 May 2007 12:42:36 +0200 From: Simon Josefsson To: Eric Rescorla References: <20070528183851.2E07E33C1A@delta.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070529:tls@ietf.org::TsjOTq4SPuQZNwuL:0pSf X-Hashcash: 1:22:070529:ekr@networkresonance.com::GNUIwOmKj//Nycen:N0NC Date: Tue, 29 May 2007 12:42:30 +0200 In-Reply-To: <20070528183851.2E07E33C1A@delta.rtfm.com> (Eric Rescorla's message of "Mon, 28 May 2007 11:38:51 -0700") Message-ID: <87tztvap2h.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: tls@ietf.org Subject: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: > Folks, > > We have a request from the IESG re draft-housley-tls-authz-extns-07. > > The IESG is considering publication of this document as a Proposed > Standard. The IESG has requested that the TLS WG provide input > (positive or negative) on this proposal. Please post comments to the > list before Monday June 11. I implemented tls-authz in gnutls some time ago and sent two technical comments in . I believe one of them is still relevant: - The size of authorization data, i.e., X.509 attribute certs and SAML assertions, are limited to 64kb. Is it certain that we won't need more? Further, as many of you are certainly aware, there are patent claims on the technology, see the IPR disclosure page at: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833 The disclosure mentions a patent license. I see two problems with the license: 1) You need to explicitly request license from RPS. This approach has worked poorly in the past. Some companies goes away and never replies to such requests, leaving implementers in a legally unclear situation. There are even examples of big companies not responding to license requests (ObExample: IBM's Unicode BOCU patent license). I believe this is sufficient to defer significant wide use of the protocol. This problem could be addressed by granting the rights in the license directly to everyone, without a need to request the license. 2) The license you get restrict use of the protocol to SAML attributes and X.509 attribute certificates that do not refer to legal contracts. This is what I have understood 'PAS functions' in the license to refer to. Whether the references must be explicit in the authorization data is probably not easy to decide. I believe there is a considerable amount of prior art for having implicit references to legal contracts in authorization data. For example, a Kerberos ticket with a principal that refer to an employee's account can be seen as an implicit reference to the employee's contract with the company, which may include a security policy that needs to be followed. Still, existence of prior art doesn't mean implementers can ignore a patent. For one project I'm involved in which is considering to use TLS-AUTHZ, we've informally realized that this situation is a non-starter, and that if we have to, we'll look into other technical solutions to achieve the same goal as tls-authz. While I am quite aware of efforts to improve the patent situation -- I have talked to Mark about the license -- I believe that until there is consensus in the IETF community that the (possibly revised) license terms are acceptable for wide deployment on the Internet, this document should not be published as a Proposed Standard. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 07:00:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HszQm-0004w4-T3; Tue, 29 May 2007 07:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HszQm-0004vz-25 for tls@ietf.org; Tue, 29 May 2007 07:00:00 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HszQV-0008Rr-Ix for tls@ietf.org; Tue, 29 May 2007 07:00:00 -0400 Received: from [172.31.24.80] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id l4TAxcFB015242; Tue, 29 May 2007 13:59:38 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <450640D7-87B3-48E0-BBDF-68A7F399A7F2@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [TLS] Straw poll on TLS SRP status Date: Tue, 29 May 2007 13:59:38 +0300 To: Tom Wu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: , Errors-To: tls-bounces@lists.ietf.org Note that I am not against SRP at all. Although the EAP-SRP effort seems to have been abandoned, it still has method type number 19 in IANA. I think SRP should not be a stand-alone extension, but rather that it should be introduced as part of EAP. The choice is between separate extensions for SRP and for each authentication method, or to introduce them all at once under EAP, as was done in IKEv2. On May 28, 2007, at 1:40 AM, Tom Wu wrote: >> I really think you should give the user the choice between IPR- >> laden methods (such as EAP-SRP) and IPR-free methods such as EAP-MD5. > > As you indicate, your bias affects how you frame the issue and what > premises you accept. In actuality, your point is ironically a good > one in favor of making TLS-SRP Proposed, precisely because it's a good > thing to have a choice between a strong password solution (TLS-SRP) > and a weaker one (EAP-MD5?) in TLS. > > And given that SRP's licensing terms have made it the most widespread > of the various strong password techniques, it's the only viable > candidate for Proposed status, if you believe that it is to the > benefit of the greater good to have a strong (against passive and > active dictionary attack), well-tested, and standardized mechanism > for password authentication over TLS. Then let the market decide. > > Tom > -- > Tom Wu > http://www-cs-students.stanford.edu/~tjw/ > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 11:28:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3cJ-0002fK-0W; Tue, 29 May 2007 11:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht3cI-0002f7-1Y for tls@ietf.org; Tue, 29 May 2007 11:28:10 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht3cG-0003so-R2 for tls@ietf.org; Tue, 29 May 2007 11:28:10 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 6EE4510027FEF for ; Tue, 29 May 2007 11:28:08 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdBEdrtIUALH for ; Tue, 29 May 2007 11:28:03 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 25A2B10027FE4 for ; Tue, 29 May 2007 11:28:03 -0400 (EDT) Received: from emilpost.certicom.com ([10.0.1.89]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP1) with ESMTP id 2007052911242703-6928 ; Tue, 29 May 2007 11:24:27 -0400 Received: by emilpost.certicom.com (Postfix, from userid 1029) id E44B9E8001; Tue, 29 May 2007 11:28:03 -0400 (EDT) Date: Tue, 29 May 2007 11:28:03 -0400 From: Brian Minard To: tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status Message-ID: <20070529152803.GG19679@certicom.com> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.9i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 05/29/2007 11:24:27 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP1|January 10, 2007) at 05/29/2007 11:24:27 AM, Serialize complete at 05/29/2007 11:24:27 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, May 24, 2007 at 01:33:32PM +0300, Pasi.Eronen@nokia.com wrote: > The question is: Do you support advancing draft-ietf-tls-srp as > Proposed Standard? > > [ ] Yes. > [ ] I think Informational/Experimental is better. > [ ] I don't care about the status, just get it published. > [ ] Something else, please state: [X] I don't care about the status, just get it published. WRT IPR concerns: the people who need to implement this need to educate themselves on what IPR exists and deal with it. Let's move the document forward. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 12:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht4A2-0004l8-9D; Tue, 29 May 2007 12:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht4A0-0004kz-Su for tls@ietf.org; Tue, 29 May 2007 12:03:00 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht49z-0003jM-H0 for tls@ietf.org; Tue, 29 May 2007 12:03:00 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l4TG2v8K044352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 May 2007 09:02:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4655FE30.8000500@bolyard.com> <4655FE30.8000500@bolyard.com> Date: Tue, 29 May 2007 09:02:53 -0700 To: , From: Paul Hoffman Subject: RE: [TLS] Straw poll on TLS SRP status Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tls-bounces@lists.ietf.org At 11:05 AM +0300 5/29/07, wrote: >Paul Hoffman wrote: > >> >Note that I don't think that "Informational/Experimental is better." >> >but rather that it is what the WG has done in the past, and the WG >> >should remain consistent, or else the chairs should explain why they >> >insisted on it before and are now not doing so. >> >> Fully agree. And I think it is appropriate to delay the decision on >> tls-srp until we have made that decision. Such a delay will not >> affect developers significantly. > >While it's relatively easy to sort documents to "IPR-affected" and >"no significant IPR issues known" buckets, do you have any suggestions >about what kinds of rules you would want for sorting documents >to "Standards Track" and "Informational/Experimental" buckets? My preference is "IPR-affected" all go into the "Informational/Experimental" bucket. My main reasons for that are: - It will stop this repetitive discussion - The "lower" status of Informational or Experimental is irrelevant to users but seems relevant to some developers --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 12:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht4xU-0004yr-Ey; Tue, 29 May 2007 12:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht4xS-0004yW-RE for tls@ietf.org; Tue, 29 May 2007 12:54:06 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht4xR-0005rl-Dt for tls@ietf.org; Tue, 29 May 2007 12:54:06 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id SAA14113; Tue, 29 May 2007 18:53:50 +0200 (MESZ) From: Martin Rex Message-Id: <200705291653.l4TGrodx029463@fs4113.wdf.sap.corp> Subject: Re: [TLS] Straw poll on TLS SRP status To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 29 May 2007 18:53:50 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at May 26, 7 01:36:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: paul.hoffman@vpnc.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.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: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > "Chris Newman" writes: > > Client certificate authentication has been there long enough that it's a > > known quantity how to dig the necessary details out of the TLS layer for an > > application to consume > > And we all know how well client certs haved worked out in practice. > The abject failure of TLS client-cert authentication is probably the > strongest argument in favour of providing new authentication mechanisms > that do actually work. We are happily using SSL with client certs for 30k+ users with a number of different servers and we've been using it productively for 6 years now (started using it 1999). Initially there were a few bugs in MSIE, but they've been fixed a few years ago. Right now, the largest remaining issue for the most commonly used platform is a Hotfix for WinHTTP that IIRC is not yet available for public download. One observation about SSL client certificate verification: you absolutely do NOT want revocation checking or any kind of fancy path validation (policy constraints and other bullshit) be done within the TLS stack. Everything that involves communication to third parties or additional computational processing will have to be done at a point where it scales (i.e. in the backend server farm) or it will kill throughput in a large server and ambitions for high availability. > > > I'd much rather keep user-level authentication as a separate subsystem and > > promote channel bindings on the standards track instead. > > From a very abstract protocol point of view that sounds good. From a UI point > of view it's terrible: You need to integrate mutual authentication directly > into the crypto handshake, not have it as a separate layer. If you don't, you > fall into the "connect to anything listening on the appropriate port, then > hand over your credentials" trap that makes HTTP-over-TLS the phisher's best > friend. A TLS handshake can have only two possibile outcomes, "connected with > both sides authenticated" or "not connected". Anything else and you're just > providing substrate for phishing attacks. I agree that for User-level (or more precisely app-level) authentication is the preferable approach for pretty much all scenarios that are not (or not yet) native SSL/TLS, including passwords and GSS-API authentication (e.g. rfc-4559). It scales much better and it is much easier to adapt to custom requirements (of legacy authentication systems). Having to mess with the _entire_ middleware (SSL/TLS and backend communication layers directly above it) each time an additional authentication scheme (or additional attribute of an existing scheme) needs to be supported is the nightmare scenario for software maintenance, especially if there are thrid-party components (like SSL Accellerators or reverse proxies) are involved. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 13:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5Qh-0003xH-C9; Tue, 29 May 2007 13:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5Qf-0003xB-LK for tls@ietf.org; Tue, 29 May 2007 13:24:17 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht5Qc-0005ko-3z for tls@ietf.org; Tue, 29 May 2007 13:24:17 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l4THOD7x019323 for ; Tue, 29 May 2007 13:24:13 -0400 (EDT) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Tue, 29 May 2007 13:24:13 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 May 2007 13:24:13 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Straw poll on TLS SRP status Date: Tue, 29 May 2007 13:23:51 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll on TLS SRP status Thread-Index: AcefNksUsYvYHIxUSz+lvTqir1ePmAC2pm2w References: <46573612.7000306@trevp.net> From: "Kemp, David P." To: X-OriginalArrivalTime: 29 May 2007 17:24:13.0650 (UTC) FILETIME=[2D4F4B20:01C7A216] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15206000 X-TM-AS-Result: : Yes--16.699000-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny03MDk1?= =?us-ascii?B?ODQtMTE0Mjg5LTcwNTkwMS03MDI3NjItMTA2NTgwLTcwMTY3Ni03?= =?us-ascii?B?MDI2MzgtNzAwNTQ2LTcwMjM1OC03MDA3ODMtNzAxNzQxLTcwODg1?= =?us-ascii?B?NS03MDcxMTQtNzAxNTc2LTcwMjM3Ni0xMzkwMDYtNzAyNjQ1LTEy?= =?us-ascii?B?MTY1Mi03MDEyMDctNzAwMDczLTcwMzczMS0xMzkwMTAtNzAyNzI2?= =?us-ascii?B?LTcwMTYxOC03MDgxNzktNzAxMjAyLTcwNDQyNS03MDQ5ODAtNzA1?= =?us-ascii?B?Mzg4LTcwMDcyNi03MDA3NTYtNzA3MTgyLTEyMTE1NS03MDIzMTMt?= =?us-ascii?B?NzAzODM1LTcwMTQ1NS03MDIwMjAtNzAwNjY3LTcwMjI2MC03MDcy?= =?us-ascii?B?MjUtNzAxMjQ5LTEzOTcwMy03MDAwNDctMTQ4MDUwLTIwMDQw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: tls-bounces@lists.ietf.org We all know that there are communities where client certs have worked quite well in practice. Based on that experience, we are at the point of arguing not over whether client certs should be used (they are) but whether smartcards should be required or software is good enough. Try banging on Google's top entry for "defense online" without a cert; there is a huge community of users with certs who use it every day. But if password-based authentication must be used, I agree that it must be as tightly bound to session establishment as client certs currently are. Perhaps that will be achieved in practice with "separate subsystem with channel bindings", perhaps not. Cert operations are handed over to the PKCS-11 subsystem yet are still bound to the handshake; in principle a PBE subsystem and binding interface could be implemented with equal care. Dave -----Original Message----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Friday, May 25, 2007 9:36 PM To: paul.hoffman@vpnc.org Cc: tls@ietf.org Subject: Re: [TLS] Straw poll on TLS SRP status "Chris Newman" writes: > Client certificate authentication has been there long enough that it's a=20 > known quantity how to dig the necessary details out of the TLS layer for an=20 > application to consume And we all know how well client certs haved worked out in practice. The abject failure of TLS client-cert authentication is probably the strongest argument in favour of providing new authentication mechanisms that do actually work. > I'd much rather keep user-level authentication as a separate subsystem and > promote channel bindings on the standards track instead. >From a very abstract protocol point of view that sounds good. From a UI point of view it's terrible: You need to integrate mutual authentication directly into the crypto handshake, not have it as a separate layer. If you don't, you fall into the "connect to anything listening on the appropriate port, then hand over your credentials" trap that makes HTTP-over-TLS the phisher's best friend. A TLS handshake can have only two possibile outcomes, "connected with both sides authenticated" or "not connected". Anything else and you're just providing substrate for phishing attacks. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 13:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5TX-0005Ug-Qf; Tue, 29 May 2007 13:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5TW-0005Ua-9o for tls@ietf.org; Tue, 29 May 2007 13:27:14 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht5TU-0006rA-Ul for tls@ietf.org; Tue, 29 May 2007 13:27:14 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id TAA21154; Tue, 29 May 2007 19:27:01 +0200 (MESZ) From: Martin Rex Message-Id: <200705291727.l4THR2qm002147@fs4113.wdf.sap.corp> Subject: Re: [TLS] Straw poll on TLS SRP status To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Tue, 29 May 2007 19:27:02 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at May 29, 7 09:02:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.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: , Errors-To: tls-bounces@lists.ietf.org [X] I think Informational/Experimental is better. Paul Hoffman wrote: > > My preference is "IPR-affected" all go into the > "Informational/Experimental" bucket. My main reasons for that are: > > - It will stop this repetitive discussion > > - The "lower" status of Informational or Experimental is irrelevant > to users but seems relevant to some developers The document status is pretty much the only "incentive" that the IETF can put out for companies to slow down on their patents race or at least to come up with reasonable licensing terms (i.e. royalty free for Free and OpenSource software). Even Lucent could come up with an IPR statement describing under what terms they will be licensing their patent(s) should they ever come to the conclusion that their any of their patent(s) apply, and that they have not made any such determination so far. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 13:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5x1-0004Ia-KZ; Tue, 29 May 2007 13:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht5x0-0004Ep-2L for tls@ietf.org; Tue, 29 May 2007 13:57:42 -0400 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht5wy-0002sx-Rc for tls@ietf.org; Tue, 29 May 2007 13:57:42 -0400 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l4THveBt021674 for ; Tue, 29 May 2007 13:57:40 -0400 (EDT) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Tue, 29 May 2007 13:57:40 -0400 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 29 May 2007 13:57:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Straw poll on TLS SRP status Date: Tue, 29 May 2007 13:57:38 -0400 Message-ID: In-Reply-To: <200705291653.l4TGrodx029463@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll on TLS SRP status Thread-Index: AceiEgZrF6aZ117tSPKEZPB5LfkNGgABgaAw References: from "PeterGutmann" at May 26, 7 01:36:08 pm <200705291653.l4TGrodx029463@fs4113.wdf.sap.corp> From: "Kemp, David P." To: X-OriginalArrivalTime: 29 May 2007 17:57:40.0436 (UTC) FILETIME=[D9728940:01C7A21A] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-15206000 X-TM-AS-Result: : Yes--4.456700-0-2-1 X-TM-AS-Category-Info: : 2:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE4LTE1MDU2Ny0xMzkw?= =?us-ascii?B?MTAtNzAwMDczLTcwNTgzNy0xMTQyODktNzAxNTk0LTEyMTEyNC03?= =?us-ascii?B?MDE1NzYtNzA0NTc4LTcwMTYxOC03MDM1MTctMTIxMTA4LTcwNDY4?= =?us-ascii?B?MC03MDAzNTEtNzAwNzgzLTE0ODA1MC0yMDA0MC0xNTkxMw==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: tls-bounces@lists.ietf.org > From: Martin Rex [mailto:Martin.Rex@sap.com] >=20 > We are happily using SSL with client certs for 30k+ users with > a number of different servers and we've been using it productively > for 6 years now (started using it 1999). Ditto, for 4.3 million users. Ditto for the implementation concerns surrounding revocation, which for certs can be addressed in a scalable manner. I have doubts that password-based SSO schemes can achieve a similar level of scalability. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 14:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht68r-0001tk-5t; Tue, 29 May 2007 14:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht68p-0001qC-Hd for tls@ietf.org; Tue, 29 May 2007 14:09:55 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht68o-00087E-4q for tls@ietf.org; Tue, 29 May 2007 14:09:55 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA08573; Tue, 29 May 2007 20:09:49 +0200 (MESZ) From: Martin Rex Message-Id: <200705291809.l4TI9nu0005584@fs4113.wdf.sap.corp> Subject: Re: [TLS] Straw poll on TLS SRP status To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Tue, 29 May 2007 20:09:49 +0200 (MEST) In-Reply-To: from "Kemp, David P." at May 29, 7 01:23:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.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: , Errors-To: tls-bounces@lists.ietf.org Kemp, David P. wrote: > > We all know that there are communities where client certs have worked > quite well in practice. Based on that experience, we are at the point > of arguing not over whether client certs should be used (they are) but > whether smartcards should be required or software is good enough. Try > banging on Google's top entry for "defense online" without a cert; there > is a huge community of users with certs who use it every day. I'm not very familiar with the various kinds of support for crypto hardware that is out there, or those that you're thinking of. The one that I know (available for the OEM software that we ship) performs only the secret key operations in hardware (on the smartcard) because its primary function is to not reveal the private key. Even if there were smartcards able to hold arbirarily large and complex lists of trust anchors and able to independently build certificate chains and perform path validations -- as long as the security critical action is performed in regular software, that software can be trojaned (skipping the PKI checks or ignore the results). I see one area where an improvement might be useful (at least for those platforms where users do not always work with full privileges, and where we believe that there exists some level of effective privilege seperation): have the private-key operations performed by a privileged system service rather than entirely within the process space of the user application, sort-of a software-smartcard. > > But if password-based authentication must be used, I agree that it must > be as tightly bound to session establishment as client certs currently > are. Perhaps that will be achieved in practice with "separate subsystem > with channel bindings", perhaps not. Cert operations are handed over to > the PKCS-11 subsystem yet are still bound to the handshake; in principle > a PBE subsystem and binding interface could be implemented with equal > care. Just that we currently don't have suitable channel bindings in the installed base of SSL/TLS that will work transparently accross all deployed scenarios (some of which are using seperate consecutive but independently protected communication links). A re-encrypting reverse proxy (including SSL Accellerators) is probably the most common multi-hop scenario. But if the nature of SSL/TLS channel bindings is defined and nailed down, then the existing deployments may be adopting means to transfer them in multi-hop scenarios in similar fashions how they make SSL client-cert authentication work in multi-hop scenarios, and that work must only be done once. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 15:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht6wS-0003h4-8B; Tue, 29 May 2007 15:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht6wQ-0003gu-4M for tls@ietf.org; Tue, 29 May 2007 15:01:10 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ht6wO-00053l-Q1 for tls@ietf.org; Tue, 29 May 2007 15:01:10 -0400 Received: (qmail 31995 invoked by uid 0); 29 May 2007 19:01:02 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.66.103.218) by woodstock.binhost.com with SMTP; 29 May 2007 19:01:02 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 May 2007 15:01:05 -0400 To: Simon Josefsson From: Russ Housley Subject: Re: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 In-Reply-To: <87tztvap2h.fsf@mocca.josefsson.org> References: <20070528183851.2E07E33C1A@delta.rtfm.com> <87tztvap2h.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Simon: > > We have a request from the IESG re draft-housley-tls-authz-extns-07. I see many places where authorization will be useful. I would like to see this document get published as a standards track RFC. I will also reply to Simon's comments. > > The IESG is considering publication of this document as a Proposed > > Standard. The IESG has requested that the TLS WG provide input > > (positive or negative) on this proposal. Please post comments to the > > list before Monday June 11. > >I implemented tls-authz in gnutls some time ago and sent two technical >comments in . I believe >one of them is still relevant: > >- The size of authorization data, i.e., X.509 attribute certs and SAML > assertions, are limited to 64kb. Is it certain that we won't need > more? I recall responding to this the first time around. I said that I could not imagine needing 64KB for X.509 Attribute Certificates, but I do not have experience with SAML Assertions. I know they are bigger, but I do not have any way to gauge the likelihood that 64KB will not be enough. >Further, as many of you are certainly aware, there are patent claims on >the technology, see the IPR disclosure page at: > >https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833 > >The disclosure mentions a patent license. I see two problems with the >license: > >1) You need to explicitly request license from RPS. This approach has > worked poorly in the past. Some companies goes away and never > replies to such requests, leaving implementers in a legally unclear > situation. There are even examples of big companies not responding > to license requests (ObExample: IBM's Unicode BOCU patent license). > I believe this is sufficient to defer significant wide use of the > protocol. > > This problem could be addressed by granting the rights in the license > directly to everyone, without a need to request the license. > >2) The license you get restrict use of the protocol to SAML attributes > and X.509 attribute certificates that do not refer to legal > contracts. This is what I have understood 'PAS functions' in the > license to refer to. Whether the references must be explicit in the > authorization data is probably not easy to decide. > > I believe there is a considerable amount of prior art for having > implicit references to legal contracts in authorization data. For > example, a Kerberos ticket with a principal that refer to an > employee's account can be seen as an implicit reference to the > employee's contract with the company, which may include a security > policy that needs to be followed. Still, existence of prior art > doesn't mean implementers can ignore a patent. > > For one project I'm involved in which is considering to use > TLS-AUTHZ, we've informally realized that this situation is a > non-starter, and that if we have to, we'll look into other technical > solutions to achieve the same goal as tls-authz. > >While I am quite aware of efforts to improve the patent situation -- I >have talked to Mark about the license -- I believe that until there is >consensus in the IETF community that the (possibly revised) license >terms are acceptable for wide deployment on the Internet, this document >should not be published as a Proposed Standard. I see many places where authorization will be useful, and in many, if not most, of these places the RedPhone Security IPR does not seem to apply. This is my assessment, and I am not a lawyer. I know that the most recent IPR statement from RedPhone Security does not satisfy Simon, and I hope that will be resolved in the near future. Even if that turns out to take a long time, the protocol extensions will be useful in the contexts where the RedPhone Security IPR does not apply., Of course, the applicability must be judged by the implementors and users, not by me. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 17:13:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht905-0001Yj-0w; Tue, 29 May 2007 17:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht903-0001Xf-IM; Tue, 29 May 2007 17:13:03 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht902-0001fr-77; Tue, 29 May 2007 17:13:03 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l4TLD0l9003720 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 29 May 2007 17:13:00 -0400 Date: Tue, 29 May 2007 17:12:59 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: <20070528183851.2E07E33C1A@delta.rtfm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Errors-To: tls-bounces@lists.ietf.org I believe the IETF announced that it would be sending this draft back to the 'starting gate'. To me, that means that TLS has to do several things: 1) Consider non-patented alternatives in accordance with RFC2418 and RFC3979. 2) Obtain a thorough review and consensus per RFC2026 and RFC2418. 3) Pass a working group last-call, per RFC2026 and RFC2418. So, the TLS working group should consider and process the draft as though it were just now submitted for the first time. As I understand the IESG position, it is not considering publication at the present time, and the document is not presently on the IESG agenda, and will not be on the agenda until a last-call is requested by the TLS working group chair. If my understanding is not correct, please correct me. With the above understanding: I am against the current draft as it stands on the grounds that it is patented, and a non-patented alternative is easily found. No non-patented alternative has been discussed. This is a technical objection. Furthermore, I oppose the corrupt acts of the IETF official in concealing the patent from the IESG while accepting money to write and promote the draft. The authors have already admitting to both knowing of the patent and knowing of the IETF patent policy for the entire development of the draft, and still concealed the patent from the IESG and IETF community. A software patent is often worth millions of dollars for justification of investment capital (that doesn't count the economic harms, though). A patented software standard is worth many times more. The economic motives of the deception are impossible to avoid, and while this isn't entirely a technical objection [though it is an objection based on the abuse of IETF process by the authors as permitted by RFC2026], I think a moral and ethical objection to this draft is quite appropriate and allowed by RFC2026. --Dean On Mon, 28 May 2007, Eric Rescorla wrote: > Folks, > > We have a request from the IESG re draft-housley-tls-authz-extns-07. > > The IESG is considering publication of this document as a Proposed > Standard. The IESG has requested that the TLS WG provide input > (positive or negative) on this proposal. Please post comments to the > list before Monday June 11. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 17:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9Fc-0004cu-0o; Tue, 29 May 2007 17:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9Fa-0004cQ-IG; Tue, 29 May 2007 17:29:06 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht9FZ-0005kh-5j; Tue, 29 May 2007 17:29:06 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l4TLT4bE003726 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 29 May 2007 17:29:04 -0400 Date: Tue, 29 May 2007 17:29:03 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: , Errors-To: tls-bounces@lists.ietf.org [I corrected a couple things] I believe the IESG announced that it would be sending this draft back to the 'starting gate'. To me, that means that TLS has to do several things: 1) Consider non-patented alternatives in accordance with RFC2418 and RFC3979. 2) Obtain a thorough review and consensus per RFC2026 and RFC2418. 3) Pass a working group last-call, per RFC2026 and RFC2418. So, the TLS working group should consider and process the draft as though it were just now submitted for the first time. As I understand the IESG position, it is not considering publication at the present time, and the document is not presently on the IESG agenda, and will not be on the agenda until a last-call is requested by the TLS working group chair. If my understanding is not correct, please correct me. With the above understanding: I am against the current draft as it stands on the grounds that it is patented, and a non-patented alternative is easily found. No non-patented alternative has been discussed. This is a technical objection. Furthermore, I oppose the corrupt acts of the IETF official in concealing the patent from the IESG while accepting money to write and promote the draft. The authors have already admitted to both knowing of the patent and knowing of the IETF patent policy for the entire development of the draft, and still concealed the patent from the IESG and IETF community. A software patent is often worth millions of dollars for justification of investment capital (that doesn't count the economic harms, though). A patented software standard is worth many times more. The economic motives of the deception are impossible to avoid, and while this isn't entirely a technical objection [though it is an objection based on the abuse of IETF process by the authors as permitted by RFC2026], I think a moral and ethical objection to this draft is quite appropriate and allowed by RFC2026. --Dean On Mon, 28 May 2007, Eric Rescorla wrote: > Folks, > > We have a request from the IESG re draft-housley-tls-authz-extns-07. > > The IESG is considering publication of this document as a Proposed > Standard. The IESG has requested that the TLS WG provide input > (positive or negative) on this proposal. Please post comments to the > list before Monday June 11. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 18:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtA3Q-0002Xd-GI; Tue, 29 May 2007 18:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtA3O-0002XA-Fn; Tue, 29 May 2007 18:20:34 -0400 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtA3N-00076j-6B; Tue, 29 May 2007 18:20:34 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id D2D5E33C4A; Tue, 29 May 2007 15:19:46 -0700 (PDT) Date: Tue, 29 May 2007 15:19:46 -0700 From: Eric Rescorla To: Dean Anderson Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: References: <20070528183851.2E07E33C1A@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070529221946.D2D5E33C4A@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: iesg@ietf.org, 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: , Errors-To: tls-bounces@lists.ietf.org At Tue, 29 May 2007 17:12:59 -0400 (EDT), Dean Anderson wrote: > > I believe the IETF announced that it would be sending this draft back to > the 'starting gate'. To me, that means that TLS has to do several > things: > > 1) Consider non-patented alternatives in accordance with RFC2418 and > RFC3979. > > 2) Obtain a thorough review and consensus per RFC2026 and RFC2418. > > 3) Pass a working group last-call, per RFC2026 and RFC2418. > > So, the TLS working group should consider and process the draft as > though it were just now submitted for the first time. Dean, That is not correct. This is (and was) an AD sponsored submission. The TLS WG was previously asked if it wished to take on this document and said no. The question of whether this document should go back to ground zero (i.e., as if that discussion had not taken place) is not really an appropriate one for this group and should be addressed to the IESG or the IETF mailing list. If you want to argue that TLS-WG SHOULD take up this kind of work, that is of course approriate, but it's not a procedural requirement here. > As I understand the IESG position, it is not considering publication at > the present time, and the document is not presently on the IESG agenda, > and will not be on the agenda until a last-call is requested by the TLS > working group chair. If my understanding is not correct, please correct > me. This is incorrect. The IESG is now considering publication and it is in that context that they asked the TLS WG for its opinion. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 29 22:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtE4D-0002t1-HT; Tue, 29 May 2007 22:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtE4C-0002sv-1Y for tls@ietf.org; Tue, 29 May 2007 22:37:40 -0400 Received: from conn.mc.mpls.visi.com ([208.42.156.2] helo=conn-smtp.mc.mpls.visi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtE4A-0001Gb-PK for tls@ietf.org; Tue, 29 May 2007 22:37:40 -0400 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id B5ECF83EE for ; Tue, 29 May 2007 21:37:37 -0500 (CDT) From: "Mark Brown" To: References: <20070528183851.2E07E33C1A@delta.rtfm.com> Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 Date: Tue, 29 May 2007 21:38:19 -0500 Message-ID: <000a01c7a263$975858c0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcehV5xPZYXkzI12SYOopbKNIIUD2AA4wtVg In-Reply-To: <20070528183851.2E07E33C1A@delta.rtfm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: tls-bounces@lists.ietf.org A few points I think are relevant: 1) The RedPhone Security (RPS) patent application and its General Use License (GUL) protect a *new* method of verifying authorizations. 2) If it's been published or in use prior to RPS's patent filing, then *any* such method of verifying authorizations is "prior art", and can be used with tls-authz under the GUL. There are a lot of prior specs in this area... And of course you're free to invent new verification methods, etc. Only one method is reserved by RPS under the GUL. 3) tls-authz doesn't specify any method for verifying authorizations The GUL provides a way to be sure that RPS won't raise any claims of infringement against you (except obviously the PAS functions). Since nobody knows precisely which RPS patent claims will issue, executing a GUL may help to alleviate concerns right now. The RedPhone Security GUL amounts to a way to guarantee for yourself that Sending any "prior art" SAML / AC assertions over TLS will be royalty-free. On the whole it's your choice to use the GUL or not. I'm glossing over some details, but these are the main issues. I think we all would benefit from agreeing there is value in authorizing TLS sessions using assertions, that the tls-authz mechanics are straightforward (and don't favor RPS IPR), and that using all prior art authorization methods should be -- and can easily be -- royalty-free under tls-authz and the RedPhone Security GUL. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 03:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJ51-0002fw-A8; Wed, 30 May 2007 03:58:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJ4z-0002fq-Vr for tls@ietf.org; Wed, 30 May 2007 03:58:49 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJ4y-0003ci-Gs for tls@ietf.org; Wed, 30 May 2007 03:58:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U7wdSE031480; Wed, 30 May 2007 10:58:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:58:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:58:40 +0300 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: Comments on draft-housley-tls-authz-extns-07 Date: Wed, 30 May 2007 10:58:39 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 Thread-Index: AceiI8T4+lWYjDeuQUGR49801uaxgAAanxbQ References: <20070528183851.2E07E33C1A@delta.rtfm.com><87tztvap2h.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 30 May 2007 07:58:40.0486 (UTC) FILETIME=[55FB2060:01C7A290] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > >- The size of authorization data, i.e., X.509 attribute=20 > > certs and SAML assertions, are limited to 64kb. Is it certain=20 > > that we won't need more? >=20 > I recall responding to this the first time around. I said that=20 > I could not imagine needing 64KB for X.509 Attribute Certificates,=20 > but I do not have experience with SAML Assertions. I know they=20 > are bigger, but I do not have any way to gauge the likelihood=20 > that 64KB will not be enough. One relatively simple SAML assertion example from the SAML specs=20 is 3.5 KB. If it used 4096-bit RSA keys instead of 1024, and=20 included holder-of-key SubjectConfirmation block, it would be=20 maybe 6 KB. If it included more complex assertions or additional=20 certificates, it could get over 10 KB. IMHO the safety margin is too small for "64K ought to be enough for everyone" :-) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 04:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJ68-0003Fz-Ob; Wed, 30 May 2007 04:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJ67-0003F6-IQ for tls@ietf.org; Wed, 30 May 2007 03:59:59 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJ66-0004gw-2Z for tls@ietf.org; Wed, 30 May 2007 03:59:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4U7xhbv014798 for ; Wed, 30 May 2007 10:59:56 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:59:43 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:59:43 +0300 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] Comments on draft-housley-tls-authz-extns-07 Date: Wed, 30 May 2007 10:59:42 +0300 Message-ID: In-Reply-To: <20070528183851.2E07E33C1A@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Comments on draft-housley-tls-authz-extns-07 Thread-Index: AcehV5t0tvIn66fkTUieSoPicgDO2QBNlh8A References: <20070528183851.2E07E33C1A@delta.rtfm.com> From: To: X-OriginalArrivalTime: 30 May 2007 07:59:43.0079 (UTC) FILETIME=[7B4A0F70:01C7A290] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > We have a request from the IESG re draft-housley-tls-authz-extns-07. >=20 > The IESG is considering publication of this document as a Proposed > Standard. The IESG has requested that the TLS WG provide input > (positive or negative) on this proposal. Please post comments to the > list before Monday June 11. Basically repeating the comments I made during the second IETF=20 last call: - I think this document is somewhat useful; and given that there are others who seem to share this view -- and basically nobody has claimed that the technical solution is flawed or undesirable -- I think IESG should publish this document. IMHO not publishing this as a form of punishment would be a wrong thing to do. - IMHO the most appropriate status would be Experimental. - As was already pointed out by others, the IESG should use this opportunity (before we have deployments) to change the length fields from 16 bits to 24 bits (the rest of TLS already uses 24-bit length fields for certificates). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 05:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKgL-0005z8-BZ; Wed, 30 May 2007 05:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKgJ-0005z3-Vu for tls@ietf.org; Wed, 30 May 2007 05:41:27 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKgI-0006Pz-IJ for tls@ietf.org; Wed, 30 May 2007 05:41:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3A55D480285; Wed, 30 May 2007 21:41:19 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPtFF+pqxeYq; Wed, 30 May 2007 21:41:19 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1F791480273; Wed, 30 May 2007 21:41:19 +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 BD68C1440001; Wed, 30 May 2007 21:41:18 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HtKgH-0005PK-00; Wed, 30 May 2007 21:41:25 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, tls@ietf.org Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: Message-Id: Date: Wed, 30 May 2007 21:41:25 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com writes: >I think this document is somewhat useful; and given that there are others who >seem to share this view -- and basically nobody has claimed that the >technical solution is flawed or undesirable -- I think IESG should publish >this document. IMHO not publishing this as a form of punishment would be a >wrong thing to do. One potential problem with it is that we're seeing a pile of alternative- authentication-method proposals for TLS, and there may be better (more flexible or compatible-with-existing) ways of doing this. In addition since there does seem to be a fair bit of interest in this, having a universal framework to handle it and then allowing individual mechanisms as profiles within the framework may be a better approach. At the moment we have two ways to do TLS-alternative-auth, either make it part of the TLS handshake (that is, modify the crypto portion of the TLS handshake), or add it as a TLS extension protocol. The former approach is used by TLS-KRB5, TLS-PSK, and TLS-SRP. The latter approach is used by (at least) TLS-Authz and TLS-EAP (and I think I may have seen one or two probably now-expired drafts float past in the past as well). If this is a useful way to handle it, then it looks like the question is "Which of TLS-Authz, TLS-EAP, (or potential other approaches) provides the better framework for defining extensible authentication services within TLS?". Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 06:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtL4j-0003Ba-T4; Wed, 30 May 2007 06:06:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtL4j-0003BN-9d for tls@ietf.org; Wed, 30 May 2007 06:06:41 -0400 Received: from vinyl.extundo.com ([83.241.192.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtL4h-0002JU-SH for tls@ietf.org; Wed, 30 May 2007 06:06:41 -0400 Received: from mocca.josefsson.org (38.177.241.83.in-addr.dgcsystems.net [83.241.177.38]) (authenticated bits=0) by vinyl.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l4UA6CuO019484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 May 2007 12:06:22 +0200 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:070530:pasi.eronen@nokia.com::brc6LGplsc5PDvMc:3/Kf X-Hashcash: 1:22:070530:pgut001@cs.auckland.ac.nz::WqYD+poDLOfi4e5h:FcES X-Hashcash: 1:22:070530:tls@ietf.org::DroeyoC7ErUbGJaM:0B4Qw Date: Wed, 30 May 2007 12:06:11 +0200 In-Reply-To: (Peter Gutmann's message of "Wed, 30 May 2007 21:41:25 +1200") Message-ID: <87ps4i62y4.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tls@ietf.org Subject: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 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: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Pasi.Eronen@nokia.com writes: > >>I think this document is somewhat useful; and given that there are others who >>seem to share this view -- and basically nobody has claimed that the >>technical solution is flawed or undesirable -- I think IESG should publish >>this document. IMHO not publishing this as a form of punishment would be a >>wrong thing to do. > > One potential problem with it is that we're seeing a pile of alternative- > authentication-method proposals for TLS, and there may be better (more > flexible or compatible-with-existing) ways of doing this. In addition since > there does seem to be a fair bit of interest in this, having a universal > framework to handle it and then allowing individual mechanisms as profiles > within the framework may be a better approach. > > At the moment we have two ways to do TLS-alternative-auth, either make it part > of the TLS handshake (that is, modify the crypto portion of the TLS > handshake), or add it as a TLS extension protocol. The former approach is > used by TLS-KRB5, TLS-PSK, and TLS-SRP. The latter approach is used by (at > least) TLS-Authz and TLS-EAP (and I think I may have seen one or two probably > now-expired drafts float past in the past as well). > > If this is a useful way to handle it, then it looks like the question is > "Which of TLS-Authz, TLS-EAP, (or potential other approaches) provides the > better framework for defining extensible authentication services within TLS?". Hold on! Tls-authz isn't about authentication. It is about authorization. Authorization is (or at least could be) orthogonal to authentication. I haven't seen many competing proposals to solve authorization in TLS, although the technology is simple if you know about TLS and the authorization concept. Btw, one approach to support TLS-alternative-auth is to write profiles of TLS-PSK for each alternative authentication mechanism. The mechanism has to be able to generate cryptographic keys, but I believe good authentication mechanisms (should) have this property. Then no changes to TLS would be required. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 06:16:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLEO-0000BI-E9; Wed, 30 May 2007 06:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtLEN-0000BD-Rv for tls@ietf.org; Wed, 30 May 2007 06:16:39 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtLEM-0004Ou-6X for tls@ietf.org; Wed, 30 May 2007 06:16:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C7FA0480273; Wed, 30 May 2007 22:16:28 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0WBb7cpvxvK; Wed, 30 May 2007 22:16:28 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id AD431480272; Wed, 30 May 2007 22:16:28 +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 414ECD14CFB; Wed, 30 May 2007 22:16:27 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HtLEI-0005zu-00; Wed, 30 May 2007 22:16:34 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <200705291653.l4TGrodx029463@fs4113.wdf.sap.corp> Message-Id: Date: Wed, 30 May 2007 22:16:34 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: paul.hoffman@vpnc.org, 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: , Errors-To: tls-bounces@lists.ietf.org >We are happily using SSL with client certs for 30k+ users with a number of >different servers and we've been using it productively for 6 years now >(started using it 1999). The reason I made the comment about TLS client auth being an abject failure is that every time anyone mentions the possibility of providing any other way of authenticating clients and servers, it's practically guaranteed that someone will pop out of the woodwork and state that we already have the perfect solution to authentication in the form of client certs (see e.g. the comments made during the TLS-PSK last call), and here's a special-case stovepipe deployment with a captive audience as incontrovertible proof that client certs are perfectly workable in the real world. In the meantime we have a multi- billion doller phishing industry as proof that if certificate-based authentication is working then it's a very peculiar interpretation of the term "working". At the moment for 99.9% of users if they want to do authentication to Amazon, to Hotmail, to Flickr, to almost anything out there (in other words the very situation where client-cert-auth was supposed to be used) then the state-of- the-art solution that TLS provides is to connect to the server and hand over a static password in plaintext form (over the TLS channel), circa 1965. The ultimate indictment of TLS certificate-based auth has to be the fact that when I want to authenticate myself for the NIST PKI Workshop (the premier PKI get- together AFAIK), I have to use a static password. Anyway, my point is that the No.1 threat (by a long shot) to TLS users today is phishing, and it works because (as stated above) the best way that we have of handling authentication is by handing over the password. So we urgently need to come up with some alternative (Authz, EAP, whatever) that at least provides the tools to combat phishing. I'm somewhat biased towards EAP because it provides (at least in theory :-) a universal mechanism that would allow companies to leverage their existing authentication infrastructure. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 11:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPtN-0006Ro-Uh; Wed, 30 May 2007 11:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtPtN-0006Re-0O for tls@ietf.org; Wed, 30 May 2007 11:15:17 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtPtL-0006jT-JL for tls@ietf.org; Wed, 30 May 2007 11:15:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7BD2C4802BF; Thu, 31 May 2007 03:15:09 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB6EAisg1JY6; Thu, 31 May 2007 03:15:09 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6096A48028F; Thu, 31 May 2007 03:15:09 +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 A086ED14CFB; Thu, 31 May 2007 03:15:08 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HtPtO-0002Rn-00; Thu, 31 May 2007 03:15:18 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tjw@CS.Stanford.EDU, ynir@checkpoint.com Subject: Re: [TLS] Straw poll on TLS SRP status In-Reply-To: <450640D7-87B3-48E0-BBDF-68A7F399A7F2@checkpoint.com> Message-Id: Date: Thu, 31 May 2007 03:15:18 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: tls-bounces@lists.ietf.org Yoav Nir writes: >I think SRP should not be a stand-alone extension, but rather that it should >be introduced as part of EAP. > >The choice is between separate extensions for SRP and for each authentication >method, or to introduce them all at once under EAP, as was done in IKEv2. Is it possible to do this though? Using the taxonomy I posted earlier, TLS- SRP would seem to fall into the "modify the crypto portion of the TLS handshake" bucket (alongside TLS-KRB5 and TLS-PSK), which means that you couldn't really do it inside EAP. Admittedly you could do a standard TLS handshake and then follow it up with SRP inside EAP purely for the authentication portion, but that seems (a) messy (see draft-iab-auth-mech-*) and (b) a bit of a waste of SRP's capabilities, since it can do the whole key exchange step as well. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 15:14:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTct-00007U-E0; Wed, 30 May 2007 15:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtTcs-00007P-8U for tls@ietf.org; Wed, 30 May 2007 15:14:30 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtTcq-0005WW-QV for tls@ietf.org; Wed, 30 May 2007 15:14:30 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA01523; Wed, 30 May 2007 21:14:19 +0200 (MESZ) From: Martin Rex Message-Id: <200705301914.l4UJEKMm003461@fs4113.wdf.sap.corp> Subject: Re: [TLS] Straw poll on TLS SRP status To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 30 May 2007 21:14:20 +0200 (MEST) In-Reply-To: from "Peter Gutmann" at May 30, 7 10:16:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tls@ietf.org, paul.hoffman@vpnc.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.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: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > > The reason I made the comment about TLS client auth being an abject failure > is that every time anyone mentions the possibility of providing any other > way of authenticating clients and servers, it's practically guaranteed > that someone will pop out of the woodwork and state that we already have > the perfect solution to authentication in the form of client certs The main reason why I brought it up is because most the installed base is able to cope with SSL clients certs. But it did take a few years to get there. It is far from perfect, especially in mixed scenarios for the cert-less users because, depending on the browser, they might get constantly annoyed with a certificate selection popup. I would not want to see additional password-based authentication schemes to be promoted that require significant changes to then entire infrastructure/middleware, because this will only add new problems, and not really solve any of the existing problems. The reason for people still using passwords are (a) legacy password-based authentication systems and (b) the necessity to be able to walk up to any network-connected PC and "login" from there by entering a memorized password. And the latter is often a phishing-enabling requirement. The operational costs of password-based authentication is likely much lower than the use of strong cryptographic credentials, which require either a hardware token (e.g. USB-key, smartcard) or a software credential that is distributed through the network protected by a traditional password, and which must be at least temporarily persisted on the PC where it is being used. Dealing with forgotten passwords is usually much easier for a helpdesk/callcenter than dealing with a forgotten or lost or defective hardware token, especially if when you're travelling. OTP might be seen as one approach to thwart phishing attacks, but it is also seen as a major inconvenience. More and more often you find Single Sign-On (SSO) and in addition to that, credentials management tools (not just Browsers) aggressively try to persuade users to memorize and auto-supply credentials (The credentials manager on my new notebook was a serious nuisance and real security problem, so I uninstalled it). The problem with SSO is that it allows attackers to perform all sorts of MITM attacks through active content, trojans and CSRF (Cross-site request forgery). The approach taken by online banking to limit the damage from such attacks is to accept SSO only for reading information, not for requesting transaction. Here in Germany, most banks use an OTP-style approach (TAN) for authenticating transactions. I think this is a fairly reasonable and usable compromise, but it requires careful application design (clearly seperate more dangerous and less dangerous actions and exclude the more dangerous actions from Single Sign-On) and I don't currently see how the two different authentication schemes (Single Sign-On and per-transaction authentication) should both be provided by TLS without significant architectural changes to the middleware (session management). The other thing I feel uncomfortable with is the skewed threat model. On the one hand there is the attitude that one cannot prevent the credential from being stolen, so one tries to limit the damage that can be done to the server (in a cover-your-ass fashion). On the other hand there is ignorance about the problem that an attacker that is able to steal my credentials from my machine can probably just as easily subvert my browser to perform the fraudulent transaction itself and therefore bypassing all channel-bindings and password-concealing efforts that are being proposed. At the same time the victim Joe User will be in a much worse position trying to repudiate a fraudulent transaction compared to the majority of unsophisticated phishing attacks today. Service providers will like this because Joe User will have to cover most of the damages and the attacker will like it because they're less like to get caught. As security engineers we can hardly claim tomorrow that we could not anticipate such a shift in attack methods when tweaking the technology to thwart the large amounts of low-tech phishing attacks and cutting into the attackers ROI without adding real security. If we think that passwords are fundamentally flawed in this environment, we should not significantly prolong and promote their continued use by applying band aids. :-| -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 18:32:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWif-0004u3-A6; Wed, 30 May 2007 18:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWie-0004tv-4c for tls@ietf.org; Wed, 30 May 2007 18:32:40 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtWic-0001Iy-Sy for tls@ietf.org; Wed, 30 May 2007 18:32:40 -0400 Received: (qmail 20342 invoked by uid 0); 30 May 2007 22:32:31 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (12.104.13.39) by woodstock.binhost.com with SMTP; 30 May 2007 22:32:31 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 May 2007 18:31:59 -0400 To: From: Russ Housley Subject: RE: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 In-Reply-To: References: <20070528183851.2E07E33C1A@delta.rtfm.com> <87tztvap2h.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: I'm okay with increasing the size as long as others agree with your assessment. The current version of tls-authz says: struct{ AuthorizationDataEntry authz_data_list<1..2^16-1>; } AuthorizationData; It is easy to change "2^16" to "2^24" The current version also says: opaque X509AttrCert<1..2^16-1>; opaque SAMLAssertion<1..2^16-1>; I have not heard anyone suggest that a single X.509 Attribute Certificate or a single SAML Assertion will exceed 64KB, but this could be increased as well if there is consensus to do so. Russ At 03:58 AM 5/30/2007, Pasi.Eronen@nokia.com wrote: >Russ Housley wrote: > > > >- The size of authorization data, i.e., X.509 attribute > > > certs and SAML assertions, are limited to 64kb. Is it certain > > > that we won't need more? > > > > I recall responding to this the first time around. I said that > > I could not imagine needing 64KB for X.509 Attribute Certificates, > > but I do not have experience with SAML Assertions. I know they > > are bigger, but I do not have any way to gauge the likelihood > > that 64KB will not be enough. > >One relatively simple SAML assertion example from the SAML specs >is 3.5 KB. If it used 4096-bit RSA keys instead of 1024, and >included holder-of-key SubjectConfirmation block, it would be >maybe 6 KB. If it included more complex assertions or additional >certificates, it could get over 10 KB. > >IMHO the safety margin is too small for "64K ought to be enough for >everyone" :-) > >Best regards, >Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 18:36:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWm6-0006zI-Cg; Wed, 30 May 2007 18:36:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWm3-0006ue-LX for tls@ietf.org; Wed, 30 May 2007 18:36:11 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtWm2-0001Ok-Dr for tls@ietf.org; Wed, 30 May 2007 18:36:11 -0400 Received: (qmail 23369 invoked by uid 0); 30 May 2007 22:36:02 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (12.104.13.39) by woodstock.binhost.com with SMTP; 30 May 2007 22:36:02 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 May 2007 18:36:06 -0400 To: , From: Russ Housley Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: References: <20070528183851.2E07E33C1A@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: tls-bounces@lists.ietf.org Message-Id: Pasi: > > We have a request from the IESG re draft-housley-tls-authz-extns-07. > > > > The IESG is considering publication of this document as a Proposed > > Standard. The IESG has requested that the TLS WG provide input > > (positive or negative) on this proposal. Please post comments to the > > list before Monday June 11. > > > >Basically repeating the comments I made during the second IETF >last call: > >- I think this document is somewhat useful; and given that there are >others who seem to share this view -- and basically nobody has claimed >that the technical solution is flawed or undesirable -- I think IESG >should publish this document. IMHO not publishing this as a form of >punishment would be a wrong thing to do. I agree with this position. >- IMHO the most appropriate status would be Experimental. I would prefer standards track. >- As was already pointed out by others, the IESG should use this >opportunity (before we have deployments) to change the length fields >from 16 bits to 24 bits (the rest of TLS already uses 24-bit length >fields for certificates). We are discussing this, and if this is the consensus, I'm pleased to use a 24-bit length. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 19:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXUY-0004Ys-83; Wed, 30 May 2007 19:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXUW-0004Uf-Ez; Wed, 30 May 2007 19:22:08 -0400 Received: from dh152.citi.umich.edu ([141.211.133.152] helo=carter-zimmerman.suchdamage.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtXUV-0003F5-5x; Wed, 30 May 2007 19:22:08 -0400 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CB5A94013; Wed, 30 May 2007 19:22:05 -0400 (EDT) From: Sam Hartman To: Dean Anderson Subject: Re: [TLS] Comments on draft-housley-tls-authz-extns-07 References: Date: Wed, 30 May 2007 19:22:05 -0400 In-Reply-To: (Dean Anderson's message of "Tue, 29 May 2007 17:12:59 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: iesg@ietf.org, 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: , Errors-To: tls-bounces@lists.ietf.org >>>>> "Dean" == Dean Anderson writes: Dean> I believe the IETF announced that it would be sending this Dean> draft back to the 'starting gate'. To me, that means that Dean> TLS has to do several things: Dean, Eric has corrected your statements about where this draft is in the process. However I do want to respond to a couple of your comments. Dean> 1) Consider non-patented alternatives in accordance with Dean> RFC2418 and RFC3979. Dean, this is an excellent idea. Anyone who wants to including you can discuss alternatives to the technology. The availability of other ways to do this--particularly when combined with information about whether people are willing to do the necessary work to write up and implement these alternatives--would be great input to the IESG. I'd appreciate anything you can do in this regard. As an example, if all the implementers say that they prefer this solution to alternatives they have considered, and would implement this solution but not those alternatives, that would be a strong argument in favor of publication. If on the other hand people say that they would write up an alternative and that they would implement the alternative, that would argue against publication. What you may be assuming is that we have an obligation to conduct such a review or that we need to block our work until such a review is done. We do have an obligation to consider any alternatives that are brought forward. We do have an obligation to solicit comments so people know they can bring forward alternatives. But if no one actually brings forward an alternative we don't have to sit around waiting. so if you want to propose an alternative, you should do so. If you know others who want to propose an alternative you should encourage them. Dean> 2) Obtain a thorough review and consensus per RFC2026 and Dean> RFC2418. RFC 2418 does not directly apply because this is not a WG document. However you are completely correct that we need to obtain a consensus. That's why we are soliciting comments. The ietf list discussion was in the minds of some inconclusive. We're soliciting review here in hopes that the discussion will lead to a clear consensus. Dean> 3) Pass a working group last-call, per RFC2026 and RFC2418. Not applicable because this is not a WG document. Thanks for your valuable input. Sam Hartman Security Area Director _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 19:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXXR-0005l0-Ey; Wed, 30 May 2007 19:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXXP-0005jc-TY for tls@ietf.org; Wed, 30 May 2007 19:25:07 -0400 Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtXXO-000415-Gd for tls@ietf.org; Wed, 30 May 2007 19:25:07 -0400 Received: from [130.105.12.10] ([130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id l4UNP5RO005093 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 May 2007 19:25:06 -0400 Date: Wed, 30 May 2007 19:25:05 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Mark Brown Subject: RE: [TLS] Comments on draft-housley-tls-authz-extns-07 In-Reply-To: <000a01c7a263$975858c0$6801a8c0@rps.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.8 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: , Errors-To: tls-bounces@lists.ietf.org On Tue, 29 May 2007, Mark Brown wrote: > A few points I think are relevant: > > 1) The RedPhone Security (RPS) patent application and its General Use > License (GUL) protect a *new* method of verifying authorizations. Please clarify this "GUL". The last proposal you presented on the IETF list was not a license at all, but instructions on how to request a license which was to be given for free upon request. As was noted at the time, this offer is not a license. As was also noted at the time, this offer of a free license on request can end at any time. Your offer is no different from the free offers on a box of cereal----when the gizmos run out, the offer is no longer valid, no matter how box tops you have. There is nothing that compels RedPhone Security to issue a license. There is nothing that prevents RedPhone Security from changing the terms in the future; after the standard is well entrenched, widely implemented and used in many products. There is nothing to compels successors of RedPhone Security to continue to offer free licenses. 21 years is a long time, in 184 WIPO countries. If you have changed the terms since last discussed, it would be helpful to post the new terms. If you have not changed these terms, then it seems inappropriate to describe this offer as a licence, since no license is obtained until __after__ RedPhoneSecurity issues a license in response to a request. As I said, 21 years is a long time, and you've already deceived the IETF at least __7__ times on this issue. I count each time you submitted a draft that asserted to have no undisclosed patents. There are probably more times if we count the IESG discussion approving the draft; but there are at least 7. > 2) If it's been published or in use prior to RPS's patent filing, then *any* > such method of verifying authorizations is "prior art", and can be used with > tls-authz under the GUL. There are a lot of prior specs in this area... > And of course you're free to invent new verification methods, etc. Only one > method is reserved by RPS under the GUL. This is true of any patent, but it is always expensive to litigate. My view (as you already know) is that your patent is entirely covered by prior art, is not novel, and therefore should not be issued by the PTO. The PTO issues many such patents, however, despite efforts to identify prior art and obvious claims. > 3) tls-authz doesn't specify any method for verifying authorizations > > The GUL provides a way to be sure that RPS won't raise any claims of > infringement against you (except obviously the PAS functions). This is FUD. Obviously, a licensed use can't be objected to as an infringement; the use is ___licensed___. But why the hurry? Some background: A frequently cited drawback to the patent law of most countries is that the patent is valid as of the filing date (January 2005 if I recall). Unlicensed use of authz-extns between 1/2005 and now is infringement, if the patent issues. While RPS __can__ assert a patent infringement claim for this period, usually halting use is sufficient for most attorney's to agree not to press the issue. But there are also criminal penalties for intentional infringement; these usually only come into play when you willfully ignore the law and the patent. You can't bury your head in the sand and just use authz-extns. Anyone using authz-extns should stop immediately or get a license from RPS. But maybe the license isn't a 'good thing'. Another problem with the GUL is that you must agree to not implement PAS functions. Why is this bad? Why the FUD to scare people into licensing quickly? Here's why: Even if you later stop using authz-extns (say because we design a non-patented alternative), this agreement may still be valid, and it may be difficult to get out of it---And then you won't be able to implement PAS functions (well, not without paying RPS or its successors). So, executing the agreement may worse even than the patent. So, it is probably better to stop using the patented protocol immediately, and pay cash damages _if_ RPS presses for reparation for the (short) unlicensed use. What to do? It can't be ignored that a patent may issue on the authz-extns draft. Implementers who have already implemented authz-extns should remove the implementation from distribution immediately. They now have notice of possible infringement. They should even remove old versions containing implmentations, and they should notify their users of the likely infringement and inform their users they should stop using the (likely) patented code. You should look closely at the PAS functions and the license agreement and think about at least the next 21 years, and possibly forever, before you sign the agreement. Don't forget to tell the IESG that you don't want this protocol standardized. > Since nobody knows precisely which RPS patent claims will issue, > executing a GUL may help to alleviate concerns right now. The > RedPhone Security GUL amounts to a way to guarantee for yourself that > Sending any "prior art" SAML / AC assertions over TLS will be > royalty-free. On the whole it's your choice to use the GUL or not. Using prior art to create an alternative to authz-extns ensures that no patents will issue that encumber the standard. I favor a new draft, based entirely on prior art. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 30 21:12:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtZCv-0004Cx-5V; Wed, 30 May 2007 21:12:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtZCu-0004Cs-Ix for tls@ietf.org; Wed, 30 May 2007 21:12:04 -0400 Received: from moe.its.auckland.ac.nz ([130.216.10.121] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtZCt-0001Ai-6C for tls@ietf.org; Wed, 30 May 2007 21:12:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id A970948036B; Thu, 31 May 2007 13:11:55 +1200 (NZST) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVs94U893ZOE; Thu, 31 May 2007 13:11:55 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7A0A848038E; Thu, 31 May 2007 13:11:55 +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 3E1D61280A2; Thu, 31 May 2007 13:11:55 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1HtZCo-0003u2-00; Thu, 31 May 2007 13:11:58 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, Pasi.Eronen@nokia.com Subject: RE: [TLS] Re: Comments on draft-housley-tls-authz-extns-07 In-Reply-To: Message-Id: Date: Thu, 31 May 2007 13:11:58 +1200 X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: tls-bounces@lists.ietf.org Russ Housley writes: >I have not heard anyone suggest that a single X.509 Attribute Certificate or >a single SAML Assertion will exceed 64KB, but this could be increased as well >if there is consensus to do so. There's the MPEG-of-cat certificate on my home page which is ~1MB, but I don't expect that to be used much :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls