From tls-bounces@lists.ietf.org Mon Oct 03 10:55:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRit-0007bF-LM; Mon, 03 Oct 2005 10:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRis-0007b6-4Y for tls@megatron.ietf.org; Mon, 03 Oct 2005 10:55:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09331 for ; Mon, 3 Oct 2005 10:55:20 -0400 (EDT) Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EMRrM-0001bd-Rs for tls@ietf.org; Mon, 03 Oct 2005 11:04:09 -0400 Received: from simon ([70.51.144.217]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20051003145519.VSBK26550.tomts20-srv.bellnexxia.net@simon>; Mon, 3 Oct 2005 10:55:19 -0400 From: "Simon Blake-Wilson" To: Subject: RE: [TLS] IESG Feedback on RFC 3546 Date: Mon, 3 Oct 2005 10:55:19 -0400 Message-ID: <098501c5c82a$78fceb30$af00a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <20050922203812.2A8798A06E@laser.networkresonance.com> MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0902469600==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0902469600== Content-Type: multipart/signed; boundary="----=_NextPart_000_0980_01C5C808.F1C6AC30"; micalg=SHA1; protocol="application/x-pkcs7-signature" This is a multi-part message in MIME format. ------=_NextPart_000_0980_01C5C808.F1C6AC30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eric, I've just posted an updated draft which I believe addresses all the comments you identified below. It should appear shortly. Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Eric Rescorla > Sent: Thursday, September 22, 2005 4:25 PM > To: tls@ietf.org > Subject: [TLS] IESG Feedback on RFC 3546 > > > I've been working with the IESG to reach resolution on issues > raised during the IESG review > (https://datatracker.ietf.org/public/pidtracker.cgi?command=vi > ew_id&dTag=12653&rfc_flag=0) > > Here's my assessment of what needs to be done: > 1. In Section 1., clarify how non-extensions-capable servers > receive requests for extensions support. This is clear > in 2246, but it would be useful explanation. [Mankin] > > 2. In Section 2.3, suggest changing "server initiated" > to "server oriented" extensions and expand the discussion > a little bit, making clear that the client is offering > the capability to understand said extension and that > the server is taking it up on this offer. [Mankin] > > 3. In S 3.3, provide advice that only HTTP, HTTPS, and > FTP are the protocols that are expected to be used here > and that other protocols may create unexpected problems. > [Hardie] > > 4. Indicate that the ID updates both 2246 and 2246bis, > with normative references to both, because this > document applies to both TLS 1.0 and TLS 1.1 [Hollenbeck] > > 5. S 9 Update the IANA sections to indicate that the change > controller for this MIME type to be the IESG [Hartman] > > Once the document is updated to reflect these, we should be > good to go. > > -Ekr > > > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_0980_01C5C808.F1C6AC30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMDMxNDU1MTlaMCMGCSqGSIb3 DQEJBDEWBBTHPpXrtMspbQEVmiszY32/g6Y9tzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgHTFAnrU2kR62hO94ZQjJ1EbLRMHqlfk8Ifji5qFcO1MPz0j/EL5g7a+ 4b3OrtDoEMn624cxj1C6uN8xm4AwMkD5iHrlm6sPWxCJqh4b/QMOy51K29aPNZ4E+XkE3/sZZ7WV M9rTGxOtl6SXyHa35MchQ6WPMxswQySrHwyzYf2FAAAAAAAA ------=_NextPart_000_0980_01C5C808.F1C6AC30-- --===============0902469600== 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 --===============0902469600==-- From tls-bounces@lists.ietf.org Tue Oct 04 10:50:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo7I-0006vs-0R; Tue, 04 Oct 2005 10:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMo7G-0006v8-4W for tls@megatron.ietf.org; Tue, 04 Oct 2005 10:50:02 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24551 for ; Tue, 4 Oct 2005 10:49:59 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EMo7F-0007jt-PR; Tue, 04 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Oct 2005 10:50:01 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Extensions Author(s) : S. Blake-Wilson, et al. Filename : draft-ietf-tls-rfc3546bis-02.txt Pages : 29 Date : 2005-10-4 This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-02.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-rfc3546bis-02.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-rfc3546bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-4102710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc3546bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc3546bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-4102710.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Wed Oct 05 16:12:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFcT-00012g-0a; Wed, 05 Oct 2005 16:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDfm-0001U6-3d for tls@megatron.ietf.org; Wed, 05 Oct 2005 14:07:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07662 for ; Wed, 5 Oct 2005 14:07:20 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENDog-00034p-Uy for tls@ietf.org; Wed, 05 Oct 2005 14:16:36 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2005 11:07:12 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j95I78KC009184; Wed, 5 Oct 2005 11:07:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] WG review of draft-salowey-tls-ticket-03.txt Date: Wed, 5 Oct 2005 11:12:26 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906055B1C@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] WG review of draft-salowey-tls-ticket-03.txt Thread-Index: AcW9PRrz0lKwGoZfSVKEX+UCw7fRYwMj0XCQ From: "Salowey, Joe" To: "Tim Dierks" , "EKR" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 > - Can the server send NewSessionTicket on a resumed session?=20 > I'm sure people will want to do this at some point, because=20 > they'll be storing something in the ticket they want to=20 > update (last connection time, for example). >=20 [Joe] Here is some proposed text to handle this case. Note that in this cae the server sends the ticket before the client finished which can raise some issues (e.g the server is not really sure that it is the client that it gave the ticket), but I don't think they are too servere. Proposed text to adde to section 3.1: "If the server successfully verifies the client's ticket then it MAY renew the ticket to extend its lifetime by including a SessionTicket handshake message after the ServerHello. The client should start using the new ticket as soon as possible for new connections. Note that since the updated ticket is issued before the handshake completes it is possible that the client may not put the new ticket into use before it initiates new connections. The server MUST NOT assume the client actually received the updated ticket until it successfully verifies the client's finished message." _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 05 16:12:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFcW-00015t-NB; Wed, 05 Oct 2005 16:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENDyK-0008JQ-Ak for tls@megatron.ietf.org; Wed, 05 Oct 2005 14:26:32 -0400 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08332 for ; Wed, 5 Oct 2005 14:26:30 -0400 (EDT) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 9C9B9100C9; Wed, 5 Oct 2005 14:26:00 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20713-26; Wed, 5 Oct 2005 14:25:55 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7C0C910084; Wed, 5 Oct 2005 14:25:55 -0400 (EDT) In-Reply-To: <7210B31550AC934A8637D6619739CE6905FAE67B@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Wed, 5 Oct 2005 14:27:02 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 10/05/2005 02:27:05 PM, Serialize complete at 10/05/2005 02:27:05 PM 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="===============1650859006==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1650859006== Content-Type: multipart/alternative; boundary="=_alternative 006548FF85257091_=" This is a multipart message in MIME format. --=_alternative 006548FF85257091_= Content-Type: text/plain; charset="US-ASCII" After sending a client hello containing a TLS Ticket the client doesn't really have any idea whether the server will agree to resume using the ticket. To me it get's a little confusing since several scenarios are possible: - the server doesn't understand TLS Ticket extension and does a full handshake - the server doesn't understand TLS Ticket extension and resumes using the sessionID - the server resumes using the ticket and doesn't send a sessionID - the server resumes using the ticket but also sends a sessionID (is this allowable?) - the server decides not to resume using the ticket , does a full handshake and sends a new ticket I think it would simplify client implementation if the server provided some indication it intends to proceed with resumption using the client's ticket. What about including an extension in the server hello that would indicate to the client that the server will resume using the ticket? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com tls-bounces@lists.ietf.org wrote on 09/30/2005 07:47:14 PM: > Hi Nelson, > > We had discussed keeping the server side cache mechanism separate from > the client side cache mechanism when implementing this in case a server > had some reason for supporting both. If a server did not want to store > state then it would send an empty session ID. The server could decide > to send both a ticket and session ID if it intended to store state. > Likewise the client could decide to send both a session ID and ticket, > then the server could decide which to honor. If the server returns an > empty session ID (and continues on to the finished message) it is using > the ticket, if it returns the session ID then it is using the server > cache. > > In the case where a client side ticket is used and an implementation > needed a session ID associated with the ticket it could generate this > locally as you stated. For the server this could be stored in the > ticket, on the client it could be a hash of the ticket. I'm not sure if > we should cover this local implementation issue in the spec or not. > > Joe > > > -----Original Message----- > > From: Nelson B. Bolyard [mailto:nelson@bolyard.com] > > Sent: Thursday, September 29, 2005 5:04 PM > > To: Salowey, Joe > > Cc: Pasi.Eronen@nokia.com; tls@ietf.org > > Subject: Re: [TLS] WG review of draft-salowey-tls-ticket-04.txt > > > > Joe, et. al. TLSers, > > > > My concern about the server sending both a session ID and a > > ticket is that it seems to me that when a server sends a > > session ID in the server hello, that amounts to a commitment > > by the server to restart the session later if the client > > sends that session ID in a client hello (within the session > > lifetime, and assuming the session has not been invalidated), > > even if the client does not present the ticket for that session. > > > > By that reasoning, requiring the server to send a session ID > > with the ticket, also obligates the server to keep that > > session info in its own session cache, so that it can later > > restart that session. If the server is so obligated, the use > > of the ticket does not relieve the server of the burden of > > keeping its own copy of the session state. But it is the > > relief of that burden that motivates this entire idea, IMO. > > > > If the server is NOT going to keep a copy of the session > > state, and will NOT be able to restart that session later > > (unless the client also sends in the ticket), then what is > > the value of the server sending that session ID? To whom is > > that non-reusable session ID of value? > > If the client cannot rely on that session ID for session > > restart purposes, then of what value is that session id to the client? > > > > In answer to those questions, it has been suggested to me > > that there are TLS implementations that make the TLS session > > ID available to the application that uses it, so that the > > application can correlate its own data to the TLS session. > > It has also been suggested that there MAY be TLS > > implementations that allow the applications that use them to > > ask the TLS code to restart a specific session by specifying > > the session ID. > > This would suggest a possible use for session IDs, even when > > those IDs cannot be used to restart sessions. > > > > However, I think that such applications may already be in > > trouble, because the existing TLS RFC does not require TLS > > servers to always send a session ID in the server hello. So > > clients that depend on non-empty session ID strings may > > already fail with those servers. Further, the TLS > > implementation could offer its own substitute string locally > > in such cases. > > > > In order to properly set a client's expectation regarding the > > ability to subsequently restart a session based on the > > session ID alone, I think it is logical to NOT send the > > session ID in the cases where the ticket is required to > > subsequently restart the session, and in which the session > > cannot be subsequently restarted based on session ID alone. > > > > /Nelson > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 006548FF85257091_= Content-Type: text/html; charset="US-ASCII"
After sending a client hello containing a TLS Ticket the client doesn't really have any idea whether the server will agree to resume using the ticket.
To me it get's a little confusing since several scenarios are possible:
- the server doesn't understand TLS Ticket extension and does a full handshake
- the server doesn't understand TLS Ticket extension and resumes using the sessionID
- the server resumes using the ticket and doesn't send a sessionID
- the server resumes using the ticket but also sends a sessionID (is this allowable?)
- the server decides not to resume using the ticket , does a full handshake and sends a new ticket

I think it would simplify client implementation if the server provided some indication it intends to proceed with resumption using the client's ticket.
What about including an extension in the server hello that would indicate to the client that the server will resume using the ticket?



-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

tls-bounces@lists.ietf.org wrote on 09/30/2005 07:47:14 PM:

> Hi Nelson,
>
> We had discussed keeping the server side cache mechanism separate from
> the client side cache mechanism when implementing this in case a server
> had some reason for supporting both.  If a server did not want to store
> state then it would send an empty session ID.  The server could decide
> to send both a ticket and session ID if it intended to store state.
> Likewise the client could decide to send both a session ID and ticket,
> then the server could decide which to honor.  If the server returns an
> empty session ID (and continues on to the finished message) it is using
> the ticket, if it returns the session ID then it is using the server
> cache.
>
> In the case where a client side ticket is used and an implementation
> needed a session ID associated with the ticket it could generate this
> locally as you stated.  For the server this could be stored in the
> ticket, on the client it could be a hash of the ticket.  I'm not sure if
> we should cover this local implementation issue in the spec or not.  
>
> Joe
>
> > -----Original Message-----
> > From: Nelson B. Bolyard [mailto:nelson@bolyard.com]
> > Sent: Thursday, September 29, 2005 5:04 PM
> > To: Salowey, Joe
> > Cc: Pasi.Eronen@nokia.com; tls@ietf.org
> > Subject: Re: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> >
> > Joe, et. al. TLSers,
> >
> > My concern about the server sending both a session ID and a
> > ticket is that it seems to me that when a server sends a
> > session ID in the server hello, that amounts to a commitment
> > by the server to restart the session later if the client
> > sends that session ID in a client hello (within the session
> > lifetime, and assuming the session has not been invalidated),
> > even if the client does not present the ticket for that session.
> >
> > By that reasoning, requiring the server to send a session ID
> > with the ticket, also obligates the server to keep that
> > session info in its own session cache, so that it can later
> > restart that session.  If the server is so obligated, the use
> > of the ticket does not relieve the server of the burden of
> > keeping its own copy of the session state.  But it is the
> > relief of that burden that motivates this entire idea, IMO.
> >
> > If the server is NOT going to keep a copy of the session
> > state, and will NOT be able to restart that session later
> > (unless the client also sends in the ticket), then what is
> > the value of the server sending that session ID?  To whom is
> > that non-reusable session ID of value?
> > If the client cannot rely on that session ID for session
> > restart purposes, then of what value is that session id to the client?
> >
> > In answer to those questions, it has been suggested to me
> > that there are TLS implementations that make the TLS session
> > ID available to the application that uses it, so that the
> > application can correlate its own data to the TLS session.  
> > It has also been suggested that there MAY be TLS
> > implementations that allow the applications that use them to
> > ask the TLS code to restart a specific session by specifying
> > the session ID.
> > This would suggest a possible use for session IDs, even when
> > those IDs cannot be used to restart sessions.
> >
> > However, I think that such applications may already be in
> > trouble, because the existing TLS RFC does not require TLS
> > servers to always send a session ID in the server hello.  So
> > clients that depend on non-empty session ID strings may
> > already fail with those servers.  Further, the TLS
> > implementation could offer its own substitute string locally
> > in such cases.
> >
> > In order to properly set a client's expectation regarding the
> > ability to subsequently restart a session based on the
> > session ID alone, I think it is logical to NOT send the
> > session ID in the cases where the ticket is required to
> > subsequently restart the session, and in which the session
> > cannot be subsequently restarted based on session ID alone.
> >
> > /Nelson
> >
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 006548FF85257091_=-- --===============1650859006== 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 --===============1650859006==-- From tls-bounces@lists.ietf.org Wed Oct 05 17:25:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGlV-0007HU-TY; Wed, 05 Oct 2005 17:25:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENGlV-0007HO-3r for tls@megatron.ietf.org; Wed, 05 Oct 2005 17:25:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01736 for ; Wed, 5 Oct 2005 17:25:26 -0400 (EDT) Received: from [12.152.251.110] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENGuR-0005Ij-KJ for tls@ietf.org; Wed, 05 Oct 2005 17:34:44 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id A00F6B832; Wed, 5 Oct 2005 14:25:14 -0700 (PDT) To: Rob Dugal Subject: Re: [TLS] WG review of draft-salowey-tls-ticket-04.txt References: From: Eric Rescorla Date: Wed, 05 Oct 2005 14:25:14 -0700 In-Reply-To: (Rob Dugal's message of "Wed, 5 Oct 2005 14:27:02 -0400") Message-ID: <86fyrflkqt.fsf@delta.rtfm.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Rob Dugal writes: > After sending a client hello containing a TLS Ticket the client doesn't > really have any idea whether the server will agree to resume using the > ticket. > To me it get's a little confusing since several scenarios are possible: > - the server doesn't understand TLS Ticket extension and does a full > handshake > - the server doesn't understand TLS Ticket extension and resumes using the > sessionID Neither of these should happen, because the client can only get a ticket from a server that supports the extension. > - the server resumes using the ticket and doesn't send a sessionID > - the server resumes using the ticket but also sends a sessionID (is this > allowable?) As I recall, the suggestion was made not to allow sessionIDs with tickets so this shouldn't happen. > - the server decides not to resume using the ticket , does a full > handshake and sends a new ticket This is normal.... > I think it would simplify client implementation if the server provided > some indication it intends to proceed with resumption using the client's > ticket. > What about including an extension in the server hello that would indicate > to the client that the server will resume using the ticket? Isn't that what providing the ticket means? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 09:33:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVsH-00014U-1l; Thu, 06 Oct 2005 09:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVsG-00014P-CE for tls@megatron.ietf.org; Thu, 06 Oct 2005 09:33:28 -0400 Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02835 for ; Thu, 6 Oct 2005 09:33:26 -0400 (EDT) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id D4258100DC; Thu, 6 Oct 2005 09:32:56 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22262-91; Thu, 6 Oct 2005 09:32:55 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 8D099100C5; Thu, 6 Oct 2005 09:32:55 -0400 (EDT) In-Reply-To: <86fyrflkqt.fsf@delta.rtfm.com> To: EKR Subject: Re: [TLS] WG review of draft-salowey-tls-ticket-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 6 Oct 2005 09:34:04 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 10/06/2005 09:34:05 AM, Serialize complete at 10/06/2005 09:34:05 AM 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="===============2074377044==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============2074377044== Content-Type: multipart/alternative; boundary="=_alternative 004AB69485257092_=" This is a multipart message in MIME format. --=_alternative 004AB69485257092_= Content-Type: text/plain; charset="US-ASCII" Eric Rescorla wrote on 10/05/2005 05:25:14 PM: > Rob Dugal writes: > > > After sending a client hello containing a TLS Ticket the client doesn't > > really have any idea whether the server will agree to resume using the > > ticket. > > To me it get's a little confusing since several scenarios are possible: > > - the server doesn't understand TLS Ticket extension and does a full > > handshake > > - the server doesn't understand TLS Ticket extension and resumes using the > > sessionID > > Neither of these should happen, because the client can only get > a ticket from a server that supports the extension. > > > - the server resumes using the ticket and doesn't send a sessionID > > - the server resumes using the ticket but also sends a sessionID (is this > > allowable?) > As I recall, the suggestion was made not to allow sessionIDs with > tickets so this shouldn't happen. > > > - the server decides not to resume using the ticket , does a full > > handshake and sends a new ticket > This is normal.... > > > I think it would simplify client implementation if the server provided > > some indication it intends to proceed with resumption using the client's > > ticket. > > What about including an extension in the server hello that would indicate > > to the client that the server will resume using the ticket? > Isn't that what providing the ticket means? Actually having a ticket doesn't guarantee the server will later resume with it. For example, the ticket could be old and the server might not want to use it. My concern is that without knowing that the server will resume using the ticket it get's a little difficult to know what handshake messages the server will respond with. When the server resumes with the sessionID it is pretty clear because the server returns the same sessionID in the ServerHello as the client sent in the ClientHello. But in TLS ticket there is no clear indication from the ServerHello that the server will resume. And now there is also the proposal for allowing the server to send NewSessionTicket on a resumed session. Which also brings up the question: what does the server do if it receives an invalid ticket, such as a forged ticket? Does it just ignore the ticket? Send an alert? > > -Ekr --=_alternative 004AB69485257092_= Content-Type: text/html; charset="US-ASCII"
Eric Rescorla <ekr@rtfm.com> wrote on 10/05/2005 05:25:14 PM:

> Rob Dugal <RDugal@certicom.com> writes:
>
> > After sending a client hello containing a TLS Ticket the client doesn't
> > really have any idea whether the server will agree to resume using the
> > ticket.
> > To me it get's a little confusing since several scenarios are possible:
> > - the server doesn't understand TLS Ticket extension and does a full
> > handshake
> > - the server doesn't understand TLS Ticket extension and resumes using the
> > sessionID
>
> Neither of these should happen, because the client can only get
> a ticket from a server that supports the extension.
>
> > - the server resumes using the ticket and doesn't send a sessionID
> > - the server resumes using the ticket but also sends a sessionID (is this
> > allowable?)
> As I recall, the suggestion was made not to allow sessionIDs with
> tickets so this shouldn't happen.
>
> > - the server decides not to resume using the ticket , does a full
> > handshake and sends a new ticket
> This is normal....
>
> > I think it would simplify client implementation if the server provided
> > some indication it intends to proceed with resumption using the client's
> > ticket.
> > What about including an extension in the server hello that would indicate
> > to the client that the server will resume using the ticket?
> Isn't that what providing the ticket means?

Actually having a ticket doesn't guarantee the server will later resume with it.
For example, the ticket could be old and the server might not want to use it.
My concern is that without knowing that the server will resume using the ticket
it get's a little difficult to know what handshake messages the server will respond
with. When the server resumes with the sessionID it is pretty clear because the
server returns the same sessionID in the ServerHello as the client sent in the
ClientHello. But in TLS ticket there is no clear indication from the ServerHello
that the server will resume. And now there is also the proposal for allowing the
server to send NewSessionTicket on a resumed session.

Which also brings up the question: what does the server do if it receives an invalid ticket,
such as a forged ticket? Does it just ignore the ticket? Send an alert?


>
> -Ekr
 --=_alternative 004AB69485257092_=-- --===============2074377044== 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 --===============2074377044==-- From tls-bounces@lists.ietf.org Thu Oct 06 10:10:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWS6-0005ic-0P; Thu, 06 Oct 2005 10:10:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWS3-0005iS-W8 for tls@megatron.ietf.org; Thu, 06 Oct 2005 10:10:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05542 for ; Thu, 6 Oct 2005 10:10:25 -0400 (EDT) Received: from [12.152.251.10] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENWb7-0001Gw-Cr for tls@ietf.org; Thu, 06 Oct 2005 10:19:52 -0400 Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 67EE3B835 for ; Thu, 6 Oct 2005 07:10:05 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Thu, 06 Oct 2005 07:10:05 -0700 From: Eric Rescorla Message-Id: <20051006141005.67EE3B835@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org We have two hours to meet in Vancouver. Can people please send proposed agenda items to me by Thu Oct 13? In the items, please send me: Name: Topic: Draft (if any): Time required: Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 10:24:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWfX-0001y1-36; Thu, 06 Oct 2005 10:24:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWfW-0001xO-6U for tls@megatron.ietf.org; Thu, 06 Oct 2005 10:24:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06952 for ; Thu, 6 Oct 2005 10:24:19 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENWoY-0001zy-Tn for tls@ietf.org; Thu, 06 Oct 2005 10:33:46 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j96EMPaU010851; Thu, 6 Oct 2005 17:22:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Oct 2005 17:23:47 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Oct 2005 17:23:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt Date: Thu, 6 Oct 2005 17:23:22 +0300 Message-ID: Thread-Topic: [TLS] WG review of draft-salowey-tls-ticket-04.txt Thread-Index: AcXKex5dBLR8SOUpSuWwRgxXrHgmXQABYLfg To: X-OriginalArrivalTime: 06 Oct 2005 14:23:27.0266 (UTC) FILETIME=[84827020:01C5CA81] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Rob Dugal wrote: =09 > Actually having a ticket doesn't guarantee the server will > later resume with it. > > For example, the ticket could be old and the server might not want > to use it. My concern is that without knowing that the server will > resume using the ticket it get's a little difficult to know what > handshake messages the server will respond with. When the server > resumes with the sessionID it is pretty clear because the server > returns the same sessionID in the ServerHello as the client sent in > the ClientHello. But in TLS ticket there is no clear indication from > the ServerHello that the server will resume. And now there is also > the proposal for allowing the server to send NewSessionTicket on a > resumed session. Hmm.. I agree, it would be nice to have an unambiguous signal=20 in the ServerHello that tells the client resumption is happening. This would be the case if we also included the normal sessionID as I suggested earlier in http://www.imc.org/ietf-tls/mail-archive/msg04709.html > Which also brings up the question: what does the server do if it > receives an invalid ticket, such as a forged ticket? Does it just > ignore the ticket? Send an alert? Same thing it does when it receives an invalid session ID: ignores it and starts a full handshake. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 10:24:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWg0-00022e-Re; Thu, 06 Oct 2005 10:24:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWfz-00022W-Ic for tls@megatron.ietf.org; Thu, 06 Oct 2005 10:24:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06974 for ; Thu, 6 Oct 2005 10:24:49 -0400 (EDT) Received: from [12.152.251.10] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENWp4-00020h-Ve for tls@ietf.org; Thu, 06 Oct 2005 10:34:16 -0400 Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id CBD0AB831 for ; Thu, 6 Oct 2005 07:24:36 -0700 (PDT) To: tls@ietf.org Subject: RE: [TLS] IESG Feedback on RFC 3546 X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Thu, 06 Oct 2005 07:24:36 -0700 From: Eric Rescorla Message-Id: <20051006142436.CBD0AB831@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Eric Rescorla > Sent: Thursday, September 22, 2005 4:25 PM > To: tls@ietf.org > Subject: [TLS] IESG Feedback on RFC 3546 > > > I've been working with the IESG to reach resolution on issues > raised during the IESG review > (https://datatracker.ietf.org/public/pidtracker.cgi?command=vi > ew_id&dTag=12653&rfc_flag=0) > > Here's my assessment of what needs to be done: > 1. In Section 1., clarify how non-extensions-capable servers > receive requests for extensions support. This is clear > in 2246, but it would be useful explanation. [Mankin] > > 2. In Section 2.3, suggest changing "server initiated" > to "server oriented" extensions and expand the discussion > a little bit, making clear that the client is offering > the capability to understand said extension and that > the server is taking it up on this offer. [Mankin] > > 3. In S 3.3, provide advice that only HTTP, HTTPS, and > FTP are the protocols that are expected to be used here > and that other protocols may create unexpected problems. > [Hardie] > > 4. Indicate that the ID updates both 2246 and 2246bis, > with normative references to both, because this > document applies to both TLS 1.0 and TLS 1.1 [Hollenbeck] These changes seem to have been made and be fine. > 5. S 9 Update the IANA sections to indicate that the change > controller for this MIME type to be the IESG [Hartman] This does not seem to have been done. Can you fix? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 12:27:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYae-0003yl-Ep; Thu, 06 Oct 2005 12:27:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENYad-0003yg-Bg for tls@megatron.ietf.org; Thu, 06 Oct 2005 12:27:27 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13402 for ; Thu, 6 Oct 2005 12:27:24 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 06 Oct 2005 09:26:57 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j96GQtuk026821; Thu, 6 Oct 2005 09:26:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] WG review of draft-salowey-tls-ticket-04.txt Date: Thu, 6 Oct 2005 09:32:11 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906055DFE@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] WG review of draft-salowey-tls-ticket-04.txt Thread-Index: AcXKez4hC3WnCMxMS6Ou7/7GO3FfkQADaUsw From: "Salowey, Joe" To: "Rob Dugal" , "EKR" 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 Rob Dugal wrote: >>> I think it would simplify client implementation if the server >>> provided some indication it intends to proceed with resumption >>> using the client's ticket. What about including an extension in the >>> server hello that would indicate to the client that the server will >>> resume using=20 > the ticket? >> Isn't that what providing the ticket means? >=20 > Actually having a ticket doesn't guarantee the server will later > resume with it. For example, the ticket could be old and the server > might not want to use it. My concern is that without knowing that the > server will resume using the ticket it get's a little difficult to > know what handshake messages the server will respond with. When > the server resumes with the sessionID it is pretty clear > because the server returns the same sessionID in the > ServerHello as the client sent in the ClientHello. But in TLS > ticket there is no clear indication from the ServerHello that > the server will resume. And now there is also the proposal > for allowing the server to send NewSessionTicket on a resumed session. >=20 [Joe] The client can tell if the server is resuming unambiguously using the ticket by the subsequent message sent by the server. A NewSessionTicket Handshake message or a ChangeCipherSpec would indicate a session resume using the ticket. =20 > Which also brings up the question: what does the server do if > it receives an invalid ticket, such as a forged ticket? Does > it just ignore the ticket? Send an alert? > =20 [Joe] It ignores the ticket and falls back to a full handshake.=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 12:55:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZ1p-0003xH-3d; Thu, 06 Oct 2005 12:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZ1n-0003x9-72 for tls@megatron.ietf.org; Thu, 06 Oct 2005 12:55:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14892 for ; Thu, 6 Oct 2005 12:55:28 -0400 (EDT) Received: from smtp-out6.blueyonder.co.uk ([195.188.213.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENZAt-0008Nu-1j for tls@ietf.org; Thu, 06 Oct 2005 13:04:57 -0400 Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 17:56:10 +0100 Message-ID: <434556F9.1010406@blueyonder.co.uk> Date: Thu, 06 Oct 2005 17:55:21 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] IESG Feedback on RFC 3546 References: <20051006142436.CBD0AB831@delta.rtfm.com> In-Reply-To: <20051006142436.CBD0AB831@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 16:56:10.0803 (UTC) FILETIME=[DA673830:01C5CA96] X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: >>5. S 9 Update the IANA sections to indicate that the change >> controller for this MIME type to be the IESG [Hartman] > > This does not seem to have been done. On the contrary, it is already done. Search for "Change controller". -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 13:41:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZjq-0000E1-Ku; Thu, 06 Oct 2005 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZjo-0000Dw-V1 for tls@megatron.ietf.org; Thu, 06 Oct 2005 13:41:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17334 for ; Thu, 6 Oct 2005 13:40:59 -0400 (EDT) Received: from [12.152.251.181] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENZsw-0001uh-8X for tls@ietf.org; Thu, 06 Oct 2005 13:50:27 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id 4DBF2B832; Thu, 6 Oct 2005 10:39:40 -0700 (PDT) To: david.nospam.hopwood@blueyonder.co.uk Subject: Re: [TLS] IESG Feedback on RFC 3546 References: <20051006142436.CBD0AB831@delta.rtfm.com> <434556F9.1010406@blueyonder.co.uk> From: Eric Rescorla Date: Thu, 06 Oct 2005 10:39:40 -0700 In-Reply-To: <434556F9.1010406@blueyonder.co.uk> (David Hopwood's message of "Thu, 06 Oct 2005 17:55:21 +0100") Message-ID: <86oe62ee8z.fsf@delta.rtfm.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 David Hopwood writes: > Eric Rescorla wrote: >>>5. S 9 Update the IANA sections to indicate that the change >>> controller for this MIME type to be the IESG [Hartman] >> >> This does not seem to have been done. > > On the contrary, it is already done. Search for "Change controller". My bad, I got confused by Magnus's presence as the POC. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 06 18:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENeCG-0003Gy-HH; Thu, 06 Oct 2005 18:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENeCC-0003EJ-7A for tls@megatron.ietf.org; Thu, 06 Oct 2005 18:26:38 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22685 for ; Thu, 6 Oct 2005 18:26:32 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ENeCA-000656-GG; Thu, 06 Oct 2005 18:26:34 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 06 Oct 2005 18:26:34 -0400 Cc: Internet Architecture Board , tls mailing list , RFC Editor Subject: [TLS] Protocol Action: 'Transport Layer Security (TLS) Extensions' to Proposed Standard X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The IESG has approved the following document: - 'Transport Layer Security (TLS) Extensions ' as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc3546bis-02.txt Technical Summary This document is an update to RFC 3546, TLS extensions. TLS extensions allow implementations to jointly agree on different TLS behavior that isn't embodied in the cipher suite. Two examples are truncated MACs and communicating the expected server DNS name to allow name-based virtual hosts. This document contains no technical changes to RFC 3546. The only important change is reducing the requirement for registration of an extension from Standards Action to IETF Consensus. Working Group Summary The immediate motivation for this change was to allow the use of group negotiation with ECC, which is going forward as Informational. There was some negative comment about ECC in general and group negotiation but no major dissent for this particular change. However, outside of the ECC boosters, there wasn't much enthusiasm for it either. Protocol Quality An identical protocol (RFC 3546) has already been approved by IESG, but deployment has been very slow, but GnuTLS claims support it. This document was reviewed by Russ Housley for the IESG. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 07 19:34:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO1jY-0006hZ-5U; Fri, 07 Oct 2005 19:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO1jW-0006hU-EW for tls@megatron.ietf.org; Fri, 07 Oct 2005 19:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02945 for ; Fri, 7 Oct 2005 19:34:30 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EO1su-0001Ot-DA for tls@ietf.org; Fri, 07 Oct 2005 19:44:16 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 07 Oct 2005 16:34:25 -0700 X-IronPort-AV: i="3.97,189,1125903600"; d="scan'208"; a="218195862:sNHT25104616" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j97NYKuk017690; Fri, 7 Oct 2005 16:34:21 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] WG review of draft-salowey-tls-ticket-04.txt Date: Fri, 7 Oct 2005 16:39:41 -0700 Message-ID: <7210B31550AC934A8637D6619739CE690605631F@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] WG review of draft-salowey-tls-ticket-04.txt Thread-Index: AcXKex5dBLR8SOUpSuWwRgxXrHgmXQABYLfgAEUfI6A= From: "Salowey, Joe" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Here is some proposed test that I think resolves the issues with session ID raised by Rob and Nelson: "If a server is planning on issuing a SessionTicket to a client that does not present one it SHOULD include an empty Session ID in the ServerHello. If the server includes a non-empty session ID then it is indicating intent to use stateful session resume. If the client receives a SessionTicket from the server then it discards any Session ID that was sent in the ServerHello. When presenting a ticket the client MAY generate and include Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session or falling back to a full handshake. Since the client generates a Session ID the server MUST NOT rely upon the Session ID having a particular value when validating the ticket. If a ticket is presented by the client the server MUST NOT attempt to use the Session ID in the ClientHello for stateful session resume. Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case the client ignores the Session ID sent in the ServerHello and must determine if the server is resuming a session by the subsequent handshake messages." > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Thursday, October 06, 2005 7:23 AM > To: RDugal@certicom.com > Cc: tls@ietf.org > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt >=20 > Rob Dugal wrote: > =09 > > Actually having a ticket doesn't guarantee the server will later=20 > > resume with it. > > > > For example, the ticket could be old and the server might=20 > not want to=20 > > use it. My concern is that without knowing that the server will=20 > > resume using the ticket it get's a little difficult to know what=20 > > handshake messages the server will respond with. When the server=20 > > resumes with the sessionID it is pretty clear because the server=20 > > returns the same sessionID in the ServerHello as the client sent in=20 > > the ClientHello. But in TLS ticket there is no clear=20 > indication from=20 > > the ServerHello that the server will resume. And now there=20 > is also the=20 > > proposal for allowing the server to send NewSessionTicket=20 > on a resumed=20 > > session. >=20 > Hmm.. I agree, it would be nice to have an unambiguous signal=20 > in the ServerHello that tells the client resumption is happening. > This would be the case if we also included the normal=20 > sessionID as I suggested earlier in >=20 > http://www.imc.org/ietf-tls/mail-archive/msg04709.html >=20 > > Which also brings up the question: what does the server do if it=20 > > receives an invalid ticket, such as a forged ticket? Does it just=20 > > ignore the ticket? Send an alert? >=20 > Same thing it does when it receives an invalid session ID: > ignores it and starts a full handshake. >=20 > Best regards, > Pasi >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 11 10:50:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLS8-00037V-6X; Tue, 11 Oct 2005 10:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLS5-00036h-MD for tls@megatron.ietf.org; Tue, 11 Oct 2005 10:50:01 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29243 for ; Tue, 11 Oct 2005 10:49:59 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EPLS5-0005ce-Bu; Tue, 11 Oct 2005 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Oct 2005 10:50:01 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-10.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-10.txt Pages : 25 Date : 2005-10-11 This memo presents a technique for using the Secure Remote Password protocol ([SRP], [SRP-6]) as an authentication method for the Transport Layer Security protocol [TLS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-srp-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-srp-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-11100952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-11100952.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue Oct 11 15:42:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPQ0o-0008KM-WB; Tue, 11 Oct 2005 15:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPPLI-00029G-Pi for tls@megatron.ietf.org; Tue, 11 Oct 2005 14:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22295 for ; Tue, 11 Oct 2005 14:59:14 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPPVO-0004kI-IW for tls@ietf.org; Tue, 11 Oct 2005 15:09:47 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 47DB78A02D for ; Tue, 11 Oct 2005 12:12:18 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Tue, 11 Oct 2005 11:58:54 -0700 From: Eric Rescorla Message-Id: <20051011191218.47DB78A02D@laser.networkresonance.com> X-Spam-Score: 2.0 (++) X-Scan-Signature: 6a223e3db9d3202dafaad5e1eab5cdc2 X-Mailman-Approved-At: Tue, 11 Oct 2005 15:42:02 -0400 Cc: Subject: [TLS] AD comments on draft-ietf-tls-ecc-11 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 Attached are russ Housley's comments on this AD. I've reviewed them and they all look pretty reasonable. Authors, please fix this stuff and resubmit. -Ekr [ Comments from AD Review by Russ Housley on 2005-10-11. Look for '[' in column one for inline comments. ] TLS Working Group V. Gupta Internet-Draft Sun Labs Expires: March 20, 2006 S. Blake-Wilson BCI B. Moeller University of Calgary C. Hawk Corriente Networks N. Bolyard September 16, 2005 ECC Cipher Suites for TLS Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) Gupta, et al. Expires March 20, 2006 [Page 1] Internet-Draft ECC Cipher Suites for TLS September 2005 protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. [ This does not belong in the Abstract. I suggest that you move it to the end of the Introduction. ] Please send comments on this document to the TLS mailing list. [ This should be deleted, or a note should be added asking the RFC Editor to delete it prior to publication. ] Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 5. Data Structures and Computations . . . . . . . . . . . . . . 12 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 15 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.1 Normative References . . . . . . . . . . . . . . . . . . 33 10.2 Informative References . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . 36 Gupta, et al. Expires March 20, 2006 [Page 2] Internet-Draft ECC Cipher Suites for TLS September 2005 1. Introduction Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem for mobile/wireless environments. Compared [ What does "/" mean? Please say "and" or "or." ] to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes. This is illustrated in the following table, based on [14], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them. Symmetric | ECC | DH/DSA/RSA -------------+---------+------------ 80 | 163 | 1024 112 | 233 | 2048 128 | 283 | 3072 192 | 409 | 7680 256 | 571 | 15360 Table 1: Comparable key sizes (in bits) [ You should align the right side (not the left side) of the numbers in the DH/DSA/RSA column. ] Smaller key sizes result in power, bandwidth and computational savings that make ECC especially attractive for constrained environments. [ Memory savings too... ] This document describes additions to TLS to support ECC. In particular, it defines o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme with long-term or ephemeral keys to establish the TLS premaster secret, and o the use of fixed-ECDH certificates and ECDSA for authentication of TLS peers. The remainder of this document is organized as follows. Section 2 provides an overview of ECC-based key exchange algorithms for TLS. Section 3 describes the use of ECC certificates for client authentication. TLS extensions that allow a client to negotiate the use of specific curves and point formats are presented in Section 4. Section 5 specifies various data structures needed for an ECC-based handshake, their encoding in TLS messages and the processing of those messages. Section 6 defines new ECC-based cipher suites and identifies a small subset of these as recommended for all implementations of this specification. Section 7 discusses security considerations. Section 8 describes IANA considerations for the name spaces created by this document. Section 9 gives acknowledgments. This is followed by the lists of normative and informative references Gupta, et al. Expires March 20, 2006 [Page 3] Internet-Draft ECC Cipher Suites for TLS September 2005 cited in this document, the authors' contact information, and statements on intellectual property rights and copyrights. Implementation of this specification requires familiarity with TLS [2], TLS extensions [3] and ECC [4][5][6][8]. Gupta, et al. Expires March 20, 2006 [Page 4] Internet-Draft ECC Cipher Suites for TLS September 2005 2. Key Exchange Algorithms This document introduces five new ECC-based key exchange algorithms for TLS. All of them use ECDH to compute the TLS premaster secret and differ only in the lifetime of ECDH keys (long-term or ephemeral) and the mechanism (if any) used to authenticate them. The derivation of the TLS master secret from the premaster secret and the subsequent generation of bulk encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC. The table below summarizes the new key exchange algorithms which mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]), respectively. Key Exchange Algorithm Description --------- ----------- ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. ECDH_RSA Fixed ECDH with RSA-signed certificates. ECDHE_RSA Ephemeral ECDH with RSA signatures. ECDH_anon Anonymous ECDH, no signatures. Table 2: ECC key exchange algorithms The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see Section 4). However, the computational cost incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange which does not provide forward secrecy. The ECDH_RSA mechanism requires a server to acquire an ECC certificate but the certificate issuer can still use an existing RSA key for signing. This eliminates the need to update the trusted key store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for [ rfc2246bis does not use the term "trusted key store." Please align terms. In section 2.5, the term "trust anchor" is used. I like this term, it is used in RFC 3280, but it is not used in rfc2246bis. ] the server as well as the certification authority and is best suited for constrained devices unable to support RSA. The anonymous key exchange algorithm does not provide authentication Gupta, et al. Expires March 20, 2006 [Page 5] Internet-Draft ECC Cipher Suites for TLS September 2005 of the server or the client. Like other anonymous TLS key exchanges, it is subject to man-in-the-middle attacks. Implementations of this algorithm SHOULD provide authentication by other means. Note that there is no structural difference between ECDH and ECDSA keys. A certificate issuer may use X509.v3 keyUsage and [ s/X509.v3/X.509 v3/ ] [ A normative reference is needed for X.509 v3. I suggest RFC 3280. ] extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations. This document refers to an ECC key as ECDH- capable if its use in ECDH is permitted. ECDSA-capable is defined similarly. Client Server ------ ------ ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest*+ <-------- ServerHelloDone Certificate*+ ClientKeyExchange CertificateVerify*+ [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data * message is not sent under some conditions + message is not sent unless client authentication is desired Figure 1: Message flow in a full TLS handshake Figure 1 shows all messages involved in the TLS key establishment protocol (aka full handshake). The addition of ECC has direct impact only on the ClientHello, the ServerHello, the server's Certificate message, the ServerKeyExchange, the ClientKeyExchange, the CertificateRequest, the client's Certificate message, and the CertificateVerify. Next, we describe each ECC key exchange algorithm in greater detail in terms of the content and processing of these messages. For ease of exposition, we defer discussion of client authentication and associated messages (identified with a + in Gupta, et al. Expires March 20, 2006 [Page 6] Internet-Draft ECC Cipher Suites for TLS September 2005 Figure 1) until Section 3 and of the optional ECC-specific extensions (which impact the Hello messages) until Section 4. 2.1 ECDH_ECDSA In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA. A ServerKeyExchange MUST NOT be sent (the server's certificate contains all the necessary keying information required by the client to arrive at the premaster secret). The client generates an ECDH key pair on the same curve as the server's long-term public key and send its public key in the ClientKeyExchange message (except when using client authentication algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the modifications from Section 3.2 or Section 3.3 apply). Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in Section 5.10 [ Missing period. ] 2.2 ECDHE_ECDSA In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- capable public key and be signed with ECDSA. The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST be signed with ECDSA using the private key corresponding to the public key in the server's Certificate. The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and send its public key in the ClientKeyExchange message. Both client and server perform an ECDH operation (Section 5.10) and use the resultant shared secret as the premaster secret. 2.3 ECDH_RSA This key exchange algorithm is the same as ECDH_ECDSA except the server's certificate MUST be signed with RSA rather than ECDSA. 2.4 ECDHE_RSA This key exchange algorithm is the same as ECDHE_ECDSA except the server's certificate MUST contain an RSA public key authorized for Gupta, et al. Expires March 20, 2006 [Page 7] Internet-Draft ECC Cipher Suites for TLS September 2005 signing and the signature in the ServerKeyExchange message must be computed with the corresponding RSA private key. The server certificate MUST be signed with RSA. 2.5 ECDH_anon In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent. The server MUST send an ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST NOT be signed. The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and send its public key in the ClientKeyExchange message. Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in Section 5.10. Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it [ s/certificate chain/certification path/ ] is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be [ s/chain/certification path/ ] able to validate the server's certificate by relying on a trust anchor that appears as one of the intermediate certificates in the chain.) [ s/chain/path/ ] Gupta, et al. Expires March 20, 2006 [Page 8] Internet-Draft ECC Cipher Suites for TLS September 2005 3. Client Authentication This document defines three new client authentication mechanisms named after the type of client certificate involved: ECDSA_sign, ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is usable with any of the non-anonymous ECC key exchange algorithms described in Section 2 as well as other non-anonymous (non-ECC) key exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the use of a long-term ECDH client key would jeopardize the forward secrecy property of these algorithms. The server can request ECC-based client authentication by including one or more of these certificate types in its CertificateRequest message. The server must not include any certificate types that are prohibited for the negotiated key exchange algorithm. The client must check if it possesses a certificate appropriate for any of the methods suggested by the server and is willing to use it for authentication. If these conditions are not met, the client should send a client Certificate message containing no certificates. In this case, the ClientKeyExchange should be sent as described in Section 2 and the CertificateVerify should not be sent. If the server requires client authentication, it may respond with a fatal handshake failure alert. If the client has an appropriate certificate and is willing to use it for authentication, it must send that certificate in the client's Certificate message (as per Section 5.6) and prove possession of the private key corresponding to the certified key. The process of determining an appropriate certificate and proving possession is different for each authentication mechanism and described below. NOTE: It is permissible for a server to request (and the client to send) a client certificate of a different type than the server certificate. 3.1 ECDSA_sign To use this authentication mechanism, the client MUST possess a certificate containing an ECDSA-capable public key and signed with ECDSA. The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify message as described in Section 5.8. Gupta, et al. Expires March 20, 2006 [Page 9] Internet-Draft ECC Cipher Suites for TLS September 2005 3.2 ECDSA_fixed_ECDH To use this authentication mechanism, the client MUST possess a certificate containing an ECDH-capable public key and that certificate MUST be signed with ECDSA. Furthermore, the client's ECDH key MUST be on the same elliptic curve as the server's long-term (certified) ECDH key. This might limit use of this mechanism to closed environments. In situations where the client has an ECC key on a different curve, it would have to authenticate either using ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for both servers and clients is computationally more efficient than mechanisms providing forward secrecy. When using this authentication mechanism, the client MUST send an empty ClientKeyExchange as described in Section 5.7 and MUST NOT send the CertificateVerify message. The ClientKeyExchange is empty since the client's ECDH public key required by the server to compute the premaster secret is available inside the client's certificate. The client's ability to arrive at the same premaster secret as the server (demonstrated by a successful exchange of Finished messages) proves possession of the private key corresponding to the certified public key and the CertificateVerify message is unnecessary. 3.3 RSA_fixed_ECDH This authentication mechanism is identical to ECDSA_fixed_ECDH except the client's certificate MUST be signed with RSA. Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH client authentication mechanisms require the clients's certificate to be signed with a particular signature scheme, this specification does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it [ s/certificate chain/certification path/ ] is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a server to completely validate a given chain, the server may be [ s/chain/certification path/ ] able to validate the clients certificate by relying on a trust anchor that appears as one of the intermediate certificates in the chain.) [ s/chain/path/ ] Gupta, et al. Expires March 20, 2006 [Page 10] Internet-Draft ECC Cipher Suites for TLS September 2005 4. TLS Extensions for ECC Two new TLS extensions are defined in this specification: (i) the Supported Elliptic Curves Extension, and (ii) the Supported Point Formats Extension. These allow negotiating the use of specific curves and point formats (e.g. compressed vs. uncompressed), respectively, during a handshake starting a new session. These extensions are especially relevant for constrained clients that may only support a limited number of curves or point formats. They follow the general approach outlined in [3]; message details are specified in Section 5. The client enumerates the curves it supports and the point formats it can parse by including the appropriate extensions in its ClientHello message. The server similarly enumerates the point formats it can parse by including an extension in its ServerHello message. A TLS client that proposes ECC cipher suites in its ClientHello message SHOULD include these extensions. Servers implementing ECC cipher suites MUST support these extensions, and when a client uses these extensions, servers MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting the choice of curves and compression techniques specified by the client. This eliminates the possibility that a negotiated ECC handshake will be subsequently aborted due to a client's inability to deal with the server's EC key. These extensions MUST NOT be included if the client does not propose [ I think this will be more clear as follows: "The client MUST NOT include these extensions in ... unless ..." ] any ECC cipher suites. A client that proposes ECC cipher suites may choose not to include these extension. In this case, the server is free to choose any one of the elliptic curves or point formats listed in Section 5. That section also describes the structure and processing of these extensions in greater detail. In the case of session resumption, the server simply ignores the Supported Elliptic Curves Extension and the Supported Point Formats Extension as appearing in the current ClientHello message. These extensions only play a role during handshakes negotiating a new session. Gupta, et al. Expires March 20, 2006 [Page 11] Internet-Draft ECC Cipher Suites for TLS September 2005 5. Data Structures and Computations This section specifies the data structures and computations used by ECC-based key mechanisms specified in Section 2, Section 3 and Section 4. The presentation language used here is the same as that used in TLS [2]. Since this specification extends TLS, these descriptions should be merged with those in the TLS specification and any others that extend TLS. This means that enum types may not specify all possible values and structures with multiple formats chosen with a select() clause may not indicate all possible cases. 5.1 Client Hello Extensions This section specifies two TLS extensions that can be included with the ClientHello message as described in [3], the Supported Elliptic Curves Extension and the Supported Point Formats Extension. When these extensions are sent: The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites. Meaning of these extensions: These extensions allow a client to enumerate the elliptic curves it supports and/or the point formats it can parse. Structure of these extensions: The general structure of TLS extensions is described in [3] and this specification adds two new types to ExtensionType. enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; [[ EDITOR: The values used for elliptic_curves and ec_point_formats have been left as ??. These values will be assigned when this draft progresses to RFC. (The examples below will have to be changed accordingly.) ]] [ The use of ?? for both elliptic_curves and ec_point_formats is ambiguous. It would be better to use ?1? and ?2?, or any other unique place holder. This will ensure that IANA and the RFC Editor do "the right thing" in the examples. ] [ I think it would help the reader to start section 5.1.1 here. ] elliptic_curves (Supported Elliptic Curves Extension): Indicates the set of elliptic curves supported by the client. For this extension, the opaque extension_data field contains EllipticCurveList. Gupta, et al. Expires March 20, 2006 [Page 12] Internet-Draft ECC Cipher Suites for TLS September 2005 ec_point_formats (Supported Point Formats Extension): Indicates the set of point formats that the client can parse. For this extension, the opaque extension_data field contains ECPointFormatList. enum { sect163k1 (1), sect163r1 (2), sect163r2 (3), sect193r1 (4), sect193r2 (5), sect233k1 (6), sect233r1 (7), sect239k1 (8), sect283k1 (9), sect283r1 (10), sect409k1 (11), sect409r1 (12), sect571k1 (13), sect571r1 (14), secp160k1 (15), secp160r1 (16), secp160r2 (17), secp192k1 (18), secp192r1 (19), secp224k1 (20), secp224r1 (21), secp256k1 (22), secp256r1 (23), secp384r1 (24), secp521r1 (25), reserved (0xFE00..0xFEFF), arbitrary_explicit_prime_curves(0xFF01), arbitrary_explicit_char2_curves(0xFF02), (0xFFFF) } NamedCurve; sect163k1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves. The named curves defined here are those specified in SEC 2 [10]. Note that many of these curves are also recommended in ANSI X9.62 [6] and FIPS 186-2 [8]. Values 0xFE00 through 0xFEFF are reserved for private use. Values 0xFF01 and 0xFF02 indicate that the client supports arbitrary prime and characteristic-2 curves, respectively (the curve parameters must be encoded explicitly in ECParameters). The NamedCurve name space is maintained by IANA. See Section 8 for information on how new value assignments are added. struct { NamedCurve elliptic_curve_list<1..2^8-1> } EllipticCurveList; Items in elliptic_curve_list are ordered according to the client's preferences (favorite choice first). As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting of the following octets: Gupta, et al. Expires March 20, 2006 [Page 13] Internet-Draft ECC Cipher Suites for TLS September 2005 00 ?? 00 06 00 04 00 13 00 15 A client that supports arbitrary explicit characteristic-2 curves (value 0xFF02) would include an extension consisting of the following octets: 00 ?? 00 04 00 02 FF 02 [ I think it would help the reader to start section 5.1.2 here. ] enum { uncompressed (0), ansiX962_compressed_prime (1), ansiX962_compressed_char2 (2), reserved (248..255) } ECPointFormat; struct { ECPointFormat ec_point_format_list<1..2^8-1> } ECPointFormatList; Three point formats are included in the definition of ECPointFormat above. The uncompressed point format is the default format in that implementations of this document MUST support it for all of their supported curves. Compressed point formats reduce bandwidth by including only the x-coordinate and a single bit of the y-coordinate of the point. Implementations of this document MAY support the ansiX962_compressed_prime and ansiX962_compressed_char2 formats, where the former applies only to prime curves and the latter applies only to characteristic-2 curves. (These formats are specified in [6].) Values 248 through 255 are reserved for private use. The ECPointFormat name space is maintained by IANA. See Section 8 for information on how new value assignments are added. Items in ec_point_format_list are ordered according to the client's preferences (favorite choice first). A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets: 00 ?? 00 02 01 00 A client that in the case of prime fields prefers the compressed format (ansiX962_compressed_prime, value 1) over the uncompressed format (value 0), but in the case of characteristic-2 fields prefers the uncompressed format (value 0) over the compressed format (ansiX962_compressed_char2, value 2), may indicate these preferences by including an extension consisting of the following octets: 00 ?? 00 04 03 01 00 02 Gupta, et al. Expires March 20, 2006 [Page 14] Internet-Draft ECC Cipher Suites for TLS September 2005 [ I think the following material belongs in section 5.1 prior to the recommended start of section 5.1.1. ] Actions of the sender: A client that proposes ECC cipher suites in its ClientHello message appends these extensions (along with any others), enumerating the curves it supports and the point formats it can parse. Clients SHOULD send both the Supported Elliptic Curves Extension and the Supported Point Formats Extension. If the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats. Actions of the receiver: A server that receives a ClientHello containing one or both of these extensions MUST use the client's enumerated capabilities to guide its selection of an appropriate cipher suite. One of the proposed ECC cipher suites must be negotiated only if the server can successfully complete the handshake while using the curves and point formats supported by the client (cf. Section 5.3 and Section 5.4). NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message. The server must consider the "elliptic_curves" extension in selecting both of these curves. If a server does not understand the "elliptic_curves" extension or is unable to complete the ECC handshake while restricting itself to the enumerated curves, it MUST NOT negotiate the use of an ECC cipher suite. Depending on what other cipher suites are proposed by the client and supported by the server, this may result in a fatal handshake failure alert due to the lack of common cipher suites. 5.2 Server Hello Extension This section specifies a TLS extension that can be included with the ServerHello message as described in [3], the Supported Point Formats Extension. When this extension is sent: The Supported Point Formats Extension is included in a ServerHello message in response to a ClientHello message containing the Supported Point Formats Extension when negotiating an ECC cipher suite. Meaning of this extensions: This extension allows a server to enumerate the point formats it can parse (for the curve that will appear in its ServerKeyExchange Gupta, et al. Expires March 20, 2006 [Page 15] Internet-Draft ECC Cipher Suites for TLS September 2005 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key exchange algorithm, or for the curve that is used in the server's public key that will appear in its Certificate message when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm). Structure of this extension: The server's Supported Point Formats Extension has the same structure as the client's Supported Point Formats Extension. Items in elliptic_curve_list here are ordered according to the server's preference (favorite choice first). Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable to output points in compressed format). Actions of the sender: A server that selects an ECC cipher suite in response to a ClientHello message including a Supported Point Formats Extension appends this extension (along with others) to its ServerHello message, enumerating the point formats it can parse. The Supported Point Formats Extension, when used, MUST contain the value 0 (uncompressed) as one of the items in the list of point formats. Actions of the receiver: A client that receives a ServerHello message containing a Supported Point Formats Extension MUST respect the server's choice of point formats during the handshake (cf. Section 5.6 and Section 5.7). If no Supported Point Formats Extension is received with the ServerHello, this is equivalent to an extension allowing only the uncompressed point format. 5.3 Server Certificate When this message is sent: This message is sent in all non-anonymous ECC-based key exchange algorithms. Meaning of this message: This message is used to authentically convey the server's static public key to the client. The following table shows the server certificate type appropriate for each key exchange algorithm. ECC public keys must be encoded in certificates as described in [ s/must/MUST/ ] Section 5.9. Gupta, et al. Expires March 20, 2006 [Page 16] Internet-Draft ECC Cipher Suites for TLS September 2005 NOTE: The server's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 3 apply only to [ s/chain of certificates/certification path/ ] the server's certificate (first in the chain). [ s/chain/certification path/ ] Key Exchange Algorithm Server Certificate Type ---------------------- ----------------------- ECDH_ECDSA Certificate must contain an ECDH-capable public key. It must be signed with ECDSA. ECDHE_ECDSA Certificate must contain an ECDSA-capable public key. It must be signed with ECDSA. ECDH_RSA Certificate must contain an ECDH-capable public key. It must be signed with RSA. ECDHE_RSA Certificate must contain an RSA public key authorized for use in digital signatures. It must be signed with RSA. Table 3: Server certificate types [ Throughout Table 3: s/must/MUST/ ] Structure of this message: Identical to the TLS Certificate format. Actions of the sender: The server constructs an appropriate certificate chain and conveys it [ s/certificate chain/certification path/ ] to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves; in particular, the public key MUST employ a named curve (not the same curve as an explicit curve) unless the client has indicated support for explicit curves of the appropriate type. If the client has used a Supported Point Formats Extension, both the server's public key point and (in the case of an explicit curve) the curve's base point MUST respect the client's choice of point formats. (A server that cannot satisfy these requirements must not choose an ECC cipher suite [ s/must not/MUST NOT/ ] in its ServerHello message.) Actions of the receiver: Gupta, et al. Expires March 20, 2006 [Page 17] Internet-Draft ECC Cipher Suites for TLS September 2005 The client validates the certificate chain, extracts the server's [ s/certificate chain/certification path/ ] public key, and checks that the key type is appropriate for the negotiated key exchange algorithm. [ Shouldn't there also be consistency checks related to the elliptic_curves and ec_point_formats extensions? ] 5.4 Server Key Exchange When this message is sent: This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and ECDH_anon key exchange algorithms. Meaning of this message: This message is used to convey the server's ephemeral ECDH public key (and the corresponding elliptic curve domain parameters) to the client. Structure of this message: enum { explicit_prime (1), explicit_char2 (2), named_curve (3), reserved(248..255) } ECCurveType; explicit_prime: Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a prime field. explicit_char2: Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a characteristic-2 field. named_curve: Indicates that a named curve is used. This option SHOULD be used when applicable. Values 248 through 255 are reserved for private use. The ECCurveType name space is maintained by IANA. See Section 8 for information on how new value assignments are added. struct { opaque a <1..2^8-1>; opaque b <1..2^8-1>; } ECCurve; a, b: These parameters specify the coefficients of the elliptic curve. Each value contains the byte string representation of a field element following the conversion routine in Section 4.3.3 of ANSI X9.62 [6]. Gupta, et al. Expires March 20, 2006 [Page 18] Internet-Draft ECC Cipher Suites for TLS September 2005 struct { opaque point <1..2^8-1>; } ECPoint; point: This is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI X9.62 [6]. This byte string may represent an elliptic curve point in uncompressed, or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used. enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; ec_basis_trinomial: Indicates representation of a characteristic-2 field using a trinomial basis. ec_basis_pentanomial: Indicates representation of a characteristic-2 field using a pentanomial basis. struct { ECCurveType curve_type; select (curve_type) { case explicit_prime: opaque prime_p <1..2^8-1>; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case explicit_char2: uint16 m; ECBasisType basis; select (basis) { case ec_trinomial: opaque k <1..2^8-1>; case ec_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case named_curve: NamedCurve namedcurve; }; Gupta, et al. Expires March 20, 2006 [Page 19] Internet-Draft ECC Cipher Suites for TLS September 2005 } ECParameters; curve_type: This identifies the type of the elliptic curve domain parameters. prime_p: This is the odd prime defining the field Fp. curve: Specifies the coefficients a and b of the elliptic curve E. base: Specifies the base point G on the elliptic curve. order: Specifies the order n of the base point. cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number of points on the elliptic curve E defined over the field Fq (either Fp or F2^m). m: This is the degree of the characteristic-2 field F2^m. k: The exponent k for the trinomial basis representation x^m + x^k +1. k1, k2, k3: The exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). namedcurve: Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve. Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02). struct { ECParameters curve_params; ECPoint public; } ServerECDHParams; curve_params: Specifies the elliptic curve domain parameters associated with the ECDH public key. public: The ephemeral ECDH public key. The ServerKeyExchange message is extended as follows. enum { ec_diffie_hellman } KeyExchangeAlgorithm; Gupta, et al. Expires March 20, 2006 [Page 20] Internet-Draft ECC Cipher Suites for TLS September 2005 ec_diffie_hellman: Indicates the ServerKeyExchange message contains an ECDH public key. select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ServerECDHParams params; Signature signed_params; } ServerKeyExchange; params: Specifies the ECDH public key and associated domain parameters. signed_params: A hash of the params, with the signature appropriate to that hash applied. The private key corresponding to the certified public key in the server's Certificate message is used for signing. enum { ecdsa } SignatureAlgorithm; select (SignatureAlgorithm) { case ecdsa: digitally-signed struct { opaque sha_hash[sha_size]; }; } Signature; NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange algorithm and "anonymous" for ECDH_anon. These cases are defined in TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA signatures are generated and verified as described in Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a pair of integers r and s. These integers are both converted into byte strings of the same length as the curve order n using the conversion routine specified in Section 4.3.1 of [6]. The two byte strings are concatenated, and the result is placed in the signature field. Actions of the sender: The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to the client in the ServerKeyExchange message using the format defined above. Actions of the recipient: Gupta, et al. Expires March 20, 2006 [Page 21] Internet-Draft ECC Cipher Suites for TLS September 2005 The client verifies the signature (when present) and retrieves the server's elliptic curve domain parameters and ephemeral ECDH public key from the ServerKeyExchange message. [ Shouldn't there also be consistency checks related to the elliptic_curves and ec_point_formats extensions? ] 5.5 Certificate Request When this message is sent: This message is sent when requesting client authentication. Meaning of this message: The server uses this message to suggest acceptable client authentication methods. Structure of this message: The TLS CertificateRequest message is extended as follows. enum { ecdsa_sign(??), rsa_fixed_ecdh(??), ecdsa_fixed_ecdh(??), (255) } ClientCertificateType; [ The use of ?? for all three values is ambiguous. ] ecdsa_sign, etc Indicates that the server would like to use the corresponding client authentication method specified in Section 3. [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and ecdsa_fixed_ecdh have been left as ??. These values will be assigned when this draft progresses to RFC. Earlier versions of this draft used the values 5, 6, and 7 - however these values have been removed since they are used differently by SSL 3.0 [15] and their use by TLS is being deprecated. ]] Actions of the sender: The server decides which client authentication methods it would like to use, and conveys this information to the client using the format defined above. Actions of the receiver: The client determines whether it has a suitable certificate for use with any of the requested methods, and decides whether or not to proceed with client authentication. [ Shouldn't there also be consistency checks related to the elliptic_curves and ec_point_formats extensions? ] Gupta, et al. Expires March 20, 2006 [Page 22] Internet-Draft ECC Cipher Suites for TLS September 2005 5.6 Client Certificate When this message is sent: This message is sent in response to a CertificateRequest when a client has a suitable certificate and has decided to proceed with client authentication. (Note that if the server has used a Supported Point Formats Extension, a certificate can only be considered suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and ECDSA_fixed_ECDH authentication methods if the public key point specified in it respects the server's choice of point formats. If no Supported Point Formats Extension has been used, a certificate can only be considered suitable for use with these authentication methods if the point is represented in uncompressed point format.) Meaning of this message: This message is used to authentically convey the client's static public key to the server. The following table summarizes what client certificate types are appropriate for the ECC-based client authentication mechanisms described in Section 3. ECC public keys must be encoded in certificates as described in Section 5.9. NOTE: The client's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 4 apply only to [ s/chain of certificates/certification path/ ] the client's certificate (first in the chain). [ s/chain/certification path/ ] Client Authentication Method Client Certificate Type --------------------- ----------------------- ECDSA_sign Certificate MUST contain an ECDSA-capable public key and be signed with ECDSA. ECDSA_fixed_ECDH Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server's long-term ECDH key. This certificate MUST be signed with ECDSA. RSA_fixed_ECDH Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server's long-term ECDH key. This certificate MUST be signed with RSA. Gupta, et al. Expires March 20, 2006 [Page 23] Internet-Draft ECC Cipher Suites for TLS September 2005 Table 4: Client certificate types Structure of this message: Identical to the TLS client Certificate format. Actions of the sender: The client constructs an appropriate certificate chain, and conveys [ s/certificate chain/certification path/ ] it to the server in the Certificate message. Actions of the receiver: The TLS server validates the certificate chain, extracts the client's [ s/certificate chain/certification path/ ] public key, and checks that the key type is appropriate for the client authentication method. 5.7 Client Key Exchange When this message is sent: This message is sent in all key exchange algorithms. If client authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this message is empty. Otherwise, it contains the client's ephemeral ECDH public key. Meaning of the message: This message is used to convey ephemeral data relating to the key exchange belonging to the client (such as its ephemeral ECDH public key). Structure of this message: The TLS ClientKeyExchange message is extended as follows. enum { implicit, explicit } PublicValueEncoding; implicit, explicit: For ECC cipher suites, this indicates whether the client's ECDH public key is in the client's certificate ("implicit") or is provided, as an ephemeral ECDH public key, in the ClientKeyExchange message ("explicit"). (This is "explicit" in ECC cipher suites except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.) Gupta, et al. Expires March 20, 2006 [Page 24] Internet-Draft ECC Cipher Suites for TLS September 2005 struct { select (PublicValueEncoding) { case implicit: struct { }; case explicit: ECPoint ecdh_Yc; } ecdh_public; } ClientECDiffieHellmanPublic; ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in uncompressed or compressed format. Here the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. struct { select (KeyExchangeAlgorithm) { case ec_diffie_hellman: ClientECDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange; Actions of the sender: The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to the client in the ClientKeyExchange message using the format defined above. Actions of the recipient: The server retrieves the client's ephemeral ECDH public key from the ClientKeyExchange message and checks that it is on the same elliptic curve as the server's ECDH key. 5.8 Certificate Verify When this message is sent: This message is sent when the client sends a client certificate containing a public key usable for digital signatures, e.g. when the client is authenticated using the ECDSA_sign mechanism. Meaning of the message: This message contains a signature that proves possession of the private key corresponding to the public key in the client's Certificate message. Gupta, et al. Expires March 20, 2006 [Page 25] Internet-Draft ECC Cipher Suites for TLS September 2005 Structure of this message: The TLS CertificateVerify message is extended as follows. enum { ecdsa } SignatureAlgorithm; select (SignatureAlgorithm) { case ecdsa: digitally-signed struct { opaque sha_hash[sha_size]; }; } Signature; For the ecdsa case, the signature field in the CertificateVerify message contains an ECDSA signature computed over handshake messages exchanged so far. ECDSA signatures are computed as described in Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a pair of integers r and s. These integers are both converted into byte strings of the same length as the curve order n using the conversion routine specified in Section 4.3.1 of [6]. The two byte strings are concatenated, and the result is placed in the signature field. Actions of the sender: The client computes its signature over all handshake messages sent or received starting at client hello up to but not including this message. It uses the private key corresponding to its certified public key to compute the signature which is conveyed in the format defined above. Actions of the receiver: The server extracts the client's signature from the CertificateVerify message, and verifies the signature using the public key it received in the client's Certificate message. 5.9 Elliptic Curve Certificates X509 certificates containing ECC public keys or signed using ECDSA [ s/X509/X.509/ ] MUST comply with [11] or another RFC that replaces or extends it. Clients SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. 5.10 ECDH, ECDSA and RSA Computations All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to [5] Gupta, et al. Expires March 20, 2006 [Page 26] Internet-Draft ECC Cipher Suites for TLS September 2005 using the ECKAS-DH1 scheme with the identity map as key derivation function, so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string. Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. Note that a new extension may be introduced in the future to allow the use of a different KDF during computation of the premaster secret. In this event, the new KDF would be used in place of the process detailed above. This may be desirable, for example, to support compatibility with the planned NIST key agreement standard. [ I do not understand why we would want to go forward with the "identity" KDF when we know that NIST SP 800-56 will require a real KDF. Since this document already has so many dependencies on X9.62 and X9.63, it seems quite reasonable to use the X9.63 KDF. ] All ECDSA computations MUST be performed according to ANSI X9.62 [6] or its successors. Data to be signed/verified is hashed and the result run directly through the ECDSA algorithm with no additional hashing. The default hash function is SHA-1 [7] and sha_size (see Section 5.4 and Section 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [7], may be used instead if the certificate containing the EC public key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.) All RSA signatures must be generated and verified according to PKCS#1 [9] block type 1. [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two specifications are not compatible in some significant ways. By this, I mean that a subroutine cannot be written that works with both this document and with RFC 3278. To me, this would be highly desirable. One glaring difference is the support for UserKeyingMaterial (or UKM) that is provided by the originator (the client in this context). The UKM and the ECDH shared secret are both inputs to the KDF. ] Gupta, et al. Expires March 20, 2006 [Page 27] Internet-Draft ECC Cipher Suites for TLS September 2005 6. Cipher Suites The table below defines new ECC cipher suites that use the key exchange algorithms specified in Section 2. CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } Table 5: TLS ECC cipher suites [[ EDITOR: The actual cipher suite numbers will be assigned when this draft progresses to RFC. ]] The key exchange method, cipher, and hash algorithm for each of these cipher suites are easily determined by examining the name. Ciphers other than AES ciphers, and hash algorithms are defined in [2]. AES ciphers are defined in [16]. Server implementations SHOULD support all of the following cipher Gupta, et al. Expires March 20, 2006 [Page 28] Internet-Draft ECC Cipher Suites for TLS September 2005 suites, and client implementations SHOULD support at least one of them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. Gupta, et al. Expires March 20, 2006 [Page 29] Internet-Draft ECC Cipher Suites for TLS September 2005 7. Security Considerations This document is based on [2], [5], [6] and [16]. The appropriate [ What does "appropriate" mean here? ] security considerations of those documents apply. One important issue that implementors and users must consider is elliptic curve selection. Guidance on selecting an appropriate elliptic curve size is given in Table 1. Beyond elliptic curve size, the main issue is elliptic curve structure. As a general principle, it is more conservative to use elliptic curves with as little algebraic structure as possible - thus random curves are more conservative than special curves such as Koblitz curves, and curves over F_p with p random are more conservative than curves over F_p with p of a special form (and curves over F_p with p random might be considered more conservative than curves over F_2^m as there is no choice between multiple fields of similar size for characteristic 2). Note, however, that algebraic structure can also lead to implementation efficiencies and implementors and users may, therefore, need to balance conservatism against a need for efficiency. Concrete attacks are known against only very few special classes of curves, such as supersingular curves, and these classes are excluded from the ECC standards that this document references [5], [6]. Another issue is the potential for catastrophic failures when a single elliptic curve is widely used. In this case, an attack on the elliptic curve might result in the compromise of a large number of keys. Again, this concern may need to be balanced against efficiency and interoperability improvements associated with widely-used curves. Substantial additional information on elliptic curve choice can be found in [4], [5], [6], [8]. Implementors and users must also consider whether they need forward secrecy. Forward secrecy refers to the property that session keys are not compromised if the static, certified keys belonging to the server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key exchange algorithms provide forward secrecy protection in the event of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. Similarly if the client is providing a static, certified key, ECDSA_sign client authentication provides forward secrecy protection in the event of client key compromise, while ECDSA_fixed_ECDH and RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, with ECDSA_sign used for client authentication if necessary. Here again the security benefits of forward secrecy may need to be balanced against the improved efficiency offered by other options. Gupta, et al. Expires March 20, 2006 [Page 30] Internet-Draft ECC Cipher Suites for TLS September 2005 8. IANA Considerations This document describes three new name spaces for use with the TLS protocol: o NamedCurve (Section 5.1) o ECPointFormat (Section 5.1) o ECCurveType (Section 5.4) For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use. Any additional assignments require IETF Consensus action [12]. [ There are a whole bunch of values in section 6 that need to be assigned. ] Gupta, et al. Expires March 20, 2006 [Page 31] Internet-Draft ECC Cipher Suites for TLS September 2005 9. Acknowledgments The authors wish to thank Bill Anderson and Tim Dierks. Gupta, et al. Expires March 20, 2006 [Page 32] Internet-Draft ECC Cipher Suites for TLS September 2005 10. References 10.1 Normative References [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005. [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, . [5] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000. [6] ANSI, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998. [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5", PKCS 1, November 1993. [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 2000, . [11] Polk, T., Housley, R., and L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. 10.2 Informative References [13] Harper, G., Menezes, A., and S. Vanstone, "Public-Key Cryptosystems with Very Small Key Lengths", Advances in Cryptology -- EUROCRYPT '92, LNCS 658, 1993. Gupta, et al. Expires March 20, 2006 [Page 33] Internet-Draft ECC Cipher Suites for TLS September 2005 [14] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", Journal of Cryptology 14 (2001) 255-293, . [15] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", November 1996, . [16] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. Authors' Addresses Vipul Gupta Sun Microsystems Laboratories 16 Network Circle MS UMPK16-160 Menlo Park, CA 94025 US Phone: +1 650 786 7551 Email: vipul.gupta@sun.com Simon Blake-Wilson Basic Commerce & Industries, Inc. 96 Spandia Ave Unit 606 Toronto, ON M6G 2T6 CA Phone: +1 416 214 5961 Email: sblakewilson@bcisse.com Bodo Moeller University of Calgary Dept of Math & Stats 2500 University Dr NW Calgary, AB T2N 1N4 CA Phone: +1 403 220 5735 Email: bodo@openssl.org Gupta, et al. Expires March 20, 2006 [Page 34] Internet-Draft ECC Cipher Suites for TLS September 2005 Chris Hawk Corriente Networks Email: chris@corriente.net Nelson Bolyard Email: nelson@bolyard.com Gupta, et al. Expires March 20, 2006 [Page 35] Internet-Draft ECC Cipher Suites for TLS September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gupta, et al. Expires March 20, 2006 [Page 36] _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 11 22:35:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPWSJ-0003Jx-Ue; Tue, 11 Oct 2005 22:34:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPWSG-0003JK-UR for tls@megatron.ietf.org; Tue, 11 Oct 2005 22:34:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20622 for ; Tue, 11 Oct 2005 22:34:54 -0400 (EDT) Received: from 209-204-118-122.sniparpa.net ([209.204.118.122] helo=bcisse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPWcT-0002B5-O5 for tls@ietf.org; Tue, 11 Oct 2005 22:45:31 -0400 Received: from simon ([12.150.188.2]) by bcisse.com; Tue, 11 Oct 2005 22:33:24 -0400 From: "Simon Blake-Wilson" To: , "'Russ Housley'" Subject: RE: [TLS] AD comments on draft-ietf-tls-ecc-11 Date: Tue, 11 Oct 2005 22:34:18 -0400 Message-ID: <042401c5ced5$738ccb50$da6514ac@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 MIME-Version: 1.0 In-Reply-To: <20051011191218.47DB78A02D@laser.networkresonance.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0140465297==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0140465297== Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0420_01C5CEB3.E8BB8B40" This is a multi-part message in MIME format. ------=_NextPart_000_0420_01C5CEB3.E8BB8B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Russ and everyone else, All the AD comments look good to me except the KDF ones, which I think require some discussion. My thoughts on these embedded below ... Hope they help. I don't think there is necessarily a right or good answer, just some trade offs which depend on what one thinks is important. Best regards. simon > 5.10 ECDH, ECDSA and RSA Computations > > ... > [ I do not understand why we would want to go forward with > the "identity" > KDF when we know that NIST SP 800-56 will require a real KDF. Since > this document already has so many dependencies on X9.62 and X9.63, > it seems quite reasonable to use the X9.63 KDF. ] SBW> There was quite a long discussion among the authors on the subject of KDFs a while back. My recollection ... the "identity" KDF is applied here, then the TLS KDF is applied to the premaster secret as usual. NIST 800-56 includes the TLS KDF and allows its use for TLS, so we should be in compliance. (Of course in practice this will depend on the precise wording of the final version of 800-56.) SBW> The alternative would be to use the X9.63 KDF here, then the TLS KDF on the premaster secret. Using two distinct KDFs seems undesirable ... two potential sources of security problems rather than one, two things that may need to be negotiated rather than one, etc ... Especially when the X9.63 KDF and the 800-56 KDF are likely to be different. > [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two > specifications are not compatible in some significant ways. > By this, > I mean that a subroutine cannot be written that works with both this > document and with RFC 3278. To me, this would be highly desirable. > One glaring difference is the support for > UserKeyingMaterial (or UKM) > that is provided by the originator (the client in this > context). The > UKM and the ECDH shared secret are both inputs to the KDF. ] SBW> Both documents use the same ECDH primitive but different KDFs. This is a very common situation, isn't it? You can use a single subroutine for both if your subroutine only does the Z computation, or takes the KDF as a parameter. ------=_NextPart_000_0420_01C5CEB3.E8BB8B40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMTIwMjM0MTRaMCMGCSqGSIb3 DQEJBDEWBBRCnWe0HduR1NIMjSj5YnU2vJg8tTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgL66RcjQXthPR9PTMltZpqvNjiP8KcAMgYy/UeaDwesxmjSkfgo/BrLv HLnqHWBgbTRahJbsMFRz4ZA+H7QLovq1Fs1d1wsvcrc6fhpBs9jx3fEAC4OCDHm7EtNC7aU0/aTk LSoVfnIC3wpZQjhAkzbcdJFWYIjsnnEBM+r5dkKJAAAAAAAA ------=_NextPart_000_0420_01C5CEB3.E8BB8B40-- --===============0140465297== 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 --===============0140465297==-- From tls-bounces@lists.ietf.org Wed Oct 12 04:19:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbh6-0002l3-T2; Wed, 12 Oct 2005 04:10:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPbh4-0002kt-RL for tls@megatron.ietf.org; Wed, 12 Oct 2005 04:10:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04479 for ; Wed, 12 Oct 2005 04:10:31 -0400 (EDT) Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPbrK-0001tp-Lk for tls@ietf.org; Wed, 12 Oct 2005 04:21:12 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id E590D42E; Wed, 12 Oct 2005 10:10:31 +0200 (CEST) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45811-02; Wed, 12 Oct 2005 10:10:28 +0200 (CEST) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 858C3412; Wed, 12 Oct 2005 10:10:28 +0200 (CEST) Received: from enst.fr (dhcp164-216.enst.fr [137.194.164.216]) by infres.enst.fr (Postfix) with ESMTP id 6017713CBB; Wed, 12 Oct 2005 10:10:28 +0200 (MEST) Message-ID: <434CC4F0.9000609@enst.fr> Date: Wed, 12 Oct 2005 10:10:24 +0200 From: 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: tls@ietf.org 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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: Subject: [TLS] [Fwd: I-D ACTION:draft-badra-hajjeh-mtls-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 mailing list, I. Hajjeh and I have sent an Internet Draft that extends TLS to ensure=20 data multiplixing for applications. Comment are welcom, Best regards, Badra -------- Message d'origine -------- Sujet: I-D ACTION:draft-badra-hajjeh-mtls-00.txt Date: Tue, 11 Oct 2005 15:50:01 -0400 De: Internet-Drafts@ietf.org R=E9pondre-A: internet-drafts@ietf.org A: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : TLS Multiplexing Author(s) : M. Badra, I. Hajjeh Filename : draft-badra-hajjeh-mtls-00.txt Pages : 6 Date : 2005-10-11 =20 TLS is the famous protocol that provides authentication and data =20 protection for communication between two entities. However, missing =20 from the protocol is a way to multiplex application data over the same=20 TLS session. This document defines a new TLS sub-protocol called=20 MTLS running over TLS (or DTLS) Record protocol. The MTLS design=20 provides application multiplexing over a single TLS session. Instead=20 of associating a TLS connection with each application, MTLS allows =20 several applications to protect their exchanges over a single TLS =20 session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-badra-hajjeh-mtls-00.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 12 10:33:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhfp-0006vN-SE; Wed, 12 Oct 2005 10:33:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPhfo-0006v4-4N for tls@megatron.ietf.org; Wed, 12 Oct 2005 10:33:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23879 for ; Wed, 12 Oct 2005 10:33:37 -0400 (EDT) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPhq8-0003nO-9P for tls@ietf.org; Wed, 12 Oct 2005 10:44:20 -0400 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id A033B100FA; Wed, 12 Oct 2005 10:33:19 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07904-02; Wed, 12 Oct 2005 10:33:14 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 9966C10084; Wed, 12 Oct 2005 10:33:14 -0400 (EDT) In-Reply-To: <7210B31550AC934A8637D6619739CE690605631F@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Wed, 12 Oct 2005 10:34:13 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 10/12/2005 10:34:20 AM, Serialize complete at 10/12/2005 10:34:20 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: tls-bounces@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: , Content-Type: multipart/mixed; boundary="===============2075564420==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============2075564420== Content-Type: multipart/alternative; boundary="=_alternative 004FFC1B85257098_=" This is a multipart message in MIME format. --=_alternative 004FFC1B85257098_= Content-Type: text/plain; charset="US-ASCII" Although it is possible for the client to determine if the server is resuming by looking at the messages received, the client state machine would be easier to implement if you provided some indicator in the ServerHello message. If you include an extension in the ServerHello that indicates the server will resume then the client state machine will know exactly what msgs the server should send next. You could also indicate in the extension if the server will resume but also issue a new ticket which would then make it very clear to the client what msgs must come from the server. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com tls-bounces@lists.ietf.org wrote on 10/07/2005 07:39:41 PM: > Here is some proposed test that I think resolves the issues with session > ID raised by Rob and Nelson: > > "If a server is planning on issuing a SessionTicket to a client that > does not present one it SHOULD include an empty Session ID in the > ServerHello. If the server includes a non-empty session ID then it > is indicating intent to use stateful session resume. If the client > receives a SessionTicket from the server then it discards any Session > ID that was sent in the ServerHello. > > When presenting a ticket the client MAY generate and include Session > ID in the TLS ClientHello. If the server accepts the ticket and the > Session ID is not empty then it MUST respond with the same Session ID > present in the ClientHello. This allows the client to easily > differentiate when the server is resuming a session or falling back > to a full handshake. Since the client generates a Session ID the > server MUST NOT rely upon the Session ID having a particular value > when validating the ticket. If a ticket is presented by the client > the server MUST NOT attempt to use the Session ID in the ClientHello > for stateful session resume. Alternatively, the client MAY include > an empty Session ID in the ClientHello. In this case the client > ignores the Session ID sent in the ServerHello and must determine if > the server is resuming a session by the subsequent handshake > messages." > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Thursday, October 06, 2005 7:23 AM > > To: RDugal@certicom.com > > Cc: tls@ietf.org > > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt > > > > Rob Dugal wrote: > > > > > Actually having a ticket doesn't guarantee the server will later > > > resume with it. > > > > > > For example, the ticket could be old and the server might > > not want to > > > use it. My concern is that without knowing that the server will > > > resume using the ticket it get's a little difficult to know what > > > handshake messages the server will respond with. When the server > > > resumes with the sessionID it is pretty clear because the server > > > returns the same sessionID in the ServerHello as the client sent in > > > the ClientHello. But in TLS ticket there is no clear > > indication from > > > the ServerHello that the server will resume. And now there > > is also the > > > proposal for allowing the server to send NewSessionTicket > > on a resumed > > > session. > > > > Hmm.. I agree, it would be nice to have an unambiguous signal > > in the ServerHello that tells the client resumption is happening. > > This would be the case if we also included the normal > > sessionID as I suggested earlier in > > > > http://www.imc.org/ietf-tls/mail-archive/msg04709.html > > > > > Which also brings up the question: what does the server do if it > > > receives an invalid ticket, such as a forged ticket? Does it just > > > ignore the ticket? Send an alert? > > > > Same thing it does when it receives an invalid session ID: > > ignores it and starts a full handshake. > > > > Best regards, > > Pasi > > > > _______________________________________________ > > 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 --=_alternative 004FFC1B85257098_= Content-Type: text/html; charset="US-ASCII"
Although it is possible for the client to determine if the server is resuming by looking at the messages received, the client state machine would be easier to implement if you provided some indicator in the ServerHello message. If you include an extension in the ServerHello that indicates the server will resume then the client state machine will know exactly what msgs the server should send next. You could also indicate in the extension if the server will resume but also issue a new ticket which would then make it very clear to the client what msgs must come from the server.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

tls-bounces@lists.ietf.org wrote on 10/07/2005 07:39:41 PM:

> Here is some proposed test that I think resolves the issues with session
> ID raised by Rob and Nelson:
>
>    "If a server is planning on issuing a SessionTicket to a client that
>    does not present one it SHOULD include an empty Session ID in the
>    ServerHello.  If the server includes a non-empty session ID then it
>    is indicating intent to use stateful session resume.  If the client
>    receives a SessionTicket from the server then it discards any Session
>    ID that was sent in the ServerHello.
>
>    When presenting a ticket the client MAY generate and include Session
>    ID in the TLS ClientHello.  If the server accepts the ticket and the
>    Session ID is not empty then it MUST respond with the same Session ID
>    present in the ClientHello.  This allows the client to easily
>    differentiate when the server is resuming a session or falling back
>    to a full handshake.  Since the client generates a Session ID the
>    server MUST NOT rely upon the Session ID having a particular value
>    when validating the ticket.  If a ticket is presented by the client
>    the server MUST NOT attempt to use the Session ID in the ClientHello
>    for stateful session resume.  Alternatively, the client MAY include
>    an empty Session ID in the ClientHello.  In this case the client
>    ignores the Session ID sent in the ServerHello and must determine if
>    the server is resuming a session by the subsequent handshake
>    messages."
>
> > -----Original Message-----
> > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> > Sent: Thursday, October 06, 2005 7:23 AM
> > To: RDugal@certicom.com
> > Cc: tls@ietf.org
> > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> >
> > Rob Dugal wrote:
> >    
> > > Actually having a ticket doesn't guarantee the server will later
> > > resume with it.
> > >
> > > For example, the ticket could be old and the server might
> > not want to
> > > use it.  My concern is that without knowing that the server will
> > > resume using the ticket it get's a little difficult to know what
> > > handshake messages the server will respond with. When the server
> > > resumes with the sessionID it is pretty clear because the server
> > > returns the same sessionID in the ServerHello as the client sent in
> > > the ClientHello. But in TLS ticket there is no clear
> > indication from
> > > the ServerHello that the server will resume. And now there
> > is also the
> > > proposal for allowing the server to send NewSessionTicket
> > on a resumed
> > > session.
> >
> > Hmm.. I agree, it would be nice to have an unambiguous signal
> > in the ServerHello that tells the client resumption is happening.
> > This would be the case if we also included the normal
> > sessionID as I suggested earlier in
> >
> > http://www.imc.org/ietf-tls/mail-archive/msg04709.html
> >
> > > Which also brings up the question: what does the server do if it
> > > receives an invalid ticket, such as a forged ticket? Does it just
> > > ignore the ticket? Send an alert?
> >
> > Same thing it does when it receives an invalid session ID:
> > ignores it and starts a full handshake.
> >
> > Best regards,
> > Pasi
> >
> > _______________________________________________
> > 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
 --=_alternative 004FFC1B85257098_=-- --===============2075564420== 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 --===============2075564420==-- From tls-bounces@lists.ietf.org Wed Oct 12 11:43:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPilX-0007su-OI; Wed, 12 Oct 2005 11:43:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPilW-0007sp-Oa for tls@megatron.ietf.org; Wed, 12 Oct 2005 11:43:38 -0400 Received: from mx1.opera.com (news.opera.com [193.69.116.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29181 for ; Wed, 12 Oct 2005 11:43:34 -0400 (EDT) Received: from mailbox.opera.com (mail.opera.com [193.69.113.66]) by mx1.opera.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9CFgReG021932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 12 Oct 2005 15:42:58 GMT Received: from killashandra.oslo.opera.com (pat.opera.com [193.69.113.22]) by mailbox.opera.com (8.13.4/8.13.4/Debian-3) with ESMTP id j9CFRCsJ012834 for ; Wed, 12 Oct 2005 15:27:12 GMT Date: Wed, 12 Oct 2005 17:28:59 +0200 To: tls@ietf.org From: "Yngve Nysaeter Pettersen" Organization: Opera Software Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (Win32, build 7642) X-Virus-Scanned: ClamAV 0.87/1130/Wed Oct 12 12:34:00 2005 on mx1.opera.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit Cc: Subject: [TLS] Testing of CertificateStatus TLS Extension X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yngve@opera.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi, I've recently started experimenting with the CertificateStatus TLS Extension. Has anyone implemented serverside support for this extension? And if so, would it be possible for me to access a testserver that supports the extension so that we may test each others implementation? -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 12 12:19:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjDF-00057c-Ro; Wed, 12 Oct 2005 12:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPjDD-00057S-IB for tls@megatron.ietf.org; Wed, 12 Oct 2005 12:12:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02776 for ; Wed, 12 Oct 2005 12:12:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPjNY-0007pX-Nq for tls@ietf.org; Wed, 12 Oct 2005 12:22:57 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2005 09:12:06 -0700 X-IronPort-AV: i="3.97,207,1125903600"; d="scan'208"; a="351249753:sNHT27521168" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9CGC3Jh004602; Wed, 12 Oct 2005 09:12:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] WG review of draft-salowey-tls-ticket-04.txt Date: Wed, 12 Oct 2005 09:17:25 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6906111F67@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] WG review of draft-salowey-tls-ticket-04.txt Thread-Index: AcXPOqrNa/TvUglUTqW5ipQSBL9fRgACg7sw From: "Salowey, Joe" To: "Rob Dugal" X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 In the proposed text the client can generate a session ID for inclusion in the ClientHello with the SessionTicket extension. If the server returns the same Session ID in the ServerHello the client knows the server is resuming the session based on the ticket in the SessionTicket extension. This should address part of your concern. =20 To address whether the server will issue a SessionTicket handshake message the server could include an empty SessionTicket extension in the ClientHello when it plans to send the SessionTicket handshake message. I am reluctant to do this because the Server may not know at the time of the ServerHello if it will issue a ticket for a full handshake. =20 Joe=20 > -----Original Message----- > From: Rob Dugal [mailto:RDugal@certicom.com]=20 > Sent: Wednesday, October 12, 2005 7:34 AM > To: Salowey, Joe > Cc: Pasi.Eronen@nokia.com; tls@ietf.org; tls-bounces@lists.ietf.org > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt >=20 >=20 > Although it is possible for the client to determine if the=20 > server is resuming by looking at the messages received, the=20 > client state machine would be easier to implement if you=20 > provided some indicator in the ServerHello message. If you=20 > include an extension in the ServerHello that indicates the=20 > server will resume then the client state machine will know=20 > exactly what msgs the server should send next. You could also=20 > indicate in the extension if the server will resume but also=20 > issue a new ticket which would then make it very clear to the=20 > client what msgs must come from the server.=20 >=20 > ----------------------------------------------- > Robert Dugal > Member of Development Group > Certicom Corp. > EMAIL: rdugal@certicom.com > PHONE: (905) 501-3848 > FAX : (905) 507-4230 > WEBSITE: www.certicom.com=20 >=20 > tls-bounces@lists.ietf.org wrote on 10/07/2005 07:39:41 PM: >=20 > > Here is some proposed test that I think resolves the issues with=20 > > session ID raised by Rob and Nelson: > >=20 > > "If a server is planning on issuing a SessionTicket to a=20 > client that > > does not present one it SHOULD include an empty Session ID in the > > ServerHello. If the server includes a non-empty session=20 > ID then it > > is indicating intent to use stateful session resume. If=20 > the client > > receives a SessionTicket from the server then it=20 > discards any Session > > ID that was sent in the ServerHello. > >=20 > > When presenting a ticket the client MAY generate and=20 > include Session > > ID in the TLS ClientHello. If the server accepts the=20 > ticket and the > > Session ID is not empty then it MUST respond with the=20 > same Session ID > > present in the ClientHello. This allows the client to easily > > differentiate when the server is resuming a session or=20 > falling back > > to a full handshake. Since the client generates a Session ID the > > server MUST NOT rely upon the Session ID having a=20 > particular value > > when validating the ticket. If a ticket is presented by=20 > the client > > the server MUST NOT attempt to use the Session ID in the=20 > ClientHello > > for stateful session resume. Alternatively, the client=20 > MAY include > > an empty Session ID in the ClientHello. In this case the client > > ignores the Session ID sent in the ServerHello and must=20 > determine if > > the server is resuming a session by the subsequent handshake > > messages." > >=20 > > > -----Original Message----- > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > Sent: Thursday, October 06, 2005 7:23 AM > > > To: RDugal@certicom.com > > > Cc: tls@ietf.org > > > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt > > >=20 > > > Rob Dugal wrote: > > > =20 > > > > Actually having a ticket doesn't guarantee the server=20 > will later=20 > > > > resume with it. > > > > > > > > For example, the ticket could be old and the server might > > > not want to > > > > use it. My concern is that without knowing that the=20 > server will=20 > > > > resume using the ticket it get's a little difficult to=20 > know what=20 > > > > handshake messages the server will respond with. When=20 > the server=20 > > > > resumes with the sessionID it is pretty clear because=20 > the server=20 > > > > returns the same sessionID in the ServerHello as the=20 > client sent=20 > > > > in the ClientHello. But in TLS ticket there is no clear > > > indication from > > > > the ServerHello that the server will resume. And now there > > > is also the > > > > proposal for allowing the server to send NewSessionTicket > > > on a resumed > > > > session. > > >=20 > > > Hmm.. I agree, it would be nice to have an unambiguous=20 > signal in the=20 > > > ServerHello that tells the client resumption is happening. > > > This would be the case if we also included the normal=20 > sessionID as I=20 > > > suggested earlier in > > >=20 > > > http://www.imc.org/ietf-tls/mail-archive/msg04709.html > > >=20 > > > > Which also brings up the question: what does the server=20 > do if it=20 > > > > receives an invalid ticket, such as a forged ticket?=20 > Does it just=20 > > > > ignore the ticket? Send an alert? > > >=20 > > > Same thing it does when it receives an invalid session ID: > > > ignores it and starts a full handshake. > > >=20 > > > Best regards, > > > Pasi > > >=20 > > > _______________________________________________ > > > TLS mailing list > > > TLS@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/tls > > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 12 16:38:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnMd-0000k8-UK; Wed, 12 Oct 2005 16:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnMa-0000hy-3P for tls@megatron.ietf.org; Wed, 12 Oct 2005 16:38:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03583 for ; Wed, 12 Oct 2005 16:38:09 -0400 (EDT) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPnWw-0004Jm-BF for tls@ietf.org; Wed, 12 Oct 2005 16:48:56 -0400 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 2D3181010A; Wed, 12 Oct 2005 16:38:00 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08242-26; Wed, 12 Oct 2005 16:37:56 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 9F2DE100B4; Wed, 12 Oct 2005 16:37:56 -0400 (EDT) In-Reply-To: <7210B31550AC934A8637D6619739CE6906111F67@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Wed, 12 Oct 2005 16:38:55 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 10/12/2005 04:39:02 PM, Serialize complete at 10/12/2005 04:39:02 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 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="===============0812044325==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0812044325== Content-Type: multipart/alternative; boundary="=_alternative 00715FA085257098_=" This is a multipart message in MIME format. --=_alternative 00715FA085257098_= Content-Type: text/plain; charset="US-ASCII" "Salowey, Joe" wrote on 10/12/2005 12:17:25 PM: > In the proposed text the client can generate a session ID for inclusion > in the ClientHello with the SessionTicket extension. If the server > returns the same Session ID in the ServerHello the client knows the > server is resuming the session based on the ticket in the SessionTicket > extension. This should address part of your concern. > > To address whether the server will issue a SessionTicket handshake > message the server could include an empty SessionTicket extension in the > ClientHello when it plans to send the SessionTicket handshake message. I think you meant to say ServerHello here. > I am reluctant to do this because the Server may not know at the time of > the ServerHello if it will issue a ticket for a full handshake. > > Joe I just realized that resuming with a Ticket and sending a ServerHello with an extension would not comply with this statement from RFC 3546, section 2.3. If, on the other hand, the older session is resumed, then the server MUST ignore extensions appearing in the client hello, and send a server hello containing no extensions; in this case the extension functionality negotiated during the original session initiation is applied to the resumed session. So my earlier suggestion is probably not allowable. > > > -----Original Message----- > > From: Rob Dugal [mailto:RDugal@certicom.com] > > Sent: Wednesday, October 12, 2005 7:34 AM > > To: Salowey, Joe > > Cc: Pasi.Eronen@nokia.com; tls@ietf.org; tls-bounces@lists.ietf.org > > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt > > > > > > Although it is possible for the client to determine if the > > server is resuming by looking at the messages received, the > > client state machine would be easier to implement if you > > provided some indicator in the ServerHello message. If you > > include an extension in the ServerHello that indicates the > > server will resume then the client state machine will know > > exactly what msgs the server should send next. You could also > > indicate in the extension if the server will resume but also > > issue a new ticket which would then make it very clear to the > > client what msgs must come from the server. > > > > ----------------------------------------------- > > Robert Dugal > > Member of Development Group > > Certicom Corp. > > EMAIL: rdugal@certicom.com > > PHONE: (905) 501-3848 > > FAX : (905) 507-4230 > > WEBSITE: www.certicom.com > > > > tls-bounces@lists.ietf.org wrote on 10/07/2005 07:39:41 PM: > > > > > Here is some proposed test that I think resolves the issues with > > > session ID raised by Rob and Nelson: > > > > > > "If a server is planning on issuing a SessionTicket to a > > client that > > > does not present one it SHOULD include an empty Session ID in the > > > ServerHello. If the server includes a non-empty session > > ID then it > > > is indicating intent to use stateful session resume. If > > the client > > > receives a SessionTicket from the server then it > > discards any Session > > > ID that was sent in the ServerHello. > > > > > > When presenting a ticket the client MAY generate and > > include Session > > > ID in the TLS ClientHello. If the server accepts the > > ticket and the > > > Session ID is not empty then it MUST respond with the > > same Session ID > > > present in the ClientHello. This allows the client to easily > > > differentiate when the server is resuming a session or > > falling back > > > to a full handshake. Since the client generates a Session ID the > > > server MUST NOT rely upon the Session ID having a > > particular value > > > when validating the ticket. If a ticket is presented by > > the client > > > the server MUST NOT attempt to use the Session ID in the > > ClientHello > > > for stateful session resume. Alternatively, the client > > MAY include > > > an empty Session ID in the ClientHello. In this case the client > > > ignores the Session ID sent in the ServerHello and must > > determine if > > > the server is resuming a session by the subsequent handshake > > > messages." > > > > > > > -----Original Message----- > > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > > > Sent: Thursday, October 06, 2005 7:23 AM > > > > To: RDugal@certicom.com > > > > Cc: tls@ietf.org > > > > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt > > > > > > > > Rob Dugal wrote: > > > > > > > > > Actually having a ticket doesn't guarantee the server > > will later > > > > > resume with it. > > > > > > > > > > For example, the ticket could be old and the server might > > > > not want to > > > > > use it. My concern is that without knowing that the > > server will > > > > > resume using the ticket it get's a little difficult to > > know what > > > > > handshake messages the server will respond with. When > > the server > > > > > resumes with the sessionID it is pretty clear because > > the server > > > > > returns the same sessionID in the ServerHello as the > > client sent > > > > > in the ClientHello. But in TLS ticket there is no clear > > > > indication from > > > > > the ServerHello that the server will resume. And now there > > > > is also the > > > > > proposal for allowing the server to send NewSessionTicket > > > > on a resumed > > > > > session. > > > > > > > > Hmm.. I agree, it would be nice to have an unambiguous > > signal in the > > > > ServerHello that tells the client resumption is happening. > > > > This would be the case if we also included the normal > > sessionID as I > > > > suggested earlier in > > > > > > > > http://www.imc.org/ietf-tls/mail-archive/msg04709.html > > > > > > > > > Which also brings up the question: what does the server > > do if it > > > > > receives an invalid ticket, such as a forged ticket? > > Does it just > > > > > ignore the ticket? Send an alert? > > > > > > > > Same thing it does when it receives an invalid session ID: > > > > ignores it and starts a full handshake. > > > > > > > > Best regards, > > > > Pasi > > > > > > > > _______________________________________________ > > > > 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 > > > > --=_alternative 00715FA085257098_= Content-Type: text/html; charset="US-ASCII"
"Salowey, Joe" <jsalowey@cisco.com> wrote on 10/12/2005 12:17:25 PM:

> In the proposed text the client can generate a session ID for inclusion
> in the ClientHello with the SessionTicket extension.  If the server
> returns the same Session ID in the ServerHello the client knows the
> server is resuming the session based on the ticket in the SessionTicket
> extension.  This should address part of your concern.  
>
> To address whether the server will issue a SessionTicket handshake
> message the server could include an empty SessionTicket extension in the
> ClientHello when it plans to send the SessionTicket handshake message.
 I think you meant to say ServerHello here.

> I am reluctant to do this because the Server may not know at the time of
> the ServerHello if it will issue a ticket for a full handshake.  
>
> Joe

I just realized that resuming with a Ticket and sending a ServerHello with an extension would not comply with this statement from RFC 3546, section 2.3.

If, on the other hand, the older
  session is resumed, then the server MUST ignore extensions appearing
  in the client hello, and send a server hello containing no
  extensions; in this case the extension functionality negotiated
  during the original session initiation is applied to the resumed
  session.
So my earlier suggestion is probably not allowable.


>
> > -----Original Message-----
> > From: Rob Dugal [mailto:RDugal@certicom.com]
> > Sent: Wednesday, October 12, 2005 7:34 AM
> > To: Salowey, Joe
> > Cc: Pasi.Eronen@nokia.com; tls@ietf.org; tls-bounces@lists.ietf.org
> > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> >
> >
> > Although it is possible for the client to determine if the
> > server is resuming by looking at the messages received, the
> > client state machine would be easier to implement if you
> > provided some indicator in the ServerHello message. If you
> > include an extension in the ServerHello that indicates the
> > server will resume then the client state machine will know
> > exactly what msgs the server should send next. You could also
> > indicate in the extension if the server will resume but also
> > issue a new ticket which would then make it very clear to the
> > client what msgs must come from the server.
> >
> > -----------------------------------------------
> > Robert Dugal
> > Member of Development Group
> > Certicom Corp.
> > EMAIL: rdugal@certicom.com
> > PHONE: (905) 501-3848
> > FAX  : (905) 507-4230
> > WEBSITE: www.certicom.com
> >
> > tls-bounces@lists.ietf.org wrote on 10/07/2005 07:39:41 PM:
> >
> > > Here is some proposed test that I think resolves the issues with
> > > session ID raised by Rob and Nelson:
> > >
> > >    "If a server is planning on issuing a SessionTicket to a
> > client that
> > >    does not present one it SHOULD include an empty Session ID in the
> > >    ServerHello.  If the server includes a non-empty session
> > ID then it
> > >    is indicating intent to use stateful session resume.  If
> > the client
> > >    receives a SessionTicket from the server then it
> > discards any Session
> > >    ID that was sent in the ServerHello.
> > >
> > >    When presenting a ticket the client MAY generate and
> > include Session
> > >    ID in the TLS ClientHello.  If the server accepts the
> > ticket and the
> > >    Session ID is not empty then it MUST respond with the
> > same Session ID
> > >    present in the ClientHello.  This allows the client to easily
> > >    differentiate when the server is resuming a session or
> > falling back
> > >    to a full handshake.  Since the client generates a Session ID the
> > >    server MUST NOT rely upon the Session ID having a
> > particular value
> > >    when validating the ticket.  If a ticket is presented by
> > the client
> > >    the server MUST NOT attempt to use the Session ID in the
> > ClientHello
> > >    for stateful session resume.  Alternatively, the client
> > MAY include
> > >    an empty Session ID in the ClientHello.  In this case the client
> > >    ignores the Session ID sent in the ServerHello and must
> > determine if
> > >    the server is resuming a session by the subsequent handshake
> > >    messages."
> > >
> > > > -----Original Message-----
> > > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> > > > Sent: Thursday, October 06, 2005 7:23 AM
> > > > To: RDugal@certicom.com
> > > > Cc: tls@ietf.org
> > > > Subject: RE: [TLS] WG review of draft-salowey-tls-ticket-04.txt
> > > >
> > > > Rob Dugal wrote:
> > > >    
> > > > > Actually having a ticket doesn't guarantee the server
> > will later
> > > > > resume with it.
> > > > >
> > > > > For example, the ticket could be old and the server might
> > > > not want to
> > > > > use it.  My concern is that without knowing that the
> > server will
> > > > > resume using the ticket it get's a little difficult to
> > know what
> > > > > handshake messages the server will respond with. When
> > the server
> > > > > resumes with the sessionID it is pretty clear because
> > the server
> > > > > returns the same sessionID in the ServerHello as the
> > client sent
> > > > > in the ClientHello. But in TLS ticket there is no clear
> > > > indication from
> > > > > the ServerHello that the server will resume. And now there
> > > > is also the
> > > > > proposal for allowing the server to send NewSessionTicket
> > > > on a resumed
> > > > > session.
> > > >
> > > > Hmm.. I agree, it would be nice to have an unambiguous
> > signal in the
> > > > ServerHello that tells the client resumption is happening.
> > > > This would be the case if we also included the normal
> > sessionID as I
> > > > suggested earlier in
> > > >
> > > > http://www.imc.org/ietf-tls/mail-archive/msg04709.html
> > > >
> > > > > Which also brings up the question: what does the server
> > do if it
> > > > > receives an invalid ticket, such as a forged ticket?
> > Does it just
> > > > > ignore the ticket? Send an alert?
> > > >
> > > > Same thing it does when it receives an invalid session ID:
> > > > ignores it and starts a full handshake.
> > > >
> > > > Best regards,
> > > > Pasi
> > > >
> > > > _______________________________________________
> > > > 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
> >
> >
--=_alternative 00715FA085257098_=-- --===============0812044325== 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 --===============0812044325==-- From tls-bounces@lists.ietf.org Mon Oct 17 00:28:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMcK-0006vP-5S; Mon, 17 Oct 2005 00:28:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMcI-0006vC-H3 for tls@megatron.ietf.org; Mon, 17 Oct 2005 00:28:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14065 for ; Mon, 17 Oct 2005 00:28:46 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERMnT-0007i7-M2 for tls@ietf.org; Mon, 17 Oct 2005 00:40:32 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.55.50] (helo=tau.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKxQS-1ERMc63He6-0001Y4; Mon, 17 Oct 2005 06:28:42 +0200 Received: by tau.local (Postfix, from userid 500) id B46722F206; Sun, 16 Oct 2005 22:28:07 -0600 (MDT) Date: Sun, 16 Oct 2005 22:28:07 -0600 From: Bodo Moeller To: Russ Housley Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 Message-ID: <20051017042806.GA7755@tau.local> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042401c5ced5$738ccb50$da6514ac@simon> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Russ, thanks for the thorough review of draft-ietf-tls-ecc-11.txt. I am working on changes and clarifications to address your comments. One of your observations was that draft-ietf-tls-ecc-11.txt uses the terms "trusted key store" and "trust anchor" that do not appear in rfc2246bis. draft-ietf-tls-ecc-12.txt will instead use a terminology that is aligned with rfc2246bis. A number of times you commented that the word "certificate chain" (or simply "chain") should be replaced by "certification path". However, in these cases draft-ietf-tls-ecc-11.txt actually is following the terminology of rfc2246bis -- a "certificate chain" is a sequence of certificates as it appears in a Certificate message in the TLS protocol. I assume that when you complained about "certificate chain" this was because you thought that this was made-up terminology of draft-ietf-tls-ecc-11.txt; but actually it is a technical term for TLS, so I intend to keep it in the TLS ECC I-D. Please let me know if you do not agree with this! Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 17 16:32:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbeo-0005BH-76; Mon, 17 Oct 2005 16:32:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERben-0005Ab-0c for tls@megatron.ietf.org; Mon, 17 Oct 2005 16:32:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19332 for ; Mon, 17 Oct 2005 16:32:21 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERbq8-00061W-Eo for tls@ietf.org; Mon, 17 Oct 2005 16:44:13 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id D529B8A06F for ; Mon, 17 Oct 2005 13:45:21 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 17 Oct 2005 13:31:59 -0700 From: Eric Rescorla Message-Id: <20051017204521.D529B8A06F@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [TLS] Draft Agenda for IETF 64 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 Here's a draft agenda for our meeting in Vancouver: - Introduction (blue sheets, scribe etc) (1 min) - Agenda Bashing (4 mins) - Document status (5 minutes) - Trevor Perrin: draft-ietf-tls-srp-10 (15 minutes) - Nagendra Modadugu: draft-modadugu-tls-ctr-00 (15 minutes) - Mohamad Badra: draft-badra-hajjeh-mtls-00.txt (15 minutes) - Joe Saloway: draft-salowey-tls-ticket-04.txt (15 minutes) - General discussion: Hash functions and TLS 1.2? 1. If your name is on this list, you should plan to come with a report on the status of your draft and in particular open issues. Expect to present about 1/3-1/2 of the time and leave the rest for discussion. 2. If you asked for agenda time and didn't get it, I forgot. Let me know. 3. If you didn't get all the time you asked for, sorry about that. The schedule is a bit tight. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 17 16:35:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbhL-0007MY-P8; Mon, 17 Oct 2005 16:35:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbhI-0007Gd-G3 for tls@megatron.ietf.org; Mon, 17 Oct 2005 16:35:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20901 for ; Mon, 17 Oct 2005 16:34:57 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERbse-0006h3-VX for tls@ietf.org; Mon, 17 Oct 2005 16:46:50 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id C496D8A02D for ; Mon, 17 Oct 2005 13:48:15 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 17 Oct 2005 13:34:53 -0700 From: Eric Rescorla Message-Id: <20051017204815.C496D8A02D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] draft-modadugu-tls-ctr-00 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Relatively soon you should see an announcement about draft-modadugu-tls-ctr (temporary location: http://www.dial911anddie.com/dtls/tlsctr.txt) This draft specifies AES Counter Mode for TLS and DTLS. Comments welcome! One prefatory note: this mode was designed specifically to be essentially the same in TLS and DTLS, which is why it doesn't behave exactly like RC4. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 17 17:12:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcHw-0007qr-Sn; Mon, 17 Oct 2005 17:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERcHv-0007qj-1C for tls@megatron.ietf.org; Mon, 17 Oct 2005 17:12:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06107 for ; Mon, 17 Oct 2005 17:12:47 -0400 (EDT) Received: from saria.randombit.net ([66.179.181.167] helo=mail.randombit.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERcTJ-0003um-38 for tls@ietf.org; Mon, 17 Oct 2005 17:24:42 -0400 Received: by mail.randombit.net (Postfix, from userid 501) id F2FD6247C0FF; Mon, 17 Oct 2005 17:12:43 -0400 (EDT) Date: Mon, 17 Oct 2005 17:12:43 -0400 From: Jack Lloyd To: tls@ietf.org Subject: Re: [TLS] draft-modadugu-tls-ctr-00 Message-ID: <20051017211243.GC2598@randombit.net> Mail-Followup-To: tls@ietf.org References: <20051017204815.C496D8A02D@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051017204815.C496D8A02D@laser.networkresonance.com> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I can't say I'm a huge fan of the IV generation method, as it basically means a TLS implementation has to treat block ciphers in CBC mode, block ciphers in CTR mode, and stream ciphers all in different ways. While saving the per-record IV is, I suppose, nice, the extra code complexity doesn't make it a worthwhile tradeoff (IMO); you could do counter mode using either the explicit IVs in TLS 1.1 or even using an implicit counter when using TLS 1.0 (starting with the originally negotiated IV and incrementing), and save a lot of trouble. And IIRC DTLS always uses explicit IVs right now, so there is no problem there. Is there some environment where saving the IV (and padding bytes, if you were to treat CTR mode as "exactly like CBC, but better") is actually enough of a win where that is worth the effort? Secondly, it would be nice if this was just slightly more general, to allow the use of other block ciphers. While it would still be necessary to produce an RFC with the ciphersuite numbers, etc, there is no reason the method adopted should not be directly usable with other ciphers. In particular, I note that the IV generation method as it is defined now will only work with 128-bit block ciphers. As far as I know, 3DES in counter mode is perfectly secure (and is FIPS approved until at least 2010), and might be a good choice if, for example, you have a 3DES hardware encryptor handy, or if you just don't trust AES for whatever reason. I don't see the point in designing the mechanism specifically to exclude it, unless we're going with a "thy block cipher is AES and thou shalt have no block ciphers before it" interpretation. Which might be reasonable; I'd just like to see a little discussion on it beforehand. -Jack On Mon, Oct 17, 2005 at 01:34:53PM -0700, Eric Rescorla wrote: > Relatively soon you should see an announcement about > draft-modadugu-tls-ctr > (temporary location: http://www.dial911anddie.com/dtls/tlsctr.txt) > > This draft specifies AES Counter Mode for TLS and DTLS. > Comments welcome! One prefatory note: this mode was designed > specifically to be essentially the same in TLS and DTLS, which > is why it doesn't behave exactly like RC4. > > -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 Oct 18 04:45:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERn6R-0007Zq-4S; Tue, 18 Oct 2005 04:45:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERn6N-0007Zi-Op for tls@megatron.ietf.org; Tue, 18 Oct 2005 04:45:45 -0400 Received: from turtle.i-net.gr ([81.175.93.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13732 for ; Tue, 18 Oct 2005 04:45:31 -0400 (EDT) Received: from nmav by turtle.i-net.gr with local (Exim 4.50) id 1ERn69-00081u-Am for tls@lists.ietf.org; Tue, 18 Oct 2005 10:45:29 +0200 From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] draft-modadugu-tls-ctr-00 Date: Tue, 18 Oct 2005 10:45:26 +0200 User-Agent: KMail/1.8.2 References: <20051017204815.C496D8A02D@laser.networkresonance.com> In-Reply-To: <20051017204815.C496D8A02D@laser.networkresonance.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200510181045.27855.nmav@gnutls.org> Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Monday 17 October 2005 22:34, Eric Rescorla wrote: > Relatively soon you should see an announcement about > draft-modadugu-tls-ctr > (temporary location: http://www.dial911anddie.com/dtls/tlsctr.txt) > > This draft specifies AES Counter Mode for TLS and DTLS. > Comments welcome! One prefatory note: this mode was designed > specifically to be essentially the same in TLS and DTLS, which > is why it doesn't behave exactly like RC4. My main concern would be why this extra block cipher mode might be needed. It seems that given that this stream mode is based on a block cipher it offers little advantage over cbc for hardware implementors. Also the fact that random size padding is not available it makes it inferior to TLS CBC mode for the purposes of traffic analysis. Don't take it negatively, but the main issue that this cipher mode solves, wasn't clear to me from the document. -- Nikos Mavrogiannopoulos -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 18 08:48:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqtc-0004cU-Lh; Tue, 18 Oct 2005 08:48:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqta-0004a2-CH for tls@megatron.ietf.org; Tue, 18 Oct 2005 08:48:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27413 for ; Tue, 18 Oct 2005 08:48:37 -0400 (EDT) Received: from ottawa-hs-209-217-122-41.s-ip.magma.ca ([209.217.122.41] helo=nexus.ellipticsemi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERr54-00043u-Kl for tls@ietf.org; Tue, 18 Oct 2005 09:00:41 -0400 Message-ID: <4354EF05.3060901@ellipticsemi.com> Date: Tue, 18 Oct 2005 08:48:05 -0400 From: Michael Bowler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] draft-modadugu-tls-ctr-00 References: <20051017204815.C496D8A02D@laser.networkresonance.com> <200510181045.27855.nmav@gnutls.org> In-Reply-To: <200510181045.27855.nmav@gnutls.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org > My main concern would be why this extra block cipher mode might be needed. It > seems that given that this stream mode is based on a block cipher it offers > little advantage over cbc for hardware implementors. Counter mode may be pipelined, alowing very fast hardware implementations. Unfortunately, combining a potentially fast counter cipher with a slow authenticator (HMAC-SHA1) reduces this benefit. Michael -- Michael Bowler mbowler@ellipticsemi.com IC Design Engineer (613) 254-5456x107 Elliptic Semiconductor www.ellipticsemi.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 18 09:20:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrOV-0007iP-Fq; Tue, 18 Oct 2005 09:20:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrOT-0007hf-UR for tls@megatron.ietf.org; Tue, 18 Oct 2005 09:20:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29324 for ; Tue, 18 Oct 2005 09:20:34 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERra0-0004zh-PW for tls@ietf.org; Tue, 18 Oct 2005 09:32:37 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 053C31705C; Tue, 18 Oct 2005 06:24:50 -0700 (PDT) To: tls@ietf.org Subject: Re: [TLS] draft-modadugu-tls-ctr-00 References: <20051017204815.C496D8A02D@laser.networkresonance.com> <20051017211243.GC2598@randombit.net> From: Eric Rescorla Date: Tue, 18 Oct 2005 06:24:49 -0700 In-Reply-To: <20051017211243.GC2598@randombit.net> (Jack Lloyd's message of "Mon, 17 Oct 2005 17:12:43 -0400") Message-ID: <867jcb9cv2.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Jack Lloyd writes: > I can't say I'm a huge fan of the IV generation method, as it > basically means a TLS implementation has to treat block ciphers in CBC > mode, block ciphers in CTR mode, and stream ciphers all in different > ways. While saving the per-record IV is, I suppose, nice, the extra > code complexity doesn't make it a worthwhile tradeoff (IMO); you could > do counter mode using either the explicit IVs in TLS 1.1 or even using > an implicit counter when using TLS 1.0 (starting with the originally > negotiated IV and incrementing), and save a lot of trouble. And IIRC > DTLS always uses explicit IVs right now, so there is no problem > there. Is there some environment where saving the IV (and padding > bytes, if you were to treat CTR mode as "exactly like CBC, but > better") is actually enough of a win where that is worth the effort? Well, applying CTR to DTLS means that you really need to be able to reset the cipher-state on a per-record boundary, whether the IV is explicit or implicit. This rules out the "long cipher stream" approach that TLS uses for RC4, at least for DTLS. Obviously, you could use different mechanisms for TLS and DTLS, but this introduces extra complexity. If we agree that we want the mechanisms to be the same between TLS and DTLS, then this forces block, stream, and CTR all to be different in TLS. This brings us to the question of IV. Once you're resetting the state at the record boundary, it's not clear to me that an explicit IV is substantially more complicated than an implicit one, and the additional 16 octets on the wire is not insignificant, esp. seeing as a major part of the rationale for CTR is to reduce transmission bandwidth. This does seem to me to be important in some environments, esp. VPNs (if small packet sizes are used) and voice. > Secondly, it would be nice if this was just slightly more general, to > allow the use of other block ciphers. While it would still be > necessary to produce an RFC with the ciphersuite numbers, etc, there > is no reason the method adopted should not be directly usable with > other ciphers. In particular, I note that the IV generation method as > it is defined now will only work with 128-bit block ciphers. As far as > I know, 3DES in counter mode is perfectly secure (and is FIPS approved > until at least 2010), and might be a good choice if, for example, you > have a 3DES hardware encryptor handy, or if you just don't trust AES > for whatever reason. I don't see the point in designing the mechanism > specifically to exclude it, unless we're going with a "thy block > cipher is AES and thou shalt have no block ciphers before it" > interpretation. Which might be reasonable; I'd just like to see a > little discussion on it beforehand. Well, I think there are two separable issues here: whether we should support ciphers other than AES and whether we should support ciphers with block sizes < 128 bits. In general, I tend to think we should be moving away from DES, so I'm not super-eager to try to accomodate it. I agree that it would make sense to generalize this mechanism to block sizes > 128 bits. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 19 12:37:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGwB-0000lT-BV; Wed, 19 Oct 2005 12:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGwA-0000lI-A0 for tls@megatron.ietf.org; Wed, 19 Oct 2005 12:37:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27298 for ; Wed, 19 Oct 2005 12:37:01 -0400 (EDT) Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESH7v-0000Ug-5o for tls@ietf.org; Wed, 19 Oct 2005 12:49:20 -0400 Received: from theory.stanford.edu ([171.64.78.10]) by agp.stanford.edu with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.43) id 1ESGvx-0007Vy-FI for tls@ietf.org; Wed, 19 Oct 2005 09:36:57 -0700 Received: from mail by theory.Stanford.EDU with spam-scanned (Exim 4.30) id 1ESGvw-0002l5-4k for tls@ietf.org; Wed, 19 Oct 2005 09:36:57 -0700 Received: from cipher.stanford.edu ([171.64.78.146]) by theory.Stanford.EDU with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1ESGvw-0002l1-2m for tls@ietf.org; Wed, 19 Oct 2005 09:36:56 -0700 Received: from cipher.Stanford.EDU (localhost.localdomain [127.0.0.1]) by cipher.Stanford.EDU (8.13.4/8.12.11) with ESMTP id j9JGatc0018863 for ; Wed, 19 Oct 2005 09:36:55 -0700 Received: (from nagendra@localhost) by cipher.Stanford.EDU (8.13.4/8.13.4/Submit) id j9JGatNV018862 for tls@ietf.org; Wed, 19 Oct 2005 09:36:55 -0700 X-Authentication-Warning: cipher.Stanford.EDU: nagendra set sender to nagendra@cs.stanford.edu using -f Date: Wed, 19 Oct 2005 09:36:55 -0700 From: nagendra modadugu To: tls@ietf.org Subject: Re: [TLS] draft-modadugu-tls-ctr-00 Message-ID: <20051019163655.GA18270@cs.stanford.edu> References: <20051017204815.C496D8A02D@laser.networkresonance.com> <200510181045.27855.nmav@gnutls.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510181045.27855.nmav@gnutls.org> User-Agent: Mutt/1.4.1i X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Spam-Status: No, score=-104.9 required=7.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=no version=3.0.4-cs-csdcf X-Spam-Score: 0.0 (/) 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org * Nikos Mavrogiannopoulos [2005-10-18 10:45:26 +0200]: > My main concern would be why this extra block cipher mode might be needed. It > seems that given that this stream mode is based on a block cipher it offers > little advantage over cbc for hardware implementors. Also the fact that > random size padding is not available it makes it inferior to TLS CBC mode for > the purposes of traffic analysis. Don't take it negatively, but the main > issue that this cipher mode solves, wasn't clear to me from the document. Agreed that CTR mode provides less protection against traffic analysis-- however, there are a number of applications that send fixed sized or predictable size packets anyway (voice in particular, but even VPNs and Web traffic generate fairly predictable packet sizes in many situations) In such cases, CBC does not offer much protection against traffic analysis. The main point that CTR mode addresses is low-bandwidth that results from saving on explicit-IV and the padding block (between 17-32 bytes total), which can be a significant overhead for applications that generate small records (such as voice and VPN.) I'll work on making this point more prominently in the draft. Thanks, nagendra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 20 18:50:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjEn-0006Hl-92; Thu, 20 Oct 2005 18:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjEZ-00069O-Hr for tls@megatron.ietf.org; Thu, 20 Oct 2005 18:50:03 -0400 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20159 for ; Thu, 20 Oct 2005 18:49:53 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ESjEY-00067k-BP; Thu, 20 Oct 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 20 Oct 2005 18:50:02 -0400 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-12.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : ECC Cipher Suites for TLS Author(s) : V. Gupta, et al. Filename : draft-ietf-tls-ecc-12.txt Pages : 38 Date : 2005-10-20 This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the TLS (Transport Layer Security) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-20182934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-20182934.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Fri Oct 21 21:12:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET7wM-0001Ab-1Z; Fri, 21 Oct 2005 21:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET7wK-0001AT-0l for tls@megatron.ietf.org; Fri, 21 Oct 2005 21:12:52 -0400 Received: from sam.opera.com (sam.opera.com [193.69.113.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08954 for ; Fri, 21 Oct 2005 21:12:40 -0400 (EDT) Received: from nimisha.invalid.invalid (pat.opera.com [193.69.113.22]) (authenticated bits=0) by sam.opera.com (8.12.3/8.12.3/Debian-7.1) with ESMTP id j9M1C19B002170 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 22 Oct 2005 01:12:15 GMT Date: Sat, 22 Oct 2005 03:12:03 +0200 From: "Yngve N. Pettersen (Developer Opera Software ASA)" To: tls@ietf.org Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: User-Agent: Opera M2/8.02 (Win32, build 7680) X-Scanned-By: MIMEDefang 2.39 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA08954 Cc: Subject: [TLS] TLS Certificate Staus Extension interoperability testing X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 Hello all, As I mentioned in an earlier message I've been looking at implementing th= e =20 RFC 3546 Certificate Status TLS Extension (RFC 3546). Experimental support for this extension is included in the Opera 9.0 =20 Technology Preview released this week. We would appreciate it if developers of TLS for servers that are also =20 developing CertificateStatus support try out this extension with this =20 release. Please report any problems you find to me. Other things that may be of interest to the TLS community in this version= : - We are (again) testing if it is possible to disable SSL v2 as well a= s =20 the 40 and 56 bit ciphers in the defult configuration. A similar test a =20 year ago revealed that too many significant sites were still using these,= =20 but serveral, if not all, of the more important ones have now upgraded. - The SSL v3+ Client Hello is now used in the initial handshake to a =20 server, with a fallback to SSL v2 Client Hello if there is a problem. - TLS 1.1 and TLS Extentsions (ServerName and CertificateStatus) are =20 enabled by default, but are only used after tests have shown that the =20 server is able to handle these features. This testing is necessary due to= =20 the problems with non-compliant servers we discovered a year ago, and =20 which caused us to turn these features off by default in Opera v8.x. For more information and download links please see: Windows: http://snapshot.opera.com/windows/w90p1.html Linux: http://snapshot.opera.com/unix/u90p1.html Mac: http://snapshot.opera.com/mac/m90p1.html --=20 Sincerely, Yngve N. Pettersen =A0 ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 24 09:41:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2Zr-00061E-4T; Mon, 24 Oct 2005 09:41:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2Zq-000619-2f for tls@megatron.ietf.org; Mon, 24 Oct 2005 09:41:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10257 for ; Mon, 24 Oct 2005 09:41:11 -0400 (EDT) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EU2mZ-00044B-SW for tls@ietf.org; Mon, 24 Oct 2005 09:54:37 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 35485101819C5; Mon, 24 Oct 2005 09:41:10 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18699-02; Mon, 24 Oct 2005 09:41:08 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 1E75A101813AF; Mon, 24 Oct 2005 09:41:08 -0400 (EDT) In-Reply-To: <434CC4F0.9000609@enst.fr> To: badra Subject: Re: [TLS] [Fwd: I-D ACTION:draft-badra-hajjeh-mtls-00.txt] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Mon, 24 Oct 2005 09:41:55 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 10/24/2005 09:42:06 AM, Serialize complete at 10/24/2005 09:42:06 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: tls-bounces@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: , Content-Type: multipart/mixed; boundary="===============0734700968==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0734700968== Content-Type: multipart/alternative; boundary="=_alternative 004B3895852570A4_=" This is a multipart message in MIME format. --=_alternative 004B3895852570A4_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The wording in section 3.1 is not clear to me. Note: if the server agrees, the client SHOULD establish a single TLS=20 (respectively DTLS) session for all applications it wishes to run=20 over TCP (respectively UDP). In this case, the client SHOULD send a=20 data multiplexing extension containing "ALL" as=20 ApplicationpProtocolName value and "NULL" as TCPPort (or UDPPort)=20 value. If the server is not able to negotiate such session, it=20 replays with a list of applications (names and ports) it can accept=20 to run through a single TLS session, falls back on an ordinary TLS=20 handshake or stops the negotiation. Above you say the client should send application name "ALL" and port=20 "NULL". "NULL" appears to indicate the 4 byte string 'N','U','L','L'=20 should be encoded in the extension. However, in the=20 ApplicationLayerProtocol structure a UDP or TCP port is a 2 byte field. I=20 assume you mean 0x00,0x00. Suppose the client sends the following list of application names & ports:=20 "smtp",25,"ftp",20 Suppose the server supports: "smtp",25 and "ssh",22 Does the server respond with only the intersection between what the client = & server support, or does the server respond with all the applications it=20 supports? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com tls-bounces@lists.ietf.org wrote on 10/12/2005 04:10:24 AM: >=20 > Dear mailing list, >=20 > I. Hajjeh and I have sent an Internet Draft that extends TLS to ensure=20 > data multiplixing for applications. >=20 > Comment are welcom, >=20 > Best regards, > Badra >=20 > -------- Message d'origine -------- > Sujet: I-D ACTION:draft-badra-hajjeh-mtls-00.txt > Date: Tue, 11 Oct 2005 15:50:01 -0400 > De: Internet-Drafts@ietf.org > R=E9pondre-A: internet-drafts@ietf.org > A: i-d-announce@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : TLS Multiplexing > Author(s) : M. Badra, I. Hajjeh > Filename : draft-badra-hajjeh-mtls-00.txt > Pages : 6 > Date : 2005-10-11 >=20 > TLS is the famous protocol that provides authentication and data=20 > protection for communication between two entities. However, missing=20 > from the protocol is a way to multiplex application data over the same = > TLS session. This document defines a new TLS sub-protocol called=20 > MTLS running over TLS (or DTLS) Record protocol. The MTLS design=20 > provides application multiplexing over a single TLS session. Instead=20 > of associating a TLS connection with each application, MTLS allows=20 > several applications to protect their exchanges over a single TLS=20 > session. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-badra-hajjeh-mtls-00.txt >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 004B3895852570A4_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
The wording in section 3.1 is not cl= ear to me.

 Note: if the server agrees, the client SHOULD establish a single TLS
  (respectively DTLS) session for all applications it wishes to run
  over TCP (respectively UDP). In this case, the client SHOULD send a
  data multiplexing extension containing "ALL" as
  ApplicationpProtocolName value and "NULL" as TCPPort (or UDPPort)
  value. If the server is not able to negotiate such session, it
  replays with a list of applications (names and ports) it can accept
  to run through a single TLS session, falls back on an ordinary TLS
  handshake or stops the negotiation.

Above you say the client should send application name "ALL" and port "NULL".  "NUL= L" appears to indicate the 4 byte string 'N','U','L','L' should be encoded in the extension. However, in the ApplicationLayerProtocol structure a UDP or TCP port is a 2 byte field. I assume you mean 0x00,0x00.

Suppose the client sends the followi= ng list of application names & ports: "smtp",25,"ftp",= 20
Suppose the server supports: "s= mtp",25 and "ssh",22
Does the server respond with only the intersection between what the client & server support, or does the server respond with all the applications it supports?



-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

tls-bounces@lists.ietf.org wrote on 10/12/2005 04:10= :24 AM:

>
> Dear mailing list,
>
> I. Hajjeh and I have sent an Internet Draft that extends TLS to ensure
> data multiplixing for applications.
>
> Comment are welcom,
>
> Best regards,
> Badra
>
> -------- Message d'origine --------
> Sujet: I-D ACTION:draft-badra-hajjeh-mtls-00.txt
> Date: Tue, 11 Oct 2005 15:50:01 -0400
> De: Internet-Drafts@ietf.org
> R=E9pondre-A: internet-drafts@ietf.org
> A: i-d-announce@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>     Title        : TLS Multiplexing
>     Author(s)    : M. Badra, I. Hajjeh
>     Filename    : draft-badra-hajjeh-mtls-00.txt >     Pages        : 6
>     Date        : 2005-10-11
>    
>   TLS is the famous protocol that provides authentication and data  
> protection for communication between two entities. However, missing  
> from the protocol is a way to multiplex application data over the   same
> TLS session.      This document defines a new TLS sub-p= rotocol called
> MTLS running   over TLS (or DTLS) Record protocol. The MTLS design
> provides   application multiplexing over a single TLS session. Instead
> of   associating a TLS connection with each application, MTLS allows  
> several applications to protect their exchanges over a single TLS  
> session.
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-badra-hajjeh-mtls-00.txt
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 004B3895852570A4_=-- --===============0734700968== 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 --===============0734700968==-- From tls-bounces@lists.ietf.org Mon Oct 24 13:37:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6Gh-0005p2-Ha; Mon, 24 Oct 2005 13:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU6Gf-0005ou-Dk for tls@megatron.ietf.org; Mon, 24 Oct 2005 13:37:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22476 for ; Mon, 24 Oct 2005 13:37:40 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU6TQ-0003Qb-Q4 for tls@ietf.org; Mon, 24 Oct 2005 13:51:07 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Oct 2005 10:37:40 -0700 X-IronPort-AV: i="3.97,245,1125903600"; d="scan'208"; a="356003409:sNHT23084236" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9OHbbub013960 for ; Mon, 24 Oct 2005 10:37:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2005 10:43:07 -0700 Message-ID: <7210B31550AC934A8637D6619739CE69061B17F5@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: draft-salowey-tls-ticket-05.txt available Thread-Index: AcXYwZ9j7/G9DfUSSnSpjPBRXx8Swg== From: "Salowey, Joe" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: Subject: [TLS] draft-salowey-tls-ticket-05.txt available X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org draft-salowey-tls-ticket-05.txt is available at http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt changes based on review comments: - Section 3.4 added to describe interaction with session ID - Section 4 now indicates recommended format instead of example - Sections 3.2 and 3.3 behavior of messages clarified=20 Thanks, Joe _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 24 16:23:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8rI-0005OD-46; Mon, 24 Oct 2005 16:23:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU8rG-0005Ny-5S for tls@megatron.ietf.org; Mon, 24 Oct 2005 16:23:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10862 for ; Mon, 24 Oct 2005 16:23:35 -0400 (EDT) From: badra@infres.enst.fr Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU941-00041Z-RW for tls@ietf.org; Mon, 24 Oct 2005 16:37:05 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id F2823164C00; Mon, 24 Oct 2005 22:23:41 +0200 (CEST) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62858-05; Mon, 24 Oct 2005 22:23:41 +0200 (CEST) Received: from infres5.enst.fr (infres5.enst.fr [137.194.192.5]) by smtp2.enst.fr (Postfix) with ESMTP id 01C16164C07; Mon, 24 Oct 2005 22:23:40 +0200 (CEST) Received: from www.infres.enst.fr (localhost [IPv6:::1]) by infres5.enst.fr (8.12.10+Sun/8.12.10) with ESMTP id j9OKNdqK026044; Mon, 24 Oct 2005 22:23:40 +0200 (MEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Mon, 24 Oct 2005 22:23:40 +0200 (MEST) Message-ID: <60063.127.0.0.1.1130185420.squirrel@127.0.0.1> Date: Mon, 24 Oct 2005 22:23:40 +0200 (MEST) Subject: Re: [TLS] [Fwd: I-D ACTION:draft-badra-hajjeh-mtls-00.txt] To: "Rob Dugal" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Dear Robert, ; Mon, 24 Oct 2005 17:01:59 -0400 (EDT) Received: from smtp-out6.blueyonder.co.uk ([195.188.213.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EU9fE-0007zz-OK for tls@ietf.org; Mon, 24 Oct 2005 17:15:30 -0400 Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out6.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Oct 2005 22:00:32 +0100 Message-ID: <435D4B3B.3080003@blueyonder.co.uk> Date: Mon, 24 Oct 2005 21:59:39 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] [Fwd: I-D ACTION:draft-badra-hajjeh-mtls-00.txt] References: <60063.127.0.0.1.1130185420.squirrel@127.0.0.1> In-Reply-To: <60063.127.0.0.1.1130185420.squirrel@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Oct 2005 21:00:32.0902 (UTC) FILETIME=[F9217A60:01C5D8DD] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org badra@infres.enst.fr wrote: > Dear Robert, > > > The server selects from the client suggestions. AFAIK, the TLS server > cannot reply with additional or different suggestions for an arbitrary > extension sent by the client. I'd just like to clarify that the extensions mechanism does not specify this. How any negotiation of options within an extension is handled is up to the definition of that particular extension. IOW, while the server cannot send an extension that was not in the client hello, this policy doesn't necessarily apply to individual options within extensions. So if it is intended to apply here, should explicitly say so. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 24 22:20:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEQ7-0003Kk-27; Mon, 24 Oct 2005 22:20:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUEQ4-0003JP-Nt for tls@megatron.ietf.org; Mon, 24 Oct 2005 22:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11501 for ; Mon, 24 Oct 2005 22:19:54 -0400 (EDT) From: badra@infres.enst.fr Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUEcv-0001JO-RW for tls@ietf.org; Mon, 24 Oct 2005 22:33:27 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 0E9DC164B9A; Tue, 25 Oct 2005 04:20:06 +0200 (CEST) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78930-10; Tue, 25 Oct 2005 04:20:05 +0200 (CEST) Received: from infres5.enst.fr (infres5.enst.fr [137.194.192.5]) by smtp2.enst.fr (Postfix) with ESMTP id 6133A164B55; Tue, 25 Oct 2005 04:20:05 +0200 (CEST) Received: from www.infres.enst.fr (localhost [IPv6:::1]) by infres5.enst.fr (8.12.10+Sun/8.12.10) with ESMTP id j9P2K4qK029327; Tue, 25 Oct 2005 04:20:04 +0200 (MEST) Received: from localhost ([127.0.0.1]) (SquirrelMail authenticated user badra); by www.infres.enst.fr with HTTP; Tue, 25 Oct 2005 04:20:05 +0200 (MEST) Message-ID: <63741.127.0.0.1.1130206805.squirrel@127.0.0.1> In-Reply-To: <63563.127.0.0.1.1130205223.squirrel@127.0.0.1> References: <63563.127.0.0.1.1130205223.squirrel@127.0.0.1> Date: Tue, 25 Oct 2005 04:20:05 +0200 (MEST) Subject: Re: [TLS] [Fwd: I-D ACTION:draft-badra-hajjeh-mtls-00.txt] To: david.nospam.hopwood@blueyonder.co.uk User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 > David Hopwood a =E9crit: > > I'd just like to clarify that the extensions mechanism does not specify > this. How any negotiation of options within an extension is handled is = up > to the definition of that particular extension. > > IOW, while the server cannot send an extension that was not in the clie= nt > hello, this policy doesn't necessarily apply to individual options with= in > extensions. So if it is intended to apply here, > should explicitly say so. > In this case, it is more interested to the client that the server respond= s with all the applications it supports. This will be equivalent to the cas= e when the client initialises its extension with "ALL" as ApplicationpProtocolName and "0x00 0x00" as TCPPort (or UDPPort), except that it is the server who proposes more options. However, if the client sends a list of application names and ports and that the server does not support any of them, then the server should stop the negotiation or should fall back on an ordinary TLS handshake. The server must not answer to the multiplexing extension if it does not support at least one application requested by the client. But do you agre= e with that? Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 26 12:52:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoW0-0005d8-1V; Wed, 26 Oct 2005 12:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUoVy-0005d3-82 for tls@megatron.ietf.org; Wed, 26 Oct 2005 12:52:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06944 for ; Wed, 26 Oct 2005 12:52:22 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoj9-0001Yx-Ma for tls@ietf.org; Wed, 26 Oct 2005 13:06:16 -0400 Received: by machshav.com (Postfix, from userid 512) id BF389FB284; Wed, 26 Oct 2005 16:52:31 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 52391FB249 for ; Wed, 26 Oct 2005 16:52:31 +0000 (UTC) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 68D213BFD40 for ; Wed, 26 Oct 2005 12:52:30 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: tls@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Oct 2005 12:52:30 -0400 Message-Id: <20051026165230.68D213BFD40@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [TLS] SSL/TLS changes in Windows Vista X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 http://www.pcworld.com/news/article/0%2caid%2c123215%2c00.asp --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 Wed Oct 26 13:47:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpNB-0003Sx-6A; Wed, 26 Oct 2005 13:47:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpN8-0003Q1-QP for tls@megatron.ietf.org; Wed, 26 Oct 2005 13:47:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10019 for ; Wed, 26 Oct 2005 13:47:17 -0400 (EDT) Received: from yancy.pkiclue.com ([209.172.115.117] helo=yancy.b70.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUpaJ-0003Fj-Tp for tls@ietf.org; Wed, 26 Oct 2005 14:01:13 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id KAA06351 for ; Wed, 26 Oct 2005 10:50:49 -0700 Message-ID: <435FC12B.6060401@canola-jones.com> Date: Wed, 26 Oct 2005 10:47:23 -0700 From: Rodney Thayer User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] SSL/TLS changes in Windows Vista References: <20051026165230.68D213BFD40@berkshire.machshav.com> In-Reply-To: <20051026165230.68D213BFD40@berkshire.machshav.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Steven M. Bellovin wrote: > http://www.pcworld.com/news/article/0%2caid%2c123215%2c00.asp they're turning off SSLv2 - yay! they're turning on TLS - yay! Anyone who had heartburn about the loss of SSLv2 deserves the pain ;-) Nice of them to finally enable TLS... doing that a few years ago would have been better... are there any things that disrupt the use of the rfc? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 26 20:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUvc1-0002cz-Fx; Wed, 26 Oct 2005 20:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUvc0-0002YC-46 for tls@megatron.ietf.org; Wed, 26 Oct 2005 20:27:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08566 for ; Wed, 26 Oct 2005 20:27:03 -0400 (EDT) Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUvna-0007vo-5x for tls@ietf.org; Wed, 26 Oct 2005 20:39:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 06A7435069; Thu, 27 Oct 2005 13:25:19 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17757-26; Thu, 27 Oct 2005 13:25:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id DD39D35066; Thu, 27 Oct 2005 13:25:18 +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 6B1FC37750; Thu, 27 Oct 2005 13:25:18 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EUva4-0005Iz-00; Thu, 27 Oct 2005 13:25:20 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: rodney@canola-jones.com, tls@ietf.org Subject: Re: [TLS] SSL/TLS changes in Windows Vista In-Reply-To: <435FC12B.6060401@canola-jones.com> Message-Id: Date: Thu, 27 Oct 2005 13:25:20 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.9 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rodney Thayer writes: >they're turning off SSLv2 - yay! > >they're turning on TLS - yay! More importantly, they're finally making some desperately-needed UI changes. Not necessarily the most-needed ones, but one they have got right is making security errors behave more like general network problems, rather than popping up a "Click here to make this go away" dialog. The only depressing thing, from the HCI point of view, is that from leading the pack in terms of security features a few years ago it looks like Mozilla/Firefox is going to be going back to play-catchup-with-Microsoft mode rather than pioneering new security UI features. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 29 16:41:13 2005 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 1EVxVp-0000vE-AL; Sat, 29 Oct 2005 16:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxVn-0000v9-Tj for tls@megatron.ietf.org; Sat, 29 Oct 2005 16:41:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23812 for ; Sat, 29 Oct 2005 16:40:53 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVxjd-000706-BS for tls@ietf.org; Sat, 29 Oct 2005 16:55:30 -0400 Received: (qmail 21081 invoked by uid 0); 29 Oct 2005 20:41:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 29 Oct 2005 20:41:01 -0000 Message-Id: <7.0.0.10.2.20051029160239.02aff038@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Sat, 29 Oct 2005 16:03:01 -0400 To: Bodo Moeller From: Russ Housley Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 In-Reply-To: <20051017042806.GA7755@tau.local> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> <20051017042806.GA7755@tau.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Bodo: Okay. This works for me. Russ At 12:28 AM 10/17/2005, Bodo Moeller wrote: >Russ, > >thanks for the thorough review of draft-ietf-tls-ecc-11.txt. I am >working on changes and clarifications to address your comments. > > >One of your observations was that draft-ietf-tls-ecc-11.txt uses the >terms "trusted key store" and "trust anchor" that do not appear in >rfc2246bis. draft-ietf-tls-ecc-12.txt will instead use a terminology >that is aligned with rfc2246bis. > >A number of times you commented that the word "certificate chain" >(or simply "chain") should be replaced by "certification path". >However, in these cases draft-ietf-tls-ecc-11.txt actually is >following the terminology of rfc2246bis -- a "certificate chain" >is a sequence of certificates as it appears in a Certificate message >in the TLS protocol. I assume that when you complained about >"certificate chain" this was because you thought that this was made-up >terminology of draft-ietf-tls-ecc-11.txt; but actually it is a >technical term for TLS, so I intend to keep it in the TLS ECC I-D. >Please let me know if you do not agree with this! > >Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Oct 29 16:41:15 2005 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 1EVxVr-0000vl-R9; Sat, 29 Oct 2005 16:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxVp-0000vc-I2 for tls@megatron.ietf.org; Sat, 29 Oct 2005 16:41:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23815 for ; Sat, 29 Oct 2005 16:40:54 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVxjf-00070B-W5 for tls@ietf.org; Sat, 29 Oct 2005 16:55:32 -0400 Received: (qmail 21128 invoked by uid 0); 29 Oct 2005 20:41:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.238.33) by woodstock.binhost.com with SMTP; 29 Oct 2005 20:41:04 -0000 Message-Id: <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Sat, 29 Oct 2005 16:41:04 -0400 To: "Simon Blake-Wilson" , From: Russ Housley Subject: RE: [TLS] AD comments on draft-ietf-tls-ecc-11 In-Reply-To: <042401c5ced5$738ccb50$da6514ac@simon> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Simon: I knew that the KDF comments were doing to be the most controversial comments. >> 5.10 ECDH, ECDSA and RSA Computations >> >> ... >> [ I do not understand why we would want to go forward with >> the "identity" >> KDF when we know that NIST SP 800-56 will require a real KDF. Since >> this document already has so many dependencies on X9.62 and X9.63, >> it seems quite reasonable to use the X9.63 KDF. ] > >SBW> There was quite a long discussion among the authors on the subject of >KDFs a while back. My recollection ... the "identity" KDF is applied here, >then the TLS KDF is applied to the premaster secret as usual. NIST 800-56 >includes the TLS KDF and allows its use for TLS, so we should be in >compliance. (Of course in practice this will depend on the precise wording >of the final version of 800-56.) Good point, but there is clearly an intent to include support for the TLS KDF in the NIST SP 800-56. >SBW> The alternative would be to use the X9.63 KDF here, then the TLS KDF >on the premaster secret. Using two distinct KDFs seems undesirable ... two >potential sources of security problems rather than one, two things that >may need to be negotiated rather than one, etc ... Especially when the >X9.63 KDF and the 800-56 KDF are likely to be different. We may need to come back to this point, I suspect that it is dependent on the resolution to the next, possibly bigger, point. >> [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two >> specifications are not compatible in some significant ways. By this, >> I mean that a subroutine cannot be written that works with both this >> document and with RFC 3278. To me, this would be highly desirable. >> One glaring difference is the support for UserKeyingMaterial (or UKM) >> that is provided by the originator (the client in this context). The >> UKM and the ECDH shared secret are both inputs to the KDF. ] > >SBW> Both documents use the same ECDH primitive but different KDFs. This >is a very common situation, isn't it? You can use a single subroutine for >both if your subroutine only does the Z computation, or takes the KDF as a >parameter. I agree that the computation of Z is the same. If you consider the KDF to be a selectable parameter, the the inputs still do not line up. Maybe I am missing something. Here is how I am interpreting your comment: RFC 3278: 1) Use ECDH to compute the shared secret Z. 2) Compute KEK using a KDF with the following inputs: a) Z b) KEK algorithm identifier and key size c) UserKeyingMaterial TLS-ECC Draft: 1) Use ECDH to compute the shared secret Z. 2) Compute KEK using the identity KDF one input: Z So, I continue to be confused about the API. It does not look to me like the same API can be used for ECDH_Key_Agreement() in these two cases. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Oct 30 00:47:36 2005 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 1EW56V-0004mp-SD; Sun, 30 Oct 2005 00:47:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW56S-0004mk-49 for tls@megatron.ietf.org; Sun, 30 Oct 2005 00:47:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13739 for ; Sun, 30 Oct 2005 00:47:14 -0400 (EDT) Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW5KM-0001f5-4v for tls@ietf.org; Sun, 30 Oct 2005 01:01:54 -0400 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.55.50] (helo=tau.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1EW56L12le-00070C; Sun, 30 Oct 2005 05:47:25 +0100 Received: by tau.local (Postfix, from userid 500) id E121B2F234; Sat, 29 Oct 2005 22:46:33 -0600 (MDT) Date: Sat, 29 Oct 2005 22:46:33 -0600 From: Bodo Moeller To: Russ Housley Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 Message-ID: <20051030044633.GA12388@tau.local> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Sat, Oct 29, 2005 at 04:41:04PM -0400, Russ Housley wrote: >>> [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two >>> specifications are not compatible in some significant ways. By this, >>> I mean that a subroutine cannot be written that works with both this >>> document and with RFC 3278. To me, this would be highly desirable. >>> One glaring difference is the support for UserKeyingMaterial (or UKM) >>> that is provided by the originator (the client in this context). The >>> UKM and the ECDH shared secret are both inputs to the KDF. ] >> SBW> Both documents use the same ECDH primitive but different KDFs. This >> is a very common situation, isn't it? You can use a single subroutine for >> both if your subroutine only does the Z computation, or takes the KDF as a >> parameter. > I agree that the computation of Z is the same. If you consider the KDF to > be a selectable parameter, the the inputs still do not line up. Maybe I > am missing something. Here is how I am interpreting your comment: > > RFC 3278: > > 1) Use ECDH to compute the shared secret Z. > > 2) Compute KEK using a KDF with the following inputs: > a) Z > b) KEK algorithm identifier and key size > c) UserKeyingMaterial > > TLS-ECC Draft: > > 1) Use ECDH to compute the shared secret Z. > > 2) Compute KEK using the identity KDF one input: Z > > So, I continue to be confused about the API. It does not look to me > like the same API can be used for ECDH_Key_Agreement() in these two > cases. TLS has no need for something like the UserKeyingMaterial in CMS since TLS always includes client and server nonces in the hash computation that obtains the master secret from the premaster secret. When using an API designed for the CMS case *with* these additional parameters (where the result is supposed to be a key-encryption key, KEK), you'd just not use them for the TLS case -- i.e. write NULL or an appropriate equivalent. TLS does not need such parameters and has no input to provide for them. So the TLS case of ECDH_Key_Agreement() presumably would fail if any UserKeyingMaterial *is* provided, since this would indicate a programming error. The inputs don't line up, but they don't have to. Note that the ECDH computations in the TLS-ECC draft are modelled quite closely after the standard DH computations in TLS. This delivers what TLS needs in a straightforward way and avoids unnecessary protocol complexity. There is no reason to do ECDH fundamentally different from DH -- and there certainly is no reason to make the *differences* between ECDH in CMS and ECDH in TLS fundamentally different from those between DH in CMS and DH in TLS. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 31 11:27:30 2005 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 1EWcVO-0006mv-L2; Mon, 31 Oct 2005 11:27:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWcVL-0006mn-I0 for tls@megatron.ietf.org; Mon, 31 Oct 2005 11:27:29 -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 LAA18640 for ; Mon, 31 Oct 2005 11:27:07 -0500 (EST) Received: from 209-204-118-122.sniparpa.net ([209.204.118.122] helo=bcisse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcjY-0005Rm-TN for tls@ietf.org; Mon, 31 Oct 2005 11:42:09 -0500 Received: from simon (toronto-HSE-ppp4163170.sympatico.ca [70.51.153.50]) by bcisse.com; Mon, 31 Oct 2005 11:26:01 -0500 From: "Simon Blake-Wilson" To: "'Russ Housley'" , Subject: RE: [TLS] AD comments on draft-ietf-tls-ecc-11 Date: Mon, 31 Oct 2005 11:25:59 -0500 Message-ID: <006001c5de37$c882f3c0$0200a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959600102==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1959600102== Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_005C_01C5DE0D.DBF7FA10"; protocol="application/x-pkcs7-signature" This is a multi-part message in MIME format. ------=_NextPart_000_005C_01C5DE0D.DBF7FA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Russ, Thanks for the feedback. Just to add to Bodo's response on what seems like the remaining point of contention ... > >> [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two > >> specifications are not compatible in some significant > ways. By this, > >> I mean that a subroutine cannot be written that works > with both this > >> document and with RFC 3278. To me, this would be > highly desirable. > >> One glaring difference is the support for > UserKeyingMaterial (or UKM) > >> that is provided by the originator (the client in this > context). The > >> UKM and the ECDH shared secret are both inputs to the KDF. ] > > > >SBW> Both documents use the same ECDH primitive but > different KDFs. This >is a very common situation, isn't it? > You can use a single subroutine for >both if your subroutine > only does the Z computation, or takes the KDF as a >parameter. > > I agree that the computation of Z is the same. If you > consider the KDF to be a selectable parameter, the the inputs > still do not line up. Maybe I am missing something. Here is > how I am interpreting your comment: > > RFC 3278: > > 1) Use ECDH to compute the shared secret Z. > > 2) Compute KEK using a KDF with the following inputs: > a) Z > b) KEK algorithm identifier and key size > c) UserKeyingMaterial > > TLS-ECC Draft: > > 1) Use ECDH to compute the shared secret Z. > > 2) Compute KEK using the identity KDF one input: Z > > So, I continue to be confused about the API. It does not > look to me like the same API can be used for > ECDH_Key_Agreement() in these two cases. I don't see a problem here. The interface can take additional inputs dependent on the value of the KDF type. What am I missing?! In fact I think this is exactly how PKCS11 handles ECDH ... See Sections 12.3.8 and 12.3.9 of PKCS11 v2.20. I also think there are more complex ways as well. For example you might want to pass the NIST KDF input in pieces, with one piece for each ID, one piece for AlgID, etc. This way the function could handle the NIST encoding rules, and more easily enforce the various NIST rules concerning MUST include the identities, etc. And of course a library could choose to make the TLS KDF another option, in which case you'd it would handle the key agreement and getting from the premaster secret to the master secret in one go. Then the function would need the other info that helps get the master secret passed in as one or more auxiliary inputs as well. So I suspect a comprensive ECDH function will need to allow at least the following KDFs: - NULL - X9.63 - NIST And possibly TLS and IPSec as well. Or choose to support only NULL and treat the KDF as a separate step. (Which I suspect the NIST document may disapprove of since it makes it more likely that an attacker will somehow get hold of Z itself which may lead to additional attacks.) Best regards. Simon ------=_NextPart_000_005C_01C5DE0D.DBF7FA10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6DCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggNiMIICy6ADAgECAhAL2gsXwT+JjqsJdHq0zi4zMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIy MzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+Hthzj zMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo4GwMIGtMA8GA1UdEwQIMAYBAf8CAQAw RwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29t L3BjYTEuY3JsMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYwDQYJKoZIhvcNAQECBQAD gYEAAn2eb0VLOKC43ulTZCG85Ewrjx7+kkCs2Ao5aqEyISwHm6tZ/tJiGn1VOLA3c9z0B2ZjYr3h U3BSh+eo2FLpWy2q4d7PrDFU1IsZyNgjqO8EKzJ9LBgcyHyJqC538kTRZQpNdLXu0xuSc3QuiTs1 E3LnQDGa07LEq+dWvovj+xUwggQ9MIIDpqADAgECAhA22vJQKV5JPY1TSL01WJuyMA0GCSqGSIb3 DQEBBQUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJ bmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA1MDIxMDAwMDAw MFoXDTA2MDIyNDIzNTk1OVowggEdMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTQwMgYDVQQLEytEaWdpdGFsIElEIENsYXNzIDEgLSBNaWNyb3NvZnQgRnVs bCBTZXJ2aWNlMRswGQYDVQQDFBJTaW1vbiBCbGFrZS1XaWxzb24xJjAkBgkqhkiG9w0BCQEWF3Ni bGFrZXdpbHNvbkBiY2lzc2UuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDN6+R2i/J/ txDR7EcMMo43UUJ8fcKREr4helpUy0hhHDWYVsX6UQuhocexOVyUyg0vCsYJGJOj+QMLDSwH1Xw5 8DuRyIFK8XkNcOTCxQ1xdPtnD91x29s8MVRLlkUp9+0v1y4D9Gzl/TL1ZyhvMbRwtHMWrkIZBaat qwORMHQehQIDAQABo4HLMIHIMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcN AQEFBQADgYEAipzxjTv6HdVgTktxvwN2jeI05aKsWuAjnJG3sdEY+jEiznR881t/YJOVWJJ4g8QG 8dISKvQALdH+1f0hIwFgBwVQ9qQhoVkOjU94Ypio5F1CAWdaIE9gB6BceZLsc8GOC6g7UJQ2lZDr BwoMaYSJ4XA7FWFwEUSNNhuUk9BLmNIxggQ+MIIEOgIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNv bmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAJBgUrDgMCGgUAoIICsjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTEwMzExNjI1NTVaMCMGCSqGSIb3 DQEJBDEWBBR2p3us7+/MkSStcBo0tXNYH6FHhDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgI0iJ1kVlNlF9HD70PcSDDkE/NG2shT3r1xjRIgiuv2BrSLgrxpeuSUc +nwdSVwaKchbonF+BghKldiHor9sWd/L8DraxDlsBrKYcI5yecIeQELcd7BeapPktxXMTUZXFJYf izF1Qr2REw/pztRzF70vf+E0PfExiOfSkxSUadYIAAAAAAAA ------=_NextPart_000_005C_01C5DE0D.DBF7FA10-- --===============1959600102== 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 --===============1959600102==--