From tls-bounces@lists.ietf.org Mon Feb 06 12:35:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6AGj-0006fs-9i; Mon, 06 Feb 2006 12:35:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6AGh-0006fU-41 for tls@megatron.ietf.org; Mon, 06 Feb 2006 12:35:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06457 for ; Mon, 6 Feb 2006 12:33:26 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6ASm-0002J5-C2 for tls@ietf.org; Mon, 06 Feb 2006 12:47:45 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUA002T31EC07@szxga02-in.huawei.com> for tls@ietf.org; Tue, 07 Feb 2006 01:47:00 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUA00M791EBTI@szxga02-in.huawei.com> for tls@ietf.org; Tue, 07 Feb 2006 01:47:00 +0800 (CST) Received: from [10.18.18.211] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPSA id <0IUA003AQ1K00B@szxml01-in.huawei.com> for tls@ietf.org; Tue, 07 Feb 2006 01:50:26 +0800 (CST) Date: Mon, 06 Feb 2006 23:04:52 +0530 From: jimmy To: tls@ietf.org Message-id: <43E788BC.7080309@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7BIT Cc: Subject: [TLS] empty trustedauthorities list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, Is there a possible scenario when a client could send an empty TrustedAuthorities message, i.e., with 0 bytes of TrustedAuthority. Thanks in advance, jimmy _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 06 12:52:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6AXK-0001jT-67; Mon, 06 Feb 2006 12:52:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6AXI-0001iu-8W for tls@megatron.ietf.org; Mon, 06 Feb 2006 12:52:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07560 for ; Mon, 6 Feb 2006 12:50:31 -0500 (EST) Received: from revol3.enst.fr ([137.194.2.10] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6AjJ-0003HI-OO for tls@ietf.org; Mon, 06 Feb 2006 13:04:51 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id A6ABD5D5B; Mon, 6 Feb 2006 18:52:09 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol3.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55745-02; Mon, 6 Feb 2006 18:52:09 +0100 (CET) Received: from infres.enst.fr (infres.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 08DA05C64; Mon, 6 Feb 2006 18:52:08 +0100 (CET) Received: from enst.fr (mechmech.enst.fr [137.194.164.56]) by infres.enst.fr (Postfix) with ESMTP id 9F2DA13CBC; Mon, 6 Feb 2006 18:52:08 +0100 (MET) Message-ID: <43E78CC2.8070009@enst.fr> Date: Mon, 06 Feb 2006 18:52:02 +0100 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: jimmy Subject: Re: [TLS] empty trustedauthorities list References: <43E788BC.7080309@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Jimmy, I think that you can use TrustAuthority extension which can be sent=20 empty (the client may include none, some, or all of the CA root keys=20 they possess in this extension) struct { TrustedAuthority trusted_authorities_list<0..2^16-1>; } TrustedAuthorities; More details could be found in section 3.4 of RFC 3546. Best regards, Badra jimmy a =E9crit: > Hi, > > Is there a possible scenario when a client could send an empty=20 > TrustedAuthorities message, i.e., with 0 bytes of TrustedAuthority. > > > Thanks in advance, > jimmy > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 06 13:03:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ai5-0003yM-AH; Mon, 06 Feb 2006 13:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ai3-0003xR-DI for tls@megatron.ietf.org; Mon, 06 Feb 2006 13:03:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08433 for ; Mon, 6 Feb 2006 13:01:40 -0500 (EST) Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Au6-0003qz-Lx for tls@ietf.org; Mon, 06 Feb 2006 13:16:00 -0500 Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id k16I33i21678; Mon, 6 Feb 2006 19:03:03 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Mon, 6 Feb 2006 19:03:03 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA03398; Mon, 6 Feb 2006 19:03:02 +0100 (MET) Message-ID: <43E78D1D.1080507@edelweb.fr> Date: Mon, 06 Feb 2006 18:53:33 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: jimmy Subject: Re: [TLS] empty trustedauthorities list References: <43E788BC.7080309@huawei.com> In-Reply-To: <43E788BC.7080309@huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0356106816==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0356106816== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030601090209000409090901" This is a cryptographically signed message in MIME format. --------------ms030601090209000409090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit The option to include no CA root keys is included to allow the client to indicate possession of some pre-defined set of CA root keys. jimmy wrote: > Hi, > > Is there a possible scenario when a client could send an empty > TrustedAuthorities message, i.e., with 0 bytes of TrustedAuthority. > > > Thanks in advance, > jimmy > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms030601090209000409090901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMjA2MTc1MzMzWjAjBgkqhkiG9w0B CQQxFgQUOrp0FMD8uKiqENmwY/Mtg3oToNAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAnKbH5Odl6nZoyu1+ hy+TIli0AXUj9i2NWkCeKwnK6JrceEv7Gt3LVTCOKbJexxpJNwq7hT8KHBJk/IXmRBYuyTHq Kjhc1TpjYOZtHaJ1uhg2bMCOlm2KHC/9G2zpxPHPS9bg/v8CpBRD8NYbO/nOuo/Vs/8MYTRg JM4fZHSTL8QAAAAAAAA= --------------ms030601090209000409090901-- --===============0356106816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0356106816==-- From tls-bounces@lists.ietf.org Mon Feb 06 14:04:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BfU-0003CQ-2o; Mon, 06 Feb 2006 14:04:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BfQ-0003Ar-HX for tls@megatron.ietf.org; Mon, 06 Feb 2006 14:04:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12965 for ; Mon, 6 Feb 2006 14:02:55 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6BrO-0007MS-HQ for tls@ietf.org; Mon, 06 Feb 2006 14:17:15 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id B5DC71E8C4C; Mon, 6 Feb 2006 11:04:25 -0800 (PST) To: Sami Lehtinen Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt References: <43C5FF00.5040704@ssh.com> From: Eric Rescorla Date: Mon, 06 Feb 2006 11:04:25 -0800 In-Reply-To: <43C5FF00.5040704@ssh.com> (Sami Lehtinen's message of "Thu, 12 Jan 2006 09:02:24 +0200") Message-ID: <868xsogvgm.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Sami Lehtinen writes: > Hello, > > In section 6.2.3.2. CBC block cipher: > > The encrypted data length (TLSCiphertext.length) is one more than the > sum of TLSCompressed.length, CipherSpec.hash_size, and > padding_length. > > Should this be: > > The encrypted data length (TLSCiphertext.length) is one more than the > sum of CipherSpec.block_length, TLSCompressed.length, > ^^^^^^^^^^^^^^^^^^^^^^^^^ > CipherSpec.hash_size, and padding_length. > > to accommondate for the explicit IV? I've reviewed this and I believe this is incorrect. You can form the explicit IV by encrypting a non-explicit IV, but it's not properly part of the ciphertext. Best, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 07 04:07:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ooq-0001aU-Ny; Tue, 07 Feb 2006 04:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Oop-0001U9-0q for tls@megatron.ietf.org; Tue, 07 Feb 2006 04:07:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05336 for ; Tue, 7 Feb 2006 04:05:40 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6P15-0007Se-FL for tls@ietf.org; Tue, 07 Feb 2006 04:20:08 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUB00GNB8B505@szxga03-in.huawei.com> for tls@ietf.org; Tue, 07 Feb 2006 17:13:53 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUB00KA78B57E@szxga03-in.huawei.com> for tls@ietf.org; Tue, 07 Feb 2006 17:13:53 +0800 (CST) Received: from [10.18.18.211] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPSA id <0IUB003668PPUU@szxml01-in.huawei.com>; Tue, 07 Feb 2006 17:22:39 +0800 (CST) Date: Tue, 07 Feb 2006 14:36:58 +0530 From: jimmy Subject: Re: [TLS] empty trustedauthorities list In-reply-to: <43E78D1D.1080507@edelweb.fr> To: Peter Sylvester Message-id: <43E86332.3080302@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) References: <43E788BC.7080309@huawei.com> <43E78D1D.1080507@edelweb.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Peter Sylvester wrote: > The option to include no CA root keys is included to allow the client > to indicate possession of some pre-defined set of CA root keys. > > Is this the same as pre_agreed? In that case the list size is not '0'. Does list size '0' signify anything else? > jimmy wrote: >> Hi, >> >> Is there a possible scenario when a client could send an empty >> TrustedAuthorities message, i.e., with 0 bytes of TrustedAuthority. >> >> >> Thanks in advance, >> jimmy >> >> _______________________________________________ >> TLS mailing list >> TLS@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/tls >> >> > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 09 12:53:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Fz0-0004Wn-Rv; Thu, 09 Feb 2006 12:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Fwk-0004DL-Q7 for tls@megatron.ietf.org; Thu, 09 Feb 2006 12:51:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13136 for ; Thu, 9 Feb 2006 12:49:27 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F7G9a-0000ef-7Y for tls@ietf.org; Thu, 09 Feb 2006 13:04:27 -0500 Received: (qmail 7870 invoked by uid 0); 9 Feb 2006 17:51:03 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.48) by woodstock.binhost.com with SMTP; 9 Feb 2006 17:51:03 -0000 Message-Id: <7.0.0.16.2.20060209124651.05bf8348@vigilsec.com> Message-Id: <7.0.0.16.2.20060209124606.05c013e8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Feb 2006 12:51:05 -0500 To: tls@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mark@redphonesecurity.com Subject: [TLS] Please review draft-housley-tls-authz-extns-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Dear TLS Working Group: I am the co-author of this document. If the TLS WG is interested in making this a WG work item, that is fine with me. If not, I am also willing to see it progress as a standards-track individual submission. Either way, I would really appreciate the TLS WG review and comment. http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-00.txt Thanks, Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 13 03:03:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8YgD-0003qC-DG; Mon, 13 Feb 2006 03:03:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8YgB-0003q2-BB for tls@megatron.ietf.org; Mon, 13 Feb 2006 03:03:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23599 for ; Mon, 13 Feb 2006 03:01:41 -0500 (EST) Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8Ytg-0006ZT-Nm for tls@ietf.org; Mon, 13 Feb 2006 03:17:29 -0500 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id k1D83KK6010331 for ; Mon, 13 Feb 2006 10:03:20 +0200 (EET) Received: (qmail 517 invoked from network); 13 Feb 2006 08:03:20 -0000 Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 13 Feb 2006 08:03:20 -0000 Message-ID: <43F03D43.5060604@ssh.com> Date: Mon, 13 Feb 2006 10:03:15 +0200 From: Sami Lehtinen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt References: <43C5FF00.5040704@ssh.com> <868xsogvgm.fsf@raman.networkresonance.com> In-Reply-To: <868xsogvgm.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > Sami Lehtinen writes: >>In section 6.2.3.2. CBC block cipher: >> >> The encrypted data length (TLSCiphertext.length) is one more than the >> sum of TLSCompressed.length, CipherSpec.hash_size, and >> padding_length. >> >>Should this be: >> >> The encrypted data length (TLSCiphertext.length) is one more than the >> sum of CipherSpec.block_length, TLSCompressed.length, >> ^^^^^^^^^^^^^^^^^^^^^^^^^ >> CipherSpec.hash_size, and padding_length. >> >>to accommondate for the explicit IV? > > > I've reviewed this and I believe this is incorrect. You can form the > explicit IV by encrypting a non-explicit IV, but it's not properly > part of the ciphertext. So, in your opinion the explicit IV length is _not_ added to the TLSCiphertext.length? Record layer implementation thus needs to take into account that we are running TLS1.1, have a block cipher (=> explicit IVs) and add CipherSpec.block_length (size of IV) to received record layer length when reading the record? From draft-ietf-tls-rfc2246-bis-13.txt: struct { ContentType type; ProtocolVersion version; uint16 length; select (CipherSpec.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; } fragment; } TLSCiphertext; [...] length The length (in bytes) of the following TLSCiphertext.fragment. The length may not exceed 2^14 + 2048. and fragment is: block-ciphered struct { opaque IV[CipherSpec.block_length]; opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher; To me, `length' specification above reads as "length = sizeof(GenericBlockCipher)", which would include the size of the IV. -- sjl@ssh.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 15:53:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZ4o-0002Pp-RQ; Sat, 18 Feb 2006 15:53:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZ4n-0002Pj-Oj for tls@ietf.org; Sat, 18 Feb 2006 15:53:09 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAZ4m-0007Mp-GU for tls@ietf.org; Sat, 18 Feb 2006 15:53:09 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 923E622241D for ; Sat, 18 Feb 2006 12:54:31 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 18 Feb 2006 12:53:06 -0800 From: Eric Rescorla Message-Id: <20060218205431.923E622241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [TLS] Spec integration for TLS 1.2? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I'm starting to write up the first draft of TLS 1.2 and it's seeming increasingly weird that we have a bunch of essentially core stuff that's not in the main TLS document. In particular: - Extensions (required for certificate algorithm signalling) - AES support Do people feel this stuff should be merged into the main document? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 15:59:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZAh-0002dY-W2; Sat, 18 Feb 2006 15:59:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZAh-0002dT-7I for tls@ietf.org; Sat, 18 Feb 2006 15:59:15 -0500 Received: from omr3.networksolutionsemail.com ([205.178.146.53] helo=mail.networksolutionsemail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAZAe-0007TT-OB for tls@ietf.org; Sat, 18 Feb 2006 15:59:15 -0500 Received: (qmail 6678 invoked from network); 18 Feb 2006 20:59:12 -0000 Received: from unknown (HELO mark2wks) (81.179.34.145) by omr3.mgt.bos.netsol.com with SMTP; 18 Feb 2006 20:59:12 -0000 From: "Mark Lewis" To: "Eric Rescorla" , Subject: RE: [TLS] Spec integration for TLS 1.2? Date: Sat, 18 Feb 2006 21:03:50 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20060218205431.923E622241D@laser.networkresonance.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mark@mjlnet.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I'm in favor of including the two elements you mention. Mark > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: 18 February 2006 20:53 > To: tls@ietf.org > Subject: [TLS] Spec integration for TLS 1.2? > > > I'm starting to write up the first draft of TLS 1.2 and it's > seeming increasingly weird that we have a bunch of essentially > core stuff that's not in the main TLS document. In particular: > > - Extensions (required for certificate algorithm signalling) > - AES support > > Do people feel this stuff should be merged into the main document? > > Thanks, > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 16:01:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZCQ-0002hT-6B; Sat, 18 Feb 2006 16:01:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZCP-0002hJ-1l for tls@ietf.org; Sat, 18 Feb 2006 16:01:01 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAZCN-0007US-PR for tls@ietf.org; Sat, 18 Feb 2006 16:01:01 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 583D522241D; Sat, 18 Feb 2006 13:02:21 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 18 Feb 2006 13:00:56 -0800 From: Eric Rescorla Message-Id: <20060218210221.583D522241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] Another potential error in TLS 1.1 (Auth 48) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Section 4.7 reads: In RSA signing, a 36-byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key). It is encoded with PKCS #1 block type 0 or type 1 as described in [PKCS1]. As far as I know, everyone uses block type 1, and this is just an error. Does anyone object to changing this to read "block type 1" in the Auth 48 edits? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 16:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZXb-000381-Di; Sat, 18 Feb 2006 16:22:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZXZ-00037w-RL for tls@ietf.org; Sat, 18 Feb 2006 16:22:53 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAZXW-0007uT-IM for tls@ietf.org; Sat, 18 Feb 2006 16:22:53 -0500 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 485A6FB286; Sat, 18 Feb 2006 16:22:49 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 40E753C0293; Sat, 18 Feb 2006 16:22:46 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Eric Rescorla Subject: Re: [TLS] Spec integration for TLS 1.2? In-Reply-To: (Your message of "Sat, 18 Feb 2006 12:53:06 PST.") <20060218205431.923E622241D@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Feb 2006 16:22:46 -0500 Message-Id: <20060218212246.40E753C0293@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org In message <20060218205431.923E622241D@laser.networkresonance.com>, Eric Rescor la writes: >I'm starting to write up the first draft of TLS 1.2 and it's >seeming increasingly weird that we have a bunch of essentially >core stuff that's not in the main TLS document. In particular: > >- Extensions (required for certificate algorithm signalling) >- AES support > >Do people feel this stuff should be merged into the main document? > Absolutely. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 16:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZoA-0003Wg-UM; Sat, 18 Feb 2006 16:40:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZo9-0003WW-M6 for tls@ietf.org; Sat, 18 Feb 2006 16:40:01 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAZo9-0008D0-Cd for tls@ietf.org; Sat, 18 Feb 2006 16:40:01 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 74DD722241D for ; Sat, 18 Feb 2006 13:41:25 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 18 Feb 2006 13:40:00 -0800 From: Eric Rescorla Message-Id: <20060218214125.74DD722241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [TLS] The TLS PRF X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org People will recall that the current TLS PRF uses HMAC_MD5 and HMAC_SHA1 in tandem. In [BR05], Steve and I recommended that this be amended to solely use HMAC_X where X is the hash algorithm defined as the hash function negotiated for the cipher suite. This has three major difficulties: 1. The TLS PRF is different from the one specified in NIST SP 800-56 S 5.8.1. The TLS PRF is approved only for parameter sets FA and EA, which themselves are only approved up to 2010. 2. The TLS PRF depends on a hash function and so can't be used with MAC algorithms that are not hash-based. So, for instance, you couldn't use CCM or GCM mode. (Note that this is an issue with the 800-56 KDF as well). 3. You can't use it with algorithm suites that define their own KDF, such as GOST and potentially Suite B. In some sense these are separable problems. I think clearly we need to specify a standard TLS KDF (and note that we also use the PRF in Finished), so that at least that KDF can be usable by all of the ciphersuites we currently have. And the recommendation to use the ciphersuite-negotiated hash function still seems sound. So, that leaves us with three questions: 1. Should the Hash-based PRF be based on the current PRF or NIST 800-56? 2. Should we define a standard non-Hash-based PRF? Where would we get it from? If not, what PRF should be used with GCM/CCM/etc.? 3. Should we allow the negotiation of ciphersuite-specific PRFs? Can we get some discussion this issue please? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 20:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAdQ1-0006ad-Ol; Sat, 18 Feb 2006 20:31:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAdPz-0006a5-JL; Sat, 18 Feb 2006 20:31:19 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAdPw-0003As-Ps; Sat, 18 Feb 2006 20:31:19 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 779CC22241D; Sat, 18 Feb 2006 17:32:38 -0800 (PST) To: ietf@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 18 Feb 2006 17:31:13 -0800 From: Eric Rescorla Message-Id: <20060219013238.779CC22241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: tls@ietf.org, iesg@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org BACKGROUND This document describes an extension to TLS which allows the client to give the server a hint (the User Principal Name) about which directory entry to look up in order to verify the client's identity. This works as follows: 1. The client offers the extension (called UME) in the ClientHello message. 2. The server accepts the extension. 3. The client sends the new HandshakeType to the server before sending its Certificate message. The packet flow looks like this (cut-and-pasted from the draft): Client Server ClientHello /* with user_mapping ext */ --------> ServerHello /* with user-mapping ext */ Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone --> UserMappingDataList Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data New handshake message marked by --> on the left. This document was presented to the TLS WG in Vancouver and there was only a very small amount of interest. The authors posted the -00 version of their draft on January 10. Some minor comments were made by a single WG member and these were addressed. The authors asked for a preliminary code point assignment on January 14. I provided a number of technical comments (including suggesting an alternate approach, described below) at that time, but was told that the implementation was already too far along to be changed significantly. Since the IETF would not have change control, this is an inappropriate work item for the TLS WG and therefore the authors appear to have decided on an Individual Submission. The reason for the intended status of Proposed Standard is that this extension defines a new Handshake Type and the TLS WG has decided that new Handshake Types require a Standards Action (See S 7.4 of draft-ietf-tls-rfc2246-13, in RFC-Ed queue). Contrary to the the Last Call announcement, the comments I raised originally have not been addressed--except to be told they weren't possible. For the reasons indicated below, I believe this document should not be advanced to Proposed Standard as-is. REVIEW COMMENTS The obvious design here would simply be to place the information in the UserMappingDataList (UMDL) message directly in the ClientHello extension. The draft argues that this is bad for the following reason: The reason the mapping data itself is not placed in the extension portion of the ClientHello is to prevent broadcasting this information to servers that don't understand the extension. Additionally, if new mapping information were to be considered confidential, the addition of a new handshake message allows the data to be encrypted using the servers public key. No other modifications to the protocol are required. The messages are detailed in the following sections. This is unconvincing for a number of reasons. First, TLS handles the case where an extension is not understood just fine. It's ignored. Since the extension appears to be less than 100 bytes, there's no performance issue. The authors suggest that there is a security issue: As the client is the initiator of this TLS extension, it needs to determine when it is appropriate to send the User Mapping Information. It may not be prudent to broadcast this information to just any server at any time, as it can reveal network infrastructure the client and server are using. - The client SHOULD only send the UserMappingDataList handshake message if it is agreed upon in the Hello exchange, preventing the information from being sent to a server that doesn't understand the User Mapping Extension. - The client SHOULD further only send this information if the server belongs to a domain to which the client intends to authenticate using the UPN as identifier. However, the second piece of information (the domain name of the server) is generally available to the client prior to the connection initiation, since it's used to look up the server's address. So, the client could decide whether to send the UMDL data prior to handshake initiation. One difference here is that the client now has the server's certificate and that certificate could potentially contain some X.509 Extension that indicated that the server was authorized to receive the UMDL data. However, this is of very limited security value because in the static RSA modes which are common with SSL/TLS, the server has not proved possession of the corresponding private key at this point in the handshake. Note that this draft does not describe any such extension. An attacker who wished to impersonate the server in order to capture the UMDL would be able to do so with a simple replay/cut-and-paste attack. Moreover, because the UMDL is sent in the clear (the draft claims that it could be encrypted but provides no facility for doing so) any passive attacker can capture the UMDL by observing a single handshake. At best this strategy stops the client from inadvertantly sending the UMDL to a server which it *thinks* should support it (because it's got the right domain name) but which actually doesn't (perhaps because it's broken?). This seems to be of extremely limited value. AN ALTERNATE DESIGN There is an alternate design which has superior security properties and does not involve defining a new HandshakeType. 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. Because the second TLS handshake is conducted over the TLS session established in step (1), the entire UMDL extension exchange is protected. A passive attacker cannot capture the UMDL data and an active attacker cannot impersonate the server and force the transmission of the UMDL. This approach has two (modest) drawbwacks. 1. It is slower because it requires two handshakes. 2. The client may have to authenticate twice (this is a special case of (1)). The second case can be easily ameliorated by having the client send an extension (empty UME?) in the first handshake as a signal that it wants to do UMDL and that the server should hold off on demanding client authentication until the rehandshake happens. The performance issue is quite modest with modern servers. Indeed, it's quite common for web servers to do a first handshake without cert-based client auth and then rehandshake with client auth if the client asks for a sensitive page. Note: there is an alternate design in which you do a client auth in the first handshake and then do a resumption in the second one but do UME. This is rather faster, both in terms of computation and round trips but is technically precluded by S 2.3 of RFC3546 which requires ignoring extensions if you do a resume. One could imagine relaxing this restriction but that hasn't been done yet. Note also that if the client isn't worried about the sensitivity of the UMDL, then it can simply offer the UME extension with a UMDL in the first handshake and skip the second handshake. Another (hacky) approach would be for the client to probe the server with an initial ClientHello (and no UME) and then abort the handshake and restart if it decides that it likes the server and wants to do UME. This would have equivalent security properties to this draft at the cost of a single round trip. SUMMARY The technique described in this document appears to be of limited usefulness. In particular, the lack of confidentiality for the UMDL is a big limitation in extending it to other applications than the one envisioned by Microsoft. There are alternate designs which don't have those limitations and don't involve allocating a new HandshakeType value. This document should not advance as a Proposed Standard. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 21:59:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAenI-0001Xn-EE; Sat, 18 Feb 2006 21:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAenH-0001Xh-73 for tls@ietf.org; Sat, 18 Feb 2006 21:59:27 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAenF-0005IW-Vd for tls@ietf.org; Sat, 18 Feb 2006 21:59:27 -0500 Received: (qmail 11377 invoked by uid 0); 19 Feb 2006 02:59:16 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (72.66.14.34) by woodstock.binhost.com with SMTP; 19 Feb 2006 02:59:16 -0000 Message-Id: <7.0.0.16.2.20060218211628.05e7ef10@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 18 Feb 2006 21:17:01 -0500 To: Eric Rescorla ,tls@ietf.org From: Russ Housley Subject: Re: [TLS] Spec integration for TLS 1.2? In-Reply-To: <20060218205431.923E622241D@laser.networkresonance.com> References: <20060218205431.923E622241D@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Consolidation seems highly desirable to me. Russ At 03:53 PM 2/18/2006, Eric Rescorla wrote: >I'm starting to write up the first draft of TLS 1.2 and it's >seeming increasingly weird that we have a bunch of essentially >core stuff that's not in the main TLS document. In particular: > >- Extensions (required for certificate algorithm signalling) >- AES support > >Do people feel this stuff should be merged into the main document? > >Thanks, >-Ekr > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 18 22:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAfJ7-0003ui-SF; Sat, 18 Feb 2006 22:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAfJ5-0003u3-5q; Sat, 18 Feb 2006 22:32:19 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAfJ1-0005pQ-St; Sat, 18 Feb 2006 22:32:19 -0500 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CF927FB28D; Sat, 18 Feb 2006 22:32:14 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 85B213C028D; Sat, 18 Feb 2006 22:32:13 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Eric Rescorla In-Reply-To: (Your message of "Sat, 18 Feb 2006 17:31:13 PST.") <20060219013238.779CC22241D@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Feb 2006 22:32:13 -0500 Message-Id: <20060219033213.85B213C028D@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: iesg@ietf.org, ietf@ietf.org, tls@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org In message <20060219013238.779CC22241D@laser.networkresonance.com>, Eric Rescor la writes: > >Since the IETF would not have change control, this is an inappropriate >work item for the TLS WG and therefore the authors appear to have >decided on an Individual Submission. The reason for the intended status >of Proposed Standard Do we have a process issue here? Can we have a Proposed Standard without the IETF having change control? (2026 speaks of change control only in the context of a WG.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 19 06:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAmWh-0000S9-Hz; Sun, 19 Feb 2006 06:14:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAmWg-0000Rs-BL for tls@ietf.org; Sun, 19 Feb 2006 06:14:50 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAmWe-0001Pf-V0 for tls@ietf.org; Sun, 19 Feb 2006 06:14:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 6EAC135CFC; Mon, 20 Feb 2006 00:14:46 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25364-20; Mon, 20 Feb 2006 00:14:46 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 3159E35321; Mon, 20 Feb 2006 00:14:46 +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 09AFF37746; Mon, 20 Feb 2006 00:14:46 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FAmWk-0007HV-00; Mon, 20 Feb 2006 00:14:54 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com, tls@ietf.org Subject: Re: [TLS] The TLS PRF In-Reply-To: <20060218214125.74DD722241D@laser.networkresonance.com> Message-Id: Date: Mon, 20 Feb 2006 00:14:54 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >Can we get some discussion this issue please? There's a great quote from "The Inmates Are Running the Asylum": Geeks will repeatedly fix what isn't broken until it is. Why is the TLS PRF broken? What's the pressing need for (say) a PRF that we can build with GCM? Is it because it's trendy? Do we need more features for a marketing checklist? The current PRF has been around for 10 years, and in that time the only real argument against it has been that it doesn't meet someone's taste in fashion (e.g. the GOST case). It's not broken, and doesn't show any sign of ever being broken, let's leave the poor thing alone. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 19 10:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAqML-0001R5-53; Sun, 19 Feb 2006 10:20:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAqMJ-0001R0-DE for tls@ietf.org; Sun, 19 Feb 2006 10:20:23 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAqMI-0005OQ-3j for tls@ietf.org; Sun, 19 Feb 2006 10:20:23 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id A829222241D; Sun, 19 Feb 2006 07:21:45 -0800 (PST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] The TLS PRF In-reply-to: Your message of "Mon, 20 Feb 2006 00:14:54 +1300." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sun, 19 Feb 2006 07:20:21 -0800 From: Eric Rescorla Message-Id: <20060219152145.A829222241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Eric Rescorla writes: > >>Can we get some discussion this issue please? > > There's a great quote from "The Inmates Are Running the Asylum": Geeks will > repeatedly fix what isn't broken until it is. > > Why is the TLS PRF broken? What's the pressing need for (say) a PRF that we > can build with GCM? Is it because it's trendy? Do we need more features for > a marketing checklist? > > The current PRF has been around for 10 years, and in that time the only real > argument against it has been that it doesn't meet someone's taste in fashion > (e.g. the GOST case). It's not broken, and doesn't show any sign of ever > being broken, let's leave the poor thing alone. Hmmm... I thought I explained myself clearly the first time, but apparently not. In TLS 1.2 we're attempting to replace the hardwired MD5/SHA-1 PRF with one that is not hardwired. The natural proposal is to use the hash function that corresponds to the HMAC used for message integrity. But if you're not using HMAC for message integrity (say because you're using GCM) then there's no obvious choice. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 19 14:47:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAuWV-00075z-8m; Sun, 19 Feb 2006 14:47:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAuWT-00075d-QR for tls@ietf.org; Sun, 19 Feb 2006 14:47:09 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAuWT-0003OV-ID for tls@ietf.org; Sun, 19 Feb 2006 14:47:09 -0500 Received: (qmail 9950 invoked by uid 0); 19 Feb 2006 19:47:03 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (72.66.14.34) by woodstock.binhost.com with SMTP; 19 Feb 2006 19:47:03 -0000 Message-Id: <7.0.0.16.2.20060219142550.05b67890@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 19 Feb 2006 14:27:06 -0500 To: "Steven M. Bellovin" , Eric Rescorla From: Russ Housley In-Reply-To: <20060219033213.85B213C028D@berkshire.machshav.com> References: <(Your message of "Sat, 18 Feb 2006 17:31:13 PST.") <20060219013238.779CC22241D@laser.networkresonance.com> <20060219033213.85B213C028D@berkshire.machshav.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Steve & Eric: The document that is in Last Call gives the IETF complete change control. There is no process issue. Russ At 10:32 PM 2/18/2006, Steven M. Bellovin wrote: >In message <20060219013238.779CC22241D@laser.networkresonance.com>, >Eric Rescor >la writes: > > > > >Since the IETF would not have change control, this is an inappropriate > >work item for the TLS WG and therefore the authors appear to have > >decided on an Individual Submission. The reason for the intended status > >of Proposed Standard > >Do we have a process issue here? Can we have a Proposed Standard >without the IETF having change control? (2026 speaks of change control >only in the context of a WG.) > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 19 16:41:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAwJ8-0001Jv-Jt; Sun, 19 Feb 2006 16:41:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAwJ7-0001Jq-VZ for tls@lists.ietf.org; Sun, 19 Feb 2006 16:41:29 -0500 Received: from xproxy.gmail.com ([66.249.82.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAwJ6-0006Sh-P8 for tls@lists.ietf.org; Sun, 19 Feb 2006 16:41:29 -0500 Received: by xproxy.gmail.com with SMTP id h26so601793wxd for ; Sun, 19 Feb 2006 13:41:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=hdSmW1J07OOq57kaBL8dlCx4lwpDLXIfDgEQB4SdEdTn2azNdIilxykxWS3tvjT70FVfiRdQ0yaG9D7PuMbwXHNinwke+5fJ4LQ/DkbQs3Ix0HG0MDYMJqtCWsAJjWWZ4ZcXyBZTviupgsldUGN+VpeXWH8F5+H4Nx/MzPBUVuk= Received: by 10.70.36.8 with SMTP id j8mr3122084wxj; Sun, 19 Feb 2006 13:41:28 -0800 (PST) Received: from ?172.16.1.49? ( [81.175.93.238]) by mx.gmail.com with ESMTP id i14sm586776wxd.2006.02.19.13.41.26; Sun, 19 Feb 2006 13:41:26 -0800 (PST) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] Spec integration for TLS 1.2? Date: Sun, 19 Feb 2006 22:38:44 +0100 User-Agent: KMail/1.8.3 References: <20060218205431.923E622241D@laser.networkresonance.com> In-Reply-To: <20060218205431.923E622241D@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200602192238.44338.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Sat 18 Feb 2006 21:53, Eric Rescorla wrote: > - Extensions (required for certificate algorithm signalling) > - AES support > Do people feel this stuff should be merged into the main document? Yes, I believe there is no reason for these to be defined in a separate document. -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 19 17:21:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAww9-0002Eu-3G; Sun, 19 Feb 2006 17:21:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAww7-0002EN-NA for tls@ietf.org; Sun, 19 Feb 2006 17:21:47 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAww7-0007ii-Fx for tls@ietf.org; Sun, 19 Feb 2006 17:21:47 -0500 Received: (qmail 6077 invoked by uid 0); 19 Feb 2006 22:21:39 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (72.66.14.34) by woodstock.binhost.com with SMTP; 19 Feb 2006 22:21:39 -0000 Message-Id: <7.0.0.16.2.20060219172051.05b12120@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 19 Feb 2006 17:21:42 -0500 To: Bill Fenner , "Steven M. Bellovin" From: Russ Housley In-Reply-To: <200602190538.k1J5ciVS024829@bright.research.att.com> References: <200602190538.k1J5ciVS024829@bright.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: iesg@ietf.org, tls@ietf.org, ietf@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I misunderstood the original question. I'll get it fixed or withdraw the Last Call. Russ At 12:38 AM 2/19/2006, Bill Fenner wrote: > >Can we have a Proposed Standard > >without the IETF having change control? > >No. RFC3978 says, in section 5.2 where it describes the derivative >works limitation that's present in draft-santesson-tls-ume, "These >notices may not be used with any standards-track document". > > Bill _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 19 22:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB1VC-0007Ew-DY; Sun, 19 Feb 2006 22:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB1VB-0007Eo-GU for tls@ietf.org; Sun, 19 Feb 2006 22:14:17 -0500 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB1V7-0006sn-Vv for tls@ietf.org; Sun, 19 Feb 2006 22:14:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 4BA66351EA; Mon, 20 Feb 2006 16:14:10 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04837-06; Mon, 20 Feb 2006 16:14:10 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 29557346E6; Mon, 20 Feb 2006 16:14:09 +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 D4DFE37748; Mon, 20 Feb 2006 16:14:09 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FB1V8-0008T2-00; Mon, 20 Feb 2006 16:14:14 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com, pgut001@cs.auckland.ac.nz Subject: Re: [TLS] The TLS PRF In-Reply-To: <20060219152145.A829222241D@laser.networkresonance.com> Message-Id: Date: Mon, 20 Feb 2006 16:14:14 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >Hmmm... I thought I explained myself clearly the first time, but apparently >not. You did, but... well, let me paraphrase your question as I understood it :-), and the same for my response. Question: Here are a bunch of hypothetical scenarios under which someone, if they really wanted to be awkward, could claim the current PRF offends their fashion sense. Should we accomodate them, or tell them to get a life? Response: The current PRF has stood the test of time, implementing other PRFs is a major implementation and interop headache (especially if we were to get a combinatorial explosion of PRFs that all need interop testing with each other), and there's no technical reason to introduce more of them. Specifically, no-one would be prevented from being able to create a secure TLS implementation using the current PRF. Tell 'em to get a life - let's solve real problems like the (critical) secure phishing problem before we start debating which colour to re-paint the (completely noncritical) PRF. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 20 00:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB3Jl-0003Y8-Iu; Mon, 20 Feb 2006 00:10:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB3Jk-0003Y3-Eb for tls@ietf.org; Mon, 20 Feb 2006 00:10:36 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB3Jj-0001iw-4F for tls@ietf.org; Mon, 20 Feb 2006 00:10:36 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4D4181E8C4C; Sun, 19 Feb 2006 21:10:34 -0800 (PST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] The TLS PRF References: From: Eric Rescorla Date: Sun, 19 Feb 2006 21:10:34 -0800 In-Reply-To: (Peter Gutmann's message of "Mon, 20 Feb 2006 16:14:14 +1300") Message-ID: <868xs6mx85.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Eric Rescorla writes: > >>Hmmm... I thought I explained myself clearly the first time, but apparently >>not. > > You did, but... well, let me paraphrase your question as I understood it :-), > and the same for my response. > > Question: Here are a bunch of hypothetical scenarios under which someone, if > they really wanted to be awkward, could claim the current PRF offends their > fashion sense. Should we accomodate them, or tell them to get a life? Yeah, well, that's the problem here. The scenarios aren't hypothetical, or I wouldn't have raised them. Let's just focus on one for the moment. 1. We're planning to replace the HMAC/MD5 PRF with one that's based on the hash used in the cipher suite HMAC. 2. People have requested the addition of non-HMAC-based cipher suites. These two together create a conflict that needs to be resolved somehow. Now, your response could be (at least) one of: 1. Don't replace HMAC/MD5 combo with something else. 2. Don't add non-HMAC-based cipher suites. 3. Somehow specify a way to use the TLS PRF with case (2), e.g. by specifying a PRF hash in the cipher suite. 4. Specify a new PRF. Now, I believe there's rough consensus to do task (1), so that precludes response (1). Task (2) is in our charter, so that precludes response (2)--which leaves us with at least some task to do to make this work. You could of course argue about either of these points and attempt to establish an alternative consensus, but just telling people to get a life doesn't really get the job done. As for the issue of phishing, I agree that that's a problem, but it's not the TLS WG's problem, so complaining that we're working on something else makes about as much sense as complaining that we're not working on a cure for HIV. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 20 04:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7kG-0004mD-4l; Mon, 20 Feb 2006 04:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7Bk-0002et-Nd for tls@ietf.org; Mon, 20 Feb 2006 04:18:36 -0500 Received: from castle.ran.pp.ru ([213.134.196.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7AC-000803-Du for tls@ietf.org; Mon, 20 Feb 2006 04:17:01 -0500 Received: from localhost (localhost [127.0.0.1]) by castle.ran.pp.ru (Postfix) with ESMTP id 6FF7C232B3; Mon, 20 Feb 2006 12:16:57 +0300 (MSK) Received: from castle.ran.pp.ru ([127.0.0.1]) by localhost (castle [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28536-01-14; Mon, 20 Feb 2006 12:16:52 +0300 (MSK) Received: by castle.ran.pp.ru (Postfix, from userid 10) id 9EB18232B1; Mon, 20 Feb 2006 12:16:46 +0300 (MSK) Received: by mx.cryptocom.ru (Postfix, from userid 500) id 72BADF4E9; Mon, 20 Feb 2006 12:16:04 +0300 (MSK) Received: from manul.lan.cryptocom.ru (manul.lan.cryptocom.ru [10.51.17.211]) by mx.cryptocom.ru (Postfix) with ESMTP id 4BC62F4D4; Mon, 20 Feb 2006 12:16:04 +0300 (MSK) Date: Mon, 20 Feb 2006 12:17:10 +0300 (MSK) From: Dmitry Belyavsky X-X-Sender: beldmit@manul.lan.cryptocom.ru To: Peter Gutmann Subject: Re: [TLS] The TLS PRF In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ran.pp.ru X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Greetings! On Mon, 20 Feb 2006, Peter Gutmann wrote: > The current PRF has been around for 10 years, and in that time the only real > argument against it has been that it doesn't meet someone's taste in fashion > (e.g. the GOST case). It's not broken, and doesn't show any sign of ever > being broken, let's leave the poor thing alone. In Russia we have to implement GOST-based PRF because of our goverment restrictions. So leaving current PRF hard-coded will leave some our problems with us... -- SY, Dmitry Belyavsky (ICQ UIN 11116575) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 20 07:55:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAa2-0006R2-P8; Mon, 20 Feb 2006 07:55:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBAa0-0006QP-Ry; Mon, 20 Feb 2006 07:55:52 -0500 Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBAa0-00062V-EK; Mon, 20 Feb 2006 07:55:52 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1KCriGm003454; Mon, 20 Feb 2006 14:55:23 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:55:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:55:08 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2006 14:55:06 +0200 Message-ID: In-Reply-To: <43F91981.7070900@strahm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: 'TLS User Mapping Extension' to Proposed Standard Thread-Index: AcY1vAIv0IrQ8ooBRLGfzJoIXZnlVAAYCXZw From: To: , X-OriginalArrivalTime: 20 Feb 2006 12:55:08.0184 (UTC) FILETIME=[E09A7180:01C6361C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: fenner@research.att.com, iesg@ietf.org, tls@ietf.org, ietf@ietf.org Subject: [TLS] RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bill Strahm wrote: >=20 > I saw all of the huff, and while I agree with it, I am more=20 > concerned about >=20 > Appendix A. IPR Disclosure >=20 > TBD >=20 > What does that mean, and more specifically is a document with a=20 > TBD section really ready for last call at all ? RFC 3979 Section 11 title says it all: "No IPR Disclosures in IETF=20 Documents" -- so this section needs to be removed. But the "TBD" part probably means the authors were in the process=20 of finding out exactly where and how IPRs should be disclosed. It looks like they've now figured it out: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=3D688 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 20 11:54:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBEIK-0004id-99; Mon, 20 Feb 2006 11:53:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBEIJ-0004iS-4T for tls@ietf.org; Mon, 20 Feb 2006 11:53:51 -0500 Received: from pproxy.gmail.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBEII-00058q-Sr for tls@ietf.org; Mon, 20 Feb 2006 11:53:51 -0500 Received: by pproxy.gmail.com with SMTP id w49so1148891pyg for ; Mon, 20 Feb 2006 08:53:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UM57Feb48qV45pHrYT9aSpfVSqNoiYQkg3R6SZ0WI7Dr2BNhvGNc85th0LrX5hYfwvaQwXnoHniuj2K8yG+F+Op3u+LqxVXkqKrfR3TaX/0kaYHHUVJBk12Bc8l0Xm1k3YqtwuibbAddZJq14EcahyNA40Ooq2qXdyczZ98jZT4= Received: by 10.35.43.10 with SMTP id v10mr79366pyj; Mon, 20 Feb 2006 08:53:50 -0800 (PST) Received: by 10.35.19.9 with HTTP; Mon, 20 Feb 2006 08:53:50 -0800 (PST) Message-ID: Date: Mon, 20 Feb 2006 11:53:50 -0500 From: "Tim Dierks" To: EKR Subject: Re: [TLS] The TLS PRF In-Reply-To: <868xs6mx85.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <868xs6mx85.fsf@raman.networkresonance.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The design goal of the original SSL3 PRF was to be more secure than any single ciphersuite's hashing algorithm. This was necessary because otherwise, any vulnerable ciphersuite supported by both sides allows a MITM to downgrade the handshake to the vulnerable ciphersuite. As things are at the moment, even if you had a crack on MD5, you couldn't leverage it to keep two parties from negotiating AES/SHA1, even if they both also supported RC4/MD5. If we reduce the PRF to using the hash from the negotiated cipher suite, this will no longer be true. What's the rationale for replacing the current PRF with a ciphersuite-based= one? - Tim On 2/20/06, Eric Rescorla wrote: > pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > > > Eric Rescorla writes: > > > >>Hmmm... I thought I explained myself clearly the first time, but appare= ntly > >>not. > > > > You did, but... well, let me paraphrase your question as I understood i= t :-), > > and the same for my response. > > > > Question: Here are a bunch of hypothetical scenarios under which someon= e, if > > they really wanted to be awkward, could claim the current PRF offends= their > > fashion sense. Should we accomodate them, or tell them to get a life= ? > > Yeah, well, that's the problem here. The scenarios aren't hypothetical, > or I wouldn't have raised them. > > Let's just focus on one for the moment. > > 1. We're planning to replace the HMAC/MD5 PRF with one that's based > on the hash used in the cipher suite HMAC. > 2. People have requested the addition of non-HMAC-based cipher suites. > > These two together create a conflict that needs to be resolved somehow. > > Now, your response could be (at least) one of: > 1. Don't replace HMAC/MD5 combo with something else. > 2. Don't add non-HMAC-based cipher suites. > 3. Somehow specify a way to use the TLS PRF with case (2), e.g. > by specifying a PRF hash in the cipher suite. > 4. Specify a new PRF. > > Now, I believe there's rough consensus to do task (1), so that > precludes response (1). Task (2) is in our charter, so that > precludes response (2)--which leaves us with at least some > task to do to make this work. > > You could of course argue about either of these points and attempt to > establish an alternative consensus, but just telling people to get a > life doesn't really get the job done. As for the issue of phishing, > I agree that that's a problem, but it's not the TLS WG's problem, > so complaining that we're working on something else makes about > as much sense as complaining that we're not working on a cure for > HIV. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 20 20:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMNv-0002Wq-LG; Mon, 20 Feb 2006 20:32:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMNu-0002We-Fc; Mon, 20 Feb 2006 20:32:10 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBMNt-00053R-GH; Mon, 20 Feb 2006 20:32:10 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 20 Feb 2006 17:32:08 -0800 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 17:32:08 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 17:32:07 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 17:32:07 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard Date: Mon, 20 Feb 2006 17:32:07 -0800 Message-ID: In-Reply-To: <20060219013238.779CC22241D@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard thread-index: AcY09Mhv90dgZ/GKTTWTV+JoUheWjgBkSi8A From: "Ari Medvinsky" To: "Eric Rescorla" , X-OriginalArrivalTime: 21 Feb 2006 01:32:07.0953 (UTC) FILETIME=[A0E53010:01C63686] X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: tls@ietf.org, iesg@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, Thank you for your feedback. Below are the problems that I see with the alternative proposals that you suggested when compared to the approach taken in the current draft: 1) Proposal 1: Send the user mapping extension in the initial Client Hello (as data along with the extension value). a) Problem: Privacy/Lack of user consent in information disclosure. The UPN sent in the user extension, uniquely identifies a principal - something that users concerned with preserving their privacy may object to (i.e., the large majority of SSL sites are server side auth only; the user was anonymous and now the user is identified by the UPN). To mitigate this problem to some extent (as I think you pointed out), the client can be configured to only send the user mapping information to some subset of servers (e.g., based on domain names). However, this completely lacks end user consent. The user's principal name will be automatically sent to every SSL server in the above list (as configured by admin) - even if the user does not wish to be identified to the target server (in SSL sessions with server side auth only and mutual auth). In contrast, if the mapping extension is sent on the third leg before the certificate msg (as it is in the current draft), the user has the option to bail out of client auth and not disclose the UPN or any data in the cert (e.g., by not typing the pin for the smartcard). b) Problem: Performance. In your email you stated that the UserMapping extension is likely to be around ~ 100 bytes and that's negligible and thus it is ok to send in the initial ClientHello msg - even if the server does not need it as is the case for server side auth only TLS connections. I disagree. As you know TLS is used in many different scenarios, for example: EAP/TLS (RFC http://www.ietf.org/rfc/rfc2716.txt) is used for Radius, wireless 802.1x, RAS (dial up), etc. The MTU in EAP is 1600 bytes. Thus even 100 bytes can cause additional fragmentation causing additional latency for RAS (consider dial up across geographically dispersed end points). Furthermore, per the current draft the userMapping structure can be extended, to carry multiple user mapping hints, thus causes further degradation in this scenario ... 2) Proposal 2: =20 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. This is essentially saying that the current extensibility mechanism in TLS is broken and that the userMapping extension in contrast to all other extension requires to 2 handshakes instead of one. The method that you are proposing is inconsistent with the approach used for every other TLS extension. =20 >From a performance standpoint, proposal 2 is still a bad choice. You stated that "The performance issue is quite modest with modern servers". While servers are getting faster, user load tends to follow suit; furthermore, this proposal costs additional latency. In contrast, the approach used in the current draft does not suffer from these problems.=20 Regards, -Ari -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Saturday, February 18, 2006 5:31 PM To: ietf@ietf.org Cc: tls@ietf.org; iesg@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard BACKGROUND This document describes an extension to TLS which allows the client to give the server a hint (the User Principal Name) about which directory entry to look up in order to verify the client's identity. This works as follows: 1. The client offers the extension (called UME) in the=20 ClientHello message.=20 2. The server accepts the extension. 3. The client sends the new HandshakeType to the server before sending its Certificate message. The packet flow looks like this (cut-and-pasted from the draft): Client Server ClientHello /* with user_mapping ext */ --------> ServerHello /* with user-mapping ext */ Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone --> UserMappingDataList Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data New handshake message marked by --> on the left. This document was presented to the TLS WG in Vancouver and there was only a very small amount of interest. The authors posted the -00 version of their draft on January 10. Some minor comments were made by a single WG member and these were addressed. The authors asked for a preliminary code point assignment on January 14. I provided a number of technical comments (including suggesting an alternate approach, described below) at that time, but was told that the implementation was already too far along to be changed significantly. Since the IETF would not have change control, this is an inappropriate work item for the TLS WG and therefore the authors appear to have decided on an Individual Submission. The reason for the intended status of Proposed Standard is that this extension defines a new Handshake Type and the TLS WG has decided that new Handshake Types require a Standards Action (See S 7.4 of draft-ietf-tls-rfc2246-13, in RFC-Ed queue). Contrary to the the Last Call announcement, the comments I raised originally have not been addressed--except to be told they weren't possible. For the reasons indicated below, I believe this document should not be advanced to Proposed Standard as-is. REVIEW COMMENTS The obvious design here would simply be to place the information in the UserMappingDataList (UMDL) message directly in the ClientHello extension. The draft argues that this is bad for the following reason: The reason the mapping data itself is not placed in the extension portion of the ClientHello is to prevent broadcasting this information to servers that don't understand the extension. Additionally, if new mapping information were to be considered confidential, the addition of a new handshake message allows the data to be encrypted using the servers public key. No other modifications to the protocol are required. The messages are detailed in the following sections. This is unconvincing for a number of reasons. First, TLS handles the case where an extension is not understood just fine. It's ignored. Since the extension appears to be less than 100 bytes, there's no performance issue. The authors suggest that there is a security issue: As the client is the initiator of this TLS extension, it needs to determine when it is appropriate to send the User Mapping Information. It may not be prudent to broadcast this information to just any server at any time, as it can reveal network infrastructure the client and server are using. - The client SHOULD only send the UserMappingDataList handshake message if it is agreed upon in the Hello exchange, preventing the information from being sent to a server that doesn't understand the User Mapping Extension. - The client SHOULD further only send this information if the server belongs to a domain to which the client intends to authenticate using the UPN as identifier. However, the second piece of information (the domain name of the server) is generally available to the client prior to the connection initiation, since it's used to look up the server's address. So, the client could decide whether to send the UMDL data prior to handshake initiation. One difference here is that the client now has the server's certificate and that certificate could potentially contain some X.509 Extension that indicated that the server was authorized to receive the UMDL data. However, this is of very limited security value because in the static RSA modes which are common with SSL/TLS, the server has not proved possession of the corresponding private key at this point in the handshake. Note that this draft does not describe any such extension. An attacker who wished to impersonate the server in order to capture the UMDL would be able to do so with a simple replay/cut-and-paste attack. Moreover, because the UMDL is sent in the clear (the draft claims that it could be encrypted but provides no facility for doing so) any passive attacker can capture the UMDL by observing a single handshake.=09 At best this strategy stops the client from inadvertantly sending the UMDL to a server which it *thinks* should support it (because it's got the right domain name) but which actually doesn't (perhaps because it's broken?). This seems to be of extremely limited value. AN ALTERNATE DESIGN There is an alternate design which has superior security properties and does not involve defining a new HandshakeType.=20 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. Because the second TLS handshake is conducted over the TLS session established in step (1), the entire UMDL extension exchange is protected. A passive attacker cannot capture the UMDL data and an active attacker cannot impersonate the server and force the transmission of the UMDL.=20 This approach has two (modest) drawbwacks. 1. It is slower because it requires two handshakes. 2. The client may have to authenticate twice (this is a special case of (1)). The second case can be easily ameliorated by having the client send an extension (empty UME?) in the first handshake as a signal that it wants to do UMDL and that the server should hold off on demanding client authentication until the rehandshake happens. The performance issue is quite modest with modern servers. Indeed, it's quite common for web servers to do a first handshake without cert-based client auth and then rehandshake with client auth if the client asks for a sensitive page. Note: there is an alternate design in which you do a client auth in the first handshake and then do a resumption in the second one but do UME. This is rather faster, both in terms of computation and round trips but is technically precluded by S 2.3 of RFC3546 which requires ignoring extensions if you do a resume. One could imagine relaxing this restriction but that hasn't been done yet. Note also that if the client isn't worried about the sensitivity of the UMDL, then it can simply offer the UME extension with a UMDL in the first handshake and skip the second handshake. Another (hacky) approach would be for the client to probe the server with an initial ClientHello (and no UME) and then abort the handshake and restart if it decides that it likes the server and wants to do UME. This would have equivalent security properties to this draft at the cost of a single round trip. SUMMARY The technique described in this document appears to be of limited usefulness. In particular, the lack of confidentiality for the UMDL is a big limitation in extending it to other applications than the one envisioned by Microsoft. There are alternate designs which don't have those limitations and don't involve allocating a new HandshakeType value. This document should not advance as a Proposed Standard. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 04:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBU3I-0002wC-VE; Tue, 21 Feb 2006 04:43:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBU3H-0002w1-DJ for tls@ietf.org; Tue, 21 Feb 2006 04:43:23 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBU3E-0002ou-Vu for tls@ietf.org; Tue, 21 Feb 2006 04:43:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 706D534400; Tue, 21 Feb 2006 22:43:18 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22922-20; Tue, 21 Feb 2006 22:43:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id F00943440A; Tue, 21 Feb 2006 22:43:17 +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 CDCA337745; Tue, 21 Feb 2006 22:43:17 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FBU3J-0002VL-00; Tue, 21 Feb 2006 22:43:25 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com Subject: Re: [TLS] The TLS PRF In-Reply-To: <868xs6mx85.fsf@raman.networkresonance.com> Message-Id: Date: Tue, 21 Feb 2006 22:43:25 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >The scenarios aren't hypothetical, or I wouldn't have raised them. I guess we'll just have to agree to disagree on this - it looks to me like a bunch of artificial justifications to support messing with something that's just fine as it is, but I guess you're seeing it differently. >You could of course argue about either of these points and attempt to >establish an alternative consensus, but just telling people to get a life >doesn't really get the job done. My comment was to leave things as they are. The "get a life" (and emoticon) were tongue-in-cheek. >As for the issue of phishing, I agree that that's a problem, but it's not the >TLS WG's problem, so complaining that we're working on something else makes >about as much sense as complaining that we're not working on a cure for HIV. Not phishing, secure phishing, i.e. use of TLS server authentication as part of the phishing process. I think building systems that make phishing easier probably isn't a good idea, and that it'd be more productive to look at ways of fixing this problem than to fiddle with random bits of the protocol that work just fine as they are. Again though I guess our opinions differ... Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 10:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZ0T-0002SF-Nj; Tue, 21 Feb 2006 10:00:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBXk6-0006P2-6A; Tue, 21 Feb 2006 08:39:50 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBXZQ-0002D3-Lj; Tue, 21 Feb 2006 08:28:49 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1LDRraw006688; Tue, 21 Feb 2006 15:27:54 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 15:28:04 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Feb 2006 15:28:02 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard Date: Tue, 21 Feb 2006 15:28:15 +0200 Message-ID: In-Reply-To: <20060219013238.779CC22241D@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard Thread-Index: AcY09EnHtfbfnUp9T8WKO8+PpaeZ4QB9gfQA From: To: , , X-OriginalArrivalTime: 21 Feb 2006 13:28:02.0832 (UTC) FILETIME=[A3FF9100:01C636EA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org My personal comments about draft-santesson-tls-ume-01: The draft defines an extension to TLS that allows the client to send "user mapping" information to the TLS server. The server uses this information to fetch authentication/authorization-related information from a directory server. The draft is quite similar to draft-housley-tls-authz-extns, which allows sending X.509 attribute certificates and SAML assertions in TLS. The main difference seems to be that we only send a pointer to the authorization information (a bit like IKEv2, which supports sending an URL of the certificate instead of the cert itself). From a purely technical point of view, it would probably make sense to merge these drafts. The tls-authz-extns draft does some details better: e.g., the information is sent encrypted, and only after the server has been authenticated. The solution is also quite similar to the "client_certificate_url" extension defined in RFC 3546 (the "User Principal Name" could be considered as one type of certificate URL). Here even the placement of the handshake messages is identical to tls-ume. Unfortunately, it seems that sending both CertificateURL and Certificate handshake messages is not allowed, complicating the situation. However, it might be that process and timing issues make mergers infeasible. Also, the authors of draft-santesson-tls-ume seem to=20 be unwilling to make changes to the protocol. About the technical details: In general, the solution seems to work, and does not contain any serious flaws. I don't count sending the user mapping information unencrypted as a serious flaw -- this information is sent only when a client certificate is also sent, and the client certificate is not encrypted either (unless the double-handshake hack is used, in which case the user mapping information would be encrypted, too). It's probably not the most elegant design possible (see e.g. Eric Rescorla's review). However, I think we should clearly "distinguish between 'it won't work' and 'it could/should work better'" (as Dave Crocker well put it in one email). The document solves a real (but maybe not extremely large or important) problem, and the solution works. That's better than many documents these days... Given these, I think this would be an excellent document for Informational, especially if the title was changed to "Microsoft TLS User Mapping Extension" to indicate that it's a proprietary extension where the IETF community had no chance to change anything. I also think vendors should be encouraged to publish their extensions, even if they are not perfect. However, due to the IANA allocation rules in 2246bis, this draft is being last called for standards track, and this is slightly more problematic. One observation is that the TLS allocation rules are quite strict, and not always totally logical. "Specification Required" is sufficient to get a ClientCertificateType number, and "IETF Consensus" gets you an ExtensionType number. But many extensions (including this one, and also some of the extensions in 3546bis) also require a handshake message number, and thus Standards Track. Or in other words: the degree of consensus and process required for a document that extends TLS depends heavily on minor technical details, not on what the extension actually does. RFC 2026 also says that "A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable." I don't think we're quite there yet with this document. On the other hand, I also think that just refusing to publish this document would be a highly unproductive approach. If the document solves a reasonable problem, the solution works, and it looks likely it will be widely deployed, I don't think preventing publication on minor process details would exactly "make the Internet work better". I'm not sure what would be the best way to handle this, though. Merge this with draft-housley-tls-authz-extns? Refine the technical details so that it does not need a new handshake message number? (E.g., map the UPN to an URL, and use the existing CertificateURL message?) Change the=20 IANA allocation rules for TLS? I don't have a strong opinion here... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 10:13:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZCn-0003gq-BL; Tue, 21 Feb 2006 10:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZCm-0003gk-N8 for tls@ietf.org; Tue, 21 Feb 2006 10:13:32 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBZCl-0006tE-Dm for tls@ietf.org; Tue, 21 Feb 2006 10:13:32 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id B27861E8C4C; Tue, 21 Feb 2006 07:13:30 -0800 (PST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] The TLS PRF References: From: Eric Rescorla Date: Tue, 21 Feb 2006 07:13:30 -0800 In-Reply-To: (Peter Gutmann's message of "Tue, 21 Feb 2006 22:43:25 +1300") Message-ID: <868xs4kan9.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Eric Rescorla writes: > >>The scenarios aren't hypothetical, or I wouldn't have raised them. > > I guess we'll just have to agree to disagree on this - it looks to me like a > bunch of artificial justifications to support messing with something that's > just fine as it is, but I guess you're seeing it differently. Obviously. But all you've done is assert it's just fine as it is, without actually explaining why these scenarios aren't relevant, which really isn't that helpful. If you'd actually bother to respond in detail, we might not have to agree to disagree. > Not phishing, secure phishing, i.e. use of TLS server authentication as part > of the phishing process. I think building systems that make phishing easier > probably isn't a good idea, and that it'd be more productive to look at ways > of fixing this problem than to fiddle with random bits of the protocol that > work just fine as they are. Again though I guess our opinions differ... Do you have a proposal for a way to fix the problem that the TLS WG should be working on? If not, I really don't see your point here. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 16:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBfJN-0004OY-38; Tue, 21 Feb 2006 16:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBfJL-0004OS-AH for tls@ietf.org; Tue, 21 Feb 2006 16:44:43 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBfJK-00035r-Vv for tls@ietf.org; Tue, 21 Feb 2006 16:44:43 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 351901E8C4C; Tue, 21 Feb 2006 13:44:42 -0800 (PST) To: "Tim Dierks" Subject: Re: [TLS] The TLS PRF References: <868xs6mx85.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Tue, 21 Feb 2006 13:44:42 -0800 In-Reply-To: (Tim Dierks's message of "Mon, 20 Feb 2006 11:53:50 -0500") Message-ID: <86fymcidyt.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Tim Dierks" writes: > The design goal of the original SSL3 PRF was to be more secure than > any single ciphersuite's hashing algorithm. This was necessary because > otherwise, any vulnerable ciphersuite supported by both sides allows a > MITM to downgrade the handshake to the vulnerable ciphersuite. As > things are at the moment, even if you had a crack on MD5, you couldn't > leverage it to keep two parties from negotiating AES/SHA1, even if > they both also supported RC4/MD5. If we reduce the PRF to using the > hash from the negotiated cipher suite, this will no longer be true. > > What's the rationale for replacing the current PRF with a > ciphersuite-based one? Well, for any of this to make sense you have to assume that there's some concern that there will be a useful preimage attack on one of the hash functions that might potentially be in the PRF. At the moment all we know is that we're not meeting the design goals on SHA-1 and MD5 which is a long way from a preimage. That said, consider the following scenario: 1. There's a useful preimage attack on SHA-1 and MD5. 2. People convert to SHA-256 in their ciphersuite HMAC and turn off all non SHA-256 ciphersuites. 3. There are two ciphers of different strengths that both use SHA-256. In this case, if we don't change the PRF you could downgrade between those two ciphers. OTOH, if we do change the PRF, you could. I think it's realistic to argue that any compromise in HMAC bad enough to implicate the PRF would also require people to turn off that algorithm in their ciphersuites. So, the motivation here is not to get stuck in that situation. I agree that it's unlikely, but I see it as future-proofing. Note, btw, that this exact issue was on my slides in Vancouver. At a higher level, there are 5 major places where TLS uses hashes: - Cert signatures - Record MACs - PRF - Digitally-signed operator - Finished (also PRF) Now, the record MACs negotiate just fine. And the cert signatures can be done with an extension. So, that leaves the remaining three choices, which all use MD5 and SHA-1 in tandem (with the exception of with DSA). Do people feel we can leave those as-is? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 18:22:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBgpX-0001lp-Vf; Tue, 21 Feb 2006 18:22:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBgpW-0001li-QA for tls@ietf.org; Tue, 21 Feb 2006 18:22:02 -0500 Received: from pproxy.gmail.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBgpT-0007tL-IS for tls@ietf.org; Tue, 21 Feb 2006 18:22:02 -0500 Received: by pproxy.gmail.com with SMTP id o67so1577769pye for ; Tue, 21 Feb 2006 15:21:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QhHCb9yrF8SVadTkVmXenzhtubhXtorBV+9lETKHym0665zco6j7n51uji5GeZJ5b2Ws9jwOKlzuiOpMeIj24utwOO6oI2ZTO1+fHfn6FVIEHsrkfY5zy31pO+MJFiKoxG6iJJ2v5lQGZ/NCUKwUo1YGVZzWM4obcEqDMw+Y9i8= Received: by 10.35.107.20 with SMTP id j20mr495099pym; Tue, 21 Feb 2006 15:21:59 -0800 (PST) Received: by 10.35.19.9 with HTTP; Tue, 21 Feb 2006 15:21:59 -0800 (PST) Message-ID: Date: Tue, 21 Feb 2006 18:21:59 -0500 From: "Tim Dierks" To: EKR Subject: Re: [TLS] The TLS PRF In-Reply-To: <86fymcidyt.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <868xs6mx85.fsf@raman.networkresonance.com> <86fymcidyt.fsf@raman.networkresonance.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 2/21/06, Eric Rescorla wrote: > "Tim Dierks" writes: > > What's the rationale for replacing the current PRF with a > > ciphersuite-based one? > > Well, for any of this to make sense you have to assume that > there's some concern that there will be a useful preimage > attack on one of the hash functions that might potentially > be in the PRF. At the moment all we know is that we're not > meeting the design goals on SHA-1 and MD5 which is a long > way from a preimage. > > That said, consider the following scenario: > > 1. There's a useful preimage attack on SHA-1 and MD5. > 2. People convert to SHA-256 in their ciphersuite HMAC and > turn off all non SHA-256 ciphersuites. > 3. There are two ciphers of different strengths that both > use SHA-256. For #1 to defeat any of the mechanisms, you need a single preimage attack that works with both md5 and sha1, which, furthermore, can be executed within the protocol constraints of TLS (although the latter probably isn't too high of a bar). I think #2 is unlikely to ever happen in practice. SSL 2 is still on by default everywhere I'm familiar with. On the other hand, if we make this switch, a preimage attack on any supported hash which hasn't been disabled is sufficient to subvert the handshake mechanism, and thus force you to use the subverted hash. I'd prefer for us to replace the PRF with the best available hashing system we've got rather than use the negotiated hash. And, in the model of SSL3/TLS1, I'd use two disparate systems to try to avoid single points of failure. For example, we could replace SHA-1 with SHA-256 in the PRF. Furthermore, we could replace MD5 with another hash which has a very different structure from SHA-256 (off the cuff, and without any real knowledge, I'd consider using a hashing construction built from AES). - Tim _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 18:32:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBh05-0002EC-2E; Tue, 21 Feb 2006 18:32:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBh03-0002Dq-RO for tls@ietf.org; Tue, 21 Feb 2006 18:32:55 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBh02-00082v-JW for tls@ietf.org; Tue, 21 Feb 2006 18:32:55 -0500 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C351FFB29E; Tue, 21 Feb 2006 18:32:53 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id B6B2F3C0292; Tue, 21 Feb 2006 18:32:52 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Tim Dierks" Subject: Re: [TLS] The TLS PRF In-Reply-To: (Your message of "Tue, 21 Feb 2006 18:21:59 EST.") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Feb 2006 18:32:52 -0500 Message-Id: <20060221233252.B6B2F3C0292@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org In message , "Tim Dierks" writes: >I think #2 is unlikely to ever happen in practice. SSL 2 is still on >by default everywhere I'm familiar with. > IE7 beta turns off SSL2 by default. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 21:30:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjm3-0002ug-RN; Tue, 21 Feb 2006 21:30:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjm3-0002ub-4w for tls@ietf.org; Tue, 21 Feb 2006 21:30:39 -0500 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBjm1-0001UW-O4 for tls@ietf.org; Tue, 21 Feb 2006 21:30:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 833F7344AC; Wed, 22 Feb 2006 15:30:35 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12489-27; Wed, 22 Feb 2006 15:30:35 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 615453438F; Wed, 22 Feb 2006 15:30:35 +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 2737F3774B; Wed, 22 Feb 2006 15:30:35 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FBjm3-0003iF-00; Wed, 22 Feb 2006 15:30:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com Subject: Re: [TLS] The TLS PRF In-Reply-To: <868xs4kan9.fsf@raman.networkresonance.com> Message-Id: Date: Wed, 22 Feb 2006 15:30:39 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>Not phishing, secure phishing, i.e. use of TLS server authentication as part >>of the phishing process. I think building systems that make phishing easier >>probably isn't a good idea, and that it'd be more productive to look at ways >>of fixing this problem than to fiddle with random bits of the protocol that >>work just fine as they are. Again though I guess our opinions differ... > >Do you have a proposal for a way to fix the problem that the TLS WG should be >working on? If not, I really don't see your point here. I was suggesting that this might be a more productive (or more importantly, far more pressing) area to focus our attention on. Like (I would guess) most people I've got various ideas on how this might be addressed, the main one being to strongly promote a TLS-PSK -like mechanism (with mutual challenge- response authentication built into the handshake) in place of certs (where you connect to anything with a cert and then send the username and password to the server completely unprotected). What I was doing was trying to foster discussion, not present some fait-accompli pre-packaged solution. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 21 21:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjsW-0003A2-NR; Tue, 21 Feb 2006 21:37:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjsV-00039R-7R for tls@ietf.org; Tue, 21 Feb 2006 21:37:19 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FBjsS-00025K-UP for tls@ietf.org; Tue, 21 Feb 2006 21:37:19 -0500 Received: (qmail 28368 invoked by uid 0); 22 Feb 2006 02:37:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.126.156.113) by woodstock.binhost.com with SMTP; 22 Feb 2006 02:37:07 -0000 Message-Id: <7.0.0.16.2.20060221120850.05c87008@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 21 Feb 2006 12:13:32 -0500 To: "Tim Dierks" ,EKR From: Russ Housley Subject: Re: [TLS] The TLS PRF In-Reply-To: References: <868xs6mx85.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Tim: Thanks for reminding us about the original design goal. I think this is still an important consideration, but it is no longer the case I believe. There is also a political consideration. Presently, an exception is needed to use the TLS PRF in the US Government since it make use of a non-FIPS algorithm. Similarly, the TLS PRF is not acceptable to the Russian Government since it makes use of a non-GOST document. Russ At 11:53 AM 2/20/2006, Tim Dierks wrote: >The design goal of the original SSL3 PRF was to be more secure than >any single ciphersuite's hashing algorithm. This was necessary because >otherwise, any vulnerable ciphersuite supported by both sides allows a >MITM to downgrade the handshake to the vulnerable ciphersuite. As >things are at the moment, even if you had a crack on MD5, you couldn't >leverage it to keep two parties from negotiating AES/SHA1, even if >they both also supported RC4/MD5. If we reduce the PRF to using the >hash from the negotiated cipher suite, this will no longer be true. > >What's the rationale for replacing the current PRF with a >ciphersuite-based one? > > - Tim > >On 2/20/06, Eric Rescorla wrote: > > pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > > > > > Eric Rescorla writes: > > > > > >>Hmmm... I thought I explained myself clearly the first time, > but apparently > > >>not. > > > > > > You did, but... well, let me paraphrase your question as I > understood it :-), > > > and the same for my response. > > > > > > Question: Here are a bunch of hypothetical scenarios under > which someone, if > > > they really wanted to be awkward, could claim the current PRF > offends their > > > fashion sense. Should we accomodate them, or tell them to get a life? > > > > Yeah, well, that's the problem here. The scenarios aren't hypothetical, > > or I wouldn't have raised them. > > > > Let's just focus on one for the moment. > > > > 1. We're planning to replace the HMAC/MD5 PRF with one that's based > > on the hash used in the cipher suite HMAC. > > 2. People have requested the addition of non-HMAC-based cipher suites. > > > > These two together create a conflict that needs to be resolved somehow. > > > > Now, your response could be (at least) one of: > > 1. Don't replace HMAC/MD5 combo with something else. > > 2. Don't add non-HMAC-based cipher suites. > > 3. Somehow specify a way to use the TLS PRF with case (2), e.g. > > by specifying a PRF hash in the cipher suite. > > 4. Specify a new PRF. > > > > Now, I believe there's rough consensus to do task (1), so that > > precludes response (1). Task (2) is in our charter, so that > > precludes response (2)--which leaves us with at least some > > task to do to make this work. > > > > You could of course argue about either of these points and attempt to > > establish an alternative consensus, but just telling people to get a > > life doesn't really get the job done. As for the issue of phishing, > > I agree that that's a problem, but it's not the TLS WG's problem, > > so complaining that we're working on something else makes about > > as much sense as complaining that we're not working on a cure for > > HIV. > > > > -Ekr > > > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 22 15:13:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0Mj-0008IP-6s; Wed, 22 Feb 2006 15:13:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0Mi-0008IG-AR for tls@ietf.org; Wed, 22 Feb 2006 15:13:36 -0500 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0Mg-0004Jw-Mc for tls@ietf.org; Wed, 22 Feb 2006 15:13:36 -0500 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IV300F0GUUL0K00@dps.sfvic.sunlabs.com> for tls@ietf.org; Wed, 22 Feb 2006 12:13:33 -0800 (PST) Received: from [129.146.73.52] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IV300K3NUULAT00@mail.sunlabs.com> for tls@ietf.org; Wed, 22 Feb 2006 12:13:33 -0800 (PST) Date: Wed, 22 Feb 2006 12:13:32 -0800 From: Vipul Gupta Subject: Re: [TLS] Document Action: 'ECC Cipher Suites for TLS' to Informational RFC In-reply-to: To: tls mailing list Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Bodo Moeller , Chris Hawk , Vipul Gupta X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Jan 23, 2006, at 1:08 PM, The IESG wrote: > The IESG has approved the following document: > > - 'ECC Cipher Suites for TLS ' > as an Informational RFC > > This document is the product of the Transport Layer Security > Working Group. > > The IESG contact persons are Russ Housley and Sam Hartman. For the benefit of folks who might be implementing this specification, I'd like to point out that the RFC version will drop the lone DES ciphersuite and bump up (by 1) the cipher numbers for TLS_ECDH_ECDSA_WITH_NULL_SHA, and TLS_ECDH_ECDSA_WITH_RC4_128_SHA as per: http://www.imc.org/ietf-tls/mail-archive/msg04780.html http://www.imc.org/ietf-tls/mail-archive/msg04781.html The RFC will also include an informational appendix listing equivalent curve names chosen by different standards bodies. I've attached the email exchange with the Security Area director and the WG chairs approving these changes. vipul ---------------- On Jan 27, 2006, at 10:17 AM, Russ Housley wrote: > I think this is a good thing to include. Please work with the RFC > Editor during Auth48. > > Russ > > At 06:12 PM 1/26/2006, Vipul Gupta wrote: > >> Hi Russ, >> >> Attached here is the new rev of the draft and the diffs from >> version 12. >> For your convenience, I've reproduced the appendix below. >> >> thank you, >> >> vipul >> >> Appendix A. Equivalent Curves (Informative) >> >> All of the NIST curves [9] and several of the ANSI curves [7] are >> equivalent to curves listed in Section 5.1.1. In the following >> table, multiple names in one row represent aliases for the same >> curve. >> >> ------------------------------------------ >> Curve names chosen by >> different standards organizations >> ------------+---------------+------------- >> SECG | ANSI X9.62 | NIST >> ------------+---------------+------------- >> sect163k1 | | NIST K-163 >> sect163r1 | | >> sect163r2 | | NIST B-163 >> sect193r1 | | >> sect193r2 | | >> sect233k1 | | NIST K-233 >> sect233r1 | | NIST B-233 >> sect239k1 | | >> sect283k1 | | NIST K-283 >> sect283r1 | | NIST B-283 >> sect409k1 | | NIST K-409 >> sect409r1 | | NIST B-409 >> sect571k1 | | NIST K-571 >> sect571r1 | | NIST B-571 >> secp160k1 | | >> secp160r1 | | >> secp160r2 | | >> secp192k1 | | >> secp192r1 | prime192v1 | NIST P-192 >> secp224k1 | | >> secp224r1 | | NIST P-224 >> secp256k1 | | >> secp256r1 | prime256v1 | NIST P-256 >> secp384r1 | | NIST P-384 >> secp521r1 | | NIST P-521 >> ------------+---------------+------------- >> Table 6: Equivalent curves defined by SECG, ANSI, and NIST >> >> >> >> >> On Jan 26, 2006, at 1:44 PM, Russ Housley wrote: >> >> >>> I see no problem with dropping DES. >>> >>> I will need to see the proposed Appendix to make a judgement. Is >>> it already written? >>> >>> Russ >>> >>> At 01:23 PM 1/26/2006, Vipul Gupta wrote: >>> >>> >>>> Hi Russ, >>>> >>>> We'd like to propose a couple of minor modifications to >>>> draft-ietf-tls-ecc-12.txt (during the author 48 hr period) >>>> before it is published as an RFC. Please let us know if >>>> you are ok with this. The changes are: >>>> >>>> >>>>>> 1. address feedback received during the IETF last call >>>>>> (suggestion to drop the DES cipher suite, as per >>>>>> http://www.imc.org/ietf-tls/mail-archive/msg04780.html >>>>>> http://www.imc.org/ietf-tls/mail-archive/msg04781.html) >>>>>> >>>>>> 2. add an informative section (Appendix A) listing >>>>>> equivalent curves to aid implementors. >>>>>> >>>> >>>> thanks, >>>> >>>> vipul >>>> >>>> >>>> >>>> Begin forwarded message: >>>> >>>> >>>>> From: Pasi.Eronen@nokia.com >>>>> Date: January 26, 2006 6:01:38 AM PST >>>>> To: Vipul.Gupta@sun.com, ekr@rtfm.com, ekr@networkresonance.com >>>>> Cc: sblakewilson@bcisse.com, bmoeller@acm.org, nelson@bolyard.com, >>>>> chris@corriente.net >>>>> Subject: RE: 'ECC Cipher Suites for TLS' to Informational RFC >>>>> >>>>> Hi Vipul, >>>>> >>>>> The document has already been approved by the IESG, and >>>>> is in the RFC editor's queue -- so the changes should >>>>> wait until the Author's 48 hours (and have to be approved >>>>> by the AD if they're non-editorial). >>>>> >>>>> I would not support adding new text at this time unless >>>>> there are really good reasons -- and in this case, the >>>>> text doesn't look very important. The one spelling mistake >>>>> we can certainly fix, and I would not object to dropping >>>>> the DES ciphersuite, but that's up to Russ to decide. >>>>> >>>>> Best regards, >>>>> Pasi >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ext Vipul Gupta [mailto:Vipul.Gupta@sun.com] >>>>>> Sent: 25 January, 2006 22:42 >>>>>> To: Eric Rescorla; ekr@networkresonance.com; Eronen Pasi >>>>>> (Nokia-NRC/Helsinki) >>>>>> Cc: Vipul Gupta; Simon Blake-Wilson; Bodo Moeller; Nelson B >>>>>> Bolyard; Chris Hawk >>>>>> Subject: Re: 'ECC Cipher Suites for TLS' to Informational RFC >>>>>> >>>>>> >>>>>> Hi Eric, Pasi, >>>>>> >>>>>> We have a new version of this draft (attached) which: >>>>>> >>>>>> 1. addresses feedback received during the IETF last call >>>>>> (suggestion to drop the DES cipher suite, as per >>>>>> http://www.imc.org/ietf-tls/mail-archive/msg04780.html >>>>>> http://www.imc.org/ietf-tls/mail-archive/msg04781.html) >>>>>> >>>>>> 2. adds an informative section (Appendix A) listing >>>>>> equivalent curves to aid implementors. >>>>>> >>>>>> Should we submit the new draft via the usual channel? >>>>>> or wait for the 48-hour period and suggest these >>>>>> changes at that time? Please advise. Unless we hear >>>>>> otherwise, we'll go ahead and do the former. >>>>>> >>>>>> thanks, >>>>>> >>>>>> vipul > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Feb 22 19:56:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4mO-0006Ff-RK; Wed, 22 Feb 2006 19:56:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC4mM-0006Eo-9e for tls@ietf.org; Wed, 22 Feb 2006 19:56:22 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FC4mL-0004G2-RV for tls@ietf.org; Wed, 22 Feb 2006 19:56:22 -0500 Received: (qmail 21987 invoked by uid 0); 23 Feb 2006 00:56:13 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.126.156.113) by woodstock.binhost.com with SMTP; 23 Feb 2006 00:56:13 -0000 Message-Id: <7.0.0.16.2.20060222144633.056f1278@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 22 Feb 2006 19:34:26 -0500 To: From: Russ Housley Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard In-Reply-To: References: <20060219013238.779CC22241D@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: iesg@ietf.org, ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Pasi: >My personal comments about draft-santesson-tls-ume-01: > >The draft defines an extension to TLS that allows the client to send >"user mapping" information to the TLS server. The server uses this >information to fetch authentication/authorization-related information >from a directory server. I do not think this is a good summary of the purpose of this document. Currently in the Microsoft environment, a Microsoft-specific certificate extension that contains the username is required. This extension allows certificates without this Microsoft-specific extension to be used. The document refers to these as "legacy" certificates. In fact, these are the certificates that are in common use in many large enterprises. >The draft is quite similar to draft-housley-tls-authz-extns, which >allows sending X.509 attribute certificates and SAML assertions in >TLS. The main difference seems to be that we only send a pointer to >the authorization information (a bit like IKEv2, which supports >sending an URL of the certificate instead of the cert itself). From a >purely technical point of view, it would probably make sense to merge >these drafts. The tls-authz-extns draft does some details better: >e.g., the information is sent encrypted, and only after the server has >been authenticated. Based on the comments that I received from Eric Rescorla on draft-housley-tls-authz-extns, this draft is likely to move in a somewhat different direction; however, that is a discussion for a different thread. >The solution is also quite similar to the "client_certificate_url" >extension defined in RFC 3546 (the "User Principal Name" could be >considered as one type of certificate URL). Here even the placement >of the handshake messages is identical to tls-ume. Unfortunately, >it seems that sending both CertificateURL and Certificate handshake >messages is not allowed, complicating the situation. The change proposed here would require action by the TLS WG. And, this alternative approach was not raised at the Vancouver IETF when this solution was presented to the TLS WG. >However, it might be that process and timing issues make mergers >infeasible. Also, the authors of draft-santesson-tls-ume seem to >be unwilling to make changes to the protocol. This is not the case. I raised a significant concern when I did my AD review, and after discussion of several alternative solutions, they picked one and changed the document. I understand that they are also changing their implementation to match the document. >About the technical details: In general, the solution seems to work, >and does not contain any serious flaws. I don't count sending the user >mapping information unencrypted as a serious flaw -- this information >is sent only when a client certificate is also sent, and the client >certificate is not encrypted either (unless the double-handshake hack >is used, in which case the user mapping information would be >encrypted, too). I agree with this assessment. >It's probably not the most elegant design possible (see e.g. Eric >Rescorla's review). > >However, I think we should clearly "distinguish between 'it won't >work' and 'it could/should work better'" (as Dave Crocker well put it >in one email). The document solves a real (but maybe not extremely >large or important) problem, and the solution works. That's better >than many documents these days... I think that the folks that are using enterprise PKIs would like to see this capability, and Microsoft is prepared to make it available in Vista. >Given these, I think this would be an excellent document for >Informational, especially if the title was changed to "Microsoft TLS >User Mapping Extension" to indicate that it's a proprietary extension >where the IETF community had no chance to change anything. I also >think vendors should be encouraged to publish their extensions, even >if they are not perfect. I disagree with this point. When I did my AD review, I considered the Microsoft-specific nature of the document. The structure easily accommodates additional name forms. Thus, I do not think we should ask for "Microsoft" in the document title. >However, due to the IANA allocation rules in 2246bis, this draft is >being last called for standards track, and this is slightly more >problematic. > >One observation is that the TLS allocation rules are quite strict, and >not always totally logical. "Specification Required" is sufficient to >get a ClientCertificateType number, and "IETF Consensus" gets you an >ExtensionType number. But many extensions (including this one, and >also some of the extensions in 3546bis) also require a handshake >message number, and thus Standards Track. Or in other words: the >degree of consensus and process required for a document that extends >TLS depends heavily on minor technical details, not on what the >extension actually does. > >RFC 2026 also says that "A Proposed Standard specification is >generally stable, has resolved known design choices, is believed to be >well-understood, has received significant community review, and >appears to enjoy enough community interest to be considered valuable." > >I don't think we're quite there yet with this document. We need to strike a balance. In this case, Microsoft is trying to follow the IANA allocation rules in 2246bis. We do not want to punish them for trying to be good IETF participants. >On the other hand, I also think that just refusing to publish this >document would be a highly unproductive approach. If the document >solves a reasonable problem, the solution works, and it looks likely >it will be widely deployed, I don't think preventing publication on >minor process details would exactly "make the Internet work better". We agree on this point. >I'm not sure what would be the best way to handle this, though. Merge >this with draft-housley-tls-authz-extns? Refine the technical details >so that it does not need a new handshake message number? (E.g., map the >UPN to an URL, and use the existing CertificateURL message?) Change the >IANA allocation rules for TLS? I don't have a strong opinion here... Since the direction for draft-housley-tls-authz-extns remains unclear, I do not think we should delay draft-santesson-tls-ume while the other document gets sorted out. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 23 12:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKJc-0001Ds-EX; Thu, 23 Feb 2006 12:31:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKJb-0001Dk-0s for tls@ietf.org; Thu, 23 Feb 2006 12:31:43 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKJZ-0006RI-OO for tls@ietf.org; Thu, 23 Feb 2006 12:31:43 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id BB0F922241D for ; Thu, 23 Feb 2006 09:33:02 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Thu, 23 Feb 2006 09:31:38 -0800 From: Eric Rescorla Message-Id: <20060223173302.BB0F922241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [TLS] Call for agenda items X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The TLS WG will be meeting in Dallas. This is a call for agenda items. Please send them to me and to Pasi Eronen (pasi.eronen@nokia.com) by next Friday (Mar 3) -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Feb 23 13:13:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKyJ-0003Ls-9T; Thu, 23 Feb 2006 13:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKxy-0003GK-QS for tls@ietf.org; Thu, 23 Feb 2006 13:13:26 -0500 Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKxx-0007Tb-FV for tls@ietf.org; Thu, 23 Feb 2006 13:13:26 -0500 Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FCKxv-00027c-IY for tls@ietf.org; Thu, 23 Feb 2006 13:13:23 -0500 From: "Robert Holliday" To: Date: Thu, 23 Feb 2006 13:13:24 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcY4pNYf5BW8ly8eR22vuiOoI7dzwA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.8 (+) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Subject: [TLS] Registration for Network Security 2006 Now Open X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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="===============1961445034==" Errors-To: tls-bounces@lists.ietf.org Message-Id: This is a multi-part message in MIME format. --===============1961445034== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C6387A.ED7BD8C0" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C6387A.ED7BD8C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit International Conference on Network Security 2006 Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_0008_01C6387A.ED7BD8C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

International Conference on Network Security 2006

 

Registration = Open!!!

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://www.isocore.com/netwo= rksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/netwo= rksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.isocore.com/netwo= rksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /span>

 

------=_NextPart_000_0008_01C6387A.ED7BD8C0-- --===============1961445034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1961445034==-- From tls-bounces@lists.ietf.org Fri Feb 24 11:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCg7t-0000UE-0k; Fri, 24 Feb 2006 11:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCg7q-0000Tn-Tp; Fri, 24 Feb 2006 11:49:02 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCg7p-0000ws-MJ; Fri, 24 Feb 2006 11:49:02 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BAB83E0077; Fri, 24 Feb 2006 11:48:54 -0500 (EST) To: Colin Perkins References: <17373.4514.607960.660335@cnr.cs.columbia.edu> <17374.4868.521418.118273@cnr.cs.columbia.edu> From: Sam Hartman Date: Fri, 24 Feb 2006 11:48:54 -0500 In-Reply-To: (Colin Perkins's message of "Fri, 24 Feb 2006 15:53:24 +0000") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF MMUSIC working group , Jon Peterson , Jonathan Lennox , tls@ietf.org Subject: [TLS] Re: [MMUSIC] Re: comedia-tls: proposed change for certificate identities X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>>>> "Colin" == Colin Perkins writes: Colin> There was a comment from Hadriel Kaplan supporting this change, but Colin> this is a big enough issue that I'd like more feedback before we go Colin> forward. Any comments from other members of the working group (or Colin> from the security ADs)? As the one who proposed it, I supported it. I'm a bit worried that this may be used to bootstrap lawful intercept more easily than some other solution. However I think that concern is not very realistic because without this feature, I don't think we're going to see usable media encryption as a reality. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 25 14:41:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD5IK-0000hp-FP; Sat, 25 Feb 2006 14:41:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD5II-0000hD-IJ for tls@ietf.org; Sat, 25 Feb 2006 14:41:30 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD5IH-0002KZ-93 for tls@ietf.org; Sat, 25 Feb 2006 14:41:30 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E1E7F222437 for ; Sat, 25 Feb 2006 11:42:51 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 25 Feb 2006 11:41:28 -0800 From: Eric Rescorla Message-Id: <20060225194251.E1E7F222437@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [TLS] New TLS 1.2 draft submitted X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I've just submitted a new draft for TLS 1.2 (draft-ietf-tls-rfc4346-bis-00.txt). This draft includes the following changes: - Merged in TLS Extensions and AES Cipher Suites from external documents. - Replacement of MD5/SHA-1 combination in the PRF - Replacement of MD5/SHA-1 combination in the digitally-signed element. - Allow the client to indicate which hash functions it supports. I realize there is some controversy about the second and third points, which we need to discuss at the meeting, but I wanted to get something out and it seems to me that if we are going to replace the MD5/SHA-1 combinations that it will look something like this. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Feb 25 17:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8Hd-0007yb-Dx; Sat, 25 Feb 2006 17:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8Hc-0007yD-6i; Sat, 25 Feb 2006 17:53:00 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8Ha-0007hh-Pe; Sat, 25 Feb 2006 17:53:00 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 4D34C222457; Sat, 25 Feb 2006 14:22:52 -0800 (PST) To: Colin Perkins In-reply-to: Your message of "Fri, 24 Feb 2006 15:53:24 GMT." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Sat, 25 Feb 2006 14:21:28 -0800 From: Eric Rescorla Message-Id: <20060225222252.4D34C222457@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF MMUSIC working group , Jon Peterson , Jonathan Lennox , tls@ietf.org, Sam Hartman Subject: [TLS] Re: [MMUSIC] Re: comedia-tls: proposed change for certificate identities X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Colin Perkins wrote: > On 30 Jan 2006, at 13:22, Jonathan Lennox wrote: > > On Sunday, January 29 2006, "Sam Hartman" wrote: > >> What about hop-by-hop authenticated with each hop integrity > >> protected. > >> IMHO in many environments, this presents acceptable man-in-the-middle > >> risk. I think that it may present significantly easier to deal with > >> usability issues so I think it should at least be allowed if not > >> encouraged. > > > > This will certainly be the most common way of securing SDP, I think > > -- this > > describes how sips, i.e. sip over hop-by-hop TLS, works. You're > > vulnerable > > to a broken or subverted sip proxy server, but otherwise you're safe. > > > > If there's consensus that it's acceptable to allow this mode, I can > > add > > language allowing it. However, I think this is a big enough change > > I'd like > > to hear positive consensus for it; this should get something more > > than just > > consent-by-silence from the working group. > > There was a comment from Hadriel Kaplan supporting this change, but > this is a big enough issue that I'd like more feedback before we go > forward. Any comments from other members of the working group (or > from the security ADs)? This seems like the right approach to me. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Feb 26 07:42:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDLE4-0000Pm-Lo; Sun, 26 Feb 2006 07:42:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDLE3-0000Nv-Be for tls@ietf.org; Sun, 26 Feb 2006 07:42:11 -0500 Received: from castle.ran.pp.ru ([213.134.196.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDLE2-0001PF-1Z for tls@ietf.org; Sun, 26 Feb 2006 07:42:11 -0500 Received: from localhost (localhost [127.0.0.1]) by castle.ran.pp.ru (Postfix) with ESMTP id 31264231FD; Sun, 26 Feb 2006 15:42:08 +0300 (MSK) Received: from castle.ran.pp.ru ([127.0.0.1]) by localhost (castle [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26273-01; Sun, 26 Feb 2006 15:42:06 +0300 (MSK) Received: by castle.ran.pp.ru (Postfix, from userid 10) id 6B518231F1; Sun, 26 Feb 2006 15:42:06 +0300 (MSK) Received: by mx.cryptocom.ru (Postfix, from userid 500) id B66D1F4F3; Sun, 26 Feb 2006 15:41:08 +0300 (MSK) Received: from manul.lan.cryptocom.ru (manul.lan.cryptocom.ru [10.51.17.211]) by mx.cryptocom.ru (Postfix) with ESMTP id 935C1F4C1; Sun, 26 Feb 2006 15:41:08 +0300 (MSK) Date: Sun, 26 Feb 2006 15:42:26 +0300 (MSK) From: Dmitry Belyavsky X-X-Sender: beldmit@manul.lan.cryptocom.ru To: Eric Rescorla Subject: Re: [TLS] New TLS 1.2 draft submitted In-Reply-To: <20060225194251.E1E7F222437@laser.networkresonance.com> Message-ID: References: <20060225194251.E1E7F222437@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ran.pp.ru X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Greetings! On Sat, 25 Feb 2006, Eric Rescorla wrote: > I've just submitted a new draft for TLS 1.2 > (draft-ietf-tls-rfc4346-bis-00.txt). Sorry, where can I download the draft? Thank you! -- SY, Dmitry Belyavsky (ICQ UIN 11116575) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 27 08:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDicQ-0004OV-AE; Mon, 27 Feb 2006 08:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDicP-0004OH-44 for tls@ietf.org; Mon, 27 Feb 2006 08:40:53 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDicM-0002J2-RR for tls@ietf.org; Mon, 27 Feb 2006 08:40:53 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 27FA71E8C1B; Mon, 27 Feb 2006 05:40:50 -0800 (PST) To: Dmitry Belyavsky Subject: Re: [TLS] New TLS 1.2 draft submitted References: <20060225194251.E1E7F222437@laser.networkresonance.com> From: Eric Rescorla Date: Mon, 27 Feb 2006 05:40:50 -0800 In-Reply-To: (Dmitry Belyavsky's message of "Sun, 26 Feb 2006 15:42:26 +0300 (MSK)") Message-ID: <8664n0din1.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dmitry Belyavsky writes: > Greetings! > > On Sat, 25 Feb 2006, Eric Rescorla wrote: > >> I've just submitted a new draft for TLS 1.2 >> (draft-ietf-tls-rfc4346-bis-00.txt). > > Sorry, where can I download the draft? http://scm.sipfoundry.org/rep/ietf-drafts/ekr/draft-ietf-tls-rfc4346-bis-00.txt -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Feb 27 11:03:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkq0-0008TZ-J7; Mon, 27 Feb 2006 11:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkpz-0008TO-C9 for tls@ietf.org; Mon, 27 Feb 2006 11:03:03 -0500 Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkpz-0008SD-3I for tls@ietf.org; Mon, 27 Feb 2006 11:03:03 -0500 Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FDkpy-0008MG-4o for tls@ietf.org; Mon, 27 Feb 2006 11:03:02 -0500 From: "Robert Holliday" To: Date: Mon, 27 Feb 2006 11:03:02 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcY7t0laHlwbXztHSE6vr8k+G99IIw== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Subject: [TLS] International Conference on Network Security 2006 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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="===============0230205003==" Errors-To: tls-bounces@lists.ietf.org Message-Id: This is a multi-part message in MIME format. --===============0230205003== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C63B8D.613E2CD0" This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C63B8D.613E2CD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Registration is Now Open Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_0030_01C63B8D.613E2CD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Registration is Now = Open

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://ww= w.isocore.com/networksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.= isocore.com/networksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /a>

 

 

 

------=_NextPart_000_0030_01C63B8D.613E2CD0-- --===============0230205003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0230205003==-- From tls-bounces@lists.ietf.org Mon Feb 27 11:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlPx-0003lP-EY; Mon, 27 Feb 2006 11:40:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDlPw-0003lH-7N for tls@ietf.org; Mon, 27 Feb 2006 11:40:12 -0500 Received: from mx2.cryptopro.ru ([213.59.158.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDlPv-0001BH-Es for tls@ietf.org; Mon, 27 Feb 2006 11:40:12 -0500 Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 19:41:55 +0300 Message-ID: <031401c63bbc$b821c870$0644a8c0@cp.ru> From: "Gregory S. Chudov" To: , "Eric Rescorla" References: <20060225194251.E1E7F222437@laser.networkresonance.com> Subject: Re: [TLS] New TLS 1.2 draft submitted Date: Mon, 27 Feb 2006 19:41:55 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-OriginalArrivalTime: 27 Feb 2006 16:41:55.0640 (UTC) FILETIME=[B82BB380:01C63BBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org First comments: 1) This draft proposes a new enumerated type, HashType, which is not mentioned in IANA Considerations section, so it is unclear, how new hash types can be defined. Also, would be nice to allocate a value for gost. 7.4.1.4.7 Cert Hash Types Proposed addition: ----------------------------------------------------------------------- enum{ - md5(0), sha1(1), sha256(2), sha512(3), (255) + md5(0), sha1(1), sha256(2), sha512(3), gostR3411(4), (255) } HashType; ----------------------------------------------------------------------- Proposed addition: ----------------------------------------------------------------------- HashType values are divided into three groups: 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols. 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are reserved for assignment for non-Standards Track methods. 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use. Additional information describing the role of IANA in the allocation of HashType code points is described in Section 11. ----------------------------------------------------------------------- There are a lot of MD5 certificates still around. Are they now intentionaly forbidden by default? ----------------------------------------------------------------------- Clients SHOULD send this extension if they support any algorithm other than SHA-1. If this extension is not used, servers SHOULD assume that the client supports only SHA-1. ----------------------------------------------------------------------- 11. IANA Considerations Chapter 7.4.4 became 7.4.5, but the references in IANA Considerations section is not updated. By the way, rfc2246bis contains a typo here too - it references 7.4.3 instead of 7.4.4. Proposed change: ----------------------------------------------------------------------- - Section 7.4.3 describes a TLS ClientCertificateType Registry to be + Section 7.4.5 describes a TLS ClientCertificateType Registry to be maintained by the IANA, as defining a number of such code point identifiers. ClientCertificateType identifiers with values in the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values from the range 64-223 (decimal) inclusive are assigned via [RFC 2434] Specification Required. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. The registry will be initially populated with the values in this - document, Section 7.4.4. + document, Section 7.4.5. + Section 7.4.1.4.7 describes a TLS HashType Registry to be + maintained by the IANA, as defining a number of such code point + identifiers. HashType identifiers with values in the + range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards + Action. Values from the range 64-223 (decimal) inclusive are assigned + via [RFC 2434] Specification Required. Identifier values from + 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. + The registry will be initially populated with the values in this + document, Section 7.4.4. ----------------------------------------------------------------------- And some more invalid section numbers: Table of Contents ----------------------------------------------------------------------- 7.4.10. Certificate verify 64 - 7.4.10. Finished 65 + 7.4.10. Finished 65 ----------------------------------------------------------------------- 7.4.9. Finished ----------------------------------------------------------------------- The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message. This - may be different from handshake_messages in Section 7.4.8 because it + may be different from handshake_messages in Section 7.4.10 because it ----------------------------------------------------------------------- 7.1. Change cipher spec protocol ----------------------------------------------------------------------- (See section 6.1.) The change cipher spec message is sent during the handshake after the security parameters have been agreed upon, but - before the verifying finished message is sent (see section 7.4.9). + before the verifying finished message is sent (see section 7.4.11). ----------------------------------------------------------------------- 7.4.10. Certificate verify 7.4.10. Finished ------------------------------------------------------------------------ -7.4.10. Finished +7.4.11. Finished ----------------------------------------------------------------------- F.1.1. Authentication and key exchange ----------------------------------------------------------------------- generate the finished messages, encryption keys, and MAC secrets (see - Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished + Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished message, parties thus prove that they know the correct pre_master_secret. ----------------------------------------------------------------------- F.1.1.2. RSA key exchange and authentication ----------------------------------------------------------------------- - the certificate verify message (see Section 7.4.8). The client signs + the certificate verify message (see Section 7.4.10). The client signs ----------------------------------------------------------------------- _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 03:46:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE0Ug-0002LC-MG; Tue, 28 Feb 2006 03:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE0Uf-0002L1-PA for tls@ietf.org; Tue, 28 Feb 2006 03:46:05 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE0Ue-000308-Gh for tls@ietf.org; Tue, 28 Feb 2006 03:46:05 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVE00EXW25624@usaga01-in.huawei.com> for tls@ietf.org; Tue, 28 Feb 2006 00:27:07 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVE00MU42VO8K@szxga02-in.huawei.com> for tls@ietf.org; Tue, 28 Feb 2006 16:43:01 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVE00ERA2VFDF@szxga02-in.huawei.com> for tls@ietf.org; Tue, 28 Feb 2006 16:43:00 +0800 (CST) Received: from [10.18.18.211] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPSA id <0IVE006CT319DF@szxml01-in.huawei.com>; Tue, 28 Feb 2006 16:46:24 +0800 (CST) Date: Tue, 28 Feb 2006 14:00:07 +0530 From: jimmy Subject: Re: [TLS] New TLS 1.2 draft submitted In-reply-to: <20060225194251.E1E7F222437@laser.networkresonance.com> To: Eric Rescorla Message-id: <44040A0F.9020304@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5 (Windows/20051201) References: <20060225194251.E1E7F222437@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > I've just submitted a new draft for TLS 1.2 > (draft-ietf-tls-rfc4346-bis-00.txt). > This still has (in Section 6.2.1 Fragmentation, NOTE:) the sentence - Data of different TLS Record layer content types MAY be interleaved. Application data is generally of higher precedence for transmission than other content types and therefore handshake records may be held if application data is pending. If the same language of tls1.0 is to be followed, (see http://www1.ietf.org/mail-archive/web/tls/current/msg00445.html), then shouldn't this be the other way round? -jb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 09:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5aC-0008WK-L9; Tue, 28 Feb 2006 09:12:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5aB-0008W9-JN; Tue, 28 Feb 2006 09:12:07 -0500 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5aA-0004PI-6Z; Tue, 28 Feb 2006 09:12:07 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 14:12:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard Date: Tue, 28 Feb 2006 14:11:59 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard Thread-Index: AcY1ozyRgIGeYBvaRka9q6C9vLWfPgGzUA8A From: "Stefan Santesson" To: "Russ Housley" , "Bill Fenner" , "Steven M. Bellovin" X-OriginalArrivalTime: 28 Feb 2006 14:12:04.0944 (UTC) FILETIME=[F3B61D00:01C63C70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf@ietf.org, iesg@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Just to clarify this point. The text in the introduction where the authors retained change control was a leftover from the original draft that was intended to go informational. We simply forgot to remove this when we changed the scope to informational. This is fixed in version 03 of the draft. Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: den 19 februari 2006 23:22 To: Bill Fenner; Steven M. Bellovin Cc: iesg@ietf.org; tls@ietf.org; ietf@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard I misunderstood the original question. I'll get it fixed or withdraw=20 the Last Call. Russ At 12:38 AM 2/19/2006, Bill Fenner wrote: > >Can we have a Proposed Standard > >without the IETF having change control? > >No. RFC3978 says, in section 5.2 where it describes the derivative >works limitation that's present in draft-santesson-tls-ume, "These >notices may not be used with any standards-track document". > > Bill _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 09:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5no-0006nm-KB; Tue, 28 Feb 2006 09:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5nn-0006i8-2g; Tue, 28 Feb 2006 09:26:11 -0500 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5nl-00057I-PP; Tue, 28 Feb 2006 09:26:11 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 14:26:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 14:26:03 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: 'TLS User Mapping Extension' to Proposed Standard Thread-Index: AcY1u+UOTgT+o5X+TAq6a4+FF4tVAwGtitBQ From: "Stefan Santesson" To: "Bill Strahm" , "Russ Housley" X-OriginalArrivalTime: 28 Feb 2006 14:26:08.0787 (UTC) FILETIME=[EAAE5630:01C63C72] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Bill Fenner , iesg@ietf.org, tls@ietf.org, ietf@ietf.org Subject: [TLS] RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org This empty appendix was removed in draft 02. As Russ stated before, an IPR disclosure has been posted to the IETF IPR page which can be found at: Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Bill Strahm [mailto:bill@strahm.net]=20 Sent: den 20 februari 2006 02:21 To: Russ Housley Cc: Bill Fenner; tls@ietf.org; ietf@ietf.org; iesg@ietf.org; Steven M. Bellovin Subject: Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard I saw all of the huff, and while I agree with it, I am more concerned about Appendix A. IPR Disclosure TBD What does that mean, and more specifically is a document with a TBD=20 section really ready for last call at all ? Bill Russ Housley wrote: > I misunderstood the original question. I'll get it fixed or withdraw=20 > the Last Call. >=20 > Russ >=20 >=20 > At 12:38 AM 2/19/2006, Bill Fenner wrote: >=20 >> >Can we have a Proposed Standard >> >without the IETF having change control? >> >> No. RFC3978 says, in section 5.2 where it describes the derivative >> works limitation that's present in draft-santesson-tls-ume, "These >> notices may not be used with any standards-track document". >> >> Bill >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 09:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5pM-0008TJ-MU; Tue, 28 Feb 2006 09:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE5pL-0008T3-Kz; Tue, 28 Feb 2006 09:27:47 -0500 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE5pK-00059p-B6; Tue, 28 Feb 2006 09:27:47 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 14:27:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 14:27:40 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: 'TLS User Mapping Extension' to Proposed Standard Thread-Index: AcY1u+UOTgT+o5X+TAq6a4+FF4tVAwGtitBQAAA5FmA= From: "Stefan Santesson" To: "Bill Strahm" , "Russ Housley" X-OriginalArrivalTime: 28 Feb 2006 14:27:45.0582 (UTC) FILETIME=[246014E0:01C63C73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Bill Fenner , iesg@ietf.org, tls@ietf.org, ietf@ietf.org Subject: [TLS] RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Sorry, managed to hit send button to early. The IPR statement is available at: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=3D688 Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Stefan Santesson=20 Sent: den 28 februari 2006 15:26 To: 'Bill Strahm'; Russ Housley Cc: Bill Fenner; tls@ietf.org; ietf@ietf.org; iesg@ietf.org; Steven M. Bellovin Subject: RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard This empty appendix was removed in draft 02. As Russ stated before, an IPR disclosure has been posted to the IETF IPR page which can be found at: Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Bill Strahm [mailto:bill@strahm.net]=20 Sent: den 20 februari 2006 02:21 To: Russ Housley Cc: Bill Fenner; tls@ietf.org; ietf@ietf.org; iesg@ietf.org; Steven M. Bellovin Subject: Re: Last Call: 'TLS User Mapping Extension' to Proposed Standard I saw all of the huff, and while I agree with it, I am more concerned about Appendix A. IPR Disclosure TBD What does that mean, and more specifically is a document with a TBD=20 section really ready for last call at all ? Bill Russ Housley wrote: > I misunderstood the original question. I'll get it fixed or withdraw=20 > the Last Call. >=20 > Russ >=20 >=20 > At 12:38 AM 2/19/2006, Bill Fenner wrote: >=20 >> >Can we have a Proposed Standard >> >without the IETF having change control? >> >> No. RFC3978 says, in section 5.2 where it describes the derivative >> works limitation that's present in draft-santesson-tls-ume, "These >> notices may not be used with any standards-track document". >> >> Bill >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 09:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6E2-0007IB-Ef; Tue, 28 Feb 2006 09:53:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Dz-0007Ds-P8; Tue, 28 Feb 2006 09:53:15 -0500 Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6Dz-00065e-27; Tue, 28 Feb 2006 09:53:15 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 14:53:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Date: Tue, 28 Feb 2006 14:53:07 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Thread-Index: AcY09Mhv90dgZ/GKTTWTV+JoUheWjgBkSi8AAXuz0BA= From: "Stefan Santesson" To: "Ari Medvinsky" , "Eric Rescorla" , X-OriginalArrivalTime: 28 Feb 2006 14:53:14.0084 (UTC) FILETIME=[B36EFA40:01C63C76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: tls@ietf.org, iesg@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Adding to Ari's arguments. There is one more argument why it would less functional to send the mapping data in the extension. The current draft under last call also includes a negotiation mechanism where the client and server can agree on what type of mapping data they support. If the mapping data is sent in the client hello, the client has no clue on what data the server needs unless prior knowledge has been established. It must then send all types of mapping data that it believes the server might need. This is less desirable than sending just the type of data the server explicitly has stated that it prefers out of the types the client has stated that it supports. While it would be technically possible to implement the same solution along with Eric's alternative suggestions, I don't think it has been demonstrated that it would provide any significant advantages. Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Ari Medvinsky [mailto:arimed@windows.microsoft.com]=20 Sent: den 21 februari 2006 02:32 To: Eric Rescorla; ietf@ietf.org Cc: tls@ietf.org; iesg@ietf.org Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Eric, Thank you for your feedback. Below are the problems that I see with the alternative proposals that you suggested when compared to the approach taken in the current draft: 1) Proposal 1: Send the user mapping extension in the initial Client Hello (as data along with the extension value). a) Problem: Privacy/Lack of user consent in information disclosure. The UPN sent in the user extension, uniquely identifies a principal - something that users concerned with preserving their privacy may object to (i.e., the large majority of SSL sites are server side auth only; the user was anonymous and now the user is identified by the UPN). To mitigate this problem to some extent (as I think you pointed out), the client can be configured to only send the user mapping information to some subset of servers (e.g., based on domain names). However, this completely lacks end user consent. The user's principal name will be automatically sent to every SSL server in the above list (as configured by admin) - even if the user does not wish to be identified to the target server (in SSL sessions with server side auth only and mutual auth). In contrast, if the mapping extension is sent on the third leg before the certificate msg (as it is in the current draft), the user has the option to bail out of client auth and not disclose the UPN or any data in the cert (e.g., by not typing the pin for the smartcard). b) Problem: Performance. In your email you stated that the UserMapping extension is likely to be around ~ 100 bytes and that's negligible and thus it is ok to send in the initial ClientHello msg - even if the server does not need it as is the case for server side auth only TLS connections. I disagree. As you know TLS is used in many different scenarios, for example: EAP/TLS (RFC http://www.ietf.org/rfc/rfc2716.txt) is used for Radius, wireless 802.1x, RAS (dial up), etc. The MTU in EAP is 1600 bytes. Thus even 100 bytes can cause additional fragmentation causing additional latency for RAS (consider dial up across geographically dispersed end points). Furthermore, per the current draft the userMapping structure can be extended, to carry multiple user mapping hints, thus causes further degradation in this scenario ... 2) Proposal 2: =20 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. This is essentially saying that the current extensibility mechanism in TLS is broken and that the userMapping extension in contrast to all other extension requires to 2 handshakes instead of one. The method that you are proposing is inconsistent with the approach used for every other TLS extension. =20 >From a performance standpoint, proposal 2 is still a bad choice. You stated that "The performance issue is quite modest with modern servers". While servers are getting faster, user load tends to follow suit; furthermore, this proposal costs additional latency. In contrast, the approach used in the current draft does not suffer from these problems.=20 Regards, -Ari -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Saturday, February 18, 2006 5:31 PM To: ietf@ietf.org Cc: tls@ietf.org; iesg@ietf.org Subject: [TLS] Re: Last Call: 'TLS User Mapping Extension' to ProposedStandard BACKGROUND This document describes an extension to TLS which allows the client to give the server a hint (the User Principal Name) about which directory entry to look up in order to verify the client's identity. This works as follows: 1. The client offers the extension (called UME) in the=20 ClientHello message.=20 2. The server accepts the extension. 3. The client sends the new HandshakeType to the server before sending its Certificate message. The packet flow looks like this (cut-and-pasted from the draft): Client Server ClientHello /* with user_mapping ext */ --------> ServerHello /* with user-mapping ext */ Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone --> UserMappingDataList Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data New handshake message marked by --> on the left. This document was presented to the TLS WG in Vancouver and there was only a very small amount of interest. The authors posted the -00 version of their draft on January 10. Some minor comments were made by a single WG member and these were addressed. The authors asked for a preliminary code point assignment on January 14. I provided a number of technical comments (including suggesting an alternate approach, described below) at that time, but was told that the implementation was already too far along to be changed significantly. Since the IETF would not have change control, this is an inappropriate work item for the TLS WG and therefore the authors appear to have decided on an Individual Submission. The reason for the intended status of Proposed Standard is that this extension defines a new Handshake Type and the TLS WG has decided that new Handshake Types require a Standards Action (See S 7.4 of draft-ietf-tls-rfc2246-13, in RFC-Ed queue). Contrary to the the Last Call announcement, the comments I raised originally have not been addressed--except to be told they weren't possible. For the reasons indicated below, I believe this document should not be advanced to Proposed Standard as-is. REVIEW COMMENTS The obvious design here would simply be to place the information in the UserMappingDataList (UMDL) message directly in the ClientHello extension. The draft argues that this is bad for the following reason: The reason the mapping data itself is not placed in the extension portion of the ClientHello is to prevent broadcasting this information to servers that don't understand the extension. Additionally, if new mapping information were to be considered confidential, the addition of a new handshake message allows the data to be encrypted using the servers public key. No other modifications to the protocol are required. The messages are detailed in the following sections. This is unconvincing for a number of reasons. First, TLS handles the case where an extension is not understood just fine. It's ignored. Since the extension appears to be less than 100 bytes, there's no performance issue. The authors suggest that there is a security issue: As the client is the initiator of this TLS extension, it needs to determine when it is appropriate to send the User Mapping Information. It may not be prudent to broadcast this information to just any server at any time, as it can reveal network infrastructure the client and server are using. - The client SHOULD only send the UserMappingDataList handshake message if it is agreed upon in the Hello exchange, preventing the information from being sent to a server that doesn't understand the User Mapping Extension. - The client SHOULD further only send this information if the server belongs to a domain to which the client intends to authenticate using the UPN as identifier. However, the second piece of information (the domain name of the server) is generally available to the client prior to the connection initiation, since it's used to look up the server's address. So, the client could decide whether to send the UMDL data prior to handshake initiation. One difference here is that the client now has the server's certificate and that certificate could potentially contain some X.509 Extension that indicated that the server was authorized to receive the UMDL data. However, this is of very limited security value because in the static RSA modes which are common with SSL/TLS, the server has not proved possession of the corresponding private key at this point in the handshake. Note that this draft does not describe any such extension. An attacker who wished to impersonate the server in order to capture the UMDL would be able to do so with a simple replay/cut-and-paste attack. Moreover, because the UMDL is sent in the clear (the draft claims that it could be encrypted but provides no facility for doing so) any passive attacker can capture the UMDL by observing a single handshake.=09 At best this strategy stops the client from inadvertantly sending the UMDL to a server which it *thinks* should support it (because it's got the right domain name) but which actually doesn't (perhaps because it's broken?). This seems to be of extremely limited value. AN ALTERNATE DESIGN There is an alternate design which has superior security properties and does not involve defining a new HandshakeType.=20 1. Do an ordinary TLS handshake without offering UME. 2. Initiate a TLS rehandshake and send the UMDL in an extension in the ClientHello. Because the second TLS handshake is conducted over the TLS session established in step (1), the entire UMDL extension exchange is protected. A passive attacker cannot capture the UMDL data and an active attacker cannot impersonate the server and force the transmission of the UMDL.=20 This approach has two (modest) drawbwacks. 1. It is slower because it requires two handshakes. 2. The client may have to authenticate twice (this is a special case of (1)). The second case can be easily ameliorated by having the client send an extension (empty UME?) in the first handshake as a signal that it wants to do UMDL and that the server should hold off on demanding client authentication until the rehandshake happens. The performance issue is quite modest with modern servers. Indeed, it's quite common for web servers to do a first handshake without cert-based client auth and then rehandshake with client auth if the client asks for a sensitive page. Note: there is an alternate design in which you do a client auth in the first handshake and then do a resumption in the second one but do UME. This is rather faster, both in terms of computation and round trips but is technically precluded by S 2.3 of RFC3546 which requires ignoring extensions if you do a resume. One could imagine relaxing this restriction but that hasn't been done yet. Note also that if the client isn't worried about the sensitivity of the UMDL, then it can simply offer the UME extension with a UMDL in the first handshake and skip the second handshake. Another (hacky) approach would be for the client to probe the server with an initial ClientHello (and no UME) and then abort the handshake and restart if it decides that it likes the server and wants to do UME. This would have equivalent security properties to this draft at the cost of a single round trip. SUMMARY The technique described in this document appears to be of limited usefulness. In particular, the lack of confidentiality for the UMDL is a big limitation in extending it to other applications than the one envisioned by Microsoft. There are alternate designs which don't have those limitations and don't involve allocating a new HandshakeType value. This document should not advance as a Proposed Standard. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 10:15:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Z2-00082v-1z; Tue, 28 Feb 2006 10:15:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE6Yz-00080k-NW; Tue, 28 Feb 2006 10:14:57 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE6Yy-0006si-DS; Tue, 28 Feb 2006 10:14:57 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 73A7A1E8C1B; Tue, 28 Feb 2006 07:14:55 -0800 (PST) To: "Stefan Santesson" Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard References: From: Eric Rescorla Date: Tue, 28 Feb 2006 07:14:55 -0800 In-Reply-To: (Stefan Santesson's message of "Tue, 28 Feb 2006 14:53:07 -0000") Message-ID: <861wxn8qhc.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Ari Medvinsky , iesg@ietf.org, ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Stefan Santesson" writes: > Adding to Ari's arguments. > There is one more argument why it would less functional to send the > mapping data in the extension. > > The current draft under last call also includes a negotiation mechanism > where the client and server can agree on what type of mapping data they > support. > > If the mapping data is sent in the client hello, the client has no clue > on what data the server needs unless prior knowledge has been > established. It must then send all types of mapping data that it > believes the server might need. This is less desirable than sending just > the type of data the server explicitly has stated that it prefers out of > the types the client has stated that it supports. > > While it would be technically possible to implement the same solution > along with Eric's alternative suggestions, I don't think it has been > demonstrated that it would provide any significant advantages. I don't want to get into a long point-by-point here. Suffice to say that I don't agree with either this analyis or Ari's. It would, as I noted, have the advantage of actually applying confidentiality for data you claim is sensitive while avoiding the need to declare a new code point. I consider both of these to be significant advantages. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 10:43:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE70a-000536-0D; Tue, 28 Feb 2006 10:43:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE70Y-00051G-5I for tls@ietf.org; Tue, 28 Feb 2006 10:43:26 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FE70W-00083G-UT for tls@ietf.org; Tue, 28 Feb 2006 10:43:26 -0500 Received: (qmail 27829 invoked by uid 0); 28 Feb 2006 15:34:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.126.156.113) by woodstock.binhost.com with SMTP; 28 Feb 2006 15:34:01 -0000 Message-Id: <7.0.0.16.2.20060228102346.04c9f6e8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 28 Feb 2006 10:26:16 -0500 To: EKR , "Stefan Santesson" From: Russ Housley Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard In-Reply-To: <861wxn8qhc.fsf@raman.networkresonance.com> References: <861wxn8qhc.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Ari Medvinsky , ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org I can see many situations where the information in this is not sensitive. In fact, in the primary use case, the use mapping information is not sensitive. An enterprise PKI is used in this situation, and the TLS extension is used to map the subject name in the certificate to the host account name. Russ At 10:14 AM 2/28/2006, Eric Rescorla wrote: >"Stefan Santesson" writes: > > Adding to Ari's arguments. > > There is one more argument why it would less functional to send the > > mapping data in the extension. > > > > The current draft under last call also includes a negotiation mechanism > > where the client and server can agree on what type of mapping data they > > support. > > > > If the mapping data is sent in the client hello, the client has no clue > > on what data the server needs unless prior knowledge has been > > established. It must then send all types of mapping data that it > > believes the server might need. This is less desirable than sending just > > the type of data the server explicitly has stated that it prefers out of > > the types the client has stated that it supports. > > > > While it would be technically possible to implement the same solution > > along with Eric's alternative suggestions, I don't think it has been > > demonstrated that it would provide any significant advantages. > >I don't want to get into a long point-by-point here. Suffice to say >that I don't agree with either this analyis or Ari's. It would, >as I noted, have the advantage of actually applying confidentiality >for data you claim is sensitive while avoiding the need to declare >a new code point. I consider both of these to be significant advantages. > >-Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 10:51:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE780-000868-88; Tue, 28 Feb 2006 10:51:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE77y-00085e-OO; Tue, 28 Feb 2006 10:51:06 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE77x-0008CY-Ez; Tue, 28 Feb 2006 10:51:06 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 05FD51E8C1B; Tue, 28 Feb 2006 07:51:05 -0800 (PST) To: Russ Housley Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard References: <861wxn8qhc.fsf@raman.networkresonance.com> <7.0.0.16.2.20060228102346.04c9f6e8@vigilsec.com> From: Eric Rescorla Date: Tue, 28 Feb 2006 07:51:04 -0800 In-Reply-To: <7.0.0.16.2.20060228102346.04c9f6e8@vigilsec.com> (Russ Housley's message of "Tue, 28 Feb 2006 10:26:16 -0500") Message-ID: <86r75n7a8n.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Ari Medvinsky , ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Russ Housley writes: > I can see many situations where the information in this is not > sensitive. In fact, in the primary use case, the use mapping > information is not sensitive. An enterprise PKI is used in this > situation, and the TLS extension is used to map the subject name in > the certificate to the host account name. But then we're left with the performance rationale that the user has some semi-infinite number of mappings that makes it impossible to send all of them and too hard to figure out which one. In light of the fact that in the original -01 proposal there wasn't even any negotiation for which type of UME data should be sent, is there any evidence that this is going to be an important/common case? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 11:51:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE845-0003sD-O7; Tue, 28 Feb 2006 11:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE844-0003rz-Nd for tls@ietf.org; Tue, 28 Feb 2006 11:51:08 -0500 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FE843-0001fB-Gp for tls@ietf.org; Tue, 28 Feb 2006 11:51:08 -0500 Received: (qmail 26608 invoked by uid 0); 28 Feb 2006 16:21:06 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.126.156.113) by woodstock.binhost.com with SMTP; 28 Feb 2006 16:21:06 -0000 Message-Id: <7.0.0.16.2.20060228111255.04c9b688@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 28 Feb 2006 11:18:58 -0500 To: EKR From: Russ Housley Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard In-Reply-To: <86r75n7a8n.fsf@raman.networkresonance.com> References: <861wxn8qhc.fsf@raman.networkresonance.com> <7.0.0.16.2.20060228102346.04c9f6e8@vigilsec.com> <86r75n7a8n.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Ari Medvinsky , ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric: > > I can see many situations where the information in this is not > > sensitive. In fact, in the primary use case, the use mapping > > information is not sensitive. An enterprise PKI is used in this > > situation, and the TLS extension is used to map the subject name in > > the certificate to the host account name. > >But then we're left with the performance rationale that the user has >some semi-infinite number of mappings that makes it impossible to send >all of them and too hard to figure out which one. In light of the fact >that in the original -01 proposal there wasn't even any negotiation >for which type of UME data should be sent, is there any evidence that >this is going to be an important/common case? This requires a crystal ball.... Apparently yours is different than mine, as the negotiation that you reference above was added to resolve comments from my AD review. We all know that there is not going to be a single name form that is useful in all situations. We also know that you cannot put every useful name form into the certificate. In fact, the appropriate value can change within the normal lifetime of a certificate, so putting it in the certificate will result in high revocation rates. This is the reason that I believe this TLS extension will be useful in environments beyond the one that was considered by the Microsoft authors. Your perspective may differ .... Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 13:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9O2-0008Mb-LX; Tue, 28 Feb 2006 13:15:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9O0-0008MH-Qf; Tue, 28 Feb 2006 13:15:48 -0500 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9Nz-0004iv-E8; Tue, 28 Feb 2006 13:15:48 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 18:15:46 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Date: Tue, 28 Feb 2006 18:15:44 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Thread-Index: AcY8hy33bKM9A901Q3m64GWpANS26wABaHDg From: "Stefan Santesson" To: "Russ Housley" , "EKR" X-OriginalArrivalTime: 28 Feb 2006 18:15:46.0234 (UTC) FILETIME=[FEADE9A0:01C63C92] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Ari Medvinsky , ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric, In a general sense, name hints are IDs and IDs are not secrets and no security system should depend on them being secrets. However, there might be privacy concerns on where and when you want to send what ID info to whom. We may e.g. have an issue of aggregate knowledge. It is always good design to minimize the information sent and not broadcast them around. ID1 and ID2 might not be a privacy issue when sent separately to different servers but may be a privacy issue if they are always sent together. In the primary use case there is no reason to encrypt the UPN name hint but if such requirement would arise for another hint type, then the current model allows a new hint type to be defined which could carry encrypted information, e.g. encrypted to the public key of the server certificate. On the name space issue; We are nowhere close to exhausting the name space (less than 5% used) for handshake messages. If we think we will do that in any reasonably foreseeable future, then we simply have to figure out a way to fix that problem before it becomes a blocking factor for protocol design.=20 There are ways to do that and maintaining backwards compatibility way before this becomes a problem. Stefan Santesson Program Manager, Standards Liaison Windows Security -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: den 28 februari 2006 17:19 To: EKR Cc: Stefan Santesson; Ari Medvinsky; ietf@ietf.org; tls@ietf.org Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard Eric: > > I can see many situations where the information in this is not > > sensitive. In fact, in the primary use case, the use mapping > > information is not sensitive. An enterprise PKI is used in this > > situation, and the TLS extension is used to map the subject name in > > the certificate to the host account name. > >But then we're left with the performance rationale that the user has >some semi-infinite number of mappings that makes it impossible to send >all of them and too hard to figure out which one. In light of the fact >that in the original -01 proposal there wasn't even any negotiation >for which type of UME data should be sent, is there any evidence that >this is going to be an important/common case? This requires a crystal ball.... Apparently yours is different than=20 mine, as the negotiation that you reference above was added to=20 resolve comments from my AD review. We all know that there is not going to be a single name form that is=20 useful in all situations. We also know that you cannot put every=20 useful name form into the certificate. In fact, the appropriate=20 value can change within the normal lifetime of a certificate, so=20 putting it in the certificate will result in high revocation rates. This is the reason that I believe this TLS extension will be useful=20 in environments beyond the one that was considered by the Microsoft=20 authors. Your perspective may differ .... Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 13:26:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9YV-0006IZ-D7; Tue, 28 Feb 2006 13:26:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE9YT-0006IF-Rm; Tue, 28 Feb 2006 13:26:37 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE9YR-00056p-E5; Tue, 28 Feb 2006 13:26:37 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 59A041E8C1B; Tue, 28 Feb 2006 10:26:34 -0800 (PST) To: "Stefan Santesson" Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard References: From: Eric Rescorla Date: Tue, 28 Feb 2006 10:26:34 -0800 In-Reply-To: (Stefan Santesson's message of "Tue, 28 Feb 2006 18:15:44 -0000") Message-ID: <86oe0rpcf9.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Ari Medvinsky , ietf@ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Stefan Santesson" writes: > Eric, > > In a general sense, name hints are IDs and IDs are not secrets and no > security system should depend on them being secrets. > > However, there might be privacy concerns on where and when you want to > send what ID info to whom. We may e.g. have an issue of aggregate > knowledge. It is always good design to minimize the information sent and > not broadcast them around. ID1 and ID2 might not be a privacy issue when > sent separately to different servers but may be a privacy issue if they > are always sent together. As I noted in my original review, you already have all the information you need about which server you're talking to prior to initiating the connection, so you can triage the hint list at that point. The only way in which your approach improves on this (in the current system, as opposed to some hypothesized new set of extensions) is to have the server indicate whether it's willing to accept the extension or not--which, as I indicated earlier, you can probe for. > In the primary use case there is no reason to encrypt the UPN name hint > but if such requirement would arise for another hint type, then the > current model allows a new hint type to be defined which could carry > encrypted information, e.g. encrypted to the public key of the server > certificate. And this kind if hackery is *exactly* what I'm concerned about. TLS has a perfectly good story if you're interested in preserving the confidentiality of data in the handshake. It's called rehandshake. > On the name space issue; > We are nowhere close to exhausting the name space (less than 5% used) > for handshake messages. If we think we will do that in any reasonably > foreseeable future, then we simply have to figure out a way to fix that > problem before it becomes a blocking factor for protocol design. > There are ways to do that and maintaining backwards compatibility way > before this becomes a problem. It's not primarily an exhaustion issue--though I do worry about that as well. It's an issue of cluttering up the primary TLS state machine with things that aren't particularly generic and could be done better in other ways. At this point, I think we're just repeating ourselves. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 13:57:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEA28-00061C-8t; Tue, 28 Feb 2006 13:57:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEA27-0005zA-18; Tue, 28 Feb 2006 13:57:15 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEA26-0006CP-Pu; Tue, 28 Feb 2006 13:57:14 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k1SIvEVp029708; Tue, 28 Feb 2006 13:57:14 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k1SIvD105539; Tue, 28 Feb 2006 13:57:14 -0500 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k1SIvAKv005422; Tue, 28 Feb 2006 13:57:12 -0500 Message-ID: <44049C6B.9080805@redhat.com> Date: Tue, 28 Feb 2006 10:54:35 -0800 From: Wan-Teh Chang User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: Last Call: 'TLS User Mapping Extension' toProposedStandard References: <861wxn8qhc.fsf@raman.networkresonance.com> <7.0.0.16.2.20060228102346.04c9f6e8@vigilsec.com> <86r75n7a8n.fsf@raman.networkresonance.com> <7.0.0.16.2.20060228111255.04c9b688@vigilsec.com> In-Reply-To: <7.0.0.16.2.20060228111255.04c9b688@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ietf@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > > We all know that there is not going to be a single name form that is > useful in all situations. We also know that you cannot put every useful > name form into the certificate. In fact, the appropriate value can > change within the normal lifetime of a certificate, so putting it in the > certificate will result in high revocation rates. > > This is the reason that I believe this TLS extension will be useful in > environments beyond the one that was considered by the Microsoft > authors. Your perspective may differ .... I agree. A rationale like the above would be a good addition to the Internet-Draft to strengthen its motivation. Re: EKR's suggested alternatives While adding a new HandshakeType will incur the costs of a Standards track RFC, we should not go out of our way to avoid it. The proposed solution in the Internet-Draft looks clean and natural to me. Instead of adding a new HandshakeType, can we extend the Certificate message to include the user mapping data list as ancillary data? Re: draft 02 1. Sec. 5 "Security Considerations" says: - The client SHOULD further only send this information if the server belongs to a domain to which the client intends to authenticate using the UPN as identifier. I have some questions about this paragraph. How does the client determine which domain the server belongs to without asking the server? Should the server send its domain to the client in the ServerHello user-mapping extension? (This would be analogous to the certificate_authorities field in the CertificateRequest message.) Is it possible or common for a client to belong to multiple domains and have multiple UPNs? If so, how does a client that belongs to multiple domains pick a UPN to send to the server? 2. It would be good to define at least one other UserMappingType as a proof that the framework can be applied to a non-Microsoft environment. 3. If the UserMappingDataList and Certificate messages may be sent in either order, it would be good to specify that UserMappingDataList be sent after Certificate. This order would highlight UserMappingDataList's role of providing additional information to augment the certificate, and the implicit requirement that UserMappingDataList only be used in conjunction with a client certificate. (I assume that the server cannot send a ServerHello with user-mapping extension without following with a CertificateRequest message.) 4. I'd be interested in a use case that elaborates how a server uses the UpnDomainHint and the client certificate to locate a user in a directory database and what the server can do when the user has been located. Wan-Teh Chang _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Feb 28 18:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEiu-0001OE-01; Tue, 28 Feb 2006 18:57:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEEba-0008Lw-JP; Tue, 28 Feb 2006 18:50:10 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEEba-0005j3-F9; Tue, 28 Feb 2006 18:50:10 -0500 Received: from [156.154.24.129] (helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FEEbT-0006RB-K1; Tue, 28 Feb 2006 18:50:10 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1SNo2BX032188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2006 23:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FEEbS-0006vT-DQ; Tue, 28 Feb 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Feb 2006 18:50:02 -0500 X-Spam-Score: -5.9 (-----) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ctr-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES Counter Mode Cipher Suites for TLS and DTLS Author(s) : N. Modadugu, E. Rescorla Filename : draft-ietf-tls-ctr-00.txt Pages : 9 Date : 2006-2-28 This document describes the use of the Advanced Encryption Standard (AES) Counter Mode for use as a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.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-ctr-00.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-ctr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-28154500.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ctr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ctr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-28154500.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart--