From tls-bounces@ietf.org Wed Feb 2 15:38:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26447; Wed, 2 Feb 2005 15:38:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRZF-0004ty-1D; Wed, 02 Feb 2005 15:57:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwR9v-0002lr-J4; Wed, 02 Feb 2005 15:31:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQaf-0004JW-VA for tls@megatron.ietf.org; Wed, 02 Feb 2005 14:55:06 -0500 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20747 for ; Wed, 2 Feb 2005 14:55:01 -0500 (EST) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 11:54:34 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 2 Feb 2005 11:54:34 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 2 Feb 2005 11:54:36 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 2 Feb 2005 11:54:33 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Feb 2005 11:54:33 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10FF2CA7E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: new extension - domain hint thread-index: AcUJYQPOI98y3EJQTpiPHbPRN98oUw== From: "Joshua Ball" To: X-OriginalArrivalTime: 02 Feb 2005 19:54:34.0304 (UTC) FILETIME=[04915C00:01C50961] Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 02 Feb 2005 15:31:30 -0500 Subject: [TLS] new extension - domain hint X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Hello, I am creating a new TLS extension (a domain hint, sent by the client to help the server map the clients certificate) and would like to ensure some extension numbers and new handshake messages don't conflict with any others. Do you have a protocol for choosing these numbers, or should I just choose and submit to this list (and then an informational as well). If the latter, then here is what I suggest: Currently, we need a new ExtensionType { client_domain(6) } As well we need a new Handshake Message { client_domain_name(23) } Otherwise, if these conflict with others, I am certainly open to different numbers.=20 As well, is there (or should there be) a list of known extensions and HS messages? Any thoughts?=20 Thanks, joshua _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 3 01:32:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04074; Thu, 3 Feb 2005 01:32:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwaqA-0002RM-Bq; Thu, 03 Feb 2005 01:51:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwaVo-00023c-LG; Thu, 03 Feb 2005 01:30:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwaPC-0008AN-Es for tls@megatron.ietf.org; Thu, 03 Feb 2005 01:23:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03162 for ; Thu, 3 Feb 2005 01:23:53 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwahh-00029u-5a for tls@ietf.org; Thu, 03 Feb 2005 01:43:02 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j136NoJ06462; Thu, 3 Feb 2005 08:23:50 +0200 (EET) X-Scanned: Thu, 3 Feb 2005 08:23:07 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j136N75o005456; Thu, 3 Feb 2005 08:23:07 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00IxR93b; Thu, 03 Feb 2005 08:23:05 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j136N4U10937; Thu, 3 Feb 2005 08:23:04 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 08:22:45 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Feb 2005 08:22:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] new extension - domain hint Date: Thu, 3 Feb 2005 08:22:44 +0200 Message-ID: Thread-Topic: new extension - domain hint Thread-Index: AcUJYQPOI98y3EJQTpiPHbPRN98oUwAVInQw To: , X-OriginalArrivalTime: 03 Feb 2005 06:22:45.0130 (UTC) FILETIME=[C60CFEA0:01C509B8] X-Spam-Score: 2.3 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.3 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Joshua Ball writes: >=20 > Hello, >=20 > I am creating a new TLS extension (a domain hint, sent by the > client to help the server map the clients certificate) and > would like to ensure some extension numbers and new handshake > messages don't conflict with any others. Do you have a > protocol for choosing these numbers, or should I just choose > and submit to this list (and then an informational as well). According to RFC 3546, "requests to define new extensions (including assigning extension and error alert numbers) must be approved by IETF Standards Action". draft-ietf-tls-rfc3546bis-00=20 changes this to "IETF Consensus". RFC 2246 does not define the procedure for handshake message numbers, but draft-ietf-tls-rfc2246-bis-09 says that "New Handshake message type values MUST be defined via RFC 2434 Standards Action." Since you're defining both an extension and a new handshake message, the correct procedure would be to write an internet draft (with the values left as "TBD"), and initiate standards action as described in RFC 2026, Section 6.1.1. When IESG approves the draft as proposed standard, then the "TBDs" are=20 replaced with the actual numbers. Or this is at least how the official IETF procedure is supposed to work. Sadly, this procedure is often ignored, as this list of "TLS numbers used in various places" shows: http://people.nokia.net/~pasi/tls-numbers.txt So if you decide not to follow the official procedure, at least don't use any number that's already on the list... (Disclaimer: The list is totally unofficial, and the inclusion of any particular value does not mean that the number is "allocated" for that purpose. In some cases, it's more=20 like "hall of shame" :-) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 10 17:37:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29845; Thu, 10 Feb 2005 17:37:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNGY-0004gB-HE; Thu, 10 Feb 2005 17:58:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzM2E-0007Z2-Iu; Thu, 10 Feb 2005 16:39:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzLbW-0004Jt-BH for tls@megatron.ietf.org; Thu, 10 Feb 2005 16:12:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11254 for ; Thu, 10 Feb 2005 16:11:59 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzLvX-0006n4-36 for tls@ietf.org; Thu, 10 Feb 2005 16:32:47 -0500 Received: from [12.47.165.130] (helo=localhost) by mx2.foretec.com with smtp (Exim 4.24) id 1CzLbQ-0005WG-EZ for tls@ietf.org; Thu, 10 Feb 2005 16:11:56 -0500 Received: from simon ([10.71.0.112]) by localhost 0.5.5 with ESMTP id 39B7420BCDB90001 Thu Feb 10 14:10:17 2005 From: "Simon Blake-Wilson" To: "'EKR'" Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt Date: Thu, 10 Feb 2005 14:11:11 -0700 Message-ID: <021301c50fb5$0c0be310$7000470a@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <861xd7g4sx.fsf@romeo.rtfm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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="===============0478402081==" Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d This is a multi-part message in MIME format. --===============0478402081== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_020E_01C50F7A.5EF41B50" This is a multi-part message in MIME format. ------=_NextPart_000_020E_01C50F7A.5EF41B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eric, Are you comfortable starting WGLC on the extensions update (and the ECC draft) yet? Best regards. Simon > -----Original Message----- > From: EKR [mailto:ekr@rtfm.com] > Sent: Thursday, December 30, 2004 8:54 AM > To: Simon Blake-Wilson > Cc: tls@ietf.org > Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt > > > "Simon Blake-Wilson" writes: > > We just posted an internet-draft updating the extensions > RFC to deal > > with the issue of which documents can define new extensions - the > > current RFC allows only standards track RFCs while this > draft allows > > any RFC based on IETF consensus (which basically means IESG review). > > > > I've summarized the detailed list of changes below. > > > > Eric/Win ... How do you want to handle this? Given the > minor nature of > > the updates, can we proceed with working group last call on > this (and > > the ECC in TLS draft)? > Given the holidays, etc. let's see what people have to say > over the next few weeks. If there are no substantive comments > I'll initiate WGLC. > > -Ekr > ------=_NextPart_000_020E_01C50F7A.5EF41B50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTAyMTAyMTExMTBaMCMGCSqGSIb3 DQEJBDEWBBRnR2krcWtq3yQz5H40yBqwRChkCTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgKgsQ8KcyyAHUXP6XelTJTUN9OYRhkDJEbqtjKDLJCEGiU1tKT7Xbkms 0xDhNKSsziu0s9nnbh33rtvEOtYFGtyIkBmGc+HZjD6b+p4qWEi9ncjXK6bfct3VNiyajUvt8uii WVfqo28mi4Z366bKw+mo/w8Kn5fVMEy8nObKP25JAAAAAAAA ------=_NextPart_000_020E_01C50F7A.5EF41B50-- --===============0478402081== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0478402081==-- From tls-bounces@ietf.org Wed Feb 16 18:04:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07930; Wed, 16 Feb 2005 18:04:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YYs-0006CP-2W; Wed, 16 Feb 2005 18:26:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Y2C-0001yv-UY; Wed, 16 Feb 2005 17:52:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Xv3-0007GQ-0F for tls@megatron.ietf.org; Wed, 16 Feb 2005 17:45:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05928 for ; Wed, 16 Feb 2005 17:45:13 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YGK-0005dn-9j for tls@ietf.org; Wed, 16 Feb 2005 18:07:19 -0500 Received: from phys-ha14sca-1.sfbay.sun.com ([129.145.155.210]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1GMjBnK004903 for ; Wed, 16 Feb 2005 15:45:11 -0700 (MST) Received: from [192.18.148.184] by ha14sca-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Jul 26 2004)) with ESMTP id <0IC100D6P0JBHKF0@ha14sca-mail1.sfbay.sun.com> for tls@ietf.org; Wed, 16 Feb 2005 14:45:11 -0800 (PST) Date: Wed, 16 Feb 2005 14:44:14 -0800 From: Nelson B Bolyard To: tls@ietf.org Message-id: <4213CCBE.4050803@bolyard.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040927 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [TLS] Time for ciphersuites with new hashes? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit In light of the news that SHA1 has been "broken" http://www.schneier.com/blog/archives/2005/02/sha1_broken.html (collisions can be found with much less work than predicted), is it time for us to be defining new ciphersuites that employ SHA256, SHA384 and/or SHA512? /Nelson _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Feb 16 18:39:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12428; Wed, 16 Feb 2005 18:39:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Z7F-0007DN-N9; Wed, 16 Feb 2005 19:01:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YfX-0001sP-3A; Wed, 16 Feb 2005 18:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YaW-00082q-4o for tls@megatron.ietf.org; Wed, 16 Feb 2005 18:28:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11037 for ; Wed, 16 Feb 2005 18:28:04 -0500 (EST) Received: from saria.randombit.net ([66.179.181.167] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Yvq-0006oY-EF for tls@ietf.org; Wed, 16 Feb 2005 18:50:11 -0500 Received: by mail.randombit.net (Postfix, from userid 501) id 0977A247C03A; Wed, 16 Feb 2005 16:28:03 -0700 (MST) Date: Wed, 16 Feb 2005 16:28:03 -0700 From: Jack Lloyd To: tls@ietf.org Subject: Re: [TLS] Time for ciphersuites with new hashes? Message-ID: <20050216232803.GD29536@randombit.net> Mail-Followup-To: tls@ietf.org References: <4213CCBE.4050803@bolyard.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4213CCBE.4050803@bolyard.com> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Personally, I'm more concerned with the fact that the authorization process is fixed with SHA-1 (or MD5+SHA-1 for RSA) with no upgrade path. I still feel pretty comfortable with HMAC/SHA-1 for now, though a new set of AES+SHA2 ciphersuites would be easy to specify and probably couldn't hurt. Any thoughts on adding a TLS extension for negotiating different hashes for authorization? DSA might be a little tricky, since AFAIK NIST still hasn't approved larger keys, and you would lose quite a bit of hash space by using SHA-2 with a 160 bit q. But RSA could be trivially ugpraded to use SHA-512 with normal PKCS1 v1.5 padding instead of the MD5/SHA1 with the PKCS-variant padding that's currently used. It would be difficult to mount a succesful attack against the handshake in realtime, given the current workload of even just an MD5 collision, much less 2^69 operations for SHA, but by the time such an extension is actually widely implemented, I suspect those will have been reduced quite a bit. Basic outline: Client extension: enum { sha256(0), sha384(1), sha512(2), (255) } SignatureHash; struct { SignatureHash hash_list<1..2^8-1>; /* sorted by client preference */ } SignatureHashList; Server extension: struct { SignatureHash hash; /* whichever one the server prefers */ } SignatureHashResponse; If negotiated, the RSA signatures uses standard PKCS #1 padding with the chosen hash, DSA continues to use raw unpadded hashes as normal. Flame away, Jack On Wed, Feb 16, 2005 at 02:44:14PM -0800, Nelson B Bolyard wrote: > In light of the news that SHA1 has been "broken" > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > (collisions can be found with much less work than predicted), > is it time for us to be defining new ciphersuites that employ > SHA256, SHA384 and/or SHA512? > > /Nelson > > _______________________________________________ > 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@ietf.org Wed Feb 16 22:58:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07296; Wed, 16 Feb 2005 22:58:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1d9g-0005Uq-23; Wed, 16 Feb 2005 23:20:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1cmU-0006oj-22; Wed, 16 Feb 2005 22:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ch7-0004wj-BQ for tls@megatron.ietf.org; Wed, 16 Feb 2005 22:51:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06304 for ; Wed, 16 Feb 2005 22:51:09 -0500 (EST) Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1d2U-0005I9-2U for tls@ietf.org; Wed, 16 Feb 2005 23:13:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 5369234FF7; Thu, 17 Feb 2005 16:51:08 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32143-18; Thu, 17 Feb 2005 16:51:08 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 16AD934B22; Thu, 17 Feb 2005 16:51:07 +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 AA22B37745; Thu, 17 Feb 2005 16:51:07 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D1ch6-0001zP-00; Thu, 17 Feb 2005 16:51:12 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nelson@bolyard.com, tls@ietf.org Subject: Re: [TLS] Time for ciphersuites with new hashes? In-Reply-To: <4213CCBE.4050803@bolyard.com> Message-Id: Date: Thu, 17 Feb 2005 16:51:12 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Nelson B Bolyard writes: >In light of the news that SHA1 has been "broken" >http://www.schneier.com/blog/archives/2005/02/sha1_broken.html (collisions >can be found with much less work than predicted), is it time for us to be >defining new ciphersuites that employ SHA256, SHA384 and/or SHA512? Just to put this into perspective: - It only affects the use of SHA-1 as a hash function, not as a PRF or HMAC, so the core of SSH, SSL/TLS, etc etc are unaffected. - I've seen one report that it only affects the compression function and not the full hash function, which sounds plausible. SHA-1 (and indeed all of the MD4-type UFN hash functions) use a core compression function and then perform extra operations for the full hash function, so finding collisions in the full hash is somewhat more difficult than just the compression function. - It takes 2^69 ops on average to find a second input value that produces the same output as the first one (the ambiguous phrasing here is meant to indicate that probably the compression function produces the same output rather than the full SHA-1 hash producing the same output, see above). The second input value can't be chosen by the attacker, so the chances of forging a signature on structured data like a certificate or CMS/PGP message are fairly remote. So while it's a very interesting result, it's more a hint to consider moving to something else rather than time to hit the panic button. RIPEMD-160 still looks fairly secure, my gut feeling is that its dual-path construction is safer than the SHA-1 derived SHA-256 et al, but I suspect that in the light of the current work on attacking UFN-based designs we'll be seeing a pile of new non-UFN hash functions in the same way that differential cryptanalysis spurred a burst of work on new ciphers. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 00:50:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18291; Thu, 17 Feb 2005 00:50:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1etZ-0008Rk-Iq; Thu, 17 Feb 2005 01:12:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1eWf-0004Mz-2X; Thu, 17 Feb 2005 00:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1eSU-0002iR-2m for tls@megatron.ietf.org; Thu, 17 Feb 2005 00:44:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17841 for ; Thu, 17 Feb 2005 00:44:09 -0500 (EST) Received: from maynard.mail.mindspring.net ([207.69.200.243]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1enr-0008Ji-KR for tls@ietf.org; Thu, 17 Feb 2005 01:06:19 -0500 Received: from 1cust19.tnt36.dfw9.da.uu.net ([67.234.81.19] helo=ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D1eSN-00031V-00; Thu, 17 Feb 2005 00:44:08 -0500 Message-ID: <421449F6.BD01A8CC@ix.netcom.com> Date: Wed, 16 Feb 2005 23:38:36 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Peter Gutmann Subject: Re: [TLS] Time for ciphersuites with new hashes? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Peter and all, I think your under playing this a bit. Once you have found holes and/or collisions in compression it is short work to determined other collisions if the full hash... Moving away from SHA-1 is really overdue, but not yet entirely necessary... Peter Gutmann wrote: > Nelson B Bolyard writes: > > >In light of the news that SHA1 has been "broken" > >http://www.schneier.com/blog/archives/2005/02/sha1_broken.html (collisions > >can be found with much less work than predicted), is it time for us to be > >defining new ciphersuites that employ SHA256, SHA384 and/or SHA512? > > Just to put this into perspective: > > - It only affects the use of SHA-1 as a hash function, not as a PRF or HMAC, > so the core of SSH, SSL/TLS, etc etc are unaffected. > > - I've seen one report that it only affects the compression function and not > the full hash function, which sounds plausible. SHA-1 (and indeed all of > the MD4-type UFN hash functions) use a core compression function and then > perform extra operations for the full hash function, so finding collisions > in the full hash is somewhat more difficult than just the compression > function. > > - It takes 2^69 ops on average to find a second input value that produces the > same output as the first one (the ambiguous phrasing here is meant to > indicate that probably the compression function produces the same output > rather than the full SHA-1 hash producing the same output, see above). The > second input value can't be chosen by the attacker, so the chances of > forging a signature on structured data like a certificate or CMS/PGP message > are fairly remote. > > So while it's a very interesting result, it's more a hint to consider moving > to something else rather than time to hit the panic button. RIPEMD-160 still > looks fairly secure, my gut feeling is that its dual-path construction is > safer than the SHA-1 derived SHA-256 et al, but I suspect that in the light of > the current work on attacking UFN-based designs we'll be seeing a pile of new > non-UFN hash functions in the same way that differential cryptanalysis spurred > a burst of work on new ciphers. > > Peter. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 04:10:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26871; Thu, 17 Feb 2005 04:10:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1i1A-0004mw-JP; Thu, 17 Feb 2005 04:32:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hZq-0001Kw-P6; Thu, 17 Feb 2005 04:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hYS-0000V3-24 for tls@megatron.ietf.org; Thu, 17 Feb 2005 04:02:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26245 for ; Thu, 17 Feb 2005 04:02:34 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1htq-0004bu-2H for tls@ietf.org; Thu, 17 Feb 2005 04:24:44 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H92NP18932; Thu, 17 Feb 2005 11:02:23 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 11:01:43 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1H91hpb010357; Thu, 17 Feb 2005 11:01:43 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00SRWDPx; Thu, 17 Feb 2005 11:01:42 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H91gJ19354; Thu, 17 Feb 2005 11:01:42 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 11:01:41 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 11:01:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Time for ciphersuites with new hashes? Date: Thu, 17 Feb 2005 11:01:40 +0200 Message-ID: Thread-Topic: [TLS] Time for ciphersuites with new hashes? Thread-Index: AcUUg2XAtsgsLz6iT6C8Jiy+sdFiowASY6ow To: , X-OriginalArrivalTime: 17 Feb 2005 09:01:41.0019 (UTC) FILETIME=[4BAAAEB0:01C514CF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Another possibility would be to define a set of new TLS key exchange algorithms (RSA2/DH_RSA2/DHE_RSA2/something, either PKCSv1.5 padding with SHA-256, or maybe PKCSv2.1 PSS padding), and new ciphersuites based on those, something like: TLS_RSA2_WITH_AES_256_CBC_SHA256 TLS_RSA2_WITH_something_else TLS_DH_RSA2_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA2_WITH_AES_256_CBC_SHA256 =20 (...) This way, we could use the existing TLS ciphersuite negotiation logic without needing anything new there. And since TLS already has a large number of different key exchange algorithms (my last count was around 20, including the most stable internet-drafts), adding a couple more would probably fit the TLS architecture reasonably nicely. (But certainly adding a TLS extension would also get=20 the job done.) Best regards, Pasi > -----Original Message----- > From: Jack Lloyd > Sent: Thursday, February 17, 2005 1:28 AM > To: tls@ietf.org > Subject: Re: [TLS] Time for ciphersuites with new hashes? >=20 >=20 > Personally, I'm more concerned with the fact that the > authorization process is fixed with SHA-1 (or MD5+SHA-1 for > RSA) with no upgrade path. I still feel pretty comfortable > with HMAC/SHA-1 for now, though a new set of AES+SHA2 > ciphersuites would be easy to specify and probably couldn't > hurt. >=20 > Any thoughts on adding a TLS extension for negotiating > different hashes for authorization? DSA might be a little > tricky, since AFAIK NIST still hasn't approved larger keys, > and you would lose quite a bit of hash space by using SHA-2 > with a 160 bit q. But RSA could be trivially ugpraded to use > SHA-512 with normal PKCS1 v1.5 padding instead of the MD5/SHA1 > with the PKCS-variant padding that's currently used. It would > be difficult to mount a succesful attack against the handshake > in realtime, given the current workload of even just an MD5 > collision, much less 2^69 operations for SHA, but by the time > such an extension is actually widely implemented, I suspect > those will have been reduced quite a bit. >=20 > Basic outline: >=20 > Client extension: >=20 > enum { > sha256(0), sha384(1), sha512(2), (255) > } SignatureHash; >=20 > struct { > SignatureHash hash_list<1..2^8-1>; /* sorted by client=20 > preference */ > } SignatureHashList; >=20 > Server extension: >=20 > struct { > SignatureHash hash; /* whichever one the server prefers */ > } SignatureHashResponse; >=20 > If negotiated, the RSA signatures uses standard PKCS #1 > padding with the chosen hash, DSA continues to use raw > unpadded hashes as normal. >=20 > Flame away, > Jack _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 09:16:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26830; Thu, 17 Feb 2005 09:16:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mo8-0004Jo-0D; Thu, 17 Feb 2005 09:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mNP-0001jE-IO; Thu, 17 Feb 2005 09:11:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mFi-0006qG-5I for tls@megatron.ietf.org; Thu, 17 Feb 2005 09:03:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25507 for ; Thu, 17 Feb 2005 09:03:33 -0500 (EST) Received: from gwyn.tux.org ([199.184.165.135] ident=ident-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mbB-0003xX-1x for tls@ietf.org; Thu, 17 Feb 2005 09:25:45 -0500 Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id j1HE3Wgb022974 for ; Thu, 17 Feb 2005 09:03:32 -0500 Received: (from peterw@localhost) by gwyn.tux.org (8.12.11/8.12.11/Submit) id j1HE3WY3022973 for tls@ietf.org; Thu, 17 Feb 2005 09:03:32 -0500 Date: Thu, 17 Feb 2005 09:03:32 -0500 From: Peter Watkins To: tls@ietf.org Subject: Re: [TLS] Time for ciphersuites with new hashes? Message-ID: <20050217090332.A21200@gwyn.tux.org> References: <4213CCBE.4050803@bolyard.com> <20050216232803.GD29536@randombit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20050216232803.GD29536@randombit.net>; from lloyd@randombit.net on Wed, Feb 16, 2005 at 04:28:03PM -0700 X-Virus-Scanned: ClamAV 0.80/622/Wed Dec 8 08:36:53 2004 clamav-milter version 0.80j on gwyn.tux.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 On Wed, Feb 16, 2005 at 04:28:03PM -0700, Jack Lloyd wrote: > > Personally, I'm more concerned with the fact that the authorization process is > fixed with SHA-1 (or MD5+SHA-1 for RSA) with no upgrade path. My thoughts: I'm still much more concerned about promoting something like "RSA ephemeral" for some sort fo forward secrecy improvements. The weak link for 99% of real world TLS/SSL implementations is keypair management, since so few folks are using expensive tamper-resistent crypto hardware for their server ends, and the hash function is a moot point if an attacker can sniff traffic in anticipation of scoring a/the server keypair from some social/meatspace hack. I know Sun and Microsoft don't like specs that mandate forward secrecy, but I'd like to see this WG start to incorporate forward secrecy as a core component of future ciphersuites, even if only "ephemeral" keypairs that leave wiggle room for TLS server vendors. -Peter > On Wed, Feb 16, 2005 at 02:44:14PM -0800, Nelson B Bolyard wrote: > > In light of the news that SHA1 has been "broken" > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > (collisions can be found with much less work than predicted), > > is it time for us to be defining new ciphersuites that employ > > SHA256, SHA384 and/or SHA512? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 09:35:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28923; Thu, 17 Feb 2005 09:35:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1n5e-0004qn-Fb; Thu, 17 Feb 2005 09:57:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mhH-00021m-EN; Thu, 17 Feb 2005 09:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1mVD-0005GY-VD for tls@megatron.ietf.org; Thu, 17 Feb 2005 09:19:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27152 for ; Thu, 17 Feb 2005 09:19:34 -0500 (EST) Received: from saria.randombit.net ([66.179.181.167] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mqf-0004Os-Vq for tls@ietf.org; Thu, 17 Feb 2005 09:41:47 -0500 Received: by mail.randombit.net (Postfix, from userid 501) id 2181E247C03A; Thu, 17 Feb 2005 07:19:33 -0700 (MST) Date: Thu, 17 Feb 2005 07:19:32 -0700 From: Jack Lloyd To: tls@ietf.org Subject: Re: [TLS] Time for ciphersuites with new hashes? Message-ID: <20050217141932.GA8914@randombit.net> Mail-Followup-To: tls@ietf.org References: <4213CCBE.4050803@bolyard.com> <20050216232803.GD29536@randombit.net> <20050217090332.A21200@gwyn.tux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050217090332.A21200@gwyn.tux.org> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B 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: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, Feb 17, 2005 at 09:03:32AM -0500, Peter Watkins wrote: [...] > I know Sun and Microsoft don't like specs that mandate forward secrecy, > but I'd like to see this WG start to incorporate forward secrecy as a > core component of future ciphersuites, even if only "ephemeral" keypairs > that leave wiggle room for TLS server vendors. Don't the DHE ciphersuites provide PFS already? Am I missing something? -Jack _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 15:22:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00697; Thu, 17 Feb 2005 15:22:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sVf-0006Ni-9E; Thu, 17 Feb 2005 15:44:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qYQ-0005z4-UN; Thu, 17 Feb 2005 13:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nUE-0006on-FQ for tls@megatron.ietf.org; Thu, 17 Feb 2005 10:22:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05408 for ; Thu, 17 Feb 2005 10:22:35 -0500 (EST) Received: from mx2.cryptopro.ru ([213.59.158.218]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1npd-0006Ff-5N for tls@ietf.org; Thu, 17 Feb 2005 10:44:49 -0500 Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 18:23:00 +0300 Message-ID: <04c201c51504$90c50290$0644a8c0@cp.ru> From: "Gregory S. Chudov" To: "Jack Lloyd" , References: <4213CCBE.4050803@bolyard.com> <20050216232803.GD29536@randombit.net> Subject: Re: [TLS] Time for ciphersuites with new hashes? Date: Thu, 17 Feb 2005 18:23:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 17 Feb 2005 15:23:00.0296 (UTC) FILETIME=[90C74C80:01C51504] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Greetings! ----- Original Message ----- From: "Jack Lloyd" To: Sent: Thursday, February 17, 2005 2:28 AM Subject: Re: [TLS] Time for ciphersuites with new hashes? > > Personally, I'm more concerned with the fact that the authorization process is > fixed with SHA-1 (or MD5+SHA-1 for RSA) with no upgrade path. I still feel > pretty comfortable with HMAC/SHA-1 for now, though a new set of AES+SHA2 > ciphersuites would be easy to specify and probably couldn't hurt. > > Any thoughts on adding a TLS extension for negotiating different hashes for > authorization? [skip] I am currently working on a draft, proposing such an extension. It was mentioned on the list, that a different PRF would suit better for PSK. Besides, SHA-1/MD5/PRF cannot be used with GOST cipher suites. So we have plenty of reasons already to create an extension, which would allow PRF and authorization hash negotiation. Good luck, Greg Chudov. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 16:17:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06282; Thu, 17 Feb 2005 16:17:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tN8-00088R-Oh; Thu, 17 Feb 2005 16:39:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1r3D-0007st-W0; Thu, 17 Feb 2005 14:10:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1p9q-0007iW-IJ for tls@megatron.ietf.org; Thu, 17 Feb 2005 12:09:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24970 for ; Thu, 17 Feb 2005 12:09:39 -0500 (EST) Received: from ws6-3.us4.outblaze.com ([205.158.62.199]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1pVH-00047M-HA for tls@ietf.org; Thu, 17 Feb 2005 12:31:55 -0500 Received: (qmail 10797 invoked from network); 17 Feb 2005 17:09:35 -0000 Received: from unknown (HELO ?192.168.0.2?) (nelson@bolyard.com@24.6.210.63) by ws6-3.us4.outblaze.com with SMTP; 17 Feb 2005 17:09:35 -0000 Message-ID: <4214CFCB.6050704@bolyard.com> Date: Thu, 17 Feb 2005 09:09:31 -0800 From: "Nelson B. Bolyard" Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Williams Subject: Re: [TLS] Time for ciphersuites with new hashes? References: <421449F6.BD01A8CC@ix.netcom.com> In-Reply-To: <421449F6.BD01A8CC@ix.netcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Jeff Williams wrote: > Peter and all, > > I think your under playing this a bit. Once you have found holes > and/or collisions in compression it is short work to determined > other collisions if the full hash... Moving away from SHA-1 > is really overdue, but not yet entirely necessary... Right. It's not yet a panic, but we can see it coming, so NOW is the right time, IMO. > Peter Gutmann wrote: >>So while it's a very interesting result, it's more a hint to consider moving >>to something else rather than time to hit the panic button. Right. Let's not delay doing this work until the panic has begun. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 17:42:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19616; Thu, 17 Feb 2005 17:42:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uhV-0003NH-Uv; Thu, 17 Feb 2005 18:04:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tw4-0005OJ-PS; Thu, 17 Feb 2005 17:15:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tfh-0003lt-9k for tls@megatron.ietf.org; Thu, 17 Feb 2005 16:58:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11962 for ; Thu, 17 Feb 2005 16:58:51 -0500 (EST) Received: from gwyn.tux.org ([199.184.165.135] ident=ident-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1u1E-0001Jl-3y for tls@ietf.org; Thu, 17 Feb 2005 17:21:08 -0500 Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id j1HLwpDi000798 for ; Thu, 17 Feb 2005 16:58:51 -0500 Received: (from peterw@localhost) by gwyn.tux.org (8.12.11/8.12.11/Submit) id j1HLwpoB000797 for tls@ietf.org; Thu, 17 Feb 2005 16:58:51 -0500 Date: Thu, 17 Feb 2005 16:58:51 -0500 From: Peter Watkins To: tls@ietf.org Subject: Re: [TLS] Time for ciphersuites with new hashes? Message-ID: <20050217165851.A32583@gwyn.tux.org> References: <4213CCBE.4050803@bolyard.com> <20050216232803.GD29536@randombit.net> <20050217090332.A21200@gwyn.tux.org> <20050217141932.GA8914@randombit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20050217141932.GA8914@randombit.net>; from lloyd@randombit.net on Thu, Feb 17, 2005 at 07:19:32AM -0700 X-Virus-Scanned: ClamAV 0.80/622/Wed Dec 8 08:36:53 2004 clamav-milter version 0.80j on gwyn.tux.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 On Thu, Feb 17, 2005 at 07:19:32AM -0700, Jack Lloyd wrote: > On Thu, Feb 17, 2005 at 09:03:32AM -0500, Peter Watkins wrote: > > [...] > > I know Sun and Microsoft don't like specs that mandate forward secrecy, > > but I'd like to see this WG start to incorporate forward secrecy as a > > core component of future ciphersuites, even if only "ephemeral" keypairs > > that leave wiggle room for TLS server vendors. > > Don't the DHE ciphersuites provide PFS already? Am I missing something? The trouble is that most traffic is protected with RSA suites, so we should be very concerned about the protection that RSA suites offer. RSA_EXPORT offers some forward secrecy via the temporary key mechanism, but the "standard" RSA suite set does not. I had been under the impression that most servers were using the non-EXPORT RSA ciphersuites, but now that I examine some certificates I see mostly RSA keys with >= 1024 bit moduli -- which would necessitate server key exchange messages negotiating RSA_EXPORT. I also see Certificate Authorities like Verisign recommending 1024+ bit server keypairs, and vendors of TLS-using server software like Sun and Microsoft defaulting to 1024 bits or better in their keypair creation. So the good news is that the current state of affairs is better than I feared, and my "weak link" statement seems to be way off base. But there's an irony: it's only because of US export law that TLS servers with large RSA keys are using the server exchange mechanism to switch to the RSA_EXPORT temporary key mechanism and negotiate a suite with some forward secrecy. I'd like to see future ciphersuites include forward secrecy (perfect or not) as a core design goal, not some accidental benefit as we have now. -Peter _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Thu Feb 17 19:01:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27518; Thu, 17 Feb 2005 19:01:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vvU-0005Ge-GV; Thu, 17 Feb 2005 19:23:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vMc-0005iI-E8; Thu, 17 Feb 2005 18:47:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1uVM-0007Rt-0O for tls@megatron.ietf.org; Thu, 17 Feb 2005 17:52:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20415 for ; Thu, 17 Feb 2005 17:52:13 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uqs-0003b8-GD for tls@ietf.org; Thu, 17 Feb 2005 18:14:32 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 32FAB17043; Thu, 17 Feb 2005 14:55:36 -0800 (PST) >To: Peter Watkins Subject: Re: [TLS] Time for ciphersuites with new hashes? References: <4213CCBE.4050803@bolyard.com> <20050216232803.GD29536@randombit.net> <20050217090332.A21200@gwyn.tux.org> <20050217141932.GA8914@randombit.net> <20050217165851.A32583@gwyn.tux.org> From: Eric Rescorla Date: Thu, 17 Feb 2005 14:55:36 -0800 In-Reply-To: <20050217165851.A32583@gwyn.tux.org> (Peter Watkins's message of "Thu, 17 Feb 2005 16:58:51 -0500") Message-ID: <867jl6dcev.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Peter Watkins writes: > On Thu, Feb 17, 2005 at 07:19:32AM -0700, Jack Lloyd wrote: >> On Thu, Feb 17, 2005 at 09:03:32AM -0500, Peter Watkins wrote: >> >> [...] >> > I know Sun and Microsoft don't like specs that mandate forward secrecy, >> > but I'd like to see this WG start to incorporate forward secrecy as a >> > core component of future ciphersuites, even if only "ephemeral" keypairs >> > that leave wiggle room for TLS server vendors. >> >> Don't the DHE ciphersuites provide PFS already? Am I missing something? > > The trouble is that most traffic is protected with RSA suites, so we should > be very concerned about the protection that RSA suites offer. But that's purely a matter of how people configure their implementations. You can do DHE with the RSA certificates that people now standardly have. > RSA_EXPORT offers some forward secrecy via the temporary key mechanism, but > the "standard" RSA suite set does not. > > I had been under the impression that most servers were using the non-EXPORT > RSA ciphersuites, but now that I examine some certificates I see mostly RSA > keys with >= 1024 bit moduli -- which would necessitate server key exchange > messages negotiating RSA_EXPORT. I believe you're mistaken here. The vast majority of SSL connections use static RSA, no matter what the key size in the certificates. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Feb 18 00:13:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26883; Fri, 18 Feb 2005 00:13:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D20nW-00054m-Hn; Fri, 18 Feb 2005 00:35:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D20Nh-0000Sc-Mo; Fri, 18 Feb 2005 00:08:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D20Gt-0006Ko-QO for tls@megatron.ietf.org; Fri, 18 Feb 2005 00:01:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25973 for ; Fri, 18 Feb 2005 00:01:41 -0500 (EST) Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D20cT-0004p6-PZ for tls@ietf.org; Fri, 18 Feb 2005 00:24:03 -0500 Received: from 1cust182.tnt36.dfw9.da.uu.net ([67.234.81.182] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1D20Gp-0007Ao-00; Fri, 18 Feb 2005 00:01:40 -0500 Message-ID: <42159188.B525C58A@ix.netcom.com> Date: Thu, 17 Feb 2005 22:56:09 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Nelson B. Bolyard" Subject: Re: [TLS] Time for ciphersuites with new hashes? References: <421449F6.BD01A8CC@ix.netcom.com> <4214CFCB.6050704@bolyard.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: aba isc list , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Nelson and all, With regards to SHA-1 AND DES/3DES we are in agreement.. There is no panic yet, and if this is addressed in a expedient manner there need not be a panic. However, waiting very long would be a mistake that would lead to a panic decision mode which is almost always a disaster of one proportion or another... Nelson B. Bolyard wrote: > Jeff Williams wrote: > > Peter and all, > > > > I think your under playing this a bit. Once you have found holes > > and/or collisions in compression it is short work to determined > > other collisions if the full hash... Moving away from SHA-1 > > is really overdue, but not yet entirely necessary... > > Right. It's not yet a panic, but we can see it coming, so NOW is the > right time, IMO. > > > Peter Gutmann wrote: > > >>So while it's a very interesting result, it's more a hint to consider moving > >>to something else rather than time to hit the panic button. > > Right. Let's not delay doing this work until the panic has begun. > > -- > Nelson B Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Feb 18 01:19:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04080; Fri, 18 Feb 2005 01:19:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D21pM-0006fU-VU; Fri, 18 Feb 2005 01:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21SG-0003VJ-6t; Fri, 18 Feb 2005 01:17:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21Mt-0001AY-Hn for tls@megatron.ietf.org; Fri, 18 Feb 2005 01:11:59 -0500 Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02963 for ; Fri, 18 Feb 2005 01:11:58 -0500 (EST) Received: from 1cust223.tnt36.dfw9.da.uu.net ([67.234.81.223] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1D21Mo-0002X1-00; Fri, 18 Feb 2005 01:11:54 -0500 Message-ID: <4215A1FB.6D85E1DE@ix.netcom.com> Date: Fri, 18 Feb 2005 00:06:23 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "Austin R." References: <200502172047.1d202T35r3NZFpL0@mx-a065b05.pas.sa.earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: TLS List Subject: [TLS] Re: SHA-1 collisions found X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 22f8e36c8d8be0bcbb9bf02fb6ce7335 Content-Transfer-Encoding: 7bit Austin, I never said that DES had anything to do with identity theft directly. So such a mischaracterization is of your own interpratation of what I did say. What I did say was the following again: "it is clear that moving away from DES/3DES and SHA-1 is necessary and IMHO amongst a growing number of other security professionals as well as the NIST, long overdue due to identity theft and other security related very real concerns.." Yes your right that 3DES is not directly used to authenticate identities, and breaks in SHA-1 can't be used directly to forge identities as you state it in your remarks. However indirectly and/or as result in the use of cybersuites in TLS/SSL where SHA-1 is one hash used and 3DES is included, the "Stealing" of identities and/or misuse can be achieved... Hence, the movement away from the SHA-1 hash as well as BTW it's siblings SHA-256 and SHA-512 would be advisible as soon as can be achieved. The NIST has already recomended moving away from DES and 3DES as I believe you know... So the sooner a moving away can be achieved, the lessor of a chance a panic approach will ensue. Austin R. wrote: > Jeff, > I'm not going to waste the rest of the listserv's time with this as we did > last time when everyone on the listserv told you that you were wrong...but > you're wrong. And frankly it's frustrating to hear you keep saying things > that are plainly wrong and confuse people. 3DES has nothing to do with > identity theft because it's not used to authenticate identity, and people > can't forge identities through breaks in SHA-1 yet either...and won't be > able to for some time in the far future. Reread what the guy AT NIST wrote > the listserv regarding that. There are no reported weaknesses in 3DES > either Jeff. > > Also...I can't seen to find your company anywhere, your claim to know Prof. > Hawking was invalidated by his student assistant that I contacted, and in > general it seems like you're just BSing most of what you say. If you want > to go on a listserv and act like you know what you're talking about when you > don't, I really can't stop you (obviously)...but at least have the decency > not to scare others who don't know things that you say are BS. > > ---------------------------------------------------------------------- > Gavon (Austin) Renfroe > BSEE, BA Math, University of Texas at Austin Class of 2004 > Emory School of Law Class of 2007 > > -----Original Message----- > From: Information Security Committee [mailto:ST-ISC@MAIL.ABANET.ORG] On > Behalf Of Jeff Williams > Sent: Friday, February 18, 2005 12:59 AM > To: ST-ISC@MAIL.ABANET.ORG > Subject: Re: SHA-1 collisions found > > Richard and all, > > No offense, but it is clear that moving away from DES/3DES and > SHA-1 is necessary and IMHO amongst a growing number of other > security professionals as well as the NIST, long overdue due to identity > theft and other security related very real concerns.. If my and/or others > "Language" is seemingly alarmist or "Scary" to some folks, than that > may be a good thing so as to aid in facilitate and/or expedite said > migration away from DES/3DES as well as SHA-1. The IETF on > a number of forums I am a participant on to one degree or activity > or another are also very interested now given the increasing weakness > noticed and reported in DES/3DES and now SHA-1 and advising > to new Hash development, and I view this as a positive thing... > > Guida, Richard [JJCUS] wrote: > > > Jeff, this is a reprise of the 3DES issue regarding the term "broken." If > > you wish to get on the witness stand and testify that SHA-1 is "broken," > > that is your right. I would look forward to helping opposing counsel > > cross-examine you. We all understand the need to migrate to SHA-256 or > > better as soon as practical; there is no need for hyperbole, which may > > unduly frighten people into not using digital signatures or cryptographic > > techniques "until all of this gets sorted out." Believe it or not, that > is > > how some people actually think. So let's please be measured in our use of > > words. > > > > Here is an excerpt from a separate post on the SAAG mail-list by Peter > > Guttman which I think well captures the situation; note the first sentence > > in the final paragraph: > > > > > > > > I think it'd be better to wait a bit to get the full details. Here's a > > boilerplate summary I've been sending out to people who have mailed me > about > > this (personal opinion disclaimer, etc etc): > > > > - It only affects the use of SHA-1 as a hash function, not as a PRF or > HMAC, > > so the core of SSH, SSL/TLS, etc etc are unaffected. > > > > - I've seen one report that it only affects the compression function and > not > > the full hash function, which sounds plausible. SHA-1 (and indeed all > of > > the MD4-type UFN hashes) use a core compression function and then > perform > > extra operations for the full hash function, so finding collisions in > the > > full hash is somewhat more difficult than just the compression function. > > > > - It takes 2^69 ops on average to find a second input value that produces > > the > > same output as the first one (the ambiguous phrasing here is meant to > > indicate that probably what's meant is that the compression function > > produces the same output rather than the full SHA-1 hash producing the > > same > > output, see above). The second input value can't be chosen by the > > attacker, > > so the chances of forging a signature on structured data like a > > certificate > > or CMS/PGP message are fairly remote. > > > > So while it's a very interesting result, it's more a hint to consider > moving > > to something else rather than time to hit the panic button. RIPEMD-160 > > still > > looks fairly secure, my gut feeling is that its dual-path construction is > > safer than the SHA-1 derived SHA-256 et al, but I suspect that in the > light > > of > > the current work on attacking UFN-based designs we'll be seeing a pile of > > new > > non-UFN hash functions in the same way that differential cryptanalysis > > spurred > > a burst of work on new ciphers. > > > > > > > > Richard A. Guida > > Director, Information Security > > > > Johnson & Johnson > > Room GS8217 > > 410 George Street > > New Brunswick, New Jersey 08901 > > Phone: 732 524 3785 > > > > -----Original Message----- > > From: Jeff Williams [mailto:jwkckid1@IX.NETCOM.COM] > > Sent: Thursday, February 17, 2005 6:09 AM > > To: ST-ISC@MAIL.ABANET.ORG > > Subject: Re: SHA-1 collisions found > > > > Austina and all, > > > > I know and knew exactly what I said. SHA-1 IS broken, no > > doubt about it... > > > > And no, it is not just "Found" Collisions. If you read the peace > > I originally provided CAREFULLY you would know that.. Such > > characterizations is what in some quarters of the security and crypto > > professionals why some if not many breaches occur and compromises > > of some if not allot of significant damage and sometimes not noticed > > or recognized for a significant amount of time... > > > > Also see: > > http://pluralsight.com/blogs/keith/archive/2005/02/16/5907.aspx > > > > Austin R. wrote: > > > > > Jeff, > > > Again...SHA-1 is not broken. Broken means that you have a way to > extract > > > the plaintext from it, or at least reliably change the contents. SHA-1 > > has > > > just become the focus of current attempts of cryptanalysis, and as a > > result > > > (that and because it's aging like any hash) people have found > collisions. > > > As I have explicitly said numerous times, be careful in your terminology > > > because this: "SHA-1 is broken without a doubt" is wrong. Also, realize > > > that saying it's not is not "rhetorical backpedalling by some of [your] > > > colleagues," they're just correctly interpreting what collisions mean. > I > > > won't go back into this, but all hashes have collisions. That's how > > hashes > > > work Jeff...it's mathematics. The "breaking" involves being able to > > change > > > the contents or extract from the hash, which you as of now cannot still > > do. > > > > > > ---------------------------------------------------------------------- > > > Gavon (Austin) Renfroe > > > BSEE, BA Math, University of Texas at Austin Class of 2004 > > > Emory School of Law Class of 2007 > > > > > > -----Original Message----- > > > From: Information Security Committee [mailto:ST-ISC@MAIL.ABANET.ORG] On > > > Behalf Of Jeff Williams > > > Sent: Thursday, February 17, 2005 2:13 AM > > > To: ST-ISC@MAIL.ABANET.ORG > > > Subject: Re: SHA-1 collisions found > > > > > > Chas and all, > > > > > > Adi is right, not all collisions indicate a hash is broken. However > with > > > the number of collisions now known and more expected very soon, > > > SHA-1 is broken without a doubt, despite rhetorical backpedalling by > > > some of my colleagues.. The evidance is overwhelming and expanding > > > almost daily regarding SHA-1 and other hashes... > > > > > > Merrill, Charles wrote: > > > > > > > (disclaimer--I am an attorney, not qualified to comment on crypto). > > > Yesterday at the morning Crypto session here at the RSA conference, Adi > > > Shamir commented on the 69 rounds announcement by the Chinese team, to > put > > > it in practical context. He reminded that a hash "collision" is not the > > same > > > as functionally "broken". A collision is a pair of messages that share > the > > > same hash result with an astronomical probability of having no > practical > > > resemblance to each other -- something far less than demonstration of > the > > > ability to work the one way function backward. Nonetheless he advocated > > > continued progress toward stronger hash algrithms, remarkimg that some > > day > > > collisions might become grist for an attorney trying to undermine a pki > > > digital signature with expert testimony to the effect that there are > > > theoretical chinks in the one-way-ness of the hash that is incorporated > in > > > the digital signature. Chas > > > > > > > > -----Original Message----- > > > > From: Jeff Williams [mailto:jwkckid1@IX.NETCOM.COM] > > > > Sent: Wed Feb 16 02:10:22 2005 > > > > To: ST-ISC@MAIL.ABANET.ORG > > > > Subject: SHA-1 collisions found > > > > > > > > All, > > > > > > > > SHA-1 broken, again.. > > > > > > > > http://www.schneier.com/blog/archives/2005/02/sha1_broken.html > > > > > > > > Excerpts: > > > > > > > > SHA-1 has been broken. Not a reduced-round version. Not a simplified > > > > version. The real thing. > > > > > > > > The research team of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu > > > > (mostly from Shandong University in China) have been quietly > circulating > > > > a paper announcing their results: > > > > > > > > collisions in the the full SHA-1 in 2**69 hash operations, much less > > > > than the brute-force attack of 2**80 operations based on the hash > > > > length. > > > > > > > > collisions in SHA-0 in 2**39 operations. > > > > > > > > collisions in 58-round SHA-1 in 2**33 operations. > > > > > > > > This attack builds on previous attacks on SHA-0 and SHA-1, and is a > > > > major, major cryptanalytic result. It pretty much puts a bullet into > > > > SHA-1 as a hash function for digital signatures (although it doesn't > > > > affect applications such as HMAC where collisions aren't important). > > > > > > > > Regards > > > > > > > > -- > > > > Jeffrey A. Williams > > > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > > > > "Be precise in the use of words and expect precision from others" - > > > > Pierre Abelard > > > > > > > > "If the probability be called P; the injury, L; and the burden, B; > > > > liability depends upon whether B is less than L multiplied by > > > > P: i.e., whether B is less than PL." > > > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > > > =============================================================== > > > > Updated 1/26/04 > > > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > > > IDNS. div. of Information Network Eng. INEG. INC. > > > > E-Mail jwkckid1@ix.netcom.com > > > > Registered Email addr with the USPS > > > > Contact Number: 214-244-4827 > > > > > > > > Your e-mail address will only be used within the ABA and its entities. > > > > We do not sell or rent e-mail addresses to anyone outside the ABA. > > > > > > > > To change your e-mail address or remove your name from any future > > general > > > distribution e-mails you can call us at 1-800-285-2221 or write to: > > > > > > > > American Bar Association > > > > Service Center > > > > 321 N Clark Street > > > > Chicago, IL 60610 > > > > > > > > To unsubscribe send the following in the body of a message to > > > > listserv@abanet.org - unsubscribe st-isc > > > > > > > > To review our privacy statement, go to > > > > http://www.abanet.org/privacy_statement.html. > > > > > > > > This email message from the law firm of McCarter & English, LLP is for > > the > > > sole use of the intended recipient(s)and may contain confidential and > > > privileged information. Any unauthorized review, use, disclosure or > > > distribution is prohibited. If you are not the intended recipient, > please > > > contact the sender by reply email(or helpdesk@mccarter.com) and destroy > > all > > > copies of the original message. > > > > > > > > Your e-mail address will only be used within the ABA and its entities. > > > > We do not sell or rent e-mail addresses to anyone outside the ABA. > > > > > > > > To change your e-mail address or remove your name from any future > > general > > > distribution e-mails you can call us at 1-800-285-2221 or write to: > > > > > > > > American Bar Association > > > > Service Center > > > > 321 N Clark Street > > > > Chicago, IL 60610 > > > > > > > > To unsubscribe send the following in the body of a message to > > > > listserv@abanet.org - unsubscribe st-isc > > > > > > > > To review our privacy statement, go to > > > > http://www.abanet.org/privacy_statement.html. > > > > > > Regards, > > > > > > -- > > > Jeffrey A. Williams > > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > > > "Be precise in the use of words and expect precision from others" - > > > Pierre Abelard > > > > > > "If the probability be called P; the injury, L; and the burden, B; > > > liability depends upon whether B is less than L multiplied by > > > P: i.e., whether B is less than PL." > > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > > =============================================================== > > > Updated 1/26/04 > > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > > IDNS. div. of Information Network Eng. INEG. INC. > > > E-Mail jwkckid1@ix.netcom.com > > > Registered Email addr with the USPS > > > Contact Number: 214-244-4827 > > > > > > Your e-mail address will only be used within the ABA and its entities. > > > We do not sell or rent e-mail addresses to anyone outside the ABA. > > > > > > To change your e-mail address or remove your name from any future > general > > > distribution e-mails you can call us at 1-800-285-2221 or write to: > > > > > > American Bar Association > > > Service Center > > > 321 N Clark Street > > > Chicago, IL 60610 > > > > > > To unsubscribe send the following in the body of a message to > > > listserv@abanet.org - unsubscribe st-isc > > > > > > To review our privacy statement, go to > > > http://www.abanet.org/privacy_statement.html. > > > > > > Your e-mail address will only be used within the ABA and its entities. > > > We do not sell or rent e-mail addresses to anyone outside the ABA. > > > > > > To change your e-mail address or remove your name from any future > general > > distribution e-mails you can call us at 1-800-285-2221 or write to: > > > > > > American Bar Association > > > Service Center > > > 321 N Clark Street > > > Chicago, IL 60610 > > > > > > To unsubscribe send the following in the body of a message to > > > listserv@abanet.org - unsubscribe st-isc > > > > > > To review our privacy statement, go to > > > http://www.abanet.org/privacy_statement.html. > > > > Regards, > > > > -- > > Jeffrey A. Williams > > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > > "Be precise in the use of words and expect precision from others" - > > Pierre Abelard > > > > "If the probability be called P; the injury, L; and the burden, B; > > liability depends upon whether B is less than L multiplied by > > P: i.e., whether B is less than PL." > > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > > =============================================================== > > Updated 1/26/04 > > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > > IDNS. div. of Information Network Eng. INEG. INC. > > E-Mail jwkckid1@ix.netcom.com > > Registered Email addr with the USPS > > Contact Number: 214-244-4827 > > > > Your e-mail address will only be used within the ABA and its entities. > > We do not sell or rent e-mail addresses to anyone outside the ABA. > > > > To change your e-mail address or remove your name from any future general > > distribution e-mails you can call us at 1-800-285-2221 or write to: > > > > American Bar Association > > Service Center > > 321 N Clark Street > > Chicago, IL 60610 > > > > To unsubscribe send the following in the body of a message to > > listserv@abanet.org - unsubscribe st-isc > > > > To review our privacy statement, go to > > http://www.abanet.org/privacy_statement.html. > > > > Your e-mail address will only be used within the ABA and its entities. > > We do not sell or rent e-mail addresses to anyone outside the ABA. > > > > To change your e-mail address or remove your name from any future general > distribution e-mails you can call us at 1-800-285-2221 or write to: > > > > American Bar Association > > Service Center > > 321 N Clark Street > > Chicago, IL 60610 > > > > To unsubscribe send the following in the body of a message to > > listserv@abanet.org - unsubscribe st-isc > > > > To review our privacy statement, go to > > http://www.abanet.org/privacy_statement.html. > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1@ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 > > Your e-mail address will only be used within the ABA and its entities. > We do not sell or rent e-mail addresses to anyone outside the ABA. > > To change your e-mail address or remove your name from any future general > distribution e-mails you can call us at 1-800-285-2221 or write to: > > American Bar Association > Service Center > 321 N Clark Street > Chicago, IL 60610 > > To unsubscribe send the following in the body of a message to > listserv@abanet.org - unsubscribe st-isc > > To review our privacy statement, go to > http://www.abanet.org/privacy_statement.html. -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Feb 18 01:33:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05016; Fri, 18 Feb 2005 01:33:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2239-0006vw-OX; Fri, 18 Feb 2005 01:55:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21ev-0000Mg-Ao; Fri, 18 Feb 2005 01:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D21dw-0007jD-3q for tls@megatron.ietf.org; Fri, 18 Feb 2005 01:29:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04767 for ; Fri, 18 Feb 2005 01:29:35 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D21zV-0006qn-GV for tls@ietf.org; Fri, 18 Feb 2005 01:51:56 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id EB69E17063; Thu, 17 Feb 2005 22:32:55 -0800 (PST) To: Jeff Williams Subject: Re: [TLS] Re: SHA-1 collisions found References: <200502172047.1d202T35r3NZFpL0@mx-a065b05.pas.sa.earthlink.net> <4215A1FB.6D85E1DE@ix.netcom.com> From: Eric Rescorla Date: Thu, 17 Feb 2005 22:32:55 -0800 In-Reply-To: <4215A1FB.6D85E1DE@ix.netcom.com> (Jeff Williams's message of "Fri, 18 Feb 2005 00:06:23 -0800") Message-ID: <86u0oabco8.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: TLS List , "Austin R." X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Jeff Williams writes: > I never said that DES had anything to do with identity theft directly. > So such a mischaracterization is of your own interpratation of what > I did say. What I did say was the following again: "it is clear that > moving away from DES/3DES and SHA-1 is necessary and IMHO > amongst a growing number of other security professionals as well > as the NIST, long overdue due to identity theft and other security > related very real concerns.." > > Yes your right that 3DES is not directly used to authenticate identities, > and breaks in SHA-1 can't be used directly to forge identities as you > state it in your remarks. However indirectly and/or as result in the > use of cybersuites in TLS/SSL where SHA-1 is one hash used and > 3DES is included, the "Stealing" of identities and/or misuse can be > achieved... This strikes me as a dubious claim given our current level of cryptoanalytic sucess. In particular, it appears unlikely that the collision attacks on SHA-1 can be used to mount a successful attack on either the HMAC-SHA function used for message integrity in SSL/TLS or the HMAC-SHA-based PRF function used to generate the keying material. The only plausible point of attack on SSL/TLS at the present time is against the certificate infrastructure and even that looks to require a very large amount of effort with only a modest probability of success. I don't know of any useful attacks on 3DES in particular that could plausibly be used to perform identity theft. (The CBC-based attacks don't depend on 3DES and can also be used against AES.) > Hence, the movement away from the SHA-1 hash as > well as BTW it's siblings SHA-256 and SHA-512 would be advisible > as soon as can be achieved. It's not actually clear that SHA-256 will be more resistant to this line of cryptanalyis. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Fri Feb 18 05:19:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14465; Fri, 18 Feb 2005 05:19:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D25aQ-0003mo-6t; Fri, 18 Feb 2005 05:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D25By-0006jM-HE; Fri, 18 Feb 2005 05:16:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2534-0003Iy-9o for tls@megatron.ietf.org; Fri, 18 Feb 2005 05:07:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13589 for ; Fri, 18 Feb 2005 05:07:44 -0500 (EST) Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D25Oi-0003XR-0h for tls@ietf.org; Fri, 18 Feb 2005 05:30:08 -0500 Received: from 1cust223.tnt36.dfw9.da.uu.net ([67.234.81.223] helo=ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1D2522-0005Im-00; Fri, 18 Feb 2005 05:06:43 -0500 Message-ID: <4215D8FD.268F933D@ix.netcom.com> Date: Fri, 18 Feb 2005 04:01:08 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] Re: SHA-1 collisions found References: <200502172047.1d202T35r3NZFpL0@mx-a065b05.pas.sa.earthlink.net> <4215A1FB.6D85E1DE@ix.netcom.com> <86u0oabco8.fsf@romeo.rtfm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: TLS List , "Austin R." X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Eric and all, Eric Rescorla wrote: > Jeff Williams writes: > > I never said that DES had anything to do with identity theft directly. > > So such a mischaracterization is of your own interpratation of what > > I did say. What I did say was the following again: "it is clear that > > moving away from DES/3DES and SHA-1 is necessary and IMHO > > amongst a growing number of other security professionals as well > > as the NIST, long overdue due to identity theft and other security > > related very real concerns.." > > > > Yes your right that 3DES is not directly used to authenticate identities, > > and breaks in SHA-1 can't be used directly to forge identities as you > > state it in your remarks. However indirectly and/or as result in the > > use of cybersuites in TLS/SSL where SHA-1 is one hash used and > > 3DES is included, the "Stealing" of identities and/or misuse can be > > achieved... > This strikes me as a dubious claim given our current level of > cryptoanalytic sucess. In particular, it appears unlikely that the > collision attacks on SHA-1 can be used to mount a successful attack on > either the HMAC-SHA function used for message integrity in SSL/TLS or > the HMAC-SHA-based PRF function used to generate the keying > material. The only plausible point of attack on SSL/TLS at the present > time is against the certificate infrastructure and even that looks to > require a very large amount of effort with only a modest probability > of success. Agreed to a point to your reasoned response here. But not entirely for reasons I believe I have already articulated as it appears have others. I would think it wise to address this problem form a worst case point of view than otherwise as the latter has potentially very damaging consequences... > > > I don't know of any useful attacks on 3DES in particular that > could plausibly be used to perform identity theft. (The CBC-based > attacks don't depend on 3DES and can also be used against AES.) No attacks/hacks I know of in particular have been directed to perform identity theft either, yet. > > > > Hence, the movement away from the SHA-1 hash as > > well as BTW it's siblings SHA-256 and SHA-512 would be advisible > > as soon as can be achieved. > It's not actually clear that SHA-256 will be more resistant to > this line of cryptanalyis. That was my point, as I believe NIST has been discovering... > > > -Ekr Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Wed Feb 23 23:17:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15278; Wed, 23 Feb 2005 23:17:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4AoX-0002Yq-Ku; Wed, 23 Feb 2005 23:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43c2-00008Y-92; Wed, 23 Feb 2005 16:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43by-00007c-3P; Wed, 23 Feb 2005 15:59:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16018; Wed, 23 Feb 2005 15:59:55 -0500 (EST) Message-Id: <200502232059.PAA16018@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 23 Feb 2005 15:59:55 -0500 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-06.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) Author(s) : P. Eronen, H. Tschofenig Filename : draft-ietf-tls-psk-06.txt Pages : 17 Date : 2005-2-23 This document specifies three sets of new ciphersuites for the Transport Layer Security (TLS) protocol to support authentication based on pre-shared keys. These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key; and the third set combines public key authentication of the server with pre-shared key authentication of the client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-psk-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-psk-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-23160037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-23160037.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@ietf.org Mon Feb 28 00:36:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12382; Mon, 28 Feb 2005 00:36:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5dau-00062u-W5; Mon, 28 Feb 2005 00:37:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5dYo-0005pj-B9; Mon, 28 Feb 2005 00:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5dYj-0005pa-7w for tls@megatron.ietf.org; Mon, 28 Feb 2005 00:35:12 -0500 Received: from mail2.funk.com ([199.103.155.98]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12339 for ; Mon, 28 Feb 2005 00:35:06 -0500 (EST) Received: from paulxeon.funk.com (paulxeon [172.16.10.10]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G0XM1; Mon, 28 Feb 2005 00:32:20 -0500 Message-Id: <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> X-Sender: paul@mail3.funk.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Feb 2005 00:35:25 -0500 To: tls@ietf.org From: Paul Funk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hannes Tschofenig , "Hardjono, Thomas" , "Smith, Ned" , Tschofenig Hannes Subject: [TLS] new TLS extension: "Inner Application" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f I'd like to solicit comment on the following draft: http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-01.txt This draft defines a new TLS extension that allows authentication or other information exchange to occur under the protection of the TLS handshake and prior to exchange of upper-layer data. This permits a TLS session to be secured by EAP authentication in addition to TLS authentication, allows either party to interrogate the "endpoint integrity" status of the other, etc., prior to proceeding with data exchange. It is also intended to serve as a means to perform layer 3 authentication and negotiation of security parameters for additional communication channels. Finally, it serves as the basis for the EAP-TTLS authentication protocol. The authors are hopeful that this draft will be of interest to members of the working group. Our intention is to take this to proposed standard RFC status. Thank you very much, Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Feb 28 01:23:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15901; Mon, 28 Feb 2005 01:23:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5eKd-0006oU-6p; Mon, 28 Feb 2005 01:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5eHW-00028f-4A; Mon, 28 Feb 2005 01:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5eHT-000236-6O for tls@megatron.ietf.org; Mon, 28 Feb 2005 01:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15696 for ; Mon, 28 Feb 2005 01:21:22 -0500 (EST) Received: from smtp-out3.blueyonder.co.uk ([195.188.213.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5eI8-0006lw-VC for tls@ietf.org; Mon, 28 Feb 2005 01:22:06 -0500 Received: from [127.0.0.1] ([82.42.16.116]) by smtp-out3.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 06:21:54 +0000 Message-ID: <4222B84D.9030906@blueyonder.co.uk> Date: Mon, 28 Feb 2005 06:21:01 +0000 From: David Hopwood User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] new TLS extension: "Inner Application" References: <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> In-Reply-To: <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2005 06:21:54.0717 (UTC) FILETIME=[CC5454D0:01C51D5D] X-Spam-Score: 2.1 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Paul Funk wrote: > I'd like to solicit comment on the following draft: > > http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-01.txt > > This draft defines a new TLS extension that allows authentication or other > information exchange to occur under the protection of the TLS handshake and > prior to exchange of upper-layer data. This permits a TLS session to be > secured by EAP authentication in addition to TLS authentication, allows either > party to interrogate the "endpoint integrity" status of the other, etc., prior > to proceeding with data exchange. It is also intended to serve as a means to > perform layer 3 authentication and negotiation of security parameters for > additional communication channels. Finally, it serves as the basis for the > EAP-TTLS authentication protocol. An obvious alternative is to strictly layer the authentication protocol over TLS, e.g. "application / EAP / TLS / TCP / IP". That appears to me to be simpler, so what is the technical motivation for using new TLS record ContentTypes instead? -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Feb 28 01:44:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18101; Mon, 28 Feb 2005 01:44:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ef0-0007BN-F6; Mon, 28 Feb 2005 01:45:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5edd-0000Vc-Nl; Mon, 28 Feb 2005 01:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5edY-0000Um-Oy for tls@megatron.ietf.org; Mon, 28 Feb 2005 01:44:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18066 for ; Mon, 28 Feb 2005 01:44:12 -0500 (EST) Received: from [199.103.155.98] (helo=mail2.funk.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5eeF-0007AQ-Nv for tls@ietf.org; Mon, 28 Feb 2005 01:44:56 -0500 Received: from paulxeon.funk.com (paulxeon [172.16.10.10]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G0X3V; Mon, 28 Feb 2005 01:41:46 -0500 Message-Id: <5.2.0.9.2.20050228013254.032db600@mail3.funk.com> X-Sender: paul@mail3.funk.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Feb 2005 01:44:52 -0500 To: david.nospam.hopwood@blueyonder.co.uk, tls@ietf.org From: Paul Funk Subject: Re: [TLS] new TLS extension: "Inner Application" In-Reply-To: <4222B84D.9030906@blueyonder.co.uk> References: <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 06:21 AM 2/28/2005 +0000, David Hopwood wrote: >Paul Funk wrote: >>I'd like to solicit comment on the following draft: >>http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-01.txt >> >>This draft defines a new TLS extension that allows authentication or other >>information exchange to occur under the protection of the TLS handshake and >>prior to exchange of upper-layer data. This permits a TLS session to be >>secured by EAP authentication in addition to TLS authentication, allows >>either party to interrogate the "endpoint integrity" status of the other, >>etc., prior >>to proceeding with data exchange. It is also intended to serve as a means to >>perform layer 3 authentication and negotiation of security parameters for >>additional communication channels. Finally, it serves as the basis for the >>EAP-TTLS authentication protocol. > >An obvious alternative is to strictly layer the authentication protocol >over TLS, e.g. "application / EAP / TLS / TCP / IP". That appears to me >to be simpler, so what is the technical motivation for using new TLS >record ContentTypes instead? The purpose is to separate the EAP authentication from the upper-layer data (e.g. HTTP). So the TLS session has three phases: TLS handshake, Inner Application (e.g. EAP authentication using new record type), then HTTP traffic. In effect, the TLS handshake plus the exchange under the new record type becomes an "extended handshake", allowing the data session to proceed only after both TLS handshake and EAP authentication. The intention is to provide a 3-phase model for HTTP or other TCP sessions, and provide a 2-phase model (TLS handshake, then authentication under new record type, but omitting any further data exchange) if just authentication is required. The 2-phase model would look like what you are suggesting. >-- >David Hopwood > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Feb 28 03:22:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17593; Mon, 28 Feb 2005 03:22:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5gBO-0000XB-Qc; Mon, 28 Feb 2005 03:23:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5g8m-0004Hm-O8; Mon, 28 Feb 2005 03:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5g8e-0004HF-S7 for tls@megatron.ietf.org; Mon, 28 Feb 2005 03:20:24 -0500 Received: from amsfep19-int.chello.nl ([213.46.243.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17406 for ; Mon, 28 Feb 2005 03:20:20 -0500 (EST) Received: from [192.168.0.138] (really [212.187.119.185]) by amsfep19-int.chello.nl (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP id <20050228081950.XTCA1799.amsfep19-int.chello.nl@[192.168.0.138]> for ; Mon, 28 Feb 2005 09:19:50 +0100 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] new TLS extension: "Inner Application" Date: Mon, 28 Feb 2005 09:20:23 +0100 User-Agent: KMail/1.7.2 References: <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> <5.2.0.9.2.20050228013254.032db600@mail3.funk.com> In-Reply-To: <5.2.0.9.2.20050228013254.032db600@mail3.funk.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200502280920.23571.nmav@gnutls.org> Content-Transfer-Encoding: 7bit X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Monday 28 February 2005 07:44, Paul Funk wrote: > >An obvious alternative is to strictly layer the authentication protocol > >over TLS, e.g. "application / EAP / TLS / TCP / IP". That appears to me > >to be simpler, so what is the technical motivation for using new TLS > >record ContentTypes instead? > The purpose is to separate the EAP authentication from the upper-layer > data (e.g. HTTP). You can separate that data by encapsulating the other protocol within the application data of tls. Ie you tag the data you want to distinguish. As I understood from the document the unique offer of TLS/IA comparing to TLS-PSK and TLS-SRP, is that it allows for client password based authentication using a challenge-responce protocol. Although it doesn't look a bad idea, in this draft, it is heavily separated from the TLS protocol --not part of the handshake, uses different record types, this AVP format etc, and that makes it look like an ugly plugin. Other than that the idea of exporting the TLS secret to other protocols does not really sound nice. Although I like the idea of adding challenge and responce protocols being added, i don't like the way. It is only EAP-related, and it can hardly benefit any other applications. > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@ietf.org Mon Feb 28 19:43:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27140; Mon, 28 Feb 2005 19:43:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vV3-0005Gz-EL; Mon, 28 Feb 2005 19:44:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5vQc-0006rK-RH; Mon, 28 Feb 2005 19:39:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5vQa-0006r4-Nj for tls@megatron.ietf.org; Mon, 28 Feb 2005 19:39:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26802 for ; Mon, 28 Feb 2005 19:39:53 -0500 (EST) Received: from [199.103.155.98] (helo=mail2.funk.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vRQ-0005CH-6S for tls@ietf.org; Mon, 28 Feb 2005 19:40:49 -0500 Received: from paulxeon.funk.com (paulxeon [172.16.10.10]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VP6G06FZ; Mon, 28 Feb 2005 19:37:26 -0500 Message-Id: <5.2.0.9.2.20050228191856.060997f8@mail3.funk.com> X-Sender: paul@mail3.funk.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Feb 2005 19:40:32 -0500 To: Nikos Mavrogiannopoulos , tls@ietf.org From: Paul Funk Subject: Re: [TLS] new TLS extension: "Inner Application" In-Reply-To: <200502280920.23571.nmav@gnutls.org> References: <5.2.0.9.2.20050228013254.032db600@mail3.funk.com> <5.2.0.9.2.20050228001608.05df2b40@mail3.funk.com> <5.2.0.9.2.20050228013254.032db600@mail3.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@ietf.org Errors-To: tls-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc At 09:20 AM 2/28/2005 +0100, Nikos Mavrogiannopoulos wrote: >On Monday 28 February 2005 07:44, Paul Funk wrote: > > > >An obvious alternative is to strictly layer the authentication protocol > > >over TLS, e.g. "application / EAP / TLS / TCP / IP". That appears to me > > >to be simpler, so what is the technical motivation for using new TLS > > >record ContentTypes instead? > > The purpose is to separate the EAP authentication from the upper-layer > > data (e.g. HTTP). >You can separate that data by encapsulating the other protocol within the >application data of tls. Ie you tag the data you want to distinguish. Well, a new record type is a good way to do the tagging. The idea is that the TLS data endpoints shouldn't have to distinguish authentication data from their own data. So the TLS engine handles TLS handshake and authentication via new record type, and only emits the data to the upper layer application that it is interested in. This would allow, for example, a bump in the wire to perform the TLS handshake and inner application protocols, and expose a simple unencrypted data stream to a backend server. >As I understood from the document the unique offer of TLS/IA comparing >to TLS-PSK and TLS-SRP, is that it allows for client password based >authentication using a challenge-responce protocol. Although it doesn't >look a bad idea, in this draft, it is heavily separated from the TLS protocol >--not part of the handshake, uses different record types, this AVP format >etc, >and that makes it look like an ugly plugin. >Other than that the idea of exporting the TLS secret to other protocols does >not really sound nice. One of the intentions of the protocol is independence of the inner application from the TLS handshake. This means that the confidence in the TLS handshake itself need not be re-examined. Another intention is that arbitrary information exchange be possible within the tunnel created by the TLS handshake. TLS itself is very regimented, and for good reason. So, yes, the data within the new record type is very un-TLS, and it occurs after the base TLS security has been established via the regimented handshake. Once the handshake is complete, a more free-form exchange is possible. The reason that the Diameter AVP format was chosen is for compatibility with the RADIUS/Diameter infrastructure, with which much of the anticipated inner application traffic will have to interoperate. >Although I like the idea of adding challenge and responce protocols being >added, i don't like the way. It is only EAP-related, and it can hardly >benefit any other applications. It's more than just EAP-related. Any sequence of Diameter AVPs may be used; EAP is just one example. Plus, Diameter provides for vendor extensions. So it is possible to define any inner application you like; authentication is one, key agreement for an additional data channel might be another, endpoint integrity a third, etc. > > Paul Funk > > Funk Software, Inc. > > 617 497-6339 > > paul@funk.com > >-- >Nikos Mavrogiannopoulos > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls