From tls-bounces@lists.ietf.org Tue Aug 02 10:21:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxdj-000748-V3; Tue, 02 Aug 2005 10:21:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzxdi-00073t-Sm for tls@megatron.ietf.org; Tue, 02 Aug 2005 10:21:07 -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 KAA22738 for ; Tue, 2 Aug 2005 10:21:04 -0400 (EDT) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Dzxdg-0004AE-LO; Tue, 02 Aug 2005 10:21:04 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 02 Aug 2005 10:21:04 -0400 Cc: Internet Architecture Board , tls mailing list , RFC Editor Subject: [TLS] Protocol Action: 'The TLS Protocol Version 1.1' 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: - 'The TLS Protocol Version 1.1 ' 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-rfc2246-bis-13.txt Technical Summary The Transport Layer Security (TLS) protocol provides secure communications for connection-oriented data. A large number of network protocols operate over TCP or other connection oriented transports. TLS provides a generic security layer which allows these protocols to treat a connection as an authenticated, confidential channel. TLS 1.0 and it's predecessor SSL are widely deployed. TLS 1.1 is an update to TLS 1.0 which clarifies some issues and fixes some known security problems. Working Group Summary This document is a fairly minor update to TLS 1.0. There are only a few technical changes, and they were fairly noncontroversial. No important unresolved issues were raised in Working Group Last Call. Protocol Quality TLS 1.0 is very widely deployed. GnuTLS claims to support TLS 1.1. Some of the changes in TLS 1.0 (reducing the number of different alert types sent) are implemented in standard TLS 1.0 implementations as well. The remaining changes to make TLS 1.1 (the explicit IV) are very minor and have already been implemented in OpenSSL in the context of DTLS, though not TLS. 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 Tue Aug 02 16:02:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02yJ-000180-Op; Tue, 02 Aug 2005 16:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02yH-00017u-KA for tls@megatron.ietf.org; Tue, 02 Aug 2005 16:02:41 -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 QAA14851 for ; Tue, 2 Aug 2005 16:02:39 -0400 (EDT) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 96B44100B4 for ; Tue, 2 Aug 2005 16:02: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 00343-17 for ; Tue, 2 Aug 2005 16:02:08 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 54A63100D9 for ; Tue, 2 Aug 2005 16:02:07 -0400 (EDT) From: Mitchell Blaser To: tls@ietf.org Message-ID: Date: Tue, 2 Aug 2005 16:01:22 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 08/02/2005 04:01:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: Subject: [TLS] Mitch Blaser is out of the office. X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 will be out of the office starting 07/28/2005 and will not return until 08/08/2005. I will respond to your message when I return. - Mitch _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Aug 16 09:30:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51WV-0006F6-UX; Tue, 16 Aug 2005 09:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51WH-0006EA-5y for tls@megatron.ietf.org; Tue, 16 Aug 2005 09:30:21 -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 JAA10579 for ; Tue, 16 Aug 2005 09:30:19 -0400 (EDT) Received: from tomts40.bellnexxia.net ([209.226.175.97] helo=tomts40-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E525Z-00013L-Uy for tls@ietf.org; Tue, 16 Aug 2005 10:06:52 -0400 Received: from simon ([70.51.140.167]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050816133005.QMOQ1799.tomts40-srv.bellnexxia.net@simon> for ; Tue, 16 Aug 2005 09:30:05 -0400 From: "Simon Blake-Wilson" To: Subject: RE: [TLS] Cipher-suite specific extensions Date: Tue, 16 Aug 2005 09:30:04 -0400 Message-ID: <012101c5a266$9c6907a0$af00a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <05d801c58d6d$36c3f210$3200a8c0@simon> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 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="===============1556170233==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1556170233== Content-Type: multipart/signed; boundary="----=_NextPart_000_011C_01C5A245.152C8710"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C5A245.152C8710 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi folks, There's been very little feedback on the proposal I sent out suggesting syntax for cipher suite specific extensions. Can I take this as meaning that not many people care and we can move forward with the TLS extensions and ECC documents as they are, deferring this issue to future I-Ds? If not, please respond stating that you like my proposal, or providing specific text for a counter proposal. Best regards. simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Simon Blake-Wilson > Sent: Wednesday, July 20, 2005 4:54 PM > To: tls@ietf.org > Subject: RE: [TLS] Cipher-suite specific extensions > > > > Hi folks, > > I thought it might be worth considering how much of a change > to RFC 3456-bis would be required in order to specific a > framework for cipher suite specific extensions. The text > below is an off-the-top-of-my-head attempt at some text > aiming to introduce support with minimal changes. > > Any thoughts on whether the text below would be sufficient > (or whether I'm totally missing the point) would be much > appreciated. It seems to me that if the approach is > sufficient then it could be added quickly to RFC 3456-bis. > (And if this is all that has to be done to 3456-bis to close > this discussion and move forward then I can live with it!) > > Best regards. Simon > > Insert into 3456-bis in Section 2.3 below the definition of > "Extension": > > ""extension_data" may contain any information pertinent to > the extension using any syntax. All the extensions defined in > this document apply generically to all cipher suites, but > future extensions may be "cipher suite dependent" - i.e. the > options negotiated may differ depending on the selected > cipher suite. For such cipher suite specific extensions, > "extension_data" SHOULD contain "CSSpecificExtension" defined > as follows: > > struct { > CipherSuite cipher_suites<2...2^16-1>; > opaque cs_specific_extension_data<0...2^16-1> > } CSSpecificExtensionInfo ; > > struct { > CSSpecificExtensionInfo cs_specific_extension_info_list<1...2^16-1> > } CSSpecificExtension ; > > Where: > > - "cipher_suites" identifies a list of cipher suites. > > - "cs_specific_extension_data" contains extension specific > information pertinent to the preceding list of cipher suites. > > Note that the set of cipher suites in any cipher suite > specific extension may be different from the list of cipher > suites in the client hello. This allows, for example, the > extension to take a fixed value regardless of which cipher > suites are being requested by the client." > > > -----Original Message----- > > From: tls-bounces@lists.ietf.org > > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Nicko van Someren > > Sent: Wednesday, July 13, 2005 11:51 AM > > To: tls@ietf.org > > Subject: [TLS] (no subject) > > > > > > On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote: > > > > > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: > > > > > > >>> I have argued for a general mechanism for > ciphersuite-dependent > > > TLS > > > >>> extensions in the past. That is, instead of having individual > > > >>> specifications defining TLS extensions provide means of > > > restricting > > > >>> certain extensions to certain ciphersuites, it would > > make sense to > > > >>> have a mechanism that can be applied to all extensions, > > preferably > > > >>> defined in the successor of RFC 3456. > > > > > > >> This is a big change and I don't want to make this a gating > > > factor for > > > >> advancing the ECC draft. > > > >> > > > >> WG members: I'd like to come to some resolution on the basic > > > issue of > > > >> whether curves should be negotiable on a > > per-cipher-suite basis. My > > > >> intuition is that the case Ari mentions is kind of a corner > > > >> case--most SSL/TLS implementations aren't assembled pluggably > > > like this. > > > >> But, I'm happy to listen to arguments that I'm wrong here... > > > > > > > I agree that relying on a general purpose mech. to be > > defined in the > > > > successor of RFC 3456 may introduce a long delay before the ECC > > > draft is > > > > finalized into an RFC. However, allowing third parties to plug > > > in their > > > > cipher suites is an important scenario as it facilitates > > security > > > > vendors to provide a significant value add (in terms of perf. + > > > cipher > > > > suites that adhere to local crypto standards). > > > > > > > > It is possible to address the cipher suite/curve > mapping directly > > > in the > > > > ECC draft (without dependencies on a general purpose mech) as I > > > > suggested in the earlier msg. > > > > > > I think doing this directly in the TLS-ECC specification > is not the > > > best option because > > > > > > - this would mean reinventing the wheel when other > ciphersuites need > > > similar mechanisms, adding some complexity to each of > the affected > > > specifications individually; and > > > > > > - it already fails to take into account trusted_ca_keys (an > > extension > > > defined in RFC 3456, which appears destined for ciphersuite- > > > dependent > > > use in the context of plug-ins). > > > > > > Let me point out that one alternative for how to proceed > is to pass > > > the TLS Extensions and TLS-ECC specifications without > > provisions for > > > ciphersuite-dependent negotiation, but standardize a TLS > > extension for > > > ciphersuite-dependent TLS extensions later in a separate document > > > ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't be made a > > > "MUST" then, so for best interoperability > ciphersuite-dependent TLS > > > extensions could be defined so as to allow them to extend > > the list of > > > ciphersuites given in the "cipher_suites filed" of the > Client Hello > > > message -- i.e., clients can make ciphersuites invisible > > from servers > > > that do not support TLS-CD-Ext. > > > > > > This will keep the basic protocols simple, but optionally > > provide the > > > desired flexibility. At first, while TLS-CD-Ext is used > > only in the > > > context of TLS-ECC, the implementation overhead might be slightly > > > higher for putting this directly into the TLS-ECC > > specification (which > > > would, however, omit ciphersuite-dependent use of the > > trusted_ca_keys > > > extension); but as soon as some other set of ciphersuites > > has use for > > > TLS-CD-Ext, this more general approach should become easier > > to handle. > > > > Sorry arrive late on this one but I've been having ongoing trouble > > getting messages through to this list. Hopefully this > message will > > make it. Here's a repeat of what I tried to send before: > > > > As a vendor of widely used hardware for handling the crypto in TLS > > session negotiations I would like to lend my support for > Ari's model > > of being able to specify specific extensions on specific cipher > > suits, and in particular specifying different ECC curves on > > different > > suits. While this seems like unnecessary complication it actually > > saves implementers from much worse complication if you do it the > > other way. Here's why: > > > > When implementing crypto in hardware, and in particular when > > implementing ECC, it is common for various types of > hardware to have > > quite rigid limitations regarding the curve parameters. It > is also > > the case that software implementations of ECC often have > limitations > > due to the patent minefield in this space. This will be worst on > > hardware like ECC smartcards being used for client > > authentication but > > is also the case even on big, fast ECC chips from Motorola or > > software libraries which have been carefully constructed to skirt > > around IP issues. Due to the fragmented nature of the ECC market > > different types of hardware and software will have different > > limitations; some hardware might support MQV because it has a > > Certicom patent license but only work on binary curves > (because they > > are easy in hardware) while the software "fall-back" for > > prime curves > > might not support MQV at all because it lacks a license. > So we are > > in a situation where the intersection of supported > parameters across > > the whole set of cipher suites ends up being the empty set > > and we are > > stuck. > > > > Eric said "My intuition is that the case Ari mentions is kind of a > > corner case--most SSL/TLS implementations aren't assembled > pluggably > > like this. But, I'm happy to listen to arguments that I'm wrong > > here...". My feeling, from dealing with a great many SSL > > implementations, is that they very much are modular in > nature, or at > > least their owners would like them to be :-) and that pluggable > > crypto is very important. Certainly the vast majority of > SSL stacks > > that support hardware support it through some plug-in > mechanism and > > while I expect it is rare for any individual system to have > > more than > > one type of hardware plugged in at a time it is quite > frequently the > > case that there will be a hardware implementation and a software > > implementation operating side by side and, for the reasons > outlined > > above, this will potentially be an issue. > > > > Anyway, that's my 2p (or 3.53 cents :-) worth! > > > > Cheers, > > Nicko van Someren > > CTO, nCipher Plc. > > > > > > _______________________________________________ > > 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 > ------=_NextPart_000_011C_01C5A245.152C8710 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MTYxMzMwMDRaMCMGCSqGSIb3 DQEJBDEWBBRQHRmugimkwKTgbcUM2CdSs6xr+TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgF3wd8xMZ9B0CwHyYbr4cQSOGcmVxuK51v+Vs+BXgUDfiL5pnz2suDn2 defajcSwYipToJNjYk4lEsgORptQGAk3Fnl+l69OLms6LWpBZVmL3zjPPOzbTKpDwf7nUrQfgMJI NcxJnM1Jv1OwjFpt/xAACnLsp+cJFPalCCgQPOjxAAAAAAAA ------=_NextPart_000_011C_01C5A245.152C8710-- --===============1556170233== 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 --===============1556170233==-- From tls-bounces@lists.ietf.org Tue Aug 16 12:02:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53tu-0000Nd-G0; Tue, 16 Aug 2005 12:02:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53tt-0000NK-Hg for tls@megatron.ietf.org; Tue, 16 Aug 2005 12:02: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 MAA19808 for ; Tue, 16 Aug 2005 12:02:50 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54TF-00056f-Vs for tls@ietf.org; Tue, 16 Aug 2005 12:39:26 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 09:02:40 -0700 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 09:02:40 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 09:02:40 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 09:02:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Cipher-suite specific extensions Date: Tue, 16 Aug 2005 09:02:38 -0700 Message-ID: Thread-Topic: [TLS] Cipher-suite specific extensions thread-index: AcWiZuHYSNYAIhaPSJGRc4146sTGFgAFFePg From: "Ari Medvinsky" To: "Simon Blake-Wilson" , X-OriginalArrivalTime: 16 Aug 2005 16:02:40.0300 (UTC) FILETIME=[EDBA16C0:01C5A27B] X-Spam-Score: 2.0 (++) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Content-Transfer-Encoding: quoted-printable 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 like your proposal, I think it makes sense. Are you planning to add text to the ECC draft to state that the new ECC specific extension can be sent across using the mech. below? Thanks, Ari Medvinsky Program Manager=20 Windows Security -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Simon Blake-Wilson Sent: Tuesday, August 16, 2005 6:30 AM To: tls@ietf.org Subject: RE: [TLS] Cipher-suite specific extensions Hi folks, There's been very little feedback on the proposal I sent out suggesting syntax for cipher suite specific extensions. Can I take this as meaning that not many people care and we can move forward with the TLS extensions and ECC documents as they are, deferring this issue to future I-Ds? If not, please respond stating that you like my proposal, or providing specific text for a counter proposal. Best regards. simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Simon Blake-Wilson > Sent: Wednesday, July 20, 2005 4:54 PM > To: tls@ietf.org > Subject: RE: [TLS] Cipher-suite specific extensions >=20 >=20 >=20 > Hi folks, >=20 > I thought it might be worth considering how much of a change to RFC=20 > 3456-bis would be required in order to specific a framework for cipher > suite specific extensions. The text below is an off-the-top-of-my-head > attempt at some text aiming to introduce support with minimal changes. >=20 > Any thoughts on whether the text below would be sufficient (or whether > I'm totally missing the point) would be much appreciated. It seems to=20 > me that if the approach is sufficient then it could be added quickly=20 > to RFC 3456-bis. > (And if this is all that has to be done to 3456-bis to close this=20 > discussion and move forward then I can live with it!) >=20 > Best regards. Simon >=20 > Insert into 3456-bis in Section 2.3 below the definition of > "Extension": >=20 > ""extension_data" may contain any information pertinent to the=20 > extension using any syntax. All the extensions defined in this=20 > document apply generically to all cipher suites, but future extensions > may be "cipher suite dependent" - i.e. the options negotiated may=20 > differ depending on the selected cipher suite. For such cipher suite=20 > specific extensions, "extension_data" SHOULD contain=20 > "CSSpecificExtension" defined as follows: >=20 > struct { > CipherSuite cipher_suites<2...2^16-1>; > opaque cs_specific_extension_data<0...2^16-1> > } CSSpecificExtensionInfo ; >=20 > struct { > CSSpecificExtensionInfo cs_specific_extension_info_list<1...2^16-1> > } CSSpecificExtension ; >=20 > Where: >=20 > - "cipher_suites" identifies a list of cipher suites. >=20 > - "cs_specific_extension_data" contains extension specific information > pertinent to the preceding list of cipher suites. >=20 > Note that the set of cipher suites in any cipher suite specific=20 > extension may be different from the list of cipher suites in the=20 > client hello. This allows, for example, the extension to take a fixed=20 > value regardless of which cipher suites are being requested by the=20 > client." >=20 > > -----Original Message----- > > From: tls-bounces@lists.ietf.org > > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Nicko van Someren > > Sent: Wednesday, July 13, 2005 11:51 AM > > To: tls@ietf.org > > Subject: [TLS] (no subject) > >=20 > >=20 > > On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote: > >=20 > > > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: > > > > > > >>> I have argued for a general mechanism for > ciphersuite-dependent > > > TLS > > > >>> extensions in the past. That is, instead of having individual > > > >>> specifications defining TLS extensions provide means of > > > restricting > > > >>> certain extensions to certain ciphersuites, it would > > make sense to > > > >>> have a mechanism that can be applied to all extensions, > > preferably > > > >>> defined in the successor of RFC 3456. > > > > > > >> This is a big change and I don't want to make this a gating > > > factor for > > > >> advancing the ECC draft. > > > >> > > > >> WG members: I'd like to come to some resolution on the basic > > > issue of > > > >> whether curves should be negotiable on a > > per-cipher-suite basis. My > > > >> intuition is that the case Ari mentions is kind of a corner=20 > > > >> case--most SSL/TLS implementations aren't assembled pluggably > > > like this. > > > >> But, I'm happy to listen to arguments that I'm wrong here... > > > > > > > I agree that relying on a general purpose mech. to be > > defined in the > > > > successor of RFC 3456 may introduce a long delay before the ECC > > > draft is > > > > finalized into an RFC. However, allowing third parties to plug > > > in their > > > > cipher suites is an important scenario as it facilitates > > security > > > > vendors to provide a significant value add (in terms of perf. + > > > cipher > > > > suites that adhere to local crypto standards). > > > > > > > > It is possible to address the cipher suite/curve > mapping directly > > > in the > > > > ECC draft (without dependencies on a general purpose mech) as I=20 > > > > suggested in the earlier msg. > > > > > > I think doing this directly in the TLS-ECC specification > is not the > > > best option because > > > > > > - this would mean reinventing the wheel when other > ciphersuites need > > > similar mechanisms, adding some complexity to each of > the affected > > > specifications individually; and > > > > > > - it already fails to take into account trusted_ca_keys (an > > extension > > > defined in RFC 3456, which appears destined for ciphersuite-=20 > > > dependent > > > use in the context of plug-ins). > > > > > > Let me point out that one alternative for how to proceed > is to pass > > > the TLS Extensions and TLS-ECC specifications without > > provisions for > > > ciphersuite-dependent negotiation, but standardize a TLS > > extension for > > > ciphersuite-dependent TLS extensions later in a separate document=20 > > > ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't be made a=20 > > > "MUST" then, so for best interoperability > ciphersuite-dependent TLS > > > extensions could be defined so as to allow them to extend > > the list of > > > ciphersuites given in the "cipher_suites filed" of the > Client Hello > > > message -- i.e., clients can make ciphersuites invisible > > from servers > > > that do not support TLS-CD-Ext. > > > > > > This will keep the basic protocols simple, but optionally > > provide the > > > desired flexibility. At first, while TLS-CD-Ext is used > > only in the > > > context of TLS-ECC, the implementation overhead might be slightly=20 > > > higher for putting this directly into the TLS-ECC > > specification (which > > > would, however, omit ciphersuite-dependent use of the > > trusted_ca_keys > > > extension); but as soon as some other set of ciphersuites > > has use for > > > TLS-CD-Ext, this more general approach should become easier > > to handle. > >=20 > > Sorry arrive late on this one but I've been having ongoing trouble=20 > > getting messages through to this list. Hopefully this > message will > > make it. Here's a repeat of what I tried to send before: > >=20 > > As a vendor of widely used hardware for handling the crypto in TLS=20 > > session negotiations I would like to lend my support for > Ari's model > > of being able to specify specific extensions on specific cipher=20 > > suits, and in particular specifying different ECC curves on=20 > > different suits. While this seems like unnecessary complication it=20 > > actually saves implementers from much worse complication if you do=20 > > it the other way. Here's why: > >=20 > > When implementing crypto in hardware, and in particular when=20 > > implementing ECC, it is common for various types of > hardware to have > > quite rigid limitations regarding the curve parameters. It > is also > > the case that software implementations of ECC often have > limitations > > due to the patent minefield in this space. This will be worst on=20 > > hardware like ECC smartcards being used for client authentication=20 > > but is also the case even on big, fast ECC chips from Motorola or=20 > > software libraries which have been carefully constructed to skirt=20 > > around IP issues. Due to the fragmented nature of the ECC market=20 > > different types of hardware and software will have different=20 > > limitations; some hardware might support MQV because it has a=20 > > Certicom patent license but only work on binary curves > (because they > > are easy in hardware) while the software "fall-back" for prime=20 > > curves might not support MQV at all because it lacks a license. > So we are > > in a situation where the intersection of supported > parameters across > > the whole set of cipher suites ends up being the empty set and we=20 > > are stuck. > >=20 > > Eric said "My intuition is that the case Ari mentions is kind of a=20 > > corner case--most SSL/TLS implementations aren't assembled > pluggably > > like this. But, I'm happy to listen to arguments that I'm wrong=20 > > here...". My feeling, from dealing with a great many SSL=20 > > implementations, is that they very much are modular in > nature, or at > > least their owners would like them to be :-) and that pluggable=20 > > crypto is very important. Certainly the vast majority of > SSL stacks > > that support hardware support it through some plug-in > mechanism and > > while I expect it is rare for any individual system to have more=20 > > than one type of hardware plugged in at a time it is quite > frequently the > > case that there will be a hardware implementation and a software=20 > > implementation operating side by side and, for the reasons > outlined > > above, this will potentially be an issue. > >=20 > > Anyway, that's my 2p (or 3.53 cents :-) worth! > >=20 > > Cheers, > > Nicko van Someren > > CTO, nCipher Plc. > >=20 > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > >=20 >=20 >=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 Aug 16 14:16:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55ul-0007jx-H5; Tue, 16 Aug 2005 14:11:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55uc-0007jf-1a for tls@megatron.ietf.org; Tue, 16 Aug 2005 14:11:49 -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 OAA26455 for ; Tue, 16 Aug 2005 14:11:44 -0400 (EDT) Received: from tomts20-srv.bellnexxia.net ([209.226.175.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56Tz-00009D-RF for tls@ietf.org; Tue, 16 Aug 2005 14:48:20 -0400 Received: from simon ([70.51.151.160]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050816181139.XZI26550.tomts20-srv.bellnexxia.net@simon>; Tue, 16 Aug 2005 14:11:39 -0400 From: "Simon Blake-Wilson" To: "'Ari Medvinsky'" , Subject: RE: [TLS] Cipher-suite specific extensions Date: Tue, 16 Aug 2005 14:11:37 -0400 Message-ID: <019b01c5a28d$f1cc8c90$af00a8c0@simon> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0082393683==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0082393683== Content-Type: multipart/signed; boundary="----=_NextPart_000_0196_01C5A26C.69A4E8B0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0196_01C5A26C.69A4E8B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Ari, Yes, if the text is accepted, I would propose to rework the relevant ECC extensions to use the CS-specific extension format. Best regards. Simon > -----Original Message----- > From: Ari Medvinsky [mailto:arimed@windows.microsoft.com] > Sent: Tuesday, August 16, 2005 12:03 PM > To: Simon Blake-Wilson; tls@ietf.org > Subject: RE: [TLS] Cipher-suite specific extensions > > > > Simon, > > I like your proposal, I think it makes sense. Are you > planning to add text to the ECC draft to state that the new > ECC specific extension can be sent across using the mech. > below? Thanks, > > Ari Medvinsky > Program Manager > Windows Security > > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Simon Blake-Wilson > Sent: Tuesday, August 16, 2005 6:30 AM > To: tls@ietf.org > Subject: RE: [TLS] Cipher-suite specific extensions > > > Hi folks, > > There's been very little feedback on the proposal I sent out > suggesting syntax for cipher suite specific extensions. Can I > take this as meaning that not many people care and we can > move forward with the TLS extensions and ECC documents as > they are, deferring this issue to future I-Ds? If not, please > respond stating that you like my proposal, or providing > specific text for a counter proposal. > > Best regards. simon > > > -----Original Message----- > > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] > > On Behalf Of Simon Blake-Wilson > > Sent: Wednesday, July 20, 2005 4:54 PM > > To: tls@ietf.org > > Subject: RE: [TLS] Cipher-suite specific extensions > > > > > > > > Hi folks, > > > > I thought it might be worth considering how much of a change to RFC > > 3456-bis would be required in order to specific a framework > for cipher > > > suite specific extensions. The text below is an > off-the-top-of-my-head > > > attempt at some text aiming to introduce support with > minimal changes. > > > > Any thoughts on whether the text below would be sufficient > (or whether > > > I'm totally missing the point) would be much appreciated. > It seems to > > me that if the approach is sufficient then it could be > added quickly > > to RFC 3456-bis. > > (And if this is all that has to be done to 3456-bis to close this > > discussion and move forward then I can live with it!) > > > > Best regards. Simon > > > > Insert into 3456-bis in Section 2.3 below the definition of > > "Extension": > > > > ""extension_data" may contain any information pertinent to the > > extension using any syntax. All the extensions defined in this > > document apply generically to all cipher suites, but future > extensions > > > may be "cipher suite dependent" - i.e. the options negotiated may > > differ depending on the selected cipher suite. For such > cipher suite > > specific extensions, "extension_data" SHOULD contain > > "CSSpecificExtension" defined as follows: > > > > struct { > > CipherSuite cipher_suites<2...2^16-1>; > > opaque cs_specific_extension_data<0...2^16-1> > > } CSSpecificExtensionInfo ; > > > > struct { > > CSSpecificExtensionInfo > cs_specific_extension_info_list<1...2^16-1> > > } CSSpecificExtension ; > > > > Where: > > > > - "cipher_suites" identifies a list of cipher suites. > > > > - "cs_specific_extension_data" contains extension specific > information > > > pertinent to the preceding list of cipher suites. > > > > Note that the set of cipher suites in any cipher suite specific > > extension may be different from the list of cipher suites in the > > client hello. This allows, for example, the extension to > take a fixed > > value regardless of which cipher suites are being requested by the > > client." > > > > > -----Original Message----- > > > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] > > > On Behalf Of Nicko van Someren > > > Sent: Wednesday, July 13, 2005 11:51 AM > > > To: tls@ietf.org > > > Subject: [TLS] (no subject) > > > > > > > > > On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote: > > > > > > > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: > > > > > > > > >>> I have argued for a general mechanism for > > ciphersuite-dependent > > > > TLS > > > > >>> extensions in the past. That is, instead of having > individual > > > > > >>> specifications defining TLS extensions provide means of > > > > restricting > > > > >>> certain extensions to certain ciphersuites, it would > > > make sense to > > > > >>> have a mechanism that can be applied to all extensions, > > > preferably > > > > >>> defined in the successor of RFC 3456. > > > > > > > > >> This is a big change and I don't want to make this a gating > > > > factor for > > > > >> advancing the ECC draft. > > > > >> > > > > >> WG members: I'd like to come to some resolution on the basic > > > > issue of > > > > >> whether curves should be negotiable on a > > > per-cipher-suite basis. My > > > > >> intuition is that the case Ari mentions is kind of a corner > > > > >> case--most SSL/TLS implementations aren't assembled pluggably > > > > like this. > > > > >> But, I'm happy to listen to arguments that I'm wrong here... > > > > > > > > > I agree that relying on a general purpose mech. to be > > > defined in the > > > > > successor of RFC 3456 may introduce a long delay > before the ECC > > > > draft is > > > > > finalized into an RFC. However, allowing third > parties to plug > > > > in their > > > > > cipher suites is an important scenario as it facilitates > > > security > > > > > vendors to provide a significant value add (in terms > of perf. + > > > > cipher > > > > > suites that adhere to local crypto standards). > > > > > > > > > > It is possible to address the cipher suite/curve > > mapping directly > > > > in the > > > > > ECC draft (without dependencies on a general purpose > mech) as I > > > > > suggested in the earlier msg. > > > > > > > > I think doing this directly in the TLS-ECC specification > > is not the > > > > best option because > > > > > > > > - this would mean reinventing the wheel when other > > ciphersuites need > > > > similar mechanisms, adding some complexity to each of > > the affected > > > > specifications individually; and > > > > > > > > - it already fails to take into account trusted_ca_keys (an > > > extension > > > > defined in RFC 3456, which appears destined for ciphersuite- > > > > dependent > > > > use in the context of plug-ins). > > > > > > > > Let me point out that one alternative for how to proceed > > is to pass > > > > the TLS Extensions and TLS-ECC specifications without > > > provisions for > > > > ciphersuite-dependent negotiation, but standardize a TLS > > > extension for > > > > ciphersuite-dependent TLS extensions later in a > separate document > > > > ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't > be made a > > > > "MUST" then, so for best interoperability > > ciphersuite-dependent TLS > > > > extensions could be defined so as to allow them to extend > > > the list of > > > > ciphersuites given in the "cipher_suites filed" of the > > Client Hello > > > > message -- i.e., clients can make ciphersuites invisible > > > from servers > > > > that do not support TLS-CD-Ext. > > > > > > > > This will keep the basic protocols simple, but optionally > > > provide the > > > > desired flexibility. At first, while TLS-CD-Ext is used > > > only in the > > > > context of TLS-ECC, the implementation overhead might > be slightly > > > > higher for putting this directly into the TLS-ECC > > > specification (which > > > > would, however, omit ciphersuite-dependent use of the > > > trusted_ca_keys > > > > extension); but as soon as some other set of ciphersuites > > > has use for > > > > TLS-CD-Ext, this more general approach should become easier > > > to handle. > > > > > > Sorry arrive late on this one but I've been having ongoing trouble > > > getting messages through to this list. Hopefully this > > message will > > > make it. Here's a repeat of what I tried to send before: > > > > > > As a vendor of widely used hardware for handling the crypto in TLS > > > session negotiations I would like to lend my support for > > Ari's model > > > of being able to specify specific extensions on specific cipher > > > suits, and in particular specifying different ECC curves on > > > different suits. While this seems like unnecessary > complication it > > > actually saves implementers from much worse complication > if you do > > > it the other way. Here's why: > > > > > > When implementing crypto in hardware, and in particular when > > > implementing ECC, it is common for various types of > > hardware to have > > > quite rigid limitations regarding the curve parameters. It > > is also > > > the case that software implementations of ECC often have > > limitations > > > due to the patent minefield in this space. This will be worst on > > > hardware like ECC smartcards being used for client authentication > > > but is also the case even on big, fast ECC chips from Motorola or > > > software libraries which have been carefully constructed to skirt > > > around IP issues. Due to the fragmented nature of the ECC market > > > different types of hardware and software will have different > > > limitations; some hardware might support MQV because it has a > > > Certicom patent license but only work on binary curves > > (because they > > > are easy in hardware) while the software "fall-back" for prime > > > curves might not support MQV at all because it lacks a license. > > So we are > > > in a situation where the intersection of supported > > parameters across > > > the whole set of cipher suites ends up being the empty set and we > > > are stuck. > > > > > > Eric said "My intuition is that the case Ari mentions is kind of a > > > corner case--most SSL/TLS implementations aren't assembled > > pluggably > > > like this. But, I'm happy to listen to arguments that I'm wrong > > > here...". My feeling, from dealing with a great many SSL > > > implementations, is that they very much are modular in > > nature, or at > > > least their owners would like them to be :-) and that pluggable > > > crypto is very important. Certainly the vast majority of > > SSL stacks > > > that support hardware support it through some plug-in > > mechanism and > > > while I expect it is rare for any individual system to have more > > > than one type of hardware plugged in at a time it is quite > > frequently the > > > case that there will be a hardware implementation and a software > > > implementation operating side by side and, for the reasons > > outlined > > > above, this will potentially be an issue. > > > > > > Anyway, that's my 2p (or 3.53 cents :-) worth! > > > > > > Cheers, > > > Nicko van Someren > > > CTO, nCipher Plc. > > > > > > > > > _______________________________________________ > > > 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 > > > ------=_NextPart_000_0196_01C5A26C.69A4E8B0 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MTYxODExMzZaMCMGCSqGSIb3 DQEJBDEWBBRqsbtMzvFrp7Vw7xWYsjXKJcuPBDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgJrbZEM+xipMgdsgHfRsav2jMaDMRkTKDC6TjhaCoAAlQ+Y1wJOJQ8wS RbTRy8YxxOwhp4YIy8gSh5SEH0CaIcvf5SGsFEWyDYncDQMxfWNgaWYs6YFRSzerwi2rOrTUn/S4 ZAj1LDs+eLVKdQScNYEDlqkQNVulRAkyToswdr0eAAAAAAAA ------=_NextPart_000_0196_01C5A26C.69A4E8B0-- --===============0082393683== 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 --===============0082393683==-- From tls-bounces@lists.ietf.org Fri Aug 19 15:55:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CxW-0004xR-Ox; Fri, 19 Aug 2005 15:55:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6CxW-0004xM-1p for tls@megatron.ietf.org; Fri, 19 Aug 2005 15: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 PAA26353 for ; Fri, 19 Aug 2005 15:55:19 -0400 (EDT) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6DXW-0004aO-2g for tls@ietf.org; Fri, 19 Aug 2005 16:32:35 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id BC02A8A02D for ; Fri, 19 Aug 2005 13:01:29 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Fri, 19 Aug 2005 12:55:01 -0700 From: Eric Rescorla Message-Id: <20050819200129.BC02A8A02D@laser.networkresonance.com> X-Spam-Score: 2.0 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [TLS] AD comments on draft-ietf-tls-rfc3546bis X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 one of the authors please fix this... X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 19 Aug 2005 15:39:11 -0400 To: ekr@networkresonance.com From: Russ Housley Subject: IANA Comments: draft-ietf-tls-rfc3546bis-01.txt Eric: I have been waiting for these Last Call comments from IANA to be addressed. I think that we can generate the information needed to resolve this comment without updating the document. I just put this document on the Telechat agenda for September 1st. If I do not get this information before the telechat, I will enter a DISCUSS to hold the document until I get it. Hopefully, it will be very straightforward, Russ = = = = = = = = = IANA Last Call Comments: Upon approval of this document the IANA will create a new registry for ExtensionType values. It is not clear as to what the initial list of values are (even after looking in section 2.3). Can a list be put in the IANA Consideration section of what to populate the registry with? The IANA will also change the reference for the MIME Media Type pkix-pkipath to be this document. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 22 20:26:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7McV-0008Lp-1p; Mon, 22 Aug 2005 20:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7McU-0008Lk-0g for tls@megatron.ietf.org; Mon, 22 Aug 2005 20:26: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 UAA06622 for ; Mon, 22 Aug 2005 20:26:24 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7McS-0000BJ-H2 for tls@ietf.org; Mon, 22 Aug 2005 20:26:26 -0400 Received: from scholes.stanford.edu (Scholes.Stanford.EDU [171.64.78.72]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j7N0PprE031739 for ; Mon, 22 Aug 2005 17:25:53 -0700 Received: (qmail 28578 invoked by uid 1000); 23 Aug 2005 00:25:14 -0000 To: tls@ietf.org References: <012101c5a266$9c6907a0$af00a8c0@simon> From: Hovav Shacham In-Reply-To: <012101c5a266$9c6907a0$af00a8c0@simon> Date: 22 Aug 2005 17:25:14 -0700 Message-ID: <873bp1sdn9.fsf@scholes.stanford.edu> Lines: 12 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [TLS] Re: Cipher-suite specific extensions X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 Blake-Wilson" writes: > Can I take this as meaning that not many people care and we can move > forward with the TLS extensions and ECC documents as they are, > deferring this issue to future I-Ds? Yes. I support leaving the extensions document as is, without adding ciphersuite-specific extension support. -- Hovav Shacham hovav@hovav.net "Rightly looked at there is no laughable thing under the sun." _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 24 13:31:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z6C-0001ux-Lc; Wed, 24 Aug 2005 13:31:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7z6B-0001up-0D for tls@megatron.ietf.org; Wed, 24 Aug 2005 13:31:39 -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 NAA06985 for ; Wed, 24 Aug 2005 13:31:36 -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 1E7z6W-0000cG-9T for tls@ietf.org; Wed, 24 Aug 2005 13:32:01 -0400 Received: from simon (dns2.ccnwired.com [216.13.13.68]) by bcisse.com; Wed, 24 Aug 2005 13:28:44 -0400 From: "Simon Blake-Wilson" To: Subject: RE: [TLS] Re: Cipher-suite specific extensions Date: Wed, 24 Aug 2005 13:28:43 -0400 Message-ID: <03d701c5a8d1$4737fd10$af00a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 MIME-Version: 1.0 In-Reply-To: <873bp1sdn9.fsf@scholes.stanford.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.0 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2129321832==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2129321832== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03D2_01C5A8AF.BF25B5F0" This is a multi-part message in MIME format. ------=_NextPart_000_03D2_01C5A8AF.BF25B5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, By my count the results of my informal poll on whether people support adding cipher-suite specific extensions to the TLS extensions and ECC in TLS docs are currently 1-1. I don't think that shows sufficient support for making the changes to add cipher-suite specific support so unless more people speak up I suggest we move forward with the two documents without cipher-suite specific extension support. Note that this certainly does not exclude someone putting out a new I-D specifying syntax for cipher-suite specific extensions to use to populate extension data, as well as new extension types for cipher-suite specific versions of existing extensions and/or new cipher-suite specific extensions. Any comments? Best regards. Simon > -----Original Message----- > From: tls-bounces@lists.ietf.org > [mailto:tls-bounces@lists.ietf.org] On Behalf Of Hovav Shacham > Sent: Monday, August 22, 2005 8:25 PM > To: tls@ietf.org > Subject: [TLS] Re: Cipher-suite specific extensions > > > "Simon Blake-Wilson" writes: > > > Can I take this as meaning that not many people care and we > can move > > forward with the TLS extensions and ECC documents as they are, > > deferring this issue to future I-Ds? > > Yes. I support leaving the extensions document as is, > without adding ciphersuite-specific extension support. > > -- > Hovav Shacham hovav@hovav.net > "Rightly looked at there is no laughable thing under the sun." > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > ------=_NextPart_000_03D2_01C5A8AF.BF25B5F0 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MjQxNzI4NDJaMCMGCSqGSIb3 DQEJBDEWBBTsQTVpJavLfmnxHfyUDuLmR7AKUDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgKzcjTFxAxq4kW3dQ9FQiJH0kwbn80tm5Yv8oMCR7QTmW6Gh5Rm4yzhM f7dvWKQT8xj1tmfG4mqhx5dS3GNtdxMvwn7V4JZEuYaIFZG1Rs4P3ncYKlrnNAa8b4AEXOuMwcaz FQmvgB40RxZHAZZzHx9XJask+Ozl1qN96TT9+XFHAAAAAAAA ------=_NextPart_000_03D2_01C5A8AF.BF25B5F0-- --===============2129321832== 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 --===============2129321832==-- From tls-bounces@lists.ietf.org Wed Aug 24 13:41:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zFp-0004sU-HW; Wed, 24 Aug 2005 13:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zFo-0004sO-DC for tls@megatron.ietf.org; Wed, 24 Aug 2005 13:41:36 -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 NAA07404 for ; Wed, 24 Aug 2005 13:41:35 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zG9-0000uE-OF for tls@ietf.org; Wed, 24 Aug 2005 13:41:59 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 13DAC1706B; Wed, 24 Aug 2005 10:42:56 -0700 (PDT) To: "Simon Blake-Wilson" Subject: Re: [TLS] Re: Cipher-suite specific extensions References: <03d701c5a8d1$4737fd10$af00a8c0@simon> From: Eric Rescorla Date: Wed, 24 Aug 2005 10:42:56 -0700 In-Reply-To: <03d701c5a8d1$4737fd10$af00a8c0@simon> (Simon Blake-Wilson's message of "Wed, 24 Aug 2005 13:28:43 -0400") Message-ID: <86u0hf44f3.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: 7655788c23eb79e336f5f8ba8bce7906 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 "Simon Blake-Wilson" writes: > Hi folks, > > By my count the results of my informal poll on whether people support > adding cipher-suite specific extensions to the TLS extensions and ECC in > TLS docs are currently 1-1. > > I don't think that shows sufficient support for making the changes to add > cipher-suite specific support so unless more people speak up I suggest we > move forward with the two documents without cipher-suite specific > extension support. This is my assessment as well. As I understand the situation, we're ready to forward this document to the IESG at this point. Simon, do you have anything else to do before you're ready for that? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 24 13:46:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zKk-00076D-Hk; Wed, 24 Aug 2005 13:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zKi-00073n-PF for tls@megatron.ietf.org; Wed, 24 Aug 2005 13:46: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 NAA07985 for ; Wed, 24 Aug 2005 13:46:39 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zL4-0001BK-QB for tls@ietf.org; Wed, 24 Aug 2005 13:47:03 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:46:30 -0700 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:46:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:46:29 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:46:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Cipher-suite specific extensions Date: Wed, 24 Aug 2005 10:46:14 -0700 Message-ID: Thread-Topic: [TLS] Re: Cipher-suite specific extensions thread-index: AcWo0xcp5ZKmC3xsRragIyYqBIM8UAAAH5ow From: "Ari Medvinsky" To: "EKR" , "Simon Blake-Wilson" , "Nicko van Someren" X-OriginalArrivalTime: 24 Aug 2005 17:46:15.0803 (UTC) FILETIME=[B9C294B0:01C5A8D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Actually it is not 1-1 it is 2-1 in favor of modifying the draft. Nicko from Ncipher agreed with my position.=20 -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Eric Rescorla Sent: Wednesday, August 24, 2005 10:43 AM To: Simon Blake-Wilson Cc: tls@ietf.org Subject: Re: [TLS] Re: Cipher-suite specific extensions "Simon Blake-Wilson" writes: > Hi folks, > > By my count the results of my informal poll on whether people support=20 > adding cipher-suite specific extensions to the TLS extensions and ECC=20 > in TLS docs are currently 1-1. > > I don't think that shows sufficient support for making the changes to=20 > add cipher-suite specific support so unless more people speak up I=20 > suggest we move forward with the two documents without cipher-suite=20 > specific extension support. This is my assessment as well.=20 As I understand the situation, we're ready to forward this document to the IESG at this point. Simon, do you have anything else to do before you're ready for that? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 24 13:53:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zRH-0001oZ-N3; Wed, 24 Aug 2005 13:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zRG-0001oU-HN for tls@megatron.ietf.org; Wed, 24 Aug 2005 13:53: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 NAA08372 for ; Wed, 24 Aug 2005 13:53:25 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zRb-0001PA-Rh for tls@ietf.org; Wed, 24 Aug 2005 13:53:49 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:53:15 -0700 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:53:14 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:53:14 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 10:53:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Cipher-suite specific extensions Date: Wed, 24 Aug 2005 10:52:59 -0700 Message-ID: Thread-Topic: RE: [TLS] Re: Cipher-suite specific extensions thread-index: AcWHwxbEiKmP8443RBqlOdTHXGZMCwhEVh9A From: "Ari Medvinsky" To: , "Simon Blake-Wilson" X-OriginalArrivalTime: 24 Aug 2005 17:53:00.0164 (UTC) FILETIME=[AAC72C40:01C5A8D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable 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 =20 Simon, In case you missed Nicko's email regarding ECC cipher suites I am forwarding his email (see below). -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Nicko van Someren Sent: Wednesday, July 13, 2005 8:51 AM To: tls@ietf.org Subject: [TLS] (no subject) On Mon, 20 Jun 2005 at 11:59:16 -0600, Bodo Moeller wrote: > On Mon, Jun 20, 2005 at 10:33:51AM -0700, Ari Medvinsky wrote: > > >>> I have argued for a general mechanism for ciphersuite-dependent > TLS > >>> extensions in the past. That is, instead of having individual=20 > >>> specifications defining TLS extensions provide means of > restricting > >>> certain extensions to certain ciphersuites, it would make sense to > >>> have a mechanism that can be applied to all extensions, preferably > >>> defined in the successor of RFC 3456. > > >> This is a big change and I don't want to make this a gating > factor for > >> advancing the ECC draft. > >> > >> WG members: I'd like to come to some resolution on the basic > issue of > >> whether curves should be negotiable on a per-cipher-suite basis. > >> My intuition is that the case Ari mentions is kind of a corner=20 > >> case--most SSL/TLS implementations aren't assembled pluggably > like this. > >> But, I'm happy to listen to arguments that I'm wrong here... > > > I agree that relying on a general purpose mech. to be defined in the > > successor of RFC 3456 may introduce a long delay before the ECC > draft is > > finalized into an RFC. However, allowing third parties to plug > in their > > cipher suites is an important scenario as it facilitates security=20 > > vendors to provide a significant value add (in terms of perf. + > cipher > > suites that adhere to local crypto standards). > > > > It is possible to address the cipher suite/curve mapping directly > in the > > ECC draft (without dependencies on a general purpose mech) as I=20 > > suggested in the earlier msg. > > I think doing this directly in the TLS-ECC specification is not the=20 > best option because > > - this would mean reinventing the wheel when other ciphersuites need > similar mechanisms, adding some complexity to each of the affected > specifications individually; and > > - it already fails to take into account trusted_ca_keys (an extension > defined in RFC 3456, which appears destined for ciphersuite-=20 > dependent > use in the context of plug-ins). > > Let me point out that one alternative for how to proceed is to pass=20 > the TLS Extensions and TLS-ECC specifications without provisions for=20 > ciphersuite-dependent negotiation, but standardize a TLS extension for > ciphersuite-dependent TLS extensions later in a separate document=20 > ("TLS-CD-Ext"). Obviously TLS-CD-Ext support couldn't be made a=20 > "MUST" then, so for best interoperability ciphersuite-dependent TLS=20 > extensions could be defined so as to allow them to extend the list of=20 > ciphersuites given in the "cipher_suites filed" of the Client Hello=20 > message -- i.e., clients can make ciphersuites invisible from servers=20 > that do not support TLS-CD-Ext. > > This will keep the basic protocols simple, but optionally provide the=20 > desired flexibility. At first, while TLS-CD-Ext is used only in the=20 > context of TLS-ECC, the implementation overhead might be slightly=20 > higher for putting this directly into the TLS-ECC specification (which > would, however, omit ciphersuite-dependent use of the trusted_ca_keys=20 > extension); but as soon as some other set of ciphersuites has use for=20 > TLS-CD-Ext, this more general approach should become easier to handle. Sorry arrive late on this one but I've been having ongoing trouble getting messages through to this list. Hopefully this message will make it. Here's a repeat of what I tried to send before: As a vendor of widely used hardware for handling the crypto in TLS session negotiations I would like to lend my support for Ari's model of being able to specify specific extensions on specific cipher suits, and in particular specifying different ECC curves on different suits. While this seems like unnecessary complication it actually saves implementers from much worse complication if you do it the other way. Here's why: When implementing crypto in hardware, and in particular when implementing ECC, it is common for various types of hardware to have quite rigid limitations regarding the curve parameters. It is also the case that software implementations of ECC often have limitations due to the patent minefield in this space. This will be worst on hardware like ECC smartcards being used for client authentication but is also the case even on big, fast ECC chips from Motorola or software libraries which have been carefully constructed to skirt around IP issues. Due to the fragmented nature of the ECC market different types of hardware and software will have different limitations; some hardware might support MQV because it has a Certicom patent license but only work on binary curves (because they are easy in hardware) while the software "fall-back" for prime curves might not support MQV at all because it lacks a license. So we are in a situation where the intersection of supported parameters across the whole set of cipher suites ends up being the empty set and we are stuck. Eric said "My intuition is that the case Ari mentions is kind of a corner case--most SSL/TLS implementations aren't assembled pluggably like this. But, I'm happy to listen to arguments that I'm wrong here...". My feeling, from dealing with a great many SSL implementations, is that they very much are modular in nature, or at least their owners would like them to be :-) and that pluggable crypto is very important. Certainly the vast majority of SSL stacks that support hardware support it through some plug-in mechanism and while I expect it is rare for any individual system to have more than one type of hardware plugged in at a time it is quite frequently the case that there will be a hardware implementation and a software implementation operating side by side and, for the reasons outlined above, this will potentially be an issue. Anyway, that's my 2p (or 3.53 cents :-) worth! Cheers, Nicko van Someren CTO, nCipher Plc. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Aug 25 09:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HgN-0006TV-8X; Thu, 25 Aug 2005 09:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8HgJ-0006Qt-Vl for tls@megatron.ietf.org; Thu, 25 Aug 2005 09:22: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 JAA17131 for ; Thu, 25 Aug 2005 09:22:10 -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 1E8Hgo-00032F-WA for tls@ietf.org; Thu, 25 Aug 2005 09:22:45 -0400 Received: from simon (toronto-HSE-ppp4162885.sympatico.ca [70.51.152.19]) by bcisse.com; Thu, 25 Aug 2005 09:19:29 -0400 From: "Simon Blake-Wilson" To: "'EKR'" Subject: RE: [TLS] Re: Cipher-suite specific extensions Date: Thu, 25 Aug 2005 09:19:20 -0400 Message-ID: <048501c5a977$a05ae140$af00a8c0@simon> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 MIME-Version: 1.0 In-Reply-To: <86u0hf44f3.fsf@romeo.rtfm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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="===============1124803356==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1124803356== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0480_01C5A956.12738790" This is a multi-part message in MIME format. ------=_NextPart_000_0480_01C5A956.12738790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eric, I agree ECC in TLS is ready to go to the IESG. I'm not aware of any outstanding comments. Best regards. Simon > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Wednesday, August 24, 2005 1:43 PM > To: Simon Blake-Wilson > Cc: tls@ietf.org > Subject: Re: [TLS] Re: Cipher-suite specific extensions > > > "Simon Blake-Wilson" writes: > > > Hi folks, > > > > By my count the results of my informal poll on whether > people support > > adding cipher-suite specific extensions to the TLS > extensions and ECC > > in TLS docs are currently 1-1. > > > > I don't think that shows sufficient support for making the > changes to > > add cipher-suite specific support so unless more people speak up I > > suggest we move forward with the two documents without cipher-suite > > specific extension support. > > > > This is my assessment as well. > > As I understand the situation, we're ready to forward this > document to the IESG at this point. Simon, do you have > anything else to do before you're ready for that? > > Thanks, > -Ekr > ------=_NextPart_000_0480_01C5A956.12738790 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA4MjUxMzE5MTlaMCMGCSqGSIb3 DQEJBDEWBBRS/lmVTpeqEjm3S/MTqZi/hmwrkDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MAcGBSsOAwIaMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDAKBggqhkiG9w0CBTCB8gYJKwYBBAGCNxAEMYHkMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3 LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5 ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVy c29uYSBOb3QgVmFsaWRhdGVkAhA22vJQKV5JPY1TSL01WJuyMIH0BgsqhkiG9w0BCRACCzGB5KCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBC eSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZp ZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQNtryUCleST2NU0i9NVibsjAN BgkqhkiG9w0BAQEFAASBgEjFZ2skTrqw9AhbiY0LmRenpkg5kmWKL6IkPn87RIn/JKsGephA8JOk GD+hHD1lqqT+6XtxTUAKR2wgGnJB+zgnB9gDsSdIdSZv9/gQvZJjrNR4+ItdxPBd7gFqm4A4Hi8T Tn5E/XM7ARS0f2PcJC03C1jf779frOlCP0cilAnzAAAAAAAA ------=_NextPart_000_0480_01C5A956.12738790-- --===============1124803356== 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 --===============1124803356==-- From tls-bounces@lists.ietf.org Thu Aug 25 17:26:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PF9-0003LE-9x; Thu, 25 Aug 2005 17:26:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PF8-0003L9-0E for tls@megatron.ietf.org; Thu, 25 Aug 2005 17:26: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 RAA20903 for ; Thu, 25 Aug 2005 17:26:35 -0400 (EDT) Received: from smtp-out1.blueyonder.co.uk ([195.188.213.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8PFh-0002qA-TT for tls@ietf.org; Thu, 25 Aug 2005 17:27:15 -0400 Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out1.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Aug 2005 22:27:19 +0100 Message-ID: <430E3792.1050003@blueyonder.co.uk> Date: Thu, 25 Aug 2005 22:26:42 +0100 From: David Hopwood 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] AD comments on draft-ietf-tls-rfc3546bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Aug 2005 21:27:19.0436 (UTC) FILETIME=[C5EA1CC0:01C5A9BB] X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Wright, Timothy, VF-Group wrote: > No hollering forthcoming from me! No objection from me, either. I think it's unnecessary to change the spec from RFC 3546. It's worth pointing out that: - ciphersuite-specific extensions are useful only if the TLS *client* has extension options that depend on the ciphersuite. If the server has such options, no additional mechanism or conventions are needed, since the server can choose the ciphersuite and its extension replies together. Note that the issue of hardware that only supports certain ECC curves *mainly* affects servers, not clients. - not discussing ciphersuite-specific extensions in RFC3546bis will not prevent ECC (or anything else) from using a ciphersuite-specific extension. It just defers the issue of how to define such extensions to the documents that actually use them. (While I remember, although it's not very important: Simon's proposal in Message ID <05d801c58d6d$36c3f210$3200a8c0@simon> would have had a minor incompatibility with RFC 3546 -- it depended on sending multiple extensions of the same type, and section 2.3 of RFC 3546 explicitly disallows that. A spec that wanted to define ciphersuite-specific extensions would have to encode them all into a single extension to avoid this. I don't think that's a problem, though.) -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 26 11:19:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fzY-00058y-Kz; Fri, 26 Aug 2005 11:19:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fzX-00058p-0g for tls@megatron.ietf.org; Fri, 26 Aug 2005 11:19:39 -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 LAA26248 for ; Fri, 26 Aug 2005 11:19:36 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8g0G-0001nD-90 for tls@ietf.org; Fri, 26 Aug 2005 11:20:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7QFIetb015095 for ; Fri, 26 Aug 2005 18:18:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 18:19:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Aug 2005 18:19:35 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2005 18:19:42 +0300 Message-ID: Thread-Topic: PSK ciphersuites for OpenSSL Thread-Index: AcWqUZBxFQms3f9gQpi34tqDkQyJJg== To: X-OriginalArrivalTime: 26 Aug 2005 15:19:35.0417 (UTC) FILETIME=[9125BE90:01C5AA51] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: Subject: [TLS] PSK ciphersuites for OpenSSL X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 Some people might be interested in this:=20 http://www.mail-archive.com/openssl-dev@openssl.org/msg20099.html The actual patches can be found from the OpenSSL Request Tracker: http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=3D1191 (Follow-ups to the openssl-dev mailing list) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 26 19:48:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nvl-00015k-Su; Fri, 26 Aug 2005 19:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8nvl-00015f-6j for tls@megatron.ietf.org; Fri, 26 Aug 2005 19:48: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 TAA01706 for ; Fri, 26 Aug 2005 19:48:14 -0400 (EDT) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8nwW-0004Dk-Tx for tls@ietf.org; Fri, 26 Aug 2005 19:49:08 -0400 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 19815285E3 for ; Fri, 26 Aug 2005 17:30:10 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Fri, 26 Aug 2005 16:49:34 -0700 From: Eric Rescorla Message-Id: <20050827003010.19815285E3@sierra.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [TLS] TLS 1.2 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Folks, I'd like to start a discussion on whether we should be thinking about a TLS 1.2 that was more oriented towards newer hash functions. Obviously, we're not at a point where there's a crisis yet but it doesn't hurt to be prepared. Steve Bellovin's and my take on this can be found at: http://www.educatedguesswork.org/movabletype/archives/2005/07/deploying_a_new.html Thinking ahead, if we get much list discussion we should probably plan to have some time in Vancouver... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 26 21:14:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8pHV-0003Qm-Ja; Fri, 26 Aug 2005 21:14:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8pHU-0003Qh-CT for tls@megatron.ietf.org; Fri, 26 Aug 2005 21:14:48 -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 VAA04579 for ; Fri, 26 Aug 2005 21:14:46 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8pIJ-0006TP-7I for tls@ietf.org; Fri, 26 Aug 2005 21:15:40 -0400 Received: by machshav.com (Postfix, from userid 512) id D7DDCFB27D; Fri, 26 Aug 2005 21:14:37 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 139DBFB262; Fri, 26 Aug 2005 21:14:37 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 02AEF3BFFF4; Fri, 26 Aug 2005 21:14:35 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Eric Rescorla Subject: Re: [TLS] TLS 1.2 In-Reply-To: Your message of "Fri, 26 Aug 2005 16:49:34 PDT." <20050827003010.19815285E3@sierra.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Aug 2005 21:14:35 -0400 Message-Id: <20050827011435.02AEF3BFFF4@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This 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 message <20050827003010.19815285E3@sierra.rtfm.com>, Eric Rescorla writes: >Folks, > >I'd like to start a discussion on whether we should be thinking >about a TLS 1.2 that was more oriented towards newer hash >functions. Obviously, we're not at a point where there's >a crisis yet but it doesn't hurt to be prepared. > >Steve Bellovin's and my take on this can be found at: > >http://www.educatedguesswork.org/movabletype/archives/2005/07/deploying_a_new. >html > >Thinking ahead, if we get much list discussion we should probably >plan to have some time in Vancouver... > Obviously, I agree that we should do something... At some point, we *will* need new hash functions. That's probably years in the future, but realistically what we do will take years to deploy as well. I figure 2 years for the spec to appear as an RFC (wg time, IESG time, RFC editor queues, etc.), another 1-2 years for vendors to design, code, and test, and 3-5 years for deployment. --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 Mon Aug 29 05:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9gEf-0002Rj-Kh; Mon, 29 Aug 2005 05:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9gEa-0002RD-Lr for tls@megatron.ietf.org; Mon, 29 Aug 2005 05:47: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 FAA27128 for ; Mon, 29 Aug 2005 05:47:16 -0400 (EDT) Received: from groucho.itss.auckland.ac.nz ([130.216.190.11] helo=smtpa.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9gFr-0001PB-JK for tls@ietf.org; Mon, 29 Aug 2005 05:48:40 -0400 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 52AC1342CF; Mon, 29 Aug 2005 21:47:04 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31277-28; Mon, 29 Aug 2005 21:47:04 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 95DB6342BC; Mon, 29 Aug 2005 21:47:03 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DB6EF3774E; Mon, 29 Aug 2005 21:47:02 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1E9gEQ-0002RK-00; Mon, 29 Aug 2005 21:47:10 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] TLS 1.2 In-Reply-To: <20050827003010.19815285E3@sierra.rtfm.com> Message-Id: Date: Mon, 29 Aug 2005 21:47:10 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 2.9 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: >I'd like to start a discussion on whether we should be thinking about a TLS >1.2 that was more oriented towards newer hash functions. Obviously, we're not >at a point where there's a crisis yet but it doesn't hurt to be prepared. I've actually had a proposal for fixing TLS' broken signatures sketched out probably since it was still SSL, so perhaps we can use this to fix several problems at once. Firstly, in terms of attacks on hash functions, the only thing that really needs to be addressed is the use of hash functions as, well, hash functions. Most of the use in TLS is as PRFs and in HMAC, none of which are even remotely endangered by any known attack. Signatures, however, need to be fixed for three main reasons: 1. Use of potentially at-risk hash functions, as already noted. 2. Use of a )*#&%*$( nonstandard signature format that a number of crypto devices (and libraries) either don't support at all, or have broken support for. Trying to determine by trial and error which (say) smart cards support the weird SSL signature mechanism alongside the default PKCS #1 one, and then detecting which firmware revisions have which bugs in handling the format (claim to support it but don't, support it but add an ASN.1 wrapper at the start, only use one of the two hashes, and some other oddities that I've forgotten) is an absolute nightmare. 3. Signing of hashes that don't correspond to anything that's calculated during part of the normal handshake. That is, the dual-MAC that's sent in the Finished message isn't what gets signed, so it's necessary to run a parallel hash of handshake messages that terminates before the Finished- message hashing does. Since client certs are almost never used, there's a lot of extra overhead involved in running an extra dual hash that (most of the time) never gets used. In practice all that's needed is to sign the client and server nonces to ensure signature freshness, So my proposal was to include a new extension signatureSuites, consisting of (currently) three values: SIG_RSA_PKCS1_WITH_SHA1 SIG_RSA_PKCS1_WITH_SHA256 SIG_DSA_WITH_SHA1 and if that gets acknowledged by the other side (as per RFC 3546) then using a standard signature of the given type over the value: { "certificate verify" || client_nonce || server_nonce } So if the signature suite chosen was SIG_RSA_PKCS1_WITH_SHA1 then the cert- verify would contain a completely standard PKCS #1 signature over the above data. (Once this was added to the standard, I'd take the old signature mechanism and stomp on it and dance around it and sing hallelujah on its grave). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 29 08:22:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9if3-00072i-KL; Mon, 29 Aug 2005 08:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9if2-00072M-1m for tls@megatron.ietf.org; Mon, 29 Aug 2005 08:22:48 -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 IAA04843 for ; Mon, 29 Aug 2005 08:22:45 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9igK-00067T-4y for tls@ietf.org; Mon, 29 Aug 2005 08:24:09 -0400 Received: by machshav.com (Postfix, from userid 512) id 24B51FB262; Mon, 29 Aug 2005 08:22:39 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 494A5FB246; Mon, 29 Aug 2005 08:22:38 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 3B7CB3BFFF4; Mon, 29 Aug 2005 08:22:37 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Subject: Re: [TLS] TLS 1.2 In-Reply-To: Your message of "Mon, 29 Aug 2005 21:47:10 +1200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Aug 2005 08:22:37 -0400 Message-Id: <20050829122237.3B7CB3BFFF4@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org In message , Peter Gutmann writes : >Eric Rescorla writes: > >>I'd like to start a discussion on whether we should be thinking about a TLS >>1.2 that was more oriented towards newer hash functions. Obviously, we're not >>at a point where there's a crisis yet but it doesn't hurt to be prepared. > >I've actually had a proposal for fixing TLS' broken signatures sketched out >probably since it was still SSL, so perhaps we can use this to fix several >problems at once. Firstly, in terms of attacks on hash functions, the only >thing that really needs to be addressed is the use of hash functions as, well, >hash functions. Most of the use in TLS is as PRFs and in HMAC, none of which >are even remotely endangered by any known attack. Signatures, however, need >to be fixed for three main reasons: Note that we're also talking about negotiating which certificates are used. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls