From tls-bounces@lists.ietf.org Fri Dec 01 01:55:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq2Gu-0003Hb-7T; Fri, 01 Dec 2006 01:53:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq2Gs-0003HR-KK for tls@lists.ietf.org; Fri, 01 Dec 2006 01:53:18 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq2Gq-00032G-R9 for tls@lists.ietf.org; Fri, 01 Dec 2006 01:53:18 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 30 Nov 2006 22:53:14 -0800 Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by orsmga001.jf.intel.com with ESMTP; 30 Nov 2006 22:53:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,483,1157353200"; d="scan'208"; a="168844958:sNHT18234216" Received: from pdsmsx404.ccr.corp.intel.com ([172.16.12.64]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 22:53:10 -0800 Received: from pdsmsx412.ccr.corp.intel.com ([172.16.12.94]) by pdsmsx404.ccr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 14:53:07 +0800 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: Fri, 1 Dec 2006 14:53:07 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS pad length is necessary? Thread-Index: AccT0Zv5DeTJKCPtTbud1iRnatvLTwBQ4B3w From: "Zhu, Heqing" To: X-OriginalArrivalTime: 01 Dec 2006 06:53:08.0020 (UTC) FILETIME=[5BB16F40:01C71515] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [TLS] TLS pad length is necessary? 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, Can someone help me to clarify whether pad length field is necessary in TLS 1.1 in case of no padding required ?=20 RFC 4346 page 23, paragraph 3: The encrypted data length (TLSCiphertext.length) is one more than the sum of CipherSpec.block_length, TLSCompressed.length, CipherSpec.hash_size, and padding_length. Regards Heqing ZHU Intel Asia-Pacific Research & Development Ltd. No. 880 Zi Xing Rd., Shanghai Zizhu Science Park, Shanghai, 200241, PRC Tel: 86-21-61167369 iNet: 8-821-7369 Fax: 86-21-34293967 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 01 02:59:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3HY-0001iP-7t; Fri, 01 Dec 2006 02:58:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3HX-0001hX-Ab for tls@lists.ietf.org; Fri, 01 Dec 2006 02:58:03 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq3HV-0002O9-Ay for tls@lists.ietf.org; Fri, 01 Dec 2006 02:58:03 -0500 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 <0J9L00M9B4D5RW@szxga03-in.huawei.com> for tls@lists.ietf.org; Fri, 01 Dec 2006 15:48:41 +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 <0J9L00KZL4D46Z@szxga03-in.huawei.com> for tls@lists.ietf.org; Fri, 01 Dec 2006 15:48:40 +0800 (CST) Received: from l52008 ([10.111.12.60]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9L00EIR4D0YJ@szxml03-in.huawei.com> for tls@lists.ietf.org; Fri, 01 Dec 2006 15:48:40 +0800 (CST) Date: Fri, 01 Dec 2006 15:48:36 +0800 From: Liu Ya Subject: RE: [TLS] TLS pad length is necessary? In-reply-to: To: "'Zhu, Heqing'" , tls@lists.ietf.org Message-id: <04d001c7151d$1b9eb810$3c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccT0Zv5DeTJKCPtTbud1iRnatvLTwBQ4B3wAAHpBkA= X-Spam-Score: 0.0 (/) 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 Yes, it is necessary. It will hold zero value in case of no padding required > -----Original Message----- > From: Zhu, Heqing [mailto:heqing.zhu@intel.com] > Sent: Friday, December 01, 2006 2:53 PM > To: tls@lists.ietf.org > Subject: [TLS] TLS pad length is necessary? > > Hi, > > Can someone help me to clarify whether pad length field is > necessary in > TLS 1.1 in case of no padding required ? > > RFC 4346 page 23, paragraph 3: > The encrypted data length (TLSCiphertext.length) is one > more than the > sum of CipherSpec.block_length, TLSCompressed.length, > CipherSpec.hash_size, and padding_length. > > Regards > Heqing ZHU > > Intel Asia-Pacific Research & Development Ltd. > No. 880 Zi Xing Rd., Shanghai Zizhu Science Park, > Shanghai, 200241, PRC > Tel: 86-21-61167369 > iNet: 8-821-7369 > Fax: 86-21-34293967 > > _______________________________________________ > 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 Fri Dec 01 10:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAPf-0006aw-91; Fri, 01 Dec 2006 10:34:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAPe-0006ar-ML for tls@lists.ietf.org; Fri, 01 Dec 2006 10:34:54 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqAPd-00052N-8y for tls@lists.ietf.org; Fri, 01 Dec 2006 10:34:54 -0500 Received: by ug-out-1314.google.com with SMTP id k3so2156637ugf for ; Fri, 01 Dec 2006 07:34:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=ivnWoWLn4UF8vH+v/5luj5FzPmtwfWWg5AhLBgq/obm+MlH9kbeuLNLbyYK9XoccqMyGFliJ/EhJWiDO5mPp9xNzV27vSRx7++qXF5kCaBd+WNYMBHwLnIL5SIlzo0sB5KFCuJK5BtoHy8C6i/40QU3ZeR1XsXwTEJ83ChyQXIY= Received: by 10.82.114.3 with SMTP id m3mr1059007buc.1164987291880; Fri, 01 Dec 2006 07:34:51 -0800 (PST) Received: by 10.82.165.8 with HTTP; Fri, 1 Dec 2006 07:34:51 -0800 (PST) Message-ID: <36b11d4d0612010734m56e960d9qd55c9bffdc5a04a6@mail.gmail.com> Date: Fri, 1 Dec 2006 16:34:51 +0100 From: "Ibrahim Hajjeh" To: tls@lists.ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: d99bdc7dab88f3d1 X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [TLS] Identity Protection Ciphersuites for TLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ibrahim.hajjeh@esrgroups.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1075337258==" Errors-To: tls-bounces@lists.ietf.org --===============1075337258== Content-Type: multipart/alternative; boundary="----=_Part_1698_13468582.1164987291784" ------=_Part_1698_13468582.1164987291784 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all, Identity protection is increasingly required; especially in wireless networks. For example, EAP-TLS proposes renegotiating after the first server authentication. This requires however more cryptographic computations and augments significantly the number of rounds trips. Consequently, Badra and I have submitted an individual document to add client identity protection to TLS. The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-00.txt Best regards, Ibrahim ------=_Part_1698_13468582.1164987291784 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Dear all,

Identity protection is increasingly required; especially in wireless networks. For example, EAP-TLS proposes renegotiating after the first server authentication. This requires however more cryptographic computations and augments significantly the number of rounds trips.
 
Consequently, Badra and I have submitted an individual document to add client identity protection to TLS.

The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-00.txt

Best regards,

Ibrahim

------=_Part_1698_13468582.1164987291784-- --===============1075337258== 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 --===============1075337258==-- From tls-bounces@lists.ietf.org Fri Dec 01 11:27:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBDI-00083Z-2r; Fri, 01 Dec 2006 11:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBDG-00083O-Nd for tls@lists.ietf.org; Fri, 01 Dec 2006 11:26:10 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBDE-0005N2-W6 for tls@lists.ietf.org; Fri, 01 Dec 2006 11:26:10 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kB1GPt0d011290; Fri, 1 Dec 2006 11:25:55 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Fri, 01 Dec 2006 11:25:55 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Dec 2006 11:25:55 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8ca34017-347b-4ccb-a304-2c1151aa5868" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Identity Protection Ciphersuites for TLS Date: Fri, 1 Dec 2006 11:25:54 -0500 Message-ID: In-Reply-To: <36b11d4d0612010734m56e960d9qd55c9bffdc5a04a6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Identity Protection Ciphersuites for TLS Thread-Index: AccVXnUlFEIgXbBRSdakUXg5p0WiVwAArv1g From: "Kemp, David P." To: , X-OriginalArrivalTime: 01 Dec 2006 16:25:55.0017 (UTC) FILETIME=[60050390:01C71565] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14846003 X-TM-AS-Result: : Yes--21.888300-0-1-1 X-TM-AS-Category-Info: : 1:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE1LTE1MDU2Ny03MDgw?= =?us-ascii?B?NjEtNzAzNDY1LTcxMDQ3My03MDMxOTctNzAzMjI1LTcwMjQ0NC0x?= =?us-ascii?B?ODgwMTktNzAwMDc5LTcwOTI3OS03MDQwMTUtNzAwNDg5LTEwNTYz?= =?us-ascii?B?MC03MDUxMjMtNzAxNjUxLTcwMTExMi03MDE1NDMtNzA5Nzk0LTcx?= =?us-ascii?B?MDM2My03MDA4MjMtNzEwNzM2LTcwMzIxMi03MDc5ODQtNzEwOTQ2?= =?us-ascii?B?LTcxMDA3Mi03MDc2OTMtNzAwMTQwLTcwMDEwMy03MDAxMDktNzAw?= =?us-ascii?B?NzUwLTcwMTMzNi03MDEzOTAtNzAxMTc0LTEyMTExOC03MDQ1MTct?= =?us-ascii?B?NzAxNDM4LTcwMTEzNS03MDEyNDktNzA3MzM1LTcxMDAxMS03MDAy?= =?us-ascii?B?MTAtMTg2MDM1LTcwMjA0NS03MDA2MDQtMTM5NzAzLTcwMDYyNy03?= =?us-ascii?B?MDk5NzAtNzAyMjgzLTcwMjQwMy03MDAxNTEtNzAwODc0LTEzOTcw?= =?us-ascii?B?NC03MDI5MTEtMTExNjA0LTE4ODExOS03MDE0MjQtNzAwOTYyLTcw?= =?us-ascii?B?ODUwMi03MDAwMjgtNzAwMDAzLTcwMjQwNS03MDMzNTgtMTg4MTE4?= =?us-ascii?B?LTcxMDMwMC03MDI2MjEtNzA1NjI3LTE4ODExNC0xODgwMzgtNzAw?= =?us-ascii?B?MDYyLTcwMDE3OS03MDEzNzgtNzAxNzA5LTcwOTk4MS03MDA0MzIt?= =?us-ascii?B?NzAyNzY4LTcwMTYxNy03MDE2OTItNzA3OTA3LTcwMDI3Ny03MDIz?= =?us-ascii?B?NjUtNzAyNTI3LTcwMDA0MS03MDI2MDEtNzAwNzU4LTE4ODEyNS0x?= =?us-ascii?B?MTE2MDUtNzAxMDYyLTcwODczOC03MDA1ODEtMTkwNjQyLTE0ODA1?= =?us-ascii?B?MC0yMDAyNA==?= X-Spam-Score: 0.1 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c 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 This is a multi-part message in MIME format. ------=_NextPartTM-000-8ca34017-347b-4ccb-a304-2c1151aa5868 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71565.5FD0ECEA" ------_=_NextPart_001_01C71565.5FD0ECEA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This capability is useful. However, the introduction presents four mechanisms for "client identity protection" as if they are an exhaustive list: "Finally, client identity protection may be realized by exchanging a TLS extension ..." =20 In addition to the described techniques for obscuring the contents of certificates, client identity information may be protected by provisioning users with certificates that do not require obscuring. Context-free naming, application-specific credentials, and limited credential lifetime are all mechanisms for protecting personally identifiable information (i.e. client "identity") not only while in transit over TLS sessions but while stored at the organizations at the endpoints of those sessions. =20 It would be more accurate if this draft were called "Credential Protection Ciphersuites for TLS", and if text within the draft referred to the protection of certificates or credentials rather than protection of client "identity". =20 Dave =20 =20 _____ =20 From: Ibrahim Hajjeh [mailto:ibrahim.hajjeh@esrgroups.org]=20 Sent: Friday, December 01, 2006 10:35 AM To: tls@lists.ietf.org Subject: [TLS] Identity Protection Ciphersuites for TLS =20 Dear all, Identity protection is increasingly required; especially in wireless networks. For example, EAP-TLS proposes renegotiating after the first server authentication. This requires however more cryptographic computations and augments significantly the number of rounds trips.=20 =20 Consequently, Badra and I have submitted an individual document to add client identity protection to TLS.=20 The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection -00.txt=20 Best regards, Ibrahim ------_=_NextPart_001_01C71565.5FD0ECEA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This capability is useful. =  However, the introduction presents four mechanisms for “client identity = protection” as if they are an exhaustive list:

      =       “Finally, client identity protection may be realized by exchanging a TLS extension = …”

 

In addition to the described = techniques for obscuring the contents of certificates, client identity information = may be protected by provisioning users with certificates that do not require = obscuring.  Context-free naming, application-specific credentials, and limited credential lifetime are all mechanisms for protecting personally = identifiable information (i.e. client “identity”) not only while in = transit over TLS sessions but while stored at the organizations at the endpoints of = those sessions.

 

It would be more accurate if this = draft were called “Credential Protection Ciphersuites for TLS”, = and if text within the draft referred to the protection of certificates or = credentials rather than protection of client = “identity”.

 

Dave

 

 

From: = Ibrahim Hajjeh [mailto:ibrahim.hajjeh@esrgroups.org]
Sent: Friday, December = 01, 2006 10:35 AM
To: = tls@lists.ietf.org
Subject: [TLS] Identity = Protection Ciphersuites for TLS

 

Dear all,

Identity protection is increasingly required; especially in = wireless networks. For example, EAP-TLS proposes renegotiating after the first = server authentication. This requires however more cryptographic computations = and augments significantly the number of rounds trips. =

 

Consequently, Badra and I have submitted an individual = document to add client identity protection to TLS.

The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-iden= tity-protection-00.txt

Best regards,

Ibrahim

------_=_NextPart_001_01C71565.5FD0ECEA-- ------=_NextPartTM-000-8ca34017-347b-4ccb-a304-2c1151aa5868 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 ------=_NextPartTM-000-8ca34017-347b-4ccb-a304-2c1151aa5868-- From tls-bounces@lists.ietf.org Fri Dec 01 14:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDyX-0000nR-8V; Fri, 01 Dec 2006 14:23:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqDyV-0000nG-Ue for tls@lists.ietf.org; Fri, 01 Dec 2006 14:23:07 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqDyU-0002iV-CB for tls@lists.ietf.org; Fri, 01 Dec 2006 14:23:07 -0500 Received: by nf-out-0910.google.com with SMTP id h2so3559698nfe for ; Fri, 01 Dec 2006 11:23:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=nMmRJyTNPUf+5u41BJZi29mUa/jxTtF6nvWVgGQjunlLoGagZeuXEXspcqzpOBr52yFPURGWbB0GhsVWC3pXiZ3cEOB0yNusuXWNCAMETsfeQcpgJdTckyhZia6Smo9WqXlFMlJ1UgansYJRMNxA/HExGL/AmeZraOV8kLe2vi0= Received: by 10.82.113.6 with SMTP id l6mr1104946buc.1165000984548; Fri, 01 Dec 2006 11:23:04 -0800 (PST) Received: by 10.82.165.8 with HTTP; Fri, 1 Dec 2006 11:23:04 -0800 (PST) Message-ID: <36b11d4d0612011123v555ef5b1k155322c98e739333@mail.gmail.com> Date: Fri, 1 Dec 2006 20:23:04 +0100 From: "Ibrahim Hajjeh" To: "Kemp, David P." Subject: Re: [TLS] Identity Protection Ciphersuites for TLS In-Reply-To: MIME-Version: 1.0 References: <36b11d4d0612010734m56e960d9qd55c9bffdc5a04a6@mail.gmail.com> X-Google-Sender-Auth: 996f8a3ce048cd1b X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ibrahim.hajjeh@esrgroups.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1374856059==" Errors-To: tls-bounces@lists.ietf.org --===============1374856059== Content-Type: multipart/alternative; boundary="----=_Part_5032_14175697.1165000984387" ------=_Part_5032_14175697.1165000984387 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Dave, Thank you very much for reading and commenting the document. I agree with you regarding the client credentials. However, when a ciphersuite with certificate-based authentication is chosen, the client identity is just the client certificate. We can add that at the beginning but if this still ambiguous, we will ratify it and replace client identity with certificate identity. Best regards, Ibrahim On 12/1/06, Kemp, David P. wrote: > > This capability is useful. However, the introduction presents four > mechanisms for "client identity protection" as if they are an exhaustive > list: > > "Finally, client identity protection may be realized by > exchanging a TLS extension =85" > > > > In addition to the described techniques for obscuring the contents of > certificates, client identity information may be protected by provisionin= g > users with certificates that do not require obscuring. Context-free nami= ng, > application-specific credentials, and limited credential lifetime are all > mechanisms for protecting personally identifiable information ( i.e. > client "identity") not only while in transit over TLS sessions but while > stored at the organizations at the endpoints of those sessions. > > > > It would be more accurate if this draft were called "Credential Protectio= n > Ciphersuites for TLS", and if text within the draft referred to the > protection of certificates or credentials rather than protection of clien= t > "identity". > > > > Dave > > > > > ------------------------------ > > *From:* Ibrahim Hajjeh [mailto: ibrahim.hajjeh@esrgroups.org] > *Sent:* Friday, December 01, 2006 10:35 AM > *To:* tls@lists.ietf.org > *Subject:* [TLS] Identity Protection Ciphersuites for TLS > > > > Dear all, > > Identity protection is increasingly required; especially in wireless > networks. For example, EAP-TLS proposes renegotiating after the first ser= ver > authentication. This requires however more cryptographic computations and > augments significantly the number of rounds trips. > > > > Consequently, Badra and I have submitted an individual document to add > client identity protection to TLS. > > The document is available for your review and comments at http://www.ietf= .org/internet-drafts/draft-hajjeh-tls-identity-protection-00.txt > > > Best regards, > > Ibrahim > ------=_Part_5032_14175697.1165000984387 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear Dave,
 
Thank you very much for reading and commenting the document.
 
I agree with you regarding the client credentials. However, when a cip= hersuite with certificate-based authentication is chosen, the client identi= ty is just the client certificate. We can add that at the beginning but if = this still ambiguous, we will ratify it and replace client identity with ce= rtificate identity.=20
 
Best regards,

Ibrahim


On 12/1/06, = Kemp, David P. <DPKemp@miss= i.ncsc.mil > wrote:=20

This capability is useful.  Ho= wever, the introduction presents four mechanisms for "client identity = protection" as if they are an exhaustive list:=20

      = ;      "Finally, client identity protection m= ay be realized by exchanging a TLS extension =85"

 

In addition to the described techni= ques for obscuring the contents of certificates, client identity informatio= n may be protected by provisioning users with certificates that do not requ= ire obscuring.  Context-free naming, application-specific credentials,= and limited credential lifetime are all mechanisms for protecting personal= ly identifiable information (=20 i.e. client "identity") not only while in transit over TLS sessio= ns but while stored at the organizations at the endpoints of those sessions= .

 

It would be more accurate if this d= raft were called "Credential Protection Ciphersuites for TLS", an= d if text within the draft referred to the protection of certificates or cr= edentials rather than protection of client "identity".=20

 

Dave

 

 

From: Ibra= him Hajjeh [mailto:=20 ibrahim.hajjeh@esrgroups.or= g]
Sent: Friday, De= cember 01, 2006 10:35 AM=20
To: tls@lists.ietf.org
Subject: [TLS] Identity Protection Ciphersuites for TLS

http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-00= .txt

In-Reply-To: <36b11d4d0612011123v555ef5b1k155322c98e739333@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Identity Protection Ciphersuites for TLS Thread-Index: AccVfiIz0BaETfFbS3iYpSoKs6EfKgAArDlw From: "Kemp, David P." To: X-OriginalArrivalTime: 01 Dec 2006 20:35:19.0966 (UTC) FILETIME=[37D303E0:01C71588] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14848000 X-TM-AS-Result: : Yes--21.408500-0-1-1 X-TM-AS-Category-Info: : 1:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE1LTE1MDU2Ny03MDAy?= =?us-ascii?B?MTMtNzAwNjA0LTcwMTY1MS03MDUxMjMtNzA4NTgxLTcxMDk5Mi03?= =?us-ascii?B?MDMxOTctNzAyMDQ1LTcwODc4Mi03MDM4NjUtNzAxMDY1LTcwMDkx?= =?us-ascii?B?Mi03MTAxOTItNzAzMjEyLTcwMjczOC03MDQ1MTctNzAwNjc0LTcx?= =?us-ascii?B?MTI4Ni03MDEzMzQtNzEwMjY1LTcwMTk5My03MDA0NjYtNzAwNTg2?= =?us-ascii?B?LTcwMDM3MC03MDMyMTQtNzA0MDY2LTcwMTk2MS03MDE3MDUtNzAw?= =?us-ascii?B?ODI2LTcxMDA0My03MDkyNzktNzA0MTI0LTcwNzk4NC03MDExNDMt?= =?us-ascii?B?NzA2NzQxLTcwMjc3Ni03MDA1MjktNzAxODU2LTcwMDgyMS03MTEy?= =?us-ascii?B?OTAtNzExNTIwLTcxMDA3Mi03MDAxNTEtNzA3NjkzLTcwMDE0MC03?= =?us-ascii?B?MDMwMDEtNzAwMTAzLTcwMDEwOS03MDAzNDQtNzEwMDExLTcwODA2?= =?us-ascii?B?MS03MDA1NjQtNzAxNDM4LTcwMDIxMC03MDM5NDMtNzAxNTU5LTcw?= =?us-ascii?B?MjI4My03MDAyNzAtNzAzNDY1LTcxMDQ3My03MDMyMjUtNzAyNDQ0?= =?us-ascii?B?LTE4ODAxOS03MDAwNzktNzA0MDE1LTcwMDQ4OS0xMDU2MzAtNzAx?= =?us-ascii?B?MTEyLTcwMTU0My03MDk3OTQtNzEwMzYzLTcwMDgyMy03MTA3MzYt?= =?us-ascii?B?NzEwOTQ2LTcwMDc1MC03MDEzMzYtNzAxMzkwLTcwMTE3NC0xMjEx?= =?us-ascii?B?MTgtNzAxMTM1LTcwMTI0OS03MDczMzUtMTg2MDM1LTEzOTcwMy03?= =?us-ascii?B?MDA2MjctNzA5OTcwLTcwMjQwMy03MDA4NzQtMTkwNjQyLTE0ODA1?= =?us-ascii?B?MC0xMzkxNA==?= X-Spam-Score: 0.1 (/) X-Scan-Signature: 645960076aa293effd9740db2f975dc3 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 This is a multi-part message in MIME format. ------=_NextPartTM-000-40458ba9-5ecf-492a-8306-4995d709f428 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71588.377ADDAA" ------_=_NextPart_001_01C71588.377ADDAA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ibrahim, =20 I apologize for not making my comments sufficiently clear and specific. The crux of my comment is that a client certificate is *not* the same thing as a client identity. Your identity includes things like your name and email address, and if these are included in your certificate, then someone seeing your certificate in a TLS connection would know your identity. But if your certificate did not contain this information (for example, if a bank issued you a certificate with just a random or key-hash connection identifier for use when accessing your bank account) then someone seeing this certificate in a TLS connection would see the connection identifier but would not know the identity of the person making the connection. (More sophisticated examples exist, such as that of a credential service provider generating short-term or one-time certificates on-the-fly.) =20 So the purpose of the comment was to say that in addition to the methods of protecting identity by encrypting certificates listed in the draft, there is another method of protecting identity, namely to use certificates that contain no personally-identifying information. If you want to call the draft "identity protection", then you should include alternatives that do not require certificate encryption (and thus require no modifications to TLS). On the other hand, if you call it "credential protection", then listing only the certificate encryption alternatives in the introduction is appropriate. =20 Regards, Dave =20 _____ =20 From: hajjeh@gmail.com [mailto:hajjeh@gmail.com] On Behalf Of Ibrahim Hajjeh Sent: Friday, December 01, 2006 2:23 PM To: Kemp, David P. Cc: tls@lists.ietf.org Subject: Re: [TLS] Identity Protection Ciphersuites for TLS =20 Dear Dave,=20 =20 Thank you very much for reading and commenting the document.=20 =20 I agree with you regarding the client credentials. However, when a ciphersuite with certificate-based authentication is chosen, the client identity is just the client certificate. We can add that at the beginning but if this still ambiguous, we will ratify it and replace client identity with certificate identity.=20 =20 Best regards, Ibrahim =20 On 12/1/06, Kemp, David P. > wrote:=20 This capability is useful. However, the introduction presents four mechanisms for "client identity protection" as if they are an exhaustive list:=20 "Finally, client identity protection may be realized by exchanging a TLS extension ..."=20 =20 In addition to the described techniques for obscuring the contents of certificates, client identity information may be protected by provisioning users with certificates that do not require obscuring. Context-free naming, application-specific credentials, and limited credential lifetime are all mechanisms for protecting personally identifiable information ( i.e. client "identity") not only while in transit over TLS sessions but while stored at the organizations at the endpoints of those sessions. =20 It would be more accurate if this draft were called "Credential Protection Ciphersuites for TLS", and if text within the draft referred to the protection of certificates or credentials rather than protection of client "identity".=20 =20 Dave =20 =20 _____ =20 From: Ibrahim Hajjeh [mailto: ibrahim.hajjeh@esrgroups.org]=20 Sent: Friday, December 01, 2006 10:35 AM=20 To: tls@lists.ietf.org Subject: [TLS] Identity Protection Ciphersuites for TLS =20 Dear all, Identity protection is increasingly required; especially in wireless networks. For example, EAP-TLS proposes renegotiating after the first server authentication. This requires however more cryptographic computations and augments significantly the number of rounds trips.=20 =20 Consequently, Badra and I have submitted an individual document to add client identity protection to TLS.=20 The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection -00.txt=20 Best regards, Ibrahim =20 ------_=_NextPart_001_01C71588.377ADDAA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ibrahim,

 

I apologize for not making my = comments sufficiently clear and specific.  The crux of my comment is that a client = certificate is *not* the same thing = as a client identity.  Your identity includes things like your name and = email address, and if these are included in your certificate, then someone = seeing your certificate in a TLS connection would know your identity. =   But if your certificate did not contain this information (for example, if a = bank issued you a certificate with just a random or key-hash connection = identifier for use when accessing your bank account) then someone seeing this = certificate in a TLS connection would see the connection identifier but would not = know the identity of the person making the connection.  (More sophisticated examples exist, such as that of a credential service provider generating short-term or one-time certificates = on-the-fly.)

 

So the purpose of the comment was = to say that in addition to the methods of protecting identity by encrypting certificates listed in the draft, there is another method of protecting identity, namely to use certificates that contain no = personally-identifying information.  If you want to call the draft ”identity = protection”, then you should include alternatives that do not require certificate = encryption (and thus require no modifications to TLS).  On the other hand, if = you call it “credential protection”, then listing only the = certificate encryption alternatives in the introduction is = appropriate.

 

Regards,

Dave

 

From: = hajjeh@gmail.com [mailto:hajjeh@gmail.com] On Behalf = Of Ibrahim Hajjeh
Sent: Friday, December = 01, 2006 2:23 PM
To: Kemp, David P.
Cc: = tls@lists.ietf.org
Subject: Re: [TLS] = Identity Protection Ciphersuites for TLS

 

Dear Dave,

 

Thank you very much for reading and commenting the document. =

 

I agree with you regarding the client credentials. However, when = a ciphersuite with certificate-based authentication is chosen, the client identity is just the client certificate. We can add that at the = beginning but if this still ambiguous, we will ratify it and replace client identity = with certificate identity.

 

Best regards,


Ibrahim

 

On 12/1/06, Kemp, David P. = <DPKemp@missi.ncsc.mil > wrote:

This capability is useful.  However, the = introduction presents four mechanisms for "client identity protection" as = if they are an exhaustive list:

         &= nbsp;  "Finally, client identity protection may be realized by exchanging = a TLS extension …"

 

In addition to the described techniques for obscuring = the contents of certificates, client identity information may be protected by = provisioning users with certificates that do not require obscuring. =  Context-free naming, application-specific credentials, and limited credential = lifetime are all mechanisms for protecting personally identifiable information ( i.e. = client "identity") not only while in transit over TLS sessions but = while stored at the organizations at the endpoints of those = sessions.

 

It would be more accurate if this draft were called "Credential Protection Ciphersuites for TLS", and if text = within the draft referred to the protection of certificates or credentials rather = than protection of client "identity".

 

Dave

 

 

From: Ibrahim Hajjeh [mailto: = ibrahim.hajjeh@esrgroups.org]
Sent: Friday, December = 01, 2006 10:35 AM
To: tls@lists.ietf.org
Subject: [TLS] Identity = Protection Ciphersuites for TLS

 

Dear all,

Identity protection is increasingly required; especially in wireless networks. = For example, EAP-TLS proposes renegotiating after the first server = authentication. This requires however more cryptographic computations and augments = significantly the number of rounds trips.

 

Consequently, Badra and I have submitted an individual document to add client = identity protection to TLS.

The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-id= entity-protection-00.txt

Best regards,

Ibrahim

 

------_=_NextPart_001_01C71588.377ADDAA-- ------=_NextPartTM-000-40458ba9-5ecf-492a-8306-4995d709f428 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 ------=_NextPartTM-000-40458ba9-5ecf-492a-8306-4995d709f428-- From tls-bounces@lists.ietf.org Fri Dec 01 16:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFyC-0005UL-BR; Fri, 01 Dec 2006 16:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFyB-0005UF-Nf for tls@lists.ietf.org; Fri, 01 Dec 2006 16:30:55 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqFy7-0004Ss-5Y for tls@lists.ietf.org; Fri, 01 Dec 2006 16:30:55 -0500 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id WAA41574 ; Fri, 1 Dec 2006 22:29:18 +0100 Received: from 86.66.211.110 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Fri, 1 Dec 2006 22:33:24 +0100 (CET) Message-ID: <61876.86.66.211.110.1165008804.squirrel@www.isima.fr> In-Reply-To: References: <36b11d4d0612011123v555ef5b1k155322c98e739333@mail.gmail.com> Date: Fri, 1 Dec 2006 22:33:24 +0100 (CET) Subject: RE: [TLS] Identity Protection Ciphersuites for TLS From: badra@isima.fr To: "Kemp, David P." User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 Hi Dave, I agree that it could be nicer to rename the document "credential protection ciphersuites for TLS" and follow your proposed text. Best regard, Badra > Hi Ibrahim, > > > > I apologize for not making my comments sufficiently clear and specific. > The crux of my comment is that a client certificate is *not* the same > thing as a client identity. Your identity includes things like your > name and email address, and if these are included in your certificate, > then someone seeing your certificate in a TLS connection would know your > identity. But if your certificate did not contain this information > (for example, if a bank issued you a certificate with just a random or > key-hash connection identifier for use when accessing your bank account) > then someone seeing this certificate in a TLS connection would see the > connection identifier but would not know the identity of the person > making the connection. (More sophisticated examples exist, such as that > of a credential service provider generating short-term or one-time > certificates on-the-fly.) > > > > So the purpose of the comment was to say that in addition to the methods > of protecting identity by encrypting certificates listed in the draft, > there is another method of protecting identity, namely to use > certificates that contain no personally-identifying information. If you > want to call the draft "identity protection", then you should include > alternatives that do not require certificate encryption (and thus > require no modifications to TLS). On the other hand, if you call it > "credential protection", then listing only the certificate encryption > alternatives in the introduction is appropriate. > > > > Regards, > > Dave > > > > _____ > > From: hajjeh@gmail.com [mailto:hajjeh@gmail.com] On Behalf Of Ibrahim > Hajjeh > Sent: Friday, December 01, 2006 2:23 PM > To: Kemp, David P. > Cc: tls@lists.ietf.org > Subject: Re: [TLS] Identity Protection Ciphersuites for TLS > > > > Dear Dave, > > > > Thank you very much for reading and commenting the document. > > > > I agree with you regarding the client credentials. However, when a > ciphersuite with certificate-based authentication is chosen, the client > identity is just the client certificate. We can add that at the > beginning but if this still ambiguous, we will ratify it and replace > client identity with certificate identity. > > > > Best regards, > > > Ibrahim > > > > On 12/1/06, Kemp, David P. > wrote: > > This capability is useful. However, the introduction presents four > mechanisms for "client identity protection" as if they are an exhaustive > list: > > "Finally, client identity protection may be realized by > exchanging a TLS extension ..." > > > > In addition to the described techniques for obscuring the contents of > certificates, client identity information may be protected by > provisioning users with certificates that do not require obscuring. > Context-free naming, application-specific credentials, and limited > credential lifetime are all mechanisms for protecting personally > identifiable information ( i.e. client "identity") not only while in > transit over TLS sessions but while stored at the organizations at the > endpoints of those sessions. > > > > It would be more accurate if this draft were called "Credential > Protection Ciphersuites for TLS", and if text within the draft referred > to the protection of certificates or credentials rather than protection > of client "identity". > > > > Dave > > > > > > _____ > > From: Ibrahim Hajjeh [mailto: ibrahim.hajjeh@esrgroups.org] > Sent: Friday, December 01, 2006 10:35 AM > To: tls@lists.ietf.org > Subject: [TLS] Identity Protection Ciphersuites for TLS > > > > Dear all, > > Identity protection is increasingly required; especially in wireless > networks. For example, EAP-TLS proposes renegotiating after the first > server authentication. This requires however more cryptographic > computations and augments significantly the number of rounds trips. > > > > Consequently, Badra and I have submitted an individual document to add > client identity protection to TLS. > > The document is available for your review and comments at > http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection > -00.txt > > Best regards, > > Ibrahim > > > > _______________________________________________ > 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 Sat Dec 02 20:31:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqgAd-0005px-Uu; Sat, 02 Dec 2006 20:29:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqgAc-0005nb-0Z for tls@lists.ietf.org; Sat, 02 Dec 2006 20:29:30 -0500 Received: from bay0-omc1-s5.bay0.hotmail.com ([65.54.246.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqgAa-0006yR-Ir for tls@lists.ietf.org; Sat, 02 Dec 2006 20:29:29 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc1-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Dec 2006 17:29:28 -0800 X-Originating-IP: [71.140.80.73] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , Subject: RE: [TLS] Identity Protection Ciphersuites for TLS Date: Sat, 2 Dec 2006 17:29:28 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2006 01:29:28.0083 (UTC) FILETIME=[7955B630:01C7167A] X-Spam-Score: 2.6 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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: , Content-Type: multipart/mixed; boundary="===============0007983963==" Errors-To: tls-bounces@lists.ietf.org --===============0007983963== Content-Type: multipart/alternative; boundary="_d6d593c4-0be5-4fa1-a3e9-6c0c19bc7ef5_" --_d6d593c4-0be5-4fa1-a3e9-6c0c19bc7ef5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I read the i-d (given some prompting), and I dont get the point. But , the= n, I'm regularly dumb! =20 If we take EAP over T(unneled)TLS, doesnt that do the same thing as one exa= mple application consumer layer exploiting TLS? =20 If you send a SAML extension, where the SAML blob is protected by XML-encry= ption, per SAML procedures, doesnt that also do it. =20 Client auth in a layer 4 protocol entity (supportiung normally a layer 5 ex= change to establish the current direction of the relationship) is (unlike = in https) a matter of T-entity authentication to another T-entity, surely? = If we take an SSL/TL Conenct proxy, is not the T-entity the proxy id, doing= client auth, versus the SAML identifded APDU-issuing user - whose identiif= cation attributes are protected by the SAML/STS-layer's "client identificat= ion protection"? Date: Fri, 1 Dec 2006 16:34:51 +0100From: ibrahim.hajjeh@esrgroups.orgTo: t= ls@lists.ietf.orgSubject: [TLS] Identity Protection Ciphersuites for TLS Dear all, Identity protection is increasingly required; especially in wireless networ= ks. For example, EAP-TLS proposes renegotiating after the first server auth= entication. This requires however more cryptographic computations and augme= nts significantly the number of rounds trips.=20 =20 Consequently, Badra and I have submitted an individual document to add clie= nt identity protection to TLS.=20 The document is available for your review and comments at http://www.ietf.o= rg/internet-drafts/draft-hajjeh-tls-identity-protection-00.txt=20 Best regards, Ibrahim _________________________________________________________________ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=3D7adb59de-a857-45ba-81cc-= 685ee3e858fe= --_d6d593c4-0be5-4fa1-a3e9-6c0c19bc7ef5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I read the i-d (given some prompting), and I dont get the point. = ; But , then, I'm regularly dumb!
 
If we take EAP over T(unneled)TLS, doesnt that do the same thing as one exa= mple application consumer layer exploiting TLS?
 
If you send a SAML extension, where the SAML blob is protected by XML-encry= ption, per SAML procedures, doesnt that also do it.
 
Client auth in a layer 4 protocol entity (supportiung normally a layer 5 ex= change to establish the current direction of the relationship)  is (un= like in https) a matter of T-entity authentication to another T-entity, sur= ely? If we take an SSL/TL Conenct proxy, is not the T-entity the proxy id, = doing client auth, versus the SAML identifded APDU-issuing user - whose ide= ntiifcation attributes are protected by the SAML/STS-layer's "client identi= fication protection"?





Date: Fri, 1 Dec 2006 16:34:51 +0100
From: ibrahim.hajjeh@esrgroups.org<= BR>To: tls@lists.ietf.org
Subject: [TLS] Identity Protection Ciphersuite= s for TLS

Dear all,
Identity protection is increasingly required; especially in wireless n= etworks. For example, EAP-TLS proposes renegotiating after the first server= authentication. This requires however more cryptographic computations and = augments significantly the number of rounds trips.
 
Consequently, Badra and I have submitted an individual document t= o add client identity protection to TLS.
The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identi= ty-protection-00.txt
Best regards,
Ibrahim

Use Messenger to talk to your IM friend= s, even those on Yahoo! Talk now!<= /a> = --_d6d593c4-0be5-4fa1-a3e9-6c0c19bc7ef5_-- --===============0007983963== 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 --===============0007983963==-- From tls-bounces@lists.ietf.org Sat Dec 02 21:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqhI7-0001nX-9r; Sat, 02 Dec 2006 21:41:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqhI4-0001l3-8c for tls@lists.ietf.org; Sat, 02 Dec 2006 21:41:16 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqhI2-0004bq-QY for tls@lists.ietf.org; Sat, 02 Dec 2006 21:41:16 -0500 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id DAA24660 ; Sun, 3 Dec 2006 03:38:25 +0100 Received: from 86.66.211.110 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 3 Dec 2006 03:42:27 +0100 (CET) Message-ID: <62972.86.66.211.110.1165113747.squirrel@www.isima.fr> In-Reply-To: References: Date: Sun, 3 Dec 2006 03:42:27 +0100 (CET) Subject: RE: [TLS] Identity Protection Ciphersuites for TLS From: badra@isima.fr To: "Peter Williams" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Hi Peter, The document describes the protection of the "TLS client" certificate (i.e. the TLS Certificate message) and not of the user-per-application identity. In addition, it lists many existing solutions in the introduction. EAP-TTLS (with client based-certificate authentication), which is equivalent to EAP-TLS with privacy (see section 2.7 of EAP-TLS I-D) is indirectly listed in the introduction: Client identity protection may be also possible, assuming that the client permits renegotiation after the first server authentication. However, this requires more cryptographic computations and augments significantly the number of rounds trips. It is true that EAP-TTLS (or EAP-TLS with privacy) provides the same thing, but: -You have to establish "two" TLS sessions with encryption/decryption of the whole messages of the second session. -You will not detect a forget client too early. in EAP-TTLS, a forged client can start a TLS session with only server authentication. The server will not detect that only after sending its ServerHelloDone of the second TLS session. This IMHO sensitivity increases the DoS attack's effectiveness against the server > Client auth in a layer 4 protocol entity (supportiung normally a layer 5 > exchange to establish the current direction of the relationship) is > (unlike in https) a matter of T-entity authentication to another T-entity, > surely? If we take an SSL/TL Conenct proxy, is not the T-entity the proxy > id, doing client auth, versus the SAML identifded APDU-issuing user - > whose identiifcation attributes are protected by the SAML/STS-layer's > "client identification protection"? I didn't entirely got the point here and its relationship to the document. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 03 12:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqvHj-0004TB-Sg; Sun, 03 Dec 2006 12:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqvHi-0004OI-Fi for tls@lists.ietf.org; Sun, 03 Dec 2006 12:37:50 -0500 Received: from bay0-omc1-s35.bay0.hotmail.com ([65.54.246.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqvHf-0008ER-Mc for tls@lists.ietf.org; Sun, 03 Dec 2006 12:37:50 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 09:37:47 -0800 X-Originating-IP: [71.140.80.73] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Identity Protection Ciphersuites for TLS Date: Sun, 3 Dec 2006 09:37:47 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2006 17:37:47.0217 (UTC) FILETIME=[BF1E0410:01C71701] X-Spam-Score: 2.4 (++) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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: , Content-Type: multipart/mixed; boundary="===============0180591219==" Errors-To: tls-bounces@lists.ietf.org --===============0180591219== Content-Type: multipart/alternative; boundary="_3b70918b-90c8-4027-b4a5-61c47afa6c6d_" --_3b70918b-90c8-4027-b4a5-61c47afa6c6d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The designers *seem* to be advocating a modern position based on fundamenta= l principle that I had assumed to be a _discarded_ SSL3 design precept. Th= is assert[ed] that a SSL3-enhanced socket supports a generic "application" = - versus a specific transport level entity in the stack. By seeking to reor= der and interleave the the internal TLS protocols to now perform "client id= entity/identification protection", we need to now be very clear whether we = are truly seeking to protect a T-entity, or a non T-entity (e.g. A-entity),= when Ethereal flags a client cert in a particular handshake protocol excha= nge, within the same TLS session. =20 A forcing question, to better understand this issue, may be as follows. If= the ciphersuite is pure kerberos-based, and no X.509 certificates thus exi= st in the protocol run, would "client identity/identification protection" b= y appropriate arranging the TLS protocols be protecting the privacy of the = computer's kerberos id, or the user's kerberos credentials? In the 802.1x w= orld, where the likes of EAP-TTLS reign, we EXPECT to make the distinction = between the computer's and the user's credentials, of course. Are we seeing= the implication from the document that TLS session might now have two or m= ore interleaved handshakes ongoing, each with distinct client id protection= s .. and reasons to interleave the various TLS protocols in different ways,= while on the record layer? =20 If TLS has truly made a break from the SSL3 architecture, surely any T-prot= ocol security should protect ONLY T-entities (the computer/process/T-bridge= /sslvpn-endpoint), not A-entities ( the user or a human's agent) =20 If my understanding of the modern TLS's wider security architecture holds, = would we not now EXPECT any andALL A-entity "Client identity/identification= protection" to be handled by its own layer (e.g. SAML2 APDU's borne over T= LS or TLS1.1 extensions), or by tunneling processes (e.g. EAP-TTLS) control= led by such applications? =20 My interest in this is really so much to review the I-D own claims, but th= e adjudge whether this particular I-D's interesting ideas can be supported = within the core standard. Its a useful case to determine whether TLS has ma= de a break from SSL truly, regarding layer separation in its security model= . Its possible TLS is just pretending, with all its new fancy definitional = constructs! Perhaps, its really just the same as the SSL3 concept, and a gi= ven handshake's client id shall AMBIGUOUSLY represent EITHER the user OR th= e stack entity (computer). Or, perhaps its really quite a different beast. =20 In conclusion, it WOULD be appropriate to "realign" and more carefully inte= rleave the modern TLS protocols to suit his "client id protection idea" if = the designers intend the protection to be internal to the T-layer exchange,= and do not intend of make upper layer security dependent upon this T-netwo= rk facility. In crypto-political terms, at IETF we do not want to now repea= t the phone company-based design practices, where the voice network is (a) = the ONLY security provider for a human user , and (b) is inherently untrust= worthy for personal privacy ( in the US anyways) - because of the the way t= he critical infrastructure policy was set to enable privacy expectations to= be compromised, as fitted into the the technical standards by the architec= ture adopted by the standardization groups. As a postscript, Im worried tha= t you selected a defense citing DoS. I wish TLS was clearer on whether it d= id or did not scope DoS within the set of issues this WG is designing for. = In the SSL2 world, it was a part of the thinking, I can note; though it was= not part of SSL3. Ive no idea what was indended for TLS. Given TLS standar= d still has some ssl2 design relics to consider, I suppose its not unreason= able that TLS is ambiguous on this! Are there any authoritative TLS protect= ion profiles out there to help us determine this issue, by looking at the C= C requirements they list? This may help qualify the protection value of the= ideas in the I-D, within a clearer TLS architecture. =20 Peter. > Date: Sun, 3 Dec 2006 03:42:27 +0100> Subject: RE: [TLS] Identity Protect= ion Ciphersuites for TLS> From: badra@isima.fr> To: home_pw@msn.com> CC: ib= rahim.hajjeh@esrgroups.org; tls@lists.ietf.org> > Hi Peter,> > The document= describes the protection of the "TLS client" certificate> (i.e. the TLS Ce= rtificate message) and not of the user-per-application> identity. In additi= on, it lists many existing solutions in the> introduction.> > EAP-TTLS (wit= h client based-certificate authentication), which is> equivalent to EAP-TLS= with privacy (see section 2.7 of EAP-TLS I-D) is> indirectly listed in the= introduction:> > Client identity protection may be also possible, assuming= that the> client permits renegotiation after the first server authenticati= on.> However, this requires more cryptographic computations and augments> s= ignificantly the number of rounds trips.> > It is true that EAP-TTLS (or EA= P-TLS with privacy) provides the same> thing, but:> > -You have to establis= h "two" TLS sessions with encryption/decryption of> the whole messages of t= he second session.> -You will not detect a forget client too early. in EAP-= TTLS, a forged> client can start a TLS session with only server authenticat= ion. The server> will not detect that only after sending its ServerHelloDon= e of the second> TLS session. This IMHO sensitivity increases the DoS attac= k's> effectiveness against the server> > > Client auth in a layer 4 protoco= l entity (supportiung normally a layer 5> > exchange to establish the curre= nt direction of the relationship) is> > (unlike in https) a matter of T-ent= ity authentication to another T-entity,> > surely? If we take an SSL/TL Con= enct proxy, is not the T-entity the proxy> > id, doing client auth, versus = the SAML identifded APDU-issuing user -> > whose identiifcation attributes = are protected by the SAML/STS-layer's> > "client identification protection"= ?> > I didn't entirely got the point here and its relationship to the docum= ent.> > Best regards,> Badra _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_3b70918b-90c8-4027-b4a5-61c47afa6c6d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The designers *seem* to be advocating a modern position based on fund= amental principle that I had assumed to be a _discarded_  SSL3 de= sign precept. This assert[ed] that a SSL3-enhanced socket supports a g= eneric "application" - versus a specific transport level entity in the= stack. By seeking to reorder and interleave the the internal TLS protocols= to now perform "client identity/identification protection", we need to now= be very clear whether we are truly seeking to protect a T-entity, or a non= T-entity (e.g. A-entity), when Ethereal flags a client cert in a part= icular handshake protocol exchange, within the same TLS session.
 
A forcing question,  to better understand this issue, may be as follow= s. If the ciphersuite is pure kerberos-based, and no X.509 certificates thu= s exist in the protocol run, would "client identity/identification protecti= on" by appropriate arranging the TLS protocols be protecting the = privacy of the computer's kerberos id, or the user's kerberos credentials? = In the 802.1x world, where the likes of EAP-TTLS reign, we EXPECT to make t= he distinction between the computer's and the user's credentials, of course= . Are we seeing the implication from the document that TLS session might no= w have two or more interleaved handshakes ongoing, each with distinct clien= t id protections .. and reasons to interleave the various TLS protocols in = different ways, while on the record layer?
 
If TLS has truly made a break from the SSL3 architecture, surely any T= -protocol security should protect ONLY T-entities (the computer/process/T-b= ridge/sslvpn-endpoint), not A-entities ( the user or a human's agent)
 
If my understanding of the modern TLS's wider security architecture ho= lds, would we not now EXPECT any andALL A-entity "Client identity/identific= ation protection" to be handled by its own layer (e.g. SAML2 APDU's borne o= ver TLS or TLS1.1 extensions), or by tunneling processes (e.g. EAP-TTLS) co= ntrolled by such applications?
 
My interest in this is really so much to review  the I-D own claims, b= ut the adjudge whether this particular I-D's interesting ideas can be = supported within the core standard. Its a useful case to determine whether = TLS has made a break from SSL truly, regarding layer separation in its secu= rity model. Its possible TLS is just pretending, with all its new fancy def= initional constructs! Perhaps, its really just the same as the SSL3 concept= , and a given handshake's client id shall AMBIGUOUSLY represent EITHER= the user OR the stack entity (computer).  Or, perhaps its really quit= e a different beast.
 
In conclusion, it WOULD be appropriate to "realign" and more carefully inte= rleave the modern TLS protocols to suit his "client id protection idea" if = the designers intend the protection to be internal to the T-layer exchange,= and do not intend of make upper layer security dependent upon this T-netwo= rk facility. In crypto-political terms, at IETF we do not want to now repea= t the phone company-based design practices, where the voice network is (a) = the ONLY security provider for a human user , and (b) is inherently untrust= worthy for personal privacy ( in the US anyways) - because of the the way t= he critical infrastructure policy was set to enable privacy expectations to= be compromised, as fitted into the the technical standards by the architec= ture adopted by the standardization groups.

As a postscript, Im wor= ried that you selected a defense citing DoS. I wish TLS was clearer on whet= her it did or did not scope DoS within the set of issues this WG is designi= ng for. In the SSL2 world, it was a part of the thin= king, I can note; though it was not part of SSL3. Ive no idea what was inde= nded for TLS. Given TLS standard still has some ssl2 design relics to consi= der, I suppose its not unreasonable that TLS is ambiguous on this! Are ther= e any authoritative TLS protection profiles out there to help us determine = this issue, by looking at the CC requirements they list? This may help qual= ify the protection value of the ideas in the I-D, within a clearer TLS arch= itecture.
 
Peter.



> Date: Sun, 3 Dec 2006 03:42:27 +0100
> Subject: RE: [TLS] Identi= ty Protection Ciphersuites for TLS
> From: badra@isima.fr
> To:= home_pw@msn.com
> CC: ibrahim.hajjeh@esrgroups.org; tls@lists.ietf.o= rg
>
> Hi Peter,
>
> The document describes the p= rotection of the "TLS client" certificate
> (i.e. the TLS Certificate= message) and not of the user-per-application
> identity. In addition= , it lists many existing solutions in the
> introduction.
> > EAP-TTLS (with client based-certificate authentication), which is
= > equivalent to EAP-TLS with privacy (see section 2.7 of EAP-TLS I-D) is=
> indirectly listed in the introduction:
>
> Client ide= ntity protection may be also possible, assuming that the
> client per= mits renegotiation after the first server authentication.
> However, = this requires more cryptographic computations and augments
> signific= antly the number of rounds trips.
>
> It is true that EAP-TTLS= (or EAP-TLS with privacy) provides the same
> thing, but:
> > -You have to establish "two" TLS sessions with encryption/decryption= of
> the whole messages of the second session.
> -You will not= detect a forget client too early. in EAP-TTLS, a forged
> client can= start a TLS session with only server authentication. The server
> wi= ll not detect that only after sending its ServerHelloDone of the second
= > TLS session. This IMHO sensitivity increases the DoS attack's
> = effectiveness against the server
>
> > Client auth in a lay= er 4 protocol entity (supportiung normally a layer 5
> > exchange = to establish the current direction of the relationship) is
> > (un= like in https) a matter of T-entity authentication to another T-entity,
= > > surely? If we take an SSL/TL Conenct proxy, is not the T-entity t= he proxy
> > id, doing client auth, versus the SAML identifded APD= U-issuing user -
> > whose identiifcation attributes are protected= by the SAML/STS-layer's
> > "client identification protection"?>
> I didn't entirely got the point here and its relationship t= o the document.
>
> Best regards,
> Badra


<= hr />Check the weather nationwide with MSN Search Try it now!= = --_3b70918b-90c8-4027-b4a5-61c47afa6c6d_-- --===============0180591219== 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 --===============0180591219==-- From tls-bounces@lists.ietf.org Sun Dec 03 13:42:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqwHH-0003J0-Iz; Sun, 03 Dec 2006 13:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqwHF-0003I1-Sd for tls@lists.ietf.org; Sun, 03 Dec 2006 13:41:25 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqwHD-0001Yt-K6 for tls@lists.ietf.org; Sun, 03 Dec 2006 13:41:25 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id DCE4998429 for ; Sun, 3 Dec 2006 13:41:38 -0500 (EST) 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 AC44D9840E for ; Sun, 3 Dec 2006 13:41:38 -0500 (EST) Message-ID: <45731A29.9030604@pobox.com> Date: Sun, 03 Dec 2006 10:40:41 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Identity Protection Ciphersuites for TLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > Perhaps, its really just the same as > the SSL3 concept, and a given handshake's client id shall AMBIGUOUSLY > represent EITHER the user OR the stack entity (computer). Or, perhaps > its really quite a different beast. There are examples of IETF protocols that use TLS to authenticate the user. SASL is used in several protocols, such as SMTP, where you can use the "EXTERNAL" mechanism to ask the server to use the TLS client credentials for authentication. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 03 15:19:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqxmv-0005eJ-Cx; Sun, 03 Dec 2006 15:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqxmu-0005eD-7P for tls@lists.ietf.org; Sun, 03 Dec 2006 15:18:12 -0500 Received: from bay0-omc1-s20.bay0.hotmail.com ([65.54.246.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqxms-00034e-H0 for tls@lists.ietf.org; Sun, 03 Dec 2006 15:18:12 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc1-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 12:18:09 -0800 X-Originating-IP: [71.140.80.73] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mike , Subject: RE: [TLS] Identity Protection Ciphersuites for TLS Date: Sun, 3 Dec 2006 12:18:10 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2006 20:18:09.0857 (UTC) FILETIME=[26A85B10:01C71718] X-Spam-Score: 2.4 (++) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a 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: , Content-Type: multipart/mixed; boundary="===============1522667133==" Errors-To: tls-bounces@lists.ietf.org --===============1522667133== Content-Type: multipart/alternative; boundary="_7ce3dfd3-169e-43ca-ba02-d70b9ebe30f7_" --_7ce3dfd3-169e-43ca-ba02-d70b9ebe30f7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this is excellent material to contrast architectures - and thus dec= ide what TLS does (that good old simple SASL might not!), and thus form a r= ationale for what the right protection elements are, within TLS, for handli= ng client id (user, computer, or other layer) =20 We can then ask:- =20 Does it help ...to define whether TLS OUGHT itself to protect client id tra= nsfers, or should that be left the designer of the secure "application cont= ext" (the set of secuirty protocol, up and down the stack?). We have the ad= mission in the refutation, afterall, that EAP-TTLS does, via decent context= ual SP architecture, most of what the proposal sets out to do. =20 SASL =3D=3D=3D =20 SASL is only for connection-oriented protocols. It has S5.3 restrictions on= multiple authentications, and faciliate "security layers". Its has a gener= ic bag approach to handling security services and mechanism, and can invoke= GSSAPI (just like MSFT wanted is proposing for TLS workitem). It already s= hows how to bind S/KEY directly within the SASL world. A "client" must ini= tiate the first byte of a handshake. =20 on External, there are some very specific semantics, concerning authorizati= on and authentication: "The server uses information, external to SASL, to d= etermine whether the client is authorized to authenticate as the authorizat= ion identity. ". You can try to parse what that means, professionally, as w= ell as I can! If I rewrite that in security target language, I think it me= ans:"The server uses authentication information, external to SASL, to deter= mine whether the client is authorized to (even) connect to the SASL endpoin= t". =20 =20 TLS =3D=3D=3D =20 TLS only assumes a reliable byte channel, not a connection-oriented protoco= l bearer. TLS does not mandate NCSC RedBook's connection-oriented paradigm, for trust= ed network design (neither does it deny it) TLS assumes designers specify ciphersuites, custom ciphersuite negotiation = protocols (and other custom protocols) using the TLS "record type" conventi= onsTLS allows each designer to interleave protocols on the record layer pro= tocol, with application data. Std protocols and custom record types thus bo= th get encapsulated on the same record layer bearer. TLS allows the stack entity to fragment/reassemble the pdu stream to suit p= du transfer security objectives set by the layer 6 handshake,, including co= mpression goals negotiated in the P-connect. TLS allows a layer 5 protocol to interactively turn the direction of the SS= L relationship: which party issues the "client" certs, that is (and, in SSL= 2, require the respondent to act as SSL2 session resumption _controller_)Th= en, if we now take the SKEY issue from the SASL standard, using RSA's worke= d example instead, to aid in discussing OTP issues in a layered protocol st= ack context: =20 TLS would expect the one-time password (for a user (hand held OTPs) or a co= mputer (USB OTP devices)) to be encapsulated in a ws-security XML message, = be formally bound by that web services's protocol suite to such as https ac= ting as bearer, such that the XML blob eventually gets stuffed (a) in the T= LS 1.1 application data, (b) a TLS1.1 extensions, (c) or a custom handshake= within a TLS media type. (* refer to the RSA Labs OTPS standards to see ho= w its _actually_ done, professionally, in the EAP world). Contrast: =20 These are quite different archiectures. One is simple (SASL) and delegates = much to GSSAPI, and gets the job done trivially: one is a infrastructure fo= r designers of assured stacks. And don't someone start whining at me about = old OSI stacks. The web is as bad now with all its web services XML layers = as OSI ever was, rewritten as horrendous strings, these days!=20 =20 SASL and TLS have different mindsets, clearly. TLS existed MERELY to fill t= he gap that IPSEC (and IPv6) would eventually fill, with the same quality o= f architecture (limited to what is possible, given a socket consumer should= not be attempting normally control the media via the network adaptor, whic= h IPSEC can). Once Ipv4 and NAT goes away, we may yet be rid of TLS. =20 Client ID protection: users vs computers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =20 Its still an open question for me, but the actual controversy is now well i= dentified, and we are a better starting point for getting a buyin to the pr= oposed resolution: =20 There are two positions so far:- =20 1. Do we advocate proper layering (EAP-TTLS) for client id protection? =20 2. Or, do we we accept the (high quality) proposition from the I-D - and st= andardize record layer rules, concerning how the various record types MUST = interleave amongst themselves, or be tunneled with the assumed security of = a (partial) SSL session setup. =20 =20 =20 > Date: Sun, 3 Dec 2006 10:40:41 -0800> From: mike-list@pobox.com> To: tls@= lists.ietf.org> Subject: Re: [TLS] Identity Protection Ciphersuites for TLS= > > > Perhaps, its really just the same as > > the SSL3 concept, and a give= n handshake's client id shall AMBIGUOUSLY > > represent EITHER the user OR = the stack entity (computer). Or, perhaps > > its really quite a different b= east.> > There are examples of IETF protocols that use TLS to authenticate = the> user. SASL is used in several protocols, such as SMTP, where you can> = use the "EXTERNAL" mechanism to ask the server to use the TLS client> crede= ntials for authentication.> > Mike> > _____________________________________= __________> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mai= lman/listinfo/tls _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_7ce3dfd3-169e-43ca-ba02-d70b9ebe30f7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think this is excellent material to contrast architectures - and th= us decide what TLS does (that good old simple SASL might not!), and thus fo= rm a rationale for what the right protection elements are, within TLS, for = handling client id (user, computer, or other layer)
 
We can then ask:-
 
Does it help ...to define whether TLS OUGHT itself to protect client id tra= nsfers, or should that be left the designer of the secure "application cont= ext" (the set of secuirty protocol, up and down the stack?). We have the ad= mission in the refutation, afterall, that EAP-TTLS does, via decent co= ntextual SP architecture, most of what the proposal sets out to do.
 
SASL
=3D=3D=3D
 
SASL is only for connection-oriented protocols. It has S5.3 restrictions on= multiple authentications, and faciliate "security layers". Its has a gener= ic bag approach to handling security services and mechanism, and can invoke= GSSAPI (just like MSFT wanted is proposing for TLS workitem). It already s= hows how to bind S/KEY directly within the SASL world.  A "client" mus= t initiate the first byte of a handshake.
 
on External, there are some very specific semantics, concerning authorizati= on and authentication: "The server uses information, external to SASL, to d= etermine whether the client is authorized to authenticate as the authorizat= ion identity. ". You can try to parse what that means, professionally, as w= ell as I can! If I rewrite that in security target language,  I t= hink it means:"The server uses authentication information, external to SASL= , to determine whether the client is authorized to (even) connect to the SA= SL endpoint".
 
 
TLS
=3D=3D=3D
 
TLS only assumes a reliable byte channel, not a connection-oriented protoco= l bearer.
TLS does not mandate NCSC RedBook's connection-oriented paradigm, for trust= ed network design (neither does it deny it)
TLS assumes designers specify ciphersuites, custom ciphersuite negotiation = protocols (and other custom protocols) using the TLS "record type" conventi= ons
TLS allows each designer to interleave protocols on the record layer= protocol, with application data. Std protocols and custom record types thu= s both get encapsulated on the same record layer bearer.
TLS allows the stack entity to fragment/reassemble the pdu stream to suit p= du transfer security objectives set by the layer 6 handshake,, including co= mpression goals negotiated in the P-connect.
TLS allows a layer 5 protocol to interactively turn the direction of t= he SSL relationship: which party issues the "client" certs, that is (and, i= n SSL2, require the respondent to act as SSL2 session resumption _controlle= r_)

Then, if we now take the SKEY issue from the SASL standard, usin= g RSA's worked example instead, to aid in discussing OTP issues in a layere= d protocol stack context:
 
TLS would expect the one-time password (for a user (hand held OTPs) or a co= mputer (USB OTP devices)) to be encapsulated in a ws-security XML message, = be formally bound by that web services's protocol suite to such as https ac= ting as bearer, such that the XML blob eventually gets stuffed (a) in the T= LS 1.1 application data, (b) a TLS1.1 extensions, (c) or a custom hand= shake within a TLS media type. (* refer to the RSA Labs OTPS standards to s= ee how its _actually_ done, professionally, in the EAP world).

Contrast:
 
These are quite different archiectures. One is simple (SASL) and delegates = much to GSSAPI, and gets the job done trivially: one is a infrastructure fo= r designers of assured stacks. And don't someone start whining at me about = old OSI stacks. The web is as bad now with all its web services XML layers = as OSI ever was, rewritten as horrendous strings, these days!
 
SASL and TLS have different mindsets, clearly. TLS existed MERELY to fill t= he gap that IPSEC (and IPv6) would eventually fill, with the same quality o= f architecture (limited to what is possible, given a socket consumer should= not be attempting normally control the media via the network adaptor, whic= h IPSEC can). Once Ipv4 and NAT goes away, we may yet be rid of TLS.
 
Client ID protection: users  vs computers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
 
Its still an open question for me, but the actual controversy is now well i= dentified, and we are a better starting point for getting a buyin to the pr= oposed resolution:
 
There are two positions so far:-
 
1. Do we advocate proper layering (EAP-TTLS) for client id protection?
 
2. Or, do we we accept the (high quality) proposition from the I-D - and st= andardize record layer rules, concerning how the various record types MUST = interleave amongst themselves, or be tunneled with the assumed security of = a (partial) SSL session setup.
 
 

 

> Date: Sun, 3 Dec 2006 10:40:41 -0800
> From: mike-list@pobox.com=
> To: tls@lists.ietf.org
> Subject: Re: [TLS] Identity Protect= ion Ciphersuites for TLS
>
> > Perhaps, its really just the= same as
> > the SSL3 concept, and a given handshake's client id = shall AMBIGUOUSLY
> > represent EITHER the user OR the stack enti= ty (computer). Or, perhaps
> > its really quite a different beast= .
>
> There are examples of IETF protocols that use TLS to aut= henticate the
> user. SASL is used in several protocols, such as SMTP= , where you can
> use the "EXTERNAL" mechanism to ask the server to u= se the TLS client
> credentials for authentication.
>
> = Mike
>
> _______________________________________________
&g= t; TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.or= g/mailman/listinfo/tls


Check the weather nationwide with= MSN Search Try it now! = --_7ce3dfd3-169e-43ca-ba02-d70b9ebe30f7_-- --===============1522667133== 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 --===============1522667133==-- From tls-bounces@lists.ietf.org Mon Dec 04 04:34:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrACG-0007tG-US; Mon, 04 Dec 2006 04:33:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrACF-0007tA-CT for tls@lists.ietf.org; Mon, 04 Dec 2006 04:33:11 -0500 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 1GrACD-0006Ox-Up for tls@lists.ietf.org; Mon, 04 Dec 2006 04:33:11 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB49WeEe014505; Mon, 4 Dec 2006 11:32:59 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:32:38 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:32:38 +0200 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: Two notes on TLS 1.2 after implementing it in GnuTLS Date: Mon, 4 Dec 2006 11:32:38 +0200 Message-ID: In-Reply-To: <456F0CC8.1040405@drh-consultancy.demon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS Thread-Index: AccUoMHRDta0rRZmRoWIBdBiguMbgQC5GTDw From: To: , X-OriginalArrivalTime: 04 Dec 2006 09:32:38.0616 (UTC) FILETIME=[2373BD80:01C71787] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Stephen Henson wrote: > As I think has been mentioned some implementations generate the > DigestInfo structure using a cut+paste operation from a binary blob. > Others perform cut, paste and compare for the verify operation. Yes; for example IEEE 1363a-2004 specifies the hash identifier for SHA-1 as fixed hex string "3021300906052b0e03021a05000414" instead=20 of talking about OIDs and DER encoding. > Some existing examples, such as smart cards, cannot change the format > they use and would be rendered non compliant if we make their format > illegal. >=20 > All the examples I've seen using that technique (and a few specs) > require that a NULL parameter is present and not omitted but I can't > rule out some which may omit parameters. It's good to note that smart cards that do only RSASSA-PKCS1-v1_5=20 with omitted parameters are already non-compliant with TLS, since all existing versions of TLS use a custom signature scheme instead=20 of normal PKCS#1 signatures. But I do agree that it would be a good idea to be compatible with existing RSA smart cards, tokens, and other difficult-to-change implementations. Does anyone else have more information about what existing implementations do? Is formatting the hash to DigestInfo structure usually done in the token, or the library calling it (presumably easier to change)? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 06 13:24:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1QA-0000pb-QA; Wed, 06 Dec 2006 13:23:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs1Q9-0000pW-1i for tls@lists.ietf.org; Wed, 06 Dec 2006 13:23:05 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs1Q7-0001ai-RH for tls@lists.ietf.org; Wed, 06 Dec 2006 13:23:05 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id CBC6424C30 for ; Wed, 6 Dec 2006 13:23:20 -0500 (EST) 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 proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 92D4C99CC3 for ; Wed, 6 Dec 2006 13:23:20 -0500 (EST) Message-ID: <457709F7.9010900@pobox.com> Date: Wed, 06 Dec 2006 10:20:39 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 While not exactly the same thing, RFC 4055 discusses using various SHA digest algorithms in an AlgorithmIdentifier. In it, it says you must accept either encoding, with or without NULL parameters: There are two possible encodings for the AlgorithmIdentifier parameters field associated with these object identifiers. The two alternatives arise from the loss of the OPTIONAL associated with the algorithm identifier parameters when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax. Later the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history some implementations encode parameters as a NULL element while others omit them entirely. The correct encoding is to omit the parameters field; however, when RSASSA-PSS and RSAES-OAEP were defined, it was done using the NULL parameters rather than absent parameters. All implementations MUST accept both NULL and absent parameters as legal and equivalent encodings. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 08 08:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfIe-0001gg-5p; Fri, 08 Dec 2006 07:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfIc-0001gY-SA for tls@lists.ietf.org; Fri, 08 Dec 2006 07:57:58 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsfIb-0007Mm-Fm for tls@lists.ietf.org; Fri, 08 Dec 2006 07:57:58 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 9BC5534FAC; Sat, 9 Dec 2006 01:57:52 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18493-17; Sat, 9 Dec 2006 01:57:52 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 148BC34F92; Sat, 9 Dec 2006 01:57:51 +1300 (NZDT) 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 AE13637742; Sat, 9 Dec 2006 01:57:50 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GsfId-0008KT-00; Sat, 09 Dec 2006 01:57:59 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, tls@lists.ietf.org Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS In-Reply-To: <7.0.0.16.2.20061130103805.0409bc08@vigilsec.com> Message-Id: Date: Sat, 09 Dec 2006 01:57:59 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) 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 Russ Housley writes: >I would like to see this documented in a separate document that can be >referenced by TLS, S/MIME, and any other protocol that needs to make use of >PKCS#1 v1.5. Do you mean the NULL/absent parameters issue? I can do that fairly easily, I've still got the text I used for the PWRI RFC, and as I mentioned in an earlier post it'd be good to have a single point of reference for this. Since it's cross-WG, under whose auspices would the draft be handled? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 10 11:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtRr3-0005Q7-1z; Sun, 10 Dec 2006 11:48:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtRr1-0005Pw-QV for tls@lists.ietf.org; Sun, 10 Dec 2006 11:48:43 -0500 Received: from bay0-omc1-s41.bay0.hotmail.com ([65.54.246.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtRqx-0005XU-E5 for tls@lists.ietf.org; Sun, 10 Dec 2006 11:48:43 -0500 Received: from BAY103-W5 ([65.54.174.105]) by bay0-omc1-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 10 Dec 2006 08:48:38 -0800 X-Originating-IP: [64.148.145.220] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mike , Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS Date: Sun, 10 Dec 2006 08:48:38 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2006 16:48:38.0676 (UTC) FILETIME=[0A8A9D40:01C71C7B] X-Spam-Score: 2.6 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Content-Type: multipart/mixed; boundary="===============2105927063==" Errors-To: tls-bounces@lists.ietf.org --===============2105927063== Content-Type: multipart/alternative; boundary="_2be9e356-7a62-44b7-89b0-c0c275119685_" --_2be9e356-7a62-44b7-89b0-c0c275119685_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "OpenVPN actually runs TLS over UDP byimplementing a reliability layer for = the TLS control channel. TLS is a fairlystrong, well regarded protocol, ea= sily accessible using the OpenSSL library,and it seems to be the obvious ch= oice for initial authentication and keyexchange. "http://sites.inka.de/bigr= ed/archive/cipe-l/2003-09/msg00263.html Is this still true? I'm proud of the designers who did this, if its true. T= hey "got it' - the security architecture, that is.GnuTLS work for TLS1.2-er= a should make efforts to replicate the architecture, and ensure the SSL/TLS= record layer is not bound to TCP. =20 That is not to say that the embodiment of the SSL2/TLS fragmentation/reasse= mbly functions in the record (+ SSL2 escape or TLS1.1 custom record type es= capes for OOB) should be tied to the nature of the network media - but that= the stack API (sockets or libraries) should NOT assume anything about the = nature of TCP, in theory or practice. _________________________________________________________________ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=3D7adb59de-a857-45ba-81cc-= 685ee3e858fe= --_2be9e356-7a62-44b7-89b0-c0c275119685_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "OpenVPN actually runs TLS over UDP by
implementing a reliability = layer for the TLS control channel.  TLS is a fairly
strong, well re= garded protocol, easily accessible using the OpenSSL library,
and it see= ms to be the obvious choice for initial authentication and key
exchange.= "
http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00263.html

Is this still true? I'm proud of the designers who did this, if its true. T= hey "got it' - the security architecture, that is.

GnuTLS work for T= LS1.2-era should make efforts to replicate the architecture, and ensure the= SSL/TLS record layer is not bound to TCP.
 
That is not to say that the embodiment of the SSL2/TLS fragmentation/reasse= mbly functions in the record (+ SSL2 escape or TLS1.1 custom record type es= capes for OOB) should be tied to the nature of the network media - but that= the stack API (sockets or libraries) should NOT assume anything about the = nature of TCP, in theory or practice.

Use Messenger to talk = to your IM friends, even those on Yahoo! Talk now! = --_2be9e356-7a62-44b7-89b0-c0c275119685_-- --===============2105927063== 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 --===============2105927063==-- From tls-bounces@lists.ietf.org Sun Dec 10 12:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtSCs-0004oQ-3g; Sun, 10 Dec 2006 12:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtSCq-0004o3-CW for tls@lists.ietf.org; Sun, 10 Dec 2006 12:11:16 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtSCn-0001H1-VT for tls@lists.ietf.org; Sun, 10 Dec 2006 12:11:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 8113834010; Mon, 11 Dec 2006 06:11:11 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16126-22; Mon, 11 Dec 2006 06:11:11 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 311F933E76; Mon, 11 Dec 2006 06:11:10 +1300 (NZDT) 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 B273C37742; Mon, 11 Dec 2006 06:11:10 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GtSCv-0006Ey-00; Mon, 11 Dec 2006 06:11:21 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: home_pw@msn.com, mike-list@pobox.com, tls@lists.ietf.org Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS In-Reply-To: Message-Id: Date: Mon, 11 Dec 2006 06:11:21 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Peter Williams writes: >"OpenVPN actually runs TLS over UDP byimplementing a reliability layer for >the TLS control channel. TLS is a fairlystrong, well regarded protocol, >easily accessible using the OpenSSL library,and it seems to be the obvious >choice for initial authentication and keyexchange. " >http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00263.html In a nutshell what OpenVPN does is use TLS for the handshake and IPsec's ESP for the UDP transport. >Is this still true? I'm proud of the designers who did this, if its true. >They "got it' They certainly did. Throw away IKE and AH, and what's left of IPsec (ESP) is actually pretty decent - they took the bits that worked and glued them together to get... well, something else that works. Unfortunately the result is completely unpalatable to the IPsec folks, and probably not too palatable for the TLS side either. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 10 12:58:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtSvG-0002n9-Qx; Sun, 10 Dec 2006 12:57:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtSvF-0002mb-Iw for tls@lists.ietf.org; Sun, 10 Dec 2006 12:57:09 -0500 Received: from bay0-omc2-s33.bay0.hotmail.com ([65.54.246.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtSvE-0007re-1d for tls@lists.ietf.org; Sun, 10 Dec 2006 12:57:09 -0500 Received: from BAY103-W7 ([65.54.174.107]) by bay0-omc2-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 10 Dec 2006 09:57:07 -0800 X-Originating-IP: [64.148.145.220] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Peter Gutmann , , Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS Date: Sun, 10 Dec 2006 09:57:07 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2006 17:57:07.0341 (UTC) FILETIME=[9B7F23D0:01C71C84] X-Spam-Score: 2.4 (++) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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: , Content-Type: multipart/mixed; boundary="===============2077282681==" Errors-To: tls-bounces@lists.ietf.org --===============2077282681== Content-Type: multipart/alternative; boundary="_8db66480-9fbd-482f-bbb7-6722da208798_" --_8db66480-9fbd-482f-bbb7-6722da208798_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sounds more like they are using some or parts of the "SSL Handshake" (parts= of which are now known as a "client protocols" of the TLS record layer, in= a very dubious architectural move by IETF :-) given the SSL "privacy" goal= ) as a replacement for IKE, within the IPSEC architecture.=20 =20 I.E. there may be no TLS Record layer, in openVPN's application context ? =20 I can see why this will get the DARPA-funded folks in IETF jumping up and d= own, with rage; its dumps the (US-dominated) oakley compromises. =20 I don't believe this (i.e. merely) was an intended modality of the SSL pate= nt, but _not_ inconsistent with the open-ness intended. N&S-derived handsha= kes for accessing network authentication servers have been around a fair wh= ile! I remember reading the article on the Cambridge design, when I was at = school (20 years ago)! =20 WS-SX's SecureConversation is following the same course as OpenVPN we can n= ote, however. They are paying careful attention paid to how T-bridges can b= e handled, each with different security policies concerning how handshakes = are selected, the crypto module is seeded etc. It updates and nicely extend= s much of the unspecified/unstandardized work done in SSL Connect proxy lan= d, with a strong focus on (a) multiple key management domains for each brid= ge segment, and (b) ensuring connectionless transports are properly handled= (c) initiator/respondent access point roaming, and auto-rekeying of the ca= scade of T-bridge segments... upon roam of either endpoint (GSM security mo= del, styled) =20 =20 > From: pgut001@cs.auckland.ac.nz> To: home_pw@msn.com; mike-list@pobox.com= ; tls@lists.ietf.org> Subject: RE: [TLS] Re: Two notes on TLS 1.2 after imp= lementing it in GnuTLS> Date: Mon, 11 Dec 2006 06:11:21 +1300> > Peter Will= iams writes:> > >"OpenVPN actually runs TLS over UDP byim= plementing a reliability layer for> >the TLS control channel. TLS is a fair= lystrong, well regarded protocol,> >easily accessible using the OpenSSL lib= rary,and it seems to be the obvious> >choice for initial authentication and= keyexchange. "> >http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg002= 63.html> > In a nutshell what OpenVPN does is use TLS for the handshake and= IPsec's ESP> for the UDP transport.> > >Is this still true? I'm proud of t= he designers who did this, if its true.> >They "got it' > > They certainly = did. Throw away IKE and AH, and what's left of IPsec (ESP) is> actually pre= tty decent - they took the bits that worked and glued them> together to get= ... well, something else that works.> > Unfortunately the result is complet= ely unpalatable to the IPsec folks, and> probably not too palatable for the= TLS side either.> > Peter. _________________________________________________________________ Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! http://get.live.com/toolbar/overview= --_8db66480-9fbd-482f-bbb7-6722da208798_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable sounds more like they are using some or parts of the "SSL Handshake" = (parts of which are now known as a "client protocols" of the TLS record lay= er, in a very dubious architectural move by IETF :-) given the SSL "privacy= " goal) as a replacement for IKE, within the IPSEC architecture.
 
I.E. there may be no TLS Record layer, in openVPN's application context ?  
I can see why this will get the DARPA-funded folks in IETF jumping up and d= own, with rage; its dumps the (US-dominated) oakley compromises.
 
I don't believe this (i.e. merely) was an intended modality of the SSL= patent, but _not_ inconsistent with the open-ness intended. N&S-derive= d handshakes for accessing network authentication servers have been around = a fair while! I remember reading the article on the Cambridge design, when = I was at school (20 years ago)!
 
WS-SX's SecureConversation is following the same course as OpenVPN we can n= ote, however. They are paying careful attention paid to how T-bridges can b= e handled, each with different security policies concerning how handshakes = are selected, the crypto module is seeded etc. It updates and nicely extend= s much of the unspecified/unstandardized work done in SSL Connect proxy lan= d, with a strong focus on (a) multiple key management domains for each brid= ge segment, and (b) ensuring connectionless transports are properly handled= (c) initiator/respondent access point roaming, and auto-rekeying of t= he cascade of T-bridge segments... upon roam of either endpoint (GSM securi= ty model, styled)
 


 

> From: pgut001@cs.auckland.ac.nz
> To: home_pw@msn.com; mike-list= @pobox.com; tls@lists.ietf.org
> Subject: RE: [TLS] Re: Two notes on = TLS 1.2 after implementing it in GnuTLS
> Date: Mon, 11 Dec 2006 06:1= 1:21 +1300
>
> Peter Williams <home_pw@msn.com> writes:<= BR>>
> >"OpenVPN actually runs TLS over UDP byimplementing a r= eliability layer for
> >the TLS control channel. TLS is a fairlyst= rong, well regarded protocol,
> >easily accessible using the OpenS= SL library,and it seems to be the obvious
> >choice for initial au= thentication and keyexchange. "
> >http://sites.inka.de/bigred/arc= hive/cipe-l/2003-09/msg00263.html
>
> In a nutshell what OpenV= PN does is use TLS for the handshake and IPsec's ESP
> for the UDP tr= ansport.
>
> >Is this still true? I'm proud of the designer= s who did this, if its true.
> >They "got it'
>
> Th= ey certainly did. Throw away IKE and AH, and what's left of IPsec (ESP) is<= BR>> actually pretty decent - they took the bits that worked and glued t= hem
> together to get... well, something else that works.
> > Unfortunately the result is completely unpalatable to the IPsec folks= , and
> probably not too palatable for the TLS side either.
> <= BR>> Peter.


Search from any Web page with powerful pr= otection. Get the FREE Windows Live Toolbar Today! Try it now! = --_8db66480-9fbd-482f-bbb7-6722da208798_-- --===============2077282681== 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 --===============2077282681==-- From tls-bounces@lists.ietf.org Sun Dec 10 13:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtTWM-0006Ix-3L; Sun, 10 Dec 2006 13:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtTWL-0006Im-5d for tls@lists.ietf.org; Sun, 10 Dec 2006 13:35:29 -0500 Received: from bay0-omc3-s36.bay0.hotmail.com ([65.54.246.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtTWH-0004a0-FY for tls@lists.ietf.org; Sun, 10 Dec 2006 13:35:29 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 10 Dec 2006 10:35:24 -0800 X-Originating-IP: [64.148.145.220] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Date: Sun, 10 Dec 2006 10:35:24 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2006 18:35:24.0810 (UTC) FILETIME=[F4E516A0:01C71C89] X-Spam-Score: 2.4 (++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: [TLS] RFC 2817 proposed standard status revocation? 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="===============0825762569==" Errors-To: tls-bounces@lists.ietf.org --===============0825762569== Content-Type: multipart/alternative; boundary="_901f8fb4-8912-4a13-b254-3cc250db618d_" --_901f8fb4-8912-4a13-b254-3cc250db618d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I assume this WG is, or would be, responsible for handling RFC2817 standard= s track issues?http://tools.ietf.org/html/rfc2817. =20 I record my recommendation that the cited document have its PROPOSED STANDA= RD status revoked. Period. Its bad (SSL) theory, and even worse practice. =20 I understand from the text what Rohit was aiming for, and why; but its the = wrong tack. The HTTP 1.1 update profile for SSL should not be attempting as= an INTERNET STANDARD to be a universal upper-layer stack protocol: using A= -bridges everywhere, smushing what the distinct layers do, adding A-layer m= ultiplexing for IP-addressed endpoints, and mis-purposing SSL's stack-orien= ted security model.=20 =20 Subsequent to that RFC 2817 era, ws-security and soap have essentially re-i= nvented what ISO's upper-layer-security and ROSE/RTS/Presentation/Session p= rotocols used to attempt to do, for open networks. The modern web services = architecture does use the SSL security architecture properly, however - and= will thus easily move to the (competing) IPSEC security architecture ...on= ce IPv6 gets ubiquitous. =20 Never ever forget, SSL was intended as an IPSEC stopgap. In IETF, dont forc= e TLS into a long term position in the internet security architecture that = it doesn't deserve (e.g. RFC2817). It is SUPPOSED to go away, at some point= . =20 =20 From: home_pw@msn.comTo: pgut001@cs.auckland.ac.nz; mike-list@pobox.com; tl= s@lists.ietf.orgSubject: RE: [TLS] Re: Two notes on TLS 1.2 after implement= ing it in GnuTLSDate: Sun, 10 Dec 2006 09:57:07 -0800 sounds more like they are using some or parts of the "SSL Handshake" (parts= of which are now known as a "client protocols" of the TLS record layer, in= a very dubious architectural move by IETF :-) given the SSL "privacy" goal= ) as a replacement for IKE, within the IPSEC architecture. I.E. there may = be no TLS Record layer, in openVPN's application context ? I can see why th= is will get the DARPA-funded folks in IETF jumping up and down, with rage; = its dumps the (US-dominated) oakley compromises. I don't believe this (i.e.= merely) was an intended modality of the SSL patent, but _not_ inconsistent= with the open-ness intended. N&S-derived handshakes for accessing network = authentication servers have been around a fair while! I remember reading th= e article on the Cambridge design, when I was at school (20 years ago)! WS-= SX's SecureConversation is following the same course as OpenVPN we can note= , however. They are paying careful attention paid to how T-bridges can be h= andled, each with different security policies concerning how handshakes are= selected, the crypto module is seeded etc. It updates and nicely extends m= uch of the unspecified/unstandardized work done in SSL Connect proxy land, = with a strong focus on (a) multiple key management domains for each bridge = segment, and (b) ensuring connectionless transports are properly handled (c= ) initiator/respondent access point roaming, and auto-rekeying of the casca= de of T-bridge segments... upon roam of either endpoint (GSM security model= , styled) =20 > From: pgut001@cs.auckland.ac.nz> To: home_pw@msn.com; mike-list@pobox.com= ; tls@lists.ietf.org> Subject: RE: [TLS] Re: Two notes on TLS 1.2 after imp= lementing it in GnuTLS> Date: Mon, 11 Dec 2006 06:11:21 +1300> > Peter Will= iams writes:> > >"OpenVPN actually runs TLS over UDP byim= plementing a reliability layer for> >the TLS control channel. TLS is a fair= lystrong, well regarded protocol,> >easily accessible using the OpenSSL lib= rary,and it seems to be the obvious> >choice for initial authentication and= keyexchange. "> >http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg002= 63.html> > In a nutshell what OpenVPN does is use TLS for the handshake and= IPsec's ESP> for the UDP transport.> > >Is this still true? I'm proud of t= he designers who did this, if its true.> >They "got it' > > They certainly = did. Throw away IKE and AH, and what's left of IPsec (ESP) is> actually pre= tty decent - they took the bits that worked and glued them> together to get= ... well, something else that works.> > Unfortunately the result is complet= ely unpalatable to the IPsec folks, and> probably not too palatable for the= TLS side either.> > Peter. Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! Try it now!=20 _________________________________________________________________ All-in-one security and maintenance for your PC.=A0 Get a free 90-day trial= ! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=3Dwl_wlmail= --_901f8fb4-8912-4a13-b254-3cc250db618d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I assume this WG is, or would be, responsible for handling RF= C2817 standards track issues?

http://tools.ietf.org/html/rfc2817.
 
I record my recommendation that the cited document have its PROPOSED STANDA= RD status revoked. Period. Its bad (SSL) theory, and even worse practice.  
I understand from the text what Rohit was aiming for, and why; but its the = wrong tack. The HTTP 1.1 update profile for SSL should not be attempting as= an INTERNET STANDARD to be a universal upper-layer stack protocol: us= ing A-bridges everywhere, smushing what the distinct layers do, adding A-la= yer multiplexing for IP-addressed endpoints, and mis-purposing SSL's s= tack-oriented security model.
 
Subsequent to that RFC 2817 era, ws-security and soap have essentially re-i= nvented what ISO's upper-layer-security and ROSE/RTS/Presentation/Session p= rotocols used to attempt to do, for open networks. The modern web services = architecture does use the SSL security architecture properly, however = - and will thus easily move to the (competing) IPSEC security architecture = ...once IPv6 gets ubiquitous.
 
Never ever forget, SSL was intended as an IPSEC stopgap. In IETF, dont forc= e TLS into a long term position in the internet security architecture that = it doesn't deserve (e.g. RFC2817). It is SUPPOSED to go away, at some point= .
 
 

From: home_pw@msn.com
To: pgut001@cs.auckland.ac.nz; mike-list@pobox.com= ; tls@lists.ietf.org
Subject: RE: [TLS] Re: Two notes on TLS 1.2 after i= mplementing it in GnuTLS
Date: Sun, 10 Dec 2006 09:57:07 -0800

sounds more like they are using some or parts of the "SSL Handshake" (parts= of which are now known as a "client protocols" of the TLS record layer, in= a very dubious architectural move by IETF :-) given the SSL "privacy" goal= ) as a replacement for IKE, within the IPSEC architecture.
 
I.= E. there may be no TLS Record layer, in openVPN's application context ?
=  
I can see why this will get the DARPA-funded folks in IETF jumpin= g up and down, with rage; its dumps the (US-dominated) oakley compromises.<= BR> 
I don't believe this (i.e. merely) was an intended modali= ty of the SSL patent, but _not_ inconsistent with the open-ness intended. N= &S-derived handshakes for accessing network authentication servers have= been around a fair while! I remember reading the article on the Cambridge = design, when I was at school (20 years ago)!
 
WS-SX's SecureCon= versation is following the same course as OpenVPN we can note, however. The= y are paying careful attention paid to how T-bridges can be handled, each w= ith different security policies concerning how handshakes are selected, the= crypto module is seeded etc. It updates and nicely extends much of the uns= pecified/unstandardized work done in SSL Connect proxy land, with a strong = focus on (a) multiple key management domains for each bridge segment, and (= b) ensuring connectionless transports are properly handled (c) initiat= or/respondent access point roaming, and auto-rekeying of the cascade of T-b= ridge segments... upon roam of either endpoint (GSM security model, styled)=
 


 



> From: pgut001@cs.auckland.ac.nz
> To: home_pw@msn.com; mike-= list@pobox.com; tls@lists.ietf.org
> Subject: RE: [TLS] Re: Two notes= on TLS 1.2 after implementing it in GnuTLS
> Date: Mon, 11 Dec 2006 = 06:11:21 +1300
>
> Peter Williams <home_pw@msn.com> writ= es:
>
> >"OpenVPN actually runs TLS over UDP byimplementing= a reliability layer for
> >the TLS control channel. TLS is a fair= lystrong, well regarded protocol,
> >easily accessible using the O= penSSL library,and it seems to be the obvious
> >choice for initia= l authentication and keyexchange. "
> >http://sites.inka.de/bigred= /archive/cipe-l/2003-09/msg00263.html
>
> In a nutshell what O= penVPN does is use TLS for the handshake and IPsec's ESP
> for the UD= P transport.
>
> >Is this still true? I'm proud of the desi= gners who did this, if its true.
> >They "got it'
>
>= ; They certainly did. Throw away IKE and AH, and what's left of IPsec (ESP)= is
> actually pretty decent - they took the bits that worked and glu= ed them
> together to get... well, something else that works.
>=
> Unfortunately the result is completely unpalatable to the IPsec f= olks, and
> probably not too palatable for the TLS side either.
&g= t;
> Peter.




Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! Try it now!

All-in-one security and maintenance = for your PC.=A0 Get a free 90-day trial! Learn more!<= /a> = --_901f8fb4-8912-4a13-b254-3cc250db618d_-- --===============0825762569== 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 --===============0825762569==-- From tls-bounces@lists.ietf.org Sun Dec 10 18:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtYFs-0002Bh-MO; Sun, 10 Dec 2006 18:38:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtYFq-0002BB-Rk for tls@lists.ietf.org; Sun, 10 Dec 2006 18:38:46 -0500 Received: from bay0-omc1-s3.bay0.hotmail.com ([65.54.246.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtYFo-0003XV-5k for tls@lists.ietf.org; Sun, 10 Dec 2006 18:38:46 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc1-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 10 Dec 2006 15:38:41 -0800 X-Originating-IP: [64.148.145.220] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Benjamin Black Subject: RE: [TLS] RFC 2817 proposed standard status revocation? Date: Sun, 10 Dec 2006 15:38:41 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2006 23:38:41.0494 (UTC) FILETIME=[52F6B760:01C71CB4] X-Spam-Score: 2.5 (++) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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: , Content-Type: multipart/mixed; boundary="===============0548208211==" Errors-To: tls-bounces@lists.ietf.org --===============0548208211== Content-Type: multipart/alternative; boundary="_bd626c10-c23e-46a0-944e-e1c993a093af_" --_bd626c10-c23e-46a0-944e-e1c993a093af_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benjamin: Lets distinguish our work in IETF, from having fun in R&D, discus= sion opensource forums (e.g. ssl-talk, where the community worked on SSL3, = outside the bounds of formal standardization rules). =20 If I shorten the argument that follows to a few words, alluding to Steve Ke= nt's infamous paper on stack-based networking:- are we putting things at th= e right layer? =20 ------------- =20 Within an IETF WG structure, operating under modern rules: =20 1. I have not called for TLS to be removed from the standards track: only f= or the WG to perhaps "stop"...and let what we have become the standard. 10 = years is quite long enough, given precious little of the core has changed i= n those 10 years, and we have been through 4 versions already. I don't expe= ct to see this recommendation adopted, tho, knowing well those who operate = the IETF Security Area. Arguably, the horizontalization of TLS via the IETF= -era activities into (1) the EAP arena, (2) into non-PKI ciphersuites, (3) = SAML extensions, (4) and even into HTTP1.1 Update , are all worthwhile per = se, and more such value could be expected to be forthcoming from this WG. =20 2. I have also called into question whether several new work items (propose= d in memo form, and more properly in I-D form) are really worthy of extendi= ng the life of the WG, arguing against my own "close now, while we are ahea= d" proposal. These issues are far more debatable, and go to the heart of th= e question: so what is the role of TLS in the Internet Security Architectur= e - noting that the designers intended it merely to be an IPSEC stopgap. It= was not their intent, however, to provide all that IPSEC would provide. Co= ncerning Today, not yesterday, should the communities intent really be to a= ddress DoS, non-repudiation, client id protection? Or, should we be encoura= ging application to use migrate to an enhanced IPSEC world, for these capab= ilities? =20 3. I have certainly called for RFC 2817 to be withdrawn from the standards = track - a personal opinion that 2817's model of HTTP1.1/TLS handling of cli= ent-id protection and TLS-bridging is inappropriate, 5 years after publicat= ion and upon reflection with what is actually going on today. This is mainl= y on the grounds that vendor systems applying https, as we have known it si= nce 1994, have simply NOT followed IESG's 2817-based lead to migrate AWAY F= ROM https, even in the web world. A standard that has little adoption is wo= rthless, and perhaps ought not to continue life in the standards track. It = can go in the FYI pile. At the same time, lets reflect that it was an examp= le of an IETF WG following an earlier IESG-architectural MANDATE/RESOLUTION= - to work to move the Internet away from the TLS setup practices of https,= and its ilk. The world didn't buy this, tho - despite the MANDATE. =20 Now, all of these comments address standards issues, with a technical focus= . We could perpetuate our WG life for ever, designing yet more and more cut= e TLS features. But lets take into account that something far more importan= t occurred in Vista, than making TLS the default https (RFC2818-styled) pro= vider (albeit 2818-compliance is only apparent in InternetExplorer/control = URL handling, apparently): IPv6 is provided, and the full IPSEC architectur= e is now soon likely to become much viable than the IPv4 world restricted i= ts role to be, so far. As a community with the wider IETF interests at hear= t, I assume, we surely don't want to do in TLS WG what we really ought to b= e doing by refining the IPSEC family of protocols? =20 As someone who berated IPSEC technology and adoption rates for years (Yea! = Go SSL! Its simple! And, it works well, today!) I'm leading the debate, in = light of what is happening: perhaps its time to move on from the former pos= itions I took during the stopgap period - where the only goal was GET ADOPT= ION, by any and all means. Perhaps we need to reflect think what the fuller= community's interests needs really are, FOR THE FORMAL ISSUANCE OF INTERNE= T STANDARD STATUS to TLS-related RFCs: given IPv6 (and therefore IPSEC) inf= rastructure maturity levels are improving at a smart click.=20 =20 Perhaps I really ought to express this in the security area forum, not TLS = WG? =20 > Date: Sun, 10 Dec 2006 14:37:52 -0800> From: ben@layer8.net> To: home_pw@= msn.com> CC: tls@lists.ietf.org> Subject: Re: [TLS] RFC 2817 proposed stand= ard status revocation?> > -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1> >= Peter,> > While TLS may be objectionable to you based on engineering elega= nce> grounds, the fact remains that it is widely adopted and Some People> p= refer it _in practice_ to IPSec. One could apply similar logic to> yours to= argue for elimination of TCP in favor of SCTP as the "distinct> layer smus= hing" you lament is in full flower in that somewhat successful> old protoco= l. I'm not holding my breath for that to happen, even if> everyone agreed i= t was a Good Idea, and I look forward to many more> years of getting enormo= us value from TLS.> > > bb> > > Peter Williams wrote:> > > > > > I assume t= his WG is, or would be, responsible for handling RFC2817> > standards track= issues?> > > > http://tools.ietf.org/html/rfc2817.> > > > I record my reco= mmendation that the cited document have its PROPOSED> > STANDARD status rev= oked. Period. Its bad (SSL) theory, and even worse> > practice.> > > > I un= derstand from the text what Rohit was aiming for, and why; but its> > the w= rong tack. The HTTP 1.1 update profile for SSL should not be> > attempting = as an INTERNET STANDARD to be a universal upper-layer stack> > protocol: us= ing A-bridges everywhere, smushing what the distinct layers> > do, adding A= -layer multiplexing for IP-addressed endpoints, and> > mis-purposing SSL's = stack-oriented security model.> > > > Subsequent to that RFC 2817 era, ws-s= ecurity and soap have essentially> > re-invented what ISO's upper-layer-sec= urity and> > ROSE/RTS/Presentation/Session protocols used to attempt to do,= for open> > networks. The modern web services architecture does use the SS= L security> > architecture properly, however - and will thus easily move to= the> > (competing) IPSEC security architecture ...once IPv6 gets ubiquitou= s.> > > > Never ever forget, SSL was intended as an IPSEC stopgap. In IETF,= dont> > force TLS into a long term position in the internet security> > ar= chitecture that it doesn't deserve (e.g. RFC2817). It is SUPPOSED to> > go = away, at some point.> > > > > > -----BEGIN PGP SIGNATURE-----> Version: Gnu= PG v1.4.4 (Darwin)> > iD8DBQFFfIxANGhGGgVakhcRAqqSAKDYrlB65jFAYc/So1xnaxp5D= PPKhgCgrs6h> GNeoyJ+URGYlGTySiAEjY7A=3D> =3DML1R> -----END PGP SIGNATURE---= -- _________________________________________________________________ All-in-one security and maintenance for your PC.=A0 Get a free 90-day trial= ! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=3Dwl_wlmail= --_bd626c10-c23e-46a0-944e-e1c993a093af_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Benjamin:

Lets distinguish our work in IETF, from having fun = in R&D, discussion opensource forums (e.g. ssl-talk, where the communit= y worked on SSL3, outside the bounds of formal standardization rules).
 
If I shorten the argument that follows to a few words, alluding to Steve Ke= nt's infamous paper on stack-based networking:- are we putting things at th= e right layer?
 
-------------
 
Within an IETF WG structure, operating under modern rules:
 
1. I have not called for TLS to be removed from the standards track: only f= or the WG to perhaps "stop"...and let what we have become the standard. 10 = years is quite long enough, given precious little of the core has changed i= n those 10 years, and we have been through 4 versions already. I don't expe= ct to see this recommendation adopted, tho, knowing well those who operate = the IETF Security Area. Arguably, the horizontalization of TLS via the IETF= -era activities into (1) the EAP arena, (2) into non-PKI ciphersuites, (3) = SAML extensions, (4) and even into HTTP1.1 Update , are all worthwhile per = se, and more such value could be expected to be forthcoming from this WG.  
2. I have also called into question whether several new work items (propose= d in memo form, and more properly in I-D form) are really worthy of extendi= ng the life of the WG, arguing against my own "close now, while we are ahea= d" proposal. These issues are far more debatable, and go to the heart of th= e question: so what is the role of TLS in the Internet Security Architectur= e - noting that the designers intended it merely to be an IPSEC stopga= p. It was not their intent, however, to provide all that IPSEC would p= rovide. Concerning Today, not yesterday, should the communities intent= really be to address DoS, non-repudiation, client id protection? Or, shoul= d we be encouraging application to use migrate to an enhanced IPSEC world, = for these capabilities?
 
3. I have certainly called for RFC 2817 to be withdrawn from the standards = track - a personal opinion that 2817's model of HTTP1.1/TLS handling of cli= ent-id protection and TLS-bridging is inappropriate, 5 years after publicat= ion and upon reflection with what is actually going on today. This is mainl= y on the grounds that vendor systems applying https, as we have known it si= nce 1994, have simply NOT followed IESG's 2817-based lead to migrate A= WAY FROM https, even in the web world. A standard that has little adoption = is worthless, and perhaps ought not to continue life in the standards track= . It can go in the FYI pile. At the same time, lets reflect that it was an = example of an IETF WG following an earlier IESG-architectural MANDATE/= RESOLUTION - to work to move the Internet away from the TLS setup practices= of https, and its ilk. The world didn't buy this, tho - despite the MANDAT= E.
 
Now, all of these comments address standards issues, with a technical focus= . We could perpetuate our WG life for ever, designing yet more and more cut= e TLS features. But lets take into account that something far more imp= ortant occurred in Vista, than making TLS the default https (RFC2818-styled= ) provider (albeit 2818-compliance is only apparent in InternetExplorer/con= trol URL handling, apparently): IPv6 is provided, and= the full IPSEC architecture is now soon likely to become much viable than = the IPv4 world restricted its role to be, so far. As a commu= nity with the wider IETF interests at heart, I assume, we surely don't want= to do in TLS WG what we really ought to be doing by refining the IPSE= C family of protocols?
 
As someone who berated IPSEC technology and adoption rates for years (Yea! = Go SSL! Its simple! And, it works well, today!) I'm leading the debate, in = light of what is happening: perhaps its time to move on from the former pos= itions I took during the stopgap period - where the only goal was GET ADOPT= ION, by any and all means. Perhaps we need to reflect think what the fuller= community's interests needs really are, FOR THE FORMAL ISSUANCE OF INTERNE= T STANDARD STATUS to TLS-related RFCs: given IPv6 (and therefore = IPSEC) infrastructure maturity levels are improving at a smart click.
 
Perhaps I really ought to express this in the security area = forum, not TLS WG?
 

> Date: Sun, 10 Dec 2006 14:37:52 -0800
> From: ben@layer8.net
= > To: home_pw@msn.com
> CC: tls@lists.ietf.org
> Subject: Re= : [TLS] RFC 2817 proposed standard status revocation?
>
> ----= -BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter,>
> While TLS may be objectionable to you based on engineering = elegance
> grounds, the fact remains that it is widely adopted and So= me People
> prefer it _in practice_ to IPSec. One could apply similar= logic to
> yours to argue for elimination of TCP in favor of SCTP as= the "distinct
> layer smushing" you lament is in full flower in that= somewhat successful
> old protocol. I'm not holding my breath for th= at to happen, even if
> everyone agreed it was a Good Idea, and I loo= k forward to many more
> years of getting enormous value from TLS.>
>
> bb
>
>
> Peter Williams wrote:<= BR>> >
> >
> > I assume this WG is, or would be, = responsible for handling RFC2817
> > standards track issues?
&g= t; >
> > http://tools.ietf.org/html/rfc2817.
> >
= > > I record my recommendation that the cited document have its PROPO= SED
> > STANDARD status revoked. Period. Its bad (SSL) theory, and= even worse
> > practice.
> >
> > I understand = from the text what Rohit was aiming for, and why; but its
> > the = wrong tack. The HTTP 1.1 update profile for SSL should not be
> > = attempting as an INTERNET STANDARD to be a universal upper-layer stack
&= gt; > protocol: using A-bridges everywhere, smushing what the distinct l= ayers
> > do, adding A-layer multiplexing for IP-addressed endpoin= ts, and
> > mis-purposing SSL's stack-oriented security model.
= > >
> > Subsequent to that RFC 2817 era, ws-security and so= ap have essentially
> > re-invented what ISO's upper-layer-securit= y and
> > ROSE/RTS/Presentation/Session protocols used to attempt = to do, for open
> > networks. The modern web services architecture= does use the SSL security
> > architecture properly, however - an= d will thus easily move to the
> > (competing) IPSEC security arch= itecture ...once IPv6 gets ubiquitous.
> >
> > Never eve= r forget, SSL was intended as an IPSEC stopgap. In IETF, dont
> > = force TLS into a long term position in the internet security
> > a= rchitecture that it doesn't deserve (e.g. RFC2817). It is SUPPOSED to
&g= t; > go away, at some point.
> >
> >
>
>= ; -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.4 (Darwin)
&= gt;
> iD8DBQFFfIxANGhGGgVakhcRAqqSAKDYrlB65jFAYc/So1xnaxp5DPPKhgCgrs= 6h
> GNeoyJ+URGYlGTySiAEjY7A=3D
> =3DML1R
> -----END PGP = SIGNATURE-----


All-in-one security and maintenance for y= our PC.=A0 Get a free 90-day trial! Learn more! = --_bd626c10-c23e-46a0-944e-e1c993a093af_-- --===============0548208211== 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 --===============0548208211==-- From tls-bounces@lists.ietf.org Sun Dec 10 19:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtYjb-0003lm-Oe; Sun, 10 Dec 2006 19:09:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtYjb-0003lh-Ch for tls@lists.ietf.org; Sun, 10 Dec 2006 19:09:31 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtYja-0000sx-1f for tls@lists.ietf.org; Sun, 10 Dec 2006 19:09:31 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id CAA895C01E; Sun, 10 Dec 2006 16:12:36 -0800 (PST) To: Peter Williams Subject: Re: [TLS] RFC 2817 proposed standard status revocation? In-reply-to: Your message of "Sun, 10 Dec 2006 10:35:24 PST." X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 10 Dec 2006 16:09:27 -0800 From: Eric Rescorla Message-Id: <20061211001236.CAA895C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Peter Williams wrote: > I assume this WG is, or would be, responsible for handling RFC2817 > standards track issues?http://tools.ietf.org/html/rfc2817. > > I record my recommendation that the cited document have its PROPOSED > STANDARD status revoked. Period. Its bad (SSL) theory, and even worse > practice. I more or less agree with you that the HTTP Upgrade part of RFC 2817 is a bad idea, but I hardly think it's worth the trouble to have it moved to Historical, esp. since 2817 also standardizes the CONNECT method, which is quite widely used. > Never ever forget, SSL was intended as an IPSEC stopgap. In IETF, dont > force TLS into a long term position in the internet security > architecture that it doesn't deserve (e.g. RFC2817). It is SUPPOSED to > go away, at some point. Regardless of what the intentions of the SSL designers were, it's now quite clear that TLS is generally applicable. I don't agree that if IPsec suddenly became widely available people would suddenly stop being interested in TLS. While it may be true that TLS will go away at some point, that's not something the IETF is planning for. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 10 19:14:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtYny-0005b5-AH; Sun, 10 Dec 2006 19:14:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtYnx-0005az-Fy for tls@lists.ietf.org; Sun, 10 Dec 2006 19:14:01 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtYnw-0001eD-4K for tls@lists.ietf.org; Sun, 10 Dec 2006 19:14:01 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 68AC25C01E; Sun, 10 Dec 2006 16:17:09 -0800 (PST) To: Peter Williams Subject: Re: [TLS] RFC 2817 proposed standard status revocation? In-reply-to: Your message of "Sun, 10 Dec 2006 15:38:41 PST." X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 10 Dec 2006 16:13:59 -0800 From: Eric Rescorla Message-Id: <20061211001709.68AC25C01E@laser.networkresonance.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Benjamin Black , 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 Peter, please do something about putting line feeds into your messages. As-is it's very hard to read them. Peter Williams wrote: > Within an IETF WG structure, operating under modern rules: > > 1. I have not called for TLS to be removed from the standards track: > only for the WG to perhaps "stop"...and let what we have become the > standard. 10 years is quite long enough, given precious little of the > core has changed in those 10 years, and we have been through 4 > versions already. I don't expect to see this recommendation adopted, > tho, knowing well those who operate the IETF Security Area. Arguably, > the horizontalization of TLS via the IETF-era activities into (1) the > EAP arena This was not an activity of the TLS WG. > (2) into non-PKI ciphersuites I think this was worth doing. > (3) SAML extensions This was not an activity of the TLS WG. > (4) and > even into HTTP1.1 Update This work was done quite some time ago. > are all worthwhile per se, and more such > value could be expected to be forthcoming from this WG. I'm general sympathetic to the argument that the TLS WG should be conservative about what work it takes on. Indeed, the motivation for the recent revisions of TLS has been almost exclusively to correct security flaws (real or perceived) in the TLS core. > As someone who berated IPSEC technology and adoption rates for years > (Yea! Go SSL! Its simple! And, it works well, today!) I'm leading the > debate, in light of what is happening: perhaps its time to move on > from the former positions I took during the stopgap period - where the > only goal was GET ADOPTION, by any and all means. Perhaps we need to > reflect think what the fuller community's interests needs really are, > FOR THE FORMAL ISSUANCE OF INTERNET STANDARD STATUS to TLS-related > RFCs: given IPv6 (and therefore IPSEC) infrastructure maturity levels > are improving at a smart click. > > Perhaps I really ought to express this in the security area forum, not > TLS WG? This would be an appropriate issue to raise in a different forum. I would suggest saag@mit.edu or ietf@ietf.org -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 13 09:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVTY-0002Lx-Qc; Wed, 13 Dec 2006 09:52:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVTY-0002Ls-4h for tls@ietf.org; Wed, 13 Dec 2006 09:52:52 -0500 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 1GuVTW-0000k7-LU for tls@ietf.org; Wed, 13 Dec 2006 09:52:52 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBDEq7I3028507; Wed, 13 Dec 2006 16:52:21 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 16:52:44 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 16:52:43 +0200 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] Record layer corner cases Date: Wed, 13 Dec 2006 16:52:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccP7G5vuFMik7AjR3aGa8EoqaL8lwDx1bCgAsQvgNA= From: To: , X-OriginalArrivalTime: 13 Dec 2006 14:52:43.0856 (UTC) FILETIME=[58628D00:01C71EC6] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 wrote: > Bodo Moeller wrote: > > Now that I come to think of it, if we want to change the words of > > the specification for TLS 1.2, we might just as well simply take the > > current description of fragmentation and add "And we mean=20 > > it" ... :-) > >=20 > > Seriously, if we rule out some odd cases of fragmentation, I don't > > think it is unreasonable to require all implementations to=20 > > be able to properly process fragmented handshake messages. >=20 > My worry is that just adding "And we mean it" wouldn't change the > current situation: since receiving-side processing is so poorly > implemented, the sending side can't really rely on it. I did some more thinking about how we could handle this... .One idea I came up with would be to add a "Top Implementation Pitfalls" section (probably as non-normative appendix) that would draw special attention to the most important things that have caused problems for implementers in the past and/or are expected to cause confusion (e.g. because something was changed in TLS 1.2). E.g. something along these lines: o Do you correctly handle handshake messages that are fragmented to multiple TLS records? Also corner cases like a ClientHello that is split to several small fragments? o Do you ignore the TLS record layer version number in all TLS records before ServerHello (see Section X.Y.Z)? o When using Diffie-Hellman key exchange, do you correctly strip leading zero bytes from the negotiated key (see Section 8.1.2)?=20 If you don't, roughly once out of 256 connection attempts will fail. o When encountering an error in RSA-encrypted Premaster Secret, =20 do you continue the handshake to avoid the Bleichenbacher=20 attack (see Section 7.4.7.1)? o What countermeasures do you use against timing attacks against RSA private key operations (decryption and signing)? o When verifying RSA signatures, do you accept both NULL and missing parameters (see Section X.Y.Z)? Do you verify that there is no additional data after the hash value? o Do you use a strong and, most importantly, properly seeded random number generator for generating the premaster secret, Diffie-Hellman private values, the DSA "k" parameter, and other security-critical=20 values? Do you think something like this would be an effective way of=20 saying "And we mean it"? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 13 10:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVb6-00060c-AQ; Wed, 13 Dec 2006 10:00:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuVb5-00060M-5M for tls@ietf.org; Wed, 13 Dec 2006 10:00:39 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuVb1-0007rv-V6 for tls@ietf.org; Wed, 13 Dec 2006 10:00:38 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GuVap3NeV-0003CV; Wed, 13 Dec 2006 16:00:23 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 29F03111E7; Wed, 13 Dec 2006 16:00:22 +0100 (CET) Date: Wed, 13 Dec 2006 16:00:22 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Record layer corner cases Message-ID: <20061213150022.GA17484@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Wed, Dec 13, 2006 at 04:52:46PM +0200, Pasi.Eronen@nokia.com wrote: > I did some more thinking about how we could handle this... .One idea I > came up with would be to add a "Top Implementation Pitfalls" section > (probably as non-normative appendix) that would draw special attention > to the most important things that have caused problems for > implementers in the past and/or are expected to cause confusion > (e.g. because something was changed in TLS 1.2). > > E.g. something along these lines: > > o Do you correctly handle handshake messages that are fragmented > to multiple TLS records? Also corner cases like a ClientHello > that is split to several small fragments? > > o Do you ignore the TLS record layer version number in all TLS > records before ServerHello (see Section X.Y.Z)? [...] > Do you think something like this would be an effective way of > saying "And we mean it"? Yes, this looks very good! Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 13 11:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX2j-0002o5-G7; Wed, 13 Dec 2006 11:33:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuX2i-0002nz-PH for tls@lists.ietf.org; Wed, 13 Dec 2006 11:33:16 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuX2g-0006f5-Sw for tls@lists.ietf.org; Wed, 13 Dec 2006 11:33:16 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBDGXEhF022689 for ; Wed, 13 Dec 2006 11:33:14 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000037630.msg for ; Wed, 13 Dec 2006 11:34:29 -0500 Message-ID: <45802B8B.80503@secure-endpoints.com> Date: Wed, 13 Dec 2006 11:34:19 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Wed, 13 Dec 2006 11:34:29 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@lists.ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============1433101425==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1433101425== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090203040303010804060506" This is a cryptographically signed message in MIME format. --------------ms090203040303010804060506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit During the review of TLS 1.x while writing the Internet Draft describing the proposed TLS_GSS ciphers, Stefan Santesson noticed the following text from RFC4346 Section 7.4.2: "7.4.2. Server Certificate "When this message will be sent: "The server MUST send a certificate whenever the agreed-upon key exchange method is not an anonymous one. This message will always immediately follow the server hello message." This text appears in all versions of TLS. However, RFC2712 states in Section 3: "The server's certificate, the client CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be omitted since authentication and the establishment of a master secret will be done using the client's Kerberos credentials for the TLS server." In my opinion, RFC2712's behavior is correct. The TLS server must not send a certificate to the client when the key exchange is being performed in such as manner as not to rely on the public key pair associated with a certificate. The text in RFC4346 7.4.2 is correct assuming that certificate based public key is the only form of server authentication. As demonstrated by RFC2712, there are other methods of performing server authentication that do not involve certificates. I propose the following change to TLS 1.2 Section 7.4.2: "The server MUST send a certificate whenever the agreed-upon key exchange method is not anonymous and does not provide an alternative method of server authentication. This message will always immediately follow the server hello message." This text permits the behavior described by RFC2712 and the forthcoming TLS_GSS Internet Draft. Jeffrey Altman --------------ms090203040303010804060506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTMxNjM0MTlaMCMGCSqGSIb3DQEJBDEWBBRkByL9 BTJyiVjZboVgZ4G1mWK8cjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAHeVD6ozgvzw16GZQw9OKzsAG8MiWwWZTbTcHwId6T/NzdeA28OhK VzAFVLg7NXth0XgaUUYLyaZr6/XLp5f8u+XkLssKc/NhyvK98ITqI63wryqpJCc+zZwYRnMs 7YJbT6eqSZWocikBGdv/iHVLwoRsHBzxy4TjZGiz+lx/nxF9Wcvk0kwpxhxWrOnIqqKxNXmJ JZkZyEjLf8t9z6SEBb0LZDuaiioOgiD56rLp3m/iVXI1muxc1+iGpqomA59iDdW14jiBfxQ5 XFZYk9BdoqUUHxyGlmGPVAc3Yr4p9ooBAgFhJo+M8B1pACPH1FNHBbSxcPk0Znm8g1LTnebt XAAAAAAAAA== --------------ms090203040303010804060506-- --===============1433101425== 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 --===============1433101425==-- From tls-bounces@lists.ietf.org Wed Dec 13 23:25:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui8H-00039U-HJ; Wed, 13 Dec 2006 23:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gui8G-00039L-7w for tls@ietf.org; Wed, 13 Dec 2006 23:23:44 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gui8F-0006cL-26 for tls@ietf.org; Wed, 13 Dec 2006 23:23:44 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id AA9099D08F for ; Wed, 13 Dec 2006 23:24:00 -0500 (EST) 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 47D179CF9F for ; Wed, 13 Dec 2006 23:24:00 -0500 (EST) Message-ID: <4580D1C8.5040908@pobox.com> Date: Wed, 13 Dec 2006 20:23:36 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > o When using Diffie-Hellman key exchange, do you correctly strip > leading zero bytes from the negotiated key (see Section 8.1.2)? > If you don't, roughly once out of 256 connection attempts will fail. On a related note, my large integer code prepends a leading zero byte if the most significant bit is a one to prevent it from appearing to be negative. So when transferring the Diffie-Hellman p, g, Ys, and Yc, they might have a leading zero byte. I haven't noticed any problems with this, but wondered if this should be clarified to either always do it, never do it, or leave it up to the implementer. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 14 03:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GulWx-0006F6-UN; Thu, 14 Dec 2006 03:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GulWx-0006Dr-9h for tls@ietf.org; Thu, 14 Dec 2006 03:01:27 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GulWv-0001Pr-UF for tls@ietf.org; Thu, 14 Dec 2006 03:01:27 -0500 Received: from [80.142.186.43] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GulWp3MIO-00034p; Thu, 14 Dec 2006 09:01:20 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 8930D124D8; Thu, 14 Dec 2006 09:01:18 +0100 (CET) Date: Thu, 14 Dec 2006 09:01:18 +0100 From: Bodo Moeller To: Mike Subject: Re: [TLS] Record layer corner cases Message-ID: <20061214080118.GA21584@tau.invalid> References: <4580D1C8.5040908@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4580D1C8.5040908@pobox.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Wed, Dec 13, 2006 at 08:23:36PM -0800, Mike wrote: >> o When using Diffie-Hellman key exchange, do you correctly strip >> leading zero bytes from the negotiated key (see Section 8.1.2)? >> If you don't, roughly once out of 256 connection attempts will fail. > On a related note, my large integer code prepends a leading zero byte > if the most significant bit is a one to prevent it from appearing to > be negative. So when transferring the Diffie-Hellman p, g, Ys, and > Yc, they might have a leading zero byte. I haven't noticed any > problems with this, but wondered if this should be clarified to > either always do it, never do it, or leave it up to the implementer. You probably won't encounter problems when including leading zero bytes in encodings of integer values "on the wire", although there isn't really a point in doing so since implementations also have to be able to handle values with the most significant bit set, which are not meant to denote negative values. So the specification shouldn't recommend including leading zero bytes. Some implementations might always be using a 1024-bit integer for dh_Ys when Diffie-Hellman is used with a 1024-bit modulus, say, so there's no reason for the < In-Reply-To: <45802B8B.80503@secure-endpoints.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712) Thread-Index: Acce1NJxmwalex6cTeaT46ll+OfO5QAleRGA From: To: , X-OriginalArrivalTime: 14 Dec 2006 10:35:56.0494 (UTC) FILETIME=[A34B6EE0:01C71F6B] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061214123544-521FFBB0-2A8BE91F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Jeffrey, The text is correct if it's interpreted to apply only to the ciphersuites defined in RFC2246/4346 (all of which are based on certificates, or are anonymous)... but I do agree that it would benefit from clarification. But instead of listing the exceptions when it's not sent, I'd prefer saying when it *is* sent: "The server MUST send a certificate whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the server hello message." Best regards, Pasi=20 > -----Original Message----- > From: ext Jeffrey Altman [mailto:jaltman@secure-endpoints.com]=20 > Sent: 13 December, 2006 18:34 > To: tls@lists.ietf.org > Subject: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5=20 > Cipher Suite(RFC2712) >=20 > During the review of TLS 1.x while writing the Internet Draft > describing the proposed TLS_GSS ciphers, Stefan Santesson noticed > the following text from RFC4346 Section 7.4.2: >=20 > "7.4.2. Server Certificate >=20 > "When this message will be sent: >=20 > "The server MUST send a certificate whenever the agreed-upon key > exchange method is not an anonymous one. This message=20 > will always > immediately follow the server hello message." >=20 > This text appears in all versions of TLS. However, RFC2712 states in > Section 3: >=20 > "The server's certificate, the client CertificateRequest, and the > ServerKeyExchange shown in Figure 1 will be omitted since > authentication and the establishment of a master secret=20 > will be done > using the client's Kerberos credentials for the TLS server." >=20 > In my opinion, RFC2712's behavior is correct. The TLS server must not > send a certificate to the client when the key exchange is being > performed in such as manner as not to rely on the public key pair > associated with a certificate. >=20 > The text in RFC4346 7.4.2 is correct assuming that certificate based > public key is the only form of server authentication. As demonstrated > by RFC2712, there are other methods of performing server=20 > authentication > that do not involve certificates. >=20 > I propose the following change to TLS 1.2 Section 7.4.2: >=20 > "The server MUST send a certificate whenever the agreed-upon key > exchange method is not anonymous and does not provide an=20 > alternative > method of server authentication. This message will always > immediately follow the server hello message." >=20 > This text permits the behavior described by RFC2712 and the=20 > forthcoming > TLS_GSS Internet Draft. >=20 > Jeffrey Altman >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 14 05:38:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gunz0-00027F-Bc; Thu, 14 Dec 2006 05:38:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gunyz-00026J-5Q for tls@lists.ietf.org; Thu, 14 Dec 2006 05:38:33 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gunyx-0000zm-FJ for tls@lists.ietf.org; Thu, 14 Dec 2006 05:38:33 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gunyv0FxP-0006rt; Thu, 14 Dec 2006 11:38:29 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 2C009124D8; Thu, 14 Dec 2006 11:38:27 +0100 (CET) Date: Thu, 14 Dec 2006 11:38:27 +0100 From: Bodo Moeller To: Jeffrey Altman Subject: Re: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712) Message-ID: <20061214103827.GA27545@tau.invalid> References: <45802B8B.80503@secure-endpoints.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45802B8B.80503@secure-endpoints.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Wed, Dec 13, 2006 at 11:34:19AM -0500, Jeffrey Altman wrote: > During the review of TLS 1.x while writing the Internet Draft > describing the proposed TLS_GSS ciphers, Stefan Santesson noticed > the following text from RFC4346 Section 7.4.2: > > "7.4.2. Server Certificate > > "When this message will be sent: > > "The server MUST send a certificate whenever the agreed-upon key > exchange method is not an anonymous one. This message will always > immediately follow the server hello message." > > This text appears in all versions of TLS. However, RFC2712 states in > Section 3: > > "The server's certificate, the client CertificateRequest, and the > ServerKeyExchange shown in Figure 1 will be omitted since > authentication and the establishment of a master secret will be done > using the client's Kerberos credentials for the TLS server." > I propose the following change to TLS 1.2 Section 7.4.2: > > "The server MUST send a certificate whenever the agreed-upon key > exchange method is not anonymous and does not provide an alternative > method of server authentication. This message will always > immediately follow the server hello message." It might be better to be more explicit here. Your proposed text resolves the conflict, but could be puzzling to implementors who haven't seen the Kerberos or TLS_GSS ciphersuite specifications and don't quite know what you're talking about when you mention alternative methods of server authentication. Here is a more elaborate proposal: This message is omitted if the agreed-upon key exchange method is anonymous or uses an alternative method of server authentication. For all non-anoymous key exchange methods specified in this document, the server MUST send this message. For non-anonymous key exchange methods specified elsewhere that do not provide an alternative method of server authentication, the server MUST send this message. This message will always immediately follow the server hello message. This also would clarify that you can't send a certificate message in an anonymous handshake, which apparently isn't strictly forbidden with the current language. (The signature part of the ServerKeyExchange is empty, so there's no point in trying to attach a server certificate to a handshake that is nominally anonymous.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 14 05:52:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoC7-00004s-AV; Thu, 14 Dec 2006 05:52:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoC5-0008WO-Ux for tls@ietf.org; Thu, 14 Dec 2006 05:52:05 -0500 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 1GuoC3-00038d-El for tls@ietf.org; Thu, 14 Dec 2006 05:52:05 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBEAofCV029969; Thu, 14 Dec 2006 12:51:27 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 12:51:37 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 12:51:37 +0200 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] Diffie-Hellman parameters are unsigned (was: Record layer corner cases) Date: Thu, 14 Dec 2006 12:51:37 +0200 Message-ID: In-Reply-To: <4580D1C8.5040908@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Diffie-Hellman parameters are unsigned (was: Record layer corner cases) Thread-Index: AccfOCKELkc00uu/RpOE5nL5Wy3GRAANO50g From: To: , X-OriginalArrivalTime: 14 Dec 2006 10:51:37.0498 (UTC) FILETIME=[D42D3FA0:01C71F6D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061214125129-7420DBB0-75558FE6/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 mike-list@pobox.com wrote: > On a related note, my large integer code prepends a leading zero byte > if the most significant bit is a one to prevent it from appearing to > be negative. So when transferring the Diffie-Hellman p, g, Ys, and > Yc, they might have a leading zero byte. I haven't noticed any > problems with this, but wondered if this should be clarified to > either always do it, never do it, or leave it up to the implementer. Good catch! Perhaps we should add something like this to Section 7.4.3? "The modulus (and other Diffie-Hellman parameters) are sent as unsigned integers (i.e., leading zero octets are not required even if the most significant bit is set)." Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 14 08:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqrR-0002va-23; Thu, 14 Dec 2006 08:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuqrQ-0002vR-5r for tls@lists.ietf.org; Thu, 14 Dec 2006 08:42:56 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuqrO-0004Fu-UO for tls@lists.ietf.org; Thu, 14 Dec 2006 08:42:56 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBEDgrhP023068 for ; Thu, 14 Dec 2006 08:42:54 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000037773.msg for ; Thu, 14 Dec 2006 08:44:09 -0500 Message-ID: <45815525.10806@secure-endpoints.com> Date: Thu, 14 Dec 2006 08:44:05 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite (RFC2712) References: <45802B8B.80503@secure-endpoints.com> <20061214103827.GA27545@tau.invalid> In-Reply-To: <20061214103827.GA27545@tau.invalid> X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Thu, 14 Dec 2006 08:44:09 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@lists.ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============0581901621==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0581901621== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050905050900060806070302" This is a cryptographically signed message in MIME format. --------------ms050905050900060806070302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bodo Moeller wrote: > It might be better to be more explicit here. Your proposed text > resolves the conflict, but could be puzzling to implementors who > haven't seen the Kerberos or TLS_GSS ciphersuite specifications and > don't quite know what you're talking about when you mention > alternative methods of server authentication. Here is a more > elaborate proposal: > > This message is omitted if the agreed-upon key exchange method is > anonymous or uses an alternative method of server authentication. > For all non-anoymous key exchange methods specified in this > document, the server MUST send this message. For non-anonymous > key exchange methods specified elsewhere that do not provide an > alternative method of server authentication, the server MUST send > this message. This message will always immediately follow the > server hello message. > > This also would clarify that you can't send a certificate message in > an anonymous handshake, which apparently isn't strictly forbidden with > the current language. (The signature part of the ServerKeyExchange is > empty, so there's no point in trying to attach a server certificate to > a handshake that is nominally anonymous.) > > Bodo One more revision combining the best of Pasi's and Bodo's text: This message is omitted if the agreed-upon key exchange method is anonymous or uses server authentication method that does not involve certificates. For all key exchange methods specified in this document except for DH_anon, the server MUST send this message. For non-anonymous key exchange methods specified elsewhere that do not provide an alternative method of server authentication, the server MUST send this message. This message will always immediately follow the server hello message. Jeffrey Altman --------------ms050905050900060806070302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTQxMzQ0MDVaMCMGCSqGSIb3DQEJBDEWBBQMKapj KFigU/bHQ5rEEEhMbx0QjTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAiCFMBb4EP/oqUz/eA/bqHhnwlId8JRWKnd9Od75JM2V/a3n5/2az zZOGiYhZokmULFFRCdciatzzu4sXz/1PsrMRKiQJ0iTSdld+wyhJYK1eWQ9sE0zZTVBFPEu8 vJ4zE/J1oZNSyOY+FHzmh4evCiQn8dKa0qWPdmLb4y1MRKI1aElO044IY7xmwSTsZCWTipHG x3Bu2rusDEislG97gUob0TQ6iDcT9DStmlRtFsHDT2UK83/ZyxuSO4dYOKysfyQcUGc8Xo8H WfyNoLeK8mIfIvkQOkxUILng1WW4MDs6RITeFS/N6LpbJRhcKFo6ZdTPLAlm2mb1pGdLMVVK 2AAAAAAAAA== --------------ms050905050900060806070302-- --===============0581901621== 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 --===============0581901621==-- From tls-bounces@lists.ietf.org Thu Dec 14 09:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurmm-0007Hx-R1; Thu, 14 Dec 2006 09:42:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurml-0007Hs-JV for tls@lists.ietf.org; Thu, 14 Dec 2006 09:42:11 -0500 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 1Gurmj-0002iN-4a for tls@lists.ietf.org; Thu, 14 Dec 2006 09:42:11 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBEEfRwb015865; Thu, 14 Dec 2006 16:41:41 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 16:42:03 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 16:42:03 +0200 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] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712) Date: Thu, 14 Dec 2006 16:42:03 +0200 Message-ID: In-Reply-To: <45815525.10806@secure-endpoints.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712) Thread-Index: AccfiX56Jdo0ngkEQTe0QADs24nU6QAAt9Rw From: To: , X-OriginalArrivalTime: 14 Dec 2006 14:42:03.0768 (UTC) FILETIME=[05469F80:01C71F8E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061214164142-3D271BB0-09810DBC/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Jeffrey Altman wrote: > One more revision combining the best of Pasi's and Bodo's text: >=20 > This message is omitted if the agreed-upon key exchange method is > anonymous or uses server authentication method that does not > involve certificates. For all key exchange methods specified in > this document except for DH_anon, the server MUST send this > message. For non-anonymous key exchange methods specified > elsewhere that do not provide an alternative method of server > authentication, the server MUST send this message. This message > will always immediately follow the server hello message. Improving... except I still prefer an ordering where we first say=20 when the message is sent, and the explain the exceptions: This message MUST be sent if the agreed-upon key exchange method involves certificates for server authentication. This includes all key exchange methods defined in this document except DH_anon. For key exchange methods specified elsewhere that are either anonymous or provide an alternative method of server authentication, this message MUST NOT be sent. This message will always immediately follow the server hello message. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 14 09:44:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuroR-0007tV-KJ; Thu, 14 Dec 2006 09:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuroQ-0007tQ-Gq for tls@lists.ietf.org; Thu, 14 Dec 2006 09:43:54 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuroP-0002sh-9n for tls@lists.ietf.org; Thu, 14 Dec 2006 09:43:54 -0500 Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBEEhoCd029053 for ; Thu, 14 Dec 2006 09:43:50 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000037781.msg for ; Thu, 14 Dec 2006 09:45:04 -0500 Message-ID: <45816367.9080100@secure-endpoints.com> Date: Thu, 14 Dec 2006 09:44:55 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712) References: In-Reply-To: X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Thu, 14 Dec 2006 09:45:04 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@lists.ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============1428926262==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1428926262== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010206080603050302070400" This is a cryptographically signed message in MIME format. --------------ms010206080603050302070400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Improving... except I still prefer an ordering where we first say > when the message is sent, and the explain the exceptions: > > This message MUST be sent if the agreed-upon key exchange method > involves certificates for server authentication. This includes all > key exchange methods defined in this document except DH_anon. For > key exchange methods specified elsewhere that are either anonymous > or provide an alternative method of server authentication, this > message MUST NOT be sent. This message will always immediately > follow the server hello message. > > Best regards, > Pasi I am happy with this version. Thanks. Jeffrey Altman --------------ms010206080603050302070400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTQxNDQ0NTVaMCMGCSqGSIb3DQEJBDEWBBTyFT/0 2ATIIdbRcGLNwnX8Bm08TjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAZpT/sZUcDMSnwLtKHRzQdmeSTA3ohAmlOBdwGzWnlELGp+T5uCWM 233PDcqJq3HJ+enn0zYotjLLytQMNjXvuZBL9fUa9OZavlR2oESO1Dms1+luFhmb9zc7KivQ gYrUuHb/T+9q6UaIchlzjiNjT0DlFzxOd8rLLoWfbLM6pH4QOpUC/WP9uUbshbN0T9Gst7Cz Gq2oBozhQjYohJ52JwHw7CdxHsTqO3LyWL++rZKycB+rBNJt97QERZpfxF0H9SoCo7BBTpd7 sSkcZ6my2g3IeOFSpndrxgUbuSRgmrsAFzs3/Ee5tZvvnPsuWpMu8YOjSs3vSewXovdYr/9W AwAAAAAAAA== --------------ms010206080603050302070400-- --===============1428926262== 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 --===============1428926262==-- From tls-bounces@lists.ietf.org Fri Dec 15 04:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9L5-0007UJ-E1; Fri, 15 Dec 2006 04:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv9L3-0007UE-CF for tls@lists.ietf.org; Fri, 15 Dec 2006 04:26:45 -0500 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 1Gv9L1-0002hp-Sx for tls@lists.ietf.org; Fri, 15 Dec 2006 04:26:45 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBF9Q667017681 for ; Fri, 15 Dec 2006 11:26:15 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 11:26:20 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 11:26:19 +0200 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: Fri, 15 Dec 2006 11:26:19 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00 Thread-Index: AccgKxQDcXuDyyfXSnGGRHBQym5z8Q== From: To: X-OriginalArrivalTime: 15 Dec 2006 09:26:19.0720 (UTC) FILETIME=[14280C80:01C7202B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00 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 FYI: New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Opaque PRF Inputs for TLS Author(s) : E. Rescorla, M. Salter Filename : draft-rescorla-tls-opaque-prf-input-00.txt Pages : 8 Date : 2006-12-14 =09 This document describes a mechanism for using opaque PRF inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rescorla-tls-opaque-prf-input- 00.txt [...] A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : SuiteB CipherSuites for TLS Author(s) : M. Salter, E. Rescorla Filename : draft-rescorla-tls-suiteb-00.txt Pages : 11 Date : 2006-12-14 =09 RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm, which makes them unsuitable for some applications. This document describes eight new CipherSuites for TLS/DTLS which specify stronger digest algorithms and therefore are suitable for use in applications which require compliance with the United States Government's guidelines for "NSA Suite B Cryptography" dated July, 2005. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-00.txt [...] _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 15 19:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvNqh-0004SK-C0; Fri, 15 Dec 2006 19:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvNqf-0004SF-Ra for tls@ietf.org; Fri, 15 Dec 2006 19:56:21 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvNqe-0005Y3-Lf for tls@ietf.org; Fri, 15 Dec 2006 19:56:21 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id A8E2229D4E for ; Fri, 15 Dec 2006 19:56:37 -0500 (EST) 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 proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 6A811A145C for ; Fri, 15 Dec 2006 19:56:37 -0500 (EST) Message-ID: <45834428.70801@pobox.com> Date: Fri, 15 Dec 2006 16:56:08 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] Any advice regarding frequency of generating new DH parameters? 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, I'm wondering if there is any generally accepted advice on how long to use the same Diffie-Hellman parameters in a TLS server. Does the answer depend on whether the server generates a new public key from the parameters for each new connection (mine does)? Thanks for any insight, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 16 19:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvkDZ-0000bA-NW; Sat, 16 Dec 2006 19:49:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvkDY-0000b3-EI for tls@lists.ietf.org; Sat, 16 Dec 2006 19:49:28 -0500 Received: from bay0-omc3-s35.bay0.hotmail.com ([65.54.246.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvkDV-00047W-I3 for tls@lists.ietf.org; Sat, 16 Dec 2006 19:49:28 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 16 Dec 2006 16:49:25 -0800 X-Originating-IP: [69.239.153.56] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , Subject: RE: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00 Date: Sat, 16 Dec 2006 16:49:24 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2006 00:49:25.0011 (UTC) FILETIME=[32C68630:01C72175] X-Spam-Score: 2.4 (++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d 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: , Content-Type: multipart/mixed; boundary="===============0523072605==" Errors-To: tls-bounces@lists.ietf.org --===============0523072605== Content-Type: multipart/alternative; boundary="_1480dd52-48e8-4d33-bd18-aef7086ac6e6_" --_1480dd52-48e8-4d33-bd18-aef7086ac6e6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable COncerning Filename : draft-rescorla-tls-opaque-prf-input-00.txt "As note= d in Section 3 it is anticipated that applications may want to have acces= s to the opaque PRF input values and that they may contain data that is m= eaningful at a higher layer. Because the values are covered by the TLS F= inished message, they are integrity-protected by TLS. However, the appli= cation must independently provide any confidentiality necessary for those= values." We are used, post SSL2, to layer 5 entities inspecting SSL3/TLS1.x messages= - particularly for sessionid. We are used to sticky and persistent SSL ses= sions, over one or more reliable byte streams. In the TCP over IPv4 world,= we are well used to load balancers managing/influencing session resumption= , on sticky sessions. We are used to sticky sessions being tied to (p)vlans= , and SSL sessionids being similarly tied to networked-cryptomodule session= s via PKCS#11 session mapping. We are used to ssl offloading, in front of l= oad balancers. We are used to TTLS's additional protections for the SSL ha= ndshake, and its impact on end-end transport in the general internet. =20 However, those deployment options have nothing to do with TLS - the standar= d. They are merely a set of operational deployment practice - focusing on t= he Netscape-https world, the mobile world, and radius logon/authorization t= o ISP access points. My (SSLv2-mode) TLS endpoints however, operate within = an entirely different operational world. =20 Acting wholly within a FIPS 140-2 level 3 crypto boundary, my protocol engi= ne and the application data consumer/producer do their thing - obviously a= ccessing the crypto primitives and SMIB of keys. The design implements the = N-TCB concept of trusted network design, where the "distributed application= " operates across the set of TCB and FIPS 140-2 boundaries, just as the SSL= protocol engine, the (bluetooth wep-secured) stack and cryptomodules class= ically do. Obviously, under the trust criteria, my applications are necessa= rily very small (and happen to be small java applications). The TLS engine = does NOT have session resumption (in SSLv2 mode), enforces Red Book connect= ion-oriented paradigm (necessarily) at the T-layer endpoint, and ciphersuit= e negotiations are controlled by the cipher capabilities of the cryptomodul= e component of the NTCB instance. It is not your classical load balancer! .= .. helping websites do cost-effective hashed password login to hotmail.com! =20 Now, to the point! What the architecture change in the I-D seems to propose is that applicatio= ns in unix host type environments may require API/socket-level access to mo= re than the sessionid. Its unclear whether "applications" are client protoc= ols of, or conventional parties that generate application-data on, the reco= rd layer. Its unclear what would happen in a TTLS case, where the handshake= s are themselves requiring privacy for client-id, session-id control etc, a= nd TTLS is wholly implemented within the FIPS module boundary. =20 But, as I indicated earlier, "application" access to certain VALUES within = the SSL state machine and its data flows is not that unusual. But, control = over and/or access to PRFs data-components are. If we take the example of t= he Microsoft CSP for SSL, such SSL-crypto providers are specific to its sch= annel stack (being well distinguished from CAPI providers for security anal= ysis and export control purposes), and the PRF is assumed to be a security = mechanism that resides within the FIPS 140-1 crypto boundary - much like a = hash or signature primitive is. Unlike normal CAPI/JCA CSPs, the schannel C= SP support the PRFs required for SSL (and ws-secureconversation). How sensi= tive material enters and leaves the crypto module when the module is applyi= ng this PRF primitive, is therefore a function of the FIPS security policy,= the key/data wrapping disclosures , the state of the unit under its truste= d path rules, etc. =20 I find it the I-D a bit confusing as "so much context is missing" for rati= onalizing the scheme (which is itself perfectly well specified ). I do not= e that the spec is targeting an HTTP extension, worries alot about the exte= nsion negotiation rules, and of course entails that the extension's user-da= ta might be passing over OOB channels beyond the control of load balancers = and their traditional engineering work in trying to tie keepalives, ssl ses= sions, and cryptobox sessions together. =20 If I apply it to my own deployment context, I'm not sure how I could pass t= he additional PRF input/output values across the crypto module boundary - w= hen the integration is with a _non client-protocol_ "application", while AL= SO retaining the integrity assurance required by in the spec. =20 Perhaps we also need to look at some FIPS 140-2 security policies, looking = at the WS-encryption/WS-SX/SAML2 profiles, too. The same issues surely must= be being raised there, for the same US govt apps. =20 But, this is all a fascinating evolution of SSL! Peter. > Date: Fri, 15 Dec 2006 11:26:19 +0200> From: Pasi.Eronen@nokia.com> To: t= ls@lists.ietf.org> Subject: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-i= nput-00 and draft-rescorla-tls-suiteb-00> > FYI:> > New Internet-Draft is a= vailable from the on-line Internet-Drafts > directories.> > Title : Opaque = PRF Inputs for TLS> Author(s) : E. Rescorla, M. Salter> Filename : draft-re= scorla-tls-opaque-prf-input-00.txt> Pages : 8> Date : 2006-12-14> > This do= cument describes a mechanism for using opaque PRF inputs with> Transport La= yer Security (TLS) and Datagram TLS (DTLS).> > A URL for this Internet-Draf= t is:> http://www.ietf.org/internet-drafts/draft-rescorla-tls-opaque-prf-in= put-> 00.txt> > [...]> > A New Internet-Draft is available from the on-line= Internet-Drafts > directories.> > Title : SuiteB CipherSuites for TLS> Aut= hor(s) : M. Salter, E. Rescorla> Filename : draft-rescorla-tls-suiteb-00.tx= t> Pages : 11> Date : 2006-12-14> > RFC 4492 describes elliptic curve ciphe= r suites for Transport Layer> Security (TLS). However, all those cipher sui= tes use SHA-1 as their> MAC algorithm, which makes them unsuitable for some= applications.> This document describes eight new CipherSuites for TLS/DTLS= which> specify stronger digest algorithms and therefore are suitable for u= se> in applications which require compliance with the United States> Govern= ment's guidelines for "NSA Suite B Cryptography" dated July,> 2005.> > A UR= L for this Internet-Draft is:> http://www.ietf.org/internet-drafts/draft-re= scorla-tls-suiteb-00.txt> > [...]> > ______________________________________= _________> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mail= man/listinfo/tls _________________________________________________________________ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=3D7adb59de-a857-45ba-81cc-= 685ee3e858fe= --_1480dd52-48e8-4d33-bd18-aef7086ac6e6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable COncerning Filename : draft-rescorla-tls-opaque-prf-input-00.txt
<= BR>   "As noted in Section 3 it is anticipated that applications = may want to
   have access to the opaque PRF input values and = that they may contain
   data that is meaningful at a higher l= ayer.  Because the values are
   covered by the TLS Finis= hed message, they are integrity-protected by
   TLS.  How= ever, the application must independently provide any
   confid= entiality necessary for those values."

We are used, post SSL2, to layer 5 entities inspecting SSL3/TLS1.x messages= - particularly for sessionid. We are used to sticky and persistent SSL ses= sions, over one or more reliable byte streams.  In the TCP over IPv4 w= orld, we are well used to load balancers managing/influencing session resum= ption, on sticky sessions. We are used to sticky sessions being tied to (p)= vlans, and SSL sessionids being similarly tied to networked-cryptomodule se= ssions via PKCS#11 session mapping. We are used to ssl offloading, in front= of load balancers. We are used to TTLS's  additional protections for = the SSL handshake, and its impact on end-end transport in the general inter= net.
 
However, those deployment options have nothing to do with TLS - the standar= d. They are merely a set of operational deployment practice - focusing on t= he Netscape-https world, the mobile world, and radius logon/authorization t= o ISP access points. My (SSLv2-mode) TLS endpoints however, operate within = an entirely different operational world.
 
Acting wholly within a FIPS 140-2 level 3 crypto boundary, my protocol engi= ne and the application data consumer/producer do their thing -  o= bviously accessing the crypto primitives and SMIB of keys. The design = implements the N-TCB concept of trusted network design, where the "distribu= ted application" operates across the set of TCB and FIPS 140-2 boundaries, = just as the SSL protocol engine, the (bluetooth wep-secured) stac= k and cryptomodules classically do. Obviously, under the trust criteria, my= applications are necessarily very small (and happen to be small java appli= cations). The TLS engine does NOT have session resumption (in SSLv2 mode), = enforces Red Book connection-oriented paradigm (necessarily) at the T-layer= endpoint, and ciphersuite negotiations are controlled by the cipher capabi= lities of the cryptomodule component of the NTCB instance. It is not your c= lassical load balancer! ... helping websites do cost-effective hashed passw= ord login to hotmail.com!
 
Now, to the point!

What the architecture change in the I-D seems to propose is that applicatio= ns in unix host type environments may require API/socket-level access to mo= re than the sessionid. Its unclear whether "applications" are client protoc= ols of, or conventional parties that generate application-data on, the reco= rd layer. Its unclear what would happen in a TTLS case, where the handshake= s are themselves requiring privacy for client-id, session-id control etc, a= nd TTLS is wholly implemented within the FIPS module boundary.
 
But, as I indicated earlier, "application" access to certain VALUES within = the SSL state machine and its data flows is not that unusual. But, control = over and/or access to PRFs data-components are. If we take the example of t= he Microsoft CSP for SSL, such SSL-crypto providers are specific to its sch= annel stack (being well distinguished from CAPI providers for security anal= ysis and export control purposes), and the PRF is assumed to be a security = mechanism that resides within the FIPS 140-1 crypto boundary - much like a = hash or signature primitive is. Unlike normal CAPI/JCA CSPs, the schannel C= SP support the PRFs required for SSL (and ws-secureconversation). How sensi= tive material enters and leaves the crypto module when the module is applyi= ng this PRF primitive, is therefore a function of the FIPS security policy,= the key/data wrapping disclosures , the state of the unit under its truste= d path rules, etc.
 
I find it the I-D a bit confusing as "so much context is missing"  for= rationalizing the scheme (which is itself perfectly well specified ).=   I do note that the spec is targeting an HTTP extension, worries= alot about the extension negotiation rules, and of course entails that the= extension's user-data might be passing over OOB channels beyond the contro= l of load balancers and their traditional engineering work in trying to tie= keepalives, ssl sessions, and cryptobox sessions together.
 
If I apply it to my own deployment context, I'm not sure how I could pass t= he additional PRF input/output values across the crypto module boundar= y - when the integration is with a _non client-protocol_ "application", whi= le ALSO retaining the integrity assurance required by in the spec.
 
Perhaps we also need to look at some FIPS 140-2 security policies, looking = at the WS-encryption/WS-SX/SAML2 profiles, too. The same issues surely must= be being raised there, for the same US govt apps.
 
But, this is all a fascinating evolution of SSL!

Peter.



> Date: Fri, 15 Dec 2006 11:26:19 +0200
> From: Pasi.Eronen@nokia.= com
> To: tls@lists.ietf.org
> Subject: [TLS] New I-Ds: draft-r= escorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00
> > FYI:
>
> New Internet-Draft is available from the on-li= ne Internet-Drafts
> directories.
>
> Title : Opaque PR= F Inputs for TLS
> Author(s) : E. Rescorla, M. Salter
> Filenam= e : draft-rescorla-tls-opaque-prf-input-00.txt
> Pages : 8
> Da= te : 2006-12-14
>
> This document describes a mechanism for us= ing opaque PRF inputs with
> Transport Layer Security (TLS) and Datag= ram TLS (DTLS).
>
> A URL for this Internet-Draft is:
> = http://www.ietf.org/internet-drafts/draft-rescorla-tls-opaque-prf-input-> 00.txt
>
> [...]
>
> A New Internet-Draft i= s available from the on-line Internet-Drafts
> directories.
> =
> Title : SuiteB CipherSuites for TLS
> Author(s) : M. Salter,= E. Rescorla
> Filename : draft-rescorla-tls-suiteb-00.txt
> Pa= ges : 11
> Date : 2006-12-14
>
> RFC 4492 describes elli= ptic curve cipher suites for Transport Layer
> Security (TLS). Howeve= r, all those cipher suites use SHA-1 as their
> MAC algorithm, which = makes them unsuitable for some applications.
> This document describe= s eight new CipherSuites for TLS/DTLS which
> specify stronger digest= algorithms and therefore are suitable for use
> in applications whic= h require compliance with the United States
> Government's guidelines= for "NSA Suite B Cryptography" dated July,
> 2005.
>
> = A URL for this Internet-Draft is:
> http://www.ietf.org/internet-draf= ts/draft-rescorla-tls-suiteb-00.txt
>
> [...]
>
>= _______________________________________________
> TLS mailing list> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tl= s


Use Messenger to talk to your IM friends, even those o= n Yahoo! Talk now! = --_1480dd52-48e8-4d33-bd18-aef7086ac6e6_-- --===============0523072605== 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 --===============0523072605==-- From tls-bounces@lists.ietf.org Sat Dec 16 23:05:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvnGA-0003kK-Jk; Sat, 16 Dec 2006 23:04:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvnG9-0003kF-Qq for tls@ietf.org; Sat, 16 Dec 2006 23:04:21 -0500 Received: from bay0-omc1-s10.bay0.hotmail.com ([65.54.246.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvnG5-0001pw-E2 for tls@ietf.org; Sat, 16 Dec 2006 23:04:21 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc1-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 16 Dec 2006 20:04:17 -0800 X-Originating-IP: [69.239.153.56] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mike , Subject: RE: [TLS] Record layer corner cases Date: Sat, 16 Dec 2006 20:04:16 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2006 04:04:17.0034 (UTC) FILETIME=[6BC3A6A0:01C72190] X-Spam-Score: 2.6 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: , Content-Type: multipart/mixed; boundary="===============1292547305==" Errors-To: tls-bounces@lists.ietf.org --===============1292547305== Content-Type: multipart/alternative; boundary="_84b3ff2c-4deb-4aba-93ce-574fe4831162_" --_84b3ff2c-4deb-4aba-93ce-574fe4831162_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable in BER/DER encoding, the leading byte is required; the minimal # of 0s is r= equired, for DER conformance. 0x001 is non conforming, therefore. =20 We discovered this an eon ago, along with NULL parms are serialized *explic= itely* in DER-encoded ALGORITHM values A tight, miliitary DER-decoder should reject non-conforming DER. General cr= ap will probably be more liberal, on accepting stuff. =20 =20 > Date: Wed, 13 Dec 2006 20:23:36 -0800> From: mike-list@pobox.com> To: tls= @ietf.org> Subject: Re: [TLS] Record layer corner cases> CC: > > > o When u= sing Diffie-Hellman key exchange, do you correctly strip> > leading zero by= tes from the negotiated key (see Section 8.1.2)? > > If you don't, roughly = once out of 256 connection attempts will fail.> > On a related note, my lar= ge integer code prepends a leading zero byte> if the most significant bit i= s a one to prevent it from appearing to> be negative. So when transferring = the Diffie-Hellman p, g, Ys, and> Yc, they might have a leading zero byte. = I haven't noticed any> problems with this, but wondered if this should be c= larified to> either always do it, never do it, or leave it up to the implem= enter.> > Mike> > _______________________________________________> TLS mail= ing list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ All-in-one security and maintenance for your PC.=A0 Get a free 90-day trial= ! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=3Dwl_wlmail= --_84b3ff2c-4deb-4aba-93ce-574fe4831162_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

in BER/DER encoding, the leading byte is required; the minima= l # of 0s is required, for DER conformance. 0x001 is non conforming, theref= ore.
 
We discovered this an eon ago, along with NULL parms are serialized *explic= itely* in DER-encoded ALGORITHM values

A tight, miliitary DER-decoder should reject non-conforming DER. Genera= l crap will probably be more liberal, on accepting stuff.
 
 

> Date: Wed, 13 Dec 2006 20:23:36 -0800
> From: mike-list@pobox.co= m
> To: tls@ietf.org
> Subject: Re: [TLS] Record layer corner c= ases
> CC:
>
> > o When using Diffie-Hellman key exc= hange, do you correctly strip
> > leading zero bytes from the nego= tiated key (see Section 8.1.2)?
> > If you don't, roughly once ou= t of 256 connection attempts will fail.
>
> On a related note,= my large integer code prepends a leading zero byte
> if the most sig= nificant bit is a one to prevent it from appearing to
> be negative. = So when transferring the Diffie-Hellman p, g, Ys, and
> Yc, they migh= t have a leading zero byte. I haven't noticed any
> problems with thi= s, but wondered if this should be clarified to
> either always do it,= never do it, or leave it up to the implementer.
>
> Mike
&= gt;
> _______________________________________________
> TLS ma= iling list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman= /listinfo/tls


All-in-one security and maintenance for yo= ur PC.=A0 Get a free 90-day trial! Learn more! = --_84b3ff2c-4deb-4aba-93ce-574fe4831162_-- --===============1292547305== 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 --===============1292547305==-- From tls-bounces@lists.ietf.org Sun Dec 17 13:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0Rz-0000Ep-Ti; Sun, 17 Dec 2006 13:09:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0Ry-0000Ee-Ja for tls@ietf.org; Sun, 17 Dec 2006 13:09:26 -0500 Received: from moutng.kundenserver.de ([212.227.126.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw0Rx-0000vm-7Y for tls@ietf.org; Sun, 17 Dec 2006 13:09:26 -0500 Received: from [80.142.159.13] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Gw0Rq2TVN-000700; Sun, 17 Dec 2006 19:09:19 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 3EF2311C85; Sun, 17 Dec 2006 19:09:13 +0100 (CET) Date: Sun, 17 Dec 2006 19:09:13 +0100 From: Bodo Moeller To: Peter Williams Subject: Re: [TLS] Record layer corner cases Message-ID: <20061217180913.GA30384@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 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 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 Sat, Dec 16, 2006 at 08:04:16PM -0800, Peter Williams wrote: >>> o When using Diffie-Hellman key exchange, do you correctly strip >>> leading zero bytes from the negotiated key (see Section 8.1.2)? >>> If you don't, roughly once out of 256 connection attempts will fail. >> On a related note, my large integer code prepends a leading zero byte >> if the most significant bit is a one to prevent it from appearing to >> be negative. So when transferring the Diffie-Hellman p, g, Ys, and >> Yc, they might have a leading zero byte. I haven't noticed any >> problems with this, but wondered if this should be clarified to >> either always do it, never do it, or leave it up to the implementer. > in BER/DER encoding, the leading byte is required; the minimal # of > 0s is required, for DER conformance. [...] This isn't about BER/DER at all, though. This is about integers transmitted as "opaque"-type values in the TLS presentation language. The specification so far only clearly describes fixed-length numeric types (uint8, uint16, uint24, uint32, uint64), but in practice similar rules are used for large numbers in those "opaque" fields (there is no provision for signed values). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 17 13:34:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0pv-00012r-Qr; Sun, 17 Dec 2006 13:34:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0pu-00012j-9s for tls@ietf.org; Sun, 17 Dec 2006 13:34:10 -0500 Received: from bay0-omc3-s19.bay0.hotmail.com ([65.54.246.219]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw0ps-0003jD-Tl for tls@ietf.org; Sun, 17 Dec 2006 13:34:10 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc3-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 17 Dec 2006 10:34:08 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Bodo Moeller , Subject: RE: [TLS] Record layer corner cases Date: Sun, 17 Dec 2006 10:34:08 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 17 Dec 2006 18:34:08.0408 (UTC) FILETIME=[F03F5180:01C72209] X-Spam-Score: 2.4 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1502676318==" Errors-To: tls-bounces@lists.ietf.org --===============1502676318== Content-Type: multipart/alternative; boundary="_8e0d4b90-64de-4b6c-ac02-3de9c0d3a269_" --_8e0d4b90-64de-4b6c-ac02-3de9c0d3a269_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm getting confused. =20 its one thing to worry about whether a record-layer record straddles one or= more packets - given the legitimate issues that timing factors always have= on all Security Protocol designs. =20 Its another to say a given handshake message can *always* straddle multiple= records. This depends on the protocol version, as a part of TLS fallback r= ules. =20 ----------------- =20 The latter was specifically made NON CONFORMING (in SSL2 ). "For a two byt= e header, the maximum record length is 32767 bytes. For the three byte head= er, the maximum record length is 16383 bytes. The SSL Handshake Protocol me= ssages are constrained to fit in a single SSL Record Protocol record. Appli= cation protocol messages are allowed to consume multiple SSL Record Protoco= l record's." =20 In SSL3, of course, the priority of transferring a given record type is a f= unction of the upper-layer protocols. There is no equivalent rule in SSL3 t= o SSL2. One may decide to interrupt flow of a 32k cert chain on the client = auth portion of a second handshake say (initiated by whoever holds the clie= nt role - due to a 30s timeout of its session policy - because of the need = to prioritize transfer of some APDU (e.g. SSL protected APDU over some TLS = extension, over OOB media). Obviously, One continues the back half of the c= ertchain conveyance after the APDU has been signalled, and the client proto= col machine can expect the server to properly handle such fragmentation of = a handshake message. =20 > > o Do you correctly handle handshake messages that are fragmented> > to = multiple TLS records? Also corner cases like a ClientHello> > that is split= to several small fragments? > Yes, this looks very good!> > Bodo _________________________________________________________________ All-in-one security and maintenance for your PC.=A0 Get a free 90-day trial= ! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=3Dwl_wlmail= --_8e0d4b90-64de-4b6c-ac02-3de9c0d3a269_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm getting confused.
 
its one thing to worry about whether a record-layer record straddles one or= more packets - given the legitimate issues that timing factors always have= on all Security Protocol designs.
 
Its another to say a given handshake message can *always* straddle multiple= records. This depends on the protocol version, as a part of TLS fallback r= ules.
 
-----------------
 
The latter was specifically made NON CONFORMING (in SSL2 ).  "For a tw= o byte header, the maximum record length is 32767 bytes. For the three byte= header, the maximum record length is 16383 bytes. The SSL Handshake Protoc= ol messages are constrained to fit in a single SSL Record Protocol record. = Application protocol messages are allowed to consume multiple SSL Record Pr= otocol record's."
 
In SSL3, of course, the priority of transferring a given record type is a f= unction of the upper-layer protocols. There is no equivalent rule in SSL3 t= o SSL2. One may decide to interrupt flow of a 32k cert chain on the client = auth portion of a second handshake say (initiated by whoever holds the= client role - due to a 30s timeout of its session policy - because of the = need to prioritize transfer of some APDU (e.g. SSL protected APDU over some= TLS extension, over OOB media). Obviously, One continues the back half of = the certchain conveyance after the APDU has been signalled, and the client = protocol machine can expect the server to properly handle such fragmentatio= n of a handshake message.
 

> > o Do you correctly handle handshake messages that are fragmen= ted
> > to multiple TLS records? Also corner cases like a ClientHe= llo
> > that is split to several small fragments?

> Yes, this looks very good!
>
> Bodo


Al= l-in-one security and maintenance for your PC.=A0 Get a free 90-day trial! = Learn more! = --_8e0d4b90-64de-4b6c-ac02-3de9c0d3a269_-- --===============1502676318== 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 --===============1502676318==-- From tls-bounces@lists.ietf.org Mon Dec 18 04:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFBp-0004UG-7K; Mon, 18 Dec 2006 04:53:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwFBn-0004UB-Ha for tls@ietf.org; Mon, 18 Dec 2006 04:53:43 -0500 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 1GwFBm-0001G1-2Q for tls@ietf.org; Mon, 18 Dec 2006 04:53:43 -0500 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 kBI9qgf9015882; Mon, 18 Dec 2006 11:53:07 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 11:53:32 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 11:53:32 +0200 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] Any advice regarding frequency of generating new DHparameters? Date: Mon, 18 Dec 2006 11:53:33 +0200 Message-ID: In-Reply-To: <45834428.70801@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Any advice regarding frequency of generating new DHparameters? Thread-Index: AccgrV0uexP/HY5NRiysugPKj2syYwB25ggQ From: To: , X-OriginalArrivalTime: 18 Dec 2006 09:53:32.0187 (UTC) FILETIME=[606BFEB0:01C7228A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061218115307-3DB30BB0-103A73A8/0-0/0-0 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 Hi Mike, Protocols such as IKEv2 use the same modulus (p) and generator (g) forever (but of course generate new public/private values), since=20 they don't actually send the p/g values, but just the group number. IMHO it probably would make sense for a TLS implementation to use=20 one of the groups specified in RFC 4306 or 3526, instead of e.g.=20 generating a random prime p (generating random primes is kind of=20 slow, and then you have to worry about RFC 2785 etc.).=20 (Would others agree with this recommendation? Should we add it=20 to the TLS 1.2 spec?) Best regards, Pasi=20 > -----Original Message----- > From: ext Mike [mailto:mike-list@pobox.com]=20 > Sent: 16 December, 2006 02:56 > To: tls@ietf.org > Subject: [TLS] Any advice regarding frequency of generating=20 > new DHparameters? >=20 > Hi, >=20 > I'm wondering if there is any generally accepted advice > on how long to use the same Diffie-Hellman parameters in > a TLS server. Does the answer depend on whether the > server generates a new public key from the parameters > for each new connection (mine does)? >=20 > Thanks for any insight, >=20 > Mike >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 09:07:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJ8O-0003Mi-5t; Mon, 18 Dec 2006 09:06:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJ8M-0003M9-LC for tls@ietf.org; Mon, 18 Dec 2006 09:06:26 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJ8L-0002LI-9L for tls@ietf.org; Mon, 18 Dec 2006 09:06:26 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 18 Dec 2006 06:06:22 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 18 Dec 2006 06:06:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,183,1165219200"; d="scan'208"; a="159651011:sNHT23744119" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 06:06:21 -0800 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] Any advice regarding frequency of generating newDHparameters? Date: Mon, 18 Dec 2006 09:06:17 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E70405601175039@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Any advice regarding frequency of generating newDHparameters? thread-index: AccgrV0uexP/HY5NRiysugPKj2syYwB25ggQAAkfs0A= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 18 Dec 2006 14:06:21.0927 (UTC) FILETIME=[B24A9F70:01C722AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 > Protocols such as IKEv2 use the same modulus (p) and generator (g) > forever (but of course generate new public/private values), since=20 > they don't actually send the p/g values, but just the group number. Yes. Note that they offer more than one group. > IMHO it probably would make sense for a TLS implementation to use=20 > one of the groups specified in RFC 4306 or 3526, instead of e.g.=20 > generating a random prime p (generating random primes is kind of=20 > slow, and then you have to worry about RFC 2785 etc.).=20 Just one group? Or allow choosing the group like in IKE? > (Would others agree with this recommendation? Should we add it=20 > to the TLS 1.2 spec?) Makes perfect sense to me! > -----Original Message----- > From: ext Mike [mailto:mike-list@pobox.com]=20 > Sent: 16 December, 2006 02:56 > To: tls@ietf.org > Subject: [TLS] Any advice regarding frequency of generating=20 > new DHparameters? >=20 > Hi, >=20 > I'm wondering if there is any generally accepted advice > on how long to use the same Diffie-Hellman parameters in > a TLS server. Does the answer depend on whether the > server generates a new public key from the parameters > for each new connection (mine does)? >=20 > Thanks for any insight, >=20 > Mike >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 09:26:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJRF-0000tE-SM; Mon, 18 Dec 2006 09:25:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJRE-0000t8-SJ for tls@ietf.org; Mon, 18 Dec 2006 09:25:56 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJRC-00069s-LP for tls@ietf.org; Mon, 18 Dec 2006 09:25:56 -0500 Received: by nz-out-0506.google.com with SMTP id z6so632476nzd for ; Mon, 18 Dec 2006 06:25:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Hn2ZisoqIv22nDu34mR44fXV6erEgYneuQPkVdRlbDRbZ1VpK8JpTLTuFu0vkxbSsPjyAFV9MACMsjHB/jXjK1/yc9q7lkagjk+c0+Nv8qsSQn2AcZXuuOtV/P7wu4tLCdSpTJJwHIUgwmMEYLFKtz+huz8nMJRHKmWw68CAtjk= Received: by 10.78.201.15 with SMTP id y15mr3169181huf.1166451953178; Mon, 18 Dec 2006 06:25:53 -0800 (PST) Received: by 10.78.182.7 with HTTP; Mon, 18 Dec 2006 06:25:52 -0800 (PST) Message-ID: <7d7b76890612180625m4a3b5071we41f1eabdaba5d3f@mail.gmail.com> Date: Mon, 18 Dec 2006 15:25:52 +0100 From: "Georges Le grand" To: tls@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [TLS] Implementations for RFC4279, RFC4492, RFC4366 and RFC4347 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="===============1249955443==" Errors-To: tls-bounces@lists.ietf.org --===============1249955443== Content-Type: multipart/alternative; boundary="----=_Part_14300_7306547.1166451952871" ------=_Part_14300_7306547.1166451952871 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline RFC2026 says: ... a candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard. I'd like to be informed if the above text has been applied to RFC4279, RFC4492, RFC4366 and RFC4347. Is there at least, for each RFC, two interoperable implementations have been developed Sincerely, Georges ------=_Part_14300_7306547.1166451952871 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
RFC2026 says:
 
... a candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard.
 
I'd like to be informed if the above text has been applied to RFC4279, RFC4492, RFC4366 and RFC4347. Is there at least, for each RFC, two interoperable implementations have been developed
 
Sincerely,
Georges
------=_Part_14300_7306547.1166451952871-- --===============1249955443== 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 --===============1249955443==-- From tls-bounces@lists.ietf.org Mon Dec 18 09:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJoI-0000Fy-Oa; Mon, 18 Dec 2006 09:49:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJoH-0000ET-B4 for tls@ietf.org; Mon, 18 Dec 2006 09:49:45 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJoC-0001xq-MW for tls@ietf.org; Mon, 18 Dec 2006 09:49:45 -0500 Received: by machshav.com (Postfix, from userid 512) id 1C0B7FB4E0; Mon, 18 Dec 2006 14:49:38 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 274E5FB4DB; Mon, 18 Dec 2006 14:49:37 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 30C9D76667B; Mon, 18 Dec 2006 09:49:34 -0500 (EST) Date: Mon, 18 Dec 2006 09:49:34 -0500 From: "Steven M. Bellovin" To: "Georges Le grand" Subject: Re: [TLS] Implementations for RFC4279, RFC4492, RFC4366 and RFC4347 In-Reply-To: <7d7b76890612180625m4a3b5071we41f1eabdaba5d3f@mail.gmail.com> References: <7d7b76890612180625m4a3b5071we41f1eabdaba5d3f@mail.gmail.com> Organization: Columbia University X-Mailer: Claws Mail 2.6.1 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061218144934.30C9D76667B@berkshire.machshav.com> X-Spam-Score: 0.0 (/) 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 On Mon, 18 Dec 2006 15:25:52 +0100 "Georges Le grand" wrote: > RFC2026 says: > > ... a candidate specification must be implemented and tested for > correct operation and interoperability by multiple independent > parties and utilized in increasingly demanding environments, before > it can be adopted as an Internet Standard. > > I'd like to be informed if the above text has been applied to RFC4279, > RFC4492, RFC4366 and RFC4347. Is there at least, for each RFC, > two interoperable implementations have been developed > That appplies to Draft and Full standards, per Sections 4.1.2 and 4.1.3 of RFC 2026. TLS is, as I recall, only at Proposed Standard (4.1.1). --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 Mon Dec 18 10:30:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKR8-0006ZW-1E; Mon, 18 Dec 2006 10:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKR6-0006ZL-KH for tls@lists.ietf.org; Mon, 18 Dec 2006 10:29:53 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwKR5-0000ss-90 for tls@lists.ietf.org; Mon, 18 Dec 2006 10:29:52 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA29514; Mon, 18 Dec 2006 16:29:39 +0100 (MEZ) From: Martin Rex Message-Id: <200612181522.QAA23528@uw1048.wdf.sap.corp> Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and To: home_pw@msn.com (Peter Williams) Date: Mon, 18 Dec 2006 16:22:09 +0100 (MET) In-Reply-To: from "Peter Williams" at Dec 16, 6 04:49:24 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: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.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 Williams wrote: > > We are used, post SSL2, to layer 5 entities inspecting SSL3/TLS1.x > messages - particularly for sessionid. I don't understand the purpose of looking at the SSL session ID on (transparent) middle boxes, other than for statistics. An application or a Browser-based application frontend may be using several independent SSL sessions within a single application session, and since there is both a lifetime limit on SSL sessions and a resource limit on the server-side SSL session cache, it is undefined at which point during an application session SSL sessions expire. When the backend application is stateless, it is not necessary to look at the SSL session ID for load balancing. When there is backend state involved, looking at the SSL session ID will result in a flakey load balancing architecture. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 10:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKjT-00054F-My; Mon, 18 Dec 2006 10:48:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwKjS-000542-ED for tls@lists.ietf.org; Mon, 18 Dec 2006 10:48:50 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwKjR-0003pu-3u for tls@lists.ietf.org; Mon, 18 Dec 2006 10:48:50 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id DD2A75C01E; Mon, 18 Dec 2006 07:51:57 -0800 (PST) To: Peter Williams Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00 In-reply-to: Your message of "Sat, 16 Dec 2006 16:49:24 PST." X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 18 Dec 2006 07:48:46 -0800 From: Eric Rescorla Message-Id: <20061218155157.DD2A75C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@lists.ietf.org, pasi.eronen@nokia.com 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 Peter, *please* figure out some way to put line breaks in your messages. It makes them very hard to read. Peter Williams wrote: > What the architecture change in the I-D seems to propose is that > applications in unix host type environments may require > API/socket-level access to more than the sessionid. That's always been true. Recall that TLS doesn't specify how one checks certificates. That's done at higher layers (E.g., RFC 2818). So, the next layer protocol generally needs a fair amount of access to properties of the TLS session. It's also generally common to provide access to the cipher suite. > I do note that the spec is targeting an HTTP extension, worries alot > about the extension negotiation rules, and of course entails that the > extension's user-data might be passing over OOB channels beyond the > control of load balancers and their traditional engineering work in > trying to tie keepalives, ssl sessions, and cryptobox sessions > together. Why do you say "HTTP extension"? This is a pure TLS extension. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 12:07:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLwh-0003Mu-Gs; Mon, 18 Dec 2006 12:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLwe-0003MW-Dv for tls@ietf.org; Mon, 18 Dec 2006 12:06:32 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwLwc-0002yz-4l for tls@ietf.org; Mon, 18 Dec 2006 12:06:32 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id AC1029E6A6 for ; Mon, 18 Dec 2006 12:06:49 -0500 (EST) 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 63A8D9E67B for ; Mon, 18 Dec 2006 12:06:49 -0500 (EST) Message-ID: <4586CACF.6020907@pobox.com> Date: Mon, 18 Dec 2006 09:07:27 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Any advice regarding frequency of generating new DHparameters? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Thanks for the reply and pointers to the RFC's. In RFC 3526 they estimate the strength of their DH groups, and the strength of the 1536-bit modulus is estimated to be between 90 and 120 bits. Since 1024 bits is common in TLS, the strength would be somewhat lower than that. The RSA key exchange method uses 368 bits of random data which seems much stronger. Should we recommend using larger moduli in the Diffie-Hellman key exchange methods? And should we encourage checking the size of the ServerDHParams.p when acting as a client to make sure it is not too small? Also, how safe is it to use the DH key exchange method, since the public key(s) are fixed in the certificate(s)? Mike Pasi.Eronen@nokia.com wrote: > Hi Mike, > > Protocols such as IKEv2 use the same modulus (p) and generator (g) > forever (but of course generate new public/private values), since > they don't actually send the p/g values, but just the group number. > > IMHO it probably would make sense for a TLS implementation to use > one of the groups specified in RFC 4306 or 3526, instead of e.g. > generating a random prime p (generating random primes is kind of > slow, and then you have to worry about RFC 2785 etc.). > > (Would others agree with this recommendation? Should we add it > to the TLS 1.2 spec?) > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Mike [mailto:mike-list@pobox.com] >> Sent: 16 December, 2006 02:56 >> To: tls@ietf.org >> Subject: [TLS] Any advice regarding frequency of generating >> new DHparameters? >> >> Hi, >> >> I'm wondering if there is any generally accepted advice >> on how long to use the same Diffie-Hellman parameters in >> a TLS server. Does the answer depend on whether the >> server generates a new public key from the parameters >> for each new connection (mine does)? >> >> Thanks for any insight, >> >> Mike >> >> _______________________________________________ >> TLS mailing list >> TLS@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 12:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMOg-0008R8-Rz; Mon, 18 Dec 2006 12:35:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMOf-0008Qb-Fu for tls@ietf.org; Mon, 18 Dec 2006 12:35:29 -0500 Received: from edge.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMOb-0007YQ-4q for tls@ietf.org; Mon, 18 Dec 2006 12:35:29 -0500 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0JAH004S4CUR3300@dps.sfvic.sunlabs.com> for tls@ietf.org; Mon, 18 Dec 2006 09:35:15 -0800 (PST) Received: from [152.70.69.81] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0JAH009PMCUQT3O2@mail.sunlabs.com> for tls@ietf.org; Mon, 18 Dec 2006 09:35:15 -0800 (PST) Date: Mon, 18 Dec 2006 09:35:12 -0800 From: Vipul Gupta Subject: Re: [TLS] Implementations for RFC4279, RFC4492, RFC4366 and RFC4347 In-reply-to: <20061218144934.30C9D76667B@berkshire.machshav.com> To: tls mailing list Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <7d7b76890612180625m4a3b5071we41f1eabdaba5d3f@mail.gmail.com> <20061218144934.30C9D76667B@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Nevertheless, for RFC 4492 there are at least three independent interoperable implementations -- from Certicom, Microsoft and OpenSSL/ NSS*. I'm grouping OpenSSL and NSS together since they were developed by the same group of people at Sun Labs even though the code is quite different. For more information, check out http:// dev.experimentalstuff.com:8082/. If you have an implementation, I encourage you to test it out against the publicly available clients/ servers listed there. vipul *NSS is what's used by Mozilla/Firefox and several products from Sun, Red Hat and AOL that have their roots in Netscape products. On Dec 18, 2006, at 6:49 AM, Steven M. Bellovin wrote: > On Mon, 18 Dec 2006 15:25:52 +0100 > "Georges Le grand" wrote: > >> RFC2026 says: >> >> ... a candidate specification must be implemented and tested for >> correct operation and interoperability by multiple independent >> parties and utilized in increasingly demanding environments, before >> it can be adopted as an Internet Standard. >> >> I'd like to be informed if the above text has been applied to >> RFC4279, >> RFC4492, RFC4366 and RFC4347. Is there at least, for each RFC, >> two interoperable implementations have been developed >> > That appplies to Draft and Full standards, per Sections 4.1.2 and > 4.1.3 > of RFC 2026. TLS is, as I recall, only at Proposed Standard (4.1.1). > > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 15:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRq-0002V0-9v; Mon, 18 Dec 2006 15:50:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0001xu-Ks; Mon, 18 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0000Uj-9S; Mon, 18 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id EE3D9175DD; Mon, 18 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GwPQv-00071q-GL; Mon, 18 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-13.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-13.txt Pages : 26 Date : 2006-12-18 This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-srp-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-srp-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-18142142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-18142142.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon Dec 18 17:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwRDA-0000jP-Uy; Mon, 18 Dec 2006 17:43:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwRD8-0000fL-US for tls@lists.ietf.org; Mon, 18 Dec 2006 17:43:54 -0500 Received: from bay0-omc1-s7.bay0.hotmail.com ([65.54.246.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwRD5-0001JU-Pt for tls@lists.ietf.org; Mon, 18 Dec 2006 17:43:54 -0500 Received: from BAY103-W5 ([65.54.174.105]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 18 Dec 2006 14:43:51 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Eric Rescorla Subject: RE: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00 Date: Mon, 18 Dec 2006 14:43:51 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 18 Dec 2006 22:43:51.0187 (UTC) FILETIME=[FD17B630:01C722F5] X-Spam-Score: 2.4 (++) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 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: , Content-Type: multipart/mixed; boundary="===============1256054988==" Errors-To: tls-bounces@lists.ietf.org --===============1256054988== Content-Type: multipart/alternative; boundary="_45c0a179-8edf-4e76-b3f8-c6cb15a3bb15_" --_45c0a179-8edf-4e76-b3f8-c6cb15a3bb15_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1. First: a minor rewrite. I have no idea why I typed HTTP, incorrectly. I = certainly=20 thought "TLS." "I find it the I-D a bit confusing as "so much context is missing" for rat= ionalizing the=20 scheme (which is itself perfectly well specified ). I do note that the spe= c is targeting=20 an TLS extension, worries alot about the extension negotiation rules, and o= f course=20 entails that the extension's user-data might be passing over OOB channels b= eyond=20 the control of load balancers and their traditional engineering work in try= ing to tie=20 keepalives, ssl sessions, and cryptobox sessions together." There are now two issues in the controversy: (a) should apps have this kind= of control=20 (b) is there a public rationale for opening up application control of a PRF= crypto-primitive=20 (and thus the master keying) 2a. Its true that SSLv2 assumed/assumes applications will do cert stuff, &= assumes the server chooses whether to do the (optional) server authentication. In _= modern_ SSLv2, one can apply elements of its design intent in ways one cannot do with SSL3/TLS= 1. Recall: one=20 need not assume X.509 , and neither does one need furthermore to assume the world of assured PKIs, in SSLv2. =20 So, for example, we can use modern XML DerivedSessionTokens from modern WS-= SX specs in SSLv2=20 certificate messages, if we want. We define our own "cert type", and let SS= Lv2 record layer master key generation be a function of an WS-SX exchange in a "parallel SSL= v2 session". =20 For example, In the wifi world of PEAP-TLS, the vlan in the client stack c= reated by the first=20 ssl session on a first binding to an access point's "provisioning" ssid can= now provision/constrain and=20 key for the vlan#2 to now address the second binding to the second ssid -- = the subscriber having now=20 "paid for" the service at the hotspot, which is now suitably provisioned. =20 Thus, a DerivedSessionKeysToken exchange from the first binding can become = the key management=20 and control regime for the second, enforced by the vlan implementation in t= he client wireless=20 stack that delegates *complete* control of this new nic to the ISP.=20 =20 This is the KIND of application control that was intended, in SSLv2! =20 2b. SSLv3 design was of course radically different to SSLv2, addressing pro= xing and multi-tier=20 load balancing in ways that SSLv2 did not (and could not, by design). The = SSLv3 engineering and=20 architecture addressed high-volume SSL in the data center architectures of = the 1995 period, when=20 crypto-accelerators and trusted CSP's were not common!=20 =20 In SSLv3, we went beyond SSLv2's ideas of app control, via socket parms, li= mited up to then to the issues of deciding a. auth policy, b. cert trust, and=20 c. key management/distribution's cert formats. The design allowed **various= ** SSLv3=20 participants to now control session resumption, standardizing on the contro= l principles of hierarchical=20 PKI futhermore. Arguably, the latter was the wrong decision. However, all t= his=20 got SSL into mainstream __data center__ engineering. Today, its easy to buy= offloaders, load=20 balancers for SSL...that properly linkup with firewalls and vlan configs, f= or predicable performance and virtual SSL hosting. =20 3. In the I-D, we seem to going **yet further**, with TLS 1.2-era proposal.= Now, the application can=20 influence elements within the trusted CSP and how the crypto primitives in = the firmware of the=20 FIPS device boundary will react, to certain data signals. THis is a bit lik= e putting S/MIME's security=20 labels into the Cryptobox, and letting those signals control the PRF crypto= primitive. =20 Without disclosure of a _non_ govt application of this practice, its REALLY= hard for IETF to endorse the=20 direction. =20 We HAVE to find a (fully disclosed) motivation for this in IETF, that is no= t military/govt. Otherwise,=20 NSA really needs to just get NIST to issue a FIPS, like they did for the es= crowed algorithms in the Clinton era. Then public FIPS commenting processes can be used to quali= fy the specified=20 practice, for any non govt. uses.=20 =20 So. in conclusion: Im not opposed, except on the grounds of "less than adeq= uate disclosure".=20 =20 Peter. =20 =20 > To: home_pw@msn.com> CC: pasi.eronen@nokia.com; tls@lists.ietf.org> Subje= ct: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-re= scorla-tls-suiteb-00 > Date: Mon, 18 Dec 2006 07:48:46 -0800> From: ekr@net= workresonance.com> > Peter,> > *please* figure out some way to put line bre= aks in your messages.> It makes them very hard to read.> > Peter Williams <= home_pw@msn.com> wrote:> > What the architecture change in the I-D seems to= propose is that> > applications in unix host type environments may require= > > API/socket-level access to more than the sessionid.> > That's always be= en true. Recall that TLS doesn't specify how> one checks certificates. That= 's done at higher layers (E.g.,> RFC 2818). So, the next layer protocol gen= erally needs a > fair amount of access to properties of the TLS session. > = It's also generally common to provide access to the cipher> suite.> > > > I= do note that the spec is targeting an HTTP extension, worries alot> > abou= t the extension negotiation rules, and of course entails that the> > extens= ion's user-data might be passing over OOB channels beyond the> > control of= load balancers and their traditional engineering work in> > trying to tie = keepalives, ssl sessions, and cryptobox sessions> > together.> > Why do you= say "HTTP extension"? This is a pure TLS extension.> > -Ekr _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_45c0a179-8edf-4e76-b3f8-c6cb15a3bb15_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
1. First: a minor rewrite. I have no idea why I typed HTTP, incor= rectly. I certainly
thought "TLS."

"I find it the I-D a bit confusing as "so much context is missing" &nbs= p;for rationalizing the
scheme (which is itself perfectly well specified ).  I do note th= at the spec is targeting
an TLS extension, worries alot about the extension negotiation rules, and o= f course
entails that the extension's user-data might be passing over OOB channels b= eyond
the control of load balancers and their traditional engineering work in try= ing to tie
keepalives, ssl sessions, and cryptobox sessions together."

There are now two issues in the controversy: (a) should apps have this= kind of control
(b) is there a public rationale for opening up application control of&= nbsp;a PRF crypto-primitive
(and thus the master keying)
 
2a. Its true that SSLv2 assumed/assumes applications will do cert= stuff, & assumes
the server chooses whether to do the (optional) server authentication. In _= modern_ SSLv2, one
can apply elements of its design intent in ways one cannot do with SSL= 3/TLS1. Recall: one
need not  assume X.509 , and neither does one need furthermore to assu= me
the world of assured PKIs, in SSLv2.
 
So, for example, we can use modern XML DerivedSessionTokens from = modern WS-SX specs in SSLv2
certificate messages, if we want. We define our own "cert type", and let SS= Lv2 record layer
master key generation be a function of an WS-SX exchange in a "parallel SSL= v2 session".
 
For example,  In the wifi world of PEAP-TLS, the vlan in the client st= ack created by the first
ssl session on a first binding to an access point's "provisioning" ssid can= now provision/constrain and
key for the vlan#2 to now address the second binding to the second ssid -- = the subscriber having now
"paid for" the service at the hotspot, which is now suitably provisioned.  
Thus, a DerivedSessionKeysToken exchange from the first binding can become = the key management
and control regime for the second, enforced by the vlan implementation in t= he client wireless
stack that delegates *complete* control of this new nic to the ISP.
 
This is the KIND of application control that was intended, in SSLv2!
 
2b. SSLv3 design was of course radically different to SSLv2, addressing pro= xing and multi-tier
load balancing  in ways that SSLv2 did not (and could not, b= y design). The SSLv3 engineering and
architecture addressed high-volume SSL in the data center architectures of = the 1995 period, when
crypto-accelerators and trusted CSP's were not common!
 
In SSLv3, we went beyond SSLv2's ideas of app control, via socket parm= s, limited up to then to
the issues of deciding a. auth policy, b. cert trust, and
c. key management/distribution's cert formats. The design allowed **various= ** SSLv3
participants to now control session resumption, standardizing on the contro= l principles of hierarchical
PKI futhermore. Arguably, the latter was the wrong decision. However, all t= his
got SSL into mainstream __data center__ engineering. Today, its easy to buy= offloaders, load
balancers for SSL...that properly linkup with firewalls and vlan configs, f= or predicable performance
and virtual SSL hosting.
 
3. In the I-D, we seem to going **yet further**, with TLS 1.2-era proposal.= Now, the application can
influence elements within the trusted CSP and how the crypto primitives in = the firmware of the
FIPS device boundary will react, to certain data signals. THis is a bit lik= e putting S/MIME's security
labels into the Cryptobox, and letting those signals control the PRF crypto= primitive.
 
Without disclosure of a _non_ govt application of this practice, its REALLY= hard for IETF to endorse the
direction.
 
We HAVE to find a (fully disclosed) motivation for this in IETF, that is no= t military/govt. Otherwise,
NSA really needs to just get NIST to issue a FIPS, like they did for the es= crowed algorithms in
the Clinton era. Then public FIPS commenting processes can be used to quali= fy the specified
practice, for any non govt. uses.
 
So. in conclusion: Im not opposed, except on the grounds of "less than adeq= uate disclosure".
 
Peter.
 
 

> To: home_pw@msn.com
> CC: pasi.eronen@nokia.com; tls@lists.ietf.= org
> Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-inpu= t-00 and draft-rescorla-tls-suiteb-00
> Date: Mon, 18 Dec 2006 07:48= :46 -0800
> From: ekr@networkresonance.com
>
> Peter,>
> *please* figure out some way to put line breaks in your mess= ages.
> It makes them very hard to read.
>
> Peter Willi= ams <home_pw@msn.com> wrote:
> > What the architecture chang= e in the I-D seems to propose is that
> > applications in unix hos= t type environments may require
> > API/socket-level access to mor= e than the sessionid.
>
> That's always been true. Recall that= TLS doesn't specify how
> one checks certificates. That's done at hi= gher layers (E.g.,
> RFC 2818). So, the next layer protocol generally= needs a
> fair amount of access to properties of the TLS session. <= BR>> It's also generally common to provide access to the cipher
> = suite.
>
>
> > I do note that the spec is targeting = an HTTP extension, worries alot
> > about the extension negotiatio= n rules, and of course entails that the
> > extension's user-data = might be passing over OOB channels beyond the
> > control of load = balancers and their traditional engineering work in
> > trying to = tie keepalives, ssl sessions, and cryptobox sessions
> > together.=
>
> Why do you say "HTTP extension"? This is a pure TLS exten= sion.
>
> -Ekr


Check the weather nationwide= with MSN Search Try it now! = --_45c0a179-8edf-4e76-b3f8-c6cb15a3bb15_-- --===============1256054988== 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 --===============1256054988==-- From tls-bounces@lists.ietf.org Mon Dec 18 18:40:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwS5o-0001QL-GF; Mon, 18 Dec 2006 18:40:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwS5n-0001QG-Tj for tls@ietf.org; Mon, 18 Dec 2006 18:40:23 -0500 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwS5m-0004rU-Bg for tls@ietf.org; Mon, 18 Dec 2006 18:40:23 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 18 Dec 2006 15:40:21 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: "Blumenthal, Uri" , Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters? Date: Mon, 18 Dec 2006 15:40:21 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 18 Dec 2006 23:40:21.0796 (UTC) FILETIME=[E20D9640:01C722FD] X-Spam-Score: 2.6 (++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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: , Content-Type: multipart/mixed; boundary="===============1976928688==" Errors-To: tls-bounces@lists.ietf.org --===============1976928688== Content-Type: multipart/alternative; boundary="_e64bd73f-f36a-4846-bfd7-8b34bac16ac1_" --_e64bd73f-f36a-4846-bfd7-8b34bac16ac1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable lets put this in standards group issue/resolution format. =20 Q1: Is anyone proposing that the ephemeral DH process be removed from = the TLS 1.2 I-D? =20 Q2: Is anyone proposing that the classical DH process in TLS 1.2 I-D b= e augmented to signal=20 DH-parameters (i) whose values are standardized, and (b) are not signal= ed via certs? ------- =20 N.B. =20 The whole point of ephemeral DH is realtime generation of the public/privat= e key, with=20 realtime RSA signing of the public key. The result acts like a cert, dynami= cally issued by=20 the SSL endpoint, under the control authority of the CA issuing the RSA sig= ning cert. This=20 dynamic "cert" is never subject to PKI controls like EKU, OCSP, etc - not b= eing created by an issuing authority. How it is used in subsequent SSL sessions... is up= to=20 your imagination. =20 There was a little RSA cryptopolitics going on, if anyone is interested. Ne= tscape didn't have the library or adminwebsitecapability to have a distinct signing (vs. key trans= fer) RSA key, for all its various production servers (doing nntps, ftps, https). It thus forced o= ne RSA key to have=20 the possibility of performing its full, dual reversible functions, somethin= g the cryptopolitics of the=20 day was attempting to subvert. =20 > Subject: RE: [TLS] Any advice regarding frequency of generating newDHpara= meters?> Date: Mon, 18 Dec 2006 09:06:17 -0500> From: uri.blumenthal@intel.= com> To: tls@ietf.org> CC: > > > Protocols such as IKEv2 use the same modul= us (p) and generator (g)> > forever (but of course generate new public/priv= ate values), since > > they don't actually send the p/g values, but just th= e group number.> > Yes. Note that they offer more than one group.> > > IMHO= it probably would make sense for a TLS implementation to use > > one of th= e groups specified in RFC 4306 or 3526, instead of e.g. > > generating a ra= ndom prime p (generating random primes is kind of > > slow, and then you ha= ve to worry about RFC 2785 etc.). > > Just one group? Or allow choosing the= group like in IKE?> > > (Would others agree with this recommendation? Shou= ld we add it > > to the TLS 1.2 spec?)> > Makes perfect sense to me!> > > >= -----Original Message-----> > From: ext Mike [mailto:mike-list@pobox.com] = > > Sent: 16 December, 2006 02:56> > To: tls@ietf.org> > Subject: [TLS] Any= advice regarding frequency of generating > > new DHparameters?> > > > Hi,>= > > > I'm wondering if there is any generally accepted advice> > on how lo= ng to use the same Diffie-Hellman parameters in> > a TLS server. Does the a= nswer depend on whether the> > server generates a new public key from the p= arameters> > for each new connection (mine does)?> > > > Thanks for any ins= ight,> > > > Mike> > > > _______________________________________________> >= TLS mailing list> > TLS@lists.ietf.org> > https://www1.ietf.org/mailman/li= stinfo/tls> > > > _______________________________________________> TLS mail= ing list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls> >= _______________________________________________> TLS mailing list> TLS@lis= ts.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_e64bd73f-f36a-4846-bfd7-8b34bac16ac1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable lets put this in standards group issue/resolution format.
 
     Q1: Is anyone proposing that the ephemeral DH proc= ess be removed from the TLS 1.2 I-D?
 
     Q2: Is anyone proposing that the classical DH proc= ess in TLS 1.2 I-D be augmented to signal
    DH-parameters (i) whose values are standardized, and (b)= are not signaled via certs?


-------
 
N.B.
 
The whole point of ephemeral DH is realtime generation of the public/privat= e key, with
realtime RSA signing of the public key. The result acts like a cert, dynami= cally issued by
the SSL endpoint, under the control authority of the CA issuing the RSA sig= ning cert. This
dynamic "cert" is never subject to PKI controls like EKU, OCSP, etc - not b= eing created
by an issuing authority. How it is used in subsequent SSL sessions... is up= to
your imagination.
 
There was a little RSA cryptopolitics going on, if anyone is interested. Ne= tscape didn't have the
library or adminwebsitecapability to have a distinct signing (vs. key = transfer) RSA key, for all
its various production servers (doing nntps, ftps, https). It thus for= ced one RSA key to have
the possibility of performing its full, dual reversible functions, somethin= g the cryptopolitics of the
day was attempting to subvert.
 

> Subject: RE: [TLS] Any advice regarding frequency of generating newDHp= arameters?
> Date: Mon, 18 Dec 2006 09:06:17 -0500
> From: uri.= blumenthal@intel.com
> To: tls@ietf.org
> CC:
>
>= > Protocols such as IKEv2 use the same modulus (p) and generator (g)> > forever (but of course generate new public/private values), sinc= e
> > they don't actually send the p/g values, but just the group= number.
>
> Yes. Note that they offer more than one group.>
> > IMHO it probably would make sense for a TLS implementat= ion to use
> > one of the groups specified in RFC 4306 or 3526, i= nstead of e.g.
> > generating a random prime p (generating random= primes is kind of
> > slow, and then you have to worry about RFC= 2785 etc.).
>
> Just one group? Or allow choosing the group = like in IKE?
>
> > (Would others agree with this recommenda= tion? Should we add it
> > to the TLS 1.2 spec?)
>
>= Makes perfect sense to me!
>
>
> > -----Original Me= ssage-----
> > From: ext Mike [mailto:mike-list@pobox.com]
>= ; > Sent: 16 December, 2006 02:56
> > To: tls@ietf.org
> = > Subject: [TLS] Any advice regarding frequency of generating
> &= gt; new DHparameters?
> >
> > Hi,
> >
> = > I'm wondering if there is any generally accepted advice
> > o= n how long to use the same Diffie-Hellman parameters in
> > a TLS = server. Does the answer depend on whether the
> > server generates= a new public key from the parameters
> > for each new connection = (mine does)?
> >
> > Thanks for any insight,
> >= ;
> > Mike
> >
> > ___________________________= ____________________
> > TLS mailing list
> > TLS@lists.i= etf.org
> > https://www1.ietf.org/mailman/listinfo/tls
> >= ;
>
> _______________________________________________
>= TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/= mailman/listinfo/tls
>
> _____________________________________= __________
> TLS mailing list
> TLS@lists.ietf.org
> http= s://www1.ietf.org/mailman/listinfo/tls


Check the weather= nationwide with MSN Search Try it now! = --_e64bd73f-f36a-4846-bfd7-8b34bac16ac1_-- --===============1976928688== 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 --===============1976928688==-- From tls-bounces@lists.ietf.org Mon Dec 18 18:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSJN-0007ph-7P; Mon, 18 Dec 2006 18:54:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSJL-0007pX-UN for tls@ietf.org; Mon, 18 Dec 2006 18:54:24 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwSJK-00008x-OS for tls@ietf.org; Mon, 18 Dec 2006 18:54:23 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id F201E9E7C1 for ; Mon, 18 Dec 2006 18:54:42 -0500 (EST) 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 92D909E765 for ; Mon, 18 Dec 2006 18:54:42 -0500 (EST) Message-ID: <45872A66.7070904@pobox.com> Date: Mon, 18 Dec 2006 15:55:18 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Any advice regarding frequency of generating newDHparameters? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > Q1: Is anyone proposing that the ephemeral DH process be removed > from the TLS 1.2 I-D? No, I merely asked how often I should generate new parameters. If anything I think there should be discussion in the security issues section suggesting a minimum size for p. EDH is superior to RSA in that CA key compromise does not lead to compromise of any prior or even future TLS session. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 19:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwT4Q-0003XJ-CT; Mon, 18 Dec 2006 19:43:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwT4P-0003W2-01 for tls@ietf.org; Mon, 18 Dec 2006 19:43:01 -0500 Received: from bay0-omc1-s16.bay0.hotmail.com ([65.54.246.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwT4M-0001X9-E0 for tls@ietf.org; Mon, 18 Dec 2006 19:43:00 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc1-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 18 Dec 2006 16:42:57 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mike , Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters? Date: Mon, 18 Dec 2006 16:42:57 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2006 00:42:57.0975 (UTC) FILETIME=[A0E90470:01C72306] X-Spam-Score: 2.4 (++) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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: , Content-Type: multipart/mixed; boundary="===============0313997324==" Errors-To: tls-bounces@lists.ietf.org --===============0313997324== Content-Type: multipart/alternative; boundary="_8619af77-5527-449d-b574-b3baf7672e46_" --_8619af77-5527-449d-b574-b3baf7672e46_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The answer formally is: its up to the CA issuing the DSA/RSA cert (with a s= igning EKU). This CA authorized the endpoint to mint this message. You wont see this in any = spec, to=20 my knowledge. But its consistent with the intent.=20 =20 If you have a liberal CA or NO CA, then your endpoint make its own groups/k= eys on=20 the fly according to its own rules. the Endpoint policy gets to choose all = matters of key. It would also specify the precise format and encoding rules for the op= aques, then. =20 -------------- =20 Minting ephemeral key management messages would normally be controlled by=20 the PKI. In the SSL3 era, for PKI ciphersuites, a PKI is in charge of the a= ssurance=20 level attained by the channel. The CA particularly controls all matters of = key, key=20 size and algorithm selection, opaque definitions - all of which obviously t= hen controls=20 the security levels of each of the the 4 channels independently as a funct= ion then=20 of the PRF and the session key derivation functions(s). =20 So. in SSL3, you would really only generate ephemeral key according to endp= oint control=20 only when (a) there is no PKI controlling a PKI ciphersuite (b) when a PKI= -controlled server has selected that server authentication should not be performed (ass= uming the PKI authorizes this selection option) =20 In the latter case, how the client verifies the signed key is NOT specified= within SSL. One unstated implication is that its handled by the server hello sessionid resu= mption process, where the client repurposes its knowledge of an earlier server authentication in = the cascade of resumption handshakes. Other options exist to consulting the cascade, ho= wever. Remember, SSL3 allows for interleaving application, std handshake, and custom client = protocol record types, if session state is active. =20 Its a designers toolkit. Use it, fully! =20 > Date: Mon, 18 Dec 2006 15:55:18 -0800> From: mike-list@pobox.com> To: tls= @ietf.org> Subject: Re: [TLS] Any advice regarding frequency of generating = newDHparameters?> CC: > > > Q1: Is anyone proposing that the ephemeral DH p= rocess be removed > > from the TLS 1.2 I-D?> > No, I merely asked how often= I should generate new parameters. If> anything I think there should be dis= cussion in the security issues> section suggesting a minimum size for p. ED= H is superior to RSA> in that CA key compromise does not lead to compromise= of any prior> or even future TLS session.> > Mike> > _____________________= __________________________> TLS mailing list> TLS@lists.ietf.org> https://w= ww1.ietf.org/mailman/listinfo/tls _________________________________________________________________ All-in-one security and maintenance for your PC.=A0 Get a free 90-day trial= ! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=3Dwl_wlmail= --_8619af77-5527-449d-b574-b3baf7672e46_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The answer formally is: its up to the CA issuing the DSA/RSA = cert (with a signing EKU). This
CA  authorized the endpoint to mint this message. You wont see th= is in any spec, to
my knowledge. But its consistent with the intent.
 
If you have a liberal CA or NO CA, then your endpoint make its own groups/k= eys on
the fly according to its own rules. the Endpoint policy gets to choose all = matters of
key. It would also specify the precise format and encoding rules for the op= aques, then.
 
--------------
 
Minting ephemeral key management messages would normally be controlled by <= BR> the PKI. In the SSL3 era, for PKI ciphersuites, a PKI is in charge of = the assurance
level attained by the channel. The CA particularly controls all matter= s of key, key 
size and algorithm selection, opaque definitions - all of which obviou= sly then controls
the security levels of  each of the the 4 channels independently as a = function then
of the PRF and the session key derivation functions(s).
 
So. in SSL3, you would really only generate ephemeral key according to endp= oint control
only when (a) there is no PKI  controlling a PKI ciphersuite (b) when = a PKI-controlled
server has selected that server authentication should not be performed (ass= uming
the PKI authorizes this selection option)
 
In the latter case, how the client verifies the signed key is NOT specified= within SSL. One
unstated implication is that its handled by the server hello sessionid resu= mption process, where
the client repurposes its knowledge of an earlier server authentication in = the cascade
of resumption handshakes. Other options exist to consulting the cascade, ho= wever. Remember,
SSL3 allows for interleaving application, std handshake, and custom client = protocol record
types, if session state is active.
 
Its a designers toolkit. Use it, fully!
 

> Date: Mon, 18 Dec 2006 15:55:18 -0800
> From: mike-list@pobox.co= m
> To: tls@ietf.org
> Subject: Re: [TLS] Any advice regarding = frequency of generating newDHparameters?
> CC:
>
> >= Q1: Is anyone proposing that the ephemeral DH process be removed
> = > from the TLS 1.2 I-D?
>
> No, I merely asked how often I = should generate new parameters. If
> anything I think there should be= discussion in the security issues
> section suggesting a minimum siz= e for p. EDH is superior to RSA
> in that CA key compromise does not = lead to compromise of any prior
> or even future TLS session.
>=
> Mike
>
> ___________________________________________= ____
> TLS mailing list
> TLS@lists.ietf.org
> https://ww= w1.ietf.org/mailman/listinfo/tls


All-in-one security and= maintenance for your PC.=A0 Get a free 90-day trial! Learn more! = --_8619af77-5527-449d-b574-b3baf7672e46_-- --===============0313997324== 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 --===============0313997324==-- From tls-bounces@lists.ietf.org Mon Dec 18 20:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTKb-0002A2-Tz; Mon, 18 Dec 2006 19:59:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTKa-00029P-93 for tls@ietf.org; Mon, 18 Dec 2006 19:59:44 -0500 Received: from bay0-omc1-s35.bay0.hotmail.com ([65.54.246.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwTKY-0005ML-TX for tls@ietf.org; Mon, 18 Dec 2006 19:59:44 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 18 Dec 2006 16:59:42 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mike , Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters? Date: Mon, 18 Dec 2006 16:59:42 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2006 00:59:42.0543 (UTC) FILETIME=[F7ADEDF0:01C72308] X-Spam-Score: 2.6 (++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Content-Type: multipart/mixed; boundary="===============1766392478==" Errors-To: tls-bounces@lists.ietf.org --===============1766392478== Content-Type: multipart/alternative; boundary="_ecd8d008-4a57-4d04-8e0c-691931913034_" --_ecd8d008-4a57-4d04-8e0c-691931913034_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 EDH is superior to RSA> in that CA key compromise does not lead to comprom= ise of any prior> or even future TLS session. I think this is a dig at RSA's dual reversible function, when a CA cert has= both EKUs? =20 IETF's RFC 1422 and RFC 1424 specified CAs with certs that allows RSA to be= =20 used for key transfer (when sending a CA certain mgt messages) along with i= ssuing=20 Certs/CRLs and signed policy messages. =20 Anyways, during SSL3, RFC 1422 was still the authorized standard track spec= ; pending PKIX=20 WG coming up with something to replace it, with a more solid consensus. As = Russ may attest privately, a certain unmentioned company basically sabotaged RFC= 1422 over the whole dual function. The RSA patent in the US, the IETF standards track and= Apple's practice=20 basically saved RSA's dual reversible function from going under, given trem= endous pressure=20 (both nice and then much, much nastier in the 1996/7 period).=20 =20 Use it or not, at your discretion. Thank others for your having the option= , today. =20 Dont assume all RSA knowhow is in the public domain. It took a while for RS= A-OAEP to=20 get disclosed by IBM, for example. =20 _________________________________________________________________ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=3D7adb59de-a857-45ba-81cc-= 685ee3e858fe= --_ecd8d008-4a57-4d04-8e0c-691931913034_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


 
 EDH is superior to RSA
> in that CA key compromise does not lea= d to compromise of any prior
> or even future TLS session.

I think this is a dig at RSA's dual reversible function, when a CA cert has= both EKUs?
 
IETF's RFC 1422 and RFC 1424 specified CAs with certs that allows RSA to be=
used for key transfer (when sending a CA certain mgt messages) along with i= ssuing
Certs/CRLs and signed policy messages.
 
Anyways, during SSL3, RFC 1422 was still the authorized standard track spec= ; pending PKIX
WG coming up with something to replace it, with a more solid consensus. As = Russ
may attest privately, a certain unmentioned company basically sabotaged RFC= 1422 over the
whole dual function. The RSA patent in the US, the IETF standards track and= Apple's practice
basically saved RSA's dual reversible function from going under, given trem= endous pressure
(both nice and then much, much nastier in the 1996/7 period).
 
Use it or not, at your discretion.  Thank others for your having the o= ption, today.
 
Dont assume all RSA knowhow is in the public domain. It took a while for RS= A-OAEP to
get disclosed by IBM, for example.
 

Use Messenger to talk to your IM friends, even those = on Yahoo! Talk now! = --_ecd8d008-4a57-4d04-8e0c-691931913034_-- --===============1766392478== 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 --===============1766392478==-- From tls-bounces@lists.ietf.org Mon Dec 18 20:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTuk-00030T-T9; Mon, 18 Dec 2006 20:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTuj-0002zQ-KP for tls@ietf.org; Mon, 18 Dec 2006 20:37:05 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwTui-0004TB-Eo for tls@ietf.org; Mon, 18 Dec 2006 20:37:05 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 8C61C9E9B9 for ; Mon, 18 Dec 2006 20:37:25 -0500 (EST) 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 57E409E9B8 for ; Mon, 18 Dec 2006 20:37:25 -0500 (EST) Message-ID: <45874279.1040409@pobox.com> Date: Mon, 18 Dec 2006 17:38:01 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Any advice regarding frequency of generating newDHparameters? References: <45872A66.7070904@pobox.com> In-Reply-To: <45872A66.7070904@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > EDH is superior to RSA > in that CA key compromise does not lead to compromise of any prior > or even future TLS session. Instead of "CA key", I meant to say "server private key". Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 20:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTy2-0007GM-2X; Mon, 18 Dec 2006 20:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwTy1-0007Fz-DK for tls@ietf.org; Mon, 18 Dec 2006 20:40:29 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwTxl-0005I0-HL for tls@ietf.org; Mon, 18 Dec 2006 20:40:29 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 58B219E9C1 for ; Mon, 18 Dec 2006 20:40:35 -0500 (EST) 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 1FB089E9C0 for ; Mon, 18 Dec 2006 20:40:34 -0500 (EST) Message-ID: <45874336.9050608@pobox.com> Date: Mon, 18 Dec 2006 17:41:10 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Any advice regarding frequency of generating newDHparameters? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > EDH is superior to RSA > > in that CA key compromise does not lead to compromise of any prior > > or even future TLS session. > > I think this is a dig at RSA's dual reversible function, when a CA cert > has both EKUs? I'm not dissing RSA, but it is true that if an RSA key is compromised, the RSA key exchange mechanism allows you to recover the premaster secret, and thus the entire TLS session of any previous connection. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 18 21:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwUOz-00066J-QB; Mon, 18 Dec 2006 21:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwUOy-00064o-Lh for tls@ietf.org; Mon, 18 Dec 2006 21:08:20 -0500 Received: from bay0-omc2-s7.bay0.hotmail.com ([65.54.246.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwUOx-0004Lm-BM for tls@ietf.org; Mon, 18 Dec 2006 21:08:20 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc2-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 18 Dec 2006 18:08:18 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters? Date: Mon, 18 Dec 2006 18:08:18 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2006 02:08:18.0802 (UTC) FILETIME=[8D293520:01C72312] X-Spam-Score: 2.2 (++) 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: , Content-Type: multipart/mixed; boundary="===============1710838969==" Errors-To: tls-bounces@lists.ietf.org --===============1710838969== Content-Type: multipart/alternative; boundary="_3d463105-0fc9-48a6-96ab-e6d5f89d34b4_" --_3d463105-0fc9-48a6-96ab-e6d5f89d34b4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I took the discussion private. However Ill repeat one element publicly:- =20 " I have about 200 [RSA smartc= ards] in my garage, if anyone in the US wants them. Ihave 50k in chip form = still on the reel, if someone in the US wants to build a key cracker. Ill d= onatethem to a[n accredited] university." > Date: Mon, 18 Dec 2006 17:41:10 -0800> From: mike-list@pobox.com> To: tls= @ietf.org> Subject: Re: [TLS] Any advice regarding frequency of generating = newDHparameters? _________________________________________________________________ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=3D7adb59de-a857-45ba-81cc-= 685ee3e858fe= --_3d463105-0fc9-48a6-96ab-e6d5f89d34b4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


I took the discussion private. However Ill repeat one ele= ment publicly:-
 
"            &n= bsp;            = ;            &n= bsp;        I have about 200 [RSA s= martcards] in my garage, if anyone in the US wants them. I
have 50k in c= hip form still on the reel, if someone in the US wants to build a key crack= er. Ill donate
them to a[n accredited] university."


> Date: Mon, 18 Dec 2006 17:41:10 -0800
> From: mike-list@pobox.co= m
> To: tls@ietf.org
> Subject: Re: [TLS] Any advice regarding = frequency of generating newDHparameters?


Use Messenger t= o talk to your IM friends, even those on Yahoo! Talk now! = --_3d463105-0fc9-48a6-96ab-e6d5f89d34b4_-- --===============1710838969== 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 --===============1710838969==-- From tls-bounces@lists.ietf.org Tue Dec 19 09:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwgO3-0000I1-6q; Tue, 19 Dec 2006 09:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwgO1-0000HX-BX for tls@ietf.org; Tue, 19 Dec 2006 09:56:09 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwgNy-0000oC-Tv for tls@ietf.org; Tue, 19 Dec 2006 09:56:09 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA05936; Tue, 19 Dec 2006 15:53:52 +0100 (MEZ) From: Martin Rex Message-Id: <200612191453.PAA15106@uw1048.wdf.sap.corp> Subject: Re: [TLS] Any advice regarding frequency of generating To: mike-list@pobox.com (Mike) Date: Tue, 19 Dec 2006 15:53:47 +0100 (MET) In-Reply-To: <45874279.1040409@pobox.com> from "Mike" at Dec 18, 6 05:38:01 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: 798b2e660f1819ae38035ac1d8d5e3ab 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 Mike wrote: > > > EDH is superior to RSA > > in that CA key compromise does not lead to compromise of any prior > > or even future TLS session. > > Instead of "CA key", I meant to say "server private key". At least not for passive attacks, that is, I assume. Complete man-in-the-middle (i.e. active attack) using a compromised servers private key is still possible. The same would be achievable with RSA ephemeral keys. I wonder why ephemeral RSA keys are prohibited for regular RSA key exchange algorithms. Ephemeral RSA keypairs with the same size as the server's cert would provide perfect forward secrecy and protection against passive attacks -- and the entire code necessary to implement this is already there. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 10:34:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwgyd-0006Ca-39; Tue, 19 Dec 2006 10:33:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwgyc-0006CS-A0; Tue, 19 Dec 2006 10:33:58 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwgya-0000NX-Tj; Tue, 19 Dec 2006 10:33:58 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 15:24:44 +0000 Received: from mail pickup service by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC; Tue, 19 Dec 2006 15:21:21 +0000 Received: from smtp4.smtp.bt.com ([217.32.164.183]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Dec 2006 20:54:05 +0000 Received: from megatron.ietf.org ([156.154.16.145]) by smtp4.smtp.bt.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 20:54:04 +0000 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRn-0002Oj-Po; Mon, 18 Dec 2006 15:50:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0001xu-Ks; Mon, 18 Dec 2006 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwPRQ-0000Uj-9S; Mon, 18 Dec 2006 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id EE3D9175DD; Mon, 18 Dec 2006 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GwPQv-00071q-GL; Mon, 18 Dec 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 18 Dec 2006 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 18 Dec 2006 20:54:04.0625 (UTC) FILETIME=[A7321C10:01C722E6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-13.txt X-BeenThere: tls@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-13.txt Pages : 26 Date : 2006-12-18 This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-srp-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-srp-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-12-18142142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-12-18142142.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue Dec 19 11:02:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwhPS-0005F9-7S; Tue, 19 Dec 2006 11:01:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwhPR-0005F3-Ap for tls@ietf.org; Tue, 19 Dec 2006 11:01:41 -0500 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwhPO-00054t-3O for tls@ietf.org; Tue, 19 Dec 2006 11:01:41 -0500 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kBJG1W515526 for ; Tue, 19 Dec 2006 17:01:32 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 19 Dec 2006 17:01:32 +0100 (MET) Message-ID: <45880C64.2080305@edelweb.fr> Date: Tue, 19 Dec 2006 16:59:32 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Subject: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282639440==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1282639440== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000900070004040007080507" This is a cryptographically signed message in MIME format. --------------ms000900070004040007080507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello, it took me a while to discover that the new srp-tls draft contains: CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 }; CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3 }; CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4 }; CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 }; CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6 }; CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7 }; CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 }; CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9 }; CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10 }; Does this mean that that the document is not supposed to proceed in standards track according to TLS 1.1? 2. Cipher suite values with first byte decimal 192 (0xC0) through decimal 254 (0xFE) inclusive are reserved for assignment for non-Standards Track methods. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms000900070004040007080507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjE5MTU1OTMyWjAjBgkqhkiG9w0B CQQxFgQUb0/Q3+95u9oTom5GC7V+Zh7Mz1gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAcioSAS4hapCINRty xdATdW4vlHsImfHai44RQE2ajU+3xHVZdtve0wyvbl7WNwaUhyf92sD6bqIhZZME2R1ViZTF j84lztrO+8KVoZFLvbt7l3JO2mIhnuGqHS8FPiWxJdyeGNY1EkfTiRl44xhgmPYgrmEMHc9m rIAcPDqPwp8AAAAAAAA= --------------ms000900070004040007080507-- --===============1282639440== 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 --===============1282639440==-- From tls-bounces@lists.ietf.org Tue Dec 19 11:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwhtC-0002Xd-TU; Tue, 19 Dec 2006 11:32:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwhtB-0002XQ-Nb for tls@ietf.org; Tue, 19 Dec 2006 11:32:25 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwhtA-0001sd-Ds for tls@ietf.org; Tue, 19 Dec 2006 11:32:25 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 19 Dec 2006 16:32:23 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 19 Dec 2006 16:32:23 +0000 From: Stefan Santesson To: "tls@ietf.org" Date: Tue, 19 Dec 2006 16:31:39 +0000 Thread-Topic: GSS-API extension draft available Thread-Index: Accjhz2oFpwHVVyFSca4KcQYIeqPnwAAxKiA Message-ID: References: <45880C64.2080305@edelweb.fr> In-Reply-To: <45880C64.2080305@edelweb.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Ari Medvinsky , "pasi.eronen@nokia.com" Subject: [TLS] GSS-API extension draft available 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 first version of the GSS-API draft is available from: http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-00.txt The title of this draft is wrong. Please ignore that error. A new draft 01 = with a correct title has been submitted today. I request on behalf of the editors that the TLS WG adopt this as a WG docum= ent. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 12:47:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwj3H-0000Kk-RC; Tue, 19 Dec 2006 12:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwj3G-0000KO-VS for tls@ietf.org; Tue, 19 Dec 2006 12:46:54 -0500 Received: from bay0-omc3-s40.bay0.hotmail.com ([65.54.246.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwj3E-0007rr-Ix for tls@ietf.org; Tue, 19 Dec 2006 12:46:54 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 09:46:52 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , Mike Subject: RE: [TLS] Any advice regarding frequency of generating Date: Tue, 19 Dec 2006 09:46:51 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2006 17:46:52.0183 (UTC) FILETIME=[AA8D3A70:01C72395] X-Spam-Score: 2.6 (++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2120878547==" Errors-To: tls-bounces@lists.ietf.org --===============2120878547== Content-Type: multipart/alternative; boundary="_bdd8077e-15db-415c-a2ef-aee813d98fde_" --_bdd8077e-15db-415c-a2ef-aee813d98fde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Martin: =20 RSA ephemeral is not "prohibited". Is not standardized, thats true. =20 Look at it now from various angles. With Russ's non-repudiation proposal, a= TLS session=20 can be a form of signature, "certifying" (ephemeral) public keys. Another s= ession, would now=20 use the NR-grade (ephemeral) RSA key... so recently learned. =20 Think about using TCP pipelining, where multiple client protocols are alwa= ys=20 in play at the same time, not all of which are standards defined; some may = be=20 application defined. Break the limiting mental model of: create bind, make = session,=20 use session, drop TLS connection, keepalive TCP, resume session. =20 > The same would be achievable with RSA ephemeral keys.> I wonder why ephem= eral RSA keys are prohibited for regular> RSA key exchange algorithms. Ephe= meral RSA keypairs with the same> size as the server's cert would provide p= erfect forward secrecy> and protection against passive attacks -- and the e= ntire code> necessary to implement this is already there.> > -Martin> > > _= ______________________________________________> TLS mailing list> TLS@lists= .ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Express yourself with gadgets on Windows Live Spaces http://discoverspaces.live.com?source=3Dhmtag1&loc=3Dus= --_bdd8077e-15db-415c-a2ef-aee813d98fde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
Martin:
 
RSA ephemeral is not "prohibited".  Is not standardized, thats true.  
Look at it now from various angles. With Russ's non-repudiation propos= al, a TLS session
can be a form of signature, "certifying" (ephemeral) public keys. Another s= ession, would now
use the NR-grade (ephemeral) RSA key... so recently learned.
 
Think about using TCP pipelining,  where multiple client protocols are= always
in play at the same time, not all of which are standards defined; some may = be
application defined. Break the limiting mental model of: create bind, make = session,
use session, drop TLS connection, keepalive TCP, resume session.
 
> The same would be achievable with RSA ephemeral keys.
> I wonder= why ephemeral RSA keys are prohibited for regular
> RSA key exchange= algorithms. Ephemeral RSA keypairs with the same
> size as the serve= r's cert would provide perfect forward secrecy
> and protection again= st passive attacks -- and the entire code
> necessary to implement th= is is already there.
>
> -Martin
>
>
> ___= ____________________________________________
> TLS mailing list
&g= t; TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

Express yourself with gadgets on Windows Live Spaces Try it! = --_bdd8077e-15db-415c-a2ef-aee813d98fde_-- --===============2120878547== 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 --===============2120878547==-- From tls-bounces@lists.ietf.org Tue Dec 19 12:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjF5-0006OV-Mb; Tue, 19 Dec 2006 12:59:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjF4-0006OP-2J for tls@ietf.org; Tue, 19 Dec 2006 12:59:06 -0500 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 1GwjF2-0001Pc-NE for tls@ietf.org; Tue, 19 Dec 2006 12:59:06 -0500 Received: from [192.168.1.2] (ip139.post-street-towers.sfo.ygnition.net [24.219.24.139]) by darthmail.iqcicom.com (Vircom SMTPRS 4.35.480.0) with ESMTP id for ; Tue, 19 Dec 2006 09:58:58 -0800 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 Message-ID: <458829A7.1030404@trevp.net> Date: Tue, 19 Dec 2006 10:04:23 -0800 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [TLS] draft-ietf-tls-srp-13 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 new TLS/SRP draft has been posted. There are some significant changes in response to comments from Pasi and Eric, and to make this draft suitable as Experimental: - hello extension number marked IANA TBD - ciphersuite numbers marked IANA TBD - alert numbers changed to reuse existing alerts - the feature of optionally sending a 2nd ClientHello on same connection was removed, as it deviated from the RFC 4346 message exchange. - fair bit of text cleanup, in particular "Security Considerations" was re-structured, and considerations about Hash Function Agility were added. The authors still need to decide how to handle the normative reference to SRP-6, which currently is just a URL. There's several options, among them: - wait for IEEE P1363.2 to become a standard, reference that - move the reference to informational, since all necessary details are already in this document Regardless, the authors invite feedback on the current state of the draft. Trevor Detailed Changelist 12->13 --------------------------- - In 2.3, capitalized "SHALL" - In 2.5.1, add two clarifying sentences to end to define the phrase "SRP extension" and introduce the next two subsections. - In 2.5.1.1, replace phrase "user name extension" with "SRP extension" for clarity - In 2.5.1.2, rename title "Missing SRP Username" -> "Missing SRP Extension" for clarity - In 2.5.1.2, replace 'MAY return a "missing_srp_username"' with 'SHOULD return a fatal "unknown_psk_identity"' to avoid defining a new alert. - In 2.5.1.2, replace "This alert signals the client to resend the hello message" with "A client receiving this alert MAY choose to reconnect and resend the hello message". The old behavior of sending a 2nd ClientHello on the same connection is removed. - In 2.5.1.2, delete last two paragraphs, same reason. - In 2.5.1.3, replace "the given user name" with "the user name in the SRP extension" for clarity. - In 2.5.1.3, replace "unknown_srp_username" with "unknown_psk_identity" to avoid defining a new alert. - In 2.5.3, replace "untrusted_srp_parameters" with "insufficient_security" to avoid defining a new alert. - In 2.7, change the CipherSuite numbers from {0x00, TBD} to {0xC0, TBD}, since the range with first byte < 0xC0 requires Standard Action for assignment. - In 2.8.1, change reference from 2.4 -> 2.3 - In 2.9, replace the definition of 3 new alerts with a description of how the 4 old alerts in this draft are used. - In 3, break into subsections - In 3, move the consideration of checking A and B to the top and strengthen the language, since it's very important but I've seen several SRP implementations skip this. - In 3, replace "missing_srp_username" with "unknown_psk_identity", and remove some excess language. - In 3, remove mention of "locking" out an account, since redundant with prior suggestions, and potentially a security risk of its own. - In 3, reword discussion of attacker "learns a user's verifier" - In 3, add "Security Consideration" about hash functions - In 3, add reference to [TLS] for PRNG req'ts - In 4, update IANA considerations for hello extension - 6 is no longer suggested. - In 4, delete IANA considerations for alerts, since they require Standards Track - In 4, update IANA considerations for ciphersuites, to use the first byte 0xC0 per above. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 13:09:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjOf-0002xT-8M; Tue, 19 Dec 2006 13:09:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjOe-0002xO-Mj for tls@ietf.org; Tue, 19 Dec 2006 13:09:00 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwjOd-0003TC-H4 for tls@ietf.org; Tue, 19 Dec 2006 13:09:00 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 828329EC88 for ; Tue, 19 Dec 2006 13:09:20 -0500 (EST) 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 5087D9EC4C for ; Tue, 19 Dec 2006 13:09:20 -0500 (EST) Message-ID: <45882AF1.7020205@pobox.com> Date: Tue, 19 Dec 2006 10:09:53 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Ephemeral RSA (was Re: [TLS] Any advice regarding frequency of generating) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > RSA ephemeral is not "prohibited". Is not standardized, thats true. It would be easy to define a hello extension to add ephemeral RSA. The client would send the extension indicating that it would accept an ephemeral RSA key, and the server would respond with the same extension in the server hello indicating that it will send a server key exchange message with the key. This would avoid the need to define new cipher suites for ephemeral RSA. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 13:11:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjRK-0003p4-6Q; Tue, 19 Dec 2006 13:11:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwjRJ-0003oz-7Q for tls@ietf.org; Tue, 19 Dec 2006 13:11:45 -0500 Received: from bay0-omc2-s9.bay0.hotmail.com ([65.54.246.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwjRH-0004C2-Of for tls@ietf.org; Tue, 19 Dec 2006 13:11:45 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc2-s9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 10:11:43 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: "tls@ietf.org" Subject: RE: [TLS] GSS-API extension draft available Date: Tue, 19 Dec 2006 10:11:43 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2006 18:11:43.0250 (UTC) FILETIME=[234BFF20:01C72399] X-Spam-Score: 3.1 (+++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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: , Content-Type: multipart/mixed; boundary="===============0990489402==" Errors-To: tls-bounces@lists.ietf.org --===============0990489402== Content-Type: multipart/alternative; boundary="_3e323127-f839-47fc-b5f9-74e3ce8e54b3_" --_3e323127-f839-47fc-b5f9-74e3ce8e54b3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I much rather see the usul negotiation of the GSSAPI ciphersuite, and then = a custom-GSS client protocol=20 handshake occur, before the master keying occurs. This would naturally occu= r after serverkeyexchange, which=20 could be used to signal the GSS mechanism and payload exchange process sub-= states to the client. =20 Like ChangeCipherSuite messages, the GSS mechanism oid exchanges should not= be classified=20 as a handshake message. Arguably, the GSS payloads should: trouble is ...t= hey would have to be opaques, under the conventional formalism. =20 I don't like the idea of GSS mechanisms having any possibility of influenci= ng the sessionid resumption processes.=20 Thus im not in favor of the binding to the hello process.=20 =20 Interesting that yet another proposal is once again all about PRFs, and con= trolling master keying. Its not=20 OBVIOUSLY a spec about adding GSS API mechanisms to the portfolio of techni= ques, or fixing kerbersos ciphersuites, per the marketing! Did occur to me to wonder, from the design, whether there is an intend to b= e assigning to the GSS provider's=20 selected mechanism now the management/control of the session resumption pr= ocess. This is interesting, if=20 its an intent; particularly if its in the first packet (being bound to clie= nthello) =20 > From: stefans@microsoft.com> To: tls@ietf.org> Date: Tue, 19 Dec 2006 16:= 31:39 +0000> CC: arimed@windows.microsoft.com; pasi.eronen@nokia.com> Subje= ct: [TLS] GSS-API extension draft available> > A first version of the GSS-A= PI draft is available from:> http://www.ietf.org/internet-drafts/draft-sant= esson-tls-gssapi-00.txt> > The title of this draft is wrong. Please ignore = that error. A new draft 01 with a correct title has been submitted today.> = > I request on behalf of the editors that the TLS WG adopt this as a WG doc= ument.> > > > Stefan Santesson> Senior Program Manager> Windows Security, S= tandards> > > > > _______________________________________________> TLS mail= ing list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_3e323127-f839-47fc-b5f9-74e3ce8e54b3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
I much rather see the usul negotiation of the GSSAPI ciphersuite, and then = a custom-GSS client protocol
handshake occur, before the master keying occurs. This would naturally occu= r after serverkeyexchange, which
could be used to signal the GSS mechanism and payload exchange process sub-= states to the client.
 
Like ChangeCipherSuite messages, the GSS mechanism oid exchanges should not= be classified
as a handshake message.  Arguably, the GSS payloads should: trouble is= ...they would have to be opaques, under
the conventional formalism.
 
I don't like the idea of GSS mechanisms having any possibility of influenci= ng the sessionid resumption processes.
Thus im not in favor of the binding to the hello process. 
 
Interesting that yet another proposal is once again all about PRFs, and con= trolling master keying. Its not
OBVIOUSLY a spec about adding GSS API mechanisms to the portfolio of techni= ques, or fixing
kerbersos ciphersuites, per the marketing!

Did occur to me to wonder, from the design, whether there is an intend = to be assigning to the GSS provider's
selected mechanism now the  management/control of the session res= umption process. This is interesting, if
its an intent; particularly if its in the first packet (being bound to clie= nthello)
 

> From: stefans@microsoft.com
> To: tls@ietf.org
> Date: Tue= , 19 Dec 2006 16:31:39 +0000
> CC: arimed@windows.microsoft.com; pasi= .eronen@nokia.com
> Subject: [TLS] GSS-API extension draft available<= BR>>
> A first version of the GSS-API draft is available from:> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-00.txt=
>
> The title of this draft is wrong. Please ignore that erro= r. A new draft 01 with a correct title has been submitted today.
> > I request on behalf of the editors that the TLS WG adopt this as a W= G document.
>
>
>
> Stefan Santesson
> Sen= ior Program Manager
> Windows Security, Standards
>
> >
>
> _______________________________________________> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf= .org/mailman/listinfo/tls


Check the weather nationwide w= ith MSN Search Try it now! = --_3e323127-f839-47fc-b5f9-74e3ce8e54b3_-- --===============0990489402== 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 --===============0990489402==-- From tls-bounces@lists.ietf.org Tue Dec 19 13:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwk1y-00087o-9Q; Tue, 19 Dec 2006 13:49:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwk1w-00087Z-TT for tls@ietf.org; Tue, 19 Dec 2006 13:49:36 -0500 Received: from webmail.ntru.com ([64.115.150.147] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwk1u-0004wi-LS for tls@ietf.org; Tue, 19 Dec 2006 13:49:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Ephemeral RSA (was Re: [TLS] Any advice regarding frequency ofgenerating) Date: Tue, 19 Dec 2006 13:46:04 -0500 Message-ID: <9DC3EBEFB87A97498A7D25F130DE27E4984877@ohthree.jjj-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ephemeral RSA (was Re: [TLS] Any advice regarding frequency ofgenerating) Thread-Index: AccjmN+9p8KFL4SXS5WFJuXktCRtkAABPxhQ From: "Whyte, William" To: "Mike" , X-Spam-Score: 0.1 (/) 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 RSA keys take a long time to generate, so it's not clear that this would have any significant advantages over ephemeral DH. William=20 > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com]=20 > Sent: Tuesday, December 19, 2006 6:10 PM > To: tls@ietf.org > Subject: Ephemeral RSA (was Re: [TLS] Any advice regarding=20 > frequency ofgenerating) >=20 > > RSA ephemeral is not "prohibited". Is not standardized, thats true. >=20 > It would be easy to define a hello extension to add ephemeral RSA. > The client would send the extension indicating that it would accept > an ephemeral RSA key, and the server would respond with the same > extension in the server hello indicating that it will send a server > key exchange message with the key. This would avoid the need to > define new cipher suites for ephemeral RSA. >=20 > Mike >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 14:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwkQi-0003j9-DP; Tue, 19 Dec 2006 14:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwkQg-0003iw-N7 for tls@ietf.org; Tue, 19 Dec 2006 14:15:10 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwkQe-0002N0-CY for tls@ietf.org; Tue, 19 Dec 2006 14:15:10 -0500 Received: from www.secure-endpoints.com (cpe-68-175-93-48.nyc.res.rr.com [68.175.93.48]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBJJF70g009089 for ; Tue, 19 Dec 2006 14:15:07 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000038207.msg for ; Tue, 19 Dec 2006 14:16:30 -0500 Message-ID: <45883A8F.1090801@secure-endpoints.com> Date: Tue, 19 Dec 2006 14:16:31 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "tls@ietf.org" Subject: Re: [TLS] GSS-API extension draft available References: In-Reply-To: X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 19 Dec 2006 14:16:30 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.5 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============1466617942==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1466617942== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080801010208000106030908" This is a cryptographically signed message in MIME format. --------------ms080801010208000106030908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter: In RFC 2712 (TLS Kerberos Ciphers) the Kerberos session key is used as the pre-master secret. This mechanism has severe problems because it means that each and every TLS session that is created for as long as the Kerberos service ticket is valid will use the same pre-master secret. What this proposal does is replace RFC 2712 with a generic GSS-API method of generating a unique pre-master secret when used with the GSS Kerberos5 mechanism. GSS-API does not provide a method to extract key data from the underlying mechanism because doing so would result in a mechanism specific dependency and violate the GSS-API abstraction. The GSS-API PRF was implemented specifically to support higher level protocols (and applications) that require access to random data on both sides of the connection for use in generating keys. The GSS-API PRF is a mechanism independent abstraction. This proposal is a replacement for the RFC 2712. It also provides applications that use the GSS Kerberos5 mechanism support for credential delegation. I do not believe that the TLS GSS-API extension for negotiating GSS mechanisms should influence the Session resumption process. Jeffrey Altman Peter Williams wrote: > > I much rather see the usul negotiation of the GSSAPI ciphersuite, and > then a custom-GSS client protocol > handshake occur, before the master keying occurs. This would naturally > occur after serverkeyexchange, which > could be used to signal the GSS mechanism and payload exchange process > sub-states to the client. > > Like ChangeCipherSuite messages, the GSS mechanism oid exchanges should > not be classified > as a handshake message. Arguably, the GSS payloads should: trouble is > ...they would have to be opaques, under > the conventional formalism. > > I don't like the idea of GSS mechanisms having any possibility of > influencing the sessionid resumption processes. > Thus im not in favor of the binding to the hello process. > > Interesting that yet another proposal is once again all about PRFs, and > controlling master keying. Its not > OBVIOUSLY a spec about adding GSS API mechanisms to the portfolio of > techniques, or fixing > kerbersos ciphersuites, per the marketing! > > Did occur to me to wonder, from the design, whether there is an intend > to be assigning to the GSS provider's > selected mechanism now the management/control of the session resumption > process. This is interesting, if > its an intent; particularly if its in the first packet (being bound to > clienthello) > > ------------------------------------------------------------------------ > >> From: stefans@microsoft.com >> To: tls@ietf.org >> Date: Tue, 19 Dec 2006 16:31:39 +0000 >> CC: arimed@windows.microsoft.com; pasi.eronen@nokia.com >> Subject: [TLS] GSS-API extension draft available >> >> A first version of the GSS-API draft is available from: >> http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-00.txt >> >> The title of this draft is wrong. Please ignore that error. A new > draft 01 with a correct title has been submitted today. >> >> I request on behalf of the editors that the TLS WG adopt this as a WG > document. >> >> >> >> Stefan Santesson >> Senior Program Manager >> Windows Security, Standards >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/tls > > > ------------------------------------------------------------------------ > Check the weather nationwide with MSN Search Try it now! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --------------ms080801010208000106030908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTkxOTE2MzFaMCMGCSqGSIb3DQEJBDEWBBTBmasJ MdUuufqaGam3mEpI1uV1CjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAJZG/Awrd7RjxVUjz/B/X5jhLfTkYxz2Helx8l6ns18p5HWESMegL Pl6SLQOZavgAeg1j0S1oje3YUdxt3WfKHRb0XSRNrEqLX1Hg4W3XbB6AJDQbdtG5Dkn8I9UD MyHq5WyKxElY8a1+/qxhi4OksD0yHRpzqUj/q3Ss8shJj5KQxb8TbBL2lEqg7tJjghnLv+Z9 Bc0YL77OgEvUt2z6iUISn6iQH66bQTGJ/WyigkqB0e/Q7VfDx7HpDzpemIa8OSrM/5zD2xS5 fXqVe2P13rCtVwbj5d8Bn+InL/1esnjXEzIO/hzSZCaB/YOKFu9cwa2MBvCpwvw3Ueox6d2f 3QAAAAAAAA== --------------ms080801010208000106030908-- --===============1466617942== 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 --===============1466617942==-- From tls-bounces@lists.ietf.org Tue Dec 19 15:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlCr-00048s-Lb; Tue, 19 Dec 2006 15:04:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlCq-00046G-No for tls@ietf.org; Tue, 19 Dec 2006 15:04:56 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlCo-0005FP-QI for tls@ietf.org; Tue, 19 Dec 2006 15:04:56 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA15800; Tue, 19 Dec 2006 21:04:46 +0100 (MEZ) From: Martin Rex Message-Id: <200612192004.VAA20902@uw1048.wdf.sap.corp> Subject: Re: [TLS] Any advice regarding frequency of generating To: home_pw@msn.com (Peter Williams) Date: Tue, 19 Dec 2006 21:04:45 +0100 (MET) In-Reply-To: from "Peter Williams" at Dec 19, 6 09:46:51 am 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: 0a7aa2e6e558383d84476dc338324fab 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 Peter Williams wrote: > > Martin: > > RSA ephemeral is not "prohibited". Is not standardized, thats true. They are standardized and required for SSL ciphersuites with the RSA_EXPORT key exchange method when a Server cert with an RSA key >512 bit is being used. quoting rfc2246 (tls v1.0) 7.4.3. Server key exchange message: When this message will be sent: This message will be sent immediately after the server certificate message (or the server hello message, if this is an anonymous negotiation). The server key exchange message is sent by the server only when the server certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods: RSA_EXPORT (if the public key in the server certificate is longer than 512 bits) DHE_DSS DHE_DSS_EXPORT DHE_RSA DHE_RSA_EXPORT DH_anon It is not legal to send the server key exchange message for the following key exchange methods: RSA RSA_EXPORT (when the public key in the server certificate is less than or equal to 512 bits in length) DH_DSS DH_RSA rfc2246 says "It is not legal" to use ephemeral RSA for ciphersuites with the RSA key exchange method. And while the first part at least mentions the possibility of sign-only RSA keys, the second part completely ignores them. What is that supposed to mean anyway? "Not legal (under some jurisdictions?) but well within the spec" or "MUST NOT send/use" in spec language? > > With Russ's non-repudiation proposal, a TLS session can be a form of > signature. Btw. I completely and thoroughly dislike Russ' proposal for non-repudiation (he used the disguise terminology "evidence" though), both from a technical standpoint, as well as from a "political" perspective. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 15:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlNL-0002t9-Vl; Tue, 19 Dec 2006 15:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlNJ-0002sz-W5 for tls@ietf.org; Tue, 19 Dec 2006 15:15:46 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlNI-0007ci-MS for tls@ietf.org; Tue, 19 Dec 2006 15:15:45 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BD8AA1E8C5D; Tue, 19 Dec 2006 12:15:41 -0800 (PST) To: Peter Sylvester Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt References: <45880C64.2080305@edelweb.fr> From: Eric Rescorla Date: Tue, 19 Dec 2006 12:15:41 -0800 In-Reply-To: <45880C64.2080305@edelweb.fr> (Peter Sylvester's message of "Tue, 19 Dec 2006 16:59:32 +0100") Message-ID: <86lkl3r6aa.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Sylvester writes: > Hello, > > it took me a while to discover that the new srp-tls draft contains: > > > > CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 }; > > CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3 > }; > > CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4 > }; > > CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 }; > > CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6 > }; > > CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7 > }; > > CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 }; > > CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9 > }; > > CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10 > }; > > > Does this mean that that the document is not supposed to proceed in > standards track > according to TLS 1.1? > > 2. Cipher suite values with first byte decimal 192 (0xC0) through > decimal 254 (0xFE) inclusive are reserved for assignment for > non-Standards Track methods. Yes. This document is expected to proceed as Experimental. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 15:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlXb-0007Uk-PQ; Tue, 19 Dec 2006 15:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlXa-0007Uc-V1 for tls@ietf.org; Tue, 19 Dec 2006 15:26:22 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlXZ-0002B8-JT for tls@ietf.org; Tue, 19 Dec 2006 15:26:22 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA19724; Tue, 19 Dec 2006 21:26:10 +0100 (MEZ) From: Martin Rex Message-Id: <200612192026.VAA21427@uw1048.wdf.sap.corp> Subject: Re: [TLS] GSS-API extension draft available To: jaltman@secure-endpoints.com Date: Tue, 19 Dec 2006 21:26:10 +0100 (MET) In-Reply-To: <45883A8F.1090801@secure-endpoints.com> from "Jeffrey Altman" at Dec 19, 6 02:16:31 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: 2409bba43e9c8d580670fda8b695204a 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 Jeffrey Altman wrote: > > In RFC 2712 (TLS Kerberos Ciphers) the Kerberos session key is used as > the pre-master secret. This mechanism has severe problems because it > means that each and every TLS session that is created for as long as the > Kerberos service ticket is valid will use the same pre-master secret. This looks like an extremely poor choice to me, given the (lack of) entropy in Kerberos sessions keys, in particular of the installed base and the predominant interorable enctype when rfc2712 was issued. > > What this proposal does is replace RFC 2712 with a generic GSS-API > method of generating a unique pre-master secret when used with the GSS > Kerberos5 mechanism. GSS-API does not provide a method to extract key > data from the underlying mechanism because doing so would result in a > mechanism specific dependency and violate the GSS-API abstraction. Using the entropy from the GSS-API prf is fine. Completly ignoring additional randomness that is available through the regular TLS handshake looks somewhat strange to me. I would have expected that one would XOR a GSS-API supplied entropy for the pre-master secret with a traditional TLS-generated entropy. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 15:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlcg-0002ot-VT; Tue, 19 Dec 2006 15:31:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlcf-0002n7-M6 for tls@ietf.org; Tue, 19 Dec 2006 15:31:37 -0500 Received: from ms-smtp-03.rdc-nyc.rr.com ([24.29.109.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwlcc-0003DY-2B for tls@ietf.org; Tue, 19 Dec 2006 15:31:37 -0500 Received: from www.secure-endpoints.com (cpe-68-175-93-48.nyc.res.rr.com [68.175.93.48]) by ms-smtp-03.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBJKVXR1029343 for ; Tue, 19 Dec 2006 15:31:33 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000038228.msg for ; Tue, 19 Dec 2006 15:32:55 -0500 Message-ID: <45884C73.4030402@secure-endpoints.com> Date: Tue, 19 Dec 2006 15:32:51 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] GSS-API extension draft available References: <200612192026.VAA21427@uw1048.wdf.sap.corp> In-Reply-To: <200612192026.VAA21427@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 19 Dec 2006 15:32:55 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============0911975586==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0911975586== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000200080108070802030703" This is a cryptographically signed message in MIME format. --------------ms000200080108070802030703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > Using the entropy from the GSS-API prf is fine. Completly ignoring > additional randomness that is available through the regular TLS > handshake looks somewhat strange to me. > > I would have expected that one would XOR a GSS-API supplied entropy > for the pre-master secret with a traditional TLS-generated entropy. In other words, you would prefer an anonymous-DH exchange in addition to the GSS-API PRF? Jeffrey Altman --------------ms000200080108070802030703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTkyMDMyNTFaMCMGCSqGSIb3DQEJBDEWBBRmX653 XC+nv+OOV/JLD8TVzkjH+zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAh8nQvXgUXQ4dK26rgPhyQ5riDK0qUXcjpF3diEOq2Ut7VfYyH+BX jOOoDrvUnowBZ7LEkrdXVGntgEpg0GiJ8WBcqfyGfM7RlihQwS+iWHIGKiTBp6mqV5kfDq+r ate1MSctJl4Xc9Xq2kFnZYRlUjWchT/5gevZUodJ95kItUIylIh098BHtuWf8toP5VfGDGuj 6avgY3iVHLFXv20eFLH8lherDsuKd6PfonzAjVpVbkhkJevkIQWjUoNJvHBoszPqn6aSn0go H0YqTtNla9/ZaN+ceLHWXhia5zXCOLFNrr0V+mgLn/eiRH3qWGpPe2B//0GnBsZoRtxRG0Be 5wAAAAAAAA== --------------ms000200080108070802030703-- --===============0911975586== 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 --===============0911975586==-- From tls-bounces@lists.ietf.org Tue Dec 19 15:42:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlme-0000Az-SA; Tue, 19 Dec 2006 15:41:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlmd-0000Au-UT for tls@ietf.org; Tue, 19 Dec 2006 15:41:55 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gwlmc-0006k5-AE for tls@ietf.org; Tue, 19 Dec 2006 15:41:55 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 5F2EE5C01E for ; Tue, 19 Dec 2006 12:45:05 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 19 Dec 2006 12:41:53 -0800 From: Eric Rescorla Message-Id: <20061219204505.5F2EE5C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Subject: [TLS] Comments on TLS identity protection 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've reviewed both draft-hajjeh-tls-identity-protection-00 and draft-urien-badra-eap-tls-identity-protection-01. Extensive reviews below but the executive summary is that i think these proposals are poorly motivated and do not believe they should be adopted by the TLS WG. -Ekr Comments on: draft-hajjeh-tls-identity-protection-00 BACKGROUND The TLS handshake occurs in the clear. Thus, any observer can determine the credentials used by the client or server to authenticate themselves. This document describes an "identity protection" mode for TLS designed to hide the client's certificate. GENERAL COMMENTS I don't understand what the motivation for this mode is. I appreciate that it was an advertised feature of IPsec, but TLS doesn't need to replicate every feature of IPsec. In particular, since certificate-based client authentication is actually fairly rare, it's not clear that *privacy* of that client authentication is really a big consideration. The good news is that TLS has a very simple mechanism for achieving this: do an ordinary TLS handshake without client authentication and then do an immediate re-handshake with client auth. As the authors observe, this is slower (two sets of crypto computations and 4 RTTs) than a specialized identity protection mode. However, it is available now and as far as I can tell is rarely done. I don't find the argument that there is a large demand for this feature if it were only 50% faster particularly persuasive. Rather, this seems like a premature optimization. As a secondary consideration, this mechanism provides imperfect privacy guarantees. Although the Certificate is hidden, the CertificateVerify is not. As a consequence, if an attacker ever obtains a client's certificate it can do trial verification to determine whether a new handshake uses that certificate. In order for the identity protection to be protected against MITM attack, the server cert needs to be verified prior to sending the Certificate message. Because the question of whether this is the correct certificate is outside of TLS, in many TLS stacks the handshake completes prior to checking the server hostname. That won't work here. DETAILED COMMENTS S 1. Client identity protection may also be done through a EDH exchange before establishing an ordinary handshake with identity information [RESCORLA]. This wouldn't however be secure enough against active attackers and wouldn't be favorable for some environments (e.g. mobile), due to the additional cryptographic computations. It's important to be clear about "secure enough". The active attack here discloses the client's certificate. It does not result in compromise of the connection. S 2. If the server selects one of the ciphersuites defined in this document, the client MUST encrypt its certificate using the symmetric algorithm selected by the server from the list in ClientHello.cipher_suites and a key derived from the SecurityParameters.master_secret (see section 3 for the key computation). This is underspecified. How is the encryption process performed? S 3. This changes the TLS state machine. In TLS the ClientKeyExchange precedes the Certificate message. The identity_protection_key is set to the low order bits of the key_block, and its length is set appropriately to ServerHello.cipher_suite. "low-order bits"? And what about the next extension which wants the "low-order bits". You need to specify complete slicing and dicing instructions. Comments on: draft-urien-badra-eap-tls-identity-protection-01 NOTE: This document is somehow related to draft-hajjeh-tls-identity-protection-00. See the review for that document. GENERAL COMMENTS I don't understand what the relationship of this document is to draft-hajjeh-tls-identity-protection-00, which seems to be similar. See my comments on that document for why I don't think this work is adequately motivated. I note that this mechanism has the same partial information leakage problem as described in that document. I note that this document talks about EAP-TLS but it clearly is a modification to TLS. DETAILED COMMENTS S 5. The "Implicit" mode creates a situation in which two implementations both of which would be willing to do client auth without encryption of the Certificate can't communicate because the client insists on encrypting. That's not really an acceptable situation. S 6. Notified mode implies a change to TLS behavior (And the Certificate reading state machine) from some mechanism that's not detectable or negotiable inside TLS. That doesn't seem acceptable either. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 15:48:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlt6-0003Ab-AI; Tue, 19 Dec 2006 15:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwlt4-00039n-JH for tls@ietf.org; Tue, 19 Dec 2006 15:48:34 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwlt3-0007K5-Az for tls@ietf.org; Tue, 19 Dec 2006 15:48:34 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 88FBC5C01E for ; Tue, 19 Dec 2006 12:51:44 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 19 Dec 2006 12:48:32 -0800 From: Eric Rescorla Message-Id: <20061219205144.88FBC5C01E@laser.networkresonance.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Please discuss: draft-housley-evidence-extns-00 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 SPEAKING AS CHAIR: Mark Brown and Russ Housley have requested that the TLS WG adopt draft-housley-evidence-extns-01 as a WG item. This work was presented at San Diego to a generally positive response but it needs to be discussed on the list. Please use this thread to start that discussion. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 15:54:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwly9-0007lf-Jz; Tue, 19 Dec 2006 15:53:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwly8-0007lV-UL for tls@ietf.org; Tue, 19 Dec 2006 15:53:48 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwlxo-000077-W1 for tls@ietf.org; Tue, 19 Dec 2006 15:53:48 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 78E7B1E8C5D; Tue, 19 Dec 2006 12:53:28 -0800 (PST) To: tls@ietf.org Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <20061219205144.88FBC5C01E@laser.networkresonance.com> From: Eric Rescorla Date: Tue, 19 Dec 2006 12:53:28 -0800 In-Reply-To: <20061219205144.88FBC5C01E@laser.networkresonance.com> (Eric Rescorla's message of "Tue, 19 Dec 2006 12:48:32 -0800") Message-ID: <86ac1jr4jb.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: > SPEAKING AS CHAIR: > Mark Brown and Russ Housley have requested that the TLS WG > adopt draft-housley-evidence-extns-01 as a WG item. This > work was presented at San Diego to a generally positive > response but it needs to be discussed on the list. Please > use this thread to start that discussion. SPEAKING AS MYSELF I'm quite negative on this proposal. Review attached. Note: the following review was based on the -00 version of the document but a quick skim suggests that the -01 has the same weaknesses. BACKGROUND TLS provides for public key authentication of both client and server but this only provides for proof of the existence of the handshake (and this only in limited circumstances). It doesn't provide for any proof of the contents of the data messages. This draft extends TLS to provide signatures over the data. ARCHITECTURAL COMMENTS I'm not particularly enamored of this general approach. The signatures in question are fundamentally an application-level construct: they're requested by the applications and ultimately consumed by them. The only real reason to do this at the TLS layer is the sense that it's easier to deploy. I'm not actually convinced that that's so, since this approach still requires modifying the applications to request security the signature/evidence services. In addition, putting this functionality at the TLS layer embodies some not-so-attractive tradeoffs, in particular, that the binding of application-layer messages to the actual evidence provided isn't particularly tight, since the signatures cover extents of the traffic rather than messages. This introduces a number of race conditions which are only partially solved by the interlocking alerts used here. Among these are: - The sender of the start1 alert has only minimal information/control over when the peer will start signing traffic. - It's quite likely that one side will have to process messages without knowing whether the peer will actually sign his section of the traffic. This is obviously a problem if you are producing side effects. You can mitigate this problem only by doing two evidence collections in lockstep. - Applications need a bunch of new logic to detect the evidence request but hold their response to application-layer boundaries. This cannot be implemented at the TLS layer. - If you want to condition your application-layer responses to whether the peer provided a signature you need some way to provide application-layer "please resend with signature". This is a common case but can only be dealt with very clumsily here. This seems like a fairly large architectural change to TLS to make it do something it was never designed to do and which can be done better in the application. DETAILED COMMENTS S 1. It looks like the evidence creation has to involve signatures by both parties. Why not have it be one-way. S 1.2. Generating evidence is not compatible with Diffie-Hellman Ephemeral (DHE) key exchanges. DHE does not permit the same keying material to be generated for validation of the evidence after the TLS session is over. Persistent evidence requires the use of a digital signature so that it can be validated well after the TLS session is over. Why not just store the traffic keys? Figure 1 would be better with some markers about the traffic segments that are signed. S 2. I'm uncomfortable with the idea if "evidence suites" and later of new certificates and certificate negotiation. This seems like you're layering an entirely new protocol over TLS. S 3. This consumes 4 new alerts. The space isn't that big. Since you're already defining a new protocol type, these messages might as well be part of that protocol. S A. Defining cipher suites with key lengths attached to them isn't hte TLS way. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwm8G-0001pL-UL; Tue, 19 Dec 2006 16:04:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwm8F-0001pB-G0 for tls@ietf.org; Tue, 19 Dec 2006 16:04:15 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwm88-0002lo-Gy for tls@ietf.org; Tue, 19 Dec 2006 16:04:15 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 06E5B1E8C5D; Tue, 19 Dec 2006 13:04:08 -0800 (PST) To: martin.rex@sap.com Subject: Re: [TLS] Comments on TLS identity protection References: <200612192100.WAA22456@uw1048.wdf.sap.corp> From: Eric Rescorla Date: Tue, 19 Dec 2006 13:04:07 -0800 In-Reply-To: <200612192100.WAA22456@uw1048.wdf.sap.corp> (Martin Rex's message of "Tue, 19 Dec 2006 22:00:29 +0100 (MET)") Message-ID: <86vek7pph4.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: > Eric Rescorla wrote: >> >> The good news is that TLS has a very simple mechanism for achieving >> this: do an ordinary TLS handshake without client authentication >> and then do an immediate re-handshake with client auth. As the >> authors observe, this is slower (two sets of crypto computations >> and 4 RTTs) than a specialized identity protection mode. However, >> it is available now and as far as I can tell is rarely done. >> I don't find the argument that there is a large demand for this >> feature if it were only 50% faster particularly persuasive. >> Rather, this seems like a premature optimization. > > It is not as rare as you might think. It is actually the > default in Microsoft's IIS with some configurations that > IIS only requests SSL client authentication after > having seen the request (URL). It might be a side-effect > of NOT requiring SSL client authentication on the root/home > page of the webserver and only for certain areas/paths. Good point. However, as you say in most cases the request for client auth is contingent upon seeing the request and so a rehandshake is required here in any case. A one-pass protocol wouldn't work here. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmCU-0002dn-Mh; Tue, 19 Dec 2006 16:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmCT-0002db-PU for tls@ietf.org; Tue, 19 Dec 2006 16:08:37 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwmCR-0003lj-K0 for tls@ietf.org; Tue, 19 Dec 2006 16:08:37 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA22920; Tue, 19 Dec 2006 22:08:11 +0100 (MEZ) From: Martin Rex Message-Id: <200612192108.WAA22619@uw1048.wdf.sap.corp> Subject: Re: Ephemeral RSA (was Re: [TLS] Any advice regarding frequency To: WWhyte@ntru.com (Whyte William) Date: Tue, 19 Dec 2006 22:08:11 +0100 (MET) In-Reply-To: <9DC3EBEFB87A97498A7D25F130DE27E4984877@ohthree.jjj-i.com> from "Whyte, William" at Dec 19, 6 01:46:04 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: de4f315c9369b71d7dd5909b42224370 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 Whyte, William wrote: > > RSA keys take a long time to generate, so it's not clear that this > would have any significant advantages over ephemeral DH. One of the advantages is that the code is already there and most of it interoperability tested because the RSA_EXPORT key exchange method requires an ephemeral RSA keypair for use with certs that have RSA keys >512 bits. There is no requirement to generate a new ephemeral RSA keypair on every SSL handshake. It should be perfectly sufficient for a TLS server to re-generate an ephemeral keypair out-of-band like once per hour. SSHD in daemon mode uses a similar approach. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmEb-00036p-Cw; Tue, 19 Dec 2006 16:10:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmEZ-00036T-Mr for tls@ietf.org; Tue, 19 Dec 2006 16:10:47 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwmEY-0002yd-AF for tls@ietf.org; Tue, 19 Dec 2006 16:10:47 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 942575C089; Tue, 19 Dec 2006 13:13:57 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 19 Dec 2006 13:10:45 -0800 From: Eric Rescorla Message-Id: <20061219211357.942575C089@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: kent@bbn.com Subject: [TLS] Counter structure 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 Currently, the (D)TLS Counter draft uses the sequence number to generate the per-record IV. Recently, Steve Kent pointed out a drawback of this mode which mau motivate a different counter structure. I was hoping we could discuss this on the list and try to reach consensus. Here's the issue as I understand it (Steve, please correct me if I screw something up): The CTR IV is security critical in a way that the CBC IV is not. Accordingly, for evaluated products the IV must be generated inside the evaluation boundary where it can be insured that it's not reused. As the IV is currently designed, this would mean that the record sequence number was also maintained inside the security boundary. Ordinarily, this isn't an issue but in implementations where you are doing hardware record processing you might have multiple parallel hardware modules. Synchronizing the sequence number between those modules could be quite problematic. An alternate approach is to use an explicit per-record IV which can be maintained independently by each encryption module. This IV doesn't need to be the full block width, just long enough to prevent collisions. If the modules use a counter or LFSR (with a few bits reserved for module ID) to generate the IV, then you can get by with 64 bits of IV. [0] So, the question is: is enabling this kind of parallel hardware implementation a good tradeoff for 8 more bytes of record size? Please discuss. Thanks, -Ekr [0] Note that this IV size more or less precludes random IVs because of birthday statistics. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmIp-00045u-1N; Tue, 19 Dec 2006 16:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmIn-000457-BR for tls@ietf.org; Tue, 19 Dec 2006 16:15:09 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwmIl-0005UK-VW for tls@ietf.org; Tue, 19 Dec 2006 16:15:09 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA02921; Tue, 19 Dec 2006 22:15:02 +0100 (MEZ) From: Martin Rex Message-Id: <200612192115.WAA22812@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection To: ekr@networkresonance.com Date: Tue, 19 Dec 2006 22:15:01 +0100 (MET) In-Reply-To: <86vek7pph4.fsf@raman.networkresonance.com> from "Eric Rescorla" at Dec 19, 6 01:04:07 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Eric Rescorla wrote: > > Good point. > > However, as you say in most cases the request for client auth > is contingent upon seeing the request and so a rehandshake is > required here in any case. A one-pass protocol wouldn't work > here. Correct. I had the same thought but completely failed to point this out. In the not uncommon case with IIS renegotiating after having evaluated the HTTP(S)-request, the one-pass protocol can not be used. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmRe-0006fy-2E; Tue, 19 Dec 2006 16:24:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwm4V-0007xF-5G for tls@ietf.org; Tue, 19 Dec 2006 16:00:23 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwm4R-0001k0-8W for tls@ietf.org; Tue, 19 Dec 2006 16:00:23 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 19 Dec 2006 12:59:18 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.24; Tue, 19 Dec 2006 12:59:17 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Tue, 19 Dec 2006 12:59:17 -0800 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] Please discuss: draft-housley-evidence-extns-00 Date: Tue, 19 Dec 2006 12:58:58 -0800 Message-ID: <802A881C87166D4597F9EEFC3F04F4F80347E8FF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <20061219205144.88FBC5C01E@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Index: Accjryq6Q0PRb8xGSIeo36JAFNvEQAAATgcg References: <20061219205144.88FBC5C01E@laser.networkresonance.com> From: Ari Medvinsky To: Eric Rescorla , X-OriginalArrivalTime: 19 Dec 2006 20:59:17.0583 (UTC) FILETIME=[8C2575F0:01C723B0] X-Spam-Score: 1.1 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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, It would be great if you could add a link to this draft from http://www.ietf.org/html.charters/tls-charter.html (the draft section). Thanks, -Ari -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Tuesday, December 19, 2006 12:49 PM To: tls@ietf.org Subject: [TLS] Please discuss: draft-housley-evidence-extns-00 SPEAKING AS CHAIR: Mark Brown and Russ Housley have requested that the TLS WG adopt draft-housley-evidence-extns-01 as a WG item. This work was presented at San Diego to a generally positive response but it needs to be discussed on the list. Please use this thread to start that discussion. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmU5-0007mF-1s; Tue, 19 Dec 2006 16:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwm5Q-0000S8-V4 for tls@ietf.org; Tue, 19 Dec 2006 16:01:21 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwm5I-0001vn-SE for tls@ietf.org; Tue, 19 Dec 2006 16:01:20 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6191B1E8C5D; Tue, 19 Dec 2006 13:01:12 -0800 (PST) To: Ari Medvinsky Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <20061219205144.88FBC5C01E@laser.networkresonance.com> <802A881C87166D4597F9EEFC3F04F4F80347E8FF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> From: Eric Rescorla Date: Tue, 19 Dec 2006 13:01:12 -0800 In-Reply-To: <802A881C87166D4597F9EEFC3F04F4F80347E8FF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> (Ari Medvinsky's message of "Tue, 19 Dec 2006 12:58:58 -0800") Message-ID: <8664c7r46f.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Ari Medvinsky writes: > It would be great if you could add a link to this draft from > http://www.ietf.org/html.charters/tls-charter.html (the draft section). It's not yet a WG item. If it becomes one, I'll arrange for a link. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:27:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwm50-0008Ou-6e; Tue, 19 Dec 2006 16:00:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwm4o-0008Gr-Fr for tls@ietf.org; Tue, 19 Dec 2006 16:00:42 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwm4i-0001nt-IK for tls@ietf.org; Tue, 19 Dec 2006 16:00:42 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA06822; Tue, 19 Dec 2006 22:00:28 +0100 (MEZ) From: Martin Rex Message-Id: <200612192100.WAA22456@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection To: ekr@networkresonance.com (Eric Rescorla) Date: Tue, 19 Dec 2006 22:00:29 +0100 (MET) In-Reply-To: <20061219204505.5F2EE5C01E@laser.networkresonance.com> from "Eric Rescorla" at Dec 19, 6 12:41:53 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: 7d33c50f3756db14428398e2bdedd581 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 Eric Rescorla wrote: > > The good news is that TLS has a very simple mechanism for achieving > this: do an ordinary TLS handshake without client authentication > and then do an immediate re-handshake with client auth. As the > authors observe, this is slower (two sets of crypto computations > and 4 RTTs) than a specialized identity protection mode. However, > it is available now and as far as I can tell is rarely done. > I don't find the argument that there is a large demand for this > feature if it were only 50% faster particularly persuasive. > Rather, this seems like a premature optimization. It is not as rare as you might think. It is actually the default in Microsoft's IIS with some configurations that IIS only requests SSL client authentication after having seen the request (URL). It might be a side-effect of NOT requiring SSL client authentication on the root/home page of the webserver and only for certain areas/paths. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:33:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmaP-00053u-Dz; Tue, 19 Dec 2006 16:33:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmaO-00053p-Gd for tls@ietf.org; Tue, 19 Dec 2006 16:33:20 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwmaN-0000t9-5F for tls@ietf.org; Tue, 19 Dec 2006 16:33:20 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA00768; Tue, 19 Dec 2006 22:33:12 +0100 (MEZ) From: Martin Rex Message-Id: <200612192133.WAA23266@uw1048.wdf.sap.corp> Subject: Re: [TLS] GSS-API extension draft available To: jaltman@secure-endpoints.com Date: Tue, 19 Dec 2006 22:33:13 +0100 (MET) In-Reply-To: <45884C73.4030402@secure-endpoints.com> from "Jeffrey Altman" at Dec 19, 6 03:32: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: 7d33c50f3756db14428398e2bdedd581 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 Jeffrey Altman wrote: > > Martin Rex wrote: > > Using the entropy from the GSS-API prf is fine. Completly ignoring > > additional randomness that is available through the regular TLS > > handshake looks somewhat strange to me. > > > > I would have expected that one would XOR a GSS-API supplied entropy > > for the pre-master secret with a traditional TLS-generated entropy. > > In other words, you would prefer an anonymous-DH exchange in addition > to the GSS-API PRF? Ooops, sorry -- I had only looked at the new draft, not rfc2712, and was not aware that this completely removed the server certificate from the TLS handshake. This might be a challenge for client-side UIs, which may not be prepared to deal with server identities not based on X.509 certs, i.e. plug'n'play this into a TLS mechanism probably does not work. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 16:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmiD-0006LY-Ak; Tue, 19 Dec 2006 16:41:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmiB-000644-Ox for tls@ietf.org; Tue, 19 Dec 2006 16:41:23 -0500 Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwmi9-0002Aq-Gx for tls@ietf.org; Tue, 19 Dec 2006 16:41:23 -0500 Received: from www.secure-endpoints.com (cpe-68-175-93-48.nyc.res.rr.com [68.175.93.48]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBJLfIgU025486 for ; Tue, 19 Dec 2006 16:41:18 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000038245.msg for ; Tue, 19 Dec 2006 16:42:41 -0500 Message-ID: <45885CCF.7040004@secure-endpoints.com> Date: Tue, 19 Dec 2006 16:42:39 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: martin.rex@sap.com Subject: Re: [TLS] GSS-API extension draft available References: <200612192133.WAA23266@uw1048.wdf.sap.corp> In-Reply-To: <200612192133.WAA23266@uw1048.wdf.sap.corp> X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Tue, 19 Dec 2006 16:42:41 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============0399184190==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0399184190== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050509020402030903050904" This is a cryptographically signed message in MIME format. --------------ms050509020402030903050904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Martin Rex wrote: > Jeffrey Altman wrote: >> Martin Rex wrote: >>> Using the entropy from the GSS-API prf is fine. Completly ignoring >>> additional randomness that is available through the regular TLS >>> handshake looks somewhat strange to me. >>> >>> I would have expected that one would XOR a GSS-API supplied entropy >>> for the pre-master secret with a traditional TLS-generated entropy. >> In other words, you would prefer an anonymous-DH exchange in addition >> to the GSS-API PRF? > > Ooops, sorry -- I had only looked at the new draft, not rfc2712, > and was not aware that this completely removed the server certificate > from the TLS handshake. This might be a challenge for client-side UIs, > which may not be prepared to deal with server identities not based > on X.509 certs, i.e. plug'n'play this into a TLS mechanism probably > does not work. > > -Martin RFC 2712 is currently supported by both Java and OpenSSL. I do not expect the new protocol to have additional challenges from a UI perspective. Jeffrey Altman --------------ms050509020402030903050904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMTkyMTQyMzlaMCMGCSqGSIb3DQEJBDEWBBQlOaNo tEvIxr5WINC9gkrWnNQk0DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAC86TIfJjCymENy6BO7YxLp+OkGGAGsRacykeY3yWWQgekkfDhDF6 EfWWQE/weXZwOMnASxS8sysLWBzMZOtWQ01Qfw+mmyOBKHEe91pKnMqJo7/YmMlNBd6WWOsB h9VuZ5TYrpTitkKjHTi1vruj1vBGgKyZfWDRgaJHaIA7lTDjSFhifKl0FdiPsIFPtDyXVuTG RWfDYV0648em1BuXBpAf8eKAHFjFYmphpCWCtlxrG8VGx4pVtnDdbawTGkyPlDGatfWBqoOR G8TbZxdl0uQ/RXlEVT6sNchTKIwEAlOGFYGvoAMRp125ynJ0bN76V2GVtBOnx92D0sY709oN ygAAAAAAAA== --------------ms050509020402030903050904-- --===============0399184190== 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 --===============0399184190==-- From tls-bounces@lists.ietf.org Tue Dec 19 17:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnUL-0001OV-6w; Tue, 19 Dec 2006 17:31:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnUK-0001Np-23 for tls@ietf.org; Tue, 19 Dec 2006 17:31:08 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwnUI-00018J-Es for tls@ietf.org; Tue, 19 Dec 2006 17:31:08 -0500 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id XAA44914 ; Tue, 19 Dec 2006 23:29:38 +0100 Received: from 86.72.162.216 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 19 Dec 2006 23:32:38 +0100 (CET) Message-ID: <61434.86.72.162.216.1166567558.squirrel@www.isima.fr> In-Reply-To: <20061219204505.5F2EE5C01E@laser.networkresonance.com> References: <20061219204505.5F2EE5C01E@laser.networkresonance.com> Date: Tue, 19 Dec 2006 23:32:38 +0100 (CET) Subject: Re: [TLS] Comments on TLS identity protection From: badra@isima.fr To: "Eric Rescorla" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Hi Eric, Thank you for your review, please find comments in-line. Note: my comments concern the draft-hajjeh-tls-identity-protection-00, since the second document proposes the same feature but by using, among others, a TLS extension. > Comments on: draft-hajjeh-tls-identity-protection-00 > > BACKGROUND > The TLS handshake occurs in the clear. Thus, any observer can > determine the credentials used by the client or server to authenticate > themselves. This document describes an "identity protection" mode for > TLS designed to hide the client's certificate. > > > GENERAL COMMENTS > I don't understand what the motivation for this mode is. I appreciate > that it was an advertised feature of IPsec, but TLS doesn't > need to replicate every feature of IPsec. In particular, since > certificate-based client authentication is actually fairly > rare, it's not clear that *privacy* of that client authentication > is really a big consideration. In EAP-TLS, an implementation of TLS for Wireless LAN and later for WiMAX, the client is authenticated based on the certificate's use. This is the initial motivation of this work. > As a secondary consideration, this mechanism provides imperfect > privacy guarantees. Although the Certificate is hidden, the > CertificateVerify is not. As a consequence, if an attacker > ever obtains a client's certificate it can do trial verification > to determine whether a new handshake uses that certificate. OK. in this case, CertificateVerify should be symmetrically encrypted too. > In order for the identity protection to be protected against > MITM attack, the server cert needs to be verified prior to > sending the Certificate message. Because the question of whether > this is the correct certificate is outside of TLS, in many TLS > stacks the handshake completes prior to checking the server > hostname. That won't work here. Could you clarify that please? I didn't get the point regarding the server cert which is sent in cleartext. > DETAILED COMMENTS > S 1. > > Client identity protection may also be done through a EDH exchange > before establishing an ordinary handshake with identity information > [RESCORLA]. This wouldn't however be secure enough against active > attackers and wouldn't be favorable for some environments (e.g. > mobile), due to the additional cryptographic computations. > > It's important to be clear about "secure enough". The active > attack here discloses the client's certificate. It does not > result in compromise of the connection. Right, I will modify the text with regard to your remark. > S 2. > If the server selects one of the ciphersuites defined in this > document, the client MUST encrypt its certificate using the > symmetric algorithm selected by the server from the list in > ClientHello.cipher_suites and a key derived from the > SecurityParameters.master_secret (see section 3 for the key > computation). > > This is underspecified. How is the encryption process > performed? The following text will be added: If a stream cipher is chosen, then the peer's certificate is encrypted with the derived key, without any padding byte. If a block cipher is selected, then padding bytes are added to force the length of the certificate message to be an integral multiple of the bloc cipher's length. > S 3. > This changes the TLS state machine. In TLS the ClientKeyExchange > precedes the Certificate message. Right. The following sequence replaces the sequence used by the actual version of the document. It is true that the server must read the ClientKeyExchange before the Certificate. Is that a big change to the TLS machine-state? .... <-------- ServerHelloDone {Certificate} ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished --------> .... > The identity_protection_key is set to the low order bits of the > key_block, and its length is set appropriately to > ServerHello.cipher_suite. > > "low-order bits"? And what about the next extension which wants > the "low-order bits". You need to specify complete slicing and > dicing instructions. OK. TLS notes that P_hash can be iterated as many times as is necessary to produce the required quantity of data. Then, both the client and the server derive the identity_protection_key as follow: client_write_MAC_secret[SecurityParameters.hash_size] server_write_MAC_secret[SecurityParameters.hash_size] client_write_key[SecurityParameters.key_material_length] server_write_key[SecurityParameters.key_material_length] client_write_IV[SecurityParameters.IV_size] server_write_IV[SecurityParameters.IV_size] identity_protection_key[SecurityParameters.key_material_length] > Comments on: draft-urien-badra-eap-tls-identity-protection-01 > > DETAILED COMMENTS > S 5. > The "Implicit" mode creates a situation in which two implementations > both of which would be willing to do client auth without encryption > of the Certificate can't communicate because the client insists > on encrypting. That's not really an acceptable situation. Agree. > > > S 6. > Notified mode implies a change to TLS behavior (And the Certificate > reading state machine) from some mechanism that's not detectable > or negotiable inside TLS. That doesn't seem acceptable either. Idem for S 3. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 17:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnZn-0003ra-C6; Tue, 19 Dec 2006 17:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnZm-0003rV-6R for tls@ietf.org; Tue, 19 Dec 2006 17:36:46 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwnZk-0002Z0-S8 for tls@ietf.org; Tue, 19 Dec 2006 17:36:46 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0AF461E8C5D; Tue, 19 Dec 2006 14:36:44 -0800 (PST) To: badra@isima.fr Subject: Re: [TLS] Comments on TLS identity protection References: <20061219204505.5F2EE5C01E@laser.networkresonance.com> <61434.86.72.162.216.1166567558.squirrel@www.isima.fr> From: Eric Rescorla Date: Tue, 19 Dec 2006 14:36:43 -0800 In-Reply-To: <61434.86.72.162.216.1166567558.squirrel@www.isima.fr> (badra@isima.fr's message of "Tue, 19 Dec 2006 23:32:38 +0100 (CET)") Message-ID: <86ejqvpl6s.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org badra@isima.fr writes: >> Comments on: draft-hajjeh-tls-identity-protection-00 >> >> BACKGROUND >> The TLS handshake occurs in the clear. Thus, any observer can >> determine the credentials used by the client or server to authenticate >> themselves. This document describes an "identity protection" mode for >> TLS designed to hide the client's certificate. >> >> >> GENERAL COMMENTS >> I don't understand what the motivation for this mode is. I appreciate >> that it was an advertised feature of IPsec, but TLS doesn't >> need to replicate every feature of IPsec. In particular, since >> certificate-based client authentication is actually fairly >> rare, it's not clear that *privacy* of that client authentication >> is really a big consideration. > > In EAP-TLS, an implementation of TLS for Wireless LAN and later for WiMAX, > the client is authenticated based on the certificate's use. This is the > initial motivation of this work. Yes, but I don't think this really explains why the certificate needs to be kept secret or why the double handshake technique isn't good enough. >> In order for the identity protection to be protected against >> MITM attack, the server cert needs to be verified prior to >> sending the Certificate message. Because the question of whether >> this is the correct certificate is outside of TLS, in many TLS >> stacks the handshake completes prior to checking the server >> hostname. That won't work here. > > > Could you clarify that please? I didn't get the point regarding the server > cert which is sent in cleartext. The attacker performs a MITM attack with a valid certificate. The TLS implementation completes the handshake and then prompts the application to verify the certificate's identity against the intended identity. This fails, but by this time the client has already provided his certificate. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 17:42:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwner-0006sm-0I; Tue, 19 Dec 2006 17:42:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwnep-0006sX-J3 for tls@ietf.org; Tue, 19 Dec 2006 17:41:59 -0500 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwnen-0003LC-BJ for tls@ietf.org; Tue, 19 Dec 2006 17:41:59 -0500 Received: by wx-out-0506.google.com with SMTP id h27so1854776wxd for ; Tue, 19 Dec 2006 14:41:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KxwXq1JQOUzxaJcwII/0jlJxHu+oJNYgPlC2+8E7IRouPT/5VU3nUCkFZsRZqjZa1wAlbxPlL7uxRs/XatARihhiUbUsbJdq09d11w2p/VJLUsXtckaeedbMor6j47w8PCVi5m5XsmtvixBUtw8X/flFaFtLB9VkDwsUp9oEpX4= Received: by 10.90.90.16 with SMTP id n16mr6198984agb.1166568117081; Tue, 19 Dec 2006 14:41:57 -0800 (PST) Received: by 10.90.56.2 with HTTP; Tue, 19 Dec 2006 14:41:57 -0800 (PST) Message-ID: <6b9359640612191441w3ec5bdecqfe902ca18e29c19b@mail.gmail.com> Date: Tue, 19 Dec 2006 15:41:57 -0700 From: "Kyle Hamilton" To: martin.rex@sap.com Subject: Re: [TLS] Comments on TLS identity protection In-Reply-To: <200612192115.WAA22812@uw1048.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <86vek7pph4.fsf@raman.networkresonance.com> <200612192115.WAA22812@uw1048.wdf.sap.corp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 every renegotiation, does the server have to reauthenticate itself (present its certificate again)? Or can the credential on the client side be cached to avoid that duplication? -Kyle H On 12/19/06, Martin Rex wrote: > Eric Rescorla wrote: > > > > Good point. > > > > However, as you say in most cases the request for client auth > > is contingent upon seeing the request and so a rehandshake is > > required here in any case. A one-pass protocol wouldn't work > > here. > > Correct. > > I had the same thought but completely failed to point this out. > > In the not uncommon case with IIS renegotiating after having > evaluated the HTTP(S)-request, the one-pass protocol can not > be used. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > -- -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 17:45:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnhV-0000xy-5N; Tue, 19 Dec 2006 17:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwnhR-0000xg-G5 for tls@ietf.org; Tue, 19 Dec 2006 17:44:41 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwnhQ-0003lS-6y for tls@ietf.org; Tue, 19 Dec 2006 17:44:41 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id B40C01E8C5D; Tue, 19 Dec 2006 14:44:39 -0800 (PST) To: "Kyle Hamilton" Subject: Re: [TLS] Comments on TLS identity protection References: <86vek7pph4.fsf@raman.networkresonance.com> <200612192115.WAA22812@uw1048.wdf.sap.corp> <6b9359640612191441w3ec5bdecqfe902ca18e29c19b@mail.gmail.com> From: Eric Rescorla Date: Tue, 19 Dec 2006 14:44:39 -0800 In-Reply-To: <6b9359640612191441w3ec5bdecqfe902ca18e29c19b@mail.gmail.com> (Kyle Hamilton's message of "Tue, 19 Dec 2006 15:41:57 -0700") Message-ID: <868xh3pktk.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Kyle Hamilton" writes: > On every renegotiation, does the server have to reauthenticate itself > (present its certificate again)? Or can the credential on the client > side be cached to avoid that duplication? I don't think I understand the question. 1. You do a regular handshake with no client auth. 2. The server initiates a rehandshake with client auth. This has to be a full handshake with a new key exchange. Any future resumptions of the second session can be done out of cache. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 18:07:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwo3I-0004KL-Dd; Tue, 19 Dec 2006 18:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwo3I-0004KA-1m for tls@ietf.org; Tue, 19 Dec 2006 18:07:16 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwo3F-0007FL-M4 for tls@ietf.org; Tue, 19 Dec 2006 18:07:16 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id AAA23490; Wed, 20 Dec 2006 00:07:04 +0100 (MEZ) From: Martin Rex Message-Id: <200612192307.AAA25601@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection To: ekr@networkresonance.com Date: Wed, 20 Dec 2006 00:07:03 +0100 (MET) In-Reply-To: <868xh3pktk.fsf@raman.networkresonance.com> from "Eric Rescorla" at Dec 19, 6 02:44:39 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Eric Rescorla wrote: > > "Kyle Hamilton" writes: > > On every renegotiation, does the server have to reauthenticate itself > > (present its certificate again)? Or can the credential on the client > > side be cached to avoid that duplication? > > I don't think I understand the question. > > 1. You do a regular handshake with no client auth. > > 2. The server initiates a rehandshake with client auth. This has > to be a full handshake with a new key exchange. > > Any future resumptions of the second session can be done out > of cache. When the server-requested renegotiation is application triggered, as in the Microsoft IIS case, then the server better caches the result along with the SSL session. Microsoft IIS has a silly (performance-wasting) bug, where a client that does either not have a client cert or does not show one (and requiring the application to perform application level client authentication) is continously forced through the renegotiation when the client tries to resume the session from the session cache on a new connection. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 18:10:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwo6b-0005K5-Ke; Tue, 19 Dec 2006 18:10:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwo6a-0005Jz-GO for tls@ietf.org; Tue, 19 Dec 2006 18:10:40 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwo6Y-0008GF-S4 for tls@ietf.org; Tue, 19 Dec 2006 18:10:40 -0500 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id AAA57972 ; Wed, 20 Dec 2006 00:09:13 +0100 Received: from 86.72.162.216 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Wed, 20 Dec 2006 00:12:13 +0100 (CET) Message-ID: <61492.86.72.162.216.1166569933.squirrel@www.isima.fr> In-Reply-To: <86ejqvpl6s.fsf@raman.networkresonance.com> References: <20061219204505.5F2EE5C01E@laser.networkresonance.com><61434.86.72.162.216.1166567558.squirrel@www.isima.fr> <86ejqvpl6s.fsf@raman.networkresonance.com> Date: Wed, 20 Dec 2006 00:12:13 +0100 (CET) Subject: Re: [TLS] Comments on TLS identity protection From: badra@isima.fr To: "EKR" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Hi Eric, > Yes, but I don't think this really explains why the certificate > needs to be kept secret or why the double handshake technique isn't > good enough. IMHO, WiMAX and Wireless Networks operators that use TLS based-certificate have interests in providing alike GSM and UMTS modele for identity hiding. I CCed Joe Salowey who could have more arguments regarding the certificate hiding in WLAN and WiMAX using TLS. > The attacker performs a MITM attack with a valid certificate. > The TLS implementation completes the handshake and then prompts > the application to verify the certificate's identity against > the intended identity. This fails, but by this time the client > has already provided his certificate. Thank you. It is clear for me now. However, sentences will be added to the Security Considerations, in order for the client to check its understanding of the server hostname against the server's identity as presented in the server Certificate message. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 18:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwoiz-0005rL-7Y; Tue, 19 Dec 2006 18:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwoix-0005rE-Fb for tls@ietf.org; Tue, 19 Dec 2006 18:50:19 -0500 Received: from bay0-omc3-s14.bay0.hotmail.com ([65.54.246.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwoiw-00076m-MQ for tls@ietf.org; Tue, 19 Dec 2006 18:50:19 -0500 Received: from BAY103-W7 ([65.54.174.107]) by bay0-omc3-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 15:50:18 -0800 X-Originating-IP: [75.209.218.23] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Any advice regarding frequency of generating Date: Tue, 19 Dec 2006 15:50:18 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2006 23:50:18.0489 (UTC) FILETIME=[701F7690:01C723C8] X-Spam-Score: 2.4 (++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1936717424==" Errors-To: tls-bounces@lists.ietf.org --===============1936717424== Content-Type: multipart/alternative; boundary="_f9d64e8b-09c5-47d5-95af-6cc842b8af81_" --_f9d64e8b-09c5-47d5-95af-6cc842b8af81_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, Ive now read the whole TLS 1.0 document very carefully (dont laugh, it = was published in 1999, but only now made default for most internet consumers), and that novel section = specifically about 10 times. =20 Neither ephemeral RSA nor the IETF_endorsed export regime of RSAEXPORT were= part of SSLv3. its a bid sad to see certain IETF luminaries be a part of restricting RSA in th= at way, in its TLS 1.0 standard. =20 (1) we can interpret the phrase "not legal" in technical terms of the IETF = material, by considering:- export_restriction A negotiation not in compliance with export res= trictions was detected; for example, attempting to transfer a 1024 bi= t ephemeral RSA key for the RSA_EXPORT handshake method. This m= essage is always fatal. Creation of this error by either client or server means: "Servers and clien= ts are required to forget any session-identifiers, keys, and secrets as= sociated with a failed connection." =20 In US corporations, "forget" means exactly the opposite of its popular mean= ing: it means=20 store all the data in the corporate data rentention logs even more carefull= y than normally, given its good basis for suspecting criminal violation of export laws.=20 =20 (2) its clearly true that TLS 1.0 has ephemeral RSA. And, its in the right = section of the protocol machine, logically. However, the overall text looks poor for t= he RSA use cases,=20 as if RSA_EXPORT was retrofitted at a late stage into text that looks even = better formulated=20 for the DH use cases that the SSL3 original text.=20 =20 Now TLS does say:- =20 "Following the hello messages, the server will send its certificate, if i= t is to be authenticated. Additionally, a server key exchange message may= be sent, if it is required (e.g. if their server has no certificate, or = if its certificate is for signing only)." =20 Thus SSL server endpoints without PKI certs are clearly allowed. and the ke= y exchange message is *required*, if the server has no cert. =20 Furthermore, in formal conformance testing terms, the RSAEXPORT controls on= the server only=20 apply to those servers that have a server cert, given this provides the con= trol signal (by inspecting the=20 public key modulus len). TLS status no limits about the case we are interes= ted in, and actually specifies no controls on how RSAEXPORT is to be handled there,= when limiting ephemeral key gen, and issuance of error alerts. =20 In terms of what I said to Mike, thus, in TLS1.0 protocol for RSA ephemeral= , Id now say that one=20 creates ephemeral RSA __under endpoint controls__, rather than PKI control = limits, when=20 (1) responding to an anon-capable ciphersuite, and (2) one does not perform= server cert auth, as no=20 cert is configured =20 IN commercial systems (vs military systems), servers can be configured to "= view" themselves as having no server cert for any reason the designer selects. This is the s= ame logic in product design as when handling RSA EKU controls, for certs that have only Signing = EKU. If someone send=20 you an encrypted email cleartitled "hi Peter: bomb threat in building 8" us= ing your RSA key in key transport=20 mode, of course you use the (privileged) software config mode to overide th= e EKU rule...and use RSA=20 to decrypt the damn thing. =20 > From: martin.rex@sap.com> Subject: Re: [TLS] Any advice regarding frequen= cy of generating> To: home_pw@msn.com> Date: Tue, 19 Dec 2006 21:04:45 +010= 0> CC: tls@ietf.org> > Peter Williams wrote:> > > > Martin:> >> > RSA ephem= eral is not "prohibited". Is not standardized, thats true.> > They are stan= dardized and required for SSL ciphersuites with the> RSA_EXPORT key exchang= e method when a Server cert with an> RSA key >512 bit is being used.> > quo= ting rfc2246 (tls v1.0) 7.4.3. Server key exchange message:> > When this me= ssage will be sent:> This message will be sent immediately after the server= > certificate message (or the server hello message, if this is an> anonymou= s negotiation).> > The server key exchange message is sent by the server on= ly when> the server certificate message (if sent) does not contain enough> = data to allow the client to exchange a premaster secret. This is> true for = the following key exchange methods:> > RSA_EXPORT (if the public key in the= server certificate is> longer than 512 bits)> DHE_DSS> DHE_DSS_EXPORT> DHE= _RSA> DHE_RSA_EXPORT> DH_anon> > It is not legal to send the server key exc= hange message for the> following key exchange methods:> > RSA> RSA_EXPORT (= when the public key in the server certificate is> less than or equal to 512= bits in length)> DH_DSS> DH_RSA> > > rfc2246 says "It is not legal" to use= ephemeral RSA for ciphersuites> with the RSA key exchange method. And whil= e the first part at least> mentions the possibility of sign-only RSA keys, = the second part> completely ignores them.> > What is that supposed to mean = anyway? "Not legal (under some jurisdictions?)> but well within the spec" o= r "MUST NOT send/use" in spec language?> > > >> > With Russ's non-repudiati= on proposal, a TLS session can be a form of> > signature.> > Btw. I complet= ely and thoroughly dislike Russ' proposal for non-repudiation> (he used the= disguise terminology "evidence" though), both from a> technical standpoint= , as well as from a "political" perspective.> > -Martin>=20 _________________________________________________________________ Try amazing new 3D maps http://maps.live.com/?wip=3D51= --_f9d64e8b-09c5-47d5-95af-6cc842b8af81_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, Ive now read the whole TLS 1.0 document very carefully (dont laug= h, it was published in 1999, but
only now made default for most internet consumers), and that novel section = specifically about 10 times.
 
Neither ephemeral RSA nor the IETF_endorsed export regime of RSAEXPORT were= part of SSLv3. its
a bid sad to see certain IETF luminaries be a part of restricting RSA = in that way, in its TLS 1.0 standard.
 
(1) we can interpret the phrase "not legal" in technical terms of the IETF = material, by considering:-

   export_restriction
      = A negotiation not in compliance with export restrictions was
 &nbs= p;     detected; for example, attempting to transfer a = 1024 bit
       ephemeral RSA key for the = RSA_EXPORT handshake method. This
       m= essage is always fatal.

Creation of this error by either client or server means: "Servers and clien= ts are
   required to forget any session-identifiers, keys, an= d secrets
   associated with a failed connection."
 
In US corporations, "forget" means exactly the opposite of its popular mean= ing: it means
store all the data in the corporate data rentention logs even more carefull= y than normally, given
its good basis for suspecting criminal violation of export laws.
 
(2) its clearly true that TLS 1.0 has ephemeral RSA. And, its in the right = section of
the protocol machine, logically. However, the overall text looks poor for t= he RSA use cases,
as if RSA_EXPORT was retrofitted at a late stage into text that looks = even better formulated
for the DH use cases that the SSL3 original text.
 
Now TLS does say:-
 
"Following the hello messages, the server will send its certificate,
&nb= sp;  if it is to be authenticated. Additionally, a server key exchange=
   message may be sent, if it is required (e.g. if their serv= er has no
   certificate, or if its certificate is for signing= only)."
 
Thus SSL server endpoints without PKI certs are clearly allowed. and the ke= y exchange
message is *required*, if the server has no cert.
 
Furthermore, in formal conformance testing terms, the RSAEXPORT controls on= the server only
apply to those servers that have a server cert, given this provides the con= trol signal (by inspecting the
public key modulus len). TLS status no limits about the case we are interes= ted in,
and actually specifies no controls on how RSAEXPORT is to be handled there,= when limiting
ephemeral key gen, and issuance of error alerts.
 
In terms of what I said to Mike, thus, in TLS1.0 protocol for RSA ephemeral= , Id now say that one
creates ephemeral RSA __under endpoint controls__, rather than PKI control = limits, when
(1) responding to an anon-capable ciphersuite, and (2) one does not pe= rform server cert auth, as no
cert is configured
 
IN commercial systems (vs military systems), servers can be configured to "= view" themselves
as having no server cert for any reason the designer selects. This is the s= ame logic in product
design as when handling RSA EKU controls, for certs that have only Sig= ning EKU. If someone send
you an encrypted email cleartitled "hi Peter: bomb threat in building 8" us= ing your RSA key in key transport
mode, of course you use the (privileged) software config mode to overide th= e EKU rule...and use RSA
to decrypt the damn thing.
 

> From: martin.rex@sap.com
> Subject: Re: [TLS] Any advice regardi= ng frequency of generating
> To: home_pw@msn.com
> Date: Tue, 1= 9 Dec 2006 21:04:45 +0100
> CC: tls@ietf.org
>
> Peter W= illiams wrote:
> >
> > Martin:
> >
> >= RSA ephemeral is not "prohibited". Is not standardized, thats true.
>= ;
> They are standardized and required for SSL ciphersuites with the=
> RSA_EXPORT key exchange method when a Server cert with an
> = RSA key >512 bit is being used.
>
> quoting rfc2246 (tls v1= .0) 7.4.3. Server key exchange message:
>
> When this message = will be sent:
> This message will be sent immediately after the serve= r
> certificate message (or the server hello message, if this is an> anonymous negotiation).
>
> The server key exchange mes= sage is sent by the server only when
> the server certificate message= (if sent) does not contain enough
> data to allow the client to exch= ange a premaster secret. This is
> true for the following key exchang= e methods:
>
> RSA_EXPORT (if the public key in the server cer= tificate is
> longer than 512 bits)
> DHE_DSS
> DHE_DSS_E= XPORT
> DHE_RSA
> DHE_RSA_EXPORT
> DH_anon
>
&g= t; It is not legal to send the server key exchange message for the
> = following key exchange methods:
>
> RSA
> RSA_EXPORT (wh= en the public key in the server certificate is
> less than or equal t= o 512 bits in length)
> DH_DSS
> DH_RSA
>
>
&g= t; rfc2246 says "It is not legal" to use ephemeral RSA for ciphersuites
= > with the RSA key exchange method. And while the first part at least> mentions the possibility of sign-only RSA keys, the second part
&g= t; completely ignores them.
>
> What is that supposed to mean = anyway? "Not legal (under some jurisdictions?)
> but well within the = spec" or "MUST NOT send/use" in spec language?
>
>
> &g= t;
> > With Russ's non-repudiation proposal, a TLS session can be = a form of
> > signature.
>
> Btw. I completely and th= oroughly dislike Russ' proposal for non-repudiation
> (he used the di= sguise terminology "evidence" though), both from a
> technical standp= oint, as well as from a "political" perspective.
>
> -Martin>


Try amazing new 3D maps Check it out! = --_f9d64e8b-09c5-47d5-95af-6cc842b8af81_-- --===============1936717424== 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 --===============1936717424==-- From tls-bounces@lists.ietf.org Tue Dec 19 19:34:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwpPU-00010L-7M; Tue, 19 Dec 2006 19:34:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwpPS-0000yP-Qj for tls@ietf.org; Tue, 19 Dec 2006 19:34:14 -0500 Received: from bay0-omc1-s35.bay0.hotmail.com ([65.54.246.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwpPR-0006Zh-7u for tls@ietf.org; Tue, 19 Dec 2006 19:34:14 -0500 Received: from BAY103-W5 ([65.54.174.105]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 16:34:12 -0800 X-Originating-IP: [75.209.237.5] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Kyle Hamilton , Subject: RE: [TLS] Comments on TLS identity protection Date: Tue, 19 Dec 2006 16:34:12 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 00:34:12.0746 (UTC) FILETIME=[92432EA0:01C723CE] X-Spam-Score: 2.6 (++) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2042951221==" Errors-To: tls-bounces@lists.ietf.org --===============2042951221== Content-Type: multipart/alternative; boundary="_75348ccd-77dc-406d-8788-bffcd0c83b58_" --_75348ccd-77dc-406d-8788-bffcd0c83b58_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Id say the nth handshake can select to send "no server cert" whenever its=20 cooperating to complete an anonymous-ciphersuite-targeted handshake. So, assume there are only two ciphers suite values in the HSM : RSA, RSA-AN= ON.=20 on handshake 1, changecipherspec completes session state using RSA-derived master keying, having used/sent a server cert.=20 =20 On the second handshake, the server can no constrain the negotiation of cip= hersuites=20 to only offer only RSA-ANON. If the client accepts, if is accepting the pos= sibility of=20 no server auth (via certs).=20 =20 Of course, the second handshake is conducted within the SA of the first...= =20 which may well authenticate the server's public key anyways, without using certs for that function, enough to validate the signature on the=20 server key agreement message. Thius is consitent with IETF's RFC 1421=20 practices, using public keys (only) from previous certificate-based session= s. Now, I'm delighted to be corrected on this, in theory or actual practice i= n=20 commodity internet products. TLS's 1.0 "minor" changes to SSLv3 are still= =20 new to me. I never bothered to read the TLS 1.0=20 document carefully enough before, thus failing to recognize the notions=20 of anon-ciphersuites, export-controlled key agreement , and its new fatal=20 exception modes. =20 now IETF has endorsed the notion of RSA ephemeral, we just dump the export control policy and exploit it! =20 Im going to read TLS 1.1 much more carefully tomorrow. Ill try to backtrack any new control policy developments through TLS1.0 and back to SSL3. Im half hoping IETF already dumped RSA_EXPORT as arcane, or at least increased the key length after 6 years! =20 > Date: Tue, 19 Dec 2006 15:41:57 -0700> From: aerowolf@gmail.com> To: mart= in.rex@sap.com> Subject: Re: [TLS] Comments on TLS identity protection> CC:= tls@ietf.org> > On every renegotiation, does the server have to reauthenti= cate itself> (present its certificate again)? Or can the credential on the = client> side be cached to avoid that duplication?> > -Kyle H> > On 12/19/06= , Martin Rex wrote:> > Eric Rescorla wrote:> > >> > > = Good point.> > >> > > However, as you say in most cases the request for cli= ent auth> > > is contingent upon seeing the request and so a rehandshake is= > > > required here in any case. A one-pass protocol wouldn't work> > > her= e.> >> > Correct.> >> > I had the same thought but completely failed to poi= nt this out.> >> > In the not uncommon case with IIS renegotiating after ha= ving> > evaluated the HTTP(S)-request, the one-pass protocol can not> > be = used.> >> > -Martin> >> > _______________________________________________> = > TLS mailing list> > TLS@lists.ietf.org> > https://www1.ietf.org/mailman/l= istinfo/tls> >> > > -- > > -Kyle H> > _____________________________________= __________> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mai= lman/listinfo/tls _________________________________________________________________ Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. www.live.com/?addtemplate=3Dholiday= --_75348ccd-77dc-406d-8788-bffcd0c83b58_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Id say the nth handshake can select to send "no server cert" when= ever its
cooperating to complete an anonymous-ciphersuite-targeted handshake.
So, assume there are only two ciphers suite values in the HSM : RSA, RSA-AN= ON.
on handshake 1, changecipherspec completes session state using RSA-derived<= BR> master keying, having used/sent a server cert.
 
On the second handshake, the server can no constrain the negotiation of cip= hersuites
to only offer only RSA-ANON. If the client accepts, if is accepting the pos= sibility of
no server auth (via certs).
 
Of course, the second handshake is conducted within the SA of the first... =
which may well authenticate the server's public key anyways, without
using certs for that function, enough to validate the signature on the
server key agreement message. Thius is consitent with IETF's RFC 1421
practices, using public keys (only) from previous certificate-based session= s.

Now, I'm delighted to be corrected on this, in theory or  actual pract= ice in
commodity internet products. TLS's 1.0 "minor" changes to  SSLv3 are s= till
new to me. I never bothered to read the TLS 1.0
document carefully enough before, thus failing to recognize the notions of anon-ciphersuites, export-controlled key agreement , and its new fa= tal
exception modes.
 
now IETF has endorsed the notion of RSA ephemeral, we just dump
the export control policy and exploit it!
 
Im going to read TLS 1.1 much more carefully tomorrow. Ill try
to backtrack any new control policy developments through TLS1.0
and back to SSL3. Im half hoping IETF already dumped RSA_EXPORT
as arcane, or at least increased the key length after 6 years!
 

> Date: Tue, 19 Dec 2006 15:41:57 -0700
> From: aerowolf@gmail.com=
> To: martin.rex@sap.com
> Subject: Re: [TLS] Comments on TLS = identity protection
> CC: tls@ietf.org
>
> On every rene= gotiation, does the server have to reauthenticate itself
> (present i= ts certificate again)? Or can the credential on the client
> side be = cached to avoid that duplication?
>
> -Kyle H
>
>= On 12/19/06, Martin Rex <martin.rex@sap.com> wrote:
> > Eri= c Rescorla wrote:
> > >
> > > Good point.
> &= gt; >
> > > However, as you say in most cases the request fo= r client auth
> > > is contingent upon seeing the request and s= o a rehandshake is
> > > required here in any case. A one-pass = protocol wouldn't work
> > > here.
> >
> > Co= rrect.
> >
> > I had the same thought but completely fail= ed to point this out.
> >
> > In the not uncommon case wi= th IIS renegotiating after having
> > evaluated the HTTP(S)-reques= t, the one-pass protocol can not
> > be used.
> >
>= > -Martin
> >
> > ___________________________________= ____________
> > TLS mailing list
> > TLS@lists.ietf.org<= BR>> > https://www1.ietf.org/mailman/listinfo/tls
> >
>= ;
>
> --
>
> -Kyle H
>
> _________= ______________________________________
> TLS mailing list
> TLS= @lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

<= br />
Get the Live.com Holiday Page for recipes, gift-giving ideas, an= d more. Che= ck it out! = --_75348ccd-77dc-406d-8788-bffcd0c83b58_-- --===============2042951221== 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 --===============2042951221==-- From tls-bounces@lists.ietf.org Tue Dec 19 19:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwpbF-00089U-16; Tue, 19 Dec 2006 19:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwpbD-00089F-OQ for tls@ietf.org; Tue, 19 Dec 2006 19:46:23 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwpbC-0001Io-DY for tls@ietf.org; Tue, 19 Dec 2006 19:46:23 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5D46C1E8C5D; Tue, 19 Dec 2006 16:46:21 -0800 (PST) To: Peter Williams Subject: Re: [TLS] Comments on TLS identity protection References: From: Eric Rescorla Date: Tue, 19 Dec 2006 16:46:21 -0800 In-Reply-To: (Peter Williams's message of "Tue, 19 Dec 2006 16:34:12 -0800") Message-ID: <86mz5jo0ma.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Williams writes: > Id say the nth handshake can select to send "no server cert" whenever its > cooperating to complete an anonymous-ciphersuite-targeted handshake. > So, assume there are only two ciphers suite values in the HSM : RSA, RSA-ANON. There is no such thing as RSA anon in SSLv3 or TLS. > Now, I'm delighted to be corrected on this, in theory or actual practice in > commodity internet products. TLS's 1.0 "minor" changes to SSLv3 are still > new to me. I never bothered to read the TLS 1.0 > document carefully enough before, thus failing to recognize the notions > of anon-ciphersuites, export-controlled key agreement , and its new fatal > exception modes. Huh? Nearly all of this stuff was in SSLv3--I don't know what "new fatal exception modes" are but fatal exceptions were totall in SLv3. > Im going to read TLS 1.1 much more carefully tomorrow. Ill try > to backtrack any new control policy developments through TLS1.0 > and back to SSL3. Im half hoping IETF already dumped RSA_EXPORT > as arcane, or at least increased the key length after 6 years! TLS 1.1 forbids negotiating the RSA_EXPORT cipher suites. See A.5 of RFC 4346: When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 19 21:49:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwrW2-0004ND-KR; Tue, 19 Dec 2006 21:49:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwrW1-0004N8-PH for tls@ietf.org; Tue, 19 Dec 2006 21:49:09 -0500 Received: from bay0-omc2-s24.bay0.hotmail.com ([65.54.246.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwrVz-0001Ms-6k for tls@ietf.org; Tue, 19 Dec 2006 21:49:09 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc2-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 18:49:06 -0800 X-Originating-IP: [75.209.237.5] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams Date: Tue, 19 Dec 2006 18:49:06 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 02:49:06.0748 (UTC) FILETIME=[6AA9DFC0:01C723E1] X-Spam-Score: 2.4 (++) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: tls@ietf.org Subject: [TLS] duplication session with GSSAPI PRF 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="===============1334057082==" Errors-To: tls-bounces@lists.ietf.org --===============1334057082== Content-Type: multipart/alternative; boundary="_75a31cb3-3ab8-499e-9179-c220b98cbd70_" --_75a31cb3-3ab8-499e-9179-c220b98cbd70_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been updating my personal code base, trying to accomplish a conforming= TLS1.0 whilst also=20 experimenting in line with the conversation on what the GSS API I-D actuall= y says or may imply (ignoring the kerberos backstory). =20 Lets say the first connection uses the proposed GSSAPI handshake , creating= partial session state. Per the=20 documented negotiation and payloads, a pre-master secret is created using t= he API's PRF, based on the various GSS Tokens.. Im not sure what happened to the ClientKeyExchange Mes= sage. Is it sent? Presumably=20 not... given there is no point: its function already happened in the GSSAPI= token exchange. If it is sent, what is the value? (See below.) =20 Presumably, another "GSS_API call" is then made to generate a master key fo= r the proposed connection. This=20 may do the same calculation as for RSA/DH/Fortezza, or not. Perhaps the val= ue is read from an existing GSSAPI token? Both GSS peers obviously can do this, upon explicit or implie= d ClientKeyExchange. =20 Another API call is presumably used by each party to use the masterkey as s= eed to generate the TLS=20 Connection values., using the Hello nonces. The premaster secret is then de= stroyed (as are any means of=20 regenerating it), per requirements. =20 When now we encrypt or mac records once the session status is active, where= we presumably also make GSSAPI calls to encrypt/mac the records, using GSSAPI like a general = CSP. =20 --- =20 OK, I now duplicate that active connection (session state and connect state= , but no API tokens/handles), attempting to=20 create a parallel TLS connection, updating the read/write state. I thus sen= d or respond with a client hello, with the current active=20 sessionid, and new nonce. Per the rules, my client performs the session dup= lication/resumption flow. The socket directs the output over "some reliable byte channel" =20 At this point I have no API tokens or API handles, to rebuild access to my = GSSAPI session. Lets say I can=20 somehow make a new handle to GSS, and from the masterkey alone, GSS gives m= e (a) a function to generate=20 some new connection state according to the SSL algorithm (including export = rules, nonce inputs), and (b) a handle to a CSP-like object, so I can encrypt/mac on each of the connection read/w= rite states, as we move to final message exchanges on the resuming session (with new connection state)= . -------- =20 1., Do I have the right mental model, yet? Im not sure whether or not the p= roposal is intending to use the negotiated GSS mechanism *set* fully, or JUST the PRF element of whatever mechanisms a= re indicated? I.e. is GSSAPI becoming a general=20 schannel-like CSP? =20 2. The I-D implies that ClientKeyExchange message DOES flow. Im just not su= re what is in it, and is it dependent on the=20 GSSAPI mechanism that was negotiated? Does it convey an opaque token from t= he GSS Handshake flow?=20 =20 It doesnt seem to need to, given at an earlier point all is finished: "Afte= r successful completion of the=20 gss_token messages,...the client and server each obtain 46 bytes of key ran= dom data using the GSS-API PRF.=20 This data is the TLS pre-master secret."=20 =20 Perhaps it ALWAYS simply indicates "gss_prf", with zero parameters? =20 Peter. _________________________________________________________________ Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. www.live.com/?addtemplate=3Dholiday= --_75a31cb3-3ab8-499e-9179-c220b98cbd70_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been updating my personal code base, trying to accomplish a conf= orming TLS1.0 whilst also
experimenting in line with the conversation on what the GSS API I-D actuall= y says or may imply
(ignoring the kerberos backstory).
 
Lets say the first connection uses the proposed GSSAPI handshake , creating= partial session state. Per the
documented negotiation and payloads, a pre-master secret is created using t= he API's PRF, based on the
various GSS Tokens.. Im not sure what happened to the ClientKeyExchange Mes= sage. Is it sent? Presumably
not... given there is no point: its function already happened in the GSSAPI= token exchange. If it is sent,
what is the value? (See below.)
 
Presumably, another "GSS_API call" is then made to generate a master key fo= r the proposed connection. This
may do the same calculation as for RSA/DH/Fortezza, or not. Perhaps the val= ue is read from an existing
GSSAPI token? Both GSS peers obviously can do this, upon explicit or implie= d ClientKeyExchange.
 
Another API call is presumably used by each party to use the masterkey as s= eed to generate the TLS
Connection values., using the Hello nonces. The premaster secret is then de= stroyed (as are any means of
regenerating it), per requirements.
 
When now we encrypt or mac records once the session status is active, where= we presumably also
make GSSAPI calls to  encrypt/mac the records, using GSSAPI like a gen= eral CSP.
 
---
 
OK, I now duplicate that active connection (session state and connect state= , but no API tokens/handles), attempting to
create a parallel TLS connection, updating the read/write state. I thus sen= d or respond with a client hello, with the current active
sessionid, and new nonce. Per the rules, my client performs the session dup= lication/resumption flow. The
socket directs the output over "some reliable byte channel"
 
At this point I have no API tokens or API handles, to rebuild access to my = GSSAPI session. Lets say I can
somehow make a new handle to GSS, and from the masterkey alone, GSS gives m= e (a) a function to generate
some new connection state according to the SSL algorithm (including export = rules, nonce inputs), and (b) a handle
to a CSP-like object, so I can encrypt/mac on each of the connection read/w= rite states, as we move to
final message exchanges on the resuming session (with new connection state)= .
--------
 
1., Do I have the right mental model, yet? Im not sure whether or not the p= roposal is intending to use the negotiated
GSS mechanism *set* fully, or JUST the PRF element of whatever mechanisms a= re indicated? I.e. is GSSAPI becoming a general
schannel-like CSP?
 
2. The I-D implies that ClientKeyExchange message DOES flow. Im just not su= re what is in it, and is it dependent on the
GSSAPI mechanism that was negotiated? Does it convey an opaque token f= rom the GSS Handshake flow?
 
It doesnt seem to need to, given at an earlier point all is finished: "Afte= r successful completion of the
gss_token messages,...the client and server each obtain 46 bytes of key ran= dom data using the GSS-API PRF.
This data is the TLS pre-master secret."
 
Perhaps it ALWAYS simply indicates "gss_prf", with zero parameters?
 
Peter.

Get the Live.com Holiday Page for recipes, gift-givin= g ideas, and more. Check it out! = --_75a31cb3-3ab8-499e-9179-c220b98cbd70_-- --===============1334057082== 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 --===============1334057082==-- From tls-bounces@lists.ietf.org Wed Dec 20 01:00:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwuUE-0007UV-GX; Wed, 20 Dec 2006 00:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwuUC-0007UH-Ty for tls@ietf.org; Wed, 20 Dec 2006 00:59:28 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwuUB-0000Dl-9P for tls@ietf.org; Wed, 20 Dec 2006 00:59:28 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id C50938110; Tue, 19 Dec 2006 23:59:21 -0600 (CST) From: "Mark Brown" To: "'EKR'" , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 20 Dec 2006 00:00:47 -0600 Message-ID: <006701c723fc$31a55cc0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <86ac1jr4jb.fsf@raman.networkresonance.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+g X-Spam-Score: 1.1 (+) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c 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, Thank you for your insight into technical weaknesses of the draft. I tried to address these inline, below. More broadly though, Why introduce evidence to TLS? Why ask for a WG charter extension for evidence? I need to give an argument (below) to answer these Why questions. Please bear with me. First, applications defer to TLS for good reason. The essay "Programming Satan's Computer" (Anderson & Needham, 1995) makes it clear that devising and implementing cryptographic protocols is difficult. TLS is so simple to use and ubiquitous that any user/anywhere can get a good secure socket when connecting to a TLS server. TLS hides from the user years of protocol design, analysis and cryptanalysis, all of which is hard. It is a brand that users trust because TLS simply delivers good security for sockets while following an "It better just drop in and work" layered model. (SSL was a good name.) The "users" of TLS are not just people who use web browsers. TLS users are also the numerous application-level programs and programmers that depend on TLS to do the heavy lifting, implementing a cryptographic protocol in a Known Good way. Constructing digital evidence so that it deters frivolous repudiation in a legal setting is similarly difficult. In legal settings users need evidence -- not hearsay nor impossible "burdens of proof." Moreover, what really benefits users is evidence that any user/anywhere can read and interpret (even lawyers). Numerous past attempts have failed, and digital evidence is still a hotly contested topic of debate among expert lawyers. Sure, every bit of data is evidence at the start of a legal contest, but when challenged, data often becomes worthless to the case -- or gets thrown out. While on the one hand lawyers are now crying for standard, open (did I mention nonproprietary?) ways to create digital evidence, on the other hand many relevant standards remain unread, unimplemented and unused (e.g. PKIX, but many other standards specify digital signature methods too). You said well at USENIX 2003 much of what I'm repeating here. Why should we consider digital evidence a hard problem, a crypto protocol problem, a TLS problem? One crucial issue was raised by Steven Kent last year: the problem of the recording the signer's intent. Just to be clear, "signer's intent" problems include not only the challenge of recording something intangible, or the possibility that garbage data was signed, but also claims that the system that created the digital signature was subverted - or used with an intention to defraud. I'm a newcomer to this party, but I don't think any previous standard solves this problem (I don't count the NR bit as solving the problem). Let us know... After pointing out this unsolved problem for constructors of digital evidence, Kent then affirmed the convention of delegating this seemingly intractable problem to the application layer. "Signing things for non-repudiation is usually an application-layer issue..." (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty sensible approach, I think. But to be perfectly honest, isn't "application layer" here a code word for "let them figure it out, we're not going to waste any more time on this problem"? But now TLS Evidence can solve the "signer's intent" problems, and it requires two parties, implying a network protocol connecting two parties. Or, I should say more conservatively, if TLS Evidence solves the signer's intent problems then I'd like to ask TLS WG to expand its charter to address evidence. Or better yet, would you all consider TLS Evidence to see if it solves the "signer's intent" problems? The solution to signer's intent lies in two parties using TLS Evidence together with TLS Authorizations (see -01, 4.2. EvidenceRequest Message, field handshake_protocol_hash, pp 12-13). If the handshake contains TLS Authorizations that gain one party "access" then the record of that handshake proves that the session was authorized-for something specific. Whatever that something specific is, that's the stated intent for this session. Both parties agree to it -- one said "Authorize me to do this" and the other said, "Ok, I agree." If they don't agree, the session's over before the handshake FINISHED pair. Pick any example you want: authorized to do online banking for my account; authorized to vote; authorized to read email; authorized to post to a blog; etc. There is more to say about this... But the main point is this: Authorization always seems to clarify intent, that is, the intent of both parties. I think it's baked into the definition of authorization somehow. (I'm happy to discuss this more.) To sum up, I agree that evidence is not currently part of the WG charter, it's new, and deserves questioning like this. I have proposed in TLS Evidence the solution to a hard problem and, as I see it, the solution necessarily lives in a cryptographic protocol. I think it fits well with TLS successes as both easy to use and as hiding the challenges of standardizing a cryptographic protocol well. But it's no doubt a change in the WG charter. Now it's up to the WG to answer our request that the charter be expanded. On to your comments. Pertaining to signer's intent, you raised this question: > S 1. > It looks like the evidence creation has to involve signatures by > both parties. Why not have it be one-way. My reasons for two signatures (countersignature) include: 1. Take as an example a military case where a Common Criteria EAL6 TLS server and a non-evaluated TLS client exchange TLS Evidence. If only the client signs it, how much assurance do we have that the evidence is correct? None under the Common Criteria. But if the client asserts it and the EAL6 server countersigns it (using EvidenceResponse under TLS Evidence) now we have "high assurance" for the evidence, which both client and server can retain. In this scenario, the low-assurance party obtains high-assurance evidence just because it participated with a high-assurance server. I call this "assurance bootstrapping," and it can be a valuable service to the client. I think this argument still carries the same weight even if the server is Known Good under some other current or future evaluation system (open source, peer review, etc.). 2. What if in the scenario above the transmission is the acceptance of a relatively small contract that, in its fine print, grants a huge amount of intellectual property rights to the military? And later the contractor wants to repudiate the signature, claiming that the transaction was a forgery? (This illustration is completely fictional.) If only the high-assurance server signed the evidence then the contractor can say that someone else initiated that transaction, and the burden of proof rests on the military. But if the contractor chose his own key pair, and registered his own PKC, and used that registered PKC to sign EvidenceRequest under TLS Evidence it's harder to repudiate frivolously. Especially if the contractor's PKC uses crypto stronger than the military can crack. 3. At a high level, two different parties signing the same thing forges an agreement -- both intrinsically and historically speaking. TLS Evidence proposes a standard for how to agree before evidence is born. This includes: the handshake must have worked (and all that this implies). The evidence suite must have been used with mathematical precision, so the encrypted and hashed outputs are correct. The timestamp must be acceptable to both parties. And so on. Successful TLS handshakes, especially when coupled with other TLS extensions such as TLS Authorizations as I've mentioned, can be used to forge really specific agreements using TLS Evidence. If we don't require two parties to sign, everything having to do with agreement over evidence drops out of the picture. This emphasis on agreement is not foreign to TLS, and I hope others agree that the use of agreement in the core TLS handshake(s) over the years has been a strong security practice. I think agreement between client and server is a strong card to play for evidence as well. > Why not just store the traffic keys? No smoking gun stands out to me as I try to explain why session-key-encrypted application data proves the identity of both parties. Following your book I can see how to derive the session key if I have all the right inputs, but working backwards from session key to identities seems harder. I take this to mean you'd need to hire a crypto expert (or TLS expert) to explain it in court. This is all well and good in today's legal environment where that's the norm when you deal with data, but I'd like to propose a standard that makes cryptographic protocols EASY for the user. For evidence, "It better just drop in and work" in the courtroom, for that user too. For evidence, the user may be some small business that needs to encourage a huge organization to honor a deal they "inked" using TLS. If a small business owner can do a simple cryptographic verify operation on TLS Evidence structures using free tools and his own retained records, and if what he sees using freeware on a commodity computer will stand up to fierce scrutiny in court, then I think we've created evidence worthy of the TLS brand. In fact, that easy-to-use evidence may enable that small business owner to prevail in an out-of-court settlement, which benefits everyone. With current and proposed TLS handshake extensions, the variety of authentication and key derivation methods, and the indirect linkage between a session key and the client & server identities, I guess it would be hard to write a universal TLS evidence viewer that produced a smoking gun. Especially if that viewer software must operate with high assurance, say for example, if the evidence is for a vote in an election recount situation. I'm not complaining, and I'm not opposed to others doing this. I just think that even if the traffic keys "work" at a crypto level they are complex enough to not be useful to a wide range of evidence users (and specifically lawyers and juries without hiring an expert). > ARCHITECTURAL COMMENTS > I'm not particularly enamored of this general approach. The > signatures in question are fundamentally an application-level > construct: they're requested by the applications and > ultimately consumed by them. I think of evidence like old tax returns. You are supposed to keep them for some number of years, so you file them in the garage/basement. The last time you read any of them was when you last signed them, except in special cases where having the old tax return proved really valuable. In my view, TLS layer checks the TLS Evidence as required by the Internet Draft, refuses the bad evidence, and writes the good evidence to a box in the garage (using some configuration flag at the TLS layer). Let me clarify expected operation. TLS Evidence requires participants to store evidence, and it requires configuration -- selecting targets -- before it starts creating evidence, but it does not require application interaction. The usage model I anticipate for TLS Evidence is default do-nothing. Until client (and server) both configure to client authenticate and to demand evidence when accessing specific domains/URIs, then nothing happens. TLS Evidence isn't something one party can demand with no warning, or from a stranger. Once the TLS layer is configured to demand evidence in some cases, now the app layer wants to see no traffic (for those cases) unless the traffic passes the TLS Evidence tests. It is an unwarranted prejudice to hold that digital signatures must be application-level constructs. (Just solve the signer's intent problem though...) I believe and fully expect that the application layer doesn't want to have to check or otherwise process evidence - it wants TLS to do that since it's a Difficult Crypto Problem. If TLS can create evidence, then apps will shed the responsibility. It simply costs the app too much to invent its own crypto implementations and then adequately test them. TLS has quietly bubbled up to preferred status on many occasions; I can think of some Web Services standards that go into detail to explain how to do crypto and then tack on, "and TLS does this too and that's a good approach." > The only real reason to do > this at the TLS layer is the sense that it's easier to deploy. I disagree. The reason an app wants TLS to solve a Difficult Crypto Problem is the raison d'etre of TLS. TLS makes the crypto problems easy (for the app), is a Known Good Way, and can handle the responsibilities of key management & crypto. More than anything TLS is tested and approved. Apps can't duplicate this without great cost. > I'm not actually convinced that that's so, since this approach > still requires modifying the applications to request security > the signature/evidence services. > > In addition, putting this functionality at the TLS layer embodies > some not-so-attractive tradeoffs, in particular, that the > binding of application-layer messages to the actual evidence > provided isn't particularly tight, since the signatures cover extents > of the traffic rather than messages. This introduces a number of > race conditions which are only partially solved by the > interlocking alerts used here. Among these are: > > - The sender of the start1 alert has only minimal > information/control over when the peer will start signing traffic. > - It's quite likely that one side will have to process messages > without knowing whether the peer will actually sign his > section of the traffic. This is obviously a problem if you > are producing side effects. You can mitigate this problem > only by doing two evidence collections in lockstep. > - Applications need a bunch of new logic to detect the evidence > request but hold their response to application-layer boundaries. > This cannot be implemented at the TLS layer. > - If you want to condition your application-layer responses > to whether the peer provided a signature you need some way > to provide application-layer "please resend with signature". > This is a common case but can only be dealt with very > clumsily here. Some of these scenarios seem incongruous with mutual authentication and some form of TLS Authorization (as recommended in TLS Evidence). Please give more information about the scenarios you are thinking of here. > > This seems like a fairly large architectural change to TLS to > make it do something it was never designed to do and which > can be done better in the application. > > > DETAILED COMMENTS > S 1. > It looks like the evidence creation has to involve signatures by > both parties. Why not have it be one-way. See above. > > S 1.2. > Generating evidence is not compatible with Diffie-Hellman Ephemeral > (DHE) key exchanges. DHE does not permit the same keying material to > be generated for validation of the evidence after the TLS session is > over. Persistent evidence requires the use of a digital signature so > that it can be validated well after the TLS session is over. > > Why not just store the traffic keys? See above. > > > Figure 1 would be better with some markers about the traffic > segments that are signed. Ok. > > S 2. > I'm uncomfortable with the idea if "evidence suites" and later > of new certificates and certificate negotiation. This seems > like you're layering an entirely new protocol over TLS. Using the same two certs for both authentication and signing is simple and preferable in most cases. Ditto for cipher suite & evidence suite. However, sometimes you might prefer a null ciphersuite but want evidence (transfer of an already-encrypted file). In a military case, you may need to call the function that checks EvidenceRequest via RPC, in which case using different PKCs is nice to avoid private key sharing. There are some weird cases where this flexibility is nice to have. > > S 3. > This consumes 4 new alerts. The space isn't that big. > Since you're already defining a new protocol type, these > messages might as well be part of that protocol. Let's flesh this out a bit more. Whatever is best. > > S A. > Defining cipher suites with key lengths attached to them > isn't hte TLS way. In this case, using poor crypto actually hurts your partner if you're the one whose going to repudiate with evil intent. That's reversed from the normal TLS model, and why TLS Evidence is stringent where TLS historically has been able to be loose. Parties need to protect themselves by demanding what they consider to be strong asymmetric crypto. > > > -Ekr > Best regards, --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 01:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwvLQ-0005VR-HW; Wed, 20 Dec 2006 01:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwvLP-0005VJ-2w for tls@ietf.org; Wed, 20 Dec 2006 01:54:27 -0500 Received: from bay0-omc1-s40.bay0.hotmail.com ([65.54.246.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwvLK-00049l-9b for tls@ietf.org; Wed, 20 Dec 2006 01:54:27 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc1-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 22:54:21 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: EKR Subject: RE: [TLS] Comments on TLS identity protection Date: Tue, 19 Dec 2006 22:54:21 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 06:54:21.0592 (UTC) FILETIME=[AD64E180:01C72403] X-Spam-Score: 2.1 (++) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1497820590==" Errors-To: tls-bounces@lists.ietf.org --===============1497820590== Content-Type: multipart/alternative; boundary="_d9f49949-e896-4fc2-8af2-8294b62fd905_" --_d9f49949-e896-4fc2-8af2-8294b62fd905_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric: =20 I hope Im doing ok on CRLFs. I add them manually in my paragraphs, when I=20 remember. As far as I can determine , there is no way for a hotmail.com us= ers=20 to meet the IETF usability rules (wordwrap before 65chars, affixing CRLF ea= ch line), I'm happy to be shown how, tho, by power user! I'm keeping msn, tho, as it gives me excellent IETF S/MIME from my EVDO PDA, via a webmail. > > Peter Williams writes:> > Id say the nth handshake ca= n select to send "no server cert" whenever its > > cooperating to complete = an anonymous-ciphersuite-targeted handshake.> > So, assume there are only t= wo ciphers suite values in the HSM : RSA, RSA-ANON. > > There is no such th= ing as RSA anon in SSLv3 or TLS.=20 For a long time Ive regarded SSLv3 as http://wp.netscape.com/eng/ssl3/3-SPE= C.HTM#8-1 Its an old bookmark! =20 it doesnt even contain a set of ciphersuite declarations. It clearly reinforces what I said tho: server cert presentation is ALWAYS optional architecturally, and ServerKeyExchange is then used, instead. Netcape documents were never particular formal! They were always in a rush. =20 What I learned today is something i NEVER EVER REALIZED :-) was that the ServerKeyExchange.RSA could be ephemeral. While I always knew about the=20 "temporary key" idea (which demands a server cert...), I never equated it=20 with the equivalent "ephemeral DH". If they had meant ephemeral RSA, they would have used the word ... like DH! I reasoned. I was always interested i= n the no-cert case, in any case, per the first line in the text in 7.6.3. For no cert RSA, obviously they intended the RSA block to be used. How otehrwise could key transport ever work... if you don't signal the=20 public key!!? =20 It seemed so obvious to (a) do a full cert-based handshake (with no privacy= )=20 and then do an immediate second (full) handshake, "accelerated", referring back to the full "previously cert chain verified" public key, whose chain was verified properly just moments before, and stored in my client session = context.=20 It seemed silly to do all that chain checking work again, on the client. Th= is way,=20 the second handshake would be under the session protection of the first SSL= =20 Connection, giving basic privacy to the negotiation of the ciphersuites,=20 etc. for the SSL connection that would then takeover. =20 Why would anyone want an attacker to see the good stuff!? like the ciphersu= ite selection!!? So... handshake#1 is just a foil to boot handshake#2. This was a variation from 10 years ago of the current argument over client=20 id protection, from Ibrahim and co. =20 If TLS RSA CipherSuite DENY this mode (as I think they do, on simple readin= g),=20 I will simply locally-define a local-RSA ciphersuite for use on handshake#2= , that=20 removes anything in the std RSA that follows from requiring server auth "vi= a=20 certs". I can declare this a profile, and shut up about it, here in standar= ds land. =20 =20 _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=3Dimprove&local= e=3Den-US&source=3Dwlmemailtaglinenov06= --_d9f49949-e896-4fc2-8af2-8294b62fd905_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Eric:
 
I hope Im doing ok on CRLFs. I add them manually in my paragraphs, when I <= BR> remember. As far as I can determine , there is no way for a  hotmail.c= om users
to meet the IETF usability rules (wordwrap before 65chars, affixi= ng CRLF each line),
I'm happy to be shown how, tho, by  power user! I'm keeping msn, tho, = as it
gives me excellent IETF S/MIME from my EVDO PDA, via a webmail.

>
> Peter Williams <home_pw@msn.com> writes:
> &g= t; Id say the nth handshake can select to send "no server cert" whenever it= s
> > cooperating to complete an anonymous-ciphersuite-targeted h= andshake.
> > So, assume there are only two ciphers suite values i= n the HSM : RSA, RSA-ANON.
>
> There is no such thing as RSA = anon in SSLv3 or TLS.

<= FONT face=3D"" color=3D#000000>For a long time Ive regarded SSLv3 as http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#8-1=
I= ts an old bookmark!
<= /SPAN> 
i= t doesnt even contain a set of ciphersuite declarations. It clearly<= BR> r= einforces what I said tho: server cert presentation is ALWAYS optional
a= rchitecturally, and ServerKeyExchange is then used, instead. Netcape
d= ocuments were never particular formal! They were always in a rush. <= /SPAN> 
W= hat I learned today is something i NEVER EVER REALIZED :-) was that the
S= erverKeyExchange.RSA could be ephemeral. While I always knew about the
"= temporary key" idea (which demands a server cert...), I never equated= it
w= ith the equivalent "ephemeral DH". If they had meant ephemeral RSA, they
w= ould have used the word ... like DH! I reasoned. I was always int= erested in
t= he no-cert case, in any case, per the first line in the text in 7.6.3.
F= or no cert RSA, obviously they intended the RSA block to be used. How
o= tehrwise could key transport ever work... if you don't signal the p= ublic key!!?
<= /SPAN> 
I= t seemed so obvious to (a) do a full cert-based handshake (with no privacy)=
a= nd then do an immediate second (full) handshake, "accelerated", refer= ring
b= ack to the full "previously cert chain verified" public key, whose chain
w= as verified properly just moments before, and stored in my client ses= sion context.
I= t seemed silly to do all that chain checking work again, on the= client. This way,
t= he second handshake would be under the session protection= of the first SSL
C= onnection, giving basic privacy to the negotiation of the= ciphersuites,
e= tc. for the SSL connection that would then takeover.
<= /SPAN> 
W= hy would anyone want an attacker to see the good stuff!? like the ciphersui= te
s= election!!? So... handshake#1 is just a foil to boot handshake#2. This
w= as a variation from 10 years ago of the current argument over client <= /SPAN>
i= d protection, from Ibrahim and co.
<= /SPAN> 
I= f TLS RSA CipherSuite DENY this mode (as I think they do, on simple reading= ),
I= will simply locally-define a local-RSA ciphersuite for use on h= andshake#2, that 
r= emoves anything in the std RSA that follows from requiring serve= r auth "via
c= erts". I can declare this a profile, and shut up about it, here= in standards land.
<= /SPAN> 
<= /SPAN> 

View Athletes' Collections with Live Search. See it! = --_d9f49949-e896-4fc2-8af2-8294b62fd905_-- --===============1497820590== 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 --===============1497820590==-- From tls-bounces@lists.ietf.org Wed Dec 20 02:24:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwvnJ-0004li-GO; Wed, 20 Dec 2006 02:23:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwvnH-0004lc-Sx for tls@ietf.org; Wed, 20 Dec 2006 02:23:15 -0500 Received: from bay0-omc1-s40.bay0.hotmail.com ([65.54.246.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwvnG-0001zw-DL for tls@ietf.org; Wed, 20 Dec 2006 02:23:15 -0500 Received: from BAY103-W5 ([65.54.174.105]) by bay0-omc1-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 19 Dec 2006 23:23:13 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mark Brown , 'EKR' , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Tue, 19 Dec 2006 23:23:13 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 07:23:13.0800 (UTC) FILETIME=[B5DED880:01C72407] X-Spam-Score: 3.3 (+++) 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: , Content-Type: multipart/mixed; boundary="===============0093417770==" Errors-To: tls-bounces@lists.ietf.org --===============0093417770== Content-Type: multipart/alternative; boundary="_85257e3b-e861-4f0a-ade7-21a4a863f15e_" --_85257e3b-e861-4f0a-ade7-21a4a863f15e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tech.groups.yahoo.com/group/ssl-talk/message/4767from a while ago. =20 =20 > From: mark@redphonesecurity.com> To: ekr@networkresonance.com; tls@ietf.o= rg> Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00> Dat= e: Wed, 20 Dec 2006 00:00:47 -0600> CC: >=20 _________________________________________________________________ Type your favorite song.=A0 Get a customized station.=A0 Try MSN Radio powe= red by Pandora. http://radio.msn.com= --_85257e3b-e861-4f0a-ade7-21a4a863f15e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = http://tech.groups.yahoo.com/group/ssl-talk/message/4767

from a = while ago.
 
 

> From: mark@redphonesecurity.com
> To: ekr@networkresonance.com; = tls@ietf.org
> Subject: RE: [TLS] Please discuss: draft-housley-evide= nce-extns-00
> Date: Wed, 20 Dec 2006 00:00:47 -0600
> CC:
= >


Get free, personalized online radio with MSN Radio= powered by Pandora. Try i= t! = --_85257e3b-e861-4f0a-ade7-21a4a863f15e_-- --===============0093417770== 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 --===============0093417770==-- From tls-bounces@lists.ietf.org Wed Dec 20 03:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwwfQ-0003nr-Vi; Wed, 20 Dec 2006 03:19:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwwfO-0003nS-1R for tls@ietf.org; Wed, 20 Dec 2006 03:19:10 -0500 Received: from bay0-omc1-s41.bay0.hotmail.com ([65.54.246.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwwfL-0004x9-H0 for tls@ietf.org; Wed, 20 Dec 2006 03:19:10 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc1-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 00:19:06 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mark Brown , 'EKR' , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 20 Dec 2006 00:19:06 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 08:19:06.0976 (UTC) FILETIME=[8484E600:01C7240F] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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: , Content-Type: multipart/mixed; boundary="===============1858247054==" Errors-To: tls-bounces@lists.ietf.org --===============1858247054== Content-Type: multipart/alternative; boundary="_7f9305bf-376f-49f5-8054-4277d13eaffd_" --_7f9305bf-376f-49f5-8054-4277d13eaffd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > > S A.> > Defining cipher suites with key lengths attached to them> > isn= 't hte TLS way.> > In this case, using poor crypto actually hurts your part= ner if you're the> one whose going to repudiate with evil intent. That's re= versed from the> normal TLS model, and why TLS Evidence is stringent where = TLS historically> has been able to be loose. Parties need to protect themse= lves by demanding> what they consider to be strong asymmetric crypto. =20 This one is funny. Both positions are untenable, cryptopolitically. =20 SSL was born with a 40-bit keylength-restricted ciphersuite-spoon in its mo= uth. SSL became=20 _world_ famous only because a Frenchman broke Netscape's low-end implementa= tion in 3 days=20 (overcoming low entropy seeding in the low end 40bit RC4 case), splashing t= he story all over the=20 Wall Street Journal. =20 SSLv3 formalised protocols for creating ephemeral keys with "longer" length= , provided that=20 the resulting secrets were provably bound to only a particular connection= - to compromise with _legal enforcement regulations governing less restricted longer asymme= tric keys lengths. =20 A bit in a certificate allowed servers to arm servers to offer longer lengt= h ciphersuites, where only "export-accredited CAs" could issue such certs, whose assurance = of authorized issuer was tested/proved within the https process. (we got audited by the e= xport authorities for compliance against the required assurance standards we had promised; it= wasn't pleasant.) =20 TLS from IETF itself standardized elements of ciphersuites SPECIFICALLY wit= h key-length=20 limited RSA! (more export legal _enforcement_ protocol design) =20 Conclusions:-=20 =20 SSL protocol design has always been about proving stuff, in both the crypto= graphic and legal sense of meeting administrative law requirements (export regs). T= here is a=20 perpetual clash here, between two classes of issues which collide in crypto= -politics yet also converge in that the both require the provability of the same assertions. =20 See, that had to be a silver lining in all the work to enforce export regul= ations, using crypto.=20 We can now cite it, as endorsed, historical legal practice concerning TLS P= rotocol - by the=20 executive branch of the US Federal Govt. no less! =20 Peter _________________________________________________________________ Get into the holiday spirit, chat with Santa on Messenger. http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=3Den-= us= --_7f9305bf-376f-49f5-8054-4277d13eaffd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
> > S A.
> > Defining cipher suites with key lengths attache= d to them
> > isn't hte TLS way.
>
> In this case, us= ing poor crypto actually hurts your partner if you're the
> one whose= going to repudiate with evil intent. That's reversed from the
> norm= al TLS model, and why TLS Evidence is stringent where TLS historically
&= gt; has been able to be loose. Parties need to protect themselves by demand= ing
> what they consider to be strong asymmetric crypto.

 
This one is funny. Both positions are untenable, cryptopolitically.
 
SSL was born with a 40-bit keylength-restricted ciphersuite-spoon in its mo= uth.  SSL became
_world_ famous only because a Frenchman broke Netscape's low-end implementa= tion in 3 days
(overcoming low entropy seeding in the low end 40bit RC4 case), splash= ing the story all over the 
Wall Street Journal.
 
SSLv3 formalised protocols for creating ephemeral keys with "longer" length= , provided that
the resulting secrets  were provably bound to only  a particular = connection - to compromise
with _legal enforcement regulations governing less restricted longer a= symmetric keys lengths.
 
A bit in a certificate allowed servers to arm servers to offer longer lengt= h ciphersuites,
where only "export-accredited CAs" could issue such certs, whose assurance = of authorized
issuer was tested/proved within the https process. (we got audited by the e= xport authorities
for compliance against the required assurance standards we had promised; it= wasn't pleasant.)
 
TLS from IETF itself standardized elements of ciphersuites SPECIFICALLY wit= h key-length
limited RSA! (more export legal _enforcement_ protocol design)
 
Conclusions:-
 
SSL protocol design has always been about proving stuff, in both the crypto= graphic
and legal sense of meeting administrative law requirements (export regs). T= here is a
perpetual clash here, between two classes of issues which collide in crypto= -politics yet also
converge in that the both require the provability of the same assertions.  
See, that had to be a silver lining in all the work to enforce export regul= ations, using crypto.
We can now cite it, as endorsed, historical legal practice concerning TLS P= rotocol - by the
executive branch of the US Federal Govt. no less!
 
Peter

Get into the holiday spirit, chat with Santa on Messen= ger.=A0 Ho-Ho-Ho! = --_7f9305bf-376f-49f5-8054-4277d13eaffd_-- --===============1858247054== 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 --===============1858247054==-- From tls-bounces@lists.ietf.org Wed Dec 20 03:46:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwx4q-0006Z4-C0; Wed, 20 Dec 2006 03:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwx4p-0006Yr-7K for tls@ietf.org; Wed, 20 Dec 2006 03:45:27 -0500 Received: from bay0-omc1-s11.bay0.hotmail.com ([65.54.246.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwx4n-0002P9-Rc for tls@ietf.org; Wed, 20 Dec 2006 03:45:27 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc1-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 00:45:25 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mark Brown , 'EKR' , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 20 Dec 2006 00:45:25 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 08:45:25.0360 (UTC) FILETIME=[314F2F00:01C72413] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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: , Content-Type: multipart/mixed; boundary="===============1818273544==" Errors-To: tls-bounces@lists.ietf.org --===============1818273544== Content-Type: multipart/alternative; boundary="_9178ce03-47b5-4514-ab2d-7665ead334f4_" --_9178ce03-47b5-4514-ab2d-7665ead334f4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > Why should we consider digital evidence a hard problem, a crypto protocol= > problem, a TLS problem? One crucial issue was raised by Steven Kent last>= year: the problem of the recording the signer's intent. Just to be clear,>= "signer's intent" problems include not only the challenge of recording> so= mething intangible, or the possibility that garbage data was signed, but> a= lso claims that the system that created the digital signature was subverted= > - or used with an intention to defraud. I'm a newcomer to this party, but= I> don't think any previous standard solves this problem (I don't count th= e NR> bit as solving the problem). Let us know... =20 You have to be very careful in your crypto claims; NR has semantics limits.= Its very=20 easy to modulate the record length in TLS's fragmentation process to convey= and recover=20 certain cleartext signals communicated over the sideband of record lengths.= =20 =20 Record length headers are not encrypted normally in TLS, unless one has ta= ke specific=20 precautions to tunnel one session output properly within the record layer o= f another, whose=20 fragmentation engine and message queue handler blinds timing channels. Its = quite easy with=20 telnet-s for example to use these covert channels to signal actual pattern= s in the users typing=20 behavior/errors, which are is characteristic of people (and their state of = mind!) as is their use of=20 a morse key. =20 And what precisely was the irrefutable intent established using crypto proo= fs, when we contrast that with the sideband TLS evidence of their typing behaviour? = asks competing=20 counsel? =20 Ask a person who had to listen to morse, in their military communications c= areers. They could tell what mood the person was in, after a while =20 ! _________________________________________________________________ Type your favorite song.=A0 Get a customized station.=A0 Try MSN Radio powe= red by Pandora. http://radio.msn.com= --_9178ce03-47b5-4514-ab2d-7665ead334f4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


 
> Why should we consider digital evidence a hard problem, a crypto proto= col
> problem, a TLS problem? One crucial issue was raised by Steven = Kent last
> year: the problem of the recording the signer's intent. J= ust to be clear,
> "signer's intent" problems include not only the ch= allenge of recording
> something intangible, or the possibility that = garbage data was signed, but
> also claims that the system that creat= ed the digital signature was subverted
> - or used with an intention = to defraud. I'm a newcomer to this party, but I
> don't think any pre= vious standard solves this problem (I don't count the NR
> bit as sol= ving the problem). Let us know...

 
You have to be very careful in your crypto claims; NR has semantics limits.= Its very
easy to modulate the record length in TLS's fragmentation process to c= onvey and recover
certain cleartext signals communicated over the sideband of record len= gths.
 
Record length headers are not encrypted  normally in TLS, unless one h= as take specific
precautions to tunnel one session output properly within the reco= rd layer of another, whose
fragmentation engine and message queue handler blinds timing channels. Its&= nbsp; quite easy with
telnet-s for example to use these covert channels to  signal actu= al patterns in the users typing
behavior/errors, which are is characteristic of people (and their state of = mind!) as is their use of
a morse key.
 
And what precisely was the irrefutable intent established using crypto= proofs, when
we contrast that with the sideband TLS evidence of their typing behaviour? = asks competing
counsel?
 
Ask a person who had to listen to morse, in their military communications c= areers. They
could tell what mood the person was in, after a while
 
!

Get free, personalized online radio with MSN Radio powered= by Pandora. Try it! = --_9178ce03-47b5-4514-ab2d-7665ead334f4_-- --===============1818273544== 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 --===============1818273544==-- From tls-bounces@lists.ietf.org Wed Dec 20 04:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwxQh-0001iN-VD; Wed, 20 Dec 2006 04:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwxQg-0001fB-6G for tls@ietf.org; Wed, 20 Dec 2006 04:08:02 -0500 Received: from bay0-omc3-s33.bay0.hotmail.com ([65.54.246.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwxQd-00005d-Ot for tls@ietf.org; Wed, 20 Dec 2006 04:08:02 -0500 Received: from BAY103-W5 ([65.54.174.105]) by bay0-omc3-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 01:07:59 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , Eric Rescorla Subject: RE: [TLS] Comments on TLS identity protection Date: Wed, 20 Dec 2006 01:07:59 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 09:07:59.0157 (UTC) FILETIME=[583C3650:01C72416] X-Spam-Score: 2.6 (++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0382711881==" Errors-To: tls-bounces@lists.ietf.org --===============0382711881== Content-Type: multipart/alternative; boundary="_8eac7577-7130-4c23-8755-f345affa5f9d_" --_8eac7577-7130-4c23-8755-f345affa5f9d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Microsoft has a long history of exploiting this feature, in various ways. A= ctually goes back to their own PCT proposal, when they were differentiating its features= from=20 SSLv2. Fascinating to see this all being "reinvented/reargued" 10 years after it w= as all debated the first time around. Though, there is a big difference betwee= n the then (web culture) and now (internet culture). Very different tone. =20 > From: martin.rex@sap.com> Subject: Re: [TLS] Comments on TLS identity pro= tection> To: ekr@networkresonance.com> Date: Tue, 19 Dec 2006 22:00:29 +010= 0> CC: tls@ietf.org> > Eric Rescorla wrote:> > > > The good news is that TL= S has a very simple mechanism for achieving> > this: do an ordinary TLS han= dshake without client authentication> > and then do an immediate re-handsha= ke with client auth. As the > > authors observe, this is slower (two sets o= f crypto computations> > and 4 RTTs) than a specialized identity protection= mode. However,> > it is available now and as far as I can tell is rarely d= one.> > I don't find the argument that there is a large demand for this> > = feature if it were only 50% faster particularly persuasive.> > Rather, this= seems like a premature optimization.> > It is not as rare as you might thi= nk. It is actually the> default in Microsoft's IIS with some configurations= that> IIS only requests SSL client authentication after> having seen the r= equest (URL). It might be a side-effect> of NOT requiring SSL client authen= tication on the root/home> page of the webserver and only for certain areas= /paths.> > > -Martin> > _______________________________________________> TL= S mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/= tls _________________________________________________________________ Type your favorite song.=A0 Get a customized station.=A0 Try MSN Radio powe= red by Pandora. http://radio.msn.com= --_8eac7577-7130-4c23-8755-f345affa5f9d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
 
Microsoft has a long history of exploiting this feature, in various ways. A= ctually goes
back to their own PCT proposal, when they were differentiating its features= from
SSLv2.

Fascinating to see this all being "reinvented/reargued" 10 years after it w= as
all debated the first time around. Though, there is a big difference betwee= n the
then (web culture) and now (internet culture). Very different tone.
 

> From: martin.rex@sap.com
> Subject: Re: [TLS] Comments on TLS id= entity protection
> To: ekr@networkresonance.com
> Date: Tue, 1= 9 Dec 2006 22:00:29 +0100
> CC: tls@ietf.org
>
> Eric Re= scorla wrote:
> >
> > The good news is that TLS has a ve= ry simple mechanism for achieving
> > this: do an ordinary TLS han= dshake without client authentication
> > and then do an immediate = re-handshake with client auth. As the
> > authors observe, this i= s slower (two sets of crypto computations
> > and 4 RTTs) than a s= pecialized identity protection mode. However,
> > it is available = now and as far as I can tell is rarely done.
> > I don't find the = argument that there is a large demand for this
> > feature if it w= ere only 50% faster particularly persuasive.
> > Rather, this seem= s like a premature optimization.
>
> It is not as rare as you = might think. It is actually the
> default in Microsoft's IIS with som= e configurations that
> IIS only requests SSL client authentication a= fter
> having seen the request (URL). It might be a side-effect
&g= t; of NOT requiring SSL client authentication on the root/home
> page= of the webserver and only for certain areas/paths.
>
>
&g= t; -Martin
>
> _______________________________________________=
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.i= etf.org/mailman/listinfo/tls


Get free, personalized onli= ne radio with MSN Radio powered by Pandora. Try it! = --_8eac7577-7130-4c23-8755-f345affa5f9d_-- --===============0382711881== 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 --===============0382711881==-- From tls-bounces@lists.ietf.org Wed Dec 20 05:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwygV-0003Ib-4A; Wed, 20 Dec 2006 05:28:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwygU-0003FR-Bm for tls@ietf.org; Wed, 20 Dec 2006 05:28:26 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwygS-0006d4-Ub for tls@ietf.org; Wed, 20 Dec 2006 05:28:26 -0500 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 LAA61766 ; Wed, 20 Dec 2006 11:27:01 +0100 Message-ID: <4589103B.1050402@isima.fr> Date: Wed, 20 Dec 2006 11:28:11 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 Subject: Re: [TLS] Comments on TLS identity protection References: <20061219204505.5F2EE5C01E@laser.networkresonance.com> <61434.86.72.162.216.1166567558.squirrel@www.isima.fr> <86ejqvpl6s.fsf@raman.networkresonance.com> <45890C86.5090803@enst.fr> In-Reply-To: <45890C86.5090803@enst.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Eric Rescorla writes: > badra@isima.fr writes: > >> In EAP-TLS, an implementation of TLS for Wireless LAN and later for >> WiMAX, >> the client is authenticated based on the certificate's use. This is the >> initial motivation of this work. >> > > Yes, but I don't think this really explains why the certificate > needs to be kept secret or why the double handshake technique isn't > good enough. > Hi Eric, IMHO, double handshake technique isn't good enough to many environments, especially in performance-constrained environments. In addition: - As you cited in your early mail, double handshake needs two sets of crypto computations and 4 RTTs. The number of RTT significantly increases when using TLS over EAP or UDP. Moreover, the client and the server need to encrypt/decrypt the whole messages of the second handshake. - Double handshake reduces the server performance by a factor of 2 or 3 at least. - In the case where the client has no certificate and the server isn't configured to accept connexions from unauthenticated clients, we can't stop the TLS negotiation early. So the server is overloaded for nothing: the first handshake is already done and the sever doesn't receive a certificate from the client. In the ciphersuites approach, the server and the client can detect such configuration early during the hello phase. - With double handshake, the "privacy" and "no privacy" cannot be implemented together. I mean TLS servers aren't so smart to do that without external configuration and that the client cannot set or negotiate "privacy" with a given server. - Configuration cost. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 05:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwz23-0003LS-C7; Wed, 20 Dec 2006 05:50:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwz22-0003LH-8n for tls@ietf.org; Wed, 20 Dec 2006 05:50:42 -0500 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 1Gwz20-0004CA-Q1 for tls@ietf.org; Wed, 20 Dec 2006 05:50:42 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBKAnw0E022478; Wed, 20 Dec 2006 12:50:02 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 12:49:14 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 12:49:13 +0200 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 TLS identity protection Date: Wed, 20 Dec 2006 12:49:13 +0200 Message-ID: In-Reply-To: <20061219204505.5F2EE5C01E@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Comments on TLS identity protection Thread-Index: Accjrj1dNwtsppKNS5uPtGuyI67AuAAdV3/Q From: To: , X-OriginalArrivalTime: 20 Dec 2006 10:49:13.0617 (UTC) FILETIME=[7CE54010:01C72424] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061220125002-57C31BB0-34429CDD/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 I agree with many of Eric's comments. TLS can already hide the client certificates, but this mechanism=20 is not widely used. This draft proposes an optimization to the=20 hiding mechanism that requires a smaller number of roundtrips and=20 less computation.=20 However, it seems that the reasons why the existing feature is not used have nothing to do with poor performance. And if the existing mechanism doesn't have a performance problem, optimizing it would be premature (and thus "root of all evil" :-). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 06:15:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwzPb-0006Ui-66; Wed, 20 Dec 2006 06:15:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwzPZ-0006Qo-Jy for tls@ietf.org; Wed, 20 Dec 2006 06:15:01 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwzPY-00026B-8t for tls@ietf.org; Wed, 20 Dec 2006 06:15:01 -0500 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 MAA63902 ; Wed, 20 Dec 2006 12:13:28 +0100 Message-ID: <45891B1D.9060500@isima.fr> Date: Wed, 20 Dec 2006 12:14:37 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Comments on TLS identity protection References: 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 MAA63902 X-Spam-Score: 0.0 (/) 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 Pasi.Eronen@nokia.com a =E9crit : > However, it seems that the reasons why the existing feature is > not used have nothing to do with poor performance. And if the > existing mechanism doesn't have a performance problem, optimizing > it would be premature (and thus "root of all evil" :-). > > Best regards, > Pasi > =20 Hi Pasi, Other reasons are included in my last mail for why double handshake=20 isn't good enough, optimization is one of them. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 06:50:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwzxe-00058J-4j; Wed, 20 Dec 2006 06:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwzxd-00058E-A2 for tls@ietf.org; Wed, 20 Dec 2006 06:50:13 -0500 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 1Gwzxb-0002Uk-Rq for tls@ietf.org; Wed, 20 Dec 2006 06:50:13 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBKBmlBS005243; Wed, 20 Dec 2006 13:49:14 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 13:49:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 13:49:42 +0200 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 TLS identity protection Date: Wed, 20 Dec 2006 13:49:41 +0200 Message-ID: In-Reply-To: <45891B1D.9060500@isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Comments on TLS identity protection Thread-Index: AcckKBu+aVdOB6KTTReRMVhUIaOAUgABFpwg From: To: X-OriginalArrivalTime: 20 Dec 2006 11:49:42.0235 (UTC) FILETIME=[EFB86AB0:01C7242C] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 badra wrote: > Other reasons are included in my last mail for why double=20 > handshake isn't good enough, optimization is one of them. I don't think any of the "reasons" lead to the conclusion that=20 "double handshake isn't good enough"; let me explain why: > In the case where the client has no certificate and the server isn't > configured to accept connexions from unauthenticated clients, we > can't stop the TLS negotiation early. So the server is overloaded > for nothing: the first handshake is already done and the sever > doesn't receive a certificate from the client. In the ciphersuites > approach, the server and the client can detect such configuration > early during the hello phase. And why would anyone care about this? (Note that your proposal doesn't help against intentional denial-of-service attacks either, only accidental misconfiguration.) > - With double handshake, the "privacy" and "no privacy" cannot be > implemented together. I mean TLS servers aren't so smart to do that > without external configuration and that the client cannot set or > negotiate "privacy" with a given server. See draft-simon-emu-rfc2716bis Section 2.7 for how a "smart" TLS server can support both clients that support privacy and those that don't.=20 > - Configuration cost. What configuration? A TLS server that supports both privacy and no privacy doesn't need any configuration options to do so (it does need the code to do double handshake, but new code would be required for your proposal as well). A TLS client might concievably have=20 configuration option "require privacy", but this applies to your=20 proposal as well. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 07:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0Wm-0007cW-QQ; Wed, 20 Dec 2006 07:26:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0Wl-0007NP-Dt for tls@ietf.org; Wed, 20 Dec 2006 07:26:31 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx0Wh-00039p-Aw for tls@ietf.org; Wed, 20 Dec 2006 07:26:31 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Gx0WX1yBZ-0001PZ; Wed, 20 Dec 2006 13:26:19 +0100 Received: by tau.invalid (Postfix, from userid 1000) id CD7AD101B3; Wed, 20 Dec 2006 13:26:16 +0100 (CET) Date: Wed, 20 Dec 2006 13:26:16 +0100 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] GSS-API extension draft available Message-ID: <20061220122616.GA21201@tau.invalid> References: <45883A8F.1090801@secure-endpoints.com> <200612192026.VAA21427@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612192026.VAA21427@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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, Dec 19, 2006 at 09:26:10PM +0100, Martin Rex wrote: > Jeffrey Altman wrote: >> In RFC 2712 (TLS Kerberos Ciphers) the Kerberos session key is used as >> the pre-master secret. This mechanism has severe problems because it >> means that each and every TLS session that is created for as long as the >> Kerberos service ticket is valid will use the same pre-master secret. > This looks like an extremely poor choice to me, given the (lack of) > entropy in Kerberos sessions keys, in particular of the installed base > and the predominant interorable enctype when rfc2712 was issued. >> What this proposal does is replace RFC 2712 with a generic GSS-API >> method of generating a unique pre-master secret when used with the GSS >> Kerberos5 mechanism. GSS-API does not provide a method to extract key >> data from the underlying mechanism because doing so would result in a >> mechanism specific dependency and violate the GSS-API abstraction. > Using the entropy from the GSS-API prf is fine. [...] In terms of entropy, the RFC 2712 approach does not have a problem. While the premaster secret is fixed for a given Kerberos ticket, any master secret will also depend on the client hello and server hello randomness of the specific connection and thus, for practical purposes, be unique. This is similar to the fixed DH ciphersuites for TLS (which no-one uses, though), in which the premaster secret is fixed for any given client certificate/server certificate combination. However, it is not entropy in general that counts. While the client hello and server hello do provide entropy, this is public entropy and thus cannot contribute much to long-term encryption security. What you can do to obtain better security with the RFC 2712 Kerberos ciphersuites is immediate renegotiation using an anonymous DH (or ECDH) ciphersuite: then Kerberos is relied upon for authentication, and the DH key exchange (which happens in an authenticated context) is relied upon for obtaining the symmetric keys that will be used for the actual application data. I don't think any RFC 2712 implementation has been designed with this in mind, but it would be a quite reasonable approach to use the protocol. It appears to me that when we use the GSS-API PRF for Kerberos V (RFC 4402) as suggested in draft-santesson-tls-gssapi-01.txt, we have solved the wrong problem. Using the PRF will give use a unique premaster secret for each session, which we don't really need. Using the PRF will not include any additional *secret* entropy, which is what we actually need -- at least if the main worry is the lack of entropy in the Kerberos session key. I may have misunderstood what the proposed GSS-API based handshake would be doing in the Kerberos V case. But if it works the way I think it works (without mixing in secret entropy from a key exchange such as DH/ECDH), then to improve the level of security compared with RFC 2712 as apparently is desired, we'd still have to perform an immediate renegotiation to benefit from an appropriate key exchange mechanism. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 07:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0gg-00071f-86; Wed, 20 Dec 2006 07:36:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0ge-00070L-Ht for tls@ietf.org; Wed, 20 Dec 2006 07:36:44 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx0gd-0004s2-6O for tls@ietf.org; Wed, 20 Dec 2006 07:36:44 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Gx0ga3VDA-00080O; Wed, 20 Dec 2006 13:36:41 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 6DD05101B3; Wed, 20 Dec 2006 13:36:40 +0100 (CET) Date: Wed, 20 Dec 2006 13:36:40 +0100 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Comments on TLS identity protection Message-ID: <20061220123640.GB21201@tau.invalid> References: <86vek7pph4.fsf@raman.networkresonance.com> <200612192115.WAA22812@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612192115.WAA22812@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 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 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, Dec 19, 2006 at 10:15:01PM +0100, Martin Rex wrote: >> However, as you say in most cases the request for client auth >> is contingent upon seeing the request and so a rehandshake is >> required here in any case. A one-pass protocol wouldn't work >> here. > I had the same thought but completely failed to point this out. > > In the not uncommon case with IIS renegotiating after having > evaluated the HTTP(S)-request, [...] This, by the way, applies not only to IIS servers. The Apache HTTP server with mod_ssl can also be configured to request client certificates only for specific requests, which of course is achieved through a renegotiation. This approach is reasonable not only for HTTP applications: An SMTP server supporting TLS might perform certificate-based client authentication only when used as a mail relay, and finish without attempting client authentication if a connection only involves local mail delivery. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 07:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0o1-0002Fo-Sl; Wed, 20 Dec 2006 07:44:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx0o0-0002Fa-29 for tls@ietf.org; Wed, 20 Dec 2006 07:44:20 -0500 Received: from ms-smtp-01.rdc-nyc.rr.com ([24.29.109.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx0ny-0006LJ-QM for tls@ietf.org; Wed, 20 Dec 2006 07:44:20 -0500 Received: from www.secure-endpoints.com (cpe-68-175-93-48.nyc.res.rr.com [68.175.93.48]) by ms-smtp-01.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kBKCiF4Z015263 for ; Wed, 20 Dec 2006 07:44:16 -0500 (EST) Received: from [192.168.1.13] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000038322.msg for ; Wed, 20 Dec 2006 07:45:39 -0500 Message-ID: <4589306D.5030809@secure-endpoints.com> Date: Wed, 20 Dec 2006 07:45:33 -0500 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: bmoeller@acm.org Subject: Re: [TLS] GSS-API extension draft available References: <45883A8F.1090801@secure-endpoints.com> <200612192026.VAA21427@uw1048.wdf.sap.corp> <20061220122616.GA21201@tau.invalid> In-Reply-To: <20061220122616.GA21201@tau.invalid> X-Enigmail-Version: 0.94.1.2 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Wed, 20 Dec 2006 07:45:39 -0500 (not processed: message from valid local sender) X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: tls@ietf.org X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jaltman@secure-endpoints.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: , Content-Type: multipart/mixed; boundary="===============1600229398==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1600229398== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010904050809000901050900" This is a cryptographically signed message in MIME format. --------------ms010904050809000901050900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bodo Moeller wrote: > It appears to me that when we use the GSS-API PRF for Kerberos V > (RFC 4402) as suggested in draft-santesson-tls-gssapi-01.txt, we have > solved the wrong problem. Using the PRF will give use a unique > premaster secret for each session, which we don't really need. Using > the PRF will not include any additional *secret* entropy, which is what > we actually need -- at least if the main worry is the lack of entropy in > the Kerberos session key. > > I may have misunderstood what the proposed GSS-API based handshake would > be doing in the Kerberos V case. But if it works the way I think it > works (without mixing in secret entropy from a key exchange such as > DH/ECDH), then to improve the level of security compared with RFC 2712 > as apparently is desired, we'd still have to perform an immediate > renegotiation to benefit from an appropriate key exchange mechanism. > > Bodo Currently the input to the GSS PRF would be: OM_uint32 minor_status; gss_ctx_id_t gss_context; gss_buffer_t prf_in; gss_buffer_t prf_out; ssize_t output_len = sizeof(pre-master-secret); GSS_Pseudo_random( &minor_status, gss_context, GSS_C_PRF_KEY_FULL, prf_in, output_len, prf_out); where prf_in is the concatenation of all of the previous TLS messages in the exchange up until the completion of the GSS handshake: prf_in = ClientHello || ServerHello || .... What I hear you saying is that we should add an ephemeral-ephemeral DH exchange in which case the prf_in will become: prf_in = g^xy mod p || ClientHello || ServerHello || .... where g^xy mod p is the DH key. Correct? Jeffrey Altman --------------ms010904050809000901050900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjEyMjAxMjQ1MzNaMCMGCSqGSIb3DQEJBDEWBBTYrHz6 zfBmHpmPHsatP3BjQXkfPTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEABIrpaKQcFp7+SEIAxzYUqfZ52xyKDbfLGJB/FQe3EGV5NJtJ7DvT kQBYL+vEK/uX9tB+CDX2e2fMOOJalZ9ehPGqgwE0Ip7n2zV0GjAl8AewQ78ECkA6AedUajfa hM2u4O7a7pG6N2poySsbL1kKrI7XXODkrQhzeggiw0i9K8clLtGyAQe9xWfwibFEUxpEAabb F6sDPyarNtIKXRhzWVwJT5qicXctNfBerK8akXRyeIb+ygHK0+K/R11ghZbsySD5VsLyOVxv rYL8Yal3oDQbodofNyRCrqevtTMs+w54P6cGdHn9p9/kblF/5tIaPxt25z3X54Ym9FOCB4Pr DgAAAAAAAA== --------------ms010904050809000901050900-- --===============1600229398== 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 --===============1600229398==-- From tls-bounces@lists.ietf.org Wed Dec 20 08:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1I8-0000NS-9U; Wed, 20 Dec 2006 08:15:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1I7-0000N6-0D for tls@ietf.org; Wed, 20 Dec 2006 08:15:27 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1I5-0005BG-KO for tls@ietf.org; Wed, 20 Dec 2006 08:15:26 -0500 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 OAA55070 ; Wed, 20 Dec 2006 14:13:57 +0100 Message-ID: <4589375B.8070201@isima.fr> Date: Wed, 20 Dec 2006 14:15:07 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Comments on TLS identity protection References: 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 OAA55070 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Hi Pasi, Pasi.Eronen@nokia.com a =E9crit : > And why would anyone care about this? (Note that your proposal doesn't > help against intentional denial-of-service attacks either, only > accidental misconfiguration.) > > =20 does no one care about his server consuming amounts of CPU to do, among=20 others, two sets of crypto-computations for nothing? I didn't say the proposal helps againt MITM. I said double handshake=20 raises security considerations regarding MITM, when the proposal does't=20 raise new security considerations. > What configuration? A TLS server that supports both privacy and no > privacy doesn't need any configuration options to do so (it does > need the code to do double handshake, but new code would be required > for your proposal as well). A TLS client might concievably have=20 > configuration option "require privacy", but this applies to your=20 > proposal as well. > =20 Many mechanisms can be designed to add client privacy to TLS, but the=20 question arises: which one is more efficient and preferment? Haven't=20 many documents been originally approved for easy deployment and=20 optimization reasons? > Best regards, > Pasi > > =20 Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 08:27:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1TF-0007Xd-Ot; Wed, 20 Dec 2006 08:26:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1TE-0007XY-Be for tls@ietf.org; Wed, 20 Dec 2006 08:26:56 -0500 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 1Gx1TB-00088O-S3 for tls@ietf.org; Wed, 20 Dec 2006 08:26:56 -0500 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 kBKDQ5sJ009712; Wed, 20 Dec 2006 15:26:10 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 15:26:46 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 15:26:45 +0200 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 TLS identity protection Date: Wed, 20 Dec 2006 15:26:46 +0200 Message-ID: In-Reply-To: <4589375B.8070201@isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Comments on TLS identity protection Thread-Index: AcckOOgsbSsUcy0WRDWY3EP/NKp1PgAACGNQ From: To: X-OriginalArrivalTime: 20 Dec 2006 13:26:45.0622 (UTC) FILETIME=[7EBAC160:01C7243A] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061220152610-25B36BB0-2B4221BC/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 badra@isima.fr wrote: > does no one care about his server consuming amounts of CPU to do, > among others, two sets of crypto-computations for nothing? =20 If the extra computations occur only in very rare situations,=20 it's perfectly reasonable not to care about it (at least=20 sufficiently to spend the $$$ for designing, implementing,=20 testing, deploying, etc. a new mechanism). > Many mechanisms can be designed to add client privacy to TLS, but > the question arises: which one is more efficient and preferment? My point was that we *already* have one mechanism for client privacy in TLS. Thus IMHO the right question to ask is *NOT* which one is=20 more efficient and preferred, but rather is the existing mechanism=20 so bad that we should spend effort in adding *another* one? > Haven't many documents been originally approved for easy=20 > deployment and optimization reasons? I think deployment-wise, double handshake has the advantage that it's already specified and implemented. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 08:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1of-0001ju-5P; Wed, 20 Dec 2006 08:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1oc-0001gO-JI for tls@ietf.org; Wed, 20 Dec 2006 08:49:02 -0500 Received: from moutng.kundenserver.de ([212.227.126.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1ob-0003RG-6B for tls@ietf.org; Wed, 20 Dec 2006 08:49:02 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Gx1oX00ZC-0001N7; Wed, 20 Dec 2006 14:48:57 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 91674101B3; Wed, 20 Dec 2006 14:48:56 +0100 (CET) Date: Wed, 20 Dec 2006 14:48:56 +0100 From: Bodo Moeller To: Jeffrey Altman Subject: Re: [TLS] GSS-API extension draft available Message-ID: <20061220134856.GA24847@tau.invalid> References: <45883A8F.1090801@secure-endpoints.com> <200612192026.VAA21427@uw1048.wdf.sap.corp> <20061220122616.GA21201@tau.invalid> <4589306D.5030809@secure-endpoints.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4589306D.5030809@secure-endpoints.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Wed, Dec 20, 2006 at 07:45:33AM -0500, Jeffrey Altman wrote: > Bodo Moeller wrote: >> It appears to me that when we use the GSS-API PRF for Kerberos V >> (RFC 4402) as suggested in draft-santesson-tls-gssapi-01.txt, we have >> solved the wrong problem. Using the PRF will give use a unique >> premaster secret for each session, which we don't really need. Using >> the PRF will not include any additional *secret* entropy, which is what >> we actually need -- at least if the main worry is the lack of entropy in >> the Kerberos session key. >> >> I may have misunderstood what the proposed GSS-API based handshake would >> be doing in the Kerberos V case. But if it works the way I think it >> works (without mixing in secret entropy from a key exchange such as >> DH/ECDH), then to improve the level of security compared with RFC 2712 >> as apparently is desired, we'd still have to perform an immediate >> renegotiation to benefit from an appropriate key exchange mechanism. > Currently the input to the GSS PRF would be: > > OM_uint32 minor_status; > gss_ctx_id_t gss_context; > gss_buffer_t prf_in; > gss_buffer_t prf_out; > ssize_t output_len = sizeof(pre-master-secret); > > GSS_Pseudo_random( &minor_status, > gss_context, > GSS_C_PRF_KEY_FULL, > prf_in, > output_len, > prf_out); > > where prf_in is the concatenation of all of the previous TLS messages > in the exchange up until the completion of the GSS handshake: > > prf_in = ClientHello || ServerHello || .... I see. This is something that I had not managed to gather from draft-santesson-tls-gssapi-01.txt. (Why not use just ClientHello.random and ServerHello.random instead of the complete TLS handshake data collected so far?) > What I hear you saying is that we should add an ephemeral-ephemeral DH > exchange in which case the prf_in will become: > > prf_in = g^xy mod p || ClientHello || ServerHello || .... > > where g^xy mod p is the DH key. > > > Correct? Yes, this looks much better -- at least when the key exchange mechanism is used with Kerberos V. For other GSS-API mechanisms, the DH computation might just be overhead. The renegotiation approach, while appearing somewhat ad-hoc, has some advantages in terms of flexibility at the cost of some extra protocol rounds (but little extra computational effort): It can accomodate DH and ECDH and any other key exchanges. For GSS-API mechanisms for which an additional key exchange is not necessary, there simply wouldn't have to be a second handshake. (Of course, to ensure interoperability, the specification would have to provide appropriate instructions.) Still it probably would be the best to integrate all components of the key exchange into a single TLS handshake. I am just not sure what the best protocol design would be: Have separate ciphersuites without a ServerKeyExchange, with DH, with ECDH? Or use some additional negotiation mechanism (based on TLS extensions) to choose if and how ServerKeyExchange (and ClientKeyExchange) should be used? Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 09:09:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx27i-0002NB-QI; Wed, 20 Dec 2006 09:08:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx27h-0002Mc-Cp for tls@ietf.org; Wed, 20 Dec 2006 09:08:45 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx27f-0006QH-0W for tls@ietf.org; Wed, 20 Dec 2006 09:08:45 -0500 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 PAA56734 ; Wed, 20 Dec 2006 15:07:18 +0100 Message-ID: <458943DC.7020303@isima.fr> Date: Wed, 20 Dec 2006 15:08:28 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Comments on TLS identity protection References: 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 PAA56734 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Hi Pasi, Pasi.Eronen@nokia.com a =E9crit : > If the extra computations occur only in very rare situations,=20 > it's perfectly reasonable not to care about it=20 I disagree. Anybody can connect to your server at any time and doing=20 uncompleted double handshake. It is not a rare situation. > (at least=20 > sufficiently to spend the $$$ for designing, implementing,=20 > testing, deploying, etc. a new mechanism). > =20 How much :). The proposed changes are minimal. > My point was that we *already* have one mechanism for client privacy > in TLS. Thus IMHO the right question to ask is *NOT* which one is=20 > more efficient and preferred, but rather is the existing mechanism=20 > so bad that we should spend effort in adding *another* one? > > =20 I tried to explain why double handshake is not good in terms of=20 optimization and security consideration. Well, I know your opinion regarding the double handshake since=20 Montreal's meeting when you said "it would the same end result as adding=20 a couple of roundtrips". Note that double handshake at this time was not described in=20 draft-simon-emu-rfc2716bis-03 and it has been added by August 2006, one=20 month after Montreal meeting and three months after=20 draft-urien-badra-eap-tls-identity-protection :) > I think deployment-wise, double handshake has the advantage that > it's already specified and implemented. > =20 Any link to test the implementation, please? Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 09:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2Ux-0006pc-Cz; Wed, 20 Dec 2006 09:32:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2Uw-0006pT-2t for tls@ietf.org; Wed, 20 Dec 2006 09:32:46 -0500 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 1Gx2Ur-0003Rl-Iw for tls@ietf.org; Wed, 20 Dec 2006 09:32:46 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBKEVVRQ023879; Wed, 20 Dec 2006 16:32:03 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 16:32:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 16:32:35 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Comments on TLS identity protection Date: Wed, 20 Dec 2006 16:32:35 +0200 Message-ID: In-Reply-To: <458943DC.7020303@isima.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Comments on TLS identity protection Thread-Index: AcckQFsfKkRgmyGGToa1t4nCYSWEyQAACPvg From: To: X-OriginalArrivalTime: 20 Dec 2006 14:32:35.0736 (UTC) FILETIME=[B12E5180:01C72443] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 badra wrote: > Pasi.Eronen@nokia.com a =E9crit : > > If the extra computations occur only in very rare situations,=20 > > it's perfectly reasonable not to care about it=20 >=20 > I disagree. Anybody can connect to your server at any time and=20 > doing uncompleted double handshake. It is not a rare situation. Do you have any data to back that claim? The fact that anybody can connect at any time does not automatically imply that lots of people are connecting all the time!=20 (And in particular, lots of people without client certificates=20 connecting all the time to servers that always require client authentication, and without malicious intent to DoS the server.) > > (at least sufficiently to spend the $$$ for designing,=20 > > implementing, testing, deploying, etc. a new mechanism). >=20 > How much :). The proposed changes are minimal. To get widespread deployment, several TLS implementations would=20 have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS,=20 JSSE, GnuTLS, etc. Getting any change, no matter how "minimal",=20 to them is not easy. > > I think deployment-wise, double handshake has the advantage=20 > > that it's already specified and implemented. >=20 > Any link to test the implementation, please? Pick your favorite TLS implementation! There are at least couple of dozen of them (though probably not all of them support renegotiation).=20 Some of my favourites (which seem to support renegotiation) are http://www.openssl.org/ and http://www.gnutls.org/ -- but no=20 doubt there are other ones that are equally good. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 09:54:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2pT-0001aj-Ql; Wed, 20 Dec 2006 09:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2pS-0001ad-CE for tls@ietf.org; Wed, 20 Dec 2006 09:53:58 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2pQ-0007Z3-08 for tls@ietf.org; Wed, 20 Dec 2006 09:53:58 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C8F271E8C5D; Wed, 20 Dec 2006 06:53:50 -0800 (PST) To: Peter Williams Subject: Re: [TLS] Comments on TLS identity protection References: From: Eric Rescorla Date: Wed, 20 Dec 2006 06:53:50 -0800 In-Reply-To: (Peter Williams's message of "Tue, 19 Dec 2006 22:54:21 -0800") Message-ID: <86bqlyk48x.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Williams writes: > Eric: > > I hope Im doing ok on CRLFs. I add them manually in my paragraphs, when I > remember. As far as I can determine , there is no way for a hotmail.com users > to meet the IETF usability rules (wordwrap before 65chars, affixing CRLF each line), > I'm happy to be shown how, tho, by power user! I'm keeping msn, tho, as it > gives me excellent IETF S/MIME from my EVDO PDA, via a webmail. Prehistoric technology, dude! OK, I'll try to adjust. >> > Peter Williams writes:> > Id say the nth handshake can select to send "no server cert" whenever its > > cooperating to complete an anonymous-ciphersuite-targeted handshake.> > So, assume there are only two ciphers suite values in the HSM : RSA, RSA-ANON. > > There is no such thing as RSA anon in SSLv3 or TLS. > For a long time Ive regarded SSLv3 as http://wp.netscape.com/eng/ssl3/3-SPEC.HTM#8-1 > Its an old bookmark! Here's the SSLv3 spec that I usually use as a reference. http://wp.netscape.com/eng/ssl3/draft302.txt You'll note that it's very similar to TLS :) > it doesnt even contain a set of ciphersuite declarations. It clearly > reinforces what I said tho: server cert presentation is ALWAYS optional > architecturally, and ServerKeyExchange is then used, instead. Netcape > documents were never particular formal! They were always in a rush. I don't agree with this interpretation. Here's the key text, from A.6. The following CipherSuite definitions require that the server provide an RSA certificate that can be used for key exchange. The server may request either an RSA or a DSS signature-capable certificate in the certificate request message. CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 10:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2we-00043i-2K; Wed, 20 Dec 2006 10:01:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx2wd-00043c-B9 for tls@ietf.org; Wed, 20 Dec 2006 10:01:23 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx2wc-0000OZ-BA for tls@ietf.org; Wed, 20 Dec 2006 10:01:23 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 20 Dec 2006 15:01:20 +0000 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; Wed, 20 Dec 2006 15:01:20 +0000 From: Stefan Santesson To: Mark Brown , 'EKR' , "tls@ietf.org" Date: Wed, 20 Dec 2006 15:00:32 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+gACTeRuA= Message-ID: References: <86ac1jr4jb.fsf@raman.networkresonance.com> <006701c723fc$31a55cc0$6801a8c0@rps.local> In-Reply-To: <006701c723fc$31a55cc0$6801a8c0@rps.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e 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 remain divided on this work. On one hand I recognize that implementing signing of exchanged content is a= very hard issue for many providers of internet services. Taking internet b= anks or public governmental services as an example, it is virtually impossi= ble to find an on the shelf generic solution that is compatible with all pl= atforms the user may have. Providing signing capacity on the TLS level may = therefore be a very interesting alternative to create signed records of tra= nsactions. In the end this is a matter of what is most effective. The problems rightfu= lly belongs on the application level and only the applications can determin= e intent and put signing in such a context that it becomes "evidence". On t= he other hand, all attempts to solve this in any generic way on the applica= tion level involves code that is not easily standardized. I have one strong opinion. Abandon the term "evidence" in this draft and it= would be much better. This draft is about adding signing capacity to TLS f= or selective data. I would strongly suggest moving to a terminology that re= flects the technical feature provided rather than the eventual legal conseq= uence. Then we can avoid the legal discussion of NR that has already started, whic= h I don't think belong here. Whether this turns out to be used as evidence = is completely up to the applications using this technology and should be to= tally out of scope for this document. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Mark Brown [mailto:mark@redphonesecurity.com] > Sent: den 20 december 2006 07:01 > To: 'EKR'; tls@ietf.org > Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 > > Eric, > > Thank you for your insight into technical weaknesses of the draft. I > tried > to address these inline, below. More broadly though, Why introduce > evidence > to TLS? Why ask for a WG charter extension for evidence? I need to > give an > argument (below) to answer these Why questions. Please bear with me. > > First, applications defer to TLS for good reason. The essay > "Programming > Satan's Computer" (Anderson & Needham, 1995) makes it clear that > devising > and implementing cryptographic protocols is difficult. TLS is so > simple to > use and ubiquitous that any user/anywhere can get a good secure socket > when > connecting to a TLS server. TLS hides from the user years of protocol > design, analysis and cryptanalysis, all of which is hard. It is a > brand > that users trust because TLS simply delivers good security for sockets > while > following an "It better just drop in and work" layered model. (SSL was > a > good name.) The "users" of TLS are not just people who use web > browsers. > TLS users are also the numerous application-level programs and > programmers > that depend on TLS to do the heavy lifting, implementing a > cryptographic > protocol in a Known Good way. > > Constructing digital evidence so that it deters frivolous repudiation > in a > legal setting is similarly difficult. In legal settings users need > evidence > -- not hearsay nor impossible "burdens of proof." Moreover, what > really > benefits users is evidence that any user/anywhere can read and > interpret > (even lawyers). Numerous past attempts have failed, and digital > evidence is > still a hotly contested topic of debate among expert lawyers. Sure, > every > bit of data is evidence at the start of a legal contest, but when > challenged, data often becomes worthless to the case -- or gets thrown > out. > While on the one hand lawyers are now crying for standard, open (did I > mention nonproprietary?) ways to create digital evidence, on the other > hand > many relevant standards remain unread, unimplemented and unused (e.g. > PKIX, > but many other standards specify digital signature methods too). You > said > well at USENIX 2003 much of what I'm repeating here. > > Why should we consider digital evidence a hard problem, a crypto > protocol > problem, a TLS problem? One crucial issue was raised by Steven Kent > last > year: the problem of the recording the signer's intent. Just to be > clear, > "signer's intent" problems include not only the challenge of recording > something intangible, or the possibility that garbage data was signed, > but > also claims that the system that created the digital signature was > subverted > - or used with an intention to defraud. I'm a newcomer to this party, > but I > don't think any previous standard solves this problem (I don't count > the NR > bit as solving the problem). Let us know... > > After pointing out this unsolved problem for constructors of digital > evidence, Kent then affirmed the convention of delegating this > seemingly > intractable problem to the application layer. "Signing things for > non-repudiation is usually an application-layer issue..." > (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty > sensible approach, I think. But to be perfectly honest, isn't > "application > layer" here a code word for "let them figure it out, we're not going to > waste any more time on this problem"? > > But now TLS Evidence can solve the "signer's intent" problems, and it > requires two parties, implying a network protocol connecting two > parties. > Or, I should say more conservatively, if TLS Evidence solves the > signer's > intent problems then I'd like to ask TLS WG to expand its charter to > address > evidence. Or better yet, would you all consider TLS Evidence to see if > it > solves the "signer's intent" problems? > > The solution to signer's intent lies in two parties using TLS Evidence > together with TLS Authorizations (see -01, 4.2. EvidenceRequest > Message, > field handshake_protocol_hash, pp 12-13). If the handshake contains > TLS > Authorizations that gain one party "access" then the record of that > handshake proves that the session was authorized-for something > specific. > Whatever that something specific is, that's the stated intent for this > session. Both parties agree to it -- one said "Authorize me to do > this" and > the other said, "Ok, I agree." If they don't agree, the session's over > before the handshake FINISHED pair. Pick any example you want: > authorized > to do online banking for my account; authorized to vote; authorized to > read > email; authorized to post to a blog; etc. There is more to say about > this... But the main point is this: Authorization always seems to > clarify > intent, that is, the intent of both parties. I think it's baked into > the > definition of authorization somehow. (I'm happy to discuss this more.) > > To sum up, I agree that evidence is not currently part of the WG > charter, > it's new, and deserves questioning like this. I have proposed in TLS > Evidence the solution to a hard problem and, as I see it, the solution > necessarily lives in a cryptographic protocol. I think it fits well > with > TLS successes as both easy to use and as hiding the challenges of > standardizing a cryptographic protocol well. But it's no doubt a > change in > the WG charter. Now it's up to the WG to answer our request that the > charter be expanded. > > On to your comments. Pertaining to signer's intent, you raised this > question: > > > S 1. > > It looks like the evidence creation has to involve signatures by > > both parties. Why not have it be one-way. > > My reasons for two signatures (countersignature) include: > > 1. Take as an example a military case where a Common Criteria EAL6 TLS > server and a non-evaluated TLS client exchange TLS Evidence. If only > the > client signs it, how much assurance do we have that the evidence is > correct? > None under the Common Criteria. But if the client asserts it and the > EAL6 > server countersigns it (using EvidenceResponse under TLS Evidence) now > we > have "high assurance" for the evidence, which both client and server > can > retain. In this scenario, the low-assurance party obtains high- > assurance > evidence just because it participated with a high-assurance server. I > call > this "assurance bootstrapping," and it can be a valuable service to the > client. I think this argument still carries the same weight even if > the > server is Known Good under some other current or future evaluation > system > (open source, peer review, etc.). > > 2. What if in the scenario above the transmission is the acceptance of > a > relatively small contract that, in its fine print, grants a huge amount > of > intellectual property rights to the military? And later the contractor > wants to repudiate the signature, claiming that the transaction was a > forgery? (This illustration is completely fictional.) If only the > high-assurance server signed the evidence then the contractor can say > that > someone else initiated that transaction, and the burden of proof rests > on > the military. But if the contractor chose his own key pair, and > registered > his own PKC, and used that registered PKC to sign EvidenceRequest under > TLS > Evidence it's harder to repudiate frivolously. Especially if the > contractor's PKC uses crypto stronger than the military can crack. > > 3. At a high level, two different parties signing the same thing forges > an > agreement -- both intrinsically and historically speaking. TLS > Evidence > proposes a standard for how to agree before evidence is born. This > includes: the handshake must have worked (and all that this implies). > The > evidence suite must have been used with mathematical precision, so the > encrypted and hashed outputs are correct. The timestamp must be > acceptable > to both parties. And so on. Successful TLS handshakes, especially > when > coupled with other TLS extensions such as TLS Authorizations as I've > mentioned, can be used to forge really specific agreements using TLS > Evidence. If we don't require two parties to sign, everything having > to do > with agreement over evidence drops out of the picture. This emphasis > on > agreement is not foreign to TLS, and I hope others agree that the use > of > agreement in the core TLS handshake(s) over the years has been a strong > security practice. I think agreement between client and server is a > strong > card to play for evidence as well. > > > Why not just store the traffic keys? > > No smoking gun stands out to me as I try to explain why > session-key-encrypted application data proves the identity of both > parties. > Following your book I can see how to derive the session key if I have > all > the right inputs, but working backwards from session key to identities > seems > harder. I take this to mean you'd need to hire a crypto expert (or TLS > expert) to explain it in court. This is all well and good in today's > legal > environment where that's the norm when you deal with data, but I'd like > to > propose a standard that makes cryptographic protocols EASY for the > user. > For evidence, "It better just drop in and work" in the courtroom, for > that > user too. For evidence, the user may be some small business that needs > to > encourage a huge organization to honor a deal they "inked" using TLS. > If a > small business owner can do a simple cryptographic verify operation on > TLS > Evidence structures using free tools and his own retained records, and > if > what he sees using freeware on a commodity computer will stand up to > fierce > scrutiny in court, then I think we've created evidence worthy of the > TLS > brand. In fact, that easy-to-use evidence may enable that small > business > owner to prevail in an out-of-court settlement, which benefits > everyone. > > With current and proposed TLS handshake extensions, the variety of > authentication and key derivation methods, and the indirect linkage > between > a session key and the client & server identities, I guess it would be > hard > to write a universal TLS evidence viewer that produced a smoking gun. > Especially if that viewer software must operate with high assurance, > say for > example, if the evidence is for a vote in an election recount > situation. > I'm not complaining, and I'm not opposed to others doing this. I just > think > that even if the traffic keys "work" at a crypto level they are complex > enough to not be useful to a wide range of evidence users (and > specifically > lawyers and juries without hiring an expert). > > > > ARCHITECTURAL COMMENTS > > I'm not particularly enamored of this general approach. The > > signatures in question are fundamentally an application-level > > construct: they're requested by the applications and > > ultimately consumed by them. > > I think of evidence like old tax returns. You are supposed to keep > them for > some number of years, so you file them in the garage/basement. The > last > time you read any of them was when you last signed them, except in > special > cases where having the old tax return proved really valuable. In my > view, > TLS layer checks the TLS Evidence as required by the Internet Draft, > refuses > the bad evidence, and writes the good evidence to a box in the garage > (using > some configuration flag at the TLS layer). > > Let me clarify expected operation. TLS Evidence requires participants > to > store evidence, and it requires configuration -- selecting targets -- > before > it starts creating evidence, but it does not require application > interaction. The usage model I anticipate for TLS Evidence is default > do-nothing. Until client (and server) both configure to client > authenticate > and to demand evidence when accessing specific domains/URIs, then > nothing > happens. TLS Evidence isn't something one party can demand with no > warning, > or from a stranger. Once the TLS layer is configured to demand > evidence in > some cases, now the app layer wants to see no traffic (for those cases) > unless the traffic passes the TLS Evidence tests. > > It is an unwarranted prejudice to hold that digital signatures must be > application-level constructs. (Just solve the signer's intent problem > though...) I believe and fully expect that the application layer > doesn't > want to have to check or otherwise process evidence - it wants TLS to > do > that since it's a Difficult Crypto Problem. If TLS can create > evidence, > then apps will shed the responsibility. It simply costs the app too > much to > invent its own crypto implementations and then adequately test them. > TLS > has quietly bubbled up to preferred status on many occasions; I can > think of > some Web Services standards that go into detail to explain how to do > crypto > and then tack on, "and TLS does this too and that's a good approach." > > > The only real reason to do > > this at the TLS layer is the sense that it's easier to deploy. > > I disagree. The reason an app wants TLS to solve a Difficult Crypto > Problem > is the raison d'etre of TLS. TLS makes the crypto problems easy (for > the > app), is a Known Good Way, and can handle the responsibilities of key > management & crypto. More than anything TLS is tested and approved. > Apps > can't duplicate this without great cost. > > > I'm not actually convinced that that's so, since this approach > > still requires modifying the applications to request security > > the signature/evidence services. > > > > In addition, putting this functionality at the TLS layer embodies > > some not-so-attractive tradeoffs, in particular, that the > > binding of application-layer messages to the actual evidence > > provided isn't particularly tight, since the signatures cover extents > > of the traffic rather than messages. This introduces a number of > > race conditions which are only partially solved by the > > interlocking alerts used here. Among these are: > > > > - The sender of the start1 alert has only minimal > > information/control over when the peer will start signing traffic. > > - It's quite likely that one side will have to process messages > > without knowing whether the peer will actually sign his > > section of the traffic. This is obviously a problem if you > > are producing side effects. You can mitigate this problem > > only by doing two evidence collections in lockstep. > > - Applications need a bunch of new logic to detect the evidence > > request but hold their response to application-layer boundaries. > > This cannot be implemented at the TLS layer. > > - If you want to condition your application-layer responses > > to whether the peer provided a signature you need some way > > to provide application-layer "please resend with signature". > > This is a common case but can only be dealt with very > > clumsily here. > > Some of these scenarios seem incongruous with mutual authentication and > some > form of TLS Authorization (as recommended in TLS Evidence). Please > give > more information about the scenarios you are thinking of here. > > > > > This seems like a fairly large architectural change to TLS to > > make it do something it was never designed to do and which > > can be done better in the application. > > > > > > DETAILED COMMENTS > > S 1. > > It looks like the evidence creation has to involve signatures by > > both parties. Why not have it be one-way. > > See above. > > > > > S 1.2. > > Generating evidence is not compatible with Diffie-Hellman > Ephemeral > > (DHE) key exchanges. DHE does not permit the same keying material > to > > be generated for validation of the evidence after the TLS session > is > > over. Persistent evidence requires the use of a digital signature > so > > that it can be validated well after the TLS session is over. > > > > Why not just store the traffic keys? > > See above. > > > > > > > Figure 1 would be better with some markers about the traffic > > segments that are signed. > > Ok. > > > > > S 2. > > I'm uncomfortable with the idea if "evidence suites" and later > > of new certificates and certificate negotiation. This seems > > like you're layering an entirely new protocol over TLS. > > Using the same two certs for both authentication and signing is simple > and > preferable in most cases. Ditto for cipher suite & evidence suite. > However, sometimes you might prefer a null ciphersuite but want > evidence > (transfer of an already-encrypted file). In a military case, you may > need > to call the function that checks EvidenceRequest via RPC, in which case > using different PKCs is nice to avoid private key sharing. There are > some > weird cases where this flexibility is nice to have. > > > > > S 3. > > This consumes 4 new alerts. The space isn't that big. > > Since you're already defining a new protocol type, these > > messages might as well be part of that protocol. > > Let's flesh this out a bit more. Whatever is best. > > > > > S A. > > Defining cipher suites with key lengths attached to them > > isn't hte TLS way. > > In this case, using poor crypto actually hurts your partner if you're > the > one whose going to repudiate with evil intent. That's reversed from > the > normal TLS model, and why TLS Evidence is stringent where TLS > historically > has been able to be loose. Parties need to protect themselves by > demanding > what they consider to be strong asymmetric crypto. > > > > > > > -Ekr > > > > Best regards, > > --mark > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 10:07:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx31z-0007Q2-0M; Wed, 20 Dec 2006 10:06:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx31x-0007Pv-HP for tls@lists.ietf.org; Wed, 20 Dec 2006 10:06:53 -0500 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 1Gx31w-00017p-2l for tls@lists.ietf.org; Wed, 20 Dec 2006 10:06:53 -0500 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 kBKF5NPL032439; Wed, 20 Dec 2006 17:05:55 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 17:05:58 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 17:05:58 +0200 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] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 anddraft-rescorla-tls-suiteb-00 Date: Wed, 20 Dec 2006 17:05:58 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 anddraft-rescorla-tls-suiteb-00 Thread-Index: Acci9ipnWsxB0GWGRDWqk/HpfbUZMABUTzAw From: To: X-OriginalArrivalTime: 20 Dec 2006 15:05:58.0672 (UTC) FILETIME=[5B061900:01C72448] X-Nokia-AV: Clean X-Spam-Score: 1.3 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 I sort of agree with what Peter already said about the opaque-prf-input draft. It is clearly the "lower layer" of some mechanism for doing something useful. It's not useful if we don't=20 know what the "upper layer", "some mechanism" or "something useful"=20 are, and without knowing those, it's very difficult to comment the=20 draft or support its advancement. So, more details would be very welcome!=20 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 10:30:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3OA-0002z5-Uw; Wed, 20 Dec 2006 10:29:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3O9-0002yz-CH for tls@ietf.org; Wed, 20 Dec 2006 10:29:49 -0500 Received: from bay0-omc3-s34.bay0.hotmail.com ([65.54.246.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3O4-0005OB-Gn for tls@ietf.org; Wed, 20 Dec 2006 10:29:49 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 07:29:43 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , Subject: RE: [TLS] Comments on TLS identity protection Date: Wed, 20 Dec 2006 07:29:43 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 15:29:43.0813 (UTC) FILETIME=[AC795B50:01C7244B] X-Spam-Score: 2.4 (++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1902250087==" Errors-To: tls-bounces@lists.ietf.org --===============1902250087== Content-Type: multipart/alternative; boundary="_54d7004f-36cf-461c-b5ed-5f3a5783ae52_" --_54d7004f-36cf-461c-b5ed-5f3a5783ae52_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Netscape and Microsoft always took different approaches to https, and TLS. = You can, too! For Netscape,=20 they really never moved beyond writing a common client-side library, that s= melled like a socket, but got managed like any winform or adminwebsite. The lib was always used t= o secure-enable an=20 app [platform], versus be a protocol layer. And this was despite their exce= llent stack-architecture (as=20 the patent shows!); and the MSFT-produced implementation of the platform ev= en in winsock! For Microsoft, they contrasted Netscape's "application-centric platform making" by putting= SSL and SSL CSPs into the OS platform, so it could be properly evaluated under CC like all t= he rest of the B1-grade OS security features that Windows NT was approaching at that point. For Netsca= pe, FIPS-mode was really as far as they got with assurance doctrine; for Microsoft (MSFT = UK in particular, and the UK=20 eval labs), meeting assurance standards, architecturally and functionally, = was the whole game. Evaluating the=20 network component of a trusted commodity OS was not hard science, at that p= oint. There was=20 a enormous amount work done in this area, for NT 4.0, and then again for NT= 4 SP4. This is all junk Internet history. But, SSL has always been a very varied c= amp, as you would expect from something capable of being an Internet Standard. It has a momentum of = its own, because of something architecturally "right". Kipp H (who I never met) and = Tajer did something=20 very special. It would not have made it to SSL3 without the Wienstiens, and= their hypermedia orientation.=20 Tim D and co, with SSLRef and those early VeriSign security audits! and the= 2 nameless Australian breathren, of=20 course! And, lets not forget the other Eric! Eric R.'s work with Alan Schif= fman for DARPA were all part of the early argument that became the mainstay of NS vs MSFT,= choosing between=20 application vs OS/stack solutions for SPs. I still remember the first time = I ever heard of=20 SSL...in Eric's/Alan's lecture, launching shttp version dot-something, by c= ompare and contrast! I dont recall if this was late 94, or 95; though it would not be hard to find out,= given the "searchable record=20 system" known as the Internet. =20 This all seemed bizzare to the world I was looking at, which was all about = repurposing NSA's TLSP , fathoming=20 ongoing NLSP standards in ISOland, and figuring what all the legacy "weird"= key management protocol stuff from the Motorola/BBN/GTE security groups was all about, and= its (then) weird access=20 control concept, via key management! =20 And none of that would have mattered if the MSFT team (which I knew very we= ll) had not been competing at the architectural level: on the the grounds of "platform-= to-platform,"=20 "belief system" to "belief system" about what grandma really needs from a P= C. IETF gave the standard the wrong name. As that benchmark of security argume= nt, known as=20 David Kemp, once erred: the "Session Layer Socket" protocol does X.... =20 > To get widespread deployment, several TLS implementations would > have to= be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, > JSSE, GnuTLS,= etc. Getting any change, no matter how "minimal", > to them is not easy.> = > > > I think deployment-wise, double handshake has the advantage > > > tha= t it's already specified and implemented.> > > > Any link to test the imple= mentation, please?> > Pick your favorite TLS implementation! There are at l= east> couple of dozen of them (though probably not all of them> support ren= egotiation). > > Some of my favourites (which seem to support renegotiation= )> are http://www.openssl.org/ and http://www.gnutls.org/ -- but no > doubt= there are other ones that are equally good.> > Best regards,> Pasi> > ____= ___________________________________________> TLS mailing list> TLS@lists.ie= tf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Try amazing new 3D maps http://maps.live.com/?wip=3D51= --_54d7004f-36cf-461c-b5ed-5f3a5783ae52_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
 
Netscape and Microsoft always took different approaches to https, and TLS. = You can, too! For Netscape,
they really never moved beyond writing a common client-side library, that s= melled like a socket,
but got managed like any winform or adminwebsite. The lib was always used t= o secure-enable an
app [platform], versus be a protocol layer. And this was despite their exce= llent stack-architecture (as
the patent shows!); and the MSFT-produced implementation of the platform ev= en in winsock! For Microsoft,
they contrasted Netscape's "application-centric platform making" by putting= SSL and SSL CSPs
into the OS platform, so it could be properly evaluated under CC like all t= he rest of the B1-grade OS
security features that Windows NT was approaching at that point. For Netsca= pe, FIPS-mode
was really as far as they got with assurance doctrine; for Microsoft (MSFT = UK in particular, and the UK
eval labs), meeting assurance standards, architecturally and functionally, = was the whole game. Evaluating the
network component of a trusted commodity OS was not hard science, at t= hat point. There was
a enormous amount work done in this area, for NT 4.0, and then again for NT= 4 SP4.

This is all junk Internet history. But, SSL has always been a very vari= ed camp, as you would expect
from something capable of being an Internet Standard. It has a momentum of = its own,
because of something architecturally "right". Kipp H (who I never met) and = Tajer did something
very special. It would not have made it to SSL3 without the Wienstiens, and= their hypermedia orientation.
Tim D and co, with SSLRef and those early VeriSign security audits! and the= 2 nameless Australian breathren, of
course! And, lets not forget the other Eric! Eric R.'s work with Alan Schif= fman for DARPA
were all part of the early argument that became the mainstay of NS vs MSFT,= choosing between
application vs OS/stack solutions for SPs. I still remember the first time = I ever heard of
SSL...in Eric's/Alan's lecture, launching shttp version dot-something, by c= ompare and contrast! I dont
recall if this was late 94, or 95; though it would not be hard to find out,= given the "searchable record
system" known as the Internet.
 
This all seemed bizzare to the world I was looking at, which was all about = repurposing NSA's TLSP , fathoming
ongoing NLSP standards in ISOland, and figuring what all the legacy "weird"= key management
protocol stuff from the Motorola/BBN/GTE security groups was all about, and= its (then) weird access
control concept, via key management!
 
And none of that would have mattered if the MSFT team (which I knew very we= ll) had not
been competing at the architectural level: on the the grounds of "platform-= to-platform,"
"belief system" to "belief system" about what grandma really needs from a P= C.

IETF gave the standard the wrong name. As that benchmark of security argume= nt, known as
David Kemp, once  erred: the "Session Layer Socket" protocol does X...= .
 

> To get widespread deployment, several TLS implementations would
&g= t; have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS,
&= gt; JSSE, GnuTLS, etc. Getting any change, no matter how "minimal",
>= ; to them is not easy.
>
> > > I think deployment-wise, = double handshake has the advantage
> > > that it's already spe= cified and implemented.
> >
> > Any link to test the imp= lementation, please?
>
> Pick your favorite TLS implementation= ! There are at least
> couple of dozen of them (though probably not a= ll of them
> support renegotiation).
>
> Some of my fav= ourites (which seem to support renegotiation)
> are http://www.openss= l.org/ and http://www.gnutls.org/ -- but no
> doubt there are other = ones that are equally good.
>
> Best regards,
> Pasi
= >
> _______________________________________________
> TLS m= ailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailma= n/listinfo/tls


Try amazing new 3D maps Check it out! = --_54d7004f-36cf-461c-b5ed-5f3a5783ae52_-- --===============1902250087== 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 --===============1902250087==-- From tls-bounces@lists.ietf.org Wed Dec 20 10:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3Zd-0000Vz-Fj; Wed, 20 Dec 2006 10:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3Zb-0000Vf-Cs for tls@ietf.org; Wed, 20 Dec 2006 10:41:39 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3ZZ-0007Zx-W0 for tls@ietf.org; Wed, 20 Dec 2006 10:41:39 -0500 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 QAA65044 ; Wed, 20 Dec 2006 16:40:13 +0100 Message-ID: <458959A2.8020309@isima.fr> Date: Wed, 20 Dec 2006 16:41:22 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Comments on TLS identity protection References: 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 QAA65044 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 : >> I disagree. Anybody can connect to your server at any time and >> doing uncompleted double handshake. It is not a rare situation. >> =20 > > Do you have any data to back that claim?=20 No, unfortunately. > The fact that anybody can > connect at any time does not automatically imply that lots of people > are connecting all the time!=20 > (And in particular, lots of people without client certificates connecti= ng all the time to servers that always require client > authentication, and without malicious intent to DoS the server.) > =20 But the "anybody" that can connect at any time will be able to establish=20 several "double handshake" in parallel; especially when TLS is used over=20 EAP or UDP (I don't have data but maybe Eric). My point is that double handshake will increase complexity and will not=20 help in reducing TLS server overload factor, especially when legitimate=20 clients that don't have certificates are trying to connect. Their number=20 is not actually important. >>> (at least sufficiently to spend the $$$ for designing,=20 >>> implementing, testing, deploying, etc. a new mechanism). >>> =20 >> How much :). The proposed changes are minimal. >> =20 > > To get widespread deployment, several TLS implementations would=20 > have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS,=20 > JSSE, GnuTLS, etc. Getting any change, no matter how "minimal",=20 > to them is not easy. > =20 I don't see the point here. Any TLS feature will require updating TLS=20 implementations. > Best regards, > Pasi > > =20 Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 11:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3zJ-0006el-KQ; Wed, 20 Dec 2006 11:08:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3zG-0006ed-NU for tls@ietf.org; Wed, 20 Dec 2006 11:08:11 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3zF-0003Bg-Cn for tls@ietf.org; Wed, 20 Dec 2006 11:08:10 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 973641E8C5D; Wed, 20 Dec 2006 08:08:08 -0800 (PST) To: badra Subject: Re: [TLS] Comments on TLS identity protection References: <458959A2.8020309@isima.fr> From: Eric Rescorla Date: Wed, 20 Dec 2006 08:08:08 -0800 In-Reply-To: <458959A2.8020309@isima.fr> (badra@isima.fr's message of "Wed, 20 Dec 2006 16:41:22 +0100") Message-ID: <86slfaim8n.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org badra writes: > Pasi.Eronen@nokia.com a =E9crit : >> The fact that anybody can >> connect at any time does not automatically imply that lots of people >> are connecting all the time! (And in particular, lots of people >> without client certificates connecting all the time to servers that >> always require client >> authentication, and without malicious intent to DoS the server.) >> > But the "anybody" that can connect at any time will be able to > establish several "double handshake" in parallel; especially when TLS > is used over EAP or UDP (I don't have data but maybe Eric). > > My point is that double handshake will increase complexity and will > not help in reducing TLS server overload factor, especially when > legitimate clients that don't have certificates are trying to > connect. Their number is not actually important. Wait, there are two issues here: 1. General server load in the absence of malicious behavior. As Pasi points out, there's no evidence that the double handshake technique is widely enough used to cause this to be a problem. 2. Enabling DoS attacks. There are lots of ways to DoS a TLS server, and since this only doubles server load,=20 I don't think it's much of an amplifier. >>>> (at least sufficiently to spend the $$$ for designing, >>>> implementing, testing, deploying, etc. a new mechanism). >>>> >>> How much :). The proposed changes are minimal. >>> >> >> To get widespread deployment, several TLS implementations would have >> to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, JSSE, >> GnuTLS, etc. Getting any change, no matter how "minimal", to them is >> not easy. >> > > I don't see the point here. Any TLS feature will require updating TLS > implementations. Right, which is why it's a good idea to avoid making changes unless we have to. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 11:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4CK-000411-Um; Wed, 20 Dec 2006 11:21:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4CJ-00040w-Hn for tls@ietf.org; Wed, 20 Dec 2006 11:21:39 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx4CI-0005RT-65 for tls@ietf.org; Wed, 20 Dec 2006 11:21:39 -0500 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 RAA20212 ; Wed, 20 Dec 2006 17:20:04 +0100 Message-ID: <458962F9.9070805@isima.fr> Date: Wed, 20 Dec 2006 17:21:13 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Comments on TLS identity protection References: <458959A2.8020309@isima.fr> <86slfaim8n.fsf@raman.networkresonance.com> In-Reply-To: <86slfaim8n.fsf@raman.networkresonance.com> 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 RAA20212 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Eric Rescorla writes: > badra writes: > =20 >> Pasi.Eronen@nokia.com a =E9crit : >> =20 > Right, which is why it's a good idea to avoid making changes unless > we have to. > =20 OK Eric, but extending and changing TLS are two different jobs for me:) Besr regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 11:23:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4Db-00074o-D1; Wed, 20 Dec 2006 11:22:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4DZ-00074b-K7 for tls@ietf.org; Wed, 20 Dec 2006 11:22:57 -0500 Received: from bay0-omc3-s41.bay0.hotmail.com ([65.54.246.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx4DY-0005a8-3j for tls@ietf.org; Wed, 20 Dec 2006 11:22:57 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc3-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 08:22:55 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Stefan Santesson , Mark Brown , "tls@ietf.org" Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 20 Dec 2006 08:22:55 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 16:22:55.0845 (UTC) FILETIME=[1B12C950:01C72453] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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: , Content-Type: multipart/mixed; boundary="===============0553398787==" Errors-To: tls-bounces@lists.ietf.org --===============0553398787== Content-Type: multipart/alternative; boundary="_4d54fec0-00e2-4c07-bf74-ae177c4f367f_" --_4d54fec0-00e2-4c07-bf74-ae177c4f367f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan: =20 Mark Brown is making a case, using legal argumentation style, for changing = the charter, postulating a new "stasis of definition".=20 Its a refined form of argument we dont use in IETF, mostly cos uz programma= s dunno howzit dun, tho it is seen in usenet culture still. The essay was beautifully crafted. It gives good reasons for changin= g the way we think. It will fail, tho; given IETF's inbred war mentality. Rhetoric vs political regimes found on wars-on-X: these nev= er go together in the same argumentation bed. =20 If we assume the Zarefsky-ian teaching on handling claims and evidence in u= ncertain arguments (like the internet! not=20 cryptography! not! TPM's limited concepts of technical evidence), the work = certainly-might be *effectively* handled=20 in WS-SX forum within OASIS. There, much of the same architecture and mech= anisms as SSL considered are being revisited, without DARPA dogma and DoD legacy issues, and within a revised set of func= tions for the upper layers of the stack. It would be a good fit, perhaps only because of IETF's angst over the NR topic - which I = got nicely tied in the consciousness to the associated possibility of it becoming an easy basis for mandatory key escrow (via certs.). Its als= o "application layer" (where the single app layer=20 got split into 7 sublayers doing communication protocols, to be true!). Its= also not US centric, which is important for the next generation internet. =20 The new "socket" is perhaps what the web architect's intended: the URI! (an= d the strongly-named URI! with secureConversation's=20 rendition of SSL handshakes). =20 That new socket can have mandatory spying and recording built in, for all I= care. Just, now, grandma will know=20 it and accept it, socially; she will not be part of a social structure fou= nded on deception. She can then even benefit from=20 its flip side: NR (or probative internet evidence (PIE), or whichever new m= oniker becomes established) =20 =20 Peter. =20 =20 > From: stefans@microsoft.com> To: mark@redphonesecurity.com; ekr@networkre= sonance.com; tls@ietf.org> Date: Wed, 20 Dec 2006 15:00:32 +0000> Subject: = RE: [TLS] Please discuss: draft-housley-evidence-extns-00> CC: > Then we ca= n avoid the legal discussion of NR that has already started, which I don't = think belong here. Whether this turns out to be used as evidence is complet= ely up to the applications using this technology and should be totally out = of scope for this document.> > > Stefan Santesson> Senior Program Manager> = Windows Security, Standards _________________________________________________________________ Get into the holiday spirit, chat with Santa on Messenger. http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=3Den-= us= --_4d54fec0-00e2-4c07-bf74-ae177c4f367f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan:
 
Mark Brown is making a case, using legal argumentation style, for chan= ging the charter, postulating a new "stasis of definition".
Its a refined form of argument we dont use in IETF, mostly cos uz programma= s dunno howzit dun, tho it is seen in usenet culture
still. The essay was beautifully crafted. It gives good reasons for changin= g the way we think. It will fail, tho; given IETF's inbred
war mentality. Rhetoric vs political regimes found on wars-on-X: = these  never go together in the same argumentation
bed.
 
If we assume the Zarefsky-ian teaching on handling claims and evidence in u= ncertain arguments (like the internet! not
cryptography! not! TPM's limited concepts of technical evidence), the work = certainly-might be *effectively* handled
in WS-SX  forum within OASIS. There, much of the same architecture and= mechanisms as SSL considered are being revisited,
without DARPA dogma and DoD legacy issues, and within a revised set of= functions for the upper layers of the stack. It would be a
good fit, perhaps only because of IETF's angst over the NR topic - which I = got nicely tied in the consciousness to the associated possibility
of it becoming an easy basis for mandatory key escrow (via certs.). Its als= o "application layer" (where the single app layer
got split into 7 sublayers doing communication protocols, to be true!). Its= also not US centric, which is important for the next
generation internet.
 
The new "socket" is perhaps what the web architect's intended: the URI! (an= d the strongly-named URI! with secureConversation's
rendition of SSL handshakes).
 
That new socket can have mandatory spying and recording built in, for all I= care. Just, now, grandma will know
it and accept it,  socially; she will not be part of a social structur= e founded on deception. She can then even benefit from
its flip side: NR (or probative internet evidence (PIE), or whichever new m= oniker becomes established)
 
 
Peter.
 
 

> From: stefans@microsoft.com
> To: mark@redphonesecurity.com; ekr= @networkresonance.com; tls@ietf.org
> Date: Wed, 20 Dec 2006 15:00:32= +0000
> Subject: RE: [TLS] Please discuss: draft-housley-evidence-ex= tns-00
> CC:
> Then we can avoid the legal discussion of NR th= at has already started, which I don't think belong here. Whether this turns= out to be used as evidence is completely up to the applications using this= technology and should be totally out of scope for this document.
> <= BR>>
> Stefan Santesson
> Senior Program Manager
> Wi= ndows Security, Standards



Get into the holiday spiri= t, chat with Santa on Messenger.=A0 Ho-Ho-Ho= ! = --_4d54fec0-00e2-4c07-bf74-ae177c4f367f_-- --===============0553398787== 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 --===============0553398787==-- From tls-bounces@lists.ietf.org Wed Dec 20 11:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4Vm-0008Nq-O5; Wed, 20 Dec 2006 11:41:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx4Vl-0008Li-Un for tls@ietf.org; Wed, 20 Dec 2006 11:41:45 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx4Vk-0000Du-Bc for tls@ietf.org; Wed, 20 Dec 2006 11:41:45 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id RAA13169; Wed, 20 Dec 2006 17:40:55 +0100 (MEZ) From: Martin Rex Message-Id: <200612201640.RAA18078@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection To: badra@isima.fr (badra) Date: Wed, 20 Dec 2006 17:40:55 +0100 (MET) In-Reply-To: <458959A2.8020309@isima.fr> from "badra" at Dec 20, 6 04:41:22 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: de4f315c9369b71d7dd5909b42224370 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 badra wrote: > > > To get widespread deployment, several TLS implementations would > > have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, > > JSSE, GnuTLS, etc. Getting any change, no matter how "minimal", > > to them is not easy. > > > > I don't see the point here. Any TLS feature will require updating TLS > implementations. The point is, that by using renegotiation (=double handshake) to protect the client identity, no code changes are necessary, this should already work with most of the installed base, even with many/most pure SSLv3 client implementations. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 12:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx55h-0001gk-RG; Wed, 20 Dec 2006 12:18:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx55g-0001gT-5J for tls@ietf.org; Wed, 20 Dec 2006 12:18:52 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx55b-0006Sc-FI for tls@ietf.org; Wed, 20 Dec 2006 12:18:52 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id A871783B4; Wed, 20 Dec 2006 11:18:42 -0600 (CST) From: "Mark Brown" To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Wed, 20 Dec 2006 11:20:08 -0600 Message-ID: <009201c7245b$192dbc00$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+gACTeRuAAAMk8IAAEMZKw X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Stefan, (resend, to tls@ietf.org, with additions to the first paragraph) Thanks for your helpful comments. I don't agree entirely with you, specifically your position that signatures are (must be?) application level constructs, but you're probably in the majority on this issue. My opinion is based on personal experience though. I am working on a router project that uses TLS Evidence and Authorizations at the TLS level only: http://www.navysbir.com/06_1/215.htm The router works below the application-level and aims at high assurance under Common Criteria, e.g. EAL6. Its design and implementation has been and will continue to be carefully scrutinized. This project does not depend on "signer's intent" though, and perhaps intent is what you locate at the application level? I think you're right about this: the wisest choice may be to wait and see how things pan out in the legal community, and not try to extract a final answer from them too soon. Would the TLS WG be willing to extend the charter for evidence even if a large part of the discussion was hosted by a lawyer community and could take some time to hash out? For those of you who are interested in the legal aspect of "evidence", I am currently engaged in conversation with the American Bar Association's Information Security Committee listserv. If you would like to enter that discussion, please let me know. The ABA ISC discussion has recently rehashed the use of the term "evidence" with respect to TLS Evidence. To summarize that discussion as fairly as I can, I think as long as one spells evidence with a lowercase "e" and not as Evidence or EVIDENCE the lawyers on the ISC listserv are comfortable with the term. I also plan to work closely with the ABA Digital Evidence Project over the next year as well, and my first project with DEP is to hash out terms together. The following is a snippet -- really, a teaser -- for those of you with some inclination to join the ABA ISC group: (mark) > The TLS definition of "evidence" is unstated to allow it to flex with the > prevailing > definition in the legal world (this decade's definition or the next's). > > You say the definition of evidence is anything that can be "thrown into > the > pot", which seems reasonable to me. > (Steven Teppler) > > First, what is unknown is the definition of "evidence" as the technical > > protocol means it. In the legal world, anything can be, and usually > > thrown > > into the pot as, evidence. How is this specie of evidence different > from > > other evidence? > (mark) > TLS Evidence does not claim some special privilege e.g. being > non-repudiable. It's just evidence like everything else in the pot. The > specter of duress is never eliminated, for example. How could it be? > Neither does TLS Evidence claim any special privileges to magically gain > affirmatives to any of the following: > (Steven Teppler) > > Is EG'd evidence automatically admissible? Does it > > automatically exclude contradictory digital data or testimony? Does it > > generate enough evidence to survive a summary judgment motion? Does it > > satisfy a burden of production? Burden of persuasion? If so, why isn't > > some modifier, such as "trusted evidence" or "summary judgment > eliminator" > > used? > (mark) > No thank you! If a court chose to admit TLS Evidence into a trial then > that > court could examine it as a record like anything else. The TLS Evidence > draft standard _only_ defines a minimum technical standard for security > measures including cryptographic/equality tests which must be passed > before TLS Evidence is "born". Best regards, mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 12:44:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5Te-0007Om-S9; Wed, 20 Dec 2006 12:43:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5Te-0007NA-6O for tls@ietf.org; Wed, 20 Dec 2006 12:43:38 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx5Tc-0000xh-R5 for tls@ietf.org; Wed, 20 Dec 2006 12:43:38 -0500 Received: by nz-out-0506.google.com with SMTP id z6so971756nzd for ; Wed, 20 Dec 2006 09:43:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=HuqdApSj/4l3eGNEeYhr6BF7y2zvaeGUIHtGQ5McqDYyFrUZ2nLH16hh4cYQg7D/k0ukZrrlePlOJ+0KK8REPN5HHFmsFZpoNEWTuVFJ1qbqPaQtEmi67oXdQ5xflQcT3xfB/xR+ygWxZYTza31xZIU7teRv6DTWM4IWwiZh/0M= Received: by 10.64.249.18 with SMTP id w18mr9784649qbh.1166636614029; Wed, 20 Dec 2006 09:43:34 -0800 (PST) Received: by 10.65.230.7 with HTTP; Wed, 20 Dec 2006 09:43:33 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 18:43:33 +0100 From: Badra To: martin.rex@sap.com Subject: Re: [TLS] Comments on TLS identity protection In-Reply-To: <200612201640.RAA18078@uw1048.wdf.sap.corp> MIME-Version: 1.0 References: <458959A2.8020309@isima.fr> <200612201640.RAA18078@uw1048.wdf.sap.corp> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1870398073==" Errors-To: tls-bounces@lists.ietf.org --===============1870398073== Content-Type: multipart/alternative; boundary="----=_Part_20970_15556437.1166636613955" ------=_Part_20970_15556437.1166636613955 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/20/06, Martin Rex wrote: > badra wrote: > > > > > To get widespread deployment, several TLS implementations would > > > have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, > > > JSSE, GnuTLS, etc. Getting any change, no matter how "minimal", > > > to them is not easy. > > > > > > > I don't see the point here. Any TLS feature will require updating TLS > > implementations. > > The point is, that by using renegotiation (=double handshake) > to protect the client identity, no code changes are necessary, > this should already work with most of the installed base, > even with many/most pure SSLv3 client implementations. I think we can stop argumanting on the (to be extended) code :) Best regards, Badra ------=_Part_20970_15556437.1166636613955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 12/20/06, Martin Rex <martin.rex@sap.com> wrote:
badra wrote:
>
> > To get widespread deployment, several TLS implementations would
> > have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS,
> > JSSE, GnuTLS, etc. Getting any change, no matter how "minimal",
> > to them is not easy.
> >
>
> I don't see the point here. Any TLS feature will require updating TLS
> implementations.

The point is, that by using renegotiation (=double handshake)
to protect the client identity, no code changes are necessary,
this should already work with most of the installed base,
even with many/most pure SSLv3 client implementations.
 
 

 
I think we can stop argumanting on the (to be extended) code :)

 

Best regards,
Badra
------=_Part_20970_15556437.1166636613955-- --===============1870398073== 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 --===============1870398073==-- From tls-bounces@lists.ietf.org Wed Dec 20 12:45:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5VL-000840-1z; Wed, 20 Dec 2006 12:45:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5VK-00083v-3m for tls@ietf.org; Wed, 20 Dec 2006 12:45:22 -0500 Received: from bay0-omc1-s16.bay0.hotmail.com ([65.54.246.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx5VH-000174-LD for tls@ietf.org; Wed, 20 Dec 2006 12:45:22 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc1-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 09:45:19 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mark Brown , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Wed, 20 Dec 2006 09:45:18 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 17:45:19.0080 (UTC) FILETIME=[9D789680:01C7245E] X-Spam-Score: 2.4 (++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: , Content-Type: multipart/mixed; boundary="===============0994333247==" Errors-To: tls-bounces@lists.ietf.org --===============0994333247== Content-Type: multipart/alternative; boundary="_10b89634-f717-425d-b23d-8e996cfbae76_" --_10b89634-f717-425d-b23d-8e996cfbae76_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > I think you're right about this: the wisest choice may be to wait and see= > how things pan out in the legal community, and not try to extract a final= > answer from them too soon. Would the TLS WG be willing to extend the> cha= rter for evidence even if a large part of the discussion was hosted by a> l= awyer community and could take some time to hash out? No; is my vote. The legal community would have to join the argumentation ru= les of IETF.=20 These are mostly unpalatable to the bar-regulated lawyer, however. Just as = lawyers=20 discriminate against non professionals, they tend to be similarly discrimin= ated against=20 in turn, by other professions that reject the very speech restrictions impo= sed on=20 the bar-regulated lawyer. IETF uses certain argumentation forms and commun= ication=20 media to garner consensus about what is best - like an open golf tournament= - and, without=20 which we could not do our engineering job on a problem the scale of the int= ernet phenomenon.=20 IETF is a fulcrum of social politics, and, despite my oft heady criticism,= it works. As much as=20 I criticise IETF, I still say "we". Lawyers would have to be seen to do the= same. =20 You are the second person I've met as an email persona, who probably has a = special,=20 personal talent to bridge these two worlds of WGs. You can be a we, in bot= h worlds; I firmly believe that. =20 There is a possibility of IAB-level liaison, tho. Its an IETF communication= channel that transcends WGs and mailing lists. We mere mortals in the IETF mailing = list=20 trenches dont get a lot of say, there, tho. The last attempt, ITU-IETF for= the=20 benefit of ENUM WG, really didn't do that well. Extra-IETF structures for = other forms of external liason (ICANN, etc) similarly are struggling to find work= ing=20 political mechanism. (It broke my heart to see ICANN and VeriSign in litiga= tion.) _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=3Dimprove&local= e=3Den-US&source=3Dwlmemailtaglinenov06= --_10b89634-f717-425d-b23d-8e996cfbae76_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
> I think you're right about this: the wisest choice may be to wait and = see
> how things pan out in the legal community, and not try to extra= ct a final
> answer from them too soon. Would the TLS WG be willing t= o extend the
> charter for evidence even if a large part of the discu= ssion was hosted by a
> lawyer community and could take some time to = hash out?

No; is my vote. The legal community would have to join the argumentation ru= les of IETF.
These are mostly unpalatable to the bar-regulated lawyer, however. Just as = lawyers
discriminate against non professionals, they tend to be similarly discrimin= ated against
in turn, by other professions that reject the very speech restrictions impo= sed on
the bar-regulated lawyer.  IETF uses certain argumentation f= orms and communication
media to garner consensus about what is best - like an open golf tournament= - and, without
which we could not do our engineering job on a problem the scale of the int= ernet phenomenon.
IETF is a fulcrum of social politics, and,  despite my oft heady criti= cism, it works. As much as
I criticise IETF, I still say "we". Lawyers would have to be seen to do the= same.
 
You are the second person I've met as an email persona, who probably h= as a special,
personal talent to bridge  these two worlds of WGs. You can be a we, i= n both worlds; I
firmly believe that.
 
There is a possibility of IAB-level liaison, tho. Its an IETF communication= channel
that transcends WGs and mailing lists. We mere mortals in the IETF mailing = list
trenches dont  get a lot of say, there, tho. The last attempt, ITU-IET= F for the
benefit of ENUM WG,  really didn't do that well. Extra-IETF structures= for other
forms of external liason (ICANN, etc) similarly are struggling to find work= ing
political mechanism. (It broke my heart to see ICANN and VeriSign in litiga= tion.)


View Athletes' Collections with Live Search. See it! = --_10b89634-f717-425d-b23d-8e996cfbae76_-- --===============0994333247== 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 --===============0994333247==-- From tls-bounces@lists.ietf.org Wed Dec 20 13:01:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5k7-0007hI-4C; Wed, 20 Dec 2006 13:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5k5-0007gx-Eo for tls@ietf.org; Wed, 20 Dec 2006 13:00:37 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx5k2-0002eJ-VB for tls@ietf.org; Wed, 20 Dec 2006 13:00:37 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 20 Dec 2006 10:00:34 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.24; Wed, 20 Dec 2006 10:00:33 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Wed, 20 Dec 2006 10:00:33 -0800 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] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Wed, 20 Dec 2006 10:00:32 -0800 Message-ID: <802A881C87166D4597F9EEFC3F04F4F80347EB77@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <009201c7245b$192dbc00$6801a8c0@rps.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+gACTeRuAAAMk8IAAEMZKwAAGX1QA= References: <009201c7245b$192dbc00$6801a8c0@rps.local> From: Ari Medvinsky To: Mark Brown , X-OriginalArrivalTime: 20 Dec 2006 18:00:33.0959 (UTC) FILETIME=[BEC80B70:01C72460] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 with Stefan. In general I see a lot of potential for signature support in TLS for commerce, non-repudiation and secure audit scenarios. The term evidence brings in a legal discussion that clearly does not belong here. Ari Medvinsky Sr. Program Manager Windows Security -----Original Message----- From: Mark Brown [mailto:mark@redphonesecurity.com]=20 Sent: Wednesday, December 20, 2006 9:20 AM To: tls@ietf.org Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Stefan, (resend, to tls@ietf.org, with additions to the first paragraph) Thanks for your helpful comments. I don't agree entirely with you, specifically your position that signatures are (must be?) application level constructs, but you're probably in the majority on this issue. My opinion is based on personal experience though. I am working on a router project that uses TLS Evidence and Authorizations at the TLS level only: http://www.navysbir.com/06_1/215.htm The router works below the application-level and aims at high assurance under Common Criteria, e.g. EAL6. Its design and implementation has been and will continue to be carefully scrutinized. This project does not depend on "signer's intent" though, and perhaps intent is what you locate at the application level? I think you're right about this: the wisest choice may be to wait and see how things pan out in the legal community, and not try to extract a final answer from them too soon. Would the TLS WG be willing to extend the charter for evidence even if a large part of the discussion was hosted by a lawyer community and could take some time to hash out? For those of you who are interested in the legal aspect of "evidence", I am currently engaged in conversation with the American Bar Association's Information Security Committee listserv. If you would like to enter that discussion, please let me know. =20 The ABA ISC discussion has recently rehashed the use of the term "evidence" with respect to TLS Evidence. To summarize that discussion as fairly as I can, I think as long as one spells evidence with a lowercase "e" and not as Evidence or EVIDENCE the lawyers on the ISC listserv are comfortable with the term. I also plan to work closely with the ABA Digital Evidence Project over the next year as well, and my first project with DEP is to hash out terms together. The following is a snippet -- really, a teaser -- for those of you with some inclination to join the ABA ISC group: (mark) > The TLS definition of "evidence" is unstated to allow it to flex with the > prevailing=20 > definition in the legal world (this decade's definition or the next's). >=20 > You say the definition of evidence is anything that can be "thrown into > the > pot", which seems reasonable to me. >=20 (Steven Teppler) > > First, what is unknown is the definition of "evidence" as the technical > > protocol means it. In the legal world, anything can be, and usually > > thrown > > into the pot as, evidence. How is this specie of evidence different > from > > other evidence? >=20 (mark) > TLS Evidence does not claim some special privilege e.g. being > non-repudiable. It's just evidence like everything else in the pot. The > specter of duress is never eliminated, for example. How could it be? > Neither does TLS Evidence claim any special privileges to magically gain > affirmatives to any of the following: > (Steven Teppler) > > Is EG'd evidence automatically admissible? Does it > > automatically exclude contradictory digital data or testimony? Does it > > generate enough evidence to survive a summary judgment motion? Does it > > satisfy a burden of production? Burden of persuasion? If so, why isn't > > some modifier, such as "trusted evidence" or "summary judgment > eliminator" > > used? >=20 (mark) > No thank you! If a court chose to admit TLS Evidence into a trial then > that > court could examine it as a record like anything else. The TLS Evidence > draft standard _only_ defines a minimum technical standard for security > measures including cryptographic/equality tests which must be passed > before TLS Evidence is "born". Best regards, mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 13:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5xe-0006M3-U1; Wed, 20 Dec 2006 13:14:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5xd-0006LA-Qe for tls@ietf.org; Wed, 20 Dec 2006 13:14:37 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx5xc-0004VZ-Es for tls@ietf.org; Wed, 20 Dec 2006 13:14:37 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 20 Dec 2006 10:14:36 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 20 Dec 2006 10:14:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,193,1165219200"; d="scan'208"; a="179875043:sNHT23828007" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 10:14:20 -0800 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] Counter structure Date: Wed, 20 Dec 2006 13:14:17 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056011D1A28@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Counter structure thread-index: AccjsjOj9wdzJnavSEeHLzwywTDj3QAsB/GQ From: "Blumenthal, Uri" To: "Eric Rescorla" , X-OriginalArrivalTime: 20 Dec 2006 18:14:20.0011 (UTC) FILETIME=[AB2593B0:01C72462] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: kent@bbn.com 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 Considering that computational performance=20 (crypto speed) seems more precious now than=20 the bandwidth - I suggest that paying 8 extra=20 bytes per record for support of hardware parallelization is a good trade-off. I am for it. -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Tuesday, December 19, 2006 4:11 PM To: tls@ietf.org Cc: kent@bbn.com Subject: [TLS] Counter structure Currently, the (D)TLS Counter draft uses the sequence number to generate the per-record IV. Recently, Steve Kent pointed out a drawback of this mode which mau motivate a different counter structure. I was hoping we could discuss this on the list and try to reach consensus. Here's the issue as I understand it (Steve, please correct me if I screw something up): The CTR IV is security critical in a way that the CBC IV is not. Accordingly, for evaluated products the IV must be generated inside the evaluation boundary where it can be insured that it's not reused. As the IV is currently designed, this would mean that the record sequence number was also maintained inside the security boundary. Ordinarily, this isn't an issue but in implementations where you are doing hardware record processing you might have multiple parallel hardware modules. Synchronizing the sequence number between those modules could be quite problematic. An alternate approach is to use an explicit per-record IV which can be maintained independently by each encryption module. This IV doesn't need to be the full block width, just long enough to prevent collisions. If the modules use a counter or LFSR (with a few bits reserved for module ID) to generate the IV, then you can get by with 64 bits of IV. [0] So, the question is: is enabling this kind of parallel hardware implementation a good tradeoff for 8 more bytes of record size? Please discuss. Thanks, -Ekr [0] Note that this IV size more or less precludes random IVs because of birthday statistics. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 13:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6Sv-0007UM-D7; Wed, 20 Dec 2006 13:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6St-0007TG-RK for tls@ietf.org; Wed, 20 Dec 2006 13:46:55 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx6Sr-0001JT-Bp for tls@ietf.org; Wed, 20 Dec 2006 13:46:55 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA03210; Wed, 20 Dec 2006 19:46:39 +0100 (MEZ) From: Martin Rex Message-Id: <200612201846.TAA20793@uw1048.wdf.sap.corp> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 To: mark@redphonesecurity.com (Mark Brown) Date: Wed, 20 Dec 2006 19:46:39 +0100 (MET) In-Reply-To: <006701c723fc$31a55cc0$6801a8c0@rps.local> from "Mark Brown" at Dec 20, 6 00:00:47 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: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Mark Brown wrote: > > After pointing out this unsolved problem for constructors of digital > evidence, Kent then affirmed the convention of delegating this seemingly > intractable problem to the application layer. "Signing things for > non-repudiation is usually an application-layer issue..." Correct. Choose between CMS & S/MIME, signed XML and maybe GSSAPI-IDUP if you're looking for standards how to put digital signatures on actual content, rather than TLS, who has a option to use a digital signature as a proof for possession of a private key as a method for online authentication. > (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty > sensible approach, I think. But to be perfectly honest, isn't "application > layer" here a code word for "let them figure it out, we're not going to > waste any more time on this problem"? > > But now TLS Evidence can solve the "signer's intent" problems, and it > requires two parties, implying a network protocol connecting two parties. TLS Evidence can NOT solve the signer's intent problems, it is in the worst possible position to do so, right above the bits-on-the-wire. Most protocol stacks have several protocol layers in between, carrying data that is produced by software rather rather than users and users never get to know what amounts of protocol framing and auxiliary data the different layers of the software stack are going to put in there. They don't even know whether, when they are shown a popup window with "OK" and "Cancel", what will be sent over the communication channel -- is it "OK", or "0" or "0xff3456ab" or "button 0x200". The signer's intent is extremely sensitive to the context, and TLS has nothing to do whatsoever with the UIs -- which are going to have a significant impact on the users intent. And user shouldn't have to know or care about that. If users are expected to digitally sign actual meaningful content rather than producing evidence for possession/knowledge of a (private) key, then they better know every single bit that gets signed. IMHO TLS MUST NOT have access to keying material that vouches for anything else than "private key present". The purpose of TLS is online authentication, and the users private key is used to process arbitrary data as seen fit by the underlying authentication protocol. I'm firmly opposed to the TLS Evidence proposal. > > 2. What if in the scenario above the transmission is the acceptance of a > relatively small contract that, in its fine print, grants a huge amount of > intellectual property rights to the military? And later the contractor > wants to repudiate the signature, claiming that the transaction was a > forgery? If you need a contract sign, just do it. There have been perfectly working schemes to do contracts for centuries. Many do not require computers or the internet, and everyone knows how to handle them. You certainly do not need TLS contortions in order to do contracts. Think about what you propose: you're seriously suggesting that click-through-licenses are a good idea. I'm violently opposed to this. Fortunately German jurisdiction has been considering click-through licenses nul and void, and I certainly do not want that to change. Think about the much more dangerous use of this. Currently there are public forums operated by big companies (Microsoft,Google,etc.) and at least some of them have "terms of use" (subject to change without prior notice) which is supposed to transfer your IP to them for everything that you write/post/upload. Click-through licenses are evil, and I don't want to see an IETF working group pushing click-through licensing scheme. > > If only the high-assurance server signed the evidence then the > contractor can say that someone else initiated that transaction, > and the burden of proof rests on the military. As I mentioned, we don't have to reinvent the wheel -- the world has been successfully doing contracts before the internet, and with concepts every adult is accustomed to. I don't know how you think applications are being built today, but the application area that I know keeps adding protocol layers between the wire-level and the presentation layer (what the user really gets to see) like crazy. TLS is just above the network layer, hidden under several abstractions and resource-managed by the middleware. When the middleware feels like it (or when there's some network hickup) the network connection may be dropped and the TLS connection interrupted. Depending on the protocol layers in the middleware and the requirements of the application, the communication channel will be automatically reconnected and the TLS secure channel automatically re-established, transparent and unnoticed by the "application" in many scenarios. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 14:16:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6sF-00045M-OJ; Wed, 20 Dec 2006 14:13:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6sE-0003vu-0F for tls@ietf.org; Wed, 20 Dec 2006 14:13:06 -0500 Received: from bay0-omc1-s7.bay0.hotmail.com ([65.54.246.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx6pq-000571-Ss for tls@ietf.org; Wed, 20 Dec 2006 14:10:41 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 11:10:38 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mark Brown , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Wed, 20 Dec 2006 11:10:38 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 19:10:38.0063 (UTC) FILETIME=[889F67F0:01C7246A] X-Spam-Score: 2.6 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Content-Type: multipart/mixed; boundary="===============1877195145==" Errors-To: tls-bounces@lists.ietf.org --===============1877195145== Content-Type: multipart/alternative; boundary="_98fc3b53-94f2-4be1-91e7-dc4e7079a1d6_" --_98fc3b53-94f2-4be1-91e7-dc4e7079a1d6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hmm.=20 =20 > http://www.navysbir.com/06_1/215.htm a multi-level capable router, with layer 3 segregation based on KMI control= ling the TLSConnections, with=20 the protocol engine inside the N-TCB. =20 I.e. WAN router prevents IP-connectivity if the evidence does not satisfy c= entralized policy. =20 one should be able to repurpose alot of the multilevel layer 2 stack work d= one by cisco for LANs/MANs, with=20 different STPs for each VLAN (PVST+) - controlling compartmentalization ac= ross the trunks. i.e. 802.1q=20 tagging for multilevel policy. =20 I assume that the testing criteria in the reseach is to do it all now with = commodity TLS as the=20 enforcement mechanism, and use CA graphs (with security labels in the certs= ) as the control=20 mechanism for connectivity.? =20 _________________________________________________________________ Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. www.live.com/?addtemplate=3Dholiday= --_98fc3b53-94f2-4be1-91e7-dc4e7079a1d6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hmm.
 
> http://www.navysbir.com/06_1/215.htm

a multi-level capable router, with layer 3 segregation based on KMI control= ling the TLSConnections, with
the protocol engine inside the N-TCB.
 
I.e. WAN router prevents IP-connectivity if the evidence does not satisfy c= entralized policy.
 
one should be able to repurpose alot of the multilevel layer 2 stack work&n= bsp;done by cisco for LANs/MANs, with
different STPs  for each VLAN (PVST+) - controlling compartmentalizati= on across the trunks. i.e. 802.1q
tagging for multilevel policy.
 
I assume that the testing criteria in the reseach is to do it all now with = commodity TLS as the
enforcement mechanism, and use CA graphs (with security labels in the certs= ) as the control
mechanism for connectivity.?
 

Get the Live.com Holiday Page for recipes, gift-givin= g ideas, and more. Check it out! = --_98fc3b53-94f2-4be1-91e7-dc4e7079a1d6_-- --===============1877195145== 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 --===============1877195145==-- From tls-bounces@lists.ietf.org Wed Dec 20 14:21:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6zv-0007jS-9J; Wed, 20 Dec 2006 14:21:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx6zt-0007jK-N8 for tls@ietf.org; Wed, 20 Dec 2006 14:21:01 -0500 Received: from bay0-omc3-s1.bay0.hotmail.com ([65.54.246.201]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gx6zq-0000du-Ph for tls@ietf.org; Wed, 20 Dec 2006 14:21:01 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 11:20:58 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 20 Dec 2006 11:20:58 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 19:20:58.0090 (UTC) FILETIME=[FA3004A0:01C7246B] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1939792398==" Errors-To: tls-bounces@lists.ietf.org --===============1939792398== Content-Type: multipart/alternative; boundary="_ffa822eb-fb4c-4bdd-8a0c-4ce75020a906_" --_ffa822eb-fb4c-4bdd-8a0c-4ce75020a906_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nah, Martin. This layering is not the real issue in debate. Its not the cru= x of the design controversy. The crux is actually sociopolitical and similar to that which I argued abou= t, years ago, unsuccessfully=20 (and alone, sob!) against the Netscape/MISSI line. =20 The power of SSL/TLS is in its commodity status, as a universal bearer, hav= ing public repute, and public trust.=20 Everyone will want to tag on (pun) to that: e.g. my own Connection-NR argum= ent. What matters is adoption, and=20 Peter even proposed a theory of reliance explaining the causes of adoption = (and non-adoption of the IETF stuff).=20 Even got one of my Phd examiners to go red in the face with rage during the= oral, before giving it a grade of=20 "miserable fail (with total prejudice)". =20 Now that was fun! =20 =20 > From: martin.rex@sap.com> Subject: Re: [TLS] Please discuss: draft-housle= y-evidence-extns-00> To: mark@redphonesecurity.com> Date: Wed, 20 Dec 2006 = 19:46:39 +0100> CC: tls@ietf.org> > Mark Brown wrote:> > > > After pointing= out this unsolved problem for constructors of digital> > evidence, Kent th= en affirmed the convention of delegating this seemingly> > intractable prob= lem to the application layer. "Signing things for> > non-repudiation is usu= ally an application-layer issue..."> > Correct.> > Choose between CMS & S/M= IME, signed XML and maybe GSSAPI-IDUP> if you're looking for standards how = to put digital signatures> on actual content, rather than TLS, who has a op= tion to use> a digital signature as a proof for possession of a private> ke= y as a method for online authentication.> > > > (http://www3.ietf.org/proce= edings/05nov/tls.html ) Which is a pretty> > sensible approach, I think. Bu= t to be perfectly honest, isn't "application> > layer" here a code word for= "let them figure it out, we're not going to> > waste any more time on this= problem"?> > > > But now TLS Evidence can solve the "signer's intent" prob= lems, and it> > requires two parties, implying a network protocol connectin= g two parties.> > TLS Evidence can NOT solve the signer's intent problems, = it is in the> worst possible position to do so, right above the bits-on-the= -wire.> > Most protocol stacks have several protocol layers in between, car= rying> data that is produced by software rather rather than users and users= > never get to know what amounts of protocol framing and auxiliary data> th= e different layers of the software stack are going to put in there.> They d= on't even know whether, when they are shown a popup window> with "OK" and "= Cancel", what will be sent over the communication> channel -- is it "OK", o= r "0" or "0xff3456ab" or "button 0x200".> The signer's intent is extremely = sensitive to the context,> and TLS has nothing to do whatsoever with the UI= s -- which are> going to have a significant impact on the users intent.> An= d user shouldn't have to know or care about that.> > If users are expected = to digitally sign actual meaningful content> rather than producing evidence= for possession/knowledge of a (private) key,> then they better know every = single bit that gets signed.> > IMHO TLS MUST NOT have access to keying mat= erial that vouches for> anything else than "private key present". The purpo= se of TLS is online> authentication, and the users private key is used to p= rocess> arbitrary data as seen fit by the underlying authentication protoco= l.> > > I'm firmly opposed to the TLS Evidence proposal.> > > > > > 2. What= if in the scenario above the transmission is the acceptance of a> > relati= vely small contract that, in its fine print, grants a huge amount of> > int= ellectual property rights to the military? And later the contractor> > want= s to repudiate the signature, claiming that the transaction was a> > forger= y?> > If you need a contract sign, just do it. There have been perfectly> w= orking schemes to do contracts for centuries. Many do not require> computer= s or the internet, and everyone knows how to handle them.> You certainly do= not need TLS contortions in order to do contracts.> > Think about what you= propose: you're seriously suggesting that> click-through-licenses are a go= od idea. I'm violently opposed to> this. Fortunately German jurisdiction ha= s been considering> click-through licenses nul and void, and I certainly do= not> want that to change.> > > Think about the much more dangerous use of = this. Currently there> are public forums operated by big companies (Microso= ft,Google,etc.)> and at least some of them have "terms of use" (subject to = change> without prior notice) which is supposed to transfer your IP to> the= m for everything that you write/post/upload. > > Click-through licenses are= evil, and I don't want to see an> IETF working group pushing click-through= licensing scheme.> > > >> > If only the high-assurance server signed the e= vidence then the> > contractor can say that someone else initiated that tra= nsaction,> > and the burden of proof rests on the military.> > As I mention= ed, we don't have to reinvent the wheel -- the world> has been successfully= doing contracts before the internet, and> with concepts every adult is acc= ustomed to.> > > I don't know how you think applications are being built to= day,> but the application area that I know keeps adding protocol> layers be= tween the wire-level and the presentation layer> (what the user really gets= to see) like crazy.> TLS is just above the network layer, hidden under sev= eral> abstractions and resource-managed by the middleware.> > When the midd= leware feels like it (or when there's some> network hickup) the network con= nection may be dropped and> the TLS connection interrupted. Depending on th= e> protocol layers in the middleware and the requirements> of the applicati= on, the communication channel will> be automatically reconnected and the TL= S secure channel> automatically re-established, transparent and unnoticed> = by the "application" in many scenarios.> > > -Martin> > ___________________= ____________________________> TLS mailing list> TLS@lists.ietf.org> https:/= /www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Get into the holiday spirit, chat with Santa on Messenger. http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=3Den-= us= --_ffa822eb-fb4c-4bdd-8a0c-4ce75020a906_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nah, Martin. This layering is not the real issue in debate. Its not t= he crux of the design controversy.
The crux is actually sociopolitical and similar to that which I argued abou= t, years ago, unsuccessfully
(and alone, sob!) against the Netscape/MISSI line.
 
The power of SSL/TLS is in its commodity status, as a universal bearer, hav= ing public repute, and public trust.
Everyone will want to tag on (pun) to that: e.g. my own Connection-NR argum= ent. What matters is adoption, and
Peter even proposed a theory of reliance explaining the causes of adoption = (and non-adoption of the IETF stuff).
Even got one of my Phd examiners to go red in the face with rage during the= oral, before giving it a grade of
"miserable fail (with total prejudice)".
 
Now that was fun!
 





 

> From: martin.rex@sap.com
> Subject: Re: [TLS] Please discuss: dr= aft-housley-evidence-extns-00
> To: mark@redphonesecurity.com
>= Date: Wed, 20 Dec 2006 19:46:39 +0100
> CC: tls@ietf.org
> > Mark Brown wrote:
> >
> > After pointing out this = unsolved problem for constructors of digital
> > evidence, Kent th= en affirmed the convention of delegating this seemingly
> > intrac= table problem to the application layer. "Signing things for
> > no= n-repudiation is usually an application-layer issue..."
>
> Co= rrect.
>
> Choose between CMS & S/MIME, signed XML and may= be GSSAPI-IDUP
> if you're looking for standards how to put digital s= ignatures
> on actual content, rather than TLS, who has a option to u= se
> a digital signature as a proof for possession of a private
&g= t; key as a method for online authentication.
>
>
> >= ; (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty
&= gt; > sensible approach, I think. But to be perfectly honest, isn't "app= lication
> > layer" here a code word for "let them figure it out, = we're not going to
> > waste any more time on this problem"?
&g= t; >
> > But now TLS Evidence can solve the "signer's intent" = problems, and it
> > requires two parties, implying a network prot= ocol connecting two parties.
>
> TLS Evidence can NOT solve th= e signer's intent problems, it is in the
> worst possible position to= do so, right above the bits-on-the-wire.
>
> Most protocol st= acks have several protocol layers in between, carrying
> data that is= produced by software rather rather than users and users
> never get = to know what amounts of protocol framing and auxiliary data
> the dif= ferent layers of the software stack are going to put in there.
> They= don't even know whether, when they are shown a popup window
> with "= OK" and "Cancel", what will be sent over the communication
> channel = -- is it "OK", or "0" or "0xff3456ab" or "button 0x200".
> The signer= 's intent is extremely sensitive to the context,
> and TLS has nothin= g to do whatsoever with the UIs -- which are
> going to have a signif= icant impact on the users intent.
> And user shouldn't have to know o= r care about that.
>
> If users are expected to digitally sign= actual meaningful content
> rather than producing evidence for posse= ssion/knowledge of a (private) key,
> then they better know every sin= gle bit that gets signed.
>
> IMHO TLS MUST NOT have access to= keying material that vouches for
> anything else than "private key p= resent". The purpose of TLS is online
> authentication, and the users= private key is used to process
> arbitrary data as seen fit by the u= nderlying authentication protocol.
>
>
> I'm firmly opp= osed to the TLS Evidence proposal.
>
>
> >
> = > 2. What if in the scenario above the transmission is the acceptance of= a
> > relatively small contract that, in its fine print, grants a= huge amount of
> > intellectual property rights to the military? = And later the contractor
> > wants to repudiate the signature, cla= iming that the transaction was a
> > forgery?
>
> If = you need a contract sign, just do it. There have been perfectly
> wor= king schemes to do contracts for centuries. Many do not require
> com= puters or the internet, and everyone knows how to handle them.
> You = certainly do not need TLS contortions in order to do contracts.
> > Think about what you propose: you're seriously suggesting that
>= ; click-through-licenses are a good idea. I'm violently opposed to
> = this. Fortunately German jurisdiction has been considering
> click-th= rough licenses nul and void, and I certainly do not
> want that to ch= ange.
>
>
> Think about the much more dangerous use of = this. Currently there
> are public forums operated by big companies (= Microsoft,Google,etc.)
> and at least some of them have "terms of use= " (subject to change
> without prior notice) which is supposed to tra= nsfer your IP to
> them for everything that you write/post/upload. >
> Click-through licenses are evil, and I don't want to see an=
> IETF working group pushing click-through licensing scheme.
>=
>
> >
> > If only the high-assurance server sign= ed the evidence then the
> > contractor can say that someone else = initiated that transaction,
> > and the burden of proof rests on t= he military.
>
> As I mentioned, we don't have to reinvent the= wheel -- the world
> has been successfully doing contracts before th= e internet, and
> with concepts every adult is accustomed to.
>=
>
> I don't know how you think applications are being built = today,
> but the application area that I know keeps adding protocol> layers between the wire-level and the presentation layer
> (wh= at the user really gets to see) like crazy.
> TLS is just above the n= etwork layer, hidden under several
> abstractions and resource-manage= d by the middleware.
>
> When the middleware feels like it (or= when there's some
> network hickup) the network connection may be dr= opped and
> the TLS connection interrupted. Depending on the
> = protocol layers in the middleware and the requirements
> of the appli= cation, the communication channel will
> be automatically reconnected= and the TLS secure channel
> automatically re-established, transpare= nt and unnoticed
> by the "application" in many scenarios.
> >
> -Martin
>
> __________________________________= _____________
> TLS mailing list
> TLS@lists.ietf.org
> h= ttps://www1.ietf.org/mailman/listinfo/tls


Get into the h= oliday spirit, chat with Santa on Messenger.=A0 Ho-Ho-Ho! = --_ffa822eb-fb4c-4bdd-8a0c-4ce75020a906_-- --===============1939792398== 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 --===============1939792398==-- From tls-bounces@lists.ietf.org Wed Dec 20 14:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx77M-00044p-0a; Wed, 20 Dec 2006 14:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx77L-00042q-Dm for tls@ietf.org; Wed, 20 Dec 2006 14:28:43 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gx77J-0002Bs-5A for tls@ietf.org; Wed, 20 Dec 2006 14:28:43 -0500 Received: (qmail 12392 invoked by uid 0); 20 Dec 2006 19:28:33 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 20 Dec 2006 19:28:33 -0000 Message-Id: <7.0.0.16.2.20061220142408.073c5008@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 20 Dec 2006 14:28:32 -0500 To: Eric Rescorla ,tls@ietf.org From: Russ Housley Subject: Re: [TLS] Counter structure In-Reply-To: <20061219211357.942575C089@laser.networkresonance.com> References: <20061219211357.942575C089@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: kent@bbn.com 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 [ SECURITY AD HAT OFF ] We had a very similar discussion when we were trying to figure out what structure to use for Counter Mode in the context of IPsec. The possibility of multiple modules was a very real concern in that context. This might be in the future for TLS too. TLS is used to provide hop-by-hop protections for SIP, and it seems to me that a media gateway may need enough hardware support for this to be an issue. I support the use of a few more bits to ensure that support for such a capability is straightforward. Russ At 04:10 PM 12/19/2006, Eric Rescorla wrote: >Currently, the (D)TLS Counter draft uses the sequence number to >generate the per-record IV. Recently, Steve Kent pointed out >a drawback of this mode which mau motivate a different counter >structure. I was hoping we could discuss this on the list >and try to reach consensus. > >Here's the issue as I understand it (Steve, please correct >me if I screw something up): > > The CTR IV is security critical in a way that the CBC IV is > not. Accordingly, for evaluated products the IV must be generated > inside the evaluation boundary where it can be insured that it's not > reused. As the IV is currently designed, this would mean that the > record sequence number was also maintained inside the security > boundary. > > Ordinarily, this isn't an issue but in implementations where you are > doing hardware record processing you might have multiple parallel > hardware modules. Synchronizing the sequence number between those > modules could be quite problematic. > > An alternate approach is to use an explicit per-record IV which can > be maintained independently by each encryption module. This IV > doesn't need to be the full block width, just long enough to prevent > collisions. If the modules use a counter or LFSR (with a few bits > reserved for module ID) to generate the IV, then you can get by with > 64 bits of IV. [0] > >So, the question is: is enabling this kind of parallel hardware >implementation a good tradeoff for 8 more bytes of record size? > >Please discuss. > >Thanks, >-Ekr > > >[0] Note that this IV size more or less precludes random IVs because of >birthday statistics. > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 14:34:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx7Cf-00072a-Mm; Wed, 20 Dec 2006 14:34:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx7Cf-00072L-4N for tls@ietf.org; Wed, 20 Dec 2006 14:34:13 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gx7CY-0001iU-Pr for tls@ietf.org; Wed, 20 Dec 2006 14:34:11 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id C3F1C8157; Wed, 20 Dec 2006 13:33:59 -0600 (CST) From: "Mark Brown" To: "'Peter Williams'" , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Wed, 20 Dec 2006 13:35:25 -0600 Message-ID: <00bd01c7246d$ff558b60$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcckXp4E5jT7JIMjSHW0plW9JUmqNQACdlLQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Peter, Thanks for the warm welcome to the TLS listserv. I won't be able to address your concerns about covert channels, timing channels, Morse code, until several months from now. Your concern is a good challenge all the same. (Have you read "Proof of Separability"? http://ftp.csl.sri.com/~rushby/abstracts/isp82 Let's take this discussion offline.) --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 15:43:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8HN-0008Vd-FO; Wed, 20 Dec 2006 15:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8HL-0008VT-G4 for tls@ietf.org; Wed, 20 Dec 2006 15:43:07 -0500 Received: from bay0-omc2-s18.bay0.hotmail.com ([65.54.246.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx8HI-0000Sx-4x for tls@ietf.org; Wed, 20 Dec 2006 15:43:07 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc2-s18.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 12:43:03 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Date: Wed, 20 Dec 2006 12:43:03 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 20:43:03.0704 (UTC) FILETIME=[72151180:01C72477] X-Spam-Score: 2.2 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [TLS] question: decode_eror 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="===============0474337393==" Errors-To: tls-bounces@lists.ietf.org --===============0474337393== Content-Type: multipart/alternative; boundary="_58adc52a-a308-45bd-b6a0-5e6b52439f57_" --_58adc52a-a308-45bd-b6a0-5e6b52439f57_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable is the TLS1.0 procedure for creating alerts well established AND uniform in= =20 practice, for the last case below:- =20 In the interests of forward compatibility, it is permitted for a = client hello message to include extra data after the compression me= thods. This data must be included in the handshake hashes, but must o= therwise be ignored. This is the only handshake message for which thi= s is legal; for all other messages, the amount of data in the message= must match the description of the message precisely. For example, are folks required to send the alert: decode_error (mandatory = fatal)? =20 What does the IETF require of implementors concerning WHEN this is alert is= =20 sent, given the server.write queue may have data? _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=3Dimprove&local= e=3Den-US&source=3Dwlmemailtaglinenov06= --_58adc52a-a308-45bd-b6a0-5e6b52439f57_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable is the TLS1.0 procedure for creating alerts well established AND unif= orm in
practice, for the last case below:-
 
      In the interests of forward compatibility, i= t is permitted for a
       client hello m= essage to include extra data after the compression
   &nb= sp;   methods. This data must be included in the handshake hashes= , but
       must otherwise be ignored. Th= is is the only handshake message for
      = ; which this is legal; for all other messages, the amount of data
 =       in the message must match the description of= the message
       precisely.


For example, are folks required to send the alert: decode_error (mandatory = fatal)?
 
What does the IETF require of implementors concerning WHEN this is ale= rt is
sent, given the server.write queue may have data?

View Athle= tes' Collections with Live Search. See it! = --_58adc52a-a308-45bd-b6a0-5e6b52439f57_-- --===============0474337393== 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 --===============0474337393==-- From tls-bounces@lists.ietf.org Wed Dec 20 16:12:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8j4-0007nP-IK; Wed, 20 Dec 2006 16:11:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8j3-0007mk-HA for tls@ietf.org; Wed, 20 Dec 2006 16:11:45 -0500 Received: from bay0-omc2-s40.bay0.hotmail.com ([65.54.246.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx8j1-0005r1-48 for tls@ietf.org; Wed, 20 Dec 2006 16:11:45 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 13:11:42 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] question: decode_eror Date: Wed, 20 Dec 2006 13:11:42 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 21:11:42.0701 (UTC) FILETIME=[72AF31D0:01C7247B] X-Spam-Score: 2.2 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: , Content-Type: multipart/mixed; boundary="===============0551720054==" Errors-To: tls-bounces@lists.ietf.org --===============0551720054== Content-Type: multipart/alternative; boundary="_d554e201-957b-4c3e-94c9-a50983343d7a_" --_d554e201-957b-4c3e-94c9-a50983343d7a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerning RFC 4366 updates to TLS1.1 =20 The document state that "...clients MUST abort the handshake if they receiv= e an extension type in the extended server hello that they did not requ= est in the associated (extended) client hello." =20 it also asserts that: " In the event that a client requests additional fu= nctionality using the extended client hello, and this functionality is no= t supplied by the server, the client MAY abort the handshake." how does one "abort the handshake", in each case? =20 For example:- Does one send handshake_failure alert, at warning or fatal? L= ets assume warning. =20 Upon "abort the handshake", does the updated TLS1.1 standard require either= client or server=20 implementations to perform a warning-level close_notify? Peter. From: home_pw@msn.comTo: tls@ietf.orgDate: Wed, 20 Dec 2006 12:43:03 -0800C= C: Subject: [TLS] question: decode_eror is the TLS1.0 procedure for creating alerts well established AND uniform in= practice, for the last case below:- In the interests of forward comp= atibility, it is permitted for a client hello message to include extr= a data after the compression methods. This data must be included in t= he handshake hashes, but must otherwise be ignored. This is the only = handshake message for which this is legal; for all other messages, th= e amount of data in the message must match the description of the mes= sage precisely.For example, are folks required to send the alert: dec= ode_error (mandatory fatal)? What does the IETF require of implementors con= cerning WHEN this is alert is sent, given the server.write queue may have d= ata? View Athletes' Collections with Live Search. See it!=20 _________________________________________________________________ Try amazing new 3D maps http://maps.live.com/?wip=3D51= --_d554e201-957b-4c3e-94c9-a50983343d7a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerning RFC 4366 updates to TLS1.1
 
The document state that "...clients MUST abort the handshake if they receiv= e
   an extension type in the extended server hello that they = did not
   request in the associated (extended) client hello."=
 
it also asserts that:   " In the event that a client request= s additional functionality using
   the extended client hello,= and this functionality is not supplied by
   the server, the = client MAY abort the handshake."

how does one "abort the handshake", in each case?
 
For example:- Does one send handshake_failure alert, at warning or fatal? L= ets assume warning.
 
Upon "abort the handshake", does the updated TLS1.1 standard require either= client or server
implementations to perform a warning-level close_notify?

Peter.





From: home_pw@msn.com
To: tls@ietf.org
Date: Wed, 20 Dec 2006 12:43:0= 3 -0800
CC:
Subject: [TLS] question: decode_eror

is the TLS1.0 procedure for creating alerts well established AND uniform in=
practice, for the last case below:-
 
  &nbs= p;   In the interests of forward compatibility, it is permitted f= or a
       client hello message to includ= e extra data after the compression
       = methods. This data must be included in the handshake hashes, but
 &= nbsp;     must otherwise be ignored. This is the only h= andshake message for
       which this is = legal; for all other messages, the amount of data
   &nbs= p;   in the message must match the description of the message
=        precisely.


For example, are= folks required to send the alert: decode_error (mandatory fatal)?
 = ;
What does the IETF require of implementors concerning WHEN this i= s alert is
sent, given the server.write queue may have data?

View Athletes' Collections with Live Search. See it!

Try amazing new 3D maps Check it out! = --_d554e201-957b-4c3e-94c9-a50983343d7a_-- --===============0551720054== 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 --===============0551720054==-- From tls-bounces@lists.ietf.org Wed Dec 20 17:23:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9pW-0000eb-LC; Wed, 20 Dec 2006 17:22:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9pV-0000eN-4C for tls@ietf.org; Wed, 20 Dec 2006 17:22:29 -0500 Received: from simmts12.bellnexxia.net ([206.47.199.141] helo=simmts12-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx9pR-0001wa-GL for tls@ietf.org; Wed, 20 Dec 2006 17:22:29 -0500 Received: from pbo8f8e10aowa ([65.94.94.252]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061220222220.IPDG29497.simmts12-srv.bellnexxia.net@pbo8f8e10aowa>; Wed, 20 Dec 2006 17:22:20 -0500 Message-ID: <007f01c72485$8d446ab0$fc5e5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "Peter Williams" , , References: Subject: Re: [TLS] Comments on TLS identity protection Date: Wed, 20 Dec 2006 17:24:01 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.1 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1930881194==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1930881194== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01C7245B.A41EE320" This is a multi-part message in MIME format. ------=_NextPart_000_007C_01C7245B.A41EE320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking of the various SSL/TLS implementations on the win 32 or 64 = platforms: Where do they put the dll or COM object or ... that holds the client = side session cache? Thanks. Regards, Omirjan Batyrbaev ----- Original Message -----=20 From: Peter Williams=20 To: pasi.eronen@nokia.com ; badra@isima.fr=20 Cc: tls@ietf.org=20 Sent: Wednesday, December 20, 2006 10:29 AM Subject: RE: [TLS] Comments on TLS identity protection =20 =20 Netscape and Microsoft always took different approaches to https, and = TLS. You can, too! For Netscape,=20 they really never moved beyond writing a common client-side library, = that smelled like a socket, but got managed like any winform or adminwebsite. The lib was always = used to secure-enable an=20 app [platform], versus be a protocol layer. And this was despite their = excellent stack-architecture (as=20 the patent shows!); and the MSFT-produced implementation of the = platform even in winsock! For Microsoft, they contrasted Netscape's "application-centric platform making" by = putting SSL and SSL CSPs into the OS platform, so it could be properly evaluated under CC like = all the rest of the B1-grade OS security features that Windows NT was approaching at that point. For = Netscape, FIPS-mode was really as far as they got with assurance doctrine; for Microsoft = (MSFT UK in particular, and the UK=20 eval labs), meeting assurance standards, architecturally and = functionally, was the whole game. Evaluating the=20 network component of a trusted commodity OS was not hard science, at = that point. There was=20 a enormous amount work done in this area, for NT 4.0, and then again = for NT4 SP4. This is all junk Internet history. But, SSL has always been a very = varied camp, as you would expect from something capable of being an Internet Standard. It has a = momentum of its own, because of something architecturally "right". Kipp H (who I never met) = and Tajer did something=20 very special. It would not have made it to SSL3 without the = Wienstiens, and their hypermedia orientation.=20 Tim D and co, with SSLRef and those early VeriSign security audits! = and the 2 nameless Australian breathren, of=20 course! And, lets not forget the other Eric! Eric R.'s work with Alan = Schiffman for DARPA were all part of the early argument that became the mainstay of NS vs = MSFT, choosing between=20 application vs OS/stack solutions for SPs. I still remember the first = time I ever heard of=20 SSL...in Eric's/Alan's lecture, launching shttp version dot-something, = by compare and contrast! I dont recall if this was late 94, or 95; though it would not be hard to find = out, given the "searchable record=20 system" known as the Internet. =20 This all seemed bizzare to the world I was looking at, which was all = about repurposing NSA's TLSP , fathoming=20 ongoing NLSP standards in ISOland, and figuring what all the legacy = "weird" key management protocol stuff from the Motorola/BBN/GTE security groups was all = about, and its (then) weird access=20 control concept, via key management! =20 And none of that would have mattered if the MSFT team (which I knew = very well) had not been competing at the architectural level: on the the grounds of = "platform-to-platform,"=20 "belief system" to "belief system" about what grandma really needs = from a PC. IETF gave the standard the wrong name. As that benchmark of security = argument, known as=20 David Kemp, once erred: the "Session Layer Socket" protocol does = X.... =20 -------------------------------------------------------------------------= ----- > To get widespread deployment, several TLS implementations would=20 > have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS,=20 > JSSE, GnuTLS, etc. Getting any change, no matter how "minimal",=20 > to them is not easy. >=20 > > > I think deployment-wise, double handshake has the advantage=20 > > > that it's already specified and implemented. > >=20 > > Any link to test the implementation, please? >=20 > Pick your favorite TLS implementation! There are at least > couple of dozen of them (though probably not all of them > support renegotiation).=20 >=20 > Some of my favourites (which seem to support renegotiation) > are http://www.openssl.org/ and http://www.gnutls.org/ -- but no=20 > doubt there are other ones that are equally good. >=20 > Best regards, > Pasi >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls -------------------------------------------------------------------------= ----- Try amazing new 3D maps Check it out!=20 -------------------------------------------------------------------------= ----- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls ------=_NextPart_000_007C_01C7245B.A41EE320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Speaking of the various SSL/TLS implementations = on the win=20 32 or 64 platforms:
Where do they put the dll or COM object or = ... that=20 holds the client side session cache?
 
Thanks.
Regards,
Omirjan = Batyrbaev
----- Original Message -----
From:=20 Peter = Williams=20
To: pasi.eronen@nokia.com ; badra@isima.fr
Sent: Wednesday, December 20, = 2006 10:29=20 AM
Subject: RE: [TLS] Comments on = TLS=20 identity protection

 
 
Netscape and Microsoft always took=20 different approaches to https, and TLS. You can, too! For Netscape, =
they=20 really never moved beyond writing a common client-side library, that = smelled=20 like a socket,
but got managed like any winform or adminwebsite. = The lib=20 was always used to secure-enable an
app [platform], versus be a = protocol=20 layer. And this was despite their excellent stack-architecture (as =
the=20 patent shows!); and the MSFT-produced implementation of the platform = even in=20 winsock! For Microsoft,
they contrasted Netscape's = "application-centric=20 platform making" by putting SSL and SSL CSPs
into the OS platform, = so it=20 could be properly evaluated under CC like all the rest of the B1-grade = OS
security features that Windows NT was approaching at that point. = For=20 Netscape, FIPS-mode
was really as far as they got with assurance = doctrine;=20 for Microsoft (MSFT UK in particular, and the UK
eval labs), = meeting=20 assurance standards, architecturally and functionally, was the whole = game.=20 Evaluating the
network component of a trusted commodity OS was=20 not hard science, at that point. There was
a enormous amount = work=20 done in this area, for NT 4.0, and then again for NT4 SP4.

This = is all=20 junk Internet history. But, SSL has always been a very varied camp, as = you=20 would expect
from something capable of being an Internet Standard. = It has a=20 momentum of its own,
because of something architecturally "right". = Kipp H=20 (who I never met) and Tajer did something
very special. It would = not have=20 made it to SSL3 without the Wienstiens, and their hypermedia = orientation.=20
Tim D and co, with SSLRef and those early VeriSign security = audits! and=20 the 2 nameless Australian breathren, of
course! And, lets not = forget the=20 other Eric! Eric R.'s work with Alan Schiffman for DARPA
were all = part of=20 the early argument that became the mainstay of NS vs MSFT, choosing = between=20
application vs OS/stack solutions for SPs. I still remember the = first time=20 I ever heard of
SSL...in Eric's/Alan's lecture, launching shttp = version=20 dot-something, by compare and contrast! I dont
recall if this was = late 94,=20 or 95; though it would not be hard to find out, given the "searchable = record=20
system" known as the Internet.
 
This all seemed = bizzare to the=20 world I was looking at, which was all about repurposing NSA's TLSP , = fathoming=20
ongoing NLSP standards in ISOland, and figuring what all the = legacy=20 "weird" key management
protocol stuff from the Motorola/BBN/GTE = security=20 groups was all about, and its (then) weird access
control concept, = via key=20 management!
 
And none of that would have mattered if the = MSFT team=20 (which I knew very well) had not
been competing at the = architectural level:=20 on the the grounds of "platform-to-platform,"
"belief system" to = "belief=20 system" about what grandma really needs from a PC.

IETF gave = the=20 standard the wrong name. As that benchmark of security argument, known = as=20
David Kemp, once  erred: the "Session Layer Socket" protocol = does=20 X....
 

> To get widespread deployment, several TLS implementations = would=20
> have to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla = NSS,=20
> JSSE, GnuTLS, etc. Getting any change, no matter how = "minimal",=20
> to them is not easy.
>
> > > I think=20 deployment-wise, double handshake has the advantage
> > > = that=20 it's already specified and implemented.
> >
> > Any = link to=20 test the implementation, please?
>
> Pick your favorite = TLS=20 implementation! There are at least
> couple of dozen of them = (though=20 probably not all of them
> support renegotiation).
> =
>=20 Some of my favourites (which seem to support renegotiation)
> = are=20 http://www.openssl.org/ and http://www.gnutls.org/ -- but no
> = doubt=20 there are other ones that are equally good.
>
> Best=20 regards,
> Pasi
>
>=20 _______________________________________________
> TLS mailing=20 list
> TLS@lists.ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/tls


Try amazing new 3D maps Check it out!=20

_______________________________________________
TLS mailing=20 = list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls<= BR>
------=_NextPart_000_007C_01C7245B.A41EE320-- --===============1930881194== 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 --===============1930881194==-- From tls-bounces@lists.ietf.org Wed Dec 20 17:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9vd-0004nm-Kk; Wed, 20 Dec 2006 17:28:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9vc-0004nb-Ge for tls@ietf.org; Wed, 20 Dec 2006 17:28:48 -0500 Received: from bay0-omc2-s40.bay0.hotmail.com ([65.54.246.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx9vb-0003Iy-5K for tls@ietf.org; Wed, 20 Dec 2006 17:28:48 -0500 Received: from BAY103-W7 ([65.54.174.107]) by bay0-omc2-s40.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 14:28:46 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Date: Wed, 20 Dec 2006 14:28:46 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2006 22:28:46.0821 (UTC) FILETIME=[36DFE950:01C72486] X-Spam-Score: 2.4 (++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Subject: [TLS] RFC 4366 server name indication 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="===============1369303916==" Errors-To: tls-bounces@lists.ietf.org --===============1369303916== Content-Type: multipart/alternative; boundary="_bdce5168-cd11-4555-9337-892005d215bd_" --_bdce5168-cd11-4555-9337-892005d215bd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Summary:- Sanity check sought when using a std server name indication type = of host_name, for non classical internet=20 environments. Do I use properly use host_name, or create a new indication t= ype? =20 RC4366 specifes that Server name indication allows one to indicate a virtu= al server name. host_name in the only std type. =20 So lets assume an "outer" TLS Connection exists between the parties C->S, w= here the client nic=20 for TCP is in fact one or many vlans/pseudo-nics in client's bridge/stack. = Lets say, the outer TLS Connection=20 once negotiated also gets its own vlan#base1, with a psuedo-Mac address in = the local stack. Perhaps that MAC even participates in ARP & binds to a DNS record using DHCP. =20 For whatever reason, the server party decides to create an "inner" TLS Conn= ection , as is its right. It thus=20 issues an (Extended) client hello etc transferring this over the applicati= on_data of the outer connection, using=20 tunneling techniques using some encapsulation standard (ethernet.v2 say) =20 In terms of server name extension rules as I read them, the outer tunnel's = protocol engine is now the=20 "application", which gets to "interpret" the host_name sent in the client h= ello.=20 =20 Lets say the wireless stack is bridging/trunking at layer 2 various vlans, = each if which are adjacent to vlan#base1 with local ids {vlan#base1#1, vlan#base1#2, vlan#base1#3).=20 =20 Given the application ( i.e. the TLS-Connection-capable bridge behind vlan.= base#1) interprets the name, am=20 I being consistent with the proposal if I indicate values such as "1.base1= .vlan.wirelesslan.isp.com"? =20 =20 _________________________________________________________________ Type your favorite song.=A0 Get a customized station.=A0 Try MSN Radio powe= red by Pandora. http://radio.msn.com= --_bdce5168-cd11-4555-9337-892005d215bd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Summary:- Sanity check sought when using a std server name indication= type of host_name, for non classical internet
environments. Do I use properly use host_name, or create a new indicat= ion type?
 
RC4366 specifes  that Server name indication allows one to indicate a = virtual server name. host_name in the only std type.
 
So lets assume an "outer" TLS Connection exists between the parties C-= >S, where the client nic
for TCP is in fact one or many vlans/pseudo-nics in client's bridge/st= ack. Lets say, the outer TLS Connection
once negotiated also gets its own vlan#base1, with a psuedo-Mac address in = the local stack. Perhaps that
MAC even participates in ARP & binds to a DNS record using DHCP.
 
For whatever reason, the server party decides to create an "inner" TLS= Connection , as is its right. It thus
issues an (Extended)  client hello etc transferring this over the appl= ication_data of the outer connection, using
tunneling techniques using some encapsulation standard (ethernet.v2 say)  
In terms of server name extension rules as I read them, the outer tunnel's = protocol engine is now the
"application", which gets to "interpret" the host_name sent in the client h= ello.
 
Lets say the wireless stack is bridging/trunking at layer 2 various vlans, = each if which are adjacent to
vlan#base1 with local ids {vlan#base1#1, vlan#base1#2, vlan#base1#3).
 
Given the application ( i.e. the TLS-Connection-capable bridge behind vlan.= base#1) interprets the name, am
I being consistent with the proposal if I indicate values such as  "1.= base1.vlan.wirelesslan.isp.com"?
 
 

Get free, personalized online radio with MSN Radio po= wered by Pandora. Try it!<= /a> = --_bdce5168-cd11-4555-9337-892005d215bd_-- --===============1369303916== 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 --===============1369303916==-- From tls-bounces@lists.ietf.org Wed Dec 20 17:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9vu-0004xC-6T; Wed, 20 Dec 2006 17:29:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9vt-0004wx-5n for tls@ietf.org; Wed, 20 Dec 2006 17:29:05 -0500 Received: from cenn.mc.mpls.visi.com ([208.42.156.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx9vr-0003Ls-Tm for tls@ietf.org; Wed, 20 Dec 2006 17:29:05 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id 38F9881FE; Wed, 20 Dec 2006 16:29:01 -0600 (CST) From: "Mark Brown" To: , Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Wed, 20 Dec 2006 16:30:26 -0600 Message-ID: <00d101c72486$72b4fd30$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200612201846.TAA20793@uw1048.wdf.sap.corp> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcckZzYG9LKA/0cYQA+vriqhAaoNAQACJpvA X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Martin, I see some misunderstandings: 1) Application data is fully opaque to TLS Evidence. This is a fundamental principle we both agree on. a) Application data is so opaque to TLS Evidence that it could just as well be encrypted when hashed by TLS Evidence, and the resulting digital signatures would serve users as I've proposed. Although the digital signatures would work fine, most users would want to know what the cleartext app data was too, so draft -01 currently hashes cleartext app data. a) TLS Evidence doesn't know or care if the application data contains a button clicked event, be it recorded as "OK", or "0" or "0xff3456ab" or "button 0x200". It never looks inside at app data, it just hashes & signs. c) Making sense of the app data, handshake messages and digital signatures is a forensic task, not something TLS Evidence implementations worry about. This forensic work will be done some time after the transaction occurred, not inside the crypto protocol as the transaction occurs. I hope to make forensics easier simply by laying out a clear record of what bits actually got sent by whom. TLS Evidence has no idea "what it all means" but designers can configure TLS Evidence systems so that the record is reasonably clear (they likely won't get it perfect, and that's a limit that TLS Evidence accepts). The kind of design work I propose for users of TLS Evidence is analogous to writing intelligent debugging trace outputs -- the intelligence here is to make the record clear so if the software unexpectedly goes belly up, you can put together a good guess as to what happened. I believe that people will benefit from having the option/ability to "turn trace on" for their important transactions. Both parties MUST agree first, as the ID makes clear at a number of points. But that's what I think TLS Evidence should do, a lot like setting up Ethereal for a TLS session and creating two digital signatures over the tracefile. Sure, I hold the opinion that people can employ TLS Authorizations so the tracefile is more useful -- might even help show intent. But TLS Evidence doesn't propose any magic/legal tricks. 2) TLS Evidence is incompatible with the "Click-through" aspect of click-wrap licenses, but it's not incompatible with existing laws. TLS Evidence requires client authentication, which doesn't just mean some PKC but a PKC that the server knows (i.e. can authenticate). You have to install the right PKC first. You can't just use any PKC you have on hand and expect to get in to some server that's demanding client authentication. Even if it did, and your TLS client accidentally authenticated to the server(?!?), you will still need to configure "turn trace on" and choose acceptable crypto before evidence happens. TLS Evidence gives you two out-of-band ways to confirm "Are you sure? Are you really sure?" This is the opposite of a casual in-band click wrap. I hope that puts us on the same page. --mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 17:58:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxANd-0002M7-1B; Wed, 20 Dec 2006 17:57:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxANc-0002M2-A9 for tls@ietf.org; Wed, 20 Dec 2006 17:57:44 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxANb-0008IT-1n for tls@ietf.org; Wed, 20 Dec 2006 17:57:44 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 85E622A311 for ; Wed, 20 Dec 2006 17:58:04 -0500 (EST) 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 proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 307209F28D for ; Wed, 20 Dec 2006 17:58:04 -0500 (EST) Message-ID: <4589C017.4080106@pobox.com> Date: Wed, 20 Dec 2006 14:58:31 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] question: decode_eror References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 The TLS extensions RFC retroactively defines a format for the data that follows the compression methods. See RFC 4366. If the data isn't in that format, then you must send a fatal decode_error alert. Mike Peter Williams wrote: > is the TLS1.0 procedure for creating alerts well established AND uniform in > practice, for the last case below:- > > In the interests of forward compatibility, it is permitted for a > client hello message to include extra data after the compression > methods. This data must be included in the handshake hashes, but > must otherwise be ignored. This is the only handshake message for > which this is legal; for all other messages, the amount of data > in the message must match the description of the message > precisely. > > > For example, are folks required to send the alert: decode_error > (mandatory fatal)? > > What does the IETF require of implementors concerning WHEN this is alert is > sent, given the server.write queue may have data? > > ------------------------------------------------------------------------ > View Athletes' Collections with Live Search. See it! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 18:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAQo-0004VO-Kq; Wed, 20 Dec 2006 18:01:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAQn-0004VJ-Tz for tls@ietf.org; Wed, 20 Dec 2006 18:01:01 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxAQm-0000Bn-Nj for tls@ietf.org; Wed, 20 Dec 2006 18:01:01 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 87BCC28CAB for ; Wed, 20 Dec 2006 18:01:22 -0500 (EST) 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 proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 50D5CA2935 for ; Wed, 20 Dec 2006 18:01:22 -0500 (EST) Message-ID: <4589C0DD.60302@pobox.com> Date: Wed, 20 Dec 2006 15:01:49 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] question: decode_eror References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > how does one "abort the handshake", in each case? > > For example:- Does one send handshake_failure alert, at warning or > fatal? Lets assume warning. I think that fatal is what is intended. > Upon "abort the handshake", does the updated TLS1.1 standard require > either client or server > implementations to perform a warning-level close_notify? close_notify is for graceful shutdown; I don't think you need to send it after a fatal alert is sent. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 20 18:24:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAn7-0007Rf-50; Wed, 20 Dec 2006 18:24:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAn5-0007QA-El for tls@ietf.org; Wed, 20 Dec 2006 18:24:03 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxAn4-0005Qw-12 for tls@ietf.org; Wed, 20 Dec 2006 18:24:03 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 23DF91E8C5D; Wed, 20 Dec 2006 15:23:59 -0800 (PST) To: "Mark Brown" Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 References: <006701c723fc$31a55cc0$6801a8c0@rps.local> From: Eric Rescorla Date: Wed, 20 Dec 2006 15:23:59 -0800 In-Reply-To: <006701c723fc$31a55cc0$6801a8c0@rps.local> (Mark Brown's message of "Wed, 20 Dec 2006 00:00:47 -0600") Message-ID: <86odpyi228.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.1 (+) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Mark Brown" writes: > First, applications defer to TLS for good reason. The essay "Programming > Satan's Computer" (Anderson & Needham, 1995) makes it clear that devising > and implementing cryptographic protocols is difficult. TLS is so simple to > use and ubiquitous that any user/anywhere can get a good secure socket when > connecting to a TLS server. TLS hides from the user years of protocol > design, analysis and cryptanalysis, all of which is hard. It is a brand > that users trust because TLS simply delivers good security for sockets while > following an "It better just drop in and work" layered model. (SSL was a > good name.) Yes, but the reason why this works is that the security properties that TLS provides are clear and simple (and even at that are proving too complicated in many cases). You're proposing to make them much more complicated. > Why should we consider digital evidence a hard problem, a crypto protocol > problem, a TLS problem? One crucial issue was raised by Steven Kent last > year: the problem of the recording the signer's intent. Just to be clear, > "signer's intent" problems include not only the challenge of recording > something intangible, or the possibility that garbage data was signed, but > also claims that the system that created the digital signature was subverted > - or used with an intention to defraud. I'm a newcomer to this party, but I > don't think any previous standard solves this problem (I don't count the NR > bit as solving the problem). Let us know... I don't understand why you think that somehow putting this at the TLS layer makes the situation any better. It merely moves the construction of the signature further away from the user. > After pointing out this unsolved problem for constructors of digital > evidence, Kent then affirmed the convention of delegating this seemingly > intractable problem to the application layer. "Signing things for > non-repudiation is usually an application-layer issue..." > (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty > sensible approach, I think. But to be perfectly honest, isn't "application > layer" here a code word for "let them figure it out, we're not going to > waste any more time on this problem"? No. It's an architectural principle based on the end-to-end argument. > But now TLS Evidence can solve the "signer's intent" problems, and it > requires two parties, implying a network protocol connecting two parties. > Or, I should say more conservatively, if TLS Evidence solves the signer's > intent problems then I'd like to ask TLS WG to expand its charter to address > evidence. Or better yet, would you all consider TLS Evidence to see if it > solves the "signer's intent" problems? I have. In my opinion it does not. > The solution to signer's intent lies in two parties using TLS Evidence > together with TLS Authorizations (see -01, 4.2. EvidenceRequest Message, > field handshake_protocol_hash, pp 12-13). If the handshake contains TLS > Authorizations that gain one party "access" then the record of that > handshake proves that the session was authorized-for something specific. > Whatever that something specific is, that's the stated intent for this > session. Both parties agree to it -- one said "Authorize me to do this" and > the other said, "Ok, I agree." If they don't agree, the session's over > before the handshake FINISHED pair. I think you're confusing technical proof of the user's computer being involved with the issue of intent, which is about the *user* being involved. Your draft provides the former, but not the latter. Indeed, as I indicated earlier, it makes the latter *harder* to provide because it's the application that interacts directly with the user. > On to your comments. Pertaining to signer's intent, you raised this > question: > >> S 1. >> It looks like the evidence creation has to involve signatures by >> both parties. Why not have it be one-way. > > My reasons for two signatures (countersignature) include: > > 1. Take as an example a military case where a Common Criteria EAL6 TLS > server and a non-evaluated TLS client exchange TLS Evidence. If only the > client signs it, how much assurance do we have that the evidence is correct? > None under the Common Criteria. But if the client asserts it and the EAL6 > server countersigns it (using EvidenceResponse under TLS Evidence) now we > have "high assurance" for the evidence, which both client and server can > retain. In this scenario, the low-assurance party obtains high-assurance > evidence just because it participated with a high-assurance server. I call > this "assurance bootstrapping," and it can be a valuable service to the > client. I think this argument still carries the same weight even if the > server is Known Good under some other current or future evaluation system > (open source, peer review, etc.). > > 2. What if in the scenario above the transmission is the acceptance of a > relatively small contract that, in its fine print, grants a huge amount of > intellectual property rights to the military? And later the contractor > wants to repudiate the signature, claiming that the transaction was a > forgery? (This illustration is completely fictional.) If only the > high-assurance server signed the evidence then the contractor can say that > someone else initiated that transaction, and the burden of proof rests on > the military. But if the contractor chose his own key pair, and registered > his own PKC, and used that registered PKC to sign EvidenceRequest under TLS > Evidence it's harder to repudiate frivolously. Especially if the > contractor's PKC uses crypto stronger than the military can crack. I'm not saying that you *can't* have two signatures. I'm saying that it's a mistake to *only* allow there to be two signatures. There are lots of settings where evidence is one-way only. Consider, for instance, a purchase receipt from a store. >> Why not just store the traffic keys? > > No smoking gun stands out to me as I try to explain why > session-key-encrypted application data proves the identity of both parties. > Following your book I can see how to derive the session key if I have all > the right inputs, but working backwards from session key to identities seems > harder. Huh? You've got signatures over the plaintext with a certificate to go with then. You take the traffic keys and decrypt the traffic. There's nothing even remotely difficult here. The line you're drawing doesn't seem remotely convincing to me. > Let me clarify expected operation. TLS Evidence requires participants to > store evidence, and it requires configuration -- selecting targets -- before > it starts creating evidence, but it does not require application > interaction. The usage model I anticipate for TLS Evidence is default > do-nothing. Until client (and server) both configure to client authenticate > and to demand evidence when accessing specific domains/URIs, then nothing > happens. But that's exactly application interaction. Either you generate evidence for the entire transaction or you need the application layer to trigger the evidence recording--and to refuse to proceed unless it's agreed to. And then what happens when the counterparty cheats and doesn't deliver their signature? There is an enormous amount of application interaction here, and it all requires signalling between the app and the TLS stack. > TLS Evidence isn't something one party can demand with no warning, > or from a stranger. Once the TLS layer is configured to demand evidence in > some cases, now the app layer wants to see no traffic (for those cases) > unless the traffic passes the TLS Evidence tests. I don't even understand what API you are imagining here. The TLS stack is going to throw out data from when the application requests to start gathering evidence until it's suddenly marked as the start of the evidence block? > It is an unwarranted prejudice to hold that digital signatures must be > application-level constructs. Something I never said. TLS makes extensive use of digital signatures. Rather, digital signatures over *application data* should be done at the application layer. >> The only real reason to do >> this at the TLS layer is the sense that it's easier to deploy. > > I disagree. The reason an app wants TLS to solve a Difficult Crypto Problem > is the raison d'etre of TLS. No. The raison d'etre of TLS is to solve a *particular* problem. Not this one. > TLS makes the crypto problems easy (for the > app), is a Known Good Way, and can handle the responsibilities of key > management & crypto. More than anything TLS is tested and approved. Apps > can't duplicate this without great cost. This sounds like exactly what I said "easier to deploy." >> I'm not actually convinced that that's so, since this approach >> still requires modifying the applications to request security >> the signature/evidence services. >> >> In addition, putting this functionality at the TLS layer embodies >> some not-so-attractive tradeoffs, in particular, that the >> binding of application-layer messages to the actual evidence >> provided isn't particularly tight, since the signatures cover extents >> of the traffic rather than messages. This introduces a number of >> race conditions which are only partially solved by the >> interlocking alerts used here. Among these are: >> >> - The sender of the start1 alert has only minimal >> information/control over when the peer will start signing traffic. >> - It's quite likely that one side will have to process messages >> without knowing whether the peer will actually sign his >> section of the traffic. This is obviously a problem if you >> are producing side effects. You can mitigate this problem >> only by doing two evidence collections in lockstep. >> - Applications need a bunch of new logic to detect the evidence >> request but hold their response to application-layer boundaries. >> This cannot be implemented at the TLS layer. >> - If you want to condition your application-layer responses >> to whether the peer provided a signature you need some way >> to provide application-layer "please resend with signature". >> This is a common case but can only be dealt with very >> clumsily here. > > Some of these scenarios seem incongruous with mutual authentication and some > form of TLS Authorization (as recommended in TLS Evidence). Please give > more information about the scenarios you are thinking of here. I think I did. Let's just take the second point. I'm a bank and the customer requests a financial transaction. I don't want to change anything in my database until the customer has sent me a signed request. However, because of the way you've constructed the protocol, I don't get the customer's signature until after I've changed the database entry and then sent my response. If the customer then decides not to send me their signature, I need to throw an application-layer error and then roll back the entire transaction. That's not at all convenient. >> S 3. >> This consumes 4 new alerts. The space isn't that big. >> Since you're already defining a new protocol type, these >> messages might as well be part of that protocol. > > Let's flesh this out a bit more. Whatever is best. > >> >> S A. >> Defining cipher suites with key lengths attached to them >> isn't hte TLS way. > > In this case, using poor crypto actually hurts your partner if you're the > one whose going to repudiate with evil intent. That's reversed from the > normal TLS model, and why TLS Evidence is stringent where TLS historically > has been able to be loose. Parties need to protect themselves by demanding > what they consider to be strong asymmetric crypto. I don't see how this is qualitatively different from the ordinary TLS case where I'm sending my credit card to a server and I have to decide whether the certificate it's offering represents a strong enough key. We don't bind key lengths to cipher suites there (with the exception of export) and we shouldn't do it here either. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 03:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxJJL-0001ZE-7V; Thu, 21 Dec 2006 03:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxJJK-0001Z9-66 for tls@ietf.org; Thu, 21 Dec 2006 03:29:54 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxJJJ-0002O3-Au for tls@ietf.org; Thu, 21 Dec 2006 03:29:54 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 21 Dec 2006 08:29:52 +0000 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; Thu, 21 Dec 2006 08:29:52 +0000 From: Stefan Santesson To: EKR , Mark Brown Date: Thu, 21 Dec 2006 08:29:50 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 Thread-Index: AcckjjH07LKfMk3VSTWLAdRsy0h38gASwvFA Message-ID: References: <006701c723fc$31a55cc0$6801a8c0@rps.local> <86odpyi228.fsf@raman.networkresonance.com> In-Reply-To: <86odpyi228.fsf@raman.networkresonance.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d 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 I think this discussion is even more "evidence" that the subject of "eviden= ce" is totally misplaced in TLS protocol design. There are simply too many factors that are dependent on the layers above TL= S. Keeping the legal angle of this document will take it nowhere but down the = drain of the NR mess. Not saying that someone can't make use of this, or any other security proto= col, to produce evidence. But how that is achieved is completely out of sco= pe of the technical protocol. We don't have to repeat this mistake over and over again. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 21 december 2006 00:24 > To: Mark Brown > Cc: tls@ietf.org > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 > > "Mark Brown" writes: > > First, applications defer to TLS for good reason. The essay > "Programming > > Satan's Computer" (Anderson & Needham, 1995) makes it clear that > devising > > and implementing cryptographic protocols is difficult. TLS is so > simple to > > use and ubiquitous that any user/anywhere can get a good secure > socket when > > connecting to a TLS server. TLS hides from the user years of > protocol > > design, analysis and cryptanalysis, all of which is hard. It is a > brand > > that users trust because TLS simply delivers good security for > sockets while > > following an "It better just drop in and work" layered model. (SSL > was a > > good name.) > > Yes, but the reason why this works is that the security properties > that TLS provides are clear and simple (and even at that are > proving too complicated in many cases). You're proposing to > make them much more complicated. > > > > Why should we consider digital evidence a hard problem, a crypto > protocol > > problem, a TLS problem? One crucial issue was raised by Steven Kent > last > > year: the problem of the recording the signer's intent. Just to be > clear, > > "signer's intent" problems include not only the challenge of > recording > > something intangible, or the possibility that garbage data was > signed, but > > also claims that the system that created the digital signature was > subverted > > - or used with an intention to defraud. I'm a newcomer to this > party, but I > > don't think any previous standard solves this problem (I don't count > the NR > > bit as solving the problem). Let us know... > > I don't understand why you think that somehow putting this at the > TLS layer makes the situation any better. It merely moves the > construction > of the signature further away from the user. > > > > After pointing out this unsolved problem for constructors of digital > > evidence, Kent then affirmed the convention of delegating this > seemingly > > intractable problem to the application layer. "Signing things for > > non-repudiation is usually an application-layer issue..." > > (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty > > sensible approach, I think. But to be perfectly honest, isn't > "application > > layer" here a code word for "let them figure it out, we're not going > to > > waste any more time on this problem"? > > No. It's an architectural principle based on the end-to-end argument. > > > > But now TLS Evidence can solve the "signer's intent" problems, and it > > requires two parties, implying a network protocol connecting two > parties. > > Or, I should say more conservatively, if TLS Evidence solves the > signer's > > intent problems then I'd like to ask TLS WG to expand its charter to > address > > evidence. Or better yet, would you all consider TLS Evidence to see > if it > > solves the "signer's intent" problems? > > I have. In my opinion it does not. > > > > The solution to signer's intent lies in two parties using TLS > Evidence > > together with TLS Authorizations (see -01, 4.2. EvidenceRequest > Message, > > field handshake_protocol_hash, pp 12-13). If the handshake contains > TLS > > Authorizations that gain one party "access" then the record of that > > handshake proves that the session was authorized-for something > specific. > > Whatever that something specific is, that's the stated intent for > this > > session. Both parties agree to it -- one said "Authorize me to do > this" and > > the other said, "Ok, I agree." If they don't agree, the session's > over > > before the handshake FINISHED pair. > > I think you're confusing technical proof of the user's computer > being involved with the issue of intent, which is about the *user* > being involved. Your draft provides the former, but not the latter. > Indeed, as I indicated earlier, it makes the latter *harder* to provide > because it's the application that interacts directly with the user. > > > > On to your comments. Pertaining to signer's intent, you raised this > > question: > > > >> S 1. > >> It looks like the evidence creation has to involve signatures by > >> both parties. Why not have it be one-way. > > > > My reasons for two signatures (countersignature) include: > > > > 1. Take as an example a military case where a Common Criteria EAL6 > TLS > > server and a non-evaluated TLS client exchange TLS Evidence. If only > the > > client signs it, how much assurance do we have that the evidence is > correct? > > None under the Common Criteria. But if the client asserts it and the > EAL6 > > server countersigns it (using EvidenceResponse under TLS Evidence) > now we > > have "high assurance" for the evidence, which both client and server > can > > retain. In this scenario, the low-assurance party obtains high- > assurance > > evidence just because it participated with a high-assurance server. > I call > > this "assurance bootstrapping," and it can be a valuable service to > the > > client. I think this argument still carries the same weight even if > the > > server is Known Good under some other current or future evaluation > system > > (open source, peer review, etc.). > > > > 2. What if in the scenario above the transmission is the acceptance > of a > > relatively small contract that, in its fine print, grants a huge > amount of > > intellectual property rights to the military? And later the > contractor > > wants to repudiate the signature, claiming that the transaction was a > > forgery? (This illustration is completely fictional.) If only the > > high-assurance server signed the evidence then the contractor can say > that > > someone else initiated that transaction, and the burden of proof > rests on > > the military. But if the contractor chose his own key pair, and > registered > > his own PKC, and used that registered PKC to sign EvidenceRequest > under TLS > > Evidence it's harder to repudiate frivolously. Especially if the > > contractor's PKC uses crypto stronger than the military can crack. > > I'm not saying that you *can't* have two signatures. I'm saying that > it's a mistake to *only* allow there to be two signatures. There > are lots of settings where evidence is one-way only. Consider, > for instance, a purchase receipt from a store. > > >> Why not just store the traffic keys? > > > > No smoking gun stands out to me as I try to explain why > > session-key-encrypted application data proves the identity of both > parties. > > Following your book I can see how to derive the session key if I have > all > > the right inputs, but working backwards from session key to > identities seems > > harder. > > Huh? You've got signatures over the plaintext with a certificate > to go with then. You take the traffic keys and decrypt the traffic. > There's nothing even remotely difficult here. The line you're drawing > doesn't seem remotely convincing to me. > > > > Let me clarify expected operation. TLS Evidence requires > participants to > > store evidence, and it requires configuration -- selecting targets -- > before > > it starts creating evidence, but it does not require application > > interaction. The usage model I anticipate for TLS Evidence is > default > > do-nothing. Until client (and server) both configure to client > authenticate > > and to demand evidence when accessing specific domains/URIs, then > nothing > > happens. > > But that's exactly application interaction. Either you generate > evidence for the entire transaction or you need the application > layer to trigger the evidence recording--and to refuse to proceed > unless it's agreed to. And then what happens when the counterparty > cheats and doesn't deliver their signature? There is an enormous > amount of application interaction here, and it all requires > signalling between the app and the TLS stack. > > > > TLS Evidence isn't something one party can demand with no warning, > > or from a stranger. Once the TLS layer is configured to demand > evidence in > > some cases, now the app layer wants to see no traffic (for those > cases) > > unless the traffic passes the TLS Evidence tests. > > I don't even understand what API you are imagining here. The TLS > stack is going to throw out data from when the application requests > to start gathering evidence until it's suddenly marked as the > start of the evidence block? > > > > It is an unwarranted prejudice to hold that digital signatures must > be > > application-level constructs. > > Something I never said. TLS makes extensive use of digital signatures. > Rather, digital signatures over *application data* should be done > at the application layer. > > > >> The only real reason to do > >> this at the TLS layer is the sense that it's easier to deploy. > > > > I disagree. The reason an app wants TLS to solve a Difficult Crypto > Problem > > is the raison d'etre of TLS. > > No. The raison d'etre of TLS is to solve a *particular* problem. Not > this one. > > > > TLS makes the crypto problems easy (for the > > app), is a Known Good Way, and can handle the responsibilities of key > > management & crypto. More than anything TLS is tested and approved. > Apps > > can't duplicate this without great cost. > > This sounds like exactly what I said "easier to deploy." > > >> I'm not actually convinced that that's so, since this approach > >> still requires modifying the applications to request security > >> the signature/evidence services. > >> > >> In addition, putting this functionality at the TLS layer embodies > >> some not-so-attractive tradeoffs, in particular, that the > >> binding of application-layer messages to the actual evidence > >> provided isn't particularly tight, since the signatures cover > extents > >> of the traffic rather than messages. This introduces a number of > >> race conditions which are only partially solved by the > >> interlocking alerts used here. Among these are: > >> > >> - The sender of the start1 alert has only minimal > >> information/control over when the peer will start signing > traffic. > >> - It's quite likely that one side will have to process messages > >> without knowing whether the peer will actually sign his > >> section of the traffic. This is obviously a problem if you > >> are producing side effects. You can mitigate this problem > >> only by doing two evidence collections in lockstep. > >> - Applications need a bunch of new logic to detect the evidence > >> request but hold their response to application-layer boundaries. > >> This cannot be implemented at the TLS layer. > >> - If you want to condition your application-layer responses > >> to whether the peer provided a signature you need some way > >> to provide application-layer "please resend with signature". > >> This is a common case but can only be dealt with very > >> clumsily here. > > > > Some of these scenarios seem incongruous with mutual authentication > and some > > form of TLS Authorization (as recommended in TLS Evidence). Please > give > > more information about the scenarios you are thinking of here. > > I think I did. > > Let's just take the second point. I'm a bank and the customer > requests a financial transaction. I don't want to change anything > in my database until the customer has sent me a signed request. > However, because of the way you've constructed the protocol, > I don't get the customer's signature until after I've changed > the database entry and then sent my response. If the customer > then decides not to send me their signature, I need to throw > an application-layer error and then roll back the entire > transaction. That's not at all convenient. > > >> S 3. > >> This consumes 4 new alerts. The space isn't that big. > >> Since you're already defining a new protocol type, these > >> messages might as well be part of that protocol. > > > > Let's flesh this out a bit more. Whatever is best. > > > >> > >> S A. > >> Defining cipher suites with key lengths attached to them > >> isn't hte TLS way. > > > > In this case, using poor crypto actually hurts your partner if you're > the > > one whose going to repudiate with evil intent. That's reversed from > the > > normal TLS model, and why TLS Evidence is stringent where TLS > historically > > has been able to be loose. Parties need to protect themselves by > demanding > > what they consider to be strong asymmetric crypto. > > I don't see how this is qualitatively different from the ordinary TLS > case > where I'm sending my credit card to a server and I have to decide > whether > the certificate it's offering represents a strong enough key. We don't > bind key lengths to cipher suites there (with the exception of export) > and we shouldn't do it here either. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 05:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxLbt-0006Nj-00; Thu, 21 Dec 2006 05:57:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxLbr-0006EO-6s for tls@ietf.org; Thu, 21 Dec 2006 05:57:11 -0500 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxLbp-000725-PR for tls@ietf.org; Thu, 21 Dec 2006 05:57:11 -0500 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kBLAv1504761; Thu, 21 Dec 2006 11:57:01 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 21 Dec 2006 11:57:01 +0100 (MET) Message-ID: <458A6805.4070500@edelweb.fr> Date: Thu, 21 Dec 2006 11:55:01 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt References: <45880C64.2080305@edelweb.fr> <86lkl3r6aa.fsf@raman.networkresonance.com> In-Reply-To: <86lkl3r6aa.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1224702447==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1224702447== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070909030403050007030506" This is a cryptographically signed message in MIME format. --------------ms070909030403050007030506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Would you mind giving a little bit more detailed explanation in particular what are the reasons why this cannot be on standards tracks, or what would be necessary if it would be etc. Thanks in advance Peter > > Yes. This document is expected to proceed as Experimental. > > -Ekr > > > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms070909030403050007030506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjIxMTA1NTAxWjAjBgkqhkiG9w0B CQQxFgQUhax+TCtpKlJlF6rYVPp7t+bimiEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAMkNz7nQ+AxOEh8/4 7aB0/AZ4bFa5IsfuticaG0MnTZWxAkdMCHEBoFYX5vt4bT6yh/VwMqLYIA/ZNC6J8YBFxltV wqZpQRLGMWek7EGZBlYflkHv8fvqAdpHyt8Azxev2qjNJV77M1UapMQDHtwIvkjB/aMySwe5 IazYX9Jl1IcAAAAAAAA= --------------ms070909030403050007030506-- --===============1224702447== 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 --===============1224702447==-- From tls-bounces@lists.ietf.org Thu Dec 21 07:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxNKy-0005Zv-NB; Thu, 21 Dec 2006 07:47:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxNKx-0005Zq-F5 for tls@ietf.org; Thu, 21 Dec 2006 07:47:51 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxNKv-0004WB-Tp for tls@ietf.org; Thu, 21 Dec 2006 07:47:51 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 21 Dec 2006 12:47:47 +0000 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 21 Dec 2006 12:47:46 +0000 From: Stefan Santesson To: Mark Brown , "tls@ietf.org" Date: Thu, 21 Dec 2006 12:47:45 +0000 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+gACTeRuAAAMk8IAAEMZKwACh0vHA= Message-ID: References: <009201c7245b$192dbc00$6801a8c0@rps.local> In-Reply-To: <009201c7245b$192dbc00$6801a8c0@rps.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 Mark, > Thanks for your helpful comments. I don't agree entirely with you, > specifically your position that signatures are (must be?) application > level constructs I don't think I ever said that. I said that evidence is formed in an applic= ation context. > Would the TLS WG be willing to extend the > charter for evidence even if a large part of the discussion was hosted > by a lawyer community and could take some time to hash out? > My vote is NO. The legal and technical side of this can and must be separated. If the lega= l side wants to present some requirements for security properties, fine. Bu= t a security protocol must be defined on technical grounds for the security= properties it brings. The technical community in IETF is quite capable of = that. It is not capable of determining what a lawyers will accept or not ac= cept in the hundreds of legal systems around this globe. I agree with Ari, this protocol has potential, but only if we can isolate i= t to the technical discussion. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Mark Brown [mailto:mark@redphonesecurity.com] > Sent: den 20 december 2006 18:20 > To: tls@ietf.org > Cc: Stefan Santesson; 'EKR' > Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 > (resend) > > Stefan, (resend, to tls@ietf.org, with additions to the first > paragraph) > > Thanks for your helpful comments. I don't agree entirely with you, > specifically your position that signatures are (must be?) application > level > constructs, but you're probably in the majority on this issue. My > opinion > is based on personal experience though. I am working on a router > project > that uses TLS Evidence and Authorizations at the TLS level only: > > http://www.navysbir.com/06_1/215.htm > > The router works below the application-level and aims at high assurance > under Common Criteria, e.g. EAL6. Its design and implementation has > been > and will continue to be carefully scrutinized. This project does not > depend > on "signer's intent" though, and perhaps intent is what you locate at > the > application level? > > I think you're right about this: the wisest choice may be to wait and > see > how things pan out in the legal community, and not try to extract a > final > answer from them too soon. Would the TLS WG be willing to extend the > charter for evidence even if a large part of the discussion was hosted > by a > lawyer community and could take some time to hash out? > > For those of you who are interested in the legal aspect of "evidence", > I am > currently engaged in conversation with the American Bar Association's > Information Security Committee listserv. If you would like to enter > that > discussion, please let me know. > > The ABA ISC discussion has recently rehashed the use of the term > "evidence" > with respect to TLS Evidence. To summarize that discussion as fairly > as I > can, I think as long as one spells evidence with a lowercase "e" and > not as > Evidence or EVIDENCE the lawyers on the ISC listserv are comfortable > with > the term. I also plan to work closely with the ABA Digital Evidence > Project > over the next year as well, and my first project with DEP is to hash > out > terms together. > > The following is a snippet -- really, a teaser -- for those of you with > some > inclination to join the ABA ISC group: > > (mark) > > The TLS definition of "evidence" is unstated to allow it to flex with > the > > prevailing > > definition in the legal world (this decade's definition or the > next's). > > > > You say the definition of evidence is anything that can be "thrown > into > > the > > pot", which seems reasonable to me. > > > (Steven Teppler) > > > First, what is unknown is the definition of "evidence" as the > technical > > > protocol means it. In the legal world, anything can be, and > usually > > > thrown > > > into the pot as, evidence. How is this specie of evidence > different > > from > > > other evidence? > > > (mark) > > TLS Evidence does not claim some special privilege e.g. being > > non-repudiable. It's just evidence like everything else in the pot. > The > > specter of duress is never eliminated, for example. How could it be? > > Neither does TLS Evidence claim any special privileges to magically > gain > > affirmatives to any of the following: > > > (Steven Teppler) > > > Is EG'd evidence automatically admissible? Does it > > > automatically exclude contradictory digital data or testimony? > Does it > > > generate enough evidence to survive a summary judgment motion? > Does it > > > satisfy a burden of production? Burden of persuasion? If so, why > isn't > > > some modifier, such as "trusted evidence" or "summary judgment > > eliminator" > > > used? > > > (mark) > > No thank you! If a court chose to admit TLS Evidence into a trial > then > > that > > court could examine it as a record like anything else. The TLS > Evidence > > draft standard _only_ defines a minimum technical standard for > security > > measures including cryptographic/equality tests which must be passed > > before TLS Evidence is "born". > > Best regards, > > mark _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 10:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ3x-0001wX-Fz; Thu, 21 Dec 2006 10:42:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ3v-0001vL-I1 for tls@ietf.org; Thu, 21 Dec 2006 10:42:27 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQ3u-0000jk-9n for tls@ietf.org; Thu, 21 Dec 2006 10:42:27 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 1D6941CC69; Thu, 21 Dec 2006 07:41:20 -0800 (PST) To: Peter Sylvester Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt References: <45880C64.2080305@edelweb.fr> <86lkl3r6aa.fsf@raman.networkresonance.com> <458A6805.4070500@edelweb.fr> From: EKR Date: Thu, 21 Dec 2006 07:41:19 -0800 In-Reply-To: <458A6805.4070500@edelweb.fr> (Peter Sylvester's message of "Thu, 21 Dec 2006 11:55:01 +0100") Message-ID: <86irg5jly8.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Sylvester writes: > Would you mind giving a little bit more detailed explanation in particular > what are the reasons why this cannot be on standards tracks, or what would > be necessary if it would be etc. There are two reasons. First, as a matter of policy we are attempting to move new work to Standards Track only where there is fairly strong support for the work. In this case, the support for this work did not appear to be particularly strong. Second, the IPR issues surrounding all the ZKPP protocols are quite murky and thus it would have required an affirmative decision by the WG to move this document forward as a Proposed Standard despite said issues. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 10:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ7S-0004XK-Vr; Thu, 21 Dec 2006 10:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ7R-0004Ws-O6 for tls@ietf.org; Thu, 21 Dec 2006 10:46:05 -0500 Received: from conn.mc.mpls.visi.com ([208.42.156.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQ7R-0001Q3-3Z for tls@ietf.org; Thu, 21 Dec 2006 10:46:05 -0500 Received: from rpud1 (v-209-98-144-171.mn.visi.com [209.98.144.171]) by conn.mc.mpls.visi.com (Postfix) with ESMTP id DCB1B821C; Thu, 21 Dec 2006 09:46:03 -0600 (CST) From: "Mark Brown" To: Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 Date: Thu, 21 Dec 2006 09:47:29 -0600 Message-ID: <00e601c72517$52887aa0$6801a8c0@rps.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcckjjH07LKfMk3VSTWLAdRsy0h38gASwvFAAA7+vBA= X-Spam-Score: 1.1 (+) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b 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 think my personal opinions about what might be helpful to the legal process are distracting the discussion on this forum. I'd like to take my opinions and statements about the legal aspect of evidence off the table. Sorry to open that can of worms... --mark > -----Original Message----- > From: Stefan Santesson [mailto:stefans@microsoft.com] > Sent: Thursday, December 21, 2006 2:30 AM > To: EKR; Mark Brown > Cc: tls@ietf.org > Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 > > I think this discussion is even more "evidence" that the subject of > "evidence" is totally misplaced in TLS protocol design. > There are simply too many factors that are dependent on the layers above > TLS. > > Keeping the legal angle of this document will take it nowhere but down the > drain of the NR mess. > Not saying that someone can't make use of this, or any other security > protocol, to produce evidence. But how that is achieved is completely out > of scope of the technical protocol. > > We don't have to repeat this mistake over and over again. > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Sent: den 21 december 2006 00:24 > > To: Mark Brown > > Cc: tls@ietf.org > > Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 > > > > "Mark Brown" writes: > > > First, applications defer to TLS for good reason. The essay > > "Programming > > > Satan's Computer" (Anderson & Needham, 1995) makes it clear that > > devising > > > and implementing cryptographic protocols is difficult. TLS is so > > simple to > > > use and ubiquitous that any user/anywhere can get a good secure > > socket when > > > connecting to a TLS server. TLS hides from the user years of > > protocol > > > design, analysis and cryptanalysis, all of which is hard. It is a > > brand > > > that users trust because TLS simply delivers good security for > > sockets while > > > following an "It better just drop in and work" layered model. (SSL > > was a > > > good name.) > > > > Yes, but the reason why this works is that the security properties > > that TLS provides are clear and simple (and even at that are > > proving too complicated in many cases). You're proposing to > > make them much more complicated. > > > > > > > Why should we consider digital evidence a hard problem, a crypto > > protocol > > > problem, a TLS problem? One crucial issue was raised by Steven Kent > > last > > > year: the problem of the recording the signer's intent. Just to be > > clear, > > > "signer's intent" problems include not only the challenge of > > recording > > > something intangible, or the possibility that garbage data was > > signed, but > > > also claims that the system that created the digital signature was > > subverted > > > - or used with an intention to defraud. I'm a newcomer to this > > party, but I > > > don't think any previous standard solves this problem (I don't count > > the NR > > > bit as solving the problem). Let us know... > > > > I don't understand why you think that somehow putting this at the > > TLS layer makes the situation any better. It merely moves the > > construction > > of the signature further away from the user. > > > > > > > After pointing out this unsolved problem for constructors of digital > > > evidence, Kent then affirmed the convention of delegating this > > seemingly > > > intractable problem to the application layer. "Signing things for > > > non-repudiation is usually an application-layer issue..." > > > (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty > > > sensible approach, I think. But to be perfectly honest, isn't > > "application > > > layer" here a code word for "let them figure it out, we're not going > > to > > > waste any more time on this problem"? > > > > No. It's an architectural principle based on the end-to-end argument. > > > > > > > But now TLS Evidence can solve the "signer's intent" problems, and it > > > requires two parties, implying a network protocol connecting two > > parties. > > > Or, I should say more conservatively, if TLS Evidence solves the > > signer's > > > intent problems then I'd like to ask TLS WG to expand its charter to > > address > > > evidence. Or better yet, would you all consider TLS Evidence to see > > if it > > > solves the "signer's intent" problems? > > > > I have. In my opinion it does not. > > > > > > > The solution to signer's intent lies in two parties using TLS > > Evidence > > > together with TLS Authorizations (see -01, 4.2. EvidenceRequest > > Message, > > > field handshake_protocol_hash, pp 12-13). If the handshake contains > > TLS > > > Authorizations that gain one party "access" then the record of that > > > handshake proves that the session was authorized-for something > > specific. > > > Whatever that something specific is, that's the stated intent for > > this > > > session. Both parties agree to it -- one said "Authorize me to do > > this" and > > > the other said, "Ok, I agree." If they don't agree, the session's > > over > > > before the handshake FINISHED pair. > > > > I think you're confusing technical proof of the user's computer > > being involved with the issue of intent, which is about the *user* > > being involved. Your draft provides the former, but not the latter. > > Indeed, as I indicated earlier, it makes the latter *harder* to provide > > because it's the application that interacts directly with the user. > > > > > > > On to your comments. Pertaining to signer's intent, you raised this > > > question: > > > > > >> S 1. > > >> It looks like the evidence creation has to involve signatures by > > >> both parties. Why not have it be one-way. > > > > > > My reasons for two signatures (countersignature) include: > > > > > > 1. Take as an example a military case where a Common Criteria EAL6 > > TLS > > > server and a non-evaluated TLS client exchange TLS Evidence. If only > > the > > > client signs it, how much assurance do we have that the evidence is > > correct? > > > None under the Common Criteria. But if the client asserts it and the > > EAL6 > > > server countersigns it (using EvidenceResponse under TLS Evidence) > > now we > > > have "high assurance" for the evidence, which both client and server > > can > > > retain. In this scenario, the low-assurance party obtains high- > > assurance > > > evidence just because it participated with a high-assurance server. > > I call > > > this "assurance bootstrapping," and it can be a valuable service to > > the > > > client. I think this argument still carries the same weight even if > > the > > > server is Known Good under some other current or future evaluation > > system > > > (open source, peer review, etc.). > > > > > > 2. What if in the scenario above the transmission is the acceptance > > of a > > > relatively small contract that, in its fine print, grants a huge > > amount of > > > intellectual property rights to the military? And later the > > contractor > > > wants to repudiate the signature, claiming that the transaction was a > > > forgery? (This illustration is completely fictional.) If only the > > > high-assurance server signed the evidence then the contractor can say > > that > > > someone else initiated that transaction, and the burden of proof > > rests on > > > the military. But if the contractor chose his own key pair, and > > registered > > > his own PKC, and used that registered PKC to sign EvidenceRequest > > under TLS > > > Evidence it's harder to repudiate frivolously. Especially if the > > > contractor's PKC uses crypto stronger than the military can crack. > > > > I'm not saying that you *can't* have two signatures. I'm saying that > > it's a mistake to *only* allow there to be two signatures. There > > are lots of settings where evidence is one-way only. Consider, > > for instance, a purchase receipt from a store. > > > > >> Why not just store the traffic keys? > > > > > > No smoking gun stands out to me as I try to explain why > > > session-key-encrypted application data proves the identity of both > > parties. > > > Following your book I can see how to derive the session key if I have > > all > > > the right inputs, but working backwards from session key to > > identities seems > > > harder. > > > > Huh? You've got signatures over the plaintext with a certificate > > to go with then. You take the traffic keys and decrypt the traffic. > > There's nothing even remotely difficult here. The line you're drawing > > doesn't seem remotely convincing to me. > > > > > > > Let me clarify expected operation. TLS Evidence requires > > participants to > > > store evidence, and it requires configuration -- selecting targets -- > > before > > > it starts creating evidence, but it does not require application > > > interaction. The usage model I anticipate for TLS Evidence is > > default > > > do-nothing. Until client (and server) both configure to client > > authenticate > > > and to demand evidence when accessing specific domains/URIs, then > > nothing > > > happens. > > > > But that's exactly application interaction. Either you generate > > evidence for the entire transaction or you need the application > > layer to trigger the evidence recording--and to refuse to proceed > > unless it's agreed to. And then what happens when the counterparty > > cheats and doesn't deliver their signature? There is an enormous > > amount of application interaction here, and it all requires > > signalling between the app and the TLS stack. > > > > > > > TLS Evidence isn't something one party can demand with no warning, > > > or from a stranger. Once the TLS layer is configured to demand > > evidence in > > > some cases, now the app layer wants to see no traffic (for those > > cases) > > > unless the traffic passes the TLS Evidence tests. > > > > I don't even understand what API you are imagining here. The TLS > > stack is going to throw out data from when the application requests > > to start gathering evidence until it's suddenly marked as the > > start of the evidence block? > > > > > > > It is an unwarranted prejudice to hold that digital signatures must > > be > > > application-level constructs. > > > > Something I never said. TLS makes extensive use of digital signatures. > > Rather, digital signatures over *application data* should be done > > at the application layer. > > > > > > >> The only real reason to do > > >> this at the TLS layer is the sense that it's easier to deploy. > > > > > > I disagree. The reason an app wants TLS to solve a Difficult Crypto > > Problem > > > is the raison d'etre of TLS. > > > > No. The raison d'etre of TLS is to solve a *particular* problem. Not > > this one. > > > > > > > TLS makes the crypto problems easy (for the > > > app), is a Known Good Way, and can handle the responsibilities of key > > > management & crypto. More than anything TLS is tested and approved. > > Apps > > > can't duplicate this without great cost. > > > > This sounds like exactly what I said "easier to deploy." > > > > >> I'm not actually convinced that that's so, since this approach > > >> still requires modifying the applications to request security > > >> the signature/evidence services. > > >> > > >> In addition, putting this functionality at the TLS layer embodies > > >> some not-so-attractive tradeoffs, in particular, that the > > >> binding of application-layer messages to the actual evidence > > >> provided isn't particularly tight, since the signatures cover > > extents > > >> of the traffic rather than messages. This introduces a number of > > >> race conditions which are only partially solved by the > > >> interlocking alerts used here. Among these are: > > >> > > >> - The sender of the start1 alert has only minimal > > >> information/control over when the peer will start signing > > traffic. > > >> - It's quite likely that one side will have to process messages > > >> without knowing whether the peer will actually sign his > > >> section of the traffic. This is obviously a problem if you > > >> are producing side effects. You can mitigate this problem > > >> only by doing two evidence collections in lockstep. > > >> - Applications need a bunch of new logic to detect the evidence > > >> request but hold their response to application-layer boundaries. > > >> This cannot be implemented at the TLS layer. > > >> - If you want to condition your application-layer responses > > >> to whether the peer provided a signature you need some way > > >> to provide application-layer "please resend with signature". > > >> This is a common case but can only be dealt with very > > >> clumsily here. > > > > > > Some of these scenarios seem incongruous with mutual authentication > > and some > > > form of TLS Authorization (as recommended in TLS Evidence). Please > > give > > > more information about the scenarios you are thinking of here. > > > > I think I did. > > > > Let's just take the second point. I'm a bank and the customer > > requests a financial transaction. I don't want to change anything > > in my database until the customer has sent me a signed request. > > However, because of the way you've constructed the protocol, > > I don't get the customer's signature until after I've changed > > the database entry and then sent my response. If the customer > > then decides not to send me their signature, I need to throw > > an application-layer error and then roll back the entire > > transaction. That's not at all convenient. > > > > >> S 3. > > >> This consumes 4 new alerts. The space isn't that big. > > >> Since you're already defining a new protocol type, these > > >> messages might as well be part of that protocol. > > > > > > Let's flesh this out a bit more. Whatever is best. > > > > > >> > > >> S A. > > >> Defining cipher suites with key lengths attached to them > > >> isn't hte TLS way. > > > > > > In this case, using poor crypto actually hurts your partner if you're > > the > > > one whose going to repudiate with evil intent. That's reversed from > > the > > > normal TLS model, and why TLS Evidence is stringent where TLS > > historically > > > has been able to be loose. Parties need to protect themselves by > > demanding > > > what they consider to be strong asymmetric crypto. > > > > I don't see how this is qualitatively different from the ordinary TLS > > case > > where I'm sending my credit card to a server and I have to decide > > whether > > the certificate it's offering represents a strong enough key. We don't > > bind key lengths to cipher suites there (with the exception of export) > > and we shouldn't do it here either. > > > > -Ekr > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 10:47:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ8H-0005jU-Uh; Thu, 21 Dec 2006 10:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQ8G-0005gL-D1 for tls@ietf.org; Thu, 21 Dec 2006 10:46:56 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQ8F-0001Xh-5P for tls@ietf.org; Thu, 21 Dec 2006 10:46:56 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 0A8941CC6B for ; Thu, 21 Dec 2006 07:45:49 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Thu, 21 Dec 2006 07:45:48 -0800 From: EKR Message-Id: <20061221154549.0A8941CC6B@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] WGLC: draft-ietf-tls-srp-13 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 This is a Working Group Last Call for draft-ietf-tls-srp-13. This document is intended for Experimental status. Please provide comments to the authors and the list. This WGLC will end Fri Jan 12 (to allow time for people's holidays). -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 11:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxR4y-00031R-L0; Thu, 21 Dec 2006 11:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxR4y-00031L-59 for tls@ietf.org; Thu, 21 Dec 2006 11:47:36 -0500 Received: from bay0-omc3-s27.bay0.hotmail.com ([65.54.246.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxR4t-0002gS-UL for tls@ietf.org; Thu, 21 Dec 2006 11:47:36 -0500 Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc3-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 08:47:31 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Stefan Santesson , Mark Brown , "tls@ietf.org" Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Thu, 21 Dec 2006 08:47:31 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2006 16:47:31.0483 (UTC) FILETIME=[B50906B0:01C7251F] X-Spam-Score: 2.4 (++) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 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: , Content-Type: multipart/mixed; boundary="===============2027121536==" Errors-To: tls-bounces@lists.ietf.org --===============2027121536== Content-Type: multipart/alternative; boundary="_e3e9ea87-f7de-4524-b8b4-3535cfe5d8c7_" --_e3e9ea87-f7de-4524-b8b4-3535cfe5d8c7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have the good basis of liaison here, as we did so successfully (ultimate= ly) obtain in the PKI world; a informal partnership between ABA-ISC and IETF.=20 =20 But the onus is wrong, so far, in the compromise. There is just no point ou= tsiders arguing anything in=20 IETF: its a cult mentality during design, and is very fearful of change, on= ce the torturous=20 "commenting" process comes out with a consensus lest it be lost. IETF quick= ly enter reactionary mode=20 of reasoning, as we have seen; out comes the Chenytank, to publicly dunk fo= lk in! =20 Marc's research is, in Peter's analysis, founded on NCSC Red Book doctrine = - partitioned N-TCBs and=20 multi-level enforcement. We don't openly engineer using those design precep= ts, in IETF - tho most if not=20 all of our senior engineers are Very well versed in it, and its associated = trust modelling. Many of IETF=20 "staff" engineer are or have been funded by folks who ultimately assume and= often religiously enforce=20 this *kind* of design indoctrination, furthermore. Red Book precepts don't= go down well everywhere,=20 even in the UK security community, military of otherwise, mostly for simila= r religious reasons. (They have=20 their own equivalent doctrinal models, religiously imposed.)=20 =20 But, caveats aside! http://www.windowsecurity.com/whitepaper/rainbow_series= /=20 see Red Book, part B. =20 I happen to like the Red Book's TNI, as the spirit of its author(s) comes t= hrough. I'm an independent,=20 particularly in the USG internal doctrinal wars between DoD/NSA, DARPA, GSA= -- and DHS these days.=20 Part B was/is a very USEFUL conceptual framework (being a _technical ration= ale_), even if Part A is very=20 dated. And, its purely technical (allowing for its doctrinal biases, and it= s tendency to meander around=20 the old political issues of the day). If we now point to the two main terms= Marc uses: TLS Authorization,=20 and TLS Evidence, we can perhaps map these onto TNI doctrine. And we have n= ot strayed into legalisms,=20 yet! We are still firmly in IETFland: albeit circa 1987! =20 While designed as an evaluation model for making reasoned conclusions about= network systems, from trusted=20 components, its also a useful design tool. (Using the mental framework of = the auditor at design-time, always=20 makes passing tests at audit-time easier!), And it provides "Specific guid= elines for actually partitioning the=20 various network policy elements to [trusted] components " =20 If we simply quote the guts of this 1987 view of the networking world, foun= ded (in the TNI doctrine) on=20 TNI's "access control concept" : we can see that=20 =20 Using the definitions provided above, the followingconclusion may= be stated: if it is supposed (1) that a sub-ject is confined to a single c= omponent throughout its life-time, (2) that it may directly access only= objects withinits component, (3) that every component contains a component= reference monitor that mediates all accesses made locally(and enforce th= e same access control policy), and (4) thatall communications channels= linking components do notcompromise the security of the information= entrusted tothem, one may conclude that the total collection of com-= ponent reference monitors is a reference monitor for thenetwork. =20 =20 TLS Authorization maps to the confinement objective. TLS evidence maps to t= he "data" given to the=20 (partitioned) reference monitor to allow (or not allow) "non-local" access,= subject to the (MAC/DAC) algebra=20 in the selected enforcement model for access control. TLS itself of course = maps onto the Communication channel, where its the key management (certs/labels/trusted s= tacks) of the=20 SAs/TLSConnections that now "distributes" the access control concept across= the partitions of the=20 trusted net, whilst using PKI/crypto/TLSHandshakes/FIPSboxes to enforce cen= tralized policy at=20 all those edges. =20 What worries me about the research is the politics endgame. I'm not sure I = *want* IETF to=20 standardize the use of partitioned access control concepts - in order to cr= eate an infrastructure=20 that enforces the local vs non-local separation. For local and non-local, o= ne can read national vs transnational/bilateral. =20 At the same time, if we step into the legal domain, for a moment, there is = no internet law. There is=20 only a collection of national laws (ignoring the specialized non-representa= tive international law regime),=20 and one necessarily steps from local law to non-local law, even with the in= ternal political structures of the US or the EU! =20 So, before we accept charter modification, we have to develop an understand= ing of the endgame. Then, the liaisons can be placed on a sound footing. Lots of tortuous and tortious commenting would surely happen, a few dunkings wou= ld no doubt=20 occur, and you never know, like PKI, another miracle COULD happen allowing law and technology to converge to cause even an IETF security protocol to b= ecome willingly adopted into the mainstream of society. =20 The timing is right for this issue to be raised. =20 Peter. =20 =20 =20 =20 =20 > From: stefans@microsoft.com> To: mark@redphonesecurity.com; tls@ietf.org>= Date: Thu, 21 Dec 2006 12:47:45 +0000> Subject: RE: [TLS] Please discuss: = draft-housley-evidence-extns-00 (resend)> CC: > > Mark,> > > Thanks for you= r helpful comments. I don't agree entirely with you,> > specifically your p= osition that signatures are (must be?) application> > level constructs> > I= don't think I ever said that. I said that evidence is formed in an applica= tion context.> > > Would the TLS WG be willing to extend the> > charter for= evidence even if a large part of the discussion was hosted> > by a lawyer = community and could take some time to hash out?> >> > My vote is NO.> > The= legal and technical side of this can and must be separated. If the legal s= ide wants to present some requirements for security properties, fine. But a= security protocol must be defined on technical grounds for the security pr= operties it brings. The technical community in IETF is quite capable of tha= t. It is not capable of determining what a lawyers will accept or not accep= t in the hundreds of legal systems around this globe.> > I agree with Ari, = this protocol has potential, but only if we can isolate it to the technical= discussion.> > > Stefan Santesson> Senior Program Manager> Windows Securit= y, Standards> > > > -----Original Message-----> > From: Mark Brown [mailto:= mark@redphonesecurity.com]> > Sent: den 20 december 2006 18:20> > To: tls@i= etf.org> > Cc: Stefan Santesson; 'EKR'> > Subject: RE: [TLS] Please discuss= : draft-housley-evidence-extns-00> > (resend)> >> > Stefan, (resend, to tls= @ietf.org, with additions to the first> > paragraph)> >> > Thanks for your = helpful comments. I don't agree entirely with you,> > specifically your pos= ition that signatures are (must be?) application> > level> > constructs, bu= t you're probably in the majority on this issue. My> > opinion> > is based = on personal experience though. I am working on a router> > project> > that = uses TLS Evidence and Authorizations at the TLS level only:> >> > http://ww= w.navysbir.com/06_1/215.htm> >> > The router works below the application-le= vel and aims at high assurance> > under Common Criteria, e.g. EAL6. Its des= ign and implementation has> > been> > and will continue to be carefully scr= utinized. This project does not> > depend> > on "signer's intent" though, a= nd perhaps intent is what you locate at> > the> > application level?> >> > = I think you're right about this: the wisest choice may be to wait and> > se= e> > how things pan out in the legal community, and not try to extract a> >= final> > answer from them too soon. Would the TLS WG be willing to extend = the> > charter for evidence even if a large part of the discussion was host= ed> > by a> > lawyer community and could take some time to hash out?> >> > = For those of you who are interested in the legal aspect of "evidence",> > I= am> > currently engaged in conversation with the American Bar Association'= s> > Information Security Committee listserv. If you would like to enter> >= that> > discussion, please let me know.> >> > The ABA ISC discussion has r= ecently rehashed the use of the term> > "evidence"> > with respect to TLS E= vidence. To summarize that discussion as fairly> > as I> > can, I think as = long as one spells evidence with a lowercase "e" and> > not as> > Evidence = or EVIDENCE the lawyers on the ISC listserv are comfortable> > with> > the = term. I also plan to work closely with the ABA Digital Evidence> > Project>= > over the next year as well, and my first project with DEP is to hash> > = out> > terms together.> >> > The following is a snippet -- really, a teaser= -- for those of you with> > some> > inclination to join the ABA ISC group:= > >> > (mark)> > > The TLS definition of "evidence" is unstated to allow it= to flex with> > the> > > prevailing> > > definition in the legal world (th= is decade's definition or the> > next's).> > >> > > You say the definition = of evidence is anything that can be "thrown> > into> > > the> > > pot", whi= ch seems reasonable to me.> > >> > (Steven Teppler)> > > > First, what is u= nknown is the definition of "evidence" as the> > technical> > > > protocol = means it. In the legal world, anything can be, and> > usually> > > > thrown= > > > > into the pot as, evidence. How is this specie of evidence> > differ= ent> > > from> > > > other evidence?> > >> > (mark)> > > TLS Evidence does = not claim some special privilege e.g. being> > > non-repudiable. It's just = evidence like everything else in the pot.> > The> > > specter of duress is = never eliminated, for example. How could it be?> > > Neither does TLS Evide= nce claim any special privileges to magically> > gain> > > affirmatives to = any of the following:> > >> > (Steven Teppler)> > > > Is EG'd evidence auto= matically admissible? Does it> > > > automatically exclude contradictory di= gital data or testimony?> > Does it> > > > generate enough evidence to surv= ive a summary judgment motion?> > Does it> > > > satisfy a burden of produc= tion? Burden of persuasion? If so, why> > isn't> > > > some modifier, such = as "trusted evidence" or "summary judgment> > > eliminator"> > > > used?> >= >> > (mark)> > > No thank you! If a court chose to admit TLS Evidence into= a trial> > then> > > that> > > court could examine it as a record like any= thing else. The TLS> > Evidence> > > draft standard _only_ defines a minimu= m technical standard for> > security> > > measures including cryptographic/= equality tests which must be passed> > > before TLS Evidence is "born".> >>= > Best regards,> >> > mark> > > __________________________________________= _____> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/= listinfo/tls _________________________________________________________________ Get into the holiday spirit, chat with Santa on Messenger. http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=3Den-= us= --_e3e9ea87-f7de-4524-b8b4-3535cfe5d8c7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have the good basis of liaison here, as we did so successfully (ul= timately) obtain in the PKI world;
a informal partnership between ABA-ISC and IETF.
 
But the onus is wrong, so far, in the compromise. There is just no point ou= tsiders arguing anything in
IETF: its a cult mentality during design, and is very fearful of change, on= ce the torturous
"commenting" process comes out with a consensus lest it be lost. IETF quick= ly enter reactionary mode
of reasoning, as we have seen; out comes the Chenytank, to publicly dunk fo= lk in!
 
Marc's research is, in Peter's analysis, founded on NCSC Red= Book doctrine - partitioned N-TCBs and
multi-level enforcement. We don't openly engineer using those design precep= ts, in IETF - tho most if not
all of our senior engineers are Very well versed in it, and its associated = trust modelling. Many of IETF
"staff" engineer are or have been funded by folks who ultimately assum= e and often religiously enforce
this *kind* of design indoctrination, furthermore.  Red Book prec= epts don't go down well everywhere,
even in the UK security community, military of otherwise, mostly for simila= r religious reasons. (They have
their own equivalent doctrinal models, religiously imposed.)
 
But, caveats aside! http://www.windowsecurity.com/whitepaper/rainbow_series/&= nbsp;
see Red Book, part B.
 
I happen to like the Red Book's TNI, as the spirit of its author(s)&nb= sp;comes through. I'm an independent,
particularly in the USG internal doctrinal wars between DoD/NSA, DARPA, GSA= -- and DHS these days.
Part B was/is a very USEFUL conceptual framework (being a _technical ration= ale_), even if Part A is very
dated. And, its purely technical (allowing for its doctrinal biases, and it= s tendency to meander around
the old political issues of the day). If we now point to the two main terms= Marc uses: TLS Authorization,
and TLS Evidence, we can perhaps map these onto TNI doctrine. And we have n= ot strayed into legalisms,
yet! We are still firmly in IETFland: albeit circa 1987!
 
While designed as an evaluation model for making reasoned conclusions about= network systems, from trusted
components, its  also a useful design tool. (Using the mental framewor= k of the auditor at design-time, always
makes passing tests at audit-time easier!), And it provides "Specific = guidelines  for  actually partitioning the
various network policy elements to [trusted] components "
 
If we simply quote the guts of this 1987 view of the networking world, foun= ded (in the TNI doctrine) on
TNI's "access control concept" : we can see that
 
     Using the definitions  provided  above,&= nbsp; the  following
conclusion  may be stated: if it is suppo= sed (1) that a sub-
ject is confined to a single component throughout it= s  life-
time,  (2)  that  it may directly access on= ly objects within
its component, (3) that every component contains a com= ponent
reference  monitor  that  mediates all accesses ma= de locally
(and enforce the same access control policy), and  (4)&n= bsp; that
all   communications  channels  linking&nb= sp; components  do  not
compromise the security  of = the  information  entrusted  to
them,  one  ma= y  conclude  that the total collection of com-
ponent referenc= e monitors is a  reference  monitor  for  the
networ= k.  
 
TLS Authorization maps to the confinement objective. TLS evidence maps to t= he "data" given to the
(partitioned) reference monitor to allow (or not allow) "non-local" access,= subject to the (MAC/DAC) algebra
in the selected enforcement model for access control. TLS itself of course = maps onto the
Communication channel, where its the key management (certs/labels/trusted s= tacks) of the
SAs/TLSConnections that now "distributes" the access control concept across= the partitions of the
trusted net, whilst using PKI/crypto/TLSHandshakes/FIPSboxes to enforce cen= tralized policy at
all those edges.
 
What worries me about the research is the politics endgame. I'm not sure I = *want* IETF to
standardize the use of partitioned access control concepts - in order to cr= eate an infrastructure
that enforces the local vs non-local separation. For local and non-local, o= ne can read national vs
transnational/bilateral.
 
At the same time, if we step into the legal domain, for a moment, there is = no  internet law. There is
only a collection of national laws (ignoring the specialized non-representa= tive international law regime),
and one necessarily steps from local law to non-local law, even with the in= ternal political
structures of the US or the EU!
 
So, before we accept charter modification, we have to develop an understand= ing
of the endgame. Then, the liaisons can be placed on a sound footing. Lots of tortuous and tortious commenting would surely happen, a few dunkings wou= ld no doubt
occur, and you never know, like PKI, another miracle COULD happen allowing<= BR> law and technology to converge to cause even an IETF security pro= tocol to become willingly
adopted into the mainstream of society.
 
The timing is right for this issue to be raised.
 
Peter.
 
 
 
 
 

> From: stefans@microsoft.com
> To: mark@redphonesecurity.com; tls= @ietf.org
> Date: Thu, 21 Dec 2006 12:47:45 +0000
> Subject: RE= : [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)
> CC= :
>
> Mark,
>
> > Thanks for your helpful com= ments. I don't agree entirely with you,
> > specifically your posi= tion that signatures are (must be?) application
> > level construc= ts
>
> I don't think I ever said that. I said that evidence is= formed in an application context.
>
> > Would the TLS WG b= e willing to extend the
> > charter for evidence even if a large p= art of the discussion was hosted
> > by a lawyer community and cou= ld take some time to hash out?
> >
>
> My vote is NO.=
>
> The legal and technical side of this can and must be sepa= rated. If the legal side wants to present some requirements for security pr= operties, fine. But a security protocol must be defined on technical ground= s for the security properties it brings. The technical community in IETF is= quite capable of that. It is not capable of determining what a lawyers wil= l accept or not accept in the hundreds of legal systems around this globe.<= BR>>
> I agree with Ari, this protocol has potential, but only if= we can isolate it to the technical discussion.
>
>
> S= tefan Santesson
> Senior Program Manager
> Windows Security, St= andards
>
>
> > -----Original Message-----
> &= gt; From: Mark Brown [mailto:mark@redphonesecurity.com]
> > Sent: = den 20 december 2006 18:20
> > To: tls@ietf.org
> > Cc: S= tefan Santesson; 'EKR'
> > Subject: RE: [TLS] Please discuss: draf= t-housley-evidence-extns-00
> > (resend)
> >
> >= Stefan, (resend, to tls@ietf.org, with additions to the first
> >= paragraph)
> >
> > Thanks for your helpful comments. I d= on't agree entirely with you,
> > specifically your position that = signatures are (must be?) application
> > level
> > const= ructs, but you're probably in the majority on this issue. My
> > o= pinion
> > is based on personal experience though. I am working on= a router
> > project
> > that uses TLS Evidence and Auth= orizations at the TLS level only:
> >
> > http://www.navy= sbir.com/06_1/215.htm
> >
> > The router works below the = application-level and aims at high assurance
> > under Common Crit= eria, e.g. EAL6. Its design and implementation has
> > been
>= ; > and will continue to be carefully scrutinized. This project does not=
> > depend
> > on "signer's intent" though, and perhaps = intent is what you locate at
> > the
> > application leve= l?
> >
> > I think you're right about this: the wisest ch= oice may be to wait and
> > see
> > how things pan out in= the legal community, and not try to extract a
> > final
> &= gt; answer from them too soon. Would the TLS WG be willing to extend the> > charter for evidence even if a large part of the discussion was = hosted
> > by a
> > lawyer community and could take some = time to hash out?
> >
> > For those of you who are intere= sted in the legal aspect of "evidence",
> > I am
> > curr= ently engaged in conversation with the American Bar Association's
> &= gt; Information Security Committee listserv. If you would like to enter
= > > that
> > discussion, please let me know.
> >> > The ABA ISC discussion has recently rehashed the use of the term=
> > "evidence"
> > with respect to TLS Evidence. To summ= arize that discussion as fairly
> > as I
> > can, I think= as long as one spells evidence with a lowercase "e" and
> > not a= s
> > Evidence or EVIDENCE the lawyers on the ISC listserv are com= fortable
> > with
> > the term. I also plan to work close= ly with the ABA Digital Evidence
> > Project
> > over the= next year as well, and my first project with DEP is to hash
> > o= ut
> > terms together.
> >
> > The following is = a snippet -- really, a teaser -- for those of you with
> > some> > inclination to join the ABA ISC group:
> >
> >= (mark)
> > > The TLS definition of "evidence" is unstated to a= llow it to flex with
> > the
> > > prevailing
> = > > definition in the legal world (this decade's definition or the> > next's).
> > >
> > > You say the definit= ion of evidence is anything that can be "thrown
> > into
> &= gt; > the
> > > pot", which seems reasonable to me.
> = > >
> > (Steven Teppler)
> > > > First, what = is unknown is the definition of "evidence" as the
> > technical> > > > protocol means it. In the legal world, anything can be= , and
> > usually
> > > > thrown
> > > = > into the pot as, evidence. How is this specie of evidence
> >= different
> > > from
> > > > other evidence?> > >
> > (mark)
> > > TLS Evidence does not= claim some special privilege e.g. being
> > > non-repudiable. = It's just evidence like everything else in the pot.
> > The
>= ; > > specter of duress is never eliminated, for example. How could i= t be?
> > > Neither does TLS Evidence claim any special privile= ges to magically
> > gain
> > > affirmatives to any of= the following:
> > >
> > (Steven Teppler)
> >= ; > > Is EG'd evidence automatically admissible? Does it
> >= > > automatically exclude contradictory digital data or testimony?> > Does it
> > > > generate enough evidence to surv= ive a summary judgment motion?
> > Does it
> > > > = satisfy a burden of production? Burden of persuasion? If so, why
> &g= t; isn't
> > > > some modifier, such as "trusted evidence" o= r "summary judgment
> > > eliminator"
> > > > us= ed?
> > >
> > (mark)
> > > No thank you! I= f a court chose to admit TLS Evidence into a trial
> > then
>= ; > > that
> > > court could examine it as a record like = anything else. The TLS
> > Evidence
> > > draft standa= rd _only_ defines a minimum technical standard for
> > security> > > measures including cryptographic/equality tests which must = be passed
> > > before TLS Evidence is "born".
> >
= > > Best regards,
> >
> > mark
>
> > _______________________________________________
> TLS mailing l= ist
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listin= fo/tls


Get into the holiday spirit, chat with Santa on M= essenger.=A0 Ho-Ho-Ho! = --_e3e9ea87-f7de-4524-b8b4-3535cfe5d8c7_-- --===============2027121536== 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 --===============2027121536==-- From tls-bounces@lists.ietf.org Thu Dec 21 12:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRTU-0000a7-9V; Thu, 21 Dec 2006 12:12:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRTT-0000Tp-4Z for tls@ietf.org; Thu, 21 Dec 2006 12:12:55 -0500 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRTR-0005Y6-MK for tls@ietf.org; Thu, 21 Dec 2006 12:12:55 -0500 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kBLHCm514119; Thu, 21 Dec 2006 18:12:48 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 21 Dec 2006 18:12:49 +0100 (MET) Message-ID: <458AC018.9050604@edelweb.fr> Date: Thu, 21 Dec 2006 18:10:48 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt References: <45880C64.2080305@edelweb.fr> <86lkl3r6aa.fsf@raman.networkresonance.com> <458A6805.4070500@edelweb.fr> <86irg5jly8.fsf@delta.rtfm.com> In-Reply-To: <86irg5jly8.fsf@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1371331911==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1371331911== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080309090108030507010605" This is a cryptographically signed message in MIME format. --------------ms080309090108030507010605 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit EKR wrote: > Peter Sylvester writes: > >> Would you mind giving a little bit more detailed explanation in particular >> what are the reasons why this cannot be on standards tracks, or what would >> be necessary if it would be etc. >> > > There are two reasons. First, as a matter of policy we are attempting > to move new work to Standards Track only where there is fairly strong > support for the work. In this case, the support for this work did > not appear to be particularly strong. > Several existing interoperable implementations exist. I think that this is perfectly in the spirit of the IETF. If accepted as a standards track, the protocol would probably directly directly go to draft. > Second, the IPR issues surrounding all the ZKPP protocols are quite > murky and thus it would have required an affirmative decision by > the WG to move this document forward as a Proposed Standard > despite said issues. > Several have requested the document being forwarded. I have not read any comment so far that is against the proposal except may you in this comment. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms080309090108030507010605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjIxMTcxMDQ4WjAjBgkqhkiG9w0B CQQxFgQUOLzv/9ANSgmYeE2EMJBy4Y2u4WMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAZmBYDKpGbAn79ICf wIIUV+9Ehq2+A79OO2zfri3n42Hxl9gyeD7dozxlYlpwLmJUtvznVm/o+aUI0DwcJiiTbjCK bA1jJYH+OKGyGj49zddlUMUanD+Cs0pLDMCO3wE6/enF+slpJmJPtoqlfzfiZbQie8204ys9 ZBQBrpp8YPwAAAAAAAA= --------------ms080309090108030507010605-- --===============1371331911== 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 --===============1371331911==-- From tls-bounces@lists.ietf.org Thu Dec 21 12:15:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRVn-0002pg-7S; Thu, 21 Dec 2006 12:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxRVl-0002ld-Lh for tls@ietf.org; Thu, 21 Dec 2006 12:15:17 -0500 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxRVk-0005sO-6s for tls@ietf.org; Thu, 21 Dec 2006 12:15:17 -0500 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kBLHFD514219; Thu, 21 Dec 2006 18:15:14 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Thu, 21 Dec 2006 18:15:14 +0100 (MET) Message-ID: <458AC0A9.5010305@edelweb.fr> Date: Thu, 21 Dec 2006 18:13:13 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] WGLC: draft-ietf-tls-srp-13 References: <20061221154549.0A8941CC6B@delta.rtfm.com> In-Reply-To: <20061221154549.0A8941CC6B@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0548670156==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0548670156== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040305000706000407080301" This is a cryptographically signed message in MIME format. --------------ms040305000706000407080301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Do ciphersuites in the experimental range mean that they could be reused by any other experimental protocol, or does IANA reserve values? EKR wrote: > This is a Working Group Last Call for draft-ietf-tls-srp-13. > > This document is intended for Experimental status. Please provide > comments to the authors and the list. > > This WGLC will end Fri Jan 12 (to allow time for people's holidays). > > -Ekr > > > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms040305000706000407080301 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMjIxMTcxMzEzWjAjBgkqhkiG9w0B CQQxFgQUms023oA1VtWyhHqPs6Cl4T7v8bgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAw8C/nD/Dsx8EcBJB lsGo7s3/JUCtzaPcJ1W0SzqQgMMU/CV5kzpf+EeZ3l0OyFi8XQfwrzDSyMzoWvpz+6wY8BtU 9mlSwCg0mX0/8SKccQaPDen/EE32aykGMOWXQi/JlWZg5XOtO8rny8fw910lyu0NX+Ed7ytl yHxPhikF7PUAAAAAAAA= --------------ms040305000706000407080301-- --===============0548670156== 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 --===============0548670156==-- From tls-bounces@lists.ietf.org Thu Dec 21 12:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxS3k-0004ZO-Os; Thu, 21 Dec 2006 12:50:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxS3h-0004Xa-Sa for tls@ietf.org; Thu, 21 Dec 2006 12:50:21 -0500 Received: from bay0-omc2-s28.bay0.hotmail.com ([65.54.246.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxS3e-0002zI-Vb for tls@ietf.org; Thu, 21 Dec 2006 12:50:21 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc2-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 09:50:18 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Peter Sylvester Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Thu, 21 Dec 2006 09:50:18 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2006 17:50:18.0325 (UTC) FILETIME=[7A3F8050:01C72528] X-Spam-Score: 2.6 (++) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0281400012==" Errors-To: tls-bounces@lists.ietf.org --===============0281400012== Content-Type: multipart/alternative; boundary="_738ff1ee-1f72-410a-a465-83132950f48d_" --_738ff1ee-1f72-410a-a465-83132950f48d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An important concept in IETF is that the WG is distinct from the mailing li= st. Furthermore, WG and authors are distinct. Furthermore IESG processes are yet more distinct. There is no= t a WG in IETF that would have me, for example! Put Peter's name on an I-D, and its the kiss of death= ! =20 The mailing list arguments are NOT the place where Eric's jugements are bas= ed, if I look at 10 years of history of viewing previous resolutions in IETF. They are in= a place you and=20 I cannot see, with political forces that are not visible. There is no accou= ntability, and=20 no means of reasoning against them. Many personal, funding, back-project & = other biases come into play. The ONLY way to argue against this process is to deploy. If there is adopti= on, those=20 non-mailing list processes do Change. They are still very biased and un acc= ountable, but the politics DOES WORK. IETF is not a plebs paradise; its built on the poli= tics of=20 wars-of-adoption. One has to admit, at the end of the game, its specificati= ons are models of engineering clarity and do-ability, when they stay below 50 pages= . =20 > Date: Thu, 21 Dec 2006 18:10:48 +0100 > EKR wrote:> > Peter Sylvester writes:> > > >= > Would you mind giving a little bit more detailed explanation in particula= r> >> what are the reasons why this cannot be on standards tracks, or what = would> >> be necessary if it would be etc.> >> > >> > There are two reasons= . First, as a matter of policy we are attempting> > to move new work to Sta= ndards Track only where there is fairly strong> > support for the work. In = this case, the support for this work did> > not appear to be particularly s= trong.> > > Several existing interoperable implementations exist. I think t= hat this is> perfectly in the spirit of the IETF. If accepted as a standard= s track, > the protocol> would probably directly directly go to draft. =20 _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=3Dimprove&local= e=3Den-US&source=3Dwlmemailtaglinenov06= --_738ff1ee-1f72-410a-a465-83132950f48d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An important concept in IETF is that the WG is distinct from the mail= ing list. Furthermore, WG and authors
are distinct. Furthermore IESG processes are yet more distinct. There is no= t a WG in IETF that would
have me, for example! Put Peter's name on an I-D, and its the kiss of death= !
 
The mailing list arguments are NOT the place where Eric's jugements are bas= ed, if I look
at 10 years of history of viewing previous resolutions in IETF. They a= re in a place you and
I cannot see, with political forces that are not visible. There is no accou= ntability, and
no means of reasoning against them. Many personal, funding, back-project&nb= sp;& other
biases come into play.

The ONLY way to argue against this process is to deploy. If there is adopti= on, those
non-mailing list processes do Change. They are still very biased and un acc= ountable, but
the politics DOES WORK. IETF is not a plebs paradise; its built on the poli= tics of 
wars-of-adoption. One has to admit, at the end of the game, its specificati= ons are
models of engineering clarity and do-ability, when they stay below 50 pages= .
 

> Date: Thu, 21 Dec 2006 18:10:48 +0100

> EKR wrote:
> > Peter Sylvester <Peter.Sylvester@edelweb.fr= > writes:
> >
> >> Would you mind giving a little = bit more detailed explanation in particular
> >> what are the r= easons why this cannot be on standards tracks, or what would
> >&g= t; be necessary if it would be etc.
> >>
> >
> = > There are two reasons. First, as a matter of policy we are attempting<= BR>> > to move new work to Standards Track only where there is fairly= strong
> > support for the work. In this case, the support for th= is work did
> > not appear to be particularly strong.
> >=
> Several existing interoperable implementations exist. I think tha= t this is
> perfectly in the spirit of the IETF. If accepted as a sta= ndards track,
> the protocol
> would probably directly directl= y go to draft.

 

View Athletes' Collections with Live Search. See it! = --_738ff1ee-1f72-410a-a465-83132950f48d_-- --===============0281400012== 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 --===============0281400012==-- From tls-bounces@lists.ietf.org Thu Dec 21 13:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSEE-0002jF-RD; Thu, 21 Dec 2006 13:01:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxSED-0002hG-Cw for tls@ietf.org; Thu, 21 Dec 2006 13:01:13 -0500 Received: from bay0-omc2-s20.bay0.hotmail.com ([65.54.246.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxSEC-00053V-0v for tls@ietf.org; Thu, 21 Dec 2006 13:01:13 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc2-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 10:01:11 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Peter Sylvester Subject: RE: [TLS] WGLC: draft-ietf-tls-srp-13 Date: Thu, 21 Dec 2006 10:01:11 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2006 18:01:11.0295 (UTC) FILETIME=[FF72D0F0:01C72529] X-Spam-Score: 2.6 (++) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1868151323==" Errors-To: tls-bounces@lists.ietf.org --===============1868151323== Content-Type: multipart/alternative; boundary="_b4816b50-297c-4e64-b33c-326a1e272659_" --_b4816b50-297c-4e64-b33c-326a1e272659_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Experimental is simply a formal definition. You do anything you like. No ne= ed to register the=20 (local) experimental values with IANA. By definition, an experiment is loca= l to its community.One simply defines a ciphersuite in the local class (use= d by all instances and all vendors in the self-defining experimental community). That value is properly contex= tualized by the TLS=20 application, in engineer terms. yes, it may change later upon registration;= but how hard is that=20 to do, these days!? I just reasoned the need to define my community a new naming type, in the T= LS extensions for=20 server name indication - mainly so I dont "abuse" host_name. I dont need to= ask or register! Ideally,=20 the std could have reserved a "local" class of identified indication types= ; but, it didn't. Perhaps it=20 will improve, later like TLS did for ciphersuites (improving upon SSL here!= ) assuming the politics=20 is not attempting to restrict the name forms, the classes of indication, or= limit applicability of the=20 construct to IP bearers. > Date: Thu, 21 Dec 2006 18:13:13 +0100> From: Peter.Sylvester@edelweb.fr> = To: ekr@networkresonance.com> Subject: Re: [TLS] WGLC: draft-ietf-tls-srp-1= 3> CC: tls@ietf.org> > Do ciphersuites in the experimental range mean that = they could be> reused by any other experimental protocol, or does IANA rese= rve values?> > _________________________________________________________________ Get into the holiday spirit, chat with Santa on Messenger. http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=3Den-= us= --_b4816b50-297c-4e64-b33c-326a1e272659_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Experimental is simply a formal definition. You do anything you like.= No need to register the
(local) experimental values with IANA. By definition, an experiment is loca= l to its community.

One simply defines a ciphersuite in the local cl= ass (used by all instances and all vendors
in the self-defining experimental community). That value is properly c= ontextualized by the TLS
application, in engineer terms. yes, it may change later upon registration;= but how hard is that
to do, these days!?

I just reasoned the need to define my community a new naming type, in the T= LS extensions for
server name indication - mainly so I dont "abuse" host_name. I dont need to= ask or register! Ideally,
the std could  have reserved a "local" class of identified indica= tion types; but, it didn't. Perhaps it
will improve, later like TLS did for ciphersuites (improving upon SSL here!= ) assuming the politics
is not attempting to restrict the name forms, the classes of indication, or= limit applicability of the
construct to IP bearers.



> Date: Thu, 21 Dec 2006 18:13:13 +0100
> From: Peter.Sylvester@ed= elweb.fr
> To: ekr@networkresonance.com
> Subject: Re: [TLS] WG= LC: draft-ietf-tls-srp-13
> CC: tls@ietf.org
>
> Do ciph= ersuites in the experimental range mean that they could be
> reused b= y any other experimental protocol, or does IANA reserve values?
> >

Get into the holiday spirit, chat with Santa on Messen= ger.=A0 Ho-Ho-Ho! = --_b4816b50-297c-4e64-b33c-326a1e272659_-- --===============1868151323== 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 --===============1868151323==-- From tls-bounces@lists.ietf.org Thu Dec 21 14:08:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTH7-0005wX-T3; Thu, 21 Dec 2006 14:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTH6-0005wK-I9 for tls@ietf.org; Thu, 21 Dec 2006 14:08:16 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxTH4-0006wV-IX for tls@ietf.org; Thu, 21 Dec 2006 14:08:16 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kBLJ890d018285 for ; Thu, 21 Dec 2006 14:08:10 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 21 Dec 2006 14:08:16 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Dec 2006 14:08:16 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-eb140c65-9c9b-426c-9056-f90607080543" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Date: Thu, 21 Dec 2006 14:08:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend) Thread-Index: AcclH+b/dwiACRgFTxumJ0qUzghXFwAA4seg From: "Kemp, David P." To: X-OriginalArrivalTime: 21 Dec 2006 19:08:16.0041 (UTC) FILETIME=[5E625190:01C72533] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14888000 X-TM-AS-Result: : Yes--25.466500-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTQ3MDE1LTE1MDU2Ny03MDAx?= =?us-ascii?B?NjctNzA5MDY5LTcwMDE5MC03MDE2NTEtNzEwMjgzLTcwMTM4NC03?= =?us-ascii?B?MDExMTAtNzAzNjQzLTcwMTIzOC03MDExMDItNzExMjkzLTcwMzEw?= =?us-ascii?B?My0xMjE1MzAtNzAzMjEyLTcwMjc3Ni03MDI4MTktNzA0MDE1LTEy?= =?us-ascii?B?MTM3MS03MTAwODctNzExNTIwLTcxMDk0Ni03MTAzNjMtNzAwNzU0?= =?us-ascii?B?LTcwMDY3Ny03MDI1MjctMTIxNjAwLTcwNjc0MC03MDE4ODMtNzAw?= =?us-ascii?B?ODM1LTcxMDI1MS03MDA3OTMtNzA0NzkwLTcxMDA1OC03MDE3MTAt?= =?us-ascii?B?NzAxMDAyLTcxMTc4OS03MTAwODMtNzAxMDM0LTcwODA3NS03MDI4?= =?us-ascii?B?NTgtNzExMjM4LTcxMDAxNS03MDE1MjctNzEwMDcyLTcwNDIxMy03?= =?us-ascii?B?MDAxODgtNzAwMTUxLTcwMjAzMy03MDA2NzktNzAwMzE3LTE4ODAx?= =?us-ascii?B?OS0xMzk2MjEtMTM5MDA2LTcwMzg4Ny0xMzkwMTAtMTg3MDY3LTcw?= =?us-ascii?B?MzY3NC0xMzk3MDQtNzAyNDAzLTcwMDg3NC03MDI5MTEtMTExNjA0?= =?us-ascii?B?LTE4ODExOS03MDE0MjQtNzAwOTYyLTcwODUwMi03MDAwMjgtNzAw?= =?us-ascii?B?MDAzLTcwMjQwNS03MDMzNTgtMTg4MTE4LTcxMDMwMC03MDI2MjEt?= =?us-ascii?B?NzA1NjI3LTE4ODExNC0xODgwMzgtNzAxNzA5LTcwMDA2Mi03MDk5?= =?us-ascii?B?ODEtNzAwNDMyLTcwMTM3OC03MDI3NjgtNzAxNjE3LTcwMTY5Mi03?= =?us-ascii?B?MDc5MDctNzAwNzk5LTcwMDA0MS03MDI2MDEtMTkwNjQyLTE5MDY0?= =?us-ascii?B?Mi0xOTA2NDItMTkwNjQyLTE5MDY0Mi0xNDgwNTAtMjAwMjQtMjAw?= =?us-ascii?B?NDA=?= X-Spam-Score: 0.1 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 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 This is a multi-part message in MIME format. ------=_NextPartTM-000-eb140c65-9c9b-426c-9056-f90607080543 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72533.5A224391" ------_=_NextPart_001_01C72533.5A224391 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Be that as it may, the question in my mind remains: why? =20 The first three times I read the SBIR proposal and its references to "a router that can securely enable granular cross-domain messaging" I interpreted "router" in its IETF sense - a layer 3 device that routes IP packets. But such a device would have no access to information protected at layer 3 (IPSec), layer 4 (TLS), or above, and thus would provide no motivation for TLS Authorizations within data plane (RSS producer to RSS consumer) sessions. The abstract also does not appear to discuss management plane (management station to router) traffic, so the only possibility left is control plane (router to router) traffic for which the routers act as TLS endpoints. But a combined IP router / RSS proxy-cross-domain-guard makes about as much sense as a combined IP router / message transfer agent (MTA) for SMTP, so it becomes apparent that the "router" is not a layer 3 device, it must be an application-layer process that routes RSS messages, and thus does not control the flow of IP packets to effect TNI-style network partitioning. =20 Before accepting the SBIR proposal as justification for a new TLS work item (which may well be justified for different reasons), it would be helpful to understand what a MILS platform with TLS Evidence brings to the table that couldn't be more easily accomplished using the same MILS platform with unmodified TLS: passing RSS summaries signed with CMS or xml-dsig through a standard TLS or TCP-only data stream. =20 Dave =20 =20 _____ =20 From: Peter Williams [mailto:home_pw@msn.com]=20 =20 Marc's research is, in Peter's analysis, founded on NCSC Red Book doctrine ... =20 <...> =20 -----Original Message----- From: Mark Brown [mailto:mark@redphonesecurity.com]=20 > I am working on a router project > that uses TLS Evidence and Authorizations at the TLS level only: >=20 > http://www.navysbir.com/06_1/215.htm =20 =20 ------_=_NextPart_001_01C72533.5A224391 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Be that as it may, the question in = my mind remains: why?

 

The first three times I read the = SBIR proposal and its references to “a router that = can

securely enable granular = cross-domain messaging” I interpreted “router” in its = IETF

sense – a layer 3 device that = routes IP packets.  But such a device would have = no

access to information protected at = layer 3 (IPSec), layer 4 (TLS), or above, and thus

would provide no motivation for TLS = Authorizations within data plane (RSS producer

to RSS consumer) sessions. =  The abstract also does not appear to discuss

management plane (management = station to router) traffic, so the only possibility left

is control plane (router to router) traffic for which the routers act as TLS = endpoints.

But a combined IP router / RSS = proxy-cross-domain-guard makes about as much

sense as a combined IP router / = message transfer agent (MTA) for SMTP, so it

becomes apparent that the = “router” is not a layer 3 device, it must be an

application-layer process that = routes RSS messages, and thus does not control the

flow of IP packets to effect = TNI-style network partitioning.

 

Before accepting the SBIR proposal = as justification for a new TLS work item = (which

may well be justified for different reasons), it would be helpful to understand what a = MILS

platform with TLS Evidence brings = to the table that couldn’t be more easily = accomplished

using the same MILS platform with unmodified TLS: passing RSS summaries signed = with

CMS or xml-dsig through a standard = TLS or TCP-only data stream.

 

Dave

 

 

From: = Peter Williams [mailto:home_pw@msn.com]
 
Marc's research is, in Peter's analysis, founded on NCSC = Red Book doctrine = …

 

=

<…>

 

=

-----Original Message-----
From: Mark Brown [mailto:mark@redphonesecurity.com]

> I am working on a router = project

> that uses TLS Evidence and Authorizations at the TLS level = only:

> 

> = http://www.navysbir.com/06_1/215.htm

 

 

------_=_NextPart_001_01C72533.5A224391-- ------=_NextPartTM-000-eb140c65-9c9b-426c-9056-f90607080543 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 ------=_NextPartTM-000-eb140c65-9c9b-426c-9056-f90607080543-- From tls-bounces@lists.ietf.org Thu Dec 21 14:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTkn-000647-HC; Thu, 21 Dec 2006 14:38:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTkm-00063u-8L for tls@ietf.org; Thu, 21 Dec 2006 14:38:56 -0500 Received: from [198.144.196.30] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxTkj-0002rN-Ur for tls@ietf.org; Thu, 21 Dec 2006 14:38:56 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 6536F1CC61; Thu, 21 Dec 2006 11:37:47 -0800 (PST) To: Peter Sylvester Subject: Re: [TLS] WGLC: draft-ietf-tls-srp-13 References: <20061221154549.0A8941CC6B@delta.rtfm.com> <458AC0A9.5010305@edelweb.fr> From: EKR Date: Thu, 21 Dec 2006 11:37:47 -0800 In-Reply-To: <458AC0A9.5010305@edelweb.fr> (Peter Sylvester's message of "Thu, 21 Dec 2006 18:13:13 +0100") Message-ID: <8664c5jb04.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Sylvester writes: > Do ciphersuites in the experimental range mean that they could be > reused by any other experimental protocol, or does IANA reserve values? IANA will reserve the values. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 14:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTw6-0002nv-Fh; Thu, 21 Dec 2006 14:50:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTw5-0002n3-4t for tls@ietf.org; Thu, 21 Dec 2006 14:50:37 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxTw3-0005CK-Ph for tls@ietf.org; Thu, 21 Dec 2006 14:50:37 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 787F05C01E; Thu, 21 Dec 2006 11:53:47 -0800 (PST) To: Peter Sylvester Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-reply-to: Your message of "Thu, 21 Dec 2006 18:10:48 +0100." <458AC018.9050604@edelweb.fr> X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Thu, 21 Dec 2006 11:50:35 -0800 From: Eric Rescorla Message-Id: <20061221195347.787F05C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Sylvester wrote: > EKR wrote: > > Peter Sylvester writes: > > > >> Would you mind giving a little bit more detailed explanation in particular > >> what are the reasons why this cannot be on standards tracks, or what would > >> be necessary if it would be etc. > >> > > > > There are two reasons. First, as a matter of policy we are attempting > > to move new work to Standards Track only where there is fairly strong > > support for the work. In this case, the support for this work did > > not appear to be particularly strong. > > > Several existing interoperable implementations exist. I think that this is > perfectly in the spirit of the IETF. If accepted as a standards track, > the protocol > would probably directly directly go to draft. In a thread starting November 28, 2005, I asked for expressions of support. I received three responses in favor of moving it forward as PS, from you, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi and I judged that this did not meet the bar of WG support for a decision to move it forward at PS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 15:37:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUes-0002wb-Hy; Thu, 21 Dec 2006 15:36:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxUeM-0002ZD-VT for tls@ietf.org; Thu, 21 Dec 2006 15:36:22 -0500 Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxUZp-000427-Qd for tls@ietf.org; Thu, 21 Dec 2006 15:31:45 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 21 Dec 2006 12:31:41 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 21 Dec 2006 12:31:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,200,1165219200"; d="scan'208"; a="29664295:sNHT26297496" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Dec 2006 12:31:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Thu, 21 Dec 2006 15:31:43 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056011D1F79@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt thread-index: AcclI29aeuHMJtVnS1626thLAXPMgwAG1xpw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 21 Dec 2006 20:31:40.0794 (UTC) FILETIME=[057305A0:01C7253F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 =20 I for one would like to (a) see the URLs pointing to free reference = implementation(s), and (b) hear a clarification wrt. IPR status of the = method defined in this draft. I would certainly object advancement beyond Experimental until these two = questions are answered to the satisfaction of the WG. Regards, Uri I speak for myself only. -----Original Message----- From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr]=20 Sent: Thursday, December 21, 2006 12:11 PM To: EKR Cc: tls@ietf.org Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt EKR wrote: > Peter Sylvester writes: > =20 >> Would you mind giving a little bit more detailed explanation in = particular >> what are the reasons why this cannot be on standards tracks, or what = would >> be necessary if it would be etc. >> =20 > > There are two reasons. First, as a matter of policy we are attempting > to move new work to Standards Track only where there is fairly strong > support for the work. In this case, the support for this work did > not appear to be particularly strong. > =20 Several existing interoperable implementations exist. I think that this = is perfectly in the spirit of the IETF. If accepted as a standards track,=20 the protocol would probably directly directly go to draft. > Second, the IPR issues surrounding all the ZKPP protocols are quite > murky and thus it would have required an affirmative decision by > the WG to move this document forward as a Proposed Standard > despite said issues.=20 > =20 Several have requested the document being forwarded. I have not read any comment so far that is against the proposal except = may you in this comment. --=20 To verify the signature, see http://edelpki.edelweb.fr/=20 Cela vous permet de charger le certificat de l'autorit=E9;=20 die Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 21 16:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxV23-0004l6-B7; Thu, 21 Dec 2006 16:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxV21-0004hb-Pw for tls@ietf.org; Thu, 21 Dec 2006 16:00:49 -0500 Received: from bay0-omc1-s16.bay0.hotmail.com ([65.54.246.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxV1j-0002wy-9i for tls@ietf.org; Thu, 21 Dec 2006 16:00:49 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc1-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 13:00:30 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: "Blumenthal, Uri" , Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Thu, 21 Dec 2006 13:00:30 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2006 21:00:30.0657 (UTC) FILETIME=[0C872B10:01C72543] X-Spam-Score: 2.2 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Content-Type: multipart/mixed; boundary="===============1438055380==" Errors-To: tls-bounces@lists.ietf.org --===============1438055380== Content-Type: multipart/alternative; boundary="_a43374d6-1614-4e24-9021-25f167f978ba_" --_a43374d6-1614-4e24-9021-25f167f978ba_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous perme= t de charger le certificat de l'autorit=E9; > die Liste mit zur=FCckgerufen= en Zertifikaten finden Sie da auch.=20 The main problem I have is almost immaterial, and is actually manifest in t= he tag line. =20 The English rendition contains a URL, with obvious benefits. It also focuse= s on the zignature vs. the Zertifikate. The French and German renditions don't; they refer to = the English rendition.=20 The French version then gets hungup on "authority", and the German gets hun= gup on perhaps or=20 perhaps not ever 'finding" stuff. =20 =20 =20 _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=3Dimprove&local= e=3Den-US&source=3Dwlmemailtaglinenov06= --_a43374d6-1614-4e24-9021-25f167f978ba_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> To verify the signature, see http://edelpki.edelweb.fr/
= > Cela vous permet de charger le certificat de l'autorit=E9;
> di= e Liste mit zur=FCckgerufenen Zertifikaten finden Sie da auch.

The main problem I have is almost immaterial, and is actually manifest in t= he tag line.
 
The English rendition contains a URL, with obvious benefits. It also focuse= s on the zignature
vs. the Zertifikate. The French and German renditions don't; they refer to = the English rendition. 
The French version then gets hungup on "authority", and the German gets hun= gup on perhaps or
perhaps not ever 'finding" stuff.
 
 
 

View Athletes' Collections with Live Search. See it! = --_a43374d6-1614-4e24-9021-25f167f978ba_-- --===============1438055380== 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 --===============1438055380==-- From tls-bounces@lists.ietf.org Thu Dec 21 21:57:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxaZl-00024i-H5; Thu, 21 Dec 2006 21:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxaZk-00024Z-P2 for tls@ietf.org; Thu, 21 Dec 2006 21:56:00 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxaZg-00048W-Ar for tls@ietf.org; Thu, 21 Dec 2006 21:56:00 -0500 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 1GxaZe-0007Ak-0W; Thu, 21 Dec 2006 18:55:55 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1GxaZb-0004X1-9f; Thu, 21 Dec 2006 18:55:51 -0800 Date: Thu, 21 Dec 2006 18:55:51 -0800 (PST) From: Tom Wu To: "Blumenthal, Uri" Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: <279DDDAFA85EC74C9300A0598E704056011D1F79@hdsmsx412.amr.corp.intel.com> Message-ID: References: <279DDDAFA85EC74C9300A0598E704056011D1F79@hdsmsx412.amr.corp.intel.com> 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: f824399eb00b5943f8bdbe5dd24fccda X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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, 21 Dec 2006, Blumenthal, Uri wrote: > > I for one would like to (a) see the URLs pointing to free reference implementation(s), and (b) hear a clarification wrt. IPR status of the method defined in this draft. (a) I am aware of the following free implementations of TLS/SRP: - http://www.edelweb.fr/EdelKey/ (OpenSSL, C-based) - http://www.trevp.net/tlslite/ (Python-based) - http://www.gnu.org/software/gnutls/ (C-based, GPL) - http://www.nongnu.org/jessie/ (Java-based) (b) SRP-6 as used in the TLS/SRP specification is available under Stanford's royalty-free licensing terms (http://otl.stanford.edu/pdf/97006.pdf). > I would certainly object advancement beyond Experimental until these two questions are answered to the satisfaction of the WG. > > Regards, > Uri > I speak for myself only. Tom > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > Sent: Thursday, December 21, 2006 12:11 PM > To: EKR > Cc: tls@ietf.org > Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt > > EKR wrote: >> Peter Sylvester writes: >> >>> Would you mind giving a little bit more detailed explanation in particular >>> what are the reasons why this cannot be on standards tracks, or what would >>> be necessary if it would be etc. >>> >> >> There are two reasons. First, as a matter of policy we are attempting >> to move new work to Standards Track only where there is fairly strong >> support for the work. In this case, the support for this work did >> not appear to be particularly strong. >> > Several existing interoperable implementations exist. I think that this is > perfectly in the spirit of the IETF. If accepted as a standards track, > the protocol > would probably directly directly go to draft. >> Second, the IPR issues surrounding all the ZKPP protocols are quite >> murky and thus it would have required an affirmative decision by >> the WG to move this document forward as a Proposed Standard >> despite said issues. >> > Several have requested the document being forwarded. > I have not read any comment so far that is against the proposal except may > you in this comment. > > -- 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 Dec 21 22:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxalx-0000Ag-2P; Thu, 21 Dec 2006 22:08:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxalv-0000Ab-NW for tls@ietf.org; Thu, 21 Dec 2006 22:08:35 -0500 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxalt-0006Ug-AD for tls@ietf.org; Thu, 21 Dec 2006 22:08:35 -0500 Received: from xenon.stanford.edu ([171.64.66.201]) by cs-smtp-3.Stanford.EDU with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Gxalr-0000X2-Un; Thu, 21 Dec 2006 19:08:32 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1Gxalp-0005lr-8c; Thu, 21 Dec 2006 19:08:29 -0800 Date: Thu, 21 Dec 2006 19:08:29 -0800 (PST) From: Tom Wu To: Eric Rescorla Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: <20061221195347.787F05C01E@laser.networkresonance.com> Message-ID: References: <20061221195347.787F05C01E@laser.networkresonance.com> 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-3.Stanford.EDU X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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, 21 Dec 2006, Eric Rescorla wrote: > Peter Sylvester wrote: >> EKR wrote: >>> Peter Sylvester writes: >>> >>>> Would you mind giving a little bit more detailed explanation in particular >>>> what are the reasons why this cannot be on standards tracks, or what would >>>> be necessary if it would be etc. >>>> >>> >>> There are two reasons. First, as a matter of policy we are attempting >>> to move new work to Standards Track only where there is fairly strong >>> support for the work. In this case, the support for this work did >>> not appear to be particularly strong. >>> >> Several existing interoperable implementations exist. I think that this is >> perfectly in the spirit of the IETF. If accepted as a standards track, >> the protocol >> would probably directly directly go to draft. > > In a thread starting November 28, 2005, I asked for expressions of > support. I received three responses in favor of moving it forward > as PS, from you, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi > and I judged that this did not meet the bar of WG support for > a decision to move it forward at PS. Did my vote in favor of Proposed status not count? http://www1.ietf.org/mail-archive/web/tls/current/msg00401.html Actually, my larger concern, as I raised in that message last year, is why the "bar of WG support" appears to exclude the substantial base of implementations, especially free/OSS ones, that have already developed around the TLS/SRP spec. I would think that the existence of implementations, in several languages no less, and the support of the associated implementors who have invested time/energy in solving not just the technical problems but political/legal/IPR ones if anything should carry more weight. > > -Ekr > 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 Dec 21 22:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxb3H-0001OL-FK; Thu, 21 Dec 2006 22:26:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxb3F-0001OG-9n for tls@ietf.org; Thu, 21 Dec 2006 22:26:29 -0500 Received: from sd-green-bigip-62.dreamhost.com ([208.97.132.62] helo=swarthymail-a4.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxb3E-0001Go-07 for tls@ietf.org; Thu, 21 Dec 2006 22:26:29 -0500 Received: from [192.168.1.114] (c-67-188-81-45.hsd1.ca.comcast.net [67.188.81.45]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 2D535129A87; Thu, 21 Dec 2006 19:26:27 -0800 (PST) In-Reply-To: References: <279DDDAFA85EC74C9300A0598E704056011D1F79@hdsmsx412.amr.corp.intel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Casey Marshall Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Thu, 21 Dec 2006 19:26:19 -0800 To: Tom Wu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 Dec 21, 2006, at 6:55 PM, Tom Wu wrote: > On Thu, 21 Dec 2006, Blumenthal, Uri wrote: > >> >> I for one would like to (a) see the URLs pointing to free >> reference implementation(s), and (b) hear a clarification wrt. IPR >> status of the method defined in this draft. > > (a) I am aware of the following free implementations of TLS/SRP: > > - http://www.edelweb.fr/EdelKey/ (OpenSSL, C-based) > - http://www.trevp.net/tlslite/ (Python-based) > - http://www.gnu.org/software/gnutls/ (C-based, GPL) > - http://www.nongnu.org/jessie/ (Java-based) > Jessie was written using an early draft of the spec, and (at least) the cipher suite IDs have changed in the interim (to, I believe, some values that are yet-to-be-defined for real, unless "TBD" has some value, or other implementations are using placeholder values). We have not maintained the SRP support in this code, which is now a part of GNU Classpath Cheers. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 22 00:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxcit-0006q9-KA; Fri, 22 Dec 2006 00:13:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxcis-0006q3-FB for tls@ietf.org; Fri, 22 Dec 2006 00:13:34 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxcir-0001yF-3S for tls@ietf.org; Fri, 22 Dec 2006 00:13:34 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1170B1E8C28; Thu, 21 Dec 2006 21:13:30 -0800 (PST) To: Tom Wu Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt References: <20061221195347.787F05C01E@laser.networkresonance.com> From: Eric Rescorla Date: Thu, 21 Dec 2006 21:13:30 -0800 In-Reply-To: (Tom Wu's message of "Thu, 21 Dec 2006 19:08:29 -0800 (PST)") Message-ID: <8664c4a4xx.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Tom Wu writes: > On Thu, 21 Dec 2006, Eric Rescorla wrote: >> In a thread starting November 28, 2005, I asked for expressions of >> support. I received three responses in favor of moving it forward >> as PS, from you, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi >> and I judged that this did not meet the bar of WG support for >> a decision to move it forward at PS. > > Did my vote in favor of Proposed status not count? > > http://www1.ietf.org/mail-archive/web/tls/current/msg00401.html My apologies, I miscounted when I wrote my response to Peter. Pasi and I did, however, account for your opinion when we made our decision about the document. > Actually, my larger concern, as I raised in that message last year, > is why the "bar of WG support" appears to exclude the substantial > base of implementations, especially free/OSS ones, that have already > developed around the TLS/SRP spec. I would think that the existence > of implementations, in several languages no less, and the support of > the associated implementors who have invested time/energy in solving > not just the technical problems but political/legal/IPR ones if > anything should carry more weight. Implementations are one indicator of support but they're not the only one, and when Pasi and I asked the question directly of the WG, the support was fairly weak, as I indicated in my previous message. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 22 00:54:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxdMS-00019r-N1; Fri, 22 Dec 2006 00:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxdMR-00019j-Q9 for tls@ietf.org; Fri, 22 Dec 2006 00:54:27 -0500 Received: from bay0-omc2-s1.bay0.hotmail.com ([65.54.246.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxdMP-0001rX-7b for tls@ietf.org; Fri, 22 Dec 2006 00:54:27 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc2-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 21:54:24 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Peter Sylvester Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Thu, 21 Dec 2006 21:54:24 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2006 05:54:24.0685 (UTC) FILETIME=[A24BEDD0:01C7258D] X-Spam-Score: 2.4 (++) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2006975455==" Errors-To: tls-bounces@lists.ietf.org --===============2006975455== Content-Type: multipart/alternative; boundary="_3a49b9ba-bb3b-47de-9be5-54c9382a1ad8_" --_3a49b9ba-bb3b-47de-9be5-54c9382a1ad8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't like the initial part of the binding onto the SSL protocol, if anyo= ne cares! I like the way it uses serverkeyexchange; its cute,=20 clever, and uses public key ideas in the core handshake in novel ways. I ca= n see why folks with a particular mindset about public key and certs will politik against it, though. It doesn't fit = with classical doctrine, or the way some agencies are working (legitimately!) to steer public critical infrastructur= e towards a certain grade of PKI. =20 (a) It's initial phase is architecturally as suspect as the GSSAPI idea. (T= he GSS handshake tokens' state could yet pan out=20 as improving current session resumption practices, tho. ) GSS API at least = doesn't have anything security critical tho. =20 (b) The SRP session resumption restrictions on the USING of an extension va= lue make it really suspect, architecturally =20 Recall that User auth for apps, inband to the SSL Handshake, was withdrawn = as the record in SSLv2 spec shows. Client=20 Certs are there, but they really are there for making trusted T-connects, n= ot user auth. VeriSign issues a million client certs as=20 an experiment. it was not a great success, repurposing client auth as a for= m of user auth, in the https arena. In the 802.1x arena, there is possibly a different story and maybe a= different outcome, tho, when we are no longer dealing with "hosts" and logins, but performing device auth t= o join a nic into an adjacency net, and where RADIUS does the rest (e.g. securid-enhanced Radius for wireless-nic b= ridging to ISPs over DSL etc,=20 without or without TTLS) =20 Ive never fathomed why folks dont just invent their own client protocols of= the Record Protocol for user auth purposes, give it a record_type, and mandate the dispatcher performs t= he custom SSL handshake extension=20 directly upon session state change after the finish protocol, discarding an= y APDU till it completes, and sets its own secure state, a new modified Connection secure sub-state peculiar to th= e enhancement.. This is what=20 the record_type extension capability was for! If I were doing GSSAPI 1-toke= n userauth (a signed blob, of the current write mac?), I'd do it there, also. =20 In terms of politics, I bet the GSSAPI gets fast tracked once it gets criti= cal mass, whereas SRP will be held up=20 procedurally for ever. =20 > To: Peter.Sylvester@edelweb.fr> Subject: Re: [TLS] Re: I-D ACTION:draft-i= etf-tls-srp-13.txt > Date: Thu, 21 Dec 2006 11:50:35 -0800> From: ekr@netwo= rkresonance.com> CC: tls@ietf.org > In a thread starting November 28, 2005, I asked for expressions of> suppo= rt. I received three responses in favor of moving it forward> as PS, from y= ou, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi> and I judged that thi= s did not meet the bar of WG support for> a decision to move it forward at = PS.> > -Ekr> > _______________________________________________> TLS mailing= list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Try amazing new 3D maps http://maps.live.com/?wip=3D51= --_3a49b9ba-bb3b-47de-9be5-54c9382a1ad8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't like the initial part of the binding onto the SSL protocol, i= f anyone cares! I like the way it uses serverkeyexchange; its cute,
clever, and uses public key ideas in the core handshake in novel ways. I ca= n see why folks with a particular mindset
about public key and certs will politik against it, though. It doesn't fit = with classical doctrine, or the way some
agencies are working (legitimately!) to steer public critical infrastructur= e towards a certain grade of PKI.
 
(a) It's initial phase is architecturally as suspect as the GSSAPI ide= a. (The GSS handshake tokens' state could yet pan out
as improving current session resumption practices, tho. ) GSS API at l= east doesn't have anything security critical tho.
 
(b) The SRP session resumption restrictions on the USING of an extensi= on value make it really suspect, architecturally
 
Recall that User auth for apps, inband to the SSL Handshake, was withdrawn = as the record in SSLv2 spec shows. Client
Certs are there, but they really are there for making trusted T-connects, n= ot user auth. VeriSign issues a million client certs as
an experiment. it was not a great success, repurposing client auth as a for= m of user auth, in the https
arena. In the 802.1x arena, there is possibly a different story and maybe a= different outcome, tho, when we
are no longer dealing with "hosts" and logins, but performing device auth t= o join a nic into an adjacency net, and
where RADIUS does the rest (e.g. securid-enhanced Radius for wireless-= nic bridging to ISPs over DSL etc,
without or without TTLS)
 
Ive never fathomed why folks dont just invent their own client protocols of= the Record Protocol for user
auth purposes, give it a record_type, and mandate the dispatcher perfo= rms the custom SSL handshake extension
directly upon session state change after the finish protocol, discarding an= y APDU till it completes, and sets its
own secure state, a new modified Connection secure sub-state peculiar to th= e enhancement.. This is what
the record_type extension capability was for! If I were doing GSSAPI 1-toke= n userauth (a signed blob, of the current
write mac?), I'd do it there, also.
 
In terms of politics, I bet the GSSAPI gets fast tracked once it gets criti= cal mass, whereas SRP will be held up
procedurally for ever.
 

> To: Peter.Sylvester@edelweb.fr
> Subject: Re: [TLS] Re: I-D ACTI= ON:draft-ietf-tls-srp-13.txt
> Date: Thu, 21 Dec 2006 11:50:35 -0800=
> From: ekr@networkresonance.com
> CC: tls@ietf.org

> In a thread starting November 28, 2005, I asked for expressions of
= > support. I received three responses in favor of moving it forward
&= gt; as PS, from you, Trevor Perrin, and Nikos Mavrogiannopoulus. Pasi
&g= t; and I judged that this did not meet the bar of WG support for
> a = decision to move it forward at PS.
>
> -Ekr
>
> _= ______________________________________________
> TLS mailing list
= > TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls<= BR>

Try amazing new 3D maps Check it out! = --_3a49b9ba-bb3b-47de-9be5-54c9382a1ad8_-- --===============2006975455== 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 --===============2006975455==-- From tls-bounces@lists.ietf.org Fri Dec 22 02:01:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxeO2-0002I7-DR; Fri, 22 Dec 2006 02:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxeO1-0002H5-6b for tls@ietf.org; Fri, 22 Dec 2006 02:00:09 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxeNz-0003ZU-Q9 for tls@ietf.org; Fri, 22 Dec 2006 02:00:09 -0500 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 1GxeNy-0005AK-1a; Thu, 21 Dec 2006 23:00:07 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1GxeNx-00029t-Md; Thu, 21 Dec 2006 23:00:05 -0800 Date: Thu, 21 Dec 2006 23:00:05 -0800 (PST) From: Tom Wu To: Eric Rescorla Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: <8664c4a4xx.fsf@raman.networkresonance.com> Message-ID: References: <20061221195347.787F05C01E@laser.networkresonance.com> <8664c4a4xx.fsf@raman.networkresonance.com> 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: ae35470b07fbe4e2dbb6b33d1de23969 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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, 21 Dec 2006, Eric Rescorla wrote: > Tom Wu writes: >> >> Did my vote in favor of Proposed status not count? >> >> http://www1.ietf.org/mail-archive/web/tls/current/msg00401.html > > My apologies, I miscounted when I wrote my response to Peter. > Pasi and I did, however, account for your opinion when we made > our decision about the document. > > >> Actually, my larger concern, as I raised in that message last year, >> is why the "bar of WG support" appears to exclude the substantial >> base of implementations, especially free/OSS ones, that have already >> developed around the TLS/SRP spec. I would think that the existence >> of implementations, in several languages no less, and the support of >> the associated implementors who have invested time/energy in solving >> not just the technical problems but political/legal/IPR ones if >> anything should carry more weight. > > Implementations are one indicator of support but they're not > the only one, and when Pasi and I asked the question directly > of the WG, the support was fairly weak, as I indicated in my > previous message. Ok, but reading between the lines, it seems as though strong implementation support is still being disregarded. You could just as easily have said "Although there wasn't a strong response on the WG mailing list, SRP enjoys strong implementation support" as a rationale for Proposed Standard. The way you phrased things implies that WG vote is the only thing that matters, or at the very least overrides other factors. Out of curiosity, what kind of WG support did the Camellia ciphersuites (RFC 4132) enjoy when it came up for vote? > > -Ekr > 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 Dec 22 02:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxemi-0006JI-EH; Fri, 22 Dec 2006 02:25:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxemh-0006JC-V3 for tls@ietf.org; Fri, 22 Dec 2006 02:25:39 -0500 Received: from bay0-omc2-s25.bay0.hotmail.com ([65.54.246.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxemg-0006u6-Iy for tls@ietf.org; Fri, 22 Dec 2006 02:25:39 -0500 Received: from BAY103-W7 ([65.54.174.107]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 21 Dec 2006 23:25:38 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Date: Thu, 21 Dec 2006 23:25:38 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 22 Dec 2006 07:25:38.0178 (UTC) FILETIME=[60C0AE20:01C7259A] X-Spam-Score: 2.6 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [TLS] ldaps closure alert http://www.ietf.org/rfc/rfc2830.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1160176501==" Errors-To: tls-bounces@lists.ietf.org --===============1160176501== Content-Type: multipart/alternative; boundary="_6e32c165-0c59-4b7b-aa17-d066b0d42c68_" --_6e32c165-0c59-4b7b-aa17-d066b0d42c68_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/rfc/rfc2830.txt discloses that =20 After the initiator of a close has sent a closure alert, it MUST disca= rd any TLS messages until it has received an alert from the other party. = It will cease to send TLS Record Protocol PDUs, and following the receip= t of the alert, MAY send and receive LDAP PDUs. The other party, if it re= ceives a closure alert, MUST immediately transmit a TLS closure alert. I= t will subsequently cease to send TLS Record Protocol PDUs, and MAY send = and receive LDAP PDUs. An initiating party issues a closure_alert, and starts waiting for ANY aler= t in response (from the recipient). Thereupon, it MAY starting sending cleart= ext=20 PDUs directly over the underlying TLS transport. =20 A responding party suffering delays on its TLS input qbuf (on a ciphersuite= with null confidentiality in particular) could be sending who knows what warning aler= ts (std=20 and custom), that will arrive after the initiating party sent its closure_a= lert.=20 =20 After the first one arrives, it is no longer specified to discard TLS messa= ges, note. Presumably the TLS protocol engine should now process them.=20 =20 >From what I read, the DAP engine is now in a state where it can process an= y dap=20 pdu responses, indicated to it.=20 =20 =20 _________________________________________________________________ Type your favorite song.=A0 Get a customized station.=A0 Try MSN Radio powe= red by Pandora. http://radio.msn.com= --_6e32c165-0c59-4b7b-aa17-d066b0d42c68_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/r= fc/rfc2830.txt discloses that
 
   After the initiator of a close has sent a closure alert, it MU= ST
   discard any TLS messages until it has received an alert = from the
   other party.  It will cease to send TLS Recor= d Protocol PDUs, and
   following the receipt of the alert, MA= Y send and receive LDAP PDUs.

   The other party, if it re= ceives a closure alert, MUST immediately
   transmit a TLS clo= sure alert.  It will subsequently cease to send TLS
   Re= cord Protocol PDUs, and MAY send and receive LDAP PDUs.

An initiating party issues a closure_alert, and starts waiting for ANY aler= t
in response (from the recipient). Thereupon, it MAY starting sending cleart= ext
PDUs directly over the underlying TLS transport.
 
A responding party suffering delays on its TLS input qbuf (on a ciphersuite= with null
confidentiality in particular) could be sending who knows what warning= alerts (std
and custom), that will arrive after the initiating party sent its clos= ure_alert.
 
After the first one arrives, it is no longer specified to discard TLS messa= ges, note. Presumably
the TLS protocol engine should now process them.
 
>From what I read,  the DAP engine is now in a state where it can proce= ss any dap
pdu responses, indicated to it.
 
 

Get free, personalized online radio with MSN Radio po= wered by Pandora. Try it!<= /a> = --_6e32c165-0c59-4b7b-aa17-d066b0d42c68_-- --===============1160176501== 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 --===============1160176501==-- From tls-bounces@lists.ietf.org Fri Dec 22 09:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxl83-000133-FH; Fri, 22 Dec 2006 09:12:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxl81-00012q-G4 for tls@ietf.org; Fri, 22 Dec 2006 09:12:05 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxl80-0005w9-3y for tls@ietf.org; Fri, 22 Dec 2006 09:12:05 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 22 Dec 2006 06:12:03 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 22 Dec 2006 06:12:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,204,1165219200"; d="scan'208"; a="161566493:sNHT18465706" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Dec 2006 06:12:03 -0800 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: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Fri, 22 Dec 2006 09:11:57 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E7040560121DD3C@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt thread-index: AccliE2MXU0b8xWRS4+EIKfxMBHqJwARCXAA From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 22 Dec 2006 14:12:03.0163 (UTC) FILETIME=[27561AB0:01C725D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 would think that the existence >> of implementations, in several languages no less, and the support of >> the associated implementors who have invested time/energy in solving >> not just the technical problems but political/legal/IPR ones if >> anything should carry more weight. > > Implementations are one indicator of support but they're not > the only one......... Reading the Stanford legal disclosure=20 (http://otl.stanford.edu/pdf/97006.pdf) - while it was very=20 nice of them to release THEIR patent to the public - I saw a big disclaimer on page 2 section 4 Negation of Warranties, in=20 particular 4.1.=20 I've heard that other parties claim that their patents cover SRP=20 method as well. Stanford license agreement pretty much says "yeah=20 those claims may be true - and if so it's your problem". (Caveat:=20 I'm not a lawyer - the above is how I understand the written text.=20 Feel free to correct me and provide the right interpretation.)=20 I understand that since Stanford doesn't charge for the license,=20 one can't demand or expect much from them, but you must understand=20 those who find such a license less than reassuring. In short - I'd like to see some evidence that political/legal/IPR=20 problems indeed have been solved (which is harder than writing an implementation :-). Regards, Uri I speak for myself only _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 22 10:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxluQ-0002tI-1J; Fri, 22 Dec 2006 10:02:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxluO-0002tC-W1 for tls@lists.ietf.org; Fri, 22 Dec 2006 10:02:04 -0500 Received: from simmts12-srv.bellnexxia.net ([206.47.199.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxluM-0005Dq-LL for tls@lists.ietf.org; Fri, 22 Dec 2006 10:02:04 -0500 Received: from pbo8f8e10aowa ([65.94.160.8]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061222150201.DGZH29497.simmts12-srv.bellnexxia.net@pbo8f8e10aowa>; Fri, 22 Dec 2006 10:02:01 -0500 Message-ID: <002101c725da$5e6bcd90$08a05e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "Peter Williams" , "Eric Rescorla" References: <20061218155157.DD2A75C01E@laser.networkresonance.com> Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 anddraft-rescorla-tls-suiteb-00 Date: Fri, 22 Dec 2006 10:03:41 -0500 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: pasi.eronen@nokia.com, 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 Hi, speaking of the "the next layer protocol generally needs a fair amount of access to properties of the TLS session" How to get access to the client and server session caches? How to do it on the various SSL/TLS implementations on the win 32 or 64 platforms: Where do they implement the dll or COM object or ... that holds the client and server side session caches? Thanks in advance, Regards, Omirjan Batyrbaev, ----- Original Message ----- From: "Eric Rescorla" To: "Peter Williams" Cc: ; Sent: Monday, December 18, 2006 10:48 AM Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 anddraft-rescorla-tls-suiteb-00 > Peter, > > *please* figure out some way to put line breaks in your messages. > It makes them very hard to read. > > Peter Williams wrote: > > What the architecture change in the I-D seems to propose is that > > applications in unix host type environments may require > > API/socket-level access to more than the sessionid. > > That's always been true. Recall that TLS doesn't specify how > one checks certificates. That's done at higher layers (E.g., > RFC 2818). So, the next layer protocol generally needs a > fair amount of access to properties of the TLS session. > It's also generally common to provide access to the cipher > suite. > > > > I do note that the spec is targeting an HTTP extension, worries alot > > about the extension negotiation rules, and of course entails that the > > extension's user-data might be passing over OOB channels beyond the > > control of load balancers and their traditional engineering work in > > trying to tie keepalives, ssl sessions, and cryptobox sessions > > together. > > Why do you say "HTTP extension"? This is a pure TLS extension. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 22 14:31:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxq6a-0002fh-Mh; Fri, 22 Dec 2006 14:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxq6Z-0002fc-Oz for tls@ietf.org; Fri, 22 Dec 2006 14:30:55 -0500 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxq6Y-0000Wd-Fm for tls@ietf.org; Fri, 22 Dec 2006 14:30:55 -0500 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 1Gxq6X-0001Fd-D8; Fri, 22 Dec 2006 11:30:54 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1Gxq6U-0001An-P5; Fri, 22 Dec 2006 11:30:50 -0800 Date: Fri, 22 Dec 2006 11:30:50 -0800 (PST) From: Tom Wu To: Peter Williams Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: Message-ID: References: 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: 9dddbef7dbf47a29383c7a3c8e5dce6e X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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, 20 Dec 2006, Peter Williams wrote: > Ive never fathomed why folks dont just invent their own client protocols of the Record Protocol for user > auth purposes, give it a record_type, and mandate the dispatcher performs the custom SSL handshake extension > directly upon session state change after the finish protocol, discarding any APDU till it completes, and sets its > own secure state, a new modified Connection secure sub-state peculiar to the enhancement.. This is what > the record_type extension capability was for! If I were doing GSSAPI 1-token userauth (a signed blob, of the current > write mac?), I'd do it there, also. If I understand this correctly, the user authentication would take place after (and on top of) an underlying TLS session? In this case, what ciphersuite would that session use? If it's anonymous, it's still vulnerable to active attack, even if you do application-level or some other protocol inside a TLS session. If it's certificate-based, you still depend on a PKI of some sort. The security of the TLS/SRP scheme depends on the password authentication being intertwined with the key exchange. 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 Dec 22 17:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxsyq-0002X6-SS; Fri, 22 Dec 2006 17:35:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxsyp-0002VR-1i for tls@ietf.org; Fri, 22 Dec 2006 17:35:07 -0500 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxsyn-0006A9-OH for tls@ietf.org; Fri, 22 Dec 2006 17:35:07 -0500 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 1Gxsym-000326-Fx for tls@ietf.org; Fri, 22 Dec 2006 14:35:05 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1Gxsym-000725-8U for tls@ietf.org; Fri, 22 Dec 2006 14:35:04 -0800 Date: Fri, 22 Dec 2006 14:35:04 -0800 (PST) From: Tom Wu To: tls@ietf.org Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: <279DDDAFA85EC74C9300A0598E7040560121DD3C@hdsmsx412.amr.corp.intel.com> Message-ID: References: <279DDDAFA85EC74C9300A0598E7040560121DD3C@hdsmsx412.amr.corp.intel.com> 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: bd70d0bdda1312c8b25f7b39d1e2fb7f X-Spam-Score: 0.0 (/) 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 On Fri, 22 Dec 2006, Blumenthal, Uri wrote: > I've heard that other parties claim that their patents cover SRP > method as well. Stanford license agreement pretty much says "yeah > those claims may be true - and if so it's your problem". (Caveat: > I'm not a lawyer - the above is how I understand the written text. > Feel free to correct me and provide the right interpretation.) AFAIK it's standard boilerplate. > I understand that since Stanford doesn't charge for the license, > one can't demand or expect much from them, but you must understand > those who find such a license less than reassuring. > > In short - I'd like to see some evidence that political/legal/IPR > problems indeed have been solved (which is harder than writing an > implementation :-). Under the current circumstances, the growing base of running code for TLS/SRP and the rough consensus among its implementors is the best evidence one could reasonably expect. If SRP weren't truly free, it would be in the same boat as the other ZKP protocols and would not have attracted the interest level it has, especially with OSS projects. > Regards, > Uri > I speak for myself only 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 Sat Dec 23 14:43:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyCl6-0003XK-CY; Sat, 23 Dec 2006 14:42:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyCl4-0003XF-SR for tls@ietf.org; Sat, 23 Dec 2006 14:42:14 -0500 Received: from bay0-omc2-s38.bay0.hotmail.com ([65.54.246.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyCl1-0007J9-2v for tls@ietf.org; Sat, 23 Dec 2006 14:42:14 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc2-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 23 Dec 2006 11:42:10 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Sat, 23 Dec 2006 11:42:10 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2006 19:42:10.0614 (UTC) FILETIME=[6FE90560:01C726CA] X-Spam-Score: 2.4 (++) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 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: , Content-Type: multipart/mixed; boundary="===============2008656735==" Errors-To: tls-bounces@lists.ietf.org --===============2008656735== Content-Type: multipart/alternative; boundary="_84a3238c-20cf-48a3-aa64-1b318f3418fd_" --_84a3238c-20cf-48a3-aa64-1b318f3418fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Open: =20 The stated rationale against SRP is poor, in my opinion. I doesn't "politic= ally" convey that other unstated factors were=20 _not_ actually in play (hints of Powell's UN argument, here, now that this = is "a role model"). Me and Pasi thought this (one night=20 in the bar...), trying to appear rationalized by appealing to a bit of coun= ting, on a dubious mailing list call. It doesn't smell right; like no toilets and hotels for blacks in 1960s Mississ= ippi, to enforce limited social mobility and containment, by some oppressive group or other, working through indirec= t policy means. All manner of=20 indirect biases become possible, with this limited argument. Its too easy t= o be 100% wrong, and be in no=20 position to recover from the resulting mess. =20 If we consider the Intel/personal line, on the topic, however, we get to re= open now the core argument, on TLS=20 itself. Fairs fair! Eric and co need to seen to be very consistent; its a d= ifficult leadership job, especially so=20 when you are an IAB member! =20 If we are going to look at IP, TLS (with SRP in particular) is not on solid= grounds itself, given the nature of=20 the SSL patent license. The SSL patent make insufficiently general claims = covering user auth inventions,=20 anti-phishing inventions, etc. Others have, for an (NDA) fact. B4 the IETF = era, you might even see my name... on applications. Ive also done stuff subsequently, tho. not = while being IETF contributor on SSL. =20 http://www.imc.org/ietf-mxcomp/mail-archive/msg04033.htmlPhil was not corre= ct that SSL Patent (validly) covers transport layer security (lots of SSL-l= ike layer security protocols existed before it (TNI-based), for layer 4 ports.) I hal= f remember working for Motorola GSTG, with the patent-crazy engineers who worked that area in = the late 80s. The claims=20 only cover a particular system architecture of deploying a session layer pr= otocol, where session and=20 connection states are managed independently, with cached session management= in the vlantagged-trunking=20 protocol (master switch), connection handling in the (slave) switch(es) han= dling a given vlan (to use some fun,=20 modern embodiments). Lots of other SSL-related patents application can (and= have) been filed that=20 are unrelated to the architecture. Its easy to step on them, once they emer= ge or their continuations emerge: SSL combined with fault-tolerant re-homing of gateways, re-election= of master trunking nodes....,=20 re-handshaking for trunk tunneling of labeled record_types.... =20 If one notes, I've been going ON and ON ad nauseam about the historical arc= hitecture, and the development=20 thereof. I'm trying to keep IETF on solid footings, re the SSL patent, to e= xtract the IP protection value out of=20 the parts of the (poorly written) license grant that are actually sustainab= le, and useful. We can help protect=20 IETF and its open mission, if we just stay within certain tramlines. Using = the SSL patent like this, is like how=20 we used the RSA patent, to safeguard the core of the public interest from c= ertain power players, whose mission=20 did not well align with that of the open networking community reaching out = to grandma. Yes, that policy generates=20 much short-term enmity, makes a few people millions, but if we look at RSA.= .. its now doing what the beauty=20 of the math discovery allows for. It didnt get subverted, with capitalism/g= reed acting as political countermeasure to the almighty power others had. =20 We want the same for SSL, dumping horrors like IESG-endorsed! RSA_EXPORT, f= or example. Hobbling the final protocol is one thing, hobbling the key management is another! =20 > Date: Fri, 22 Dec 2006 14:35:04 -0800> From: tjw@CS.Stanford.EDU> To: tls= @ietf.org> Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt> CC:= > > On Fri, 22 Dec 2006, Blumenthal, Uri wrote:> > > I've heard that other= parties claim that their patents cover SRP> > method as well. Stanford lic= ense agreement pretty much says "yeah> > those claims may be true - and if = so it's your problem". (Caveat:> > I'm not a lawyer - the above is how I un= derstand the written text.> > Feel free to correct me and provide the right= interpretation.)> > AFAIK it's standard boilerplate.> > > I understand tha= t since Stanford doesn't charge for the license,> > one can't demand or exp= ect much from them, but you must understand> > those who find such a licens= e less than reassuring.> >> > In short - I'd like to see some evidence that= political/legal/IPR> > problems indeed have been solved (which is harder t= han writing an> > implementation :-).> > Under the current circumstances, t= he growing base of running code> for TLS/SRP and the rough consensus among = its implementors is> the best evidence one could reasonably expect. If SRP = weren't> truly free, it would be in the same boat as the other ZKP protocol= s> and would not have attracted the interest level it has, especially> with= OSS projects.> > > Regards,> > Uri> > I speak for myself only= > > Tom> -- > Tom Wu> http://www-cs-students.stanford.edu/~tjw/> > ________= _______________________________________> TLS mailing list> TLS@lists.ietf.o= rg> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Try amazing new 3D maps http://maps.live.com/?wip=3D51= --_84a3238c-20cf-48a3-aa64-1b318f3418fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Open:
 
The stated rationale against SRP is poor, in my opinion. I doesn't "politic= ally" convey that other unstated factors were
_not_ actually in play (hints of Powell's UN argument, here, now that this = is "a role model"). Me and Pasi thought this (one night
in the bar...), trying to appear rationalized by appealing to a bit of coun= ting, on a dubious mailing list call.  It
doesn't smell right; like no toilets and hotels for blacks in 1960s Mississ= ippi, to enforce limited social mobility
and containment, by some oppressive group or other, working through in= direct policy means. All manner of
indirect biases become possible, with this limited argument. Its too easy t= o be 100% wrong, and be in no
position to recover from the resulting mess.
 
If we consider the Intel/personal line, on the topic, however, we get = to reopen now the core argument, on TLS
itself. Fairs fair! Eric and co need to seen to be very consistent; its a d= ifficult leadership job, especially so
when you are an IAB member!
 
If we are going to look at IP, TLS (with SRP in particular) is not on solid= grounds itself, given the nature of
the SSL patent license.  The SSL patent make insufficiently general cl= aims covering user auth inventions,
anti-phishing inventions, etc. Others have, for an (NDA) fact. B4 the IETF = era, you might even
see my name... on applications. Ive also done stuff subsequently, tho. not = while being IETF contributor
on SSL.
 
http:= //www.imc.org/ietf-mxcomp/mail-archive/msg04033.html

Phil was no= t correct that SSL Patent (validly) covers transport layer security (lots o= f SSL-like layer
security protocols existed before it (TNI-based), for layer 4 ports.) I hal= f remember working
for Motorola GSTG, with the patent-crazy engineers who worked that area in = the late 80s. The claims
only cover a particular system architecture of deploying a session layer pr= otocol, where session and
connection states are managed independently, with cached session management= in the vlantagged-trunking
protocol (master switch), connection handling in the (slave) switch(es) han= dling a given vlan (to use some fun,
modern embodiments). Lots of other SSL-related patents application can (and= have) been filed that
are unrelated to the architecture. Its easy to step on them, once they emer= ge or their continuations
emerge: SSL combined with fault-tolerant re-homing of gateways, re-election= of master trunking nodes....,
re-handshaking for trunk tunneling of labeled record_types....
 
If one notes, I've been going ON and ON ad nauseam about the historical arc= hitecture, and the development
thereof. I'm trying to keep IETF on solid footings, re the SSL patent, to e= xtract the IP protection value out of
the parts of the (poorly written) license grant that are actually sustainab= le, and useful. We can help protect
IETF and its open mission, if we just stay within certain tramlines. Using = the SSL patent like this, is like how
we used the RSA patent, to safeguard the core of the public interest from c= ertain power players, whose mission
did not well align with that of the open networking community reaching out = to grandma. Yes, that policy generates
much short-term enmity, makes a few people millions, but if we look at RSA.= .. its now doing what the beauty
of the math discovery allows for. It didnt get subverted, with capital= ism/greed acting as political countermeasure
to the almighty power others had.
 
We want the same for SSL, dumping horrors like IESG-endorsed! RSA_EXPORT, for example.  Hobbling the
final protocol is one thing, hobbling the key management is another!


 

> Date: Fri, 22 Dec 2006 14:35:04 -0800
> From: tjw@CS.Stanford.ED= U
> To: tls@ietf.org
> Subject: RE: [TLS] Re: I-D ACTION:draft-= ietf-tls-srp-13.txt
> CC:
>
> On Fri, 22 Dec 2006, Blum= enthal, Uri wrote:
>
> > I've heard that other parties clai= m that their patents cover SRP
> > method as well. Stanford licens= e agreement pretty much says "yeah
> > those claims may be true - = and if so it's your problem". (Caveat:
> > I'm not a lawyer - the = above is how I understand the written text.
> > Feel free to corre= ct me and provide the right interpretation.)
>
> AFAIK it's st= andard boilerplate.
>
> > I understand that since Stanford = doesn't charge for the license,
> > one can't demand or expect muc= h from them, but you must understand
> > those who find such a lic= ense less than reassuring.
> >
> > In short - I'd like to= see some evidence that political/legal/IPR
> > problems indeed ha= ve been solved (which is harder than writing an
> > implementation= :-).
>
> Under the current circumstances, the growing base of= running code
> for TLS/SRP and the rough consensus among its impleme= ntors is
> the best evidence one could reasonably expect. If SRP were= n't
> truly free, it would be in the same boat as the other ZKP proto= cols
> and would not have attracted the interest level it has, especi= ally
> with OSS projects.
>
> > Regards,
> >= Uri
> > <Disclaimer> I speak for myself only
>
&g= t; Tom
> --
> Tom Wu
> http://www-cs-students.stanford.e= du/~tjw/
>
> _______________________________________________> TLS mailing list
> TLS@lists.ietf.org
> https://www1.iet= f.org/mailman/listinfo/tls


Try amazing new 3D maps Check it out! = --_84a3238c-20cf-48a3-aa64-1b318f3418fd_-- --===============2008656735== 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 --===============2008656735==-- From tls-bounces@lists.ietf.org Sat Dec 23 14:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyCx4-0006WS-6z; Sat, 23 Dec 2006 14:54:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyCx2-0006Us-5q for tls@ietf.org; Sat, 23 Dec 2006 14:54:36 -0500 Received: from bay0-omc2-s8.bay0.hotmail.com ([65.54.246.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyCx0-0001P5-LP for tls@ietf.org; Sat, 23 Dec 2006 14:54:36 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc2-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 23 Dec 2006 11:54:34 -0800 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Any advice regarding frequency of generating newDHparameters? Date: Sat, 23 Dec 2006 11:54:33 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2006 19:54:34.0189 (UTC) FILETIME=[2B1D8FD0:01C726CC] X-Spam-Score: 2.2 (++) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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: , Content-Type: multipart/mixed; boundary="===============0924966265==" Errors-To: tls-bounces@lists.ietf.org --===============0924966265== Content-Type: multipart/alternative; boundary="_c0eac936-17ef-492f-af6a-b4e8368e5bbb_" --_c0eac936-17ef-492f-af6a-b4e8368e5bbb_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I've been looking at the ephemeral mode of Fortezza_dms (in SSLv3), followi= ng up the thread on DH/RSA ephemeral. First lets remember, the dms ciphersu= ites use mechanisms that work differently to DH/RSA features (and the vario= us RSA-using (std and locally-defined) ciphersuites that construct X.800 me= chanisms out of these X.800 features).=20 The mechanism of "key agreement" is avoided in the DMS variant of KEA, bei= ng replaced by "TEK agreement" - a wrapping mechanism. The clientside proce= ss computes the TEK, wraps SSL session (encryption mechanism) keys, where t= he server side KEA math exists only to unwrap them given access to the kea = public key in the client cert. Pre-master secrets are then swapped around u= nder the TEK wrapping, to keep the rest of the SSL state machine happy and = to generate the MAC session (integrity mechanism) keys/IVs as normal. The interesting part is that we can ephemerally generate the client's KEA p= ublic key, generated client side. In servekeyexchange, r&s are unique to ea= ch session handshake already, controlling TEK generation, without regard to= the client/server nonces (I assume). If would now be interesting to go further now, and build in further use of = several unique UKM rA values into the handshake, and generate a series of C= EKs/IVs for encrypting different custom record_types within the record-laye= r, each one extending connection state in some way. Perhaps the derived val= ue(s) could be just different record_type_IV(s), not CEKs, extending sessio= n state by 2*n IVs, one set per custom record_type, for client.write.record= _type_idX, server.write.record_type_idX.=20 If we generalize this now for schemes other than wrapping , and DMS-styled = KEA, we allow for designers to customize/extend the final protocol, per-con= nection. This can allow folks to add in their user auth schemes on "their r= ecord layer client protocols" , even those that influence the enc and mac k= eys/ivs per connection. One can argue all day that those scheme are poor (t= oo many extra round trips, etc), but=85 that=92s for the market to decide, = not IETF. Why anyone cares these days about an extra round trip, I don't kn= ow. _________________________________________________________________ Get the Live.com Holiday Page for recipes, gift-giving ideas, and more. www.live.com/?addtemplate=3Dholiday= --_c0eac936-17ef-492f-af6a-b4e8368e5bbb_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

= I've been looking at the ephemeral mode of Fortezza_dms (in SSLv3), following up the thread on DH/RSA ephemeral. First lets rem= ember, the dms ciphersuites use mechanisms that work differently to DH/RSA = features (and the various RSA-using (std and locally-defined) ciphersuites that construct X.800 mechanis= ms out of these X.800 features).

The me= chanism of "key agreement" is avoided in the DMS variant of  KEA, being replaced by "TEK agreement" - a = wrapping mechanism. The clientside process computes the TEK, wraps SSL sess= ion (encryption mechanism) keys, where the server side KEA math exists only= to unwrap them given access to the kea public key in the client cert. Pre-= master secrets are then swapped around under the TEK wrapping, to keep the = rest of the SSL state machine happy and to generate the MAC session (integr= ity mechanism) keys/IVs as normal.

The in= teresting part is that we can ephemerally generate the client's KEA public = key, generated client side. In servekeyexchange, r&s are unique to each= session handshake already, controlling TEK generation, without regard to t= he client/server nonces (I assume).

If wou= ld now be interesting to go further now, and build in further use of severa= l unique UKM rA values into the handshake, and generate a series of CEKs/IV= s for encrypting different custom record_types within the record-layer, eac= h one extending connection state in some way. Perhaps the derived value(s) = could be just different record_type_IV(s), not CEKs, extending session stat= e by 2*n IVs, one set per custom record_type, for client.write.record_type_= idX, server.write.record_type_idX.

If we = generalize this now for schemes other than wrapping , and DMS-styled KEA, w= e allow for designers to customize/extend the final protocol, per-connectio= n. This can allow folks to add in their user auth schemes on "their record = layer client protocols" , even those that influence the enc and mac keys/iv= s per connection. One can argue all day that those scheme are poor (too man= y extra round trips, etc), but=85 that=92s for the market to decide, not IE= TF. Why anyone cares these days about an extra round trip, I don't kno= w.


Get the Live.com Holiday Page fo= r recipes, gift-giving ideas, and more. Check it out! = --_c0eac936-17ef-492f-af6a-b4e8368e5bbb_-- --===============0924966265== 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 --===============0924966265==-- From tls-bounces@lists.ietf.org Sat Dec 23 21:29:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyJ5n-00069Z-LT; Sat, 23 Dec 2006 21:28:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyJ5m-00069U-0s for tls@ietf.org; Sat, 23 Dec 2006 21:28:02 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyJ5j-0004I4-L6 for tls@ietf.org; Sat, 23 Dec 2006 21:28:01 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 23 Dec 2006 18:27:58 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 23 Dec 2006 18:27:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,208,1165219200"; d="scan'208"; a="178180013:sNHT18518675" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Dec 2006 18:27:58 -0800 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: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Sat, 23 Dec 2006 21:28:01 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E7040560121E00B@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt thread-index: AccmGdN3mWlonqr6Tfu86FmnNcQcSQA6CLgg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 24 Dec 2006 02:27:58.0797 (UTC) FILETIME=[208EE7D0:01C72703] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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've heard that other parties claim that their patents cover SRP >> method as well. Stanford license agreement pretty much says "yeah >> those claims may be true - and if so it's your problem". (Caveat: >> I'm not a lawyer - the above is how I understand the written text. >> Feel free to correct me and provide the right interpretation.) > > AFAIK it's standard boilerplate. This doesn't say anything about the correctness (or the lack)of my=20 interpretation. I care not whether it is a standard boilerplate or=20 not - rather whether I interpreted it correctly. >> In short - I'd like to see some evidence that political/legal/IPR >> problems indeed have been solved (which is harder than writing an >> implementation :-). > > Under the current circumstances, the growing base of running code > for TLS/SRP and the rough consensus among its implementors is > the best evidence one could reasonably expect.=20 Speaking of political/legal/IPR issues - freeware is not a good=20 enough evidence for me, sorry. Recall RSA and PGP (wide spread=20 of PGP wasn't a proof that RSA technology was free). > If SRP weren't truly free, it would be in the same boat as > the other ZKP protocols=20 I agree that SRP has better chances (and its authors & patent holders=20 did give it to Public Domain, which is definitely nice) - but I=20 personally am afraid that its legal chances are not good enough.=20 So far I haven't seen evidence to the contrary.=20 I'd be happy to observe some!=20 Freeware available for download doesn't quite cut it (it proves that=20 the technology works, and that people like it enoiugh to invest their=20 time and efforts into it - but not its legal standing). > ...........and would not have attracted the > interest level it has, especially with OSS projects. To disprove this point - can you think back a decade and say "PGP"? :-) Regards, Uri I speak for myself only _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 25 18:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gyyt3-0002Lj-Rm; Mon, 25 Dec 2006 18:05:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gyyt1-0002L0-Vh for tls@ietf.org; Mon, 25 Dec 2006 18:05:39 -0500 Received: from bay0-omc1-s5.bay0.hotmail.com ([65.54.246.77]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gyysz-0004zr-8o for tls@ietf.org; Mon, 25 Dec 2006 18:05:39 -0500 Received: from hotmail.com ([65.54.174.88]) by bay0-omc1-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 25 Dec 2006 15:05:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Dec 2006 15:05:36 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV16.phx.gbl with DAV; Mon, 25 Dec 2006 23:05:34 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Bodo Moeller" , "Martin Rex" References: <86vek7pph4.fsf@raman.networkresonance.com><200612192115.WAA22812@uw1048.wdf.sap.corp> <20061220123640.GB21201@tau.invalid> Subject: Re: [TLS] Comments on TLS identity protection Date: Tue, 26 Dec 2006 10:14:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 25 Dec 2006 23:05:36.0759 (UTC) FILETIME=[302A7070:01C72879] X-Spam-Score: 2.5 (++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Normally, client auth is not allowed on a PKI-class ciphersuite, if the server has not performed server auth. (In a mix of PKIand non-pki ciphersuites -during a change-ciher-spec between the two - things are admittedly more ambiguous.) On a PKI-class limited renegotiation case (or a session resumption case), server auth is implied, of course - assuming both enc and mac ciphers mechanism are not NULL. For SSL3 using the RSA ciphersuites, one can ask for client auth on handshake#2, without having provided server cert chain on that second 'shake; server auth being established in the TLS resumed session (and renewed Connection) state. (I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or either of those stds with their "RFC updates" demands) being entirely different beasts to SSL3.) What https requires - and then what SLS3/TLSx.y+upd. requires - are of course different things. By virtue of its definition, https or other "SSL application" gets to set what the usage profile and the cert requirements are for an SSL/TLS layer 4.51 port. "Usage profile" includes: constraints on cert contents, cert chains rules,root certs, TLS transport handling, handling of cleartext and SSLtext data upon TLS upgrade/downgrade events (LDAP, HTTP1.1). By analogy, the implementor of https gets to set rules like: (1) client cert always requires a new handshake, even on the same TLS Transport connection (2) new server auth via certs is also required, on that second round ----- Original Message ----- From: "Bodo Moeller" To: "Martin Rex" Cc: Sent: Wednesday, December 20, 2006 4:36 AM Subject: Re: [TLS] Comments on TLS identity protection > On Tue, Dec 19, 2006 at 10:15:01PM +0100, Martin Rex wrote: > >>> However, as you say in most cases the request for client auth >>> is contingent upon seeing the request and so a rehandshake is >>> required here in any case. A one-pass protocol wouldn't work >>> here. > >> I had the same thought but completely failed to point this out. >> >> In the not uncommon case with IIS renegotiating after having >> evaluated the HTTP(S)-request, [...] > > This, by the way, applies not only to IIS servers. The Apache HTTP > server with mod_ssl can also be configured to request client > certificates only for specific requests, which of course is achieved > through a renegotiation. This approach is reasonable not only for > HTTP applications: An SMTP server supporting TLS might perform > certificate-based client authentication only when used as a mail > relay, and finish without attempting client authentication if > a connection only involves local mail delivery. > > Bodo > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 25 18:25:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyzC8-0000bt-1b; Mon, 25 Dec 2006 18:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GyzC6-0000bP-At for tls@ietf.org; Mon, 25 Dec 2006 18:25:22 -0500 Received: from bay0-omc1-s28.bay0.hotmail.com ([65.54.246.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GyzC4-0002VK-Ls for tls@ietf.org; Mon, 25 Dec 2006 18:25:22 -0500 Received: from hotmail.com ([65.54.174.80]) by bay0-omc1-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 25 Dec 2006 15:25:20 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Dec 2006 15:25:20 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV8.phx.gbl with DAV; Mon, 25 Dec 2006 23:25:17 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: , References: <200612192307.AAA25601@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection Date: Tue, 26 Dec 2006 10:34:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 25 Dec 2006 23:25:20.0200 (UTC) FILETIME=[F18D3480:01C7287B] X-Spam-Score: 2.5 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 > When the server-requested renegotiation is application triggered, > as in the Microsoft IIS case, then the server better caches the > result along with the SSL session. > > Microsoft IIS has a silly (performance-wasting) bug, where a client that > does either not have a client cert or does not show one (and requiring > the application to perform application level client authentication) > is continously forced through the renegotiation when the client > tries to resume the session from the session cache on a new connection. This is not a bug. It is an explicitly permitted state within the SSL v3 conformance/state. Upon request, a client MAY send a client cert. What happens if it doesn't, is server policy. The handshake protocol affects session state. Session resumption (a poorly named procedure) affects connection state, only. Where a client cert is used for user auth purpose(in e.g. https) we have a situation that is different to a client cert being used to merely authenticate an T-connect peer. Whether the user app intended a previous user auth to be applied to a new connection is not specified in the "designers" rendition of the https protocol. That is, its up to the implementation of https, by intent. The implementation of Netscape-https is very different to that of IE-https (and MSFT's wininet.dll's default https,for wininet consumers that are not IE) By definition http over SSL is https. Nothing more is stated. each https designer specifies their own "usage profile". Netscape-browsers have their concept for sharing hypermedia-state across TLSconnections, client side, and assured OS have theirs. Its that simple. There is no right or wrong, bug or not-bug. > > -Martin > > _______________________________________________ > 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 Dec 26 03:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gz7c6-0006p4-6G; Tue, 26 Dec 2006 03:24:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gz7c4-0006oT-5E for tls@ietf.org; Tue, 26 Dec 2006 03:24:44 -0500 Received: from cs-smtp-2.stanford.edu ([171.64.64.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gz7c2-0000Vi-Qw for tls@ietf.org; Tue, 26 Dec 2006 03:24:44 -0500 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 1Gz7c1-0003mz-7A; Tue, 26 Dec 2006 00:24:42 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.60) (envelope-from ) id 1Gz7bx-0001Hb-Nk; Tue, 26 Dec 2006 00:24:37 -0800 Date: Tue, 26 Dec 2006 00:24:37 -0800 (PST) From: Tom Wu To: "Blumenthal, Uri" Subject: RE: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: <279DDDAFA85EC74C9300A0598E7040560121E00B@hdsmsx412.amr.corp.intel.com> Message-ID: References: <279DDDAFA85EC74C9300A0598E7040560121E00B@hdsmsx412.amr.corp.intel.com> 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: dcedbbeaec314583a5a6d4e37e27e533 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Sat, 23 Dec 2006, Blumenthal, Uri wrote: >>> I've heard that other parties claim that their patents cover SRP >>> method as well. Stanford license agreement pretty much says "yeah >>> those claims may be true - and if so it's your problem". (Caveat: >>> I'm not a lawyer - the above is how I understand the written text. >>> Feel free to correct me and provide the right interpretation.) >> >> AFAIK it's standard boilerplate. > > This doesn't say anything about the correctness (or the lack)of my > interpretation. I care not whether it is a standard boilerplate or > not - rather whether I interpreted it correctly. Since it's boilerplate, Stanford isn't responding to any third party claims, as your interpretation implies, simply stating standard terms for a royalty-free license. > Speaking of political/legal/IPR issues - freeware is not a good > enough evidence for me, sorry. Recall RSA and PGP (wide spread > of PGP wasn't a proof that RSA technology was free). Yes it was, in the sense that it was possible to use PGP legally as long as you conformed to the RSA licensing terms. MIT PGP (in the US) was legal with RSAREF and the international version used PRZ's own library. SRP is likewise legal if you stay within its licensing terms, which do not place any restrictions on which specific implementation is used. > To disprove this point - can you think back a decade and say "PGP"? :-) Your example actually affirms my point nicely. > Regards, > Uri > I speak for myself only 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 Tue Dec 26 03:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gz893-0000rU-An; Tue, 26 Dec 2006 03:58:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gz891-0000qx-Qp for tls@ietf.org; Tue, 26 Dec 2006 03:58:47 -0500 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gz890-0001Hb-Jx for tls@ietf.org; Tue, 26 Dec 2006 03:58:47 -0500 Received: by wx-out-0506.google.com with SMTP id h27so3836841wxd for ; Tue, 26 Dec 2006 00:58:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tMhkpJtEfPEvd0b2o3qFX7Dncm70yr+y3BuaAN4082vL1eQDj9JfMyNKRvD1IGJ1QQqi/AhhNE+S2CyskElJLx6TRHHPdH9xw8dKqrUssQgQdnNUrtpC9FjL/ZO7LJRldE8AAz/e8JUayIq3QMNj7/ycxlbabegW7k9FVsxWZPM= Received: by 10.90.63.16 with SMTP id l16mr1969054aga.1167123526406; Tue, 26 Dec 2006 00:58:46 -0800 (PST) Received: by 10.90.56.2 with HTTP; Tue, 26 Dec 2006 00:58:46 -0800 (PST) Message-ID: <6b9359640612260058o751f75di883582c0a460a19b@mail.gmail.com> Date: Tue, 26 Dec 2006 01:58:46 -0700 From: "Kyle Hamilton" To: "Peter Williams" Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org, Peter Sylvester 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 ...primarily because there's no "record_type extension" mechanism. There's not even a defined range for experimental ones. Yes, it's security-critical. And yes, new record types cannot be created without WG action. However, I should think that this would be a VERY good reason for defining a range of record types that can be experimented with, and which can be guaranteed to be safely ignored by non-experimental stacks. and if I had any idea how to write an RFC or who to submit it to, I'd write up an idea for how to handle it. -Kyle H On 12/21/06, Peter Williams wrote: > Ive never fathomed why folks dont just invent their own client protocols of > the Record Protocol for user > auth purposes, give it a record_type, and mandate the dispatcher performs > the custom SSL handshake extension > directly upon session state change after the finish protocol, discarding > any APDU till it completes, and sets its > own secure state, a new modified Connection secure sub-state peculiar to > the enhancement.. This is what > the record_type extension capability was for! If I were doing GSSAPI > 1-token userauth (a signed blob, of the current > write mac?), I'd do it there, also. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 06:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzA2g-0007Hv-U0; Tue, 26 Dec 2006 06:00:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzA2f-0007Hm-LV for tls@ietf.org; Tue, 26 Dec 2006 06:00:21 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzA2e-0004m2-4s for tls@ietf.org; Tue, 26 Dec 2006 06:00:21 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBQB033c007691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Dec 2006 12:00:04 +0100 From: Simon Josefsson To: EKR References: <20061221154549.0A8941CC6B@delta.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061226:tls@ietf.org::Jm4aObWkeW0ghC64:4R7w X-Hashcash: 1:22:061226:ekr@networkresonance.com::keFprhB8q44FrpFV:SwnG Date: Tue, 26 Dec 2006 12:00:03 +0100 In-Reply-To: <20061221154549.0A8941CC6B@delta.rtfm.com> (ekr@networkresonance.com's message of "Thu\, 21 Dec 2006 07\:45\:48 -0800") Message-ID: <878xguzzv0.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.9 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org Subject: [TLS] Re: WGLC: draft-ietf-tls-srp-13 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 EKR writes: > This is a Working Group Last Call for draft-ietf-tls-srp-13. > > This document is intended for Experimental status. Please provide > comments to the authors and the list. > > This WGLC will end Fri Jan 12 (to allow time for people's holidays). The document seems fine, but the intended status bothers me. Changing the cipher suite numbers because the document now targets experimental status will disrupt deployed implementations and harms adoption of the protocol. Also, for this particular protocol, I believe its already wide deployment suggests that PS is the appropriate choice. However, as a general issue, it seems unfortunate that ciphersuite numbers are tightly connected to the IETF standards track category. If I recall correctly, successful documents on the Experimental track may later be revised into Proposed Standards. Will the ciphersuite numbers then change? This seems to be a general problem with the core TLS specification, and doesn't seem to be fully thought out. I suggest that for future TLS revisions, it should be considered whether to remove the distinction of standards-track numbers and non-standards track number, and that it becomes easier to have IANA perform early allocation of TLS ciphersuite numbers to help implementers test new TLS draft. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 11:17:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEyT-0007Nk-4R; Tue, 26 Dec 2006 11:16:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEyQ-0007Mp-9A for tls@ietf.org; Tue, 26 Dec 2006 11:16:18 -0500 Received: from s0106000f66877ea5.vw.shawcable.net ([70.70.131.205] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzEyN-0002eQ-1A for tls@ietf.org; Tue, 26 Dec 2006 11:16:18 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id CACC11CC2D; Tue, 26 Dec 2006 07:52:57 -0800 (PST) To: Subject: Re: [TLS] Comments on TLS identity protection References: <200612192307.AAA25601@uw1048.wdf.sap.corp> From: EKR Date: Tue, 26 Dec 2006 07:52:57 -0800 In-Reply-To: (home pw's message of "Tue, 26 Dec 2006 10:34:33 -0800") Message-ID: <86tzzislgm.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > By definition http over SSL is https. Nothing more is stated. I'm not sure what "nothing more is states" means. RFC 2818 provides a fair amount of detail on HTTPS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 11:17:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEyP-0007Mk-UH; Tue, 26 Dec 2006 11:16:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEyP-0007Md-A5 for tls@ietf.org; Tue, 26 Dec 2006 11:16:17 -0500 Received: from s0106000f66877ea5.vw.shawcable.net ([70.70.131.205] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzEyN-0002eP-1E for tls@ietf.org; Tue, 26 Dec 2006 11:16:17 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 913681CC24; Tue, 26 Dec 2006 07:51:41 -0800 (PST) To: Subject: Re: [TLS] Comments on TLS identity protection References: <86vek7pph4.fsf@raman.networkresonance.com> <200612192115.WAA22812@uw1048.wdf.sap.corp> <20061220123640.GB21201@tau.invalid> From: EKR Date: Tue, 26 Dec 2006 07:51:40 -0800 In-Reply-To: (home pw's message of "Tue, 26 Dec 2006 10:14:49 -0800") Message-ID: <86y7ouslir.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , Subject: Re: [TLS] Comments on TLS identity protection References: <200612192307.AAA25601@uw1048.wdf.sap.corp> From: EKR Date: Tue, 26 Dec 2006 07:52:57 -0800 In-Reply-To: (home pw's message of "Tue, 26 Dec 2006 10:34:33 -0800") Message-ID: <86tzzislgm.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > By definition http over SSL is https. Nothing more is stated. I'm not sure what "nothing more is states" means. RFC 2818 provides a fair amount of detail on HTTPS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 11:17:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEyP-0007Mk-UH; Tue, 26 Dec 2006 11:16:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzEyP-0007Md-A5 for tls@ietf.org; Tue, 26 Dec 2006 11:16:17 -0500 Received: from s0106000f66877ea5.vw.shawcable.net ([70.70.131.205] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzEyN-0002eP-1E for tls@ietf.org; Tue, 26 Dec 2006 11:16:17 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 913681CC24; Tue, 26 Dec 2006 07:51:41 -0800 (PST) To: Subject: Re: [TLS] Comments on TLS identity protection References: <86vek7pph4.fsf@raman.networkresonance.com> <200612192115.WAA22812@uw1048.wdf.sap.corp> <20061220123640.GB21201@tau.invalid> From: EKR Date: Tue, 26 Dec 2006 07:51:40 -0800 In-Reply-To: (home pw's message of "Tue, 26 Dec 2006 10:14:49 -0800") Message-ID: <86y7ouslir.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Normally, client auth is not allowed on a PKI-class ciphersuite, if > the server has not performed server auth. (In a mix of PKIand non-pki > ciphersuites -during a change-ciher-spec between the two - things are > admittedly more ambiguous.) > > On a PKI-class limited renegotiation case (or a session resumption > case), server auth is implied, of course - assuming both enc and mac > ciphers mechanism are not NULL. There's no way in TLS to currently have a NULL MAC algorithm. I doubt there is lilkely to be one soon. > For SSL3 using the RSA ciphersuites, one can ask for client auth on > handshake#2, without having provided server cert chain on that second > 'shake; server auth being established in the TLS resumed session (and > renewed Connection) state. I don't believe that this is correct. The state machines for the two handshakes aren't really related. What language leads you to believe that this is OK. > (I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or > either of those stds with their "RFC updates" demands) being entirely > different beasts to SSL3.) I doubt the language has changed substantially in this respect. I don't recall the WG clarifying this text. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls bscribe> List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Normally, client auth is not allowed on a PKI-class ciphersuite, if > the server has not performed server auth. (In a mix of PKIand non-pki > ciphersuites -during a change-ciher-spec between the two - things are > admittedly more ambiguous.) > > On a PKI-class limited renegotiation case (or a session resumption > case), server auth is implied, of course - assuming both enc and mac > ciphers mechanism are not NULL. There's no way in TLS to currently have a NULL MAC algorithm. I doubt there is lilkely to be one soon. > For SSL3 using the RSA ciphersuites, one can ask for client auth on > handshake#2, without having provided server cert chain on that second > 'shake; server auth being established in the TLS resumed session (and > renewed Connection) state. I don't believe that this is correct. The state machines for the two handshakes aren't really related. What language leads you to believe that this is OK. > (I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or > either of those stds with their "RFC updates" demands) being entirely > different beasts to SSL3.) I doubt the language has changed substantially in this respect. I don't recall the WG clarifying this text. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 13:36:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzH9A-0001Ab-BN; Tue, 26 Dec 2006 13:35:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzH98-0001AV-UV for tls@ietf.org; Tue, 26 Dec 2006 13:35:30 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzH96-0008VF-Nt for tls@ietf.org; Tue, 26 Dec 2006 13:35:30 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id BE42E29D52 for ; Tue, 26 Dec 2006 13:35:45 -0500 (EST) 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 proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 83652A5F56 for ; Tue, 26 Dec 2006 13:35:45 -0500 (EST) Message-ID: <45916B59.2030600@pobox.com> Date: Tue, 26 Dec 2006 10:35:05 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 References: <20061221154549.0A8941CC6B@delta.rtfm.com> <878xguzzv0.fsf@latte.josefsson.org> In-Reply-To: <878xguzzv0.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 suggest that for future TLS revisions, it should be considered > whether to remove the distinction of standards-track numbers and > non-standards track number, and that it becomes easier to have IANA > perform early allocation of TLS ciphersuite numbers to help > implementers test new TLS draft. I can see that it may be a good idea to remove the distinction between standard track and non-standard track ciphersuite numbers, but I'd like to see the private range retained. I am actually planning to use some private ciphersuites soon in an experiment. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 15:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzIsU-0000Gg-7e; Tue, 26 Dec 2006 15:26:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzIsS-0000Gb-T3 for tls@ietf.org; Tue, 26 Dec 2006 15:26:24 -0500 Received: from bay0-omc3-s8.bay0.hotmail.com ([65.54.246.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzIsQ-0005rP-Dg for tls@ietf.org; Tue, 26 Dec 2006 15:26:24 -0500 Received: from hotmail.com ([65.54.174.90]) by bay0-omc3-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 26 Dec 2006 12:26:21 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Dec 2006 12:26:21 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV18.phx.gbl with DAV; Tue, 26 Dec 2006 20:26:20 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <200612192307.AAA25601@uw1048.wdf.sap.corp> <86tzzislgm.fsf@delta.rtfm.com> Subject: Re: [TLS] Comments on TLS identity protection Date: Wed, 27 Dec 2006 07:35:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 26 Dec 2006 20:26:21.0499 (UTC) FILETIME=[1B3338B0:01C7292C] X-Spam-Score: 2.6 (++) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: >> By definition http over SSL is https. Nothing more is stated. > > I'm not sure what "nothing more is states" means. RFC 2818 provides > a fair amount of detail on HTTPS. Well, perhaps yes and perhaps no; I can argue two ways: by definition and by example. By definition, the cited work states "This memo describes how to use TLS to secure HTTP connections over the Internet." By example, the cited work doesn't state how IE2 and IE3 browsers working in a pure Novell net workstation environment allow the win95/98/Me stack to resolve HTTPS URLs, while even optionally cooperating with IP-websites using port 443! Surely, this example alone demonstrates that https is not limited to Internet! It supports the very first of the cited work! RFC 2818 does not define https: the protocol the usage profile(s), the URL resolver. Its just another designer's profile. The terms "https" was defined in the SSL patent. https is "http over SSL [the architecture]". The patent does not say...it MUST be bound to an SSL transport addressed using IANA-registerd TCP port (and lets note that IESG has essentially repudiated its https/ftps port architecture, and we all know https can bind to any SSL layer 4 port number!): http over client.write PCTv1 over reverse-tunnel server.write SSLv2 over netbios over SPX/IPX over Ethernet.v1 is just fine, where WINS resolves the netbios names in the certs!! The patent clearly indicates the claims are not limited to internet bearers, does not assume DNS support by the resolver of the https URL protocol. If all that early stuff (now seen used very little in its original Novell form) happened to gateway to IP SSL sites using SSL Connect (still seen in modern Microsoft ISA proxies, with interesting tunneling constructs these days), then IE3 browsers (applying the "https" URL on Novell nets) could even talk to Internet websites. This was "IE3-https"; im not sure Navigator.v4 ever bothered to match; it's a long time ago, tho. It was an "mozilla-compatible but \"embraced-and-extended\" https") The patent defines what SSL is (the general state machine architecture, not any particular handshake,ciphersuite or transport embodiment). It says very little about https. Its an example application. Its pretty clear, that the usage profile models featured in LDAP and HTTPS1.1 (to start and stop TLS session/connections as indicated by signals inband to application-data record_types) are very different to the "classical" class of https-es, from the Mozilla and SSL Connect world, which are based on the rules of URL protocol resolution. Given "https" can include fallback to PCT1.0, Does IETF-https include PCT 1.0 fallback? ? No! the https URL protocol resolver does, tho! Obviously, in PW world, experimental PWSSLs got added to that resolver, playing with things like ENUM addresses. So, RFC 1818 is deficient in many regards, as THE spec of "https". It doesn't address non-internet bearers, and it does not address URL resolvers. It then essentially advocated making the URL resolver is the packet originator of TLS connections and the initiator the TLS Session, interfering with the wider T-bridging architecture that https facilitated, in practice. Its just "RFC 2818-defined https" (and mighty fine profile it is too, particularly in its focus on closure rules) So, hopefully this argument demonstrates that 2818-https is but another variant of https, no more no less; hopefully, it acts as much as a conformance test target as a protocol spec (facilitating interoperability of the subtler elements, for mainstream internet https websites.) I do doubt whether 2818-https is functionally equivalent to IE-https, IE3-https, wininet-https, soap-binding-https, netscape-https, mozilla4-https, saml2-bindings-https, ws-fed-bindings-https, however; I believe it can be built with a lesser number of security critical functions than most of those, however. IF we need more evidence, we can cite already heard testimony from others, not Peter, that IIS3 and later has particular handshake practices, on seeking client certs over https over the same TCP connection (where client certs are used as a user auth mechanism, per mozilla-https practice) from "known-to-be-intending- to-be "mozilla-__compatible__clients. And, we saw behaviour difference being mentioned, when being presented (or not) with a client cert upon request handshake request. Some of the Microsoft IE team's approach to https for "enhanced mozilla- compatible" browsers was based in its work on PCT, which had some interesting ideas not present in SSL2/3. Speaking liberally, and non professionally for a paragraph, these ideas got placed into the "usage-profile" of SSL3, as manifest in IE.Vx-https. This is proper, and per intent. Being compatible with II3+ and mozilla means only that the two "interoperate in practice", not that they have the same usage profile or security target. Credit goes to the web for having achieved a "subtle" level of security interoperbility, for once! This practice fits web culture, tho perhaps not Internet culture, where we might prefer a formalized 2818-https, with a single correctness definition. Ill going to buy your book on SSL/TLS, today; and read it carefully. I'm hoping it lays out a good set of the known rationales for what are lots of subtle design choices facing designers, at least for those relying on 2818-https, RFC 2817 and other of that ilk such as ldap over SSL. I'm really quite interested in what rationales IETF had, for these latter binding practices onto TLS, particularly since given modern work is ongoing in binding application layer protocols (e.g. saml2 profiles to https). I'm expecting (sincerely) to learn. Peter. ----- Original Message ----- From: "EKR" To: Cc: ; Sent: Tuesday, December 26, 2006 7:52 AM Subject: Re: [TLS] Comments on TLS identity protection > > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 26 16:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzJjV-0000Tj-Ip; Tue, 26 Dec 2006 16:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzJjU-0000TE-Eo for tls@ietf.org; Tue, 26 Dec 2006 16:21:12 -0500 Received: from bay0-omc2-s26.bay0.hotmail.com ([65.54.246.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzJjT-0005aH-0I for tls@ietf.org; Tue, 26 Dec 2006 16:21:12 -0500 Received: from hotmail.com ([65.54.174.77]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 26 Dec 2006 13:21:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Dec 2006 13:21:10 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV5.phx.gbl with DAV; Tue, 26 Dec 2006 21:21:06 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <86vek7pph4.fsf@raman.networkresonance.com><200612192115.WAA22812@uw1048.wdf.sap.corp><20061220123640.GB21201@tau.invalid> <86y7ouslir.fsf@delta.rtfm.com> Subject: Re: [TLS] Comments on TLS identity protection Date: Wed, 27 Dec 2006 08:30:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 26 Dec 2006 21:21:10.0481 (UTC) FILETIME=[C3960C10:01C72933] X-Spam-Score: 2.5 (++) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 ----- Original Message ----- From: "EKR" To: Cc: "Bodo Moeller" ; "Martin Rex" ; Sent: Tuesday, December 26, 2006 7:51 AM Subject: Re: [TLS] Comments on TLS identity protection > writes: > >> Normally, client auth is not allowed on a PKI-class ciphersuite, if >> the server has not performed server auth. (In a mix of PKIand non-pki >> ciphersuites -during a change-ciher-spec between the two - things are >> admittedly more ambiguous.) >> >> On a PKI-class limited renegotiation case (or a session resumption >> case), server auth is implied, of course - assuming both enc and mac >> ciphers mechanism are not NULL. > > There's no way in TLS to currently have a NULL MAC algorithm. > I doubt there is lilkely to be one soon. There was no way for a client to directly control the encryption keys/IVs of a connection, until Fortezza_dms defined itself a way in its ciphersuite/serverkeyexchange! Clearly, we cannot say the SSL architecture denied that practice, or akin practices someone defines local for a (weird) MAC regime! We should learn to say "IETF standardized/endorsed ciphersuites don't...". TLS has clearly evolved, as a defined term, under the tutelage of IETF. We now understand that an "IETF-Conforming TLS implementation" may process local cipersuites, and its necessarily associated key agreement mechanisms, opaque handers, custom types, ephemeral handling. This is a consequent of standardizing the very means of denoting local ciphersuites - an excellent IETF move, if I may deliver an architectural compliment. > >> For SSL3 using the RSA ciphersuites, one can ask for client auth on >> handshake#2, without having provided server cert chain on that second >> 'shake; server auth being established in the TLS resumed session (and >> renewed Connection) state. > > I don't believe that this is correct. The state machines for the > two handshakes aren't really related. What language leads you > to believe that this is OK. Perhaps its my mental model at fault; this is not uncommon! (And I known I'm pushing the envelope, here; repeating questionable reasoning used - and previously challenged - 10 years ago, in a similar debate. I'm only interesting in RSA optimization, remember. And, I'm not interested in hobbling RSA, to be only used in modes equivalent to the limits facing other PKC schemes. And, lots of multi-key/multi-phase RSA computational variants exist, awaiting exploitation by designers of local ciphersuites.) Anyhows, Session Handshakes create pool(s) of TEKs/IKs/MEKs... using PKC algs, with centralized cache and cache protocols based off of sessionid and closure rules (per TLS and per app) that only influence connections that are yet to be active. Connections spawn off of these entries, by embodiment-specific means (perhaps each NIC uses an IEEE protocol to talk to the common session cache on the local or remote master switch in the subnet/vlan's STP, overcoming its vlan partioning sandbox that otherwise limits access to the particular session cache instance shared by all entities on the (tunneled) vlan) I see each such entry as being an "instance-factory pattern"; several runs of the truncated hello->final protocol on some bearer may each then renew the random components of the connection state(s), per connection duplication of an active session. Perhaps the http flows within may be pipelined, which includes how TLSconnections and per-connection TLS messages are mapped to bearer(s). This is particularly relevant if there is natural parallelism or streaming protocols in effect (e.g classical HTML page resolution where inline DHTML duplicates the active session to strongly name the address(es) resolved for relative URLs subordinate to that page). Now, for given cached session state (created by shake#1), and the connection stated with "renewed random values" are the two handshakes not linked by values used in the final protocol of the duplication session? Particularly, where we are are using unique TLS transports for each TLS COnnection, don't we need to rely on "inter-handshake linkage" using cryptographic strength - such that a client auth done on one TCP connection is carried forward onto the TLS Connection duplicated from its parent that as in turn communicated a different TCP (but still active) connection? (This seemed to be one of the areas in SRP that they had not quite got correct, yet.) And, then turning the argument around, doesn't the same reasoning apply for server auth? > > -Ekr Some fun in 2818, also, (half-)reasoning by analogy:- If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 27 12:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzc8s-0002bf-RR; Wed, 27 Dec 2006 12:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzc8r-0002bZ-Td for tls@ietf.org; Wed, 27 Dec 2006 12:00:37 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzc8q-0000bF-Hb for tls@ietf.org; Wed, 27 Dec 2006 12:00:37 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA20871; Wed, 27 Dec 2006 17:58:58 +0100 (MEZ) From: Martin Rex Message-Id: <200612271658.RAA10882@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection To: home_pw@msn.com Date: Wed, 27 Dec 2006 17:58:58 +0100 (MET) In-Reply-To: from "home_pw@msn.com" at Dec 26, 6 10:34:33 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 home_pw@msn.com wrote: > > > When the server-requested renegotiation is application triggered, > > as in the Microsoft IIS case, then the server better caches the > > result along with the SSL session. > > > > Microsoft IIS has a silly (performance-wasting) bug, where a client that > > does either not have a client cert or does not show one (and requiring > > the application to perform application level client authentication) > > is continously forced through the renegotiation when the client > > tries to resume the session from the session cache on a new connection. > > This is not a bug. It is an explicitly permitted state within the SSL v3 > conformance/state. Upon request, a client MAY send a client cert. What > happens if it doesn't, is server policy. In my terminology it is a design flaw of Microsoft's IIS, and one that can hardly be overlooked if the functionality is tested at least once before shipping. It might be the result of two things: (a) IIS being stateless for independent connections (b) the underlying SSL/TLS engine lacking to memorize/cache the answer on a (previous) client certificate and making this attribute available/visible for the application. I don't know if any of the existing SSL/TLS stacks memorizes/caches this meta-information along with the SSL session and make it available to (stateless) applications, so that they do not bother clients over and over with pointless renegotiations. MSIE caches the answer on the client certificate request at the application level on the client side and automatically applies it without asking the user. Netscape/Mozilla/Opera don't do that and show popups for parallel/new connections (or even every embedded object if no persistent connections are used). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 27 15:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzfIt-0000e6-4I; Wed, 27 Dec 2006 15:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzfIr-0000dU-IK for tls@ietf.org; Wed, 27 Dec 2006 15:23:09 -0500 Received: from bay0-omc1-s36.bay0.hotmail.com ([65.54.246.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzfIn-0003lS-56 for tls@ietf.org; Wed, 27 Dec 2006 15:23:09 -0500 Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 27 Dec 2006 12:23:04 -0800 X-Originating-IP: [24.6.106.3] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: EKR Subject: RE: [TLS] Comments on TLS identity protection Date: Wed, 27 Dec 2006 12:23:04 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Dec 2006 20:23:04.0920 (UTC) FILETIME=[D0716580:01C729F4] X-Spam-Score: 2.2 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1613977122==" Errors-To: tls-bounces@lists.ietf.org --===============1613977122== Content-Type: multipart/alternative; boundary="_0221e813-826e-4762-99d3-59c9d034190c_" --_0221e813-826e-4762-99d3-59c9d034190c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > > There's no way in TLS to currently have a NULL MAC algorithm.> > I doub= t there is lilkely to be one soon. =20 if we look at the text of SSLv3, it discussed null mac functions in the arc= hitecture:- =20 If the CipherSuite is SSL_NULL_WITH_NULL_NULL, encryption consists of the i= dentity=20 operation (i.e., the data is not encrypted and the MAC size is zero implyin= g that=20 no MAC is used). SSLCiphertext.length is SSLCompressed.length plus=20 CipherSpec.hash_size.=20 =20 I'd claim that a complete, SSL-patent implementing state machine (E.g TLS )= therefore supports null MAC algorithms. As TLS implies SSLv3 fallback capability...th= e capability needs to be provided to be complete. I think we can allow for "no MAC is used" (s= pec) to be equivalent to=20 "NULL MAC algorithm" (peter-speak), linguistically. =20 if we consider =20 "The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at th= e beginning of the SSL=20 Handshake Protocol, indicating that no message authentication or encryptio= n is performed. The handshake=20 protocol is used to negotiate a more secure CipherSpec and to generate cryp= tographic keys. " =20 So perhaps the truthful political-appropriate statement would be that https= (vs TLS) supports NULL=20 MAC (as https tends to include the SSLv3 fallback modes of TLS) =20 _________________________________________________________________ Fixing up the home? Live Search can help. http://imagine-windowslive.com/search/kits/default.aspx?kit=3Dimprove&local= e=3Den-US&source=3Dwlmemailtaglinenov06= --_0221e813-826e-4762-99d3-59c9d034190c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
> > There's no way in TLS to currently have a NULL MAC algorithm.
= > > I doubt there is lilkely to be one soon.
 
if we look at the text of SSLv3, it discussed null mac functions in the arc= hitecture:-
 
If the CipherSuite is SSL_NULL_WITH_NULL_NULL, encryption = consists of the identity
operation (i.e., the data is not encrypted and the MAC size is zero= implying that
no MAC is used). SSLCiphertext.length is SSLCompressed= .length plus
CipherSpec.hash_size.
 
I'd claim that a complete,=  SSL-patent implementing state machine (E.g TLS= ) therefore
supports null MAC algorith= ms. As TLS implies SSLv3 fallback capability...the capability needs<= /TT>
to be provided to be complete. I think we can a= llow for "no MAC is used" (spec) to be equivalent to =
"NULL MAC algorithm" (peter-speak), linguistica= lly.
 
if we consider
 
"The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL
Handshake Protocol,  indicating that no message authentication = or encryption is performed. The handshake
protocol is used to negotiate a more secure CipherSpec and to gene= rate cryptographic keys. "
 
So perhaps the truthful political-appropriate s= tatement would be that https (vs TLS) supports NULL
MAC (as https tends to include the SSLv3 fallback modes of TLS)
 

View Ath= letes' Collections with Live Search. See it! = --_0221e813-826e-4762-99d3-59c9d034190c_-- --===============1613977122== 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 --===============1613977122==-- From tls-bounces@lists.ietf.org Wed Dec 27 20:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzjzf-0003l4-N7; Wed, 27 Dec 2006 20:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzjzf-0003kn-62 for tls@ietf.org; Wed, 27 Dec 2006 20:23:39 -0500 Received: from s0106000f66877ea5.vw.shawcable.net ([70.70.131.205] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzjzd-00037p-U1 for tls@ietf.org; Wed, 27 Dec 2006 20:23:39 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id A59C31CC29; Wed, 27 Dec 2006 17:22:22 -0800 (PST) To: Peter Williams Subject: Re: [TLS] Comments on TLS identity protection References: From: EKR Date: Wed, 27 Dec 2006 17:22:22 -0800 In-Reply-To: (Peter Williams's message of "Wed, 27 Dec 2006 12:23:04 -0800") Message-ID: <8664bw7r1t.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Peter Williams writes: > >> > There's no way in TLS to currently have a NULL MAC algorithm.> > I doubt there is lilkely to be one soon. > > if we look at the text of SSLv3, it discussed null mac functions in the architecture:- > > If the CipherSuite is SSL_NULL_WITH_NULL_NULL, encryption consists of the identity > operation (i.e., the data is not encrypted and the MAC size is zero implying that > no MAC is used). SSLCiphertext.length is SSLCompressed.length plus > CipherSpec.hash_size. Yes, but TLS explicitly forbids you to negotiate this algorithm (i.e., it's only useful for performing the handshake). TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but must not be negotiated, as it provides no more protection than an unsecured connection. So, it's basically a different way of expressing "do your first handshake in the clear". -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 28 02:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzpU7-0007We-PF; Thu, 28 Dec 2006 02:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzpU6-0007Uq-RA for tls@ietf.org; Thu, 28 Dec 2006 02:15:26 -0500 Received: from moutng.kundenserver.de ([212.227.126.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzpU5-00032C-FS for tls@ietf.org; Thu, 28 Dec 2006 02:15:26 -0500 Received: from [80.142.189.16] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GzpU10DQa-0006o9; Thu, 28 Dec 2006 08:15:22 +0100 Received: by tau.invalid (Postfix, from userid 1000) id C0F3A11C86; Thu, 28 Dec 2006 08:15:19 +0100 (CET) Date: Thu, 28 Dec 2006 08:15:19 +0100 From: Bodo Moeller To: Simon Josefsson Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Message-ID: <20061228071519.GA6876@tau.invalid> References: <20061221154549.0A8941CC6B@delta.rtfm.com> <878xguzzv0.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878xguzzv0.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, Dec 26, 2006 at 12:00:03PM +0100, Simon Josefsson wrote: > However, as a general issue, it seems unfortunate that ciphersuite > numbers are tightly connected to the IETF standards track category. > If I recall correctly, successful documents on the Experimental track > may later be revised into Proposed Standards. Will the ciphersuite > numbers then change? Having separate ranges reserved for Standards Track assignments and reserved for non-Standards Track ciphersuite assignments is meant to prevent non-Standards Track documents from using up too much of the total ciphersuite space. So, unless there are incompatible changes to the ciphersuite, there is no need to renumber if a ciphersuite progresses from Experimental Track to Standards Track. After all, the Standards Track specification won't need to use cipher suite values that are merely reserved: instead, it can continue to use the cipher suite values that have already been assigned. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 28 08:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzurd-0007nm-Me; Thu, 28 Dec 2006 08:00:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzurb-0007nS-Ti for tls@ietf.org; Thu, 28 Dec 2006 08:00:03 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzurX-0001RS-Dx for tls@ietf.org; Thu, 28 Dec 2006 08:00:03 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id NAA07716; Thu, 28 Dec 2006 13:59:48 +0100 (MEZ) From: Martin Rex Message-Id: <200612281259.NAA28445@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection To: ekr@networkresonance.com Date: Thu, 28 Dec 2006 13:59:48 +0100 (MET) In-Reply-To: <8664bw7r1t.fsf@delta.rtfm.com> from "EKR" at Dec 27, 6 05:22:22 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: 798b2e660f1819ae38035ac1d8d5e3ab 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 EKR wrote: > > Yes, but TLS explicitly forbids you to negotiate this algorithm > (i.e., it's only useful for performing the handshake). > > TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a > TLS connection during the first handshake on that channel, but must > not be negotiated, as it provides no more protection than an > unsecured connection. > > So, it's basically a different way of expressing "do your first > handshake in the clear". TLS_NULL_WITH_NULL_NULL does not provide per-message MAC. It is sort-of a hack for the SSL protocol engine to cover the initial phase when there is not yet a shared secret. It is OK to use for the messages of the SSL handshake -- which do not need a per-message MAC as they're protected by the full handshake MAC of the Finished messages. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 29 02:06:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0BnO-0007xl-Ej; Fri, 29 Dec 2006 02:04:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0BnL-0007xO-Gw for tls@ietf.org; Fri, 29 Dec 2006 02:04:48 -0500 Received: from bay0-omc1-s6.bay0.hotmail.com ([65.54.246.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0BnK-0008KF-5G for tls@ietf.org; Fri, 29 Dec 2006 02:04:47 -0500 Received: from hotmail.com ([65.54.174.90]) by bay0-omc1-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 28 Dec 2006 23:04:45 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Dec 2006 23:04:45 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV18.phx.gbl with DAV; Fri, 29 Dec 2006 07:04:43 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Mike" , References: <20061221154549.0A8941CC6B@delta.rtfm.com><878xguzzv0.fsf@latte.josefsson.org> <45916B59.2030600@pobox.com> Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Date: Thu, 28 Dec 2006 23:04:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Dec 2006 07:04:45.0467 (UTC) FILETIME=[9EF866B0:01C72B17] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 well done! ----- Original Message ----- but I'd like to see the private range retained. I am actually > planning to use some private ciphersuites soon in an experiment. > > Mike (a) there is good basis now to define a class of "local" changeciphersuite values, to allow signaling of per-ciphersuite customizations of the finished/final process. I already gave the example of completing SSLv3 fortezza_dms generation of sessionTEKs with the UKM processes for deriving key for SSL connections, that could then control active state duplication (on the current, multiplexed, or different TLS transport) and session resumption (on a new transport instance) (b) we see GSSAPI-proposal basically introducing a mechanism-negotiation sub-protocol, qualifying the negotiation of some nominal GSS ciphersuites essentially, for PRF mechanisms and who knows what else, tomorrow. This same process could easily now mandate the changeciphersuite value to be used, and thus key derivation(s) used to create connection states, for each of the the 4 channels per SSL Connection instance (c) we see local ciphersuites being used, possibly to profile mainstream ciphersuites (E.g facilitate SGC variant for std RSA ciphersuites). That is, do IETF RSA, but don't do or perhaps add rule X on a renegotiation (e.g. use cache of public keys for server auth) when the capability negotiation from the GSSAPI negotiation signals that a particular class of renegotiation is required, using "local ciphersuite" local.X ...whose local-number and semantics is associated with some GSSAPI mechanism oid (an unlimited size name space). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 29 02:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Cao-0002Oh-Kq; Fri, 29 Dec 2006 02:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Cam-0002OW-Eb for tls@ietf.org; Fri, 29 Dec 2006 02:55:52 -0500 Received: from bay0-omc3-s5.bay0.hotmail.com ([65.54.246.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Cal-00014m-68 for tls@ietf.org; Fri, 29 Dec 2006 02:55:52 -0500 Received: from hotmail.com ([65.54.174.76]) by bay0-omc3-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 28 Dec 2006 23:55:51 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Dec 2006 23:55:50 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV4.phx.gbl with DAV; Fri, 29 Dec 2006 07:55:49 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Date: Thu, 28 Dec 2006 23:56:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Dec 2006 07:55:50.0631 (UTC) FILETIME=[C1F34F70:01C72B1E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 were discussing ephemeral DH (etc), vs temporary RSA. As always, NIST make things crystal clear: http://csrc.nist.gov/CryptoToolkit/kms/SP800-56A_May2006.pdf Its best to read this in concert with IETF's CMS for KEA/skipjack, so one can see its application to more than undergrad DH examples. Then one can apply it to SSLv3 (and extensions). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 29 03:47:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0DNc-0001ZI-3f; Fri, 29 Dec 2006 03:46:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0DNb-0001ZD-Eo for tls@ietf.org; Fri, 29 Dec 2006 03:46:19 -0500 Received: from bay0-omc1-s25.bay0.hotmail.com ([65.54.246.97]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0DNY-0004DC-Vj for tls@ietf.org; Fri, 29 Dec 2006 03:46:19 -0500 Received: from hotmail.com ([65.54.174.85]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 00:46:16 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 00:46:16 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV13.phx.gbl with DAV; Fri, 29 Dec 2006 08:46:15 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Date: Fri, 29 Dec 2006 00:46:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Dec 2006 08:46:16.0097 (UTC) FILETIME=[CD44C910:01C72B25] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 http://csrc.nist.gov/CryptoToolkit/kms/SP800-56A_May2006.pdf see appendix B. Its rationale is relevant to SSL's finished processes, and the TLS Evidence work item (concerning the confirmed roles being affirmed, pertinent to the "agreement"). I suspect TLS really ought to define more roles for use in the final KDF, including "T-bridge" and "https proxy". ----- Original Message ----- From: To: Sent: Thursday, December 28, 2006 11:56 PM Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 > We were discussing ephemeral DH (etc), vs temporary RSA. > > As always, NIST make things crystal clear: > > http://csrc.nist.gov/CryptoToolkit/kms/SP800-56A_May2006.pdf > > Its best to read this in concert with IETF's CMS for KEA/skipjack, so > one can see its application to more than undergrad DH examples. Then > one can apply it to SSLv3 (and extensions). > > > _______________________________________________ > 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 Fri Dec 29 12:53:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LuC-0007i7-Kc; Fri, 29 Dec 2006 12:52:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0LuC-0007i0-71 for tls@ietf.org; Fri, 29 Dec 2006 12:52:32 -0500 Received: from bay0-omc1-s36.bay0.hotmail.com ([65.54.246.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0LuA-0002NU-PT for tls@ietf.org; Fri, 29 Dec 2006 12:52:32 -0500 Received: from hotmail.com ([65.54.174.86]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 09:52:30 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 09:52:30 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV14.phx.gbl with DAV; Fri, 29 Dec 2006 17:52:29 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <200612281259.NAA28445@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on TLS identity protection Date: Fri, 29 Dec 2006 09:52:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Dec 2006 17:52:30.0222 (UTC) FILETIME=[1C2B62E0:01C72B72] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 TLS does indeed forbid the _negotiation_ of this defined ciphersuite. (This is why I phrased my claim in terms of SSLv3, which allows it. Furthermore, for a mixed TLS/SSL protocol entity, completeness demands the feature be negotiable, for certain versions) So the claims of all 3 parties are true :-) But we are not yet getting to the crux. Regardless of the modes under which NULL MAC is negotiated/conforming, it exists. It properly exists, furthermore. (A decent conformance checker should be testing for it.) In SSLv3 one can choose to changeCipherSuite to a null encryption and null mac state, and merely use the fragmentation, sequencing and reassembly functions of the SSL protocol machine. (Nothing in SSLv3 states how the seq_num is calculated , note. It can be simple or fancy (provided it starts at zero, when the connection state is initialized or assigned).) In TLS, one can define and negotiate a local ciphersuite that does the same, of course. PC->server does TLS RSA handshake and Netscape privacy-enhanced step-up renegotiation (from Eric's book). Server->PC initiates a tunelled SSL_NULL_WITH_NULL_NULL handshake, to negotiate a SSL_NULL_WITH_NULL_NULL SSL Connection that gives us a record layer protocol with variable-length framing, alerts and the ClientHello-signalled type-extensibility (over a reliable bearer known as the outer TLS Connection). This is all very useful! ----- Original Message ----- From: "Martin Rex" To: Cc: ; Sent: Thursday, December 28, 2006 4:59 AM Subject: Re: [TLS] Comments on TLS identity protection > EKR wrote: >> >> Yes, but TLS explicitly forbids you to negotiate this algorithm >> (i.e., it's only useful for performing the handshake). >> >> TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a >> TLS connection during the first handshake on that channel, but must >> not be negotiated, as it provides no more protection than an >> unsecured connection. >> >> So, it's basically a different way of expressing "do your first >> handshake in the clear". > > TLS_NULL_WITH_NULL_NULL does not provide per-message MAC. > It is sort-of a hack for the SSL protocol engine to cover > the initial phase when there is not yet a shared secret. > > It is OK to use for the messages of the SSL handshake -- which > do not need a per-message MAC as they're protected by the > full handshake MAC of the Finished messages. > > -Martin > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 29 16:51:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PcC-00035O-PR; Fri, 29 Dec 2006 16:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0PcB-00035J-KD for tls@ietf.org; Fri, 29 Dec 2006 16:50:11 -0500 Received: from bay0-omc1-s14.bay0.hotmail.com ([65.54.246.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Pc9-0004hf-83 for tls@ietf.org; Fri, 29 Dec 2006 16:50:11 -0500 Received: from hotmail.com ([65.54.174.75]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 13:50:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 13:50:06 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV3.phx.gbl with DAV; Fri, 29 Dec 2006 21:50:05 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Date: Fri, 29 Dec 2006 13:50:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 29 Dec 2006 21:50:06.0603 (UTC) FILETIME=[4DA27DB0:01C72B93] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Given RSA "ephemeral" is being discussed on the WG's mailing list and was discussed in Eric's authoritative SSL/TLS book, presumably referring to SSL3/TLS "temporary" keys, we should attempt to put the topic into the formal proceedings. If I read between the lines, perhaps we see the underlying issues of "hardware-assured key exchange" being introduced in NSA's proposed means for "application-enhanced" PRF mechanisms; and, perhaps also in the GSS-API proposals. Whilst this is but conjecture on my part, it's not unreasonable. Given these issues, let's revisit: http://www3.ietf.org/proceedings/04mar/I-D/draft-ietf-smime-cms-rsa-kem-01.txt (as FIPS 800-56B drafts are not available to the likes of me.) Lets contrast schemes, top begin. SSL3 invested in ephemeral (DH) and temporary (RSA) keying as means of enforcing cryptostrength-containment policies (i.e. export rules); others use them for assurance reasons, giving plausible rationales. We saw the latter clearly articulated in 800-56A, and given embodiment by IESG in the CMS with KEA/skipjack RFC. We can see read it furthermore, albeit minimally, in SSLv3 fortezza_dms's type declarations. Now, it was a colleague of Russ Housley who taught me about the linkage between PKC and integrity-protected (1) TEKs/KEKs, (2) wrapped keys/IVs (with or without LEAFs), and the design of assured FIPS-complying cryptomodules. It was a former member of CSE in Canada who then taught me how these principles are extended to trusted path arming processes, in a level 3 FIPS device. If I now summarize what I was taught, when done right, security handshakes are but a way of provisioning a trusted cryptomodule - a way of remoting the admin port, over which previouslyone might have deployed key manually, using a key fill device. When done right, we can then create families of trusted devices distinguished by manufacturing-time certs and group parameters; with HSM-certs that accompany key exchange certificates (both static and ephemeral) to distinguish crypto from such an HSM family from software CSPs. Linked now to FIPS-mode HMACs we see how key derivation can characterize even roles within a security protocol flow, extending the TNI's connection-oriented access control concept to address RBAC. When we look at what NIST and NSA folks have openly taught us, with KEA for DH's key agreement regimes, as reflected in SSLv3 and CMS, I'm open minded whether RSA ciphersuites should adopt similar assurance benefits, re key wrapping, MacTags, etc. Viewing RSA transient and additional nonces no longer as export-regulation enforcement tools but as assurance-producing mechanisms, perhaps we do need to adapt to RSA ciphersuites (a) key wrapping (b) static and ephemeral keys c) nonces (d) manufacturing and HSM certs. Peter. ----- Original Message ----- From: To: Sent: Thursday, December 28, 2006 11:56 PM Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 > We were discussing ephemeral DH (etc), vs temporary RSA. > > As always, NIST make things crystal clear: > > http://csrc.nist.gov/CryptoToolkit/kms/SP800-56A_May2006.pdf > > Its best to read this in concert with IETF's CMS for KEA/skipjack, so > one can see its application to more than undergrad DH examples. Then > one can apply it to SSLv3 (and extensions). > > > _______________________________________________ > 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 Fri Dec 29 21:24:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0TsR-00068l-To; Fri, 29 Dec 2006 21:23:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0TsR-00068d-2V for tls@ietf.org; Fri, 29 Dec 2006 21:23:15 -0500 Received: from bay0-omc3-s33.bay0.hotmail.com ([65.54.246.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0TsP-00016t-NP for tls@ietf.org; Fri, 29 Dec 2006 21:23:15 -0500 Received: from hotmail.com ([65.54.174.86]) by bay0-omc3-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 18:23:12 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 18:23:13 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV14.phx.gbl with DAV; Sat, 30 Dec 2006 02:23:10 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 Date: Fri, 29 Dec 2006 18:23:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 02:23:13.0018 (UTC) FILETIME=[74B2FDA0:01C72BB9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 > (as FIPS 800-56B drafts are not available to the likes of me.) I've been attempting to deconstruct what I understand NIST's position on next generation RSA ciphersuites to be (from what I assume 800-56B to say):- Based on the way 800-56A discusses the role of RSA (or other) key transport. One uses DH in the users' national identity cards to agree a random secret, which has the important property of "bi-lateral key confirmation" implicit to the math of the DH/KEA etc. This agreement process may include certain DH ephemerals in addition to statics, and a UKM nonce. This process satisfies the writer-to-reader rules. One may use RSA as an IK to transport to several parties the "secret" value to the authorized HSMs associated with one or more user (e.g. one's TPM-based SSL CSP, or a broadcast community of HSMs). The crypto device uses a parameterized-KDF to transform the value into a KEK, which unwraps the keying materials (and mac secrets) used in the SSL HSMs. Presumably, the KDF enforces TPM assurance controls, preventing key derivation when the secret is not assured to be from authorized id cards (validated using "tri-lateral key confirmation" using some unstated method (e.g. HSM certs)). "Key confirmation" would have to be trilateral, if there is key confirmation by a "third party" - the community of authorized crypto devices. The final KDF (per connection) in SSL finished protocol takes into account the roles of the 2 or more SSL parties, currently hashes of the terms "client" and "server" ------------ For fun one can extrapolate, doctrinally:- One can define a role for TLS Evidence, which exist to audit such handshakes, using a dig sig of the handshake hashes (and store the handshake plaintexts). Presumably, the router/ISP can enforce policy to (a) interdict certain flows (b) record certain auditable handshake plaintexts. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 29 22:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0V8Q-0007NY-1t; Fri, 29 Dec 2006 22:43:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0V8O-0007NQ-H3 for tls@ietf.org; Fri, 29 Dec 2006 22:43:48 -0500 Received: from bay0-omc3-s27.bay0.hotmail.com ([65.54.246.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0V8N-0005Rl-7o for tls@ietf.org; Fri, 29 Dec 2006 22:43:48 -0500 Received: from hotmail.com ([65.54.174.77]) by bay0-omc3-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 19:43:46 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 19:43:46 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV5.phx.gbl with DAV; Sat, 30 Dec 2006 03:43:44 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Kyle Hamilton" References: <6b9359640612260058o751f75di883582c0a460a19b@mail.gmail.com> Subject: Re: [TLS] Re: I-D ACTION:draft-ietf-tls-srp-13.txt Date: Fri, 29 Dec 2006 19:43:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 03:43:46.0567 (UTC) FILETIME=[B5B80970:01C72BC4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 ----- Original Message ----- From: "Kyle Hamilton" To: "Peter Williams" > ...primarily because there's no "record_type extension" mechanism. > There's not even a defined range for experimental ones. > > Yes, it's security-critical. And yes, new record types cannot be > created without WG action. However, I should think that this would be > a VERY good reason for defining a range of record types that can be > experimented with, and which can be guaranteed to be safely ignored by > non-experimental stacks. struct { uint8 major, minor; } ProtocolVersion; enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[SSLPlaintext.length]; } SSLPlaintext; just define your own, number 255. Define your own major=255 and minor=255 if you want, also When interworking with a conforming SSL entity, you should get unexpected_message fatal alerts. From your responder, with the knowledge of the experimental types, you will presumably not. There is no harm in defining your own record_types. You were supposed to. Experiment! > and if I had any idea how to write an RFC or who to submit it to, I'd > write up an idea for how to handle it. Don’t bother till there is evidence of a community that wants to interwork. > -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 29 23:12:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VZf-0008Fk-NR; Fri, 29 Dec 2006 23:11:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0VZe-0008Ff-JE for tls@ietf.org; Fri, 29 Dec 2006 23:11:58 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0VZd-0006dE-AZ for tls@ietf.org; Fri, 29 Dec 2006 23:11:58 -0500 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 25C961CC37; Fri, 29 Dec 2006 13:54:40 -0800 (PST) To: home_pw@msn.com Subject: Re: [TLS] Comments on TLS identity protection In-reply-to: Your message of "Fri, 29 Dec 2006 09:52:43 PST." X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Fri, 29 Dec 2006 13:54:40 -0800 From: EKR Message-Id: <20061229215440.25C961CC37@delta.rtfm.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 wrote: > TLS does indeed forbid the _negotiation_ of this defined > ciphersuite. (This is > why I phrased my claim in terms of SSLv3, which allows it. Another way of looking at this is that it's a bug in the SSLv3 spec that was fixed in TLS. Are you aware of any implementation that in fact allows you to negotiate this cipher suite? > In SSLv3 one can choose to changeCipherSuite to a null encryption and > null mac state, and merely use the fragmentation, sequencing and reassembly > functions of the SSL protocol machine. The what? SSL offers no capabilities here that are not offered by the reliable transport it must ride on top of. > (Nothing in SSLv3 states how the > seq_num is calculated , note. It can be simple or fancy (provided it starts > at zero, when the connection state is initialized or assigned).) I don't have the v3 spec in front of me, but if that's true, it's a bug in the spec, IMO. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 30 00:16:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WZR-0004Yt-IV; Sat, 30 Dec 2006 00:15:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WZQ-0004Yk-1M for tls@ietf.org; Sat, 30 Dec 2006 00:15:48 -0500 Received: from bay0-omc1-s27.bay0.hotmail.com ([65.54.246.99]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0WZO-0003qV-GA for tls@ietf.org; Sat, 30 Dec 2006 00:15:48 -0500 Received: from hotmail.com ([65.54.174.76]) by bay0-omc1-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 29 Dec 2006 21:15:45 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2006 21:15:45 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV4.phx.gbl with DAV; Sat, 30 Dec 2006 05:15:43 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <20061229215440.25C961CC37@delta.rtfm.com> Subject: Re: [TLS] Comments on TLS identity protection Date: Fri, 29 Dec 2006 21:15:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 05:15:45.0913 (UTC) FILETIME=[8F816690:01C72BD1] X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 > >> In SSLv3 one can choose to changeCipherSuite to a null encryption and >> null mac state, and merely use the fragmentation, sequencing and >> reassembly >> functions of the SSL protocol machine. > > The what? SSL offers no capabilities here that are not offered > by the reliable transport it must ride on top of. Your missing my point. Im not putting SSL record layer over TCP.... My SSL application is not https, it is itself an SSL Connection, sending record_layer records data over... record_types of an currently active (underlying) TLS Connection. Like Ldap and HTTP1.1 update an TCP session to turn TLS Connection's on and off for certain TCP fragments, I do the same with my outer SSL connection. When my upper layer (inner SSL connection) sends a certain custom record_type into the stream, this is recognized by the outer SSL Connection which does a certain class and type of handshake... I'm doing nothing here that TLS Evidence is not suggesting (albeit by abusing alerts!) Hopefully, I can read the 2nd half of your TLS/SSL book tomorrow, focusing on the engineering discussion, rather than the protocol discussion. >> (Nothing in SSLv3 states how the >> seq_num is calculated , note. It can be simple or fancy (provided it >> starts >> at zero, when the connection state is initialized or assigned).) > > I don't have the v3 spec in front of me, but if that's true, it's > a bug in the spec, IMO. Perhaps! "Each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero. Sequence numbers are of type uint64 and may not exceed 264-1. " For TLS1.0, one may assume that increment means uint64++ (which seems reasonable, when writing a conformance/value/state checker) "Sequence numbers are of type uint64 and may not exceed 2^64-1. A sequence number is incremented after each record: specifically, the first record which is transmitted under a particular connection state should use sequence number 0." I think SSLv3 is clearer than TLS, concerning when sequence number is set to zero. FOr SSL3, its changedfor any variant of the change cipher spec message. For TLS, its the :first: message under "a particular connection state". If TLS Evidence changes the notion of Connection state (which it seems to do, being an extension of connection state machine), we now now have alerts setting seq_num=0. They jury is only going to ask what went before .... if the seq_num for the audited handshake starts at 9225. Hmm. > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 30 00:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WlM-0000eP-N9; Sat, 30 Dec 2006 00:28:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0WlL-0000eH-AA for tls@ietf.org; Sat, 30 Dec 2006 00:28:07 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0WlJ-0007Dt-Vg for tls@ietf.org; Sat, 30 Dec 2006 00:28:07 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id C93061CC24; Fri, 29 Dec 2006 21:26:48 -0800 (PST) To: Subject: Re: [TLS] Comments on TLS identity protection References: <20061229215440.25C961CC37@delta.rtfm.com> From: EKR Date: Fri, 29 Dec 2006 21:26:48 -0800 In-Reply-To: (home pw's message of "Fri, 29 Dec 2006 21:15:56 -0800") Message-ID: <86ac166jjb.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: >> >>> In SSLv3 one can choose to changeCipherSuite to a null encryption and >>> null mac state, and merely use the fragmentation, sequencing and >>> reassembly >>> functions of the SSL protocol machine. >> >> The what? SSL offers no capabilities here that are not offered >> by the reliable transport it must ride on top of. > > Your missing my point. Obviously. > Im not putting SSL record layer over TCP.... My SSL application is not > https, it is > itself an SSL Connection, sending record_layer records data > over... record_types of > an currently active (underlying) TLS Connection. SSL requires that the transport over which it is carried be a reliable stream transport. For starters, it's implicit in the design of the crypto (the use of stream ciphers and CBC chaining between records). >>> (Nothing in SSLv3 states how the >>> seq_num is calculated , note. It can be simple or fancy (provided >>> it starts >>> at zero, when the connection state is initialized or assigned).) >> >> I don't have the v3 spec in front of me, but if that's true, it's >> a bug in the spec, IMO. > > > Perhaps! > > "Each party maintains separate sequence numbers for transmitted and > received messages for each connection. When a party sends or receives > a change cipher spec message, the appropriate sequence number is set > to zero. Sequence numbers are of type uint64 and may not exceed > 264-1. " > > For TLS1.0, one may assume that increment means uint64++ (which seems > reasonable, when writing a > conformance/value/state checker) I believe that it is the consensus of pretty much all SSLv3 and TLS implementors that it means start at zero and increment by one for all versions of the spec. > FOr SSL3, > its changedfor any variant of the change cipher spec message. For TLS, its > the :first: message under "a particular connection state". If TLS Evidence > changes the notion of Connection state (which it seems to do, being an > extension of connection state machine), we now now have alerts setting > seq_num=0. The anti-replay guarantees of SSL/TLS (and the security guarantees if you have an IV that depends on record seq #) depend on the property that any given set of cryptographic keys may only be used once with a given record sequence number. Since the Evidence extensions do not change the cryptographic keys, they cannot allow the sequence number to be reset. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 30 03:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZSh-0006ux-G0; Sat, 30 Dec 2006 03:21:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ZSg-0006rl-DD for tls@ietf.org; Sat, 30 Dec 2006 03:21:02 -0500 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ZSf-0008E0-4A for tls@ietf.org; Sat, 30 Dec 2006 03:21:02 -0500 Received: from hotmail.com ([65.54.174.82]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 00:21:00 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 00:21:00 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV10.phx.gbl with DAV; Sat, 30 Dec 2006 08:20:55 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <20061229215440.25C961CC37@delta.rtfm.com> Subject: Re: [TLS] Comments on TLS identity protection Date: Sat, 30 Dec 2006 00:21:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 08:21:00.0524 (UTC) FILETIME=[705472C0:01C72BEB] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org > wrote: >> TLS does indeed forbid the _negotiation_ of this defined >> ciphersuite. (This is >> why I phrased my claim in terms of SSLv3, which allows it. > > Another way of looking at this is that it's a bug in the > SSLv3 spec that was fixed in TLS. Are you aware of any > implementation that in fact allows you to negotiate this > cipher suite? I see no reason to see why one should not evaluate EAP-TLS as being other containing a valid TLS protocol run. While RFC 2716 is marked experimental, I see no non-standard uses of TLS. The custom key derivation is in the EAP-TLS layer, assumes access to the master_secret and nonces in much the same way as NSA/Eric are proposing in current standards work on PRFs, here. The derivation is not part of the SSL security state. So, upon change cipher spec selecting the null ciphersuite, we know this has no impact on the EAP-TLS key derivation for the per-connection keys/ivs/secrets. It does however set the mechanism requirements for the PPP peer, when then negotiating ECP - if required. So, when EAP-TLS simply do mutual auth, not requiring any ECP SA session keys, do folks negotiate the NULL ciphersuite, or do they negotiate the RSA ciphersuite and then just ignore the rule carrying forward the TLS Connection state to the ECP state? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 30 14:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kHS-00044z-4N; Sat, 30 Dec 2006 14:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kHQ-00044u-Ij for tls@ietf.org; Sat, 30 Dec 2006 14:54:08 -0500 Received: from bay0-omc3-s4.bay0.hotmail.com ([65.54.246.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0kHP-0000fq-4n for tls@ietf.org; Sat, 30 Dec 2006 14:54:08 -0500 Received: from hotmail.com ([65.54.174.78]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 11:54:06 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 11:54:06 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV6.phx.gbl with DAV; Sat, 30 Dec 2006 19:54:04 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sat, 30 Dec 2006 11:54:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 19:54:06.0577 (UTC) FILETIME=[438C8E10:01C72C4C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [TLS] charter comparisons, providing wider rationale for GSSAPI 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 If I look at IETF as a whole, we have arguably deviated from the proposed http://lists.w3.org/Archives/Public/ietf-tls/1996JanMar/0001.html On the one hand we have successfully borrowed from kerberos some key management techniques, from the wireless world we borrowed a little PSK, and may yet be borrowing some more from GSS_API tokens & MISSI wrapping mechanism. We obviously borrowed from PKIX and its long line of forbears, though its "NR control" monster looms, threateningly. Politics has evidently agitated against more fundamental shifts, to the models of SRP, however, On the other hand, we experiment with EAP-TLS, where the handshake is used as a "general purpose authentication" mechanism by PPP - which is not "above the transport layer" and may exhibit "inappropriate generalization". If one contrasts EAL-TLS with the originally-proposed charter, however, it's use offers tribute to the SSL architecture! It features tuned message pipelining, connectionless fragmentation handling, custom key derivation, and more. This could all have been specified much more cleanly, within the architcture, but presumably doctrine got in the way. One cannot claim that PPP EAP is competing with the security architecture of IPSEC/ISAKMP and, despite "inappropriate" generalization of the security handshake and the ciphersuite negotiation, it is consistent with "secure IP is outside the scope...". That EAP-TLS even finds itself playing at the link layer is a bid sad, for the internet security architecture and its designers' judgments. If we step back, however, what is perhaps missing still is for GSS_API to now complete Tajer's final mission statement, and specify "SSL token exchange" as an alternative handshake-mechanism, registered using GSSAPI norms. If SSL adopts GSS-API's negotiation of opaque tokens, there could be a valuable reciprocity - where GSS-API enables other applications to use the SSL handshake as a single (negotiable) mechanism - regularizing what was done essentially in EAP-TLS. I think this would be supported the MISSI misson, too, moving use slowly towards the additional benefits of hardware assurance engineering. I don't like GSSAPI, technically; never have, personally; it always reminded me of the Nortel/X.509 authentication framework for layer-independent peer-entity "strong authentication". But, in the IETF tradition, the move I hint at would be more than technically possible; it would be politically appropriate. Just as EAP-TLS was done outside TLS WG, this work might be done similarly beyond, in a nuveau GSSAPI-related work item, if it struggles to get adopted, here. ----- Original Message ----- From: To: Sent: Friday, December 29, 2006 6:23 PM Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13 > >> (as FIPS 800-56B drafts are not available to the likes of me.) > > > I've been attempting to deconstruct what I understand NIST's position on > next generation RSA ciphersuites to be (from what I assume 800-56B to > say):- > > Based on the way 800-56A discusses the role of RSA (or other) key > transport. > > One uses DH in the users' national identity cards to agree a random > secret, which has the important property of "bi-lateral key confirmation" > implicit to the math of the DH/KEA etc. This agreement process may include > certain DH ephemerals in addition to statics, and a UKM nonce. This > process > satisfies the writer-to-reader rules. > > One may use RSA as an IK to transport to several parties the "secret" > value to > the authorized HSMs associated with one or more user (e.g. one's TPM-based > SSL CSP, > or a broadcast community of HSMs). The crypto device uses a > parameterized-KDF to > transform the value into a KEK, which unwraps the keying materials (and > mac secrets) > used in the SSL HSMs. Presumably, the KDF enforces TPM assurance controls, > preventing > key derivation when the secret is not assured to be from authorized id > cards (validated > using "tri-lateral key confirmation" using some unstated method (e.g. HSM > certs)). > > "Key confirmation" would have to be trilateral, if there is key > confirmation > by a "third party" - the community of authorized crypto devices. > > The final KDF (per connection) in SSL finished protocol takes into account > the roles > of the 2 or more SSL parties, currently hashes of the terms "client" and > "server" > > ------------ > > For fun one can extrapolate, doctrinally:- > > One can define a role for TLS Evidence, which exist to audit such > handshakes, using > a dig sig of the handshake hashes (and store the handshake plaintexts). > Presumably, the router/ISP can enforce policy to (a) interdict certain > flows (b) record > certain auditable handshake plaintexts. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 30 15:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kxI-0000El-BT; Sat, 30 Dec 2006 15:37:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0kxG-0000Eg-WF for tls@ietf.org; Sat, 30 Dec 2006 15:37:23 -0500 Received: from bay0-omc1-s35.bay0.hotmail.com ([65.54.246.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0kxF-00006Y-Lr for tls@ietf.org; Sat, 30 Dec 2006 15:37:22 -0500 Received: from hotmail.com ([65.54.174.86]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 12:37:21 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 12:37:20 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV14.phx.gbl with DAV; Sat, 30 Dec 2006 20:37:16 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sat, 30 Dec 2006 12:37:31 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 20:37:20.0994 (UTC) FILETIME=[4DF12C20:01C72C52] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [TLS] update for tls- psk-null? 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="===============1274589774==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1274589774== Content-Type: multipart/alternative; boundary="----=_NextPart_000_020F_01C72C0F.45D6B8E0" This is a multi-part message in MIME format. ------=_NextPart_000_020F_01C72C0F.45D6B8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Procedurally, I don't support = http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-03.txt. I think it should be slightly rewritten, declared to be a retrospective = "update" to [TLS-PSK]. This would=20 properly contextualize the material in the I-D, while achieving the = stated goal of the current I-D ("augment"). Consider this, and consider withdrawing it from the RFC Editor queue. = The adequacy of the augmented ciphersuites (how many implementations, etc) can then be = evaluated as=20 the TLS-PSK gets evaluated in its own standards track progress. ------=_NextPart_000_020F_01C72C0F.45D6B8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Procedurally, I don=92t support http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-03.txt=
 
I think it should be slightly rewritten, declared to be a = retrospective=20 "update" to [TLS-PSK]. This would
properly contextualize the material in the I-D, while achieving the = stated=20 goal of the current I-D ("augment").
 
Consider this, and consider withdrawing it from the RFC Editor = queue. The=20 adequacy of
the augmented ciphersuites (how many implementations,  etc) = can then=20 be evaluated as
the TLS-PSK gets evaluated in its own standards track=20 progress.
------=_NextPart_000_020F_01C72C0F.45D6B8E0-- --===============1274589774== 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 --===============1274589774==-- From tls-bounces@lists.ietf.org Sat Dec 30 16:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ldZ-0004Hl-Mr; Sat, 30 Dec 2006 16:21:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ldX-0004Fe-Il for tls@ietf.org; Sat, 30 Dec 2006 16:21:03 -0500 Received: from bay0-omc2-s25.bay0.hotmail.com ([65.54.246.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ldW-0000Hq-RI for tls@ietf.org; Sat, 30 Dec 2006 16:21:03 -0500 Received: from hotmail.com ([65.54.174.89]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 13:21:02 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 13:21:02 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV17.phx.gbl with DAV; Sat, 30 Dec 2006 21:20:59 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sat, 30 Dec 2006 13:21:14 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 21:21:02.0115 (UTC) FILETIME=[68407F30:01C72C58] X-Spam-Score: 0.2 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: Subject: [TLS] TLS 1.2 draft comments 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="===============0955568471==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0955568471== Content-Type: multipart/alternative; boundary="----=_NextPart_000_021F_01C72C15.61486BE0" This is a multi-part message in MIME format. ------=_NextPart_000_021F_01C72C15.61486BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Inline comments, for 7 fragments of the I-D:- 1. - The connection is private. Symmetric cryptography is used for data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption. There are errors both technical and semantic in the above. Fortezza = connections don't have unique keys per connection. We also need to stop including = within 'key' objects such as "mac secrets." Furthermore, the secret may always not be "negotiated" by TLS. Furthermore, if the Record = Protocol can be used without encryption, we can hardly have the privacy asserted in the topic sentence: without encryption, its hard to get the data origin authentication of the TLS application messages that allows for=20 expressing the very expectation of pairwise privacy! 2. - The connection is reliable. Message transport includes a = message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters. Keep the point about RP can operate without a MAC, strike=20 the general qualifier. Either one can or cannot...operate without=20 MacTags. We readers don't need protocol design advice from TLS WG=20 stuffed into an interoperability spec, thanks! 3. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys While we are at it, lets get this accurate."One such encapsulated = protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate a __ciphersuite, key, and varios secrets.__" If I argue = with myself, the word negotiate should really become "agree". In combination with the first use of the ciphersuite and keys, the final KDF executes an "agreement" between the named parties roles, as to those objects. One is forced to (I) use, (2) rely, and (3) agree, in the final protocol. 4. The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers. how about: The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers __in order to establish appropriate = assurance for the key exchange component of a ciphersuite.__" 5. The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection. How about: The negotiation of a shared secret is secure: the negotiated secret is unavailable except to the server and client, each party = can confirm the other possesses the secret, and for any authenticated connection the secret cannot be _obtained from the wire_ , even = by an attacker who can place himself in the middle of the connection. 6. One advantage of TLS is that it is application protocol independent. Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. To address EAP-TLS session resumption rules and TLSPSK rules on = self-signed certs etc:=20 the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of _or below_ TLS. 7. Concerning section 1.1: " - Allow the client to indicate which hash functions it supports. - Allow the server to indicate which hash functions it supports - Addition of support for authenticated encryption with additional data modes." distinguish indicating hash functions, from mac functions. hash = functions used in securing the handshake are not the same as mac functions used in the = record-layer. Without reading further, I don't know which are being referred to in this = summary. I don't know what "authenticated encryption" is, only that support for = it has been added. Apparently, it has "data modes". Its presumably not a = confidentiality service. Its presumably not the privacy service. Its X. From the form of = the summary, it may be an X.800 mechanism, not a service. Peter. ------=_NextPart_000_021F_01C72C15.61486BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Inline comments, for 7 fragments of the I-D:-
 

1.     -  The connection is private. = Symmetric=20 cryptography is used for
       data = encryption=20 (e.g., DES [DES], RC4 [SCH], etc.). The keys=20 for
       this symmetric encryption = are=20 generated uniquely for each
       = connection=20 and are based on a secret negotiated by=20 another
       protocol (such as the = TLS=20 Handshake Protocol). The Record
       = Protocol=20 can also be used without encryption.
There are errors both technical and semantic in the above. Fortezza = connections
don=92t have unique keys per connection. We also need to stop = including=20 within
'key' objects such as "mac secrets." Furthermore, the secret
may always not be "negotiated" by TLS. Furthermore, if the Record=20 Protocol
can be used without encryption, we can hardly have the privacy=20 asserted
in the topic sentence: without encryption, its hard to get the = data
origin authentication of the TLS application messages that = allows for=20
expressing the very expectation of pairwise privacy!
 
 2.    -  The connection is reliable. = Message=20 transport includes a message
       = integrity=20 check using a keyed MAC. Secure hash functions=20 (e.g.,
       SHA, MD5, etc.) are used = for MAC=20 computations. The Record
       = Protocol can=20 operate without a MAC, but is generally only used=20 in
       this mode while another = protocol is=20 using the Record Protocol as
       a = transport=20 for negotiating security parameters.
Keep the point about  RP can operate without a MAC, strike =
the general qualifier. Either one can or cannot...operate without =
MacTags. We readers don=92t need protocol design advice from TLS WG =
stuffed  into an interoperability spec, thanks!
 
3. One such encapsulated protocol, the TLS = Handshake
  =20 Protocol, allows the server and client to authenticate each other=20 and
   to negotiate an encryption algorithm and = cryptographic=20 keys
 
While we are at it, lets get this accurate."One such encapsulated = protocol,=20 the TLS Handshake
   Protocol, allows the server and client = to=20 authenticate each other and
   to negotiate a = __ciphersuite, key,=20 and varios secrets.__" If I argue with myself,
the word negotiate should really become "agree". In = combination
with the first use of the ciphersuite and keys, the final KDF=20 executes
an "agreement" between the named parties roles, as to those = objects.=20 One
is forced to (I) use, (2) rely, and (3) agree, in the=20 final protocol.
 
 
 
4. The peer's identity can be authenticated using asymmetric,=20 or
       public key, cryptography = (e.g., RSA=20 [RSA], DSS [DSS], etc.). This
      =20 authentication can be made optional, but is generally=20 required
       for at least one of the = peers.
 
how about: The peer's identity can be authenticated using = asymmetric,=20 or
       public key, cryptography = (e.g., RSA=20 [RSA], DSS [DSS], etc.). This
      =20 authentication can be made optional, but is generally=20 required
       for at least one of the = peers=20 __in order to establish appropriate assurance for
 the key exchange component of a ciphersuite.__"
 
5. The negotiation of a shared secret is secure: the=20 negotiated
       secret is unavailable = to=20 eavesdroppers, and for any = authenticated
      =20 connection the secret cannot be obtained, even by an attacker=20 who
       can place himself in the = middle of=20 the connection.

How about: The negotiation of a shared secret is = secure:=20 the negotiated
       secret is = unavailable=20 except to the server and client, each party can confirm
       the other possesses the = secret, and=20 for any authenticated
       connection = the=20 secret cannot be _obtained from the wire_ , even by an attacker=20 who
       can place himself in the = middle of=20 the connection.
 
 
6. One advantage of TLS is that it is application protocol=20 independent.
   Higher level protocols can layer on top of = the TLS=20 Protocol
   transparently. The TLS standard, however, does = not=20 specify how
   protocols add security with TLS; the = decisions on=20 how to initiate TLS
   handshaking and how to interpret the = authentication certificates
   exchanged are left up to the = judgment of the designers and
   implementors of protocols = which=20 run on top of TLS.

To address EAP-TLS session resumption rules = and TLSPSK=20 rules on self-signed certs etc:
   the decisions on how to initiate TLS
  =20 handshaking and how to interpret the authentication = certificates
  =20 exchanged are left up to the judgment of the designers = and
  =20 implementors of protocols which run on top of _or below_ TLS.
 
 
7. Concerning section 1.1:
 
 
"     - Allow the client to indicate which hash = functions it supports.

     - Allow the = server to=20 indicate which hash functions it = supports

     -=20 Addition of support for authenticated encryption with=20 additional
     data modes."
 
distinguish indicating hash functions, from mac functions. hash = functions=20 used in securing
the handshake are not the same as mac functions used in the = record-layer.=20 Without
reading further, I don=92t know which are being referred to in this = summary.
 
I don=92t know what "authenticated encryption" is, only that = support for it=20 has
been added. Apparently, it has "data modes". Its presumably not a=20 confidentiality
service. Its presumably not the privacy service. Its X. From the = form of=20 the
summary, it may be an X.800 mechanism, not a service.
 
Peter.
------=_NextPart_000_021F_01C72C15.61486BE0-- --===============0955568471== 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 --===============0955568471==-- From tls-bounces@lists.ietf.org Sat Dec 30 17:11:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mPR-00024b-8z; Sat, 30 Dec 2006 17:10:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0mPP-00024W-Q7 for tls@ietf.org; Sat, 30 Dec 2006 17:10:31 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0mPP-0002QO-7m for tls@ietf.org; Sat, 30 Dec 2006 17:10:31 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 189761CC61; Sat, 30 Dec 2006 14:09:14 -0800 (PST) To: Subject: Re: [TLS] TLS 1.2 draft comments References: From: EKR Date: Sat, 30 Dec 2006 14:09:13 -0800 In-Reply-To: (home pw's message of "Sat, 30 Dec 2006 13:21:14 -0800") Message-ID: <868xgp594m.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Inline comments, for 7 fragments of the I-D:- > > > 1. - The connection is private. Symmetric cryptography is used for > data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for > this symmetric encryption are generated uniquely for each > connection and are based on a secret negotiated by another > protocol (such as the TLS Handshake Protocol). The Record > Protocol can also be used without encryption. > > There are errors both technical and semantic in the above. Fortezza connections > don't have unique keys per connection. We also need to stop including within > 'key' objects such as "mac secrets." Furthermore, the secret > may always not be "negotiated" by TLS. Furthermore, if the Record Protocol > can be used without encryption, we can hardly have the privacy asserted > in the topic sentence: without encryption, its hard to get the data > origin authentication of the TLS application messages that allows for > expressing the very expectation of pairwise privacy! > 2. - The connection is reliable. Message transport includes a message > integrity check using a keyed MAC. Secure hash functions (e.g., > SHA, MD5, etc.) are used for MAC computations. The Record > Protocol can operate without a MAC, but is generally only used in > this mode while another protocol is using the Record Protocol as > a transport for negotiating security parameters. > > Keep the point about RP can operate without a MAC, strike > the general qualifier. Either one can or cannot...operate without > MacTags. We readers don't need protocol design advice from TLS WG > stuffed into an interoperability spec, thanks! > > 3. One such encapsulated protocol, the TLS Handshake > Protocol, allows the server and client to authenticate each other and > to negotiate an encryption algorithm and cryptographic keys > > While we are at it, lets get this accurate."One such encapsulated protocol, the TLS Handshake > Protocol, allows the server and client to authenticate each other and > to negotiate a __ciphersuite, key, and varios secrets.__" If I argue with myself, > the word negotiate should really become "agree". In combination > with the first use of the ciphersuite and keys, the final KDF executes > an "agreement" between the named parties roles, as to those objects. One > is forced to (I) use, (2) rely, and (3) agree, in the final protocol. > > > > 4. The peer's identity can be authenticated using asymmetric, or > public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This > authentication can be made optional, but is generally required > for at least one of the peers. > > > how about: The peer's identity can be authenticated using asymmetric, or > public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This > authentication can be made optional, but is generally required > for at least one of the peers __in order to establish appropriate assurance for > the key exchange component of a ciphersuite.__" > > 5. The negotiation of a shared secret is secure: the negotiated > secret is unavailable to eavesdroppers, and for any authenticated > connection the secret cannot be obtained, even by an attacker who > can place himself in the middle of the connection. > > How about: The negotiation of a shared secret is secure: the negotiated > secret is unavailable except to the server and client, each party can confirm > the other possesses the secret, and for any authenticated > connection the secret cannot be _obtained from the wire_ , even by an attacker who > can place himself in the middle of the connection. In general, I don't agree that your proposed changes improve the situation. This text (or minor variants) dates back to TLS 1.0 (and I suspect back to SSLv3). Does anyone else in the WG support these changes. > 6. One advantage of TLS is that it is application protocol independent. > Higher level protocols can layer on top of the TLS Protocol > transparently. The TLS standard, however, does not specify how > protocols add security with TLS; the decisions on how to initiate TLS > handshaking and how to interpret the authentication certificates > exchanged are left up to the judgment of the designers and > implementors of protocols which run on top of TLS. > > To address EAP-TLS session resumption rules and TLSPSK rules on self-signed certs etc: > the decisions on how to initiate TLS > handshaking and how to interpret the authentication certificates > exchanged are left up to the judgment of the designers and > implementors of protocols which run on top of _or below_ TLS. I don't see the virtue of this change either. TLS-PSK doesn't run below TLS and this WG is not in the business of standardizing anything EAP. > 7. Concerning section 1.1: > > > " - Allow the client to indicate which hash functions it supports. > > - Allow the server to indicate which hash functions it supports > > - Addition of support for authenticated encryption with additional > data modes." > > distinguish indicating hash functions, from mac functions. hash functions used in securing > the handshake are not the same as mac functions used in the record-layer. Without > reading further, I don't know which are being referred to in this summary. I'll put this on the list of things to change. > I don't know what "authenticated encryption" is, only that support for it has > been added. Apparently, it has "data modes". Its presumably not a confidentiality > service. Its presumably not the privacy service. Its X. From the form of the > summary, it may be an X.800 mechanism, not a service. "authenticated encryption wiht additional data". It's combined confidentiality and message integrity in a single algorithm, as is explained later in the document. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Dec 30 18:02:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nDA-0007uj-Dx; Sat, 30 Dec 2006 18:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nD8-0007uX-Ht for tls@ietf.org; Sat, 30 Dec 2006 18:01:54 -0500 Received: from bay0-omc1-s21.bay0.hotmail.com ([65.54.246.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0nCq-0007IZ-PS for tls@ietf.org; Sat, 30 Dec 2006 18:01:54 -0500 Received: from hotmail.com ([65.54.174.83]) by bay0-omc1-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 15:01:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 15:01:36 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV11.phx.gbl with DAV; Sat, 30 Dec 2006 23:01:33 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: Subject: Re: [TLS] TLS 1.2 draft comments Date: Sat, 30 Dec 2006 15:01:47 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 30 Dec 2006 23:01:36.0068 (UTC) FILETIME=[74C4A840:01C72C66] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 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: , Content-Type: multipart/mixed; boundary="===============1359267085==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1359267085== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0232_01C72C23.6D6D5DF0" This is a multi-part message in MIME format. ------=_NextPart_000_0232_01C72C23.6D6D5DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable More detailed comments, this time to do with the protocol. These = contrast with the earlier comments on the early-doc rationale and claims (that were largely = expressed in "netscape-speak",=20 and need further professionalization - before TLS gets too much higher = in the standards track) 1. signature "master secret A 48 byte secret shared between the two peers in the connection." Is it appropriate to now specify the length of this, and the client = random component of the hello nonces? If so, give a rationale for the value in light of = the fundamental PRF architecture changes going on in TLS 1.2 Right now, this all defines a particular signature for the=20 key_block =3D PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); If in TLS1.2 a PRF MAY be defined by a ciphersuite and not by the = standard, need it have the same=20 signature as the TLS PRF of old? Why should the ciphersuite not define = the types for the input values? Cannot the ciphersuite not specify the length of the master_secret 2. wrapped KEK/IVs in finished Im dubious about the new/amended means of protecting the integrity of = the handshake, in the finished process. I cannot follow all its diddling with masks, and its = impact on wrapped key/iv mechanisms when creating the first enciphered block under a server.write = key. This may be=20 more Peter problem, than spec problem. Perhaps I just have to read it a = 100 times, more. 3. timing channels vs key This is all funny on first reading, given all the recent discussion of = NULL MAC in general!: Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a timing attack on CBC padding based on the time required to compute the MAC. In order to defend against this attack, implementations MUST ensure that record processing time is essentially the same whether or not the padding is correct. =20 Mac secrets are not "key", and are therefore assured not to influence = the keyed confidentiality mechanism. if you use a secret vs key in a crypto SEF, = you get what=20 you expect. Futzing with timing is not addressing the root cause of the = design flaw. Futz with timing in the message dispatcher in the record layer = generally, not in the handling of a particular message, or use of a mechanism.=20 This all looks like a hack/workaround not a standard. 4. AEAD well at least I know what it is now, and how it relates to compression. = Ill study the background issues to this some more, offline, before commenting in detail. But, interesting to see null length MAC getting involved, again -) And, interesting to see the failure alert: "fatal bad_record_mac alert" If I now calculate 2 + 2 =3D 5, the confidentiality service based on an = AEAD mechanism is providing data origin authentication, and that DOA can control the record_layer integrity service, and the = disconnect event. Hmm. I don't like it, at first glance. Its smells wrong. I need further = rationale, in terms of function and assurance claims.=20 5. "However, you SHOULD never send data over a link encrypted with 40 = bit security unless you feel that data is worth no more than the effort required to break that encryption. I think its time for this to go... if only because we have no "links", = above the TLS. We have channels or bridges. If its kept, perhaps consider "However, you SHOULD never send data over a link encrypted with 40 bit = OR LESS security unless you feel that data is worth no more than the effort required to break that encryption. This updates the text to address ciphersuites with null confidentiality = regimes. 6. I notice case certificate_url: CertificateURL; case certificate_status: CertificateStatus; These need adding to the "major changes section of the summary". I can = not see these in RFC 4346.=20 enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; Given the description (they are part and parcel of the extension = mechanism from other docs being folded into TLS 1.2) I think I see what's going on. a) I like certificate URL, and it moves us beyond Nescape's tunnel = vision on the format of the bag of certs (forwardCertPath). The bag can now contain HSM = certs, for example from the client, where the architect has defined an "enhanced X.509 = Certificate" cert type, per=20 the rationale. It can also be a set of SAML assertions, getting us = beyond X.509's aging formats. There is a strong danger that this extension will get badly abused, I = feel. And, many military implementations are NOT going to be willy-nilly going out and = resolving URLs=20 sent by a (enhanced) handshake protocol, even if the handshake messages = are being protected by an active (assured and sufficiently strong) TLS Connection. = I can see such handshakes being used to ping a mgt port for a given user, and thus go = collect data from certified=20 repositories (over TLS), stuffing their response in caches. This is just = X.500 revisted, tho. b) What nut pushed for that OCSP stuff in certificate_status? Don't = folks understand that it was just=20 to annoy VeriSign over the Micali patents? With TLS extensions, we will be able to recover cert status from a TLS = responder, without bothering with OCSP. It can be authoritative as OCSP can be, once it = starts putting digital signatures on sets of record fragments. c) concerning SAML certs " If the protocol used is HTTP, then the HTTP server can be configured to use the Cache-Control and Expires directives described in [HTTP] to specify whether and for how long certificates or certificate chains should be cached. The TLS server is not required to follow HTTP redirects when retrieving the certificates or certificate chain. The URLs used in this extension SHOULD therefore be chosen not to depend on such redirects." I like this, as one can follow the various SAML profiles, their = redirects, session cookies; session URLs, auto postings, artifact resolution, etc. = I do feel that the SHOULD ought to be tied only to X.509 cerificate type, tho, CLEARLY, allow other cert types to specify other constraints on required processing behaviour, including none of that which is stated currently. = Then SAML2 can retrieve the certs, attributes properly etc. rather than = fuzting around with all this HTTP-land mime type stuff. I can get my SAML2 evaluated = when co-resident with a TLS protocol engine: little chance if I have to stick = HTTP=20 and MIME in the boundary, tho. More later; once I've read the back half or Eric's book, now. Peter. ------=_NextPart_000_0232_01C72C23.6D6D5DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
More detailed comments, this time to do with the protocol. These = contrast=20 with the earlier
comments on the early-doc rationale and claims  (that = were=20 largely expressed in "netscape-speak",
and need further professionalization - before TLS gets = too much higher=20 in the standards track)
 
 
1. signature
 
"master secret
       A 48 byte = secret=20 shared between the two peers in the connection."
 
Is it appropriate to now specify the length of this, and the client = random=20 component
of the hello nonces? If so, give a rationale for the value in light = of the=20 fundamental
PRF architecture changes going on in TLS 1.2
 
Right now, this all defines a particular signature for the
       key_block =3D=20 PRF(SecurityParameters.master_secret,
     &n= bsp;           &nb= sp;       =20 "key=20 expansion",
         &nbs= p;            = ;   =20 SecurityParameters.server_random=20 +
           &n= bsp;           &nb= sp; =20 SecurityParameters.client_random);
If in TLS1.2 a PRF MAY be defined by a ciphersuite and not by the = standard,=20 need it have the same
signature as the TLS PRF of old? Why should the ciphersuite not = define the=20 types for the input values? Cannot
the ciphersuite not specify the length of the master_secret
 

2. wrapped KEK/IVs in finished
 
Im dubious about the new/amended means of protecting the integrity = of the=20 handshake, in the
finished process. I cannot follow all its diddling with masks, and = its=20 impact on wrapped key/iv
mechanisms when creating the first enciphered block under a = server.write=20 key. This may be
more Peter problem, than spec problem. Perhaps I just have to read = it a 100=20 times, more.
 
3. timing channels vs key
 
This is all funny on first reading, given all the recent discussion = of NULL=20 MAC in general!:
 
 Implementation Note: Canvel et. al. [CBCTIME] have = demonstrated=20 a
       timing attack on CBC padding = based on=20 the time required to
       compute the = MAC. In=20 order to defend against this = attack,
      =20 implementations MUST ensure that record processing time=20 is
       essentially the same whether = or not=20 the padding is correct.  

Mac secrets are not "key", and are therefore assured not to = influence=20 the keyed
confidentiality mechanism.  if you use a secret vs key in = a=20 crypto SEF, you get what
you expect. Futzing with timing is not addressing the root cause of = the=20 design flaw.
 
Futz with timing in the message dispatcher in the record layer = generally, not in the handling
of a particular message, or use of a mechanism.
 
This all looks like a hack/workaround not a standard.
 
4. AEAD
 
well at least I know what it is now, and how it relates to = compression. Ill=20 study the background issues
to this some more, offline, before commenting in detail.
 
But, interesting to see null length MAC getting involved, again = -)
 
And, interesting to see the failure alert: "fatal bad_record_mac=20 alert"
 
If I now calculate 2 + 2 =3D 5, the confidentiality service based = on an AEAD=20 mechanism is providing data origin authentication,
and that DOA can control the record_layer integrity service, and = the=20 disconnect event. Hmm.
 
I don=92t like it, at first glance. Its smells wrong. I need = further=20 rationale, in terms of function and assurance claims.
 
5.  "However, you SHOULD never send data over a link encrypted = with 40=20 bit
   security unless you feel that data is worth no more = than the=20 effort
   required to break that encryption.
 
I think its time for this to go... if only because we have no = "links",=20 above the TLS. We have
channels or bridges. If its kept, perhaps consider
 
  "However, you SHOULD never send data over a link encrypted = with 40=20 bit OR LESS
   security unless you feel that data is worth = no more=20 than the effort
   required to break that = encryption.
 
This updates the text to address ciphersuites with null = confidentiality=20 regimes.
 
6. I notice
           &n= bsp; =20 case certificate_url:    =20 CertificateURL;
         =      =20 case certificate_status:  CertificateStatus;
 
These need adding to the "major changes section of the summary". I = can not=20 see these in
RFC  4346.
 
      enum=20 {
          = hello_request(0),=20 client_hello(1),=20 server_hello(2),
         = ;=20 certificate(11), server_key_exchange=20 (12),
         =20 certificate_request(13),=20 server_hello_done(14),
        = ; =20 certificate_verify(15),=20 client_key_exchange(16),
       &nb= sp; =20 finished(20), (255)
      }=20 HandshakeType;

Given the description (they are part and parcel of = the=20 extension mechanism from other docs
being folded into TLS 1.2) I think I see what's going on.
 
a) I like certificate URL, and it moves us beyond Nescape's tunnel = vision=20 on the format
of the bag of certs (forwardCertPath). The bag can now contain HSM = certs,=20 for example
from the client, where the architect has defined an "enhanced X.509 = Certificate" cert type, per
the rationale. It can also be a set of SAML assertions, getting us = beyond=20 X.509's aging formats.
 
There is a strong danger that this extension will get badly abused, = I feel.=20 And, many
military implementations are NOT going to be willy-nilly going out = and=20 resolving URLs
sent by a (enhanced) handshake protocol, even if the handshake = messages are=20 being
protected by an active (assured and sufficiently strong) TLS = Connection. I=20 can see such
handshakes being used to ping a mgt port for a given user, and thus = go=20 collect data from certified
repositories (over TLS), stuffing their response in caches. This is = just=20 X.500 revisted, tho.
b) What nut pushed for that OCSP stuff in certificate_status? = Don=92t folks=20 understand that it was just
to annoy VeriSign over the Micali patents?
 
With TLS extensions, we will be able to recover cert status from a = TLS=20 responder, without
bothering with OCSP. It can be authoritative as OCSP can be, once = it starts=20 putting
digital signatures on sets of record fragments.
 
 
c) concerning SAML certs
 
  " If the protocol used is HTTP, then the HTTP server = can be=20 configured
   to use the Cache-Control and Expires = directives=20 described in [HTTP]
   to specify whether and for how long=20 certificates or certificate
   chains should be=20 cached.

   The TLS server is not required to follow = HTTP=20 redirects when
   retrieving the certificates or = certificate=20 chain.  The URLs used in
   this extension SHOULD = therefore be=20 chosen not to depend on such
   redirects."
 
I like this, as one can follow the various SAML profiles, their=20 redirects,
session cookies; session URLs, auto postings, artifact resolution, = etc. I=20 do feel that
the SHOULD ought to be tied only to X.509 cerificate type, = tho,
 
CLEARLY, allow other cert types to specify other constraints on=20 required
processing behaviour, including none of that which is stated = currently.=20 Then
SAML2 can retrieve the certs, attributes properly etc. rather than = fuzting=20 around
with all this HTTP-land mime type stuff. I can get my SAML2 = evaluated=20 when
co-resident with a TLS protocol engine: little chance if I have to = stick=20 HTTP
and MIME in the boundary,  tho.
 
More later; once I've read the back half or Eric's book, now.
 
Peter.
------=_NextPart_000_0232_01C72C23.6D6D5DF0-- --===============1359267085== 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 --===============1359267085==-- From tls-bounces@lists.ietf.org Sat Dec 30 18:12:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nNN-00030O-4H; Sat, 30 Dec 2006 18:12:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0nNL-0002ya-Kj for tls@ietf.org; Sat, 30 Dec 2006 18:12:27 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H0nNJ-00077B-0I for tls@ietf.org; Sat, 30 Dec 2006 18:12:27 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 7744B1CC61; Sat, 30 Dec 2006 15:11:07 -0800 (PST) To: Subject: Re: [TLS] TLS 1.2 draft comments References: From: EKR Date: Sat, 30 Dec 2006 15:11:07 -0800 In-Reply-To: (home pw's message of "Sat, 30 Dec 2006 15:01:47 -0800") Message-ID: <86ac153rp0.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > 1. signature > > "master secret > A 48 byte secret shared between the two peers in the connection." > > Is it appropriate to now specify the length of this, and the client random component > of the hello nonces? If so, give a rationale for the value in light of the fundamental > PRF architecture changes going on in TLS 1.2 I don't think there really is a rationale. At some level, this is arbitrary, but the chosen values are fine ones. > Right now, this all defines a particular signature for the > key_block = PRF(SecurityParameters.master_secret, > "key expansion", > SecurityParameters.server_random + > SecurityParameters.client_random); > > If in TLS1.2 a PRF MAY be defined by a ciphersuite and not by the standard, need it have the same > signature as the TLS PRF of old? At the Montreal IETF, the consensus was to keep the signature/API the same. > 2. wrapped KEK/IVs in finished > > Im dubious about the new/amended means of protecting the integrity of the handshake, in the > finished process. I cannot follow all its diddling with masks, and its impact on wrapped key/iv > mechanisms when creating the first enciphered block under a server.write key. This may be > more Peter problem, than spec problem. Perhaps I just have to read it a 100 times, more. What section are you talking about? > 3. timing channels vs key > > This is all funny on first reading, given all the recent discussion of NULL MAC in general!: > > Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a > timing attack on CBC padding based on the time required to > compute the MAC. In order to defend against this attack, > implementations MUST ensure that record processing time is > essentially the same whether or not the padding is correct. > > Mac secrets are not "key", and are therefore assured not to influence the keyed > confidentiality mechanism. if you use a secret vs key in a crypto SEF, you get what > you expect. That's not what's going on here. I suggest you read the referenced paper for the background. > 4. AEAD > > well at least I know what it is now, and how it relates to compression. Ill study the background issues > to this some more, offline, before commenting in detail. > > But, interesting to see null length MAC getting involved, again -) > > And, interesting to see the failure alert: "fatal bad_record_mac alert" > > If I now calculate 2 + 2 = 5, the confidentiality service based on > an AEAD mechanism is providing data origin authentication, and that > DOA can control the record_layer integrity service, and the > disconnect event. Hmm. > > I don't like it, at first glance. Its smells wrong. I need further > rationale, in terms of function and assurance claims. This is a chartered work item, so I think you're going to need to make a stronger case if you want it removed. > 5. "However, you SHOULD never send data over a link encrypted with 40 bit > security unless you feel that data is worth no more than the effort > required to break that encryption. > > I think its time for this to go... if only because we have no "links", above the TLS. We have > channels or bridges. If its kept, perhaps consider > > "However, you SHOULD never send data over a link encrypted with 40 bit OR LESS > security unless you feel that data is worth no more than the effort > required to break that encryption. Well, the 40-bit algroithms have been deprecated in TLS, so this section should simply be removed. > This updates the text to address ciphersuites with null confidentiality regimes. > > 6. I notice > case certificate_url: CertificateURL; > case certificate_status: CertificateStatus; > > These need adding to the "major changes section of the summary". I can not see these in > RFC 4346. > > enum { > hello_request(0), client_hello(1), server_hello(2), > certificate(11), server_key_exchange (12), > certificate_request(13), server_hello_done(14), > certificate_verify(15), client_key_exchange(16), > finished(20), (255) > } HandshakeType; > > Given the description (they are part and parcel of the extension mechanism from other docs > being folded into TLS 1.2) I think I see what's going on. They're being moved back out again, so not really > a) I like certificate URL, and it moves us beyond Nescape's tunnel vision on the format > of the bag of certs (forwardCertPath). The bag can now contain HSM certs, for example > from the client, where the architect has defined an "enhanced X.509 Certificate" cert type, per > the rationale. It can also be a set of SAML assertions, getting us beyond X.509's aging formats. > > There is a strong danger that this extension will get badly abused, I feel. And, many > military implementations are NOT going to be willy-nilly going out and resolving URLs > sent by a (enhanced) handshake protocol, even if the handshake messages are being > protected by an active (assured and sufficiently strong) TLS Connection. I can see such > handshakes being used to ping a mgt port for a given user, and thus go collect data from certified > repositories (over TLS), stuffing their response in caches. This is just X.500 revisted, tho. > > b) What nut pushed for that OCSP stuff in certificate_status? Don't folks understand that it was just > to annoy VeriSign over the Micali patents? > > With TLS extensions, we will be able to recover cert status from a TLS responder, without > bothering with OCSP. It can be authoritative as OCSP can be, once it starts putting > digital signatures on sets of record fragments. TLS Extensions is already a Proposed Standard (RFC 3546). It just got moved into this document for editorial reasons. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 09:13:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H11Po-00058R-0W; Sun, 31 Dec 2006 09:11:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H11Pm-000574-Ii for tls@ietf.org; Sun, 31 Dec 2006 09:11:54 -0500 Received: from bay0-omc1-s14.bay0.hotmail.com ([65.54.246.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H11Pj-0003xZ-Gy for tls@ietf.org; Sun, 31 Dec 2006 09:11:54 -0500 Received: from hotmail.com ([65.54.174.90]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 06:11:50 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 06:11:50 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV18.phx.gbl with DAV; Sun, 31 Dec 2006 14:11:49 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: <868xgp594m.fsf@delta.rtfm.com> Subject: Re: [TLS] TLS 1.2 draft comments Date: Sun, 31 Dec 2006 06:12:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 31 Dec 2006 14:11:50.0891 (UTC) FILETIME=[9DBD4BB0:01C72CE5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 ----- Original Message ----- From: "EKR" To: Cc: Sent: Saturday, December 30, 2006 2:09 PM Subject: Re: [TLS] TLS 1.2 draft comments > Well, there are only two listed authors of the TLS1.2 text... and I know how Tim thinks. Lets assume no ghost authors. But, you cannot stop being IAB, EKR. The role exists to render intuitive judgment to the engineering process. 1. NONCES, KDF, EVIDENCE in TLS1.2 we need to consider what the security section says about nonce generation. Folks are known to claim that being public, they do not need a known-safe PRNG process. Id claim (a) the random component (and time) are not always public (in renegotiation) (b) the random component is specified for use in TLS PRF(s) acting as a KDF SEF and an HMAC SEF. We have to be careful, as there is assurance "feedback". The nonces protect the handshake, by generating keying material for the encryption of the finished message, which provides the integrity protection for the handshake's activation of pending state that gates the very encryption mechanism logic unit. In TLS Evidence, this is a major auditable semantic event, furthermore, and Russ evidently intends the times and nonces to become part of the uncompressed-plaintext-handshake evidence that is stored, under US data retention laws. How long is the ClientHello random anyways? One book says it stored in 28 opaque bytes, on the wire, as does http://ietf.org/rfc/rfc2246.txt. However, Section 6.1 of the I-D list connection state as: client random A 32 byte value provided by the client. Is the master_secret KDF implmented on the message from in socket queue, or from the connection state? This is important as (computations on the ) master_secret may be limited to the kernel, in the privileged ring of the CPU. The hello messages may well be in user mode space by now. Concerning 7.4.1.1 " Note: This message MUST NOT be included in the message hashes which are maintained throughout the handshake and used in the finished messages and the certificate verify message" this will need to go in the connection state maintaining the hash for TLS Evidence digital signatures. 2. CIPHERSPEC, EXPORT If the 40-bit export ciphersuites are being deprecated, will the standard maintain the rest of the strengh-limitation (export reg.) apparatus that IESG endorsed? (the changecipherspec process leading to the final derivation of keying material in non MISSI ciphersuites?) We might leave it as is, bind the traditional function(s) associated with the current value of cipherspec (1), and introduce a second value (2) - to be associated with the expected practices hereonafter. A fatal alert might be introduced for a modern implementation to react to value=1. 3. RSA CIPHERSUITES WITH NEW KDFs, LOCAL RSA CIPHERSUITES Does IETF intend to now standardize any RSA ciphersuite that define their own KDFs? Or is IETF going to limit itself to only addressing ciphersuites that use the TLS PRF as a KDF? The following text may need updating, as KDFs per ciphersuite now may or may not be using (in the handshake layer) "HMAC, keyed MACs, or secure digesting of data that is protected by a secret" "A number of operations in the TLS record and handshake layer required a keyed MAC; this is a secure digest of some data protected by a secret. Forging the MAC is infeasible without knowledge of the MAC secret. The construction we use for this operation is known as HMAC, described in [HMAC]." "In TLS the entire output of the hash function is used as the MAC tag." Interesting to see such a "govt term" in the spec. This is not typical netscape-era use of language. but the following is done well: "Note that if new cipher suites are added that do not use HMAC, and the session negotiates one of these cipher suites, this extension will have no effect." The main problem is that we have locally-defined ciphersuites these days, FORMALLY. The style of language still often assumes ciphersuite are defined in the "standard document" (e.g. "added"). The standard has to adapt - the architecture now assumes the record layer may be being protected using non-IETF-endorsed ciphersuites. 4. AEAD I still don't understand the objective for introducing AEAD. It seems to exist to provide a explicit data origin authentication service tied a confidentiality service. Unlike the DOA that traditionally provided by assured writer-to-reader confidentiality service, the implied DOA is then tied to the error signaling in and of the record layer. At second reading, I still don't like AEAD as a construction, and I still don't like the tying of a confidentiality service state to any error signaling. My first impression was correct: a lot more rationale is required, both function claims and then assurance claims/arguments. (a) can the DOA properties of non-AEAD-based confidentiality services also be tied to the (authenticated) error signaling (b) once the AEAD internal error state is detected on the read subchannel, does the standard intend the encryption mechanism in the HSM to stay active, ... so it can now be used authenticate/encrypt/DOA the fatal alert on the write subchannel? c) is it non-conforming for an AEAD cipersuite to specify a NULL MAC component? We need an authoritative reference for AEAD, not just some I-D. All this draft document chasing is like Tom chasing Jerry chasing Tom, right now. I assume with AEAD added, TLS will now have to stay at Proposed for 7 more years... till we understand its impact. 5.PKIX 7.4.2 "All certificate profiles, key and cryptographic formats are defined by the IETF PKIX working group [PKIX]." This needs to go. TLS1.2 introduces non X.509 certificates, very clearly. And, one assumes PKIX WG has to die one day, too. We don't want references to working groups in standards. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 10:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H131j-0007Ep-6l; Sun, 31 Dec 2006 10:55:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H131h-0007Ej-TR for tls@ietf.org; Sun, 31 Dec 2006 10:55:09 -0500 Received: from simmts5-srv.bellnexxia.net ([206.47.199.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H131f-0008Ki-JX for tls@ietf.org; Sun, 31 Dec 2006 10:55:09 -0500 Received: from pbo8f8e10aowa ([65.94.174.7]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061231155500.QMJB4412.simmts5-srv.bellnexxia.net@pbo8f8e10aowa>; Sun, 31 Dec 2006 10:55:00 -0500 Message-ID: <000701c72cf4$3f171c30$07ae5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: , References: <868xgp594m.fsf@delta.rtfm.com> Subject: Re: [TLS] TLS 1.2 draft comments Date: Sun, 31 Dec 2006 10:56:34 -0500 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 > 2. CIPHERSPEC, EXPORT > > If the 40-bit export ciphersuites are being deprecated, But some constrained enviroments do need 40-bit "export" ciphersuites. Besides since the NULL encryption ciphersuites exist why can't 40-bit "export" ciphersuites exist too? If needed the TLS client and server always can neogtiate a stronger encryption so why the depreciation (and what it would exactly mean to the implementations). This depreciation would also weaken WTLS statement that it is based on TLS. > will the standard > maintain > the rest of the strengh-limitation (export reg.) apparatus that IESG > endorsed? > (the changecipherspec process leading to the final derivation of keying > material in > non MISSI ciphersuites?) > > We might leave it as is, bind the traditional function(s) associated with > the > current value of cipherspec (1), and introduce a second value (2) - to be > associated with the expected practices hereonafter. A fatal alert might > be introduced for a modern implementation to react to value=1. > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 11:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H139D-0000sf-Kr; Sun, 31 Dec 2006 11:02:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H139D-0000sa-6t for tls@ietf.org; Sun, 31 Dec 2006 11:02:55 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H139B-0001eS-Rt for tls@ietf.org; Sun, 31 Dec 2006 11:02:55 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 67BEC1CC67; Sun, 31 Dec 2006 08:01:37 -0800 (PST) To: Subject: Re: [TLS] TLS 1.2 draft comments References: <868xgp594m.fsf@delta.rtfm.com> From: EKR Date: Sun, 31 Dec 2006 08:01:37 -0800 In-Reply-To: (home pw's message of "Sun, 31 Dec 2006 06:12:04 -0800") Message-ID: <86fyaw2gwu.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > 3. RSA CIPHERSUITES WITH NEW KDFs, LOCAL RSA CIPHERSUITES > > Does IETF intend to now standardize any RSA ciphersuite that define their > own KDFs? Or is IETF going to limit itself to only addressing ciphersuites > that use the TLS PRF as a KDF? > > The following text may need updating, as KDFs per ciphersuite now may > or may not be using (in the handshake layer) "HMAC, keyed MACs, or > secure digesting of data that is protected by a secret" > > "A number of operations in the TLS record and handshake layer required > a keyed MAC; this is a secure digest of some data protected by a > secret. Forging the MAC is infeasible without knowledge of the MAC > secret. The construction we use for this operation is known as HMAC, > described in [HMAC]." Yes, I'll clean this up. > 4. AEAD > > I still don't understand the objective for introducing AEAD. It seems to > exist to provide a explicit data origin authentication service tied a > confidentiality > service. I would advise you to read draft-mcgrew-auth-enc-01, which describes the rationale for this kind of primitive. > Unlike the DOA that traditionally provided by assured > writer-to-reader > confidentiality service, the implied DOA is then tied to the error > signaling in > and of the record layer. Huh? Data origin authentication failures in TLS always occured at the record layer. We're just replacing two algorithms at the record layer with one. > (a) can the DOA properties of non-AEAD-based confidentiality services > also be tied > to the (authenticated) error signaling I don't know what this means. > (b) once the AEAD internal error state is detected on the read > subchannel, does the > standard intend the encryption mechanism in the HSM to stay active, > ... so it can > now be used authenticate/encrypt/DOA the fatal alert on the write > subchannel? The behavior here is exactly like it always has been for TLS. You generate a protected MAC on the write channel and then abort. (Note that DTLS behaves differently since MAC errors are not fatal.) > c) is it non-conforming for an AEAD cipersuite to specify a NULL MAC > component? > > We need an authoritative reference for AEAD, not just some I-D. Yes. This creates a normative dependency on that I-D. > All > this draft > document chasing is like Tom chasing Jerry chasing Tom, right now. I assume > with AEAD added, TLS will now have to stay at Proposed for 7 more > years... till > we understand its impact. TLS staying at Proposed for 7 years had to do primarily with WG inertia. And the reason that 1.2 will not go to Draft is that we are making major technical changes. > 5.PKIX > > 7.4.2 "All certificate profiles, key and cryptographic formats are defined > by the IETF PKIX working group [PKIX]." > > This needs to go. TLS1.2 introduces non X.509 certificates, very > clearly. And, > one assumes PKIX WG has to die one day, too. We don't want references to > working groups in standards. The reference is to an RFC. [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 3280, April 2002. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 11:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13hW-00023O-K7; Sun, 31 Dec 2006 11:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H13hV-00022V-Pm for tls@ietf.org; Sun, 31 Dec 2006 11:38:21 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H13hU-0003UV-Fi for tls@ietf.org; Sun, 31 Dec 2006 11:38:21 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 1C86A1CC61; Sun, 31 Dec 2006 08:37:04 -0800 (PST) To: "Omirjan Batyrbaev" Subject: Re: [TLS] TLS 1.2 draft comments References: <868xgp594m.fsf@delta.rtfm.com> <000701c72cf4$3f171c30$07ae5e41@pbo8f8e10aowa> From: EKR Date: Sun, 31 Dec 2006 08:37:03 -0800 In-Reply-To: <000701c72cf4$3f171c30$07ae5e41@pbo8f8e10aowa> (Omirjan Batyrbaev's message of "Sun, 31 Dec 2006 10:56:34 -0500") Message-ID: <86slew10pc.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Omirjan Batyrbaev" writes: >> 2. CIPHERSPEC, EXPORT >> >> If the 40-bit export ciphersuites are being deprecated, > > But some constrained enviroments do need 40-bit "export" ciphersuites. I'm not aware of any such environment. Can you please name them? > Besides since the NULL encryption ciphersuites exist why can't 40-bit > "export" ciphersuites exist too? Because there's no good reason for them to exist and the key weakening primitive adds substantial complexity to the protocol. > If needed the TLS client and server always > can neogtiate a stronger encryption so why the depreciation (and what it > would exactly mean to the implementations). Here's the relevant text from 4346. So, actually, they're already deprecated. When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 13:57:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15qs-0005eR-Ek; Sun, 31 Dec 2006 13:56:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H15qr-0005eM-BH for tls@ietf.org; Sun, 31 Dec 2006 13:56:09 -0500 Received: from bay0-omc3-s15.bay0.hotmail.com ([65.54.246.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H15qp-00066g-P1 for tls@ietf.org; Sun, 31 Dec 2006 13:56:09 -0500 Received: from hotmail.com ([65.54.174.82]) by bay0-omc3-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 10:56:07 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 10:56:07 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV10.phx.gbl with DAV; Sun, 31 Dec 2006 18:56:06 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sun, 31 Dec 2006 10:56:22 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 31 Dec 2006 18:56:07.0326 (UTC) FILETIME=[542ABBE0:01C72D0D] X-Spam-Score: 0.3 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: Subject: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices 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="===============2038626776==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2038626776== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02BE_01C72CCA.4EF0AC40" This is a multi-part message in MIME format. ------=_NextPart_000_02BE_01C72CCA.4EF0AC40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some more comments per the call on TLS 1.2 I-D.=20 These are getting a bit more practical. 1. DSS SIGNED RSA IK=20 Is TLS 1.2 introducing the idea that DSS signed cert can contain an RSA = IK? We read that in the enhanced Certificate Request that "Certificate types rsa_sign and dss_sign SHOULD contain certificates signed with the same algorithm. However, this is not required. This is a holdover from TLS 1.0 and 1.1." Is the "holdover" that TLS 1.2 still may have to accommodate = DSSsignedRSAIKs (from earlier eras),=20 Or is the holdover the opposite: TLS1.2 MAY now process DSSsignedRSAIKs = (that wont work well with systems from earlier eras)? 2. CLIENT CERTS: ClientCertificateType, authorization spaces In summary the value encoding of each element of certificate_authorities = should be a function of certificate_types. This will help the client choose the = appropriate type of certificate (X.509 or not ), when populating the value of = certCertChainType=20 when using certificate URL message. Background follows in a) and b) a) TLS 1.0 ClientCertificateType removed some SSL3 enum values. TLS1.1 = put them back (along with the scheme denoting ranges of types, each controlled by different = authorities (including private)). In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding = of the DNs. The field has to=20 be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the = format/encoding is defined=20 by the ClientCertificateType). (Tell Peter DER, and he assumes he has to = type check it, now, as DER, raising an exception if it fails the encoding rules for each attribute = type's value; this is a lot of code!) Given certificate URL in TLS1.2, the CA field need refer to X.509 no = longer. Thus, the pre-TLS1.1 convention should be put back: DistinguisedName values can be encoded in a manner = suitable for the cert type.=20 (In the SAML world, we may encode a DN as a URI, for example.) b) Given the major change in semantics due to TLS for these CA DNs = (which got more and more onerous, if you chart them), the DN is no longer cert selector: it's a = signal of "desired authorization space". Given this change, we even more clearly need non-DER-encoded DNs for = CAs. SAML2 and WS-Fed Federation=20 ids constitute the type of authorization spaces being implied, and don't = get described in terms of=20 DER-encoded DNs. Whilst they use X.509 certs behind the scenes, the = trust model underlying these authorization spaces is unlinked from KMI, PKI, CA roots etc. I don't mind keeping the name certificate_authorities. its just a field = name in a spec; it doesn't go on the wire. 3. REGISTERING CertChainType enum { individual_certs(0), pkipath(1), (255) } CertChainType; Can we do for CertChainType what was done earlier, for = ClientCertificateType=20 I.e. SUGGESTED TEXT OF " CertChainType values are divided into three = groups: 1. Values from 0 (zero) through 63 decimal (0x3F) = inclusive are reserved for IETF Standards Track protocols. 2. Values from 64 decimal (0x40) through 223 decimal = (0xDF) inclusive are reserved for assignment for non-Standards Track methods. 3. Values from 224 decimal (0xE0) through 255 decimal = (0xFF) inclusive are reserved for private use. Additional information describing the role of IANA in the allocation of CertChainType code points is described in Section 11." ------=_NextPart_000_02BE_01C72CCA.4EF0AC40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Some more comments per the call on TLS 1.2 I-D.
 
These are getting a bit more practical.
 
 
1. DSS SIGNED RSA IK
 
Is TLS 1.2 introducing the idea that DSS signed cert can contain an = RSA=20 IK?
 
We read that in the enhanced Certificate Request that
 
         &n= bsp;=20 "Certificate types rsa_sign and dss_sign SHOULD=20 contain
          =20 certificates signed with the same algorithm. However, this=20 is
           not = required.=20 This is a holdover from TLS 1.0 and 1.1."
 
Is the "holdover" that TLS 1.2 still may have to accommodate=20 DSSsignedRSAIKs (from
earlier eras),
 
Or is the holdover the opposite: TLS1.2 MAY now process = DSSsignedRSAIKs=20 (that wont work
well with systems from earlier eras)?
 
 
2. CLIENT CERTS: ClientCertificateType, authorization = spaces
In summary the value encoding of each element of = certificate_authorities=20 should
be a function of certificate_types. This will help the client = choose the=20 appropriate
type of certificate (X.509 or not ), when populating the value of=20 certCertChainType
when using certificate URL message.
 
Background follows in a) and b)
 
 
a) TLS 1.0 ClientCertificateType removed some SSL3 enum values. = TLS1.1 put=20 them back (along with
the scheme denoting ranges of types, each controlled by different=20 authorities (including private)).
 
In TLS 1.1 however, we suddenly get constrained in 2006 re the = encoding of=20 the DNs. The field has to
be DER encoded, now. In SSL and TLS1.0 it was an opaque type = (I.e. the=20 format/encoding is defined
by the ClientCertificateType). (Tell Peter DER, and he assumes he = has to=20 type check it, now, as DER,
raising an exception if it fails the encoding rules for each = attribute=20 type's value; this is a lot of code!)
 
Given certificate URL in TLS1.2, the CA field need refer to X.509 = no=20 longer. Thus, the pre-TLS1.1 convention
should be put back: DistinguisedName values can be encoded in = a manner=20 suitable for the cert type.
(In the SAML world, we may encode a DN as a URI, for = example.)
 
b) Given the major change in semantics due to TLS for these CA DNs = (which=20 got more and more
onerous, if you chart them), the DN is no longer cert selector: = it=92s a=20 signal of "desired authorization space".
Given this change, we even more clearly need non-DER-encoded DNs = for CAs.=20 SAML2 and WS-Fed Federation
ids constitute the type of authorization spaces being implied, = and=20 don=92t get described in terms of
DER-encoded DNs. Whilst they use X.509 certs behind the scenes, the = trust=20 model underlying
these authorization spaces is unlinked from KMI, PKI, CA roots = etc.
 
I don=92t mind keeping the name certificate_authorities. its just a = field=20 name in a spec; it doesn=92t
go on the wire.
 
3. REGISTERING CertChainType
 
      enum=20 {
           &n= bsp;=20 individual_certs(0), pkipath(1),=20 (255)
         }=20 CertChainType;
Can we do for CertChainType what was done earlier, for=20 ClientCertificateType
 
I.e. SUGGESTED TEXT OF " CertChainType values are divided into = three=20 groups:

         &nbs= p;   =20 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive=20 are
           =      =20 reserved for IETF Standards Track=20 protocols.

         &= nbsp;   =20 2. Values from 64 decimal (0x40) through 223 decimal=20 (0xDF)
          &nb= sp;     =20 inclusive are reserved for assignment for=20 non-Standards
         &n= bsp;      =20 Track=20 methods.

         &nb= sp;   =20 3. Values from 224 decimal (0xE0) through 255 decimal=20 (0xFF)
          &nb= sp;     =20 inclusive are reserved for private=20 use.

           = Additional information describing the role of IANA in=20 the
           = allocation=20 of CertChainType code points is=20 described
          = in=20 Section 11."

------=_NextPart_000_02BE_01C72CCA.4EF0AC40-- --===============2038626776== 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 --===============2038626776==-- From tls-bounces@lists.ietf.org Sun Dec 31 14:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1632-0000p1-Rw; Sun, 31 Dec 2006 14:08:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1632-0000ow-36 for tls@ietf.org; Sun, 31 Dec 2006 14:08:44 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H162v-0000So-N1 for tls@ietf.org; Sun, 31 Dec 2006 14:08:44 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 5AB141CC61; Sun, 31 Dec 2006 11:07:21 -0800 (PST) To: Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices References: From: EKR Date: Sun, 31 Dec 2006 11:07:21 -0800 In-Reply-To: (home pw's message of "Sun, 31 Dec 2006 10:56:22 -0800") Message-ID: <86ac1328ba.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > 1. DSS SIGNED RSA IK > > Is TLS 1.2 introducing the idea that DSS signed cert can contain an RSA IK? > > We read that in the enhanced Certificate Request that > > "Certificate types rsa_sign and dss_sign SHOULD contain > certificates signed with the same algorithm. However, this is > not required. This is a holdover from TLS 1.0 and 1.1." > > > Is the "holdover" that TLS 1.2 still may have to accommodate DSSsignedRSAIKs (from > earlier eras), > > Or is the holdover the opposite: TLS1.2 MAY now process DSSsignedRSAIKs (that wont work > well with systems from earlier eras)? The former. > 2. CLIENT CERTS: ClientCertificateType, authorization spaces > > In summary the value encoding of each element of certificate_authorities should > be a function of certificate_types. This will help the client choose the appropriate > type of certificate (X.509 or not ), when populating the value of certCertChainType > when using certificate URL message. > > Background follows in a) and b) > > > a) TLS 1.0 ClientCertificateType removed some SSL3 enum > values. TLS1.1 put them back (along with the scheme denoting ranges > of types, each controlled by different authorities (including > private)). Well, sort of. TLS 1.0 had: enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), (255) } ClientCertificateType; However, people were using other values. Those values are not standardized by the IETF. So, we added them to the enum marked RESERVED to avoid reuse. > In TLS 1.1 however, we suddenly get constrained in 2006 re the > encoding of the DNs. The field has to be DER encoded, now. In SSL > and TLS1.0 it was an opaque type (I.e. the format/encoding is > defined by the ClientCertificateType). Not really, no. RFC 2246 indicated that DistinguishedName was derived from X509. I.e., it always had to contain a DistinguishedName. 4346 merely clarifies what was already standard practice, that it should be encoded as DER (as opposed to, say, XER). -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 14:33:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16RC-0007yl-6i; Sun, 31 Dec 2006 14:33:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16RA-0007yZ-SI for tls@ietf.org; Sun, 31 Dec 2006 14:33:40 -0500 Received: from bay0-omc1-s24.bay0.hotmail.com ([65.54.246.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H16Mr-0006eM-Ep for tls@ietf.org; Sun, 31 Dec 2006 14:29:29 -0500 Received: from hotmail.com ([65.54.174.77]) by bay0-omc1-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 11:29:12 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 11:29:13 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV5.phx.gbl with DAV; Sun, 31 Dec 2006 19:29:12 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: References: Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices Date: Sun, 31 Dec 2006 11:29:28 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 31 Dec 2006 19:29:13.0077 (UTC) FILETIME=[F3C44A50:01C72D11] X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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: , Content-Type: multipart/mixed; boundary="===============0570422784==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0570422784== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DB_01C72CCE.EEADEF50" This is a multi-part message in MIME format. ------=_NextPart_000_02DB_01C72CCE.EEADEF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In 7.4.5 certificate_types, we seem - by enumerating certain enum values = - to be limiting the values of ClientCertificateType that a server may = indicate, and thus=20 a client may "offer"=20 Surely this should be any value from ClientCertificateType, including = those from the private range!? " A list of the types of certificate types which the client = may offer. rsa_sign a certificate containing an RSA key dss_sign a certificate containing a DSS key rsa_fixed_dh a certificate signed with RSA and = containing a static DH key. dss_fixed_dh a certificate signed with DSS and = containing a static DH key " ------=_NextPart_000_02DB_01C72CCE.EEADEF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In 7.4.5 certificate_types, we seem - by enumerating certain enum = values -=20 to
be limiting the values of ClientCertificateType that a server may = indicate,=20 and thus
a client may  "offer"
 
Surely this should be any value from ClientCertificateType, = including those=20 from
the private range!?

"           A = list of=20 the types of certificate types which the client=20 may
          =20 offer.
          &nb= sp;  =20 rsa_sign        a certificate = containing an=20 RSA=20 key
           =   =20 dss_sign        a certificate = containing a=20 DSS=20 key
           =   =20 rsa_fixed_dh    a certificate signed with RSA and=20 containing
          = ;            =        =20 a static DH=20 key.
           = ;  =20 dss_fixed_dh    a certificate signed with DSS and=20 containing
          = ;            =        =20 a static DH key
"
 
------=_NextPart_000_02DB_01C72CCE.EEADEF50-- --===============0570422784== 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 --===============0570422784==-- From tls-bounces@lists.ietf.org Sun Dec 31 14:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16ou-0005tG-NN; Sun, 31 Dec 2006 14:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H16os-0005t7-OC for tls@ietf.org; Sun, 31 Dec 2006 14:58:10 -0500 Received: from bay0-omc3-s35.bay0.hotmail.com ([65.54.246.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H16oq-00062v-SP for tls@ietf.org; Sun, 31 Dec 2006 14:58:10 -0500 Received: from hotmail.com ([65.54.174.75]) by bay0-omc3-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 11:58:08 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 11:58:08 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV3.phx.gbl with DAV; Sun, 31 Dec 2006 19:58:03 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices Date: Sun, 31 Dec 2006 11:58:19 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 31 Dec 2006 19:58:08.0211 (UTC) FILETIME=[FDFCBA30:01C72D15] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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: , Content-Type: multipart/mixed; boundary="===============1943840937==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1943840937== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EC_01C72CD2.F6630FB0" This is a multi-part message in MIME format. ------=_NextPart_000_02EC_01C72CD2.F6630FB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Concerning 7.4.5. Certificate request "A list of the distinguished names of acceptable certificate authorities. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used both to describe known roots and a desired authorization space. If the certificate_authorities list is empty then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary." So, what does this all really mean, just staying within the traditional = PKI world? Rather than send a simple list of root DNs, we are now sending 2 = different signals? For a list of 4 DNs, Are we saying that element 1 might point to a root, = but 2 to=20 a CA within that root's certification domain? And then for 3 and 4 = something similar for a different certification domain? If I understand what is being specified: 1. its up to the client to figure out which DN has which semantics; = there is NO ordering =20 2. its up to the client to figure out that a subordinate CA is indeed = controlled by some root=20 (e.g. name hierarchy, following hash chaining in PKIX cert extensions) 3. an intended model for "authorization space" (a subordinate CA) might = be: the CA for=20 ;organizational' certs, vs the CA for "individual" certs (in a military = messaging system context).=20 However, this has nothing to do with "authorization certs", SAML = authorization assertions, etc. This text has been in this section since TLS 1.0. So, Is this actually = used widely in this 2 signal=20 mode...as it seems it MUST? I'm guessing at its intended application, in 3. The text in the standard = on this=20 is woefully inadequate. It could mean something entirely different: = identify the=20 BridgeCA as root, and then the Agency CA as "authorization space". This needs expanding. ------=_NextPart_000_02EC_01C72CD2.F6630FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Concerning 7.4.5. Certificate request
           "A = list of the=20 distinguished names of acceptable=20 certificate
         &nbs= p;=20 authorities. These distinguished names may specify a=20 desired
          =20 distinguished name for a root CA or for a subordinate=20 CA;
           = thus, this=20 message can be used both to describe known=20 roots
           = and a=20 desired authorization space. If=20 the
          =20 certificate_authorities list is empty then the client=20 MAY
           send = any=20 certificate of the=20 appropriate
         &nbs= p;=20 ClientCertificateType, unless there is some=20 external
           = arrangement to the contrary."
 
So, what does this all really mean, just staying within the=20 traditional PKI world?
 
Rather than send a simple list of root DNs, we are now sending 2 = different=20 signals?
 
For a list of 4 DNs, Are we saying that element 1 might point = to a=20 root, but 2 to
a CA within that root's certification domain? And then for 3 and 4=20 something
similar for a different certification domain?
 
If I understand what is being specified:
 
1. its up to the client to figure out which DN has which semantics; = there=20 is NO ordering  
 
2. its up to the client to figure out that a subordinate CA is = indeed=20 controlled by some root
(e.g. name hierarchy, following hash chaining in PKIX cert=20 extensions)
 
3. an intended model for "authorization space" (a subordinate CA) = might be:=20 the CA for
;organizational' certs, vs the CA for "individual" certs (in a = military messaging system context).
However, this has nothing to do with "authorization certs", SAML=20 authorization assertions, etc.
 
This text has been in this section since TLS 1.0.  So, Is this = actually used widely in this 2 signal
mode...as it seems it MUST?
 
I'm guessing at its intended application, in 3. The text in the = standard on=20 this
is woefully inadequate. It could mean something entirely different: = identify the
BridgeCA as root, and then the Agency CA as "authorization = space".
 
This needs expanding.
 
------=_NextPart_000_02EC_01C72CD2.F6630FB0-- --===============1943840937== 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 --===============1943840937==-- From tls-bounces@lists.ietf.org Sun Dec 31 15:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H17Z3-0001GQ-5f; Sun, 31 Dec 2006 15:45:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H17Z1-0001GJ-Nn for tls@ietf.org; Sun, 31 Dec 2006 15:45:51 -0500 Received: from bay0-omc3-s26.bay0.hotmail.com ([65.54.246.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H17Xd-0003wG-Ov for tls@ietf.org; Sun, 31 Dec 2006 15:44:27 -0500 Received: from hotmail.com ([65.54.174.86]) by bay0-omc3-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 12:44:25 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 12:44:24 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV14.phx.gbl with DAV; Sun, 31 Dec 2006 20:44:22 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "EKR" References: <86ac1328ba.fsf@delta.rtfm.com> Date: Sun, 31 Dec 2006 12:44:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 31 Dec 2006 20:44:24.0905 (UTC) FILETIME=[75069B90:01C72D1C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org Subject: [TLS] server auth on renegoiate 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 disagreed earlier on whether the spec required that a (std) RSA cipersuite MUST send a certificate. I argued that it wasn't necessary for the case of renegotiate given the DAO of the confidentiality service; and we disagreed on that rationale, even. So, I've been attempting to accommodate:- which would the list prefer:- (a) a self-signed (static) cert (b) an unsigned (static) cert (c) a message with no content I feel very comfortable with (a) for re-negotiation scenarios, within a decent ciphersuite. I can quote Eric's book (p.220), at least: "However, its is of course possible to use self-signed (and hence unverified) certificates and get the effect of an anonymous connection with any SSL mode." If I recall, TLS-PSK also mentions the self-signed cert practice. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 16:16:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1820-0000Bj-TN; Sun, 31 Dec 2006 16:15:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H181z-0000A8-Vx for tls@ietf.org; Sun, 31 Dec 2006 16:15:48 -0500 Received: from simmts7-srv.bellnexxia.net ([206.47.199.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H17o0-0000zh-P4 for tls@ietf.org; Sun, 31 Dec 2006 16:01:22 -0500 Received: from pbo8f8e10aowa ([65.94.174.7]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061231210110.XIID25276.simmts7-srv.bellnexxia.net@pbo8f8e10aowa>; Sun, 31 Dec 2006 16:01:10 -0500 Message-ID: <002701c72d1f$0441dd90$07ae5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "EKR" References: <868xgp594m.fsf@delta.rtfm.com><000701c72cf4$3f171c30$07ae5e41@pbo8f8e10aowa> <86slew10pc.fsf@delta.rtfm.com> Subject: Re: [TLS] TLS 1.2 draft comments Date: Sun, 31 Dec 2006 16:02:43 -0500 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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 see inserted: Subject: Re: [TLS] TLS 1.2 draft comments > "Omirjan Batyrbaev" writes: > > >> 2. CIPHERSPEC, EXPORT > >> > >> If the 40-bit export ciphersuites are being deprecated, > > > > But some constrained enviroments do need 40-bit "export" ciphersuites. > > I'm not aware of any such environment. Can you please > name them? Some embeded systems, for example cheap EPC RFID tag. The Generation 2 tag today does not even have a cryptographic hash function, etc. > > > > Besides since the NULL encryption ciphersuites exist why can't 40-bit > > "export" ciphersuites exist too? > > Because there's no good reason for them to exist and the key > weakening primitive adds substantial complexity to the > protocol. > > > > If needed the TLS client and server always > > can neogtiate a stronger encryption so why the depreciation (and what it > > would exactly mean to the implementations). > > Here's the relevant text from 4346. So, actually, they're already > deprecated. > > When SSLv3 and TLS 1.0 were designed, the United States restricted > the export of cryptographic software containing certain strong > encryption algorithms. A series of cipher suites were designed to > operate at reduced key lengths in order to comply with those > regulations. Due to advances in computer performance, these > algorithms are now unacceptably weak, and export restrictions have > since been loosened. TLS 1.1 implementations MUST NOT negotiate > these cipher suites in TLS 1.1 mode. However, for backward > compatibility they may be offered in the ClientHello for use with TLS > 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the > server did not choose one of these cipher suites during the > handshake. These ciphersuites are listed below for informational > purposes and to reserve the numbers. > > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 16:22:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H188Q-0002li-Sf; Sun, 31 Dec 2006 16:22:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H188O-0002lc-TE for tls@ietf.org; Sun, 31 Dec 2006 16:22:24 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H188M-0006Xk-3b for tls@ietf.org; Sun, 31 Dec 2006 16:22:24 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id EBBC71CC61; Sun, 31 Dec 2006 13:21:05 -0800 (PST) To: "Omirjan Batyrbaev" Subject: Re: [TLS] TLS 1.2 draft comments References: <868xgp594m.fsf@delta.rtfm.com> <000701c72cf4$3f171c30$07ae5e41@pbo8f8e10aowa> <86slew10pc.fsf@delta.rtfm.com> <002701c72d1f$0441dd90$07ae5e41@pbo8f8e10aowa> From: EKR Date: Sun, 31 Dec 2006 13:21:05 -0800 In-Reply-To: <002701c72d1f$0441dd90$07ae5e41@pbo8f8e10aowa> (Omirjan Batyrbaev's message of "Sun, 31 Dec 2006 16:02:43 -0500") Message-ID: <863b6v224e.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Omirjan Batyrbaev" writes: > see inserted: > Subject: Re: [TLS] TLS 1.2 draft comments > > >> "Omirjan Batyrbaev" writes: >> >> >> 2. CIPHERSPEC, EXPORT >> >> >> >> If the 40-bit export ciphersuites are being deprecated, >> > >> > But some constrained enviroments do need 40-bit "export" ciphersuites. >> >> I'm not aware of any such environment. Can you please > name them? > > Some embeded systems, for example cheap EPC RFID tag. The Generation 2 tag > today does not even have a cryptographic hash function, etc. The TLS 40-bit ciphersuites don't provide any advantage here. They're just the ordinary ciphers (RC4 and DES) with pre-processing to reduce the key to 40 bits of entropy. They're no faster and no smaller (gate count, memory footprint) than the ciphers they are derived from. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 17:40:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H19L0-0005Br-4j; Sun, 31 Dec 2006 17:39:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H19Ky-0005Bl-VR for tls@ietf.org; Sun, 31 Dec 2006 17:39:28 -0500 Received: from bay0-omc1-s7.bay0.hotmail.com ([65.54.246.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H19Kx-0000ZR-LC for tls@ietf.org; Sun, 31 Dec 2006 17:39:28 -0500 Received: from hotmail.com ([65.54.174.86]) by bay0-omc1-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 14:39:26 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 14:39:26 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV14.phx.gbl with DAV; Sun, 31 Dec 2006 22:39:22 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Omirjan Batyrbaev" References: <868xgp594m.fsf@delta.rtfm.com><000701c72cf4$3f171c30$07ae5e41@pbo8f8e10aowa> <86slew10pc.fsf@delta.rtfm.com> <002701c72d1f$0441dd90$07ae5e41@pbo8f8e10aowa> Subject: Re: [TLS] TLS 1.2 draft comments Date: Sun, 31 Dec 2006 14:39:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 31 Dec 2006 22:39:26.0712 (UTC) FILETIME=[86D2C780:01C72D2C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Its true, they have gone, as has the calculation. And I didn't even notice. Wow. After:- All that crap about no RSA standard (1986 Geneva, State) All that crap about LEAFs on IVs (1993 Fort Meade, NSA/NSC) All that crap about dual certs & cross-certs (1992/1994 Ottawa, CSE) All that crap about low entropy KDFs. (1995 Mountain View, Commerce) All that crap about TTP CAs enforcing key escrow (1996 935 Pennsylvania Avenue, FBI) All that crap about dual channel keying (1996 Royal Holloway, F&CWO) All that crap about Bridge CA Assurance enforcement (2000 Washington, GSA) Talk about shunting a bad policy around the agencies, to get rid of it! I mean, it was just a career killer! We need rapidly to bring back Fortezza technology back into a general purpose SSL ciphersuite: KEA and key wrapping are well worth having. Now Rumsfeld has gone, someone get DoD to put CAC firmware for javacards (and driver libraries) into the open source community, where they belong. It will go far, and will multiply. Keep the PIV stuff proprietary and controlled for now, till public confidence is higher. All we need now is dissolution of the stooge ANSI X9 RSA group, and some test vectors from NIST for RSA key transport. And, is IESG ready to have a look at moving SSL beyond Proposed, yet!? ---- The real test is of course Microsoft Windows, looking at the China distribution of Vista next month. Does it conform (I.e. refuse to negotiate export ciphers, with a TLS 1.1 client) Does it conform (I.e. perform negotiation with them, with a TLS 1.0 client) But, I have the highest regard for Microsoft on cryptopolicy matters. Lets wait and see how they do. ----- ----- Original Message ----- From: "Omirjan Batyrbaev" To: "EKR" Cc: ; Sent: Sunday, December 31, 2006 1:02 PM Subject: Re: [TLS] TLS 1.2 draft comments > see inserted: > Subject: Re: [TLS] TLS 1.2 draft comments >> Because there's no good reason for them to exist and the key >> weakening primitive adds substantial complexity to the >> protocol. There are lots of good reasons now to have lots of different KDFs for setting connection state! There are many dual purposes of the control technology used in export enforcement, for business & legal purposes (not just the obvious purposes of mandatory data retention, wiretapping etc). I think Ill bring back my connection-NR for TLS, where handshakes punctuate the transaction, like Russ's alerts do. With TLS Evidence also making a signature, we gets lots of assurance toys to play with and apply to a wide range of orchestrated business flows. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 18:12:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H19q7-0004Y4-9f; Sun, 31 Dec 2006 18:11:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H19q6-0004Xz-9q for tls@ietf.org; Sun, 31 Dec 2006 18:11:38 -0500 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H19q3-00031y-R3 for tls@ietf.org; Sun, 31 Dec 2006 18:11:38 -0500 Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBVNBUWO023222 for ; Sun, 31 Dec 2006 15:11:30 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JB500401V2QEM00@d1-sfbay-10.sun.com> (original mail from nelson@bolyard.com) for tls@ietf.org; Sun, 31 Dec 2006 15:11:30 -0800 (PST) Received: from [192.168.0.2] ([67.188.127.211]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JB500DWYV2ZNSDY@d1-sfbay-10.sun.com> for tls@ietf.org; Sun, 31 Dec 2006 15:11:30 -0800 (PST) Date: Sun, 31 Dec 2006 15:13:24 -0800 From: Nelson B Bolyard Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY? In-reply-to: <44D32FC2.2080606@bolyard.com> To: tls@ietf.org Message-id: <45984414.2090209@bolyard.com> Organization: Spam haters R US MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT References: <44D32FC2.2080606@bolyard.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061226 SeaMonkey/1.5a X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Last August, I wrote to this list about the lack of "MUST" in the RFCs and drafts concerning the use of error and warning alerts. That message is quoted below. I only got one reply, from Peter Gutmann. I really want to see this situation get fixed in TLS 1.2. What can I do to make that happen? Do I need to submit a draft with the suggested changes? Erik, if I send you a set of suggested changes as edits to the current 1.2 draft, will you incorporate them? OBTW, the "newer implementation" that nevre sends error alerts has been released since I wrote that first message. Can you guess what it is? Nelson B Bolyard wrote: > The existing TLS RFCs and IDs don't say that an implementation MUST send > any error alerts. > > There's lots of "will", "should", "may", but not nearly enough "MUST" > (IMO) regarding error alerts (whether fatal or not). > > > Consequently, one of the newer implementations (which I won't name here), > one with which I've been doing interoperability testing, simply NEVER sends > error alerts. When any problem occurs, it silently closes the connection > without offering any clues to the peer about why it has done so. The > developer's explanation to me for the implementation's behavior was simple: > the RFCs do not require that error alerts be sent. Sending error alerts is > simply not a MUST. Doing so is implicitly a MAY, at most. > > I think this is going to be a nightmare for trouble shooting. When a peer > system drops a TLS connection, we're going to have to rely on the ability > of the user or administrator who runs that peer to determine why it did so, > rather than relying on alerts. > > So, I put the question to the TLS WG: Is there consensus that the RFC > language should be strengthened in the next version (e.g. rfc4346-bis) > to say that the error alerts MUST be sent, and when? > > > A survey of error alert discussion in the first 40-some pages of the draft. > > Regarding close notify alerts, the existing RFC and drafts say that "each > party is required to" (why not MUST?) send a close_notify alert if no error > condition has occurred and that upon receiving a close-notify alert, the > peer MUST send one in respnse. So, close_notify alerts will get sent, > but not error alerts. > > The latest draft says that when an error alert is sent or received, the > session MUST be invalidated, but doesn't require that it be sent. > > The draft says: > "When an error is detected, the detecting party sends a > message to the other party." > I think that should be MUST SEND, but as written it's not a MUST. > > There are some "SHOULD"s in the current draft rfc4346-bis: > "The receiver MUST check this padding and SHOULD use the > bad_record_mac alert to indicate padding errors." > > I think this was intended to be understood as "MUST check, MUST send an > alert to indicate errors, and SHOULD use bad_record_mac alert when > appropriate". But as written, it clearly makes sending any alert at all > at most a SHOULD for bad macs. > > no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a > MUST. certificate_unobtainable is a MAY. > > The text for client_hello says > "The server will select a cipher suite or, if no acceptable choices are > presented, return a handshake failure alert and close the connection." > No MUST in there. > > The alerts on page 30 MUST NOT be sent except when the client used a > hello extension. But there is no time when they MUST be used. > > In the current draft, I did find a few MUSTs. > > Page 37 has an inferred "will": > The server will select a cipher suite or, if no acceptable choices are > presented, return a handshake failure alert and close the connection. > > page 39 has a MUST: > "... if not then it MUST send a fatal "decode_error" alert." > > section 7.4.1.3 says: "it will respond with a handshake failure alert." > no MUST there. > > I found two MUSTS in 7.4.1.4.2 on page 44. Also a SHALL (isn't that > supposed to be a MUST?) > > I'll stop there without reviewing every weak description of an error alert. > Let's please have more MUSTs. > -- Nelson B 12345678901234567890123456789012345678901234567890123456789012345678901234567890 00000000011111111112222222222333333333344444444445555555555666666666677777777778 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 20:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Bgi-0008AD-Ml; Sun, 31 Dec 2006 20:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Bgh-00089w-G5 for tls@ietf.org; Sun, 31 Dec 2006 20:10:03 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1Bgg-0000gx-0D for tls@ietf.org; Sun, 31 Dec 2006 20:10:03 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id A4247A33CD for ; Sun, 31 Dec 2006 20:10:18 -0500 (EST) 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 6FB62A0FA4 for ; Sun, 31 Dec 2006 20:10:18 -0500 (EST) Message-ID: <45985FA9.5070307@pobox.com> Date: Sun, 31 Dec 2006 17:11:05 -0800 From: Mike User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 > In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding > of the DNs. The field has to > be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the > format/encoding is defined > by the ClientCertificateType). (Tell Peter DER, and he assumes he has to > type check it, now, as DER, > raising an exception if it fails the encoding rules for each attribute > type's value; this is a lot of code!) I don't think you need to validate the DER encoding (or not) of the distinguished names. Just compare them to your own and if you find a match, it must be DER encoded. If you don't find a match, maybe it wasn't DER encoded, or maybe your DN isn't supported. Either way you know what to do. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 31 21:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1DFD-0007NH-6X; Sun, 31 Dec 2006 21:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1DFB-0007N8-OE for tls@ietf.org; Sun, 31 Dec 2006 21:49:45 -0500 Received: from bay0-omc1-s1.bay0.hotmail.com ([65.54.246.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1DFA-0003gW-D6 for tls@ietf.org; Sun, 31 Dec 2006 21:49:45 -0500 Received: from hotmail.com ([65.54.174.89]) by bay0-omc1-s1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 18:49:43 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 18:49:43 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV17.phx.gbl with DAV; Mon, 01 Jan 2007 02:49:41 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: "Mike" , References: <45985FA9.5070307@pobox.com> Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzationspaces, registration practices Date: Sun, 31 Dec 2006 18:49:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 01 Jan 2007 02:49:43.0582 (UTC) FILETIME=[7D934BE0:01C72D4F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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; that's very practical and simple. The declaration is also opaque. So, what you say is what one SHOULD do, using formal reasoning, too. Its not the problem of the protocol state machine; its FOR a message/value handling module to deal with. The protocol machine is NOT ALLOWED to interpret an opaque byte. The certificates in the traditional messages can still be BER, as far as I can tell. But, again, they are opaques. Most if not all the other recent imports of ASN.1 into the standard are required to be DER on the wire. Once CA certs and trust anchors etc are cached, presumably upon signature verification (which necessarily includes DER recoding), the index of the cache can be a suitably hashed-DER-form of the issuerDN, for efficient search. -------------- There is an interesting legal side-argument there, for TLS Evidence. If the SSL Record Layer is signing handshakes, it necessarily is signing uninterpreted bytes, vs signing "information". it would be funny if when pinging the whitehouse.gov SSL server, one could be getting the formal record in the national archives to have a digitally signed rendition of "long live Sadaam's stockpile; good riddance to Pinochet & torture" etc etc, as present in the uninterpreted data. One could be disclosing one's patent idea, in the cert fields, more usefully. Its going to get signed and data retained, even before the https application gets to decode it as syntactic rubbish. Stick your social security number in it, claim it as PII, add a copyright notice, claim it as IP, add a securid OTP to the clientHello.nonce and time, claim its timestamped, and viola! free storage for posterity at govt expense. Strange things happen, when you don't carefully type check everything in security protocols, in my (highly ASN.1-centric) implementation experience. But there we are; that's what the spec says; this is what do therefore do. ----- Original Message ----- From: "Mike" To: Sent: Sunday, December 31, 2006 5:11 PM Subject: Re: [TLS] TLS1.2: focus on non X.509 certs, cert URLs, authoirzationspaces, registration practices >> In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding >> of the DNs. The field has to >> be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the >> format/encoding is defined >> by the ClientCertificateType). (Tell Peter DER, and he assumes he has to >> type check it, now, as DER, >> raising an exception if it fails the encoding rules for each attribute >> type's value; this is a lot of code!) > > I don't think you need to validate the DER encoding (or not) of the > distinguished names. Just compare them to your own and if you find > a match, it must be DER encoded. If you don't find a match, maybe > it wasn't DER encoded, or maybe your DN isn't supported. Either way > you know what to do. > > Mike > > _______________________________________________ > 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 Dec 31 23:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1EOh-0008K7-7Y; Sun, 31 Dec 2006 23:03:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1EOg-0008JK-4U for tls@ietf.org; Sun, 31 Dec 2006 23:03:38 -0500 Received: from bay0-omc1-s28.bay0.hotmail.com ([65.54.246.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1EOe-0000EV-SN for tls@ietf.org; Sun, 31 Dec 2006 23:03:38 -0500 Received: from hotmail.com ([65.54.174.85]) by bay0-omc1-s28.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 20:03:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 20:03:36 -0800 Message-ID: Received: from 69.227.152.254 by BAY103-DAV13.phx.gbl with DAV; Mon, 01 Jan 2007 04:03:33 +0000 X-Originating-IP: [69.227.152.254] X-Originating-Email: [home_pw@msn.com] X-Sender: home_pw@msn.com From: To: Date: Sun, 31 Dec 2006 20:03:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223 X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223 X-OriginalArrivalTime: 01 Jan 2007 04:03:36.0013 (UTC) FILETIME=[CF8297D0:01C72D59] X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [TLS] CRLFs and comments 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 Well I finally got my beta software to be IETF friendly, not that there is much left for me to say: I think I'm through for all that's worth commenting on. At send, the beta software finally now word wraps at 76 char in rich text's plain alternative if the encoding is set to none, vs the default (quoted-printable). If one selects plain as the base option (vs richtext) the encoding is indeed none, and therefore it should re-format this note at <65 char word wrap, 7bit clean, and CRLF line endings. I don't believe Grandma would have figured all this, tho! Perhaps the usability rules ought to move up a generation. My 70 year old boss loves telling me about 75baud acoustic coupled, rotor keyed, dialup devices he installed nationwide. He doesn't force me to use them tho! _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls