From bounce-ietf-tls-3458737@lists.certicom.com Fri Jan 5 12:24:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17276 for ; Fri, 5 Jan 2001 12:24:42 -0500 (EST) From: Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES outstanding issues Date: Fri, 5 Jan 2001 17:22:40 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net A comment on the suggested requirement for mandatory support of PFS. > -----Original Message----- > From: Ben Laurie [mailto:ben@algroup.co.uk] > Sent: 11 December 2000 14:13 > To: IETF Transport Layer Security WG > Subject: [ietf-tls] Re: AES outstanding issues > > > Pete Chown wrote: > > > > Okay, these are the outstanding issues that I can see with the AES > > draft. Let's go and bang our heads against the wall -- by the time > > we've been going for a while we will probably be able to > imagine that > > there is some kind of consensus! :-) > > ... > > > 2. Interoperability. Ericsson are concerned that the current > > interoperability rules will force mobile devices to support > > forward secrecy when they don't have the processing power to do > > so. > > Then they are broken. Forward secrecy should not be optional. > We should > probably allow consenting adults that don't care to configure it away > though. If you want to make server support of FS ciphersuites mandatory then fine, but it should not be mandatory for clients. Per session key generation will be a tall order for many mobile devices for some time to come. As a compensating factor, GSM and 3GPP mobile devices (unlike most servers) will have a smartcard that can be used to store the master secret, I would argue that this lessens the requirement for FS on mobile clients. Tim --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jan 5 19:20:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25872 for ; Fri, 5 Jan 2001 19:20:29 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-057.dialup.zetnet.co.uk [194.247.41.71] claimed to be zetnet.co.uk Message-ID: Date: Sat, 06 Jan 2001 00:13:32 +0000 From: David Hopwood Reply-To: "IETF Transport Layer Security WG" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES outstanding issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A56632C.3D3F39CF@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- timothy.wright@vf.vodafone.co.uk wrote: > A comment on the suggested requirement for mandatory support of PFS. [snip] > Ben Laurie wrote: > > Pete Chown wrote: > > > 2. Interoperability. Ericsson are concerned that the current > > > interoperability rules will force mobile devices to support > > > forward secrecy when they don't have the processing power to do > > > so. > > > > Then they are broken. Forward secrecy should not be optional. I strongly agree. *Either* the client or server should be able to insist on forward secrecy, and this requires that *both* support (and are actually able to negotiate) at least one common FS ciphersuite. > > We should probably allow consenting adults that don't care to > > configure it away though. > > If you want to make server support of FS ciphersuites mandatory then > fine, but it should not be mandatory for clients. Supporting forward secrecy does not have much effect on the performance of clients; the main performance effect is on servers (and I think even that could be almost eliminated by adding some new key exchange methods). IMHO Ericsson's concern is unfounded. I'll post the performance estimates again if anyone missed them last time. > Per session key generation will be a tall order for many mobile devices > for some time to come. Clients do not have to generate public/private key pairs in order to support FS (they obviously have to generate session keys using the PRF, for all ciphersuites). > As a compensating factor, GSM and 3GPP mobile devices (unlike most servers) > will have a smartcard that can be used to store the master secret, I would > argue that this lessens the requirement for FS on mobile clients. The point of FS is to protect information sent in previous sessions if the server's private key is compromised. This requires support for FS ciphersuites from the client. An anonymous client doesn't store any long-term keys anyway. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOlY39TkCAxeYt5gVAQE5EwgAmXJYrXRzS3zO990y2VQKK1qcn+rghe59 fogA/Kj+FNexTf9a93uyhPgAGSBUHby063b4o177WQYlRps9NkAZdvAqz0UOrXUu AbosclB52hVD1X3sWYJwV5OKRqTRObOjklfGyOQH3llPqh4cPVwpGI5sDhBxYtRK 6+zHxdiccPZgRmRpI63JvmIJfnNKWvevDX4+lC9gsIf/znkut42HAckJweO9ItNG 1GkyZNStYihvH8USSjIDSiQBk1ur14sBF9L0ALwwVEGtbJAz9P/N5hALy5iYptYi ZeFJDriOQDYQf7KShuItamOkqATUC+SEGyx/lb+WMfoMM8XEw4GHeg== =6fWm -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jan 12 03:55:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06356 for ; Fri, 12 Jan 2001 03:55:51 -0500 (EST) From: Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Date: Fri, 12 Jan 2001 08:52:49 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I think it would certainly be useful to re-visit the need for 2 hash functions in MS generation in TLS version 2, whenever that happens. I hope we have MS generation on the SIM/WIM as part of wireless support of TLS, and support of two hash functions on the smartcard would be something it would be good to avoid. (Sorry to keep banging on about limited client capabilities) Tim > -----Original Message----- > From: Paul Koning [mailto:pkoning@ironstream.com] > Sent: 22 December 2000 19:03 > To: IETF Transport Layer Security WG > Subject: [ietf-tls] Re: Suggested Finished Message Processing > Improvement > > > I tend to agree with Eric that this is probably not a good time to > make incompatible protocol changes. > > At the risk of being told to go back to the archives, I'll add another > comment... there seems to be a fair amount of opportunity for > removing computational complexity from the protocol. Right now it is > very heavily biased to throwing lots of cryptographic functions into > the mix to be very sure that there aren't weaknesses. Other protocols > (e.g., IKE) are much more minimalist, for example they never hash the > same stuff with two hash algorithms. > > Rather than tweak a single bottleneck now, how about revisiting things > more globally for TLS V2.0? > > paul > > > --- > You are currently subscribed to ietf-tls as: > timothy.wright@vf.vodafone.co.uk > To unsubscribe send a blank email to > leave-ietf-tls-3458737E@lists.certicom.com > --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jan 12 03:58:37 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06373 for ; Fri, 12 Jan 2001 03:58:36 -0500 (EST) From: Message-Id: To: "IETF Transport Layer Security WG" Cc: wap-wsg@mail.wapforum.org Subject: [ietf-tls] WAP TLS profile Date: Fri, 12 Jan 2001 08:55:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Dear all, I'm writing on behalf of the WAP Security Group (WSG) which I chair to request your comments on the WSG's profile of TLS. What we are trying to do (as well as get in the extensions in Simon B-W & Magnus Nystrom's I-d) is to develop a profile of TLS for use by wireless clients and servers communicating with wireless clients. Although there are recommendations for server to "optimise" connections with wireless clients, it is the intention of the WSG that a client following the profile can communicate with ANY existing TLS 1.0 server. This goal in particular is what we'd like your comments on. We know this doc is not perfect (certificate processing does not guarantee inter-op at present) and we have some changes to make, but I think your feedback at this stage is still very welcome. The best place for comments would be to the TLS list, so others in the group can comment on the comments. I hope that isn't considered an invasion of your space. I should stress that we're committed to working openly with you to get TLS onto phones in the best possible way for all. This doc is now a WAP Forum "Prototype" so is public. It's at http://www1.wapforum.org/tech/documents/WAP-219-TLS-20001204-t.pdf I can't save it directly off my browser but you can pull it out of the browser temp file store as you know. You can see the rest of the WAP specs at http://www.wapforum.org/what/technical.htm I guess for presentation at the next IETF, if that be appropriate, we have to convert the doc into an I-d? Tim --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 16 20:04:33 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24374 for ; Tue, 16 Jan 2001 20:04:30 -0500 (EST) Date: Tue, 16 Jan 2001 17:04:01 -0800 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from timothy.wright@vf.vodafone.co.uk on Fri, Jan 12, 2001 at 08:52:49AM -0000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010116170401.T15101@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Fri, Jan 12, 2001 at 08:52:49AM -0000, timothy.wright@vf.vodafone.co.uk wrote: > I think it would certainly be useful to re-visit the need for 2 hash > functions in MS generation in TLS version 2, whenever that happens. I hope > we have MS generation on the SIM/WIM as part of wireless support of TLS, and > support of two hash functions on the smartcard would be something it would > be good to avoid. (Sorry to keep banging on about limited client > capabilities) Using two hashes also causes problems for high-performance TLS servers. I'd be also interested in examining the MS generation for possible ways to streamline it and reduce the algorithm count when TLS v2 gets going. -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 16 20:26:09 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24773 for ; Tue, 16 Jan 2001 20:26:03 -0500 (EST) Message-ID: Date: Wed, 17 Jan 2001 01:25:54 +0000 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3A64F4A2.5A5C9644@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Murray wrote: > > On Fri, Jan 12, 2001 at 08:52:49AM -0000, timothy.wright@vf.vodafone.co.uk wrote: > > I think it would certainly be useful to re-visit the need for 2 hash > > functions in MS generation in TLS version 2, whenever that happens. I hope > > we have MS generation on the SIM/WIM as part of wireless support of TLS, and > > support of two hash functions on the smartcard would be something it would > > be good to avoid. (Sorry to keep banging on about limited client > > capabilities) > > Using two hashes also causes problems for high-performance TLS servers. Perhaps you should consider upgrading from the Z80, then? Surely you can't be serious about this? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 16 20:31:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24832 for ; Tue, 16 Jan 2001 20:31:05 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jan 2001 17:35:16 -0800 In-Reply-To: Ben Laurie's message of "Wed, 17 Jan 2001 01:25:54 +0000" Message-ID: Lines: 14 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Ben Laurie writes: > Eric Murray wrote: > > Using two hashes also causes problems for high-performance TLS servers. > > Perhaps you should consider upgrading from the Z80, then? Surely you > can't be serious about this? > Actually, Eric's quite right. Once you optimize out the RSA operation, the message digests for key expansion are the dominant performance cost. When you get up around 1000 handshakes/s, the performance cost becomes quite significant, even on fast processors. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 16 22:39:31 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27960 for ; Tue, 16 Jan 2001 22:39:28 -0500 (EST) Date: Tue, 16 Jan 2001 19:21:47 -0800 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: MS hashes Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from ben@algroup.co.uk on Wed, Jan 17, 2001 at 01:25:54AM +0000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010116192147.V15101@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Wed, Jan 17, 2001 at 01:25:54AM +0000, Ben Laurie wrote: > Eric Murray wrote: > > > > On Fri, Jan 12, 2001 at 08:52:49AM -0000, timothy.wright@vf.vodafone.co.uk wrote: > > > I think it would certainly be useful to re-visit the need for 2 hash > > > functions in MS generation in TLS version 2, whenever that happens. I hope > > > we have MS generation on the SIM/WIM as part of wireless support of TLS, and > > > support of two hash functions on the smartcard would be something it would > > > be good to avoid. (Sorry to keep banging on about limited client > > > capabilities) > > > > Using two hashes also causes problems for high-performance TLS servers. > > Perhaps you should consider upgrading from the Z80, then? Surely you > can't be serious about this? Surely I can. When you're trying to do 1000 TLS/sec or more, the extra operations really hurt. Yes, you can do it in hardware, but there's also RSA hardware and hardware for the bulk cipher. Each core that you add to a chip means that something else gets dropped, or the cost goes up a lot. Even if you have all hardware crypto, you have to send the data back over the bus multiple times to get hashed. Ths bus bandwidth alone, for four round trips for a hash (HMAC in two algorithms), plus RSA, plus network traffic, can get close to the practical maximum for common busses. Take a look at the TLS spec and count up the number of hashes and the number of bytes in each for each session. There's some folks working on putting various parts of TLS in hardware, which solves some of the problem, but (so far) no one I'm aware of is putting the handshake into hardware... it's just too variable. My feeling from talking to the various people who were designing SSLv3 was that the duplicate hashes for the MS were there out of a bit of ad hoc enginering-- Dobbertin had just published his attack on MD5 and the feeling was that it was going to fall, and maybe SHA1 too, but that both together would be good enough, without having to specify the MS hash in the ciphersuite. Nothing wrong with that, but they wern't thinking of running 1k sessions/sec either. The issue might be worth re-examining now epecially since it'd also be useful for small devices, so they don't have to implement both hashes even if they want to use only one for record MACs. -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 03:23:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14577 for ; Wed, 17 Jan 2001 03:23:46 -0500 (EST) Message-ID: Date: Wed, 17 Jan 2001 08:23:15 +0000 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3A655673.374A48D9@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Ben Laurie writes: > > Eric Murray wrote: > > > Using two hashes also causes problems for high-performance TLS servers. > > > > Perhaps you should consider upgrading from the Z80, then? Surely you > > can't be serious about this? > > > Actually, Eric's quite right. Once you optimize out the RSA operation, > the message digests for key expansion are the dominant performance cost. > When you get up around 1000 handshakes/s, the performance cost becomes quite > significant, even on fast processors. According to OpenSSL's benchmarks, MD5 is substantially faster than RC4, and SHA-1 a touch slower. However, you have to RC4 substantially more data, in general, so the dominant cost is surely the symmetric cipher (not forgetting that other symmetric ciphers are generally slower than RC4). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 11:26:22 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21270 for ; Wed, 17 Jan 2001 11:26:21 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 17 Jan 2001 11:26:08 -0500 (Eastern Standard Time) From: Paul Koning To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent X-Mailer: VM 6.75 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <14949.51104.953000.833663@gargle.gargle.HOWL> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit >>>>> "Ben" == Ben Laurie writes: Ben> Eric Murray wrote: >> On Fri, Jan 12, 2001 at 08:52:49AM -0000, >> timothy.wright@vf.vodafone.co.uk wrote: > I think it would >> certainly be useful to re-visit the need for 2 hash > functions in >> MS generation in TLS version 2, whenever that happens. I hope > >> we have MS generation on the SIM/WIM as part of wireless support >> of TLS, and > support of two hash functions on the smartcard would >> be something it would > be good to avoid. (Sorry to keep banging >> on about limited client > capabilities) >> >> Using two hashes also causes problems for high-performance TLS >> servers. Ben> Perhaps you should consider upgrading from the Z80, then? Surely Ben> you can't be serious about this? What a strange comment. Surely it is obvious that two hashes take twice as much processing as one hash whether you use a Z80 or a Cray? The only exception is if you have hardware hash engines that are capable of hooking up the various engines in such a way that both hashes can be done in a single pass through the hardware. It is possible to conceive of such hardware but I have never seen any. paul --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 11:32:21 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21324 for ; Wed, 17 Jan 2001 11:32:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 17 Jan 2001 11:32:14 -0500 (Eastern Standard Time) From: Paul Koning To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent X-Mailer: VM 6.75 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <14949.51470.68000.683126@gargle.gargle.HOWL> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit >>>>> "Ben" == Ben Laurie writes: Ben> Eric Rescorla wrote: >> Ben Laurie writes: > Eric Murray wrote: > > >> Using two hashes also causes problems for high-performance TLS >> servers. > > Perhaps you should consider upgrading from the Z80, >> then? Surely you > can't be serious about this? > Actually, >> Eric's quite right. Once you optimize out the RSA operation, the >> message digests for key expansion are the dominant performance >> cost. When you get up around 1000 handshakes/s, the performance >> cost becomes quite significant, even on fast processors. Ben> According to OpenSSL's benchmarks, MD5 is substantially faster Ben> than RC4, and SHA-1 a touch slower. However, you have to RC4 Ben> substantially more data, in general, so the dominant cost is Ben> surely the symmetric cipher (not forgetting that other symmetric Ben> ciphers are generally slower than RC4). It is a serious error to extrapolate like this from one benchmark of one software-based implementation. It doesn't necessarily apply on other platforms, it doesn't necessarily apply with other implementations of the algorithms. And it most definitely has no relevance whatsoever when analyzing hardware-assisted implementations. My comment came from analyzing the performance issues with hardware assisted TLS implementations. It's clear that Eric R. is doing likewise. A software-only mindset is not helpful in making appropriate design decisions here. paul --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 11:44:34 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21505 for ; Wed, 17 Jan 2001 11:44:33 -0500 (EST) Message-ID: From: "Greg Stark" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Date: Wed, 17 Jan 2001 11:43:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <012c01c080a4$b7740600$651e10ac@netscreen5> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Let's not forget the MAC that occurs as part of the payload protection. This means that every bit that gets encrypted also gets HMAC'ed, so the expense of SHA1 or MD5 also creeps into the the payload protection part. Greg Stark Ethentica, Inc. gstark@ethentica.com ----- Original Message ----- From: "Paul Koning" To: "IETF Transport Layer Security WG" Sent: Wednesday, January 17, 2001 11:32 AM Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent > >>>>> "Ben" == Ben Laurie writes: > > Ben> Eric Rescorla wrote: > >> Ben Laurie writes: > Eric Murray wrote: > > > >> Using two hashes also causes problems for high-performance TLS > >> servers. > > Perhaps you should consider upgrading from the Z80, > >> then? Surely you > can't be serious about this? > Actually, > >> Eric's quite right. Once you optimize out the RSA operation, the > >> message digests for key expansion are the dominant performance > >> cost. When you get up around 1000 handshakes/s, the performance > >> cost becomes quite significant, even on fast processors. > > Ben> According to OpenSSL's benchmarks, MD5 is substantially faster > Ben> than RC4, and SHA-1 a touch slower. However, you have to RC4 > Ben> substantially more data, in general, so the dominant cost is > Ben> surely the symmetric cipher (not forgetting that other symmetric > Ben> ciphers are generally slower than RC4). > --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 12:01:18 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22013 for ; Wed, 17 Jan 2001 12:01:17 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 17 Jan 2001 09:05:27 -0800 In-Reply-To: Ben Laurie's message of "Wed, 17 Jan 2001 08:23:15 +0000" Message-ID: Lines: 52 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Ben Laurie writes: > Eric Rescorla wrote: > > > > Ben Laurie writes: > > > Eric Murray wrote: > > > > Using two hashes also causes problems for high-performance TLS servers. > > > > > > Perhaps you should consider upgrading from the Z80, then? Surely you > > > can't be serious about this? > > > > > Actually, Eric's quite right. Once you optimize out the RSA operation, > > the message digests for key expansion are the dominant performance cost. > > When you get up around 1000 handshakes/s, the performance cost becomes quite > > significant, even on fast processors. > > According to OpenSSL's benchmarks, MD5 is substantially faster than RC4, > and SHA-1 a touch slower. On my machines, substantially slower. > However, you have to RC4 substantially more > data, in general, so the dominant cost is surely the symmetric cipher > (not forgetting that other symmetric ciphers are generally slower than > RC4). Not really. You always have to digest more data than you encrypt. It's true that you encrypt the plaintext + digest but remember that we're not just using MD5. We're using HMAC, which means that you have to digest at least 3 extra hash input blocks (the key twice and the output of the first digest block. Since you don't pad with RC4, you're always digesting more than you encrypt--this ignores the message digest cost for the handshake. However, the issue here isn't message processing. It's the amount of time required by the digests in the handshake, specifically, the additional time required by having to use MD5 and SHA-1 in parallel. In the worst case, where the data being transferred is relatively small the digest cost becomes quite significant. I misspoke when I said it was dominant. It's more like 20-50% of the overall crypto cost, depending on the size of the data records being transferred. More importantly, it's difficult to optimize this stuff out with hardware for the reasons that Eric indicated earlier. Basically, the computation is so complicated that just having an RC4 or HMAC core on your hardware doesn't help that much--whereas it does help substantially for record processing. As it happens, I don't agree with Eric that removing one of these digests is a change worth making. We'd probably reclaim (at best) 20% of the CPU and it introduces an incompatibility. IMHO, by the time we've made the change, Moore's law will have done the job for us. However, this doesn't change the fact that it's expensive. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 12:34:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22588 for ; Wed, 17 Jan 2001 12:34:26 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Date: Wed, 17 Jan 2001 18:34:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <03d401c080ab$d3cf3930$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I have had a look at the numbers. Results were obtained using our Java TLS implementation connecting to jcewww.iaik.at:443 using TLS_RSA_WITH_RC4_128_MD5. Initial handshake: MD5: 8384 bytes in 48 digests. SHA-1: 7744 bytes in 42 digests. (848 data bytes read, 280 written) Abbreviated handshake: MD5: 4964 bytes in 35 digests. SHA-1: 4244 bytes in 29 digests. (122 data bytes read, 173 written) The numbers are total numbers of bytes processed, i.e. they include the padding bytes. Also included are the operations done as part of the record mac. The digest padding bytes actually make up a significant part but will not need to be transferred over an external bus in many hardware implementations. A lot could be saved as well by changing the definition of the P_hash functions to use something simpler that HMAC. HMAC is fairly expensive for processing very short data as it requires two digest operations. At the end the question remains of whether a change is actually worth it. What seems fairly clear to me, however, is that the certificate accounts for a fairly small part of the data. So it will not make much of a difference if a precalculated hash is used, as was suggested recently. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 13:47:36 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24158 for ; Wed, 17 Jan 2001 13:47:35 -0500 (EST) Message-ID: Date: Wed, 17 Jan 2001 18:47:16 +0000 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3A65E8B4.A9CEAA97@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Paul Koning wrote: > > >>>>> "Ben" == Ben Laurie writes: > > Ben> Eric Rescorla wrote: > >> Ben Laurie writes: > Eric Murray wrote: > > > >> Using two hashes also causes problems for high-performance TLS > >> servers. > > Perhaps you should consider upgrading from the Z80, > >> then? Surely you > can't be serious about this? > Actually, > >> Eric's quite right. Once you optimize out the RSA operation, the > >> message digests for key expansion are the dominant performance > >> cost. When you get up around 1000 handshakes/s, the performance > >> cost becomes quite significant, even on fast processors. > > Ben> According to OpenSSL's benchmarks, MD5 is substantially faster > Ben> than RC4, and SHA-1 a touch slower. However, you have to RC4 > Ben> substantially more data, in general, so the dominant cost is > Ben> surely the symmetric cipher (not forgetting that other symmetric > Ben> ciphers are generally slower than RC4). > > It is a serious error to extrapolate like this from one benchmark of > one software-based implementation. It doesn't necessarily apply on > other platforms, Did I say anything about which platforms that applied to? > it doesn't necessarily apply with other > implementations of the algorithms. If people have some strange need to use slower implementations, that is not my problem. > And it most definitely has no > relevance whatsoever when analyzing hardware-assisted implementations. > > My comment came from analyzing the performance issues with hardware > assisted TLS implementations. It's clear that Eric R. is doing > likewise. A software-only mindset is not helpful in making > appropriate design decisions here. Thankyou for the lecture. The supposition was that RSA was being done by hardware, leaving the hashes and the symmetric crypto to be done in software. I would be surprised to hear that the measured performance of the symmetric crypto is less than that of the hashes in this case. Which is the point I was trying to make. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 13:50:40 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24189 for ; Wed, 17 Jan 2001 13:50:39 -0500 (EST) Message-ID: Date: Wed, 17 Jan 2001 18:50:26 +0000 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3A65E972.F4BBB95B@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Ben Laurie writes: > > Eric Rescorla wrote: > > > > > > Ben Laurie writes: > > > > Eric Murray wrote: > > > > > Using two hashes also causes problems for high-performance TLS servers. > > > > > > > > Perhaps you should consider upgrading from the Z80, then? Surely you > > > > can't be serious about this? > > > > > > > Actually, Eric's quite right. Once you optimize out the RSA operation, > > > the message digests for key expansion are the dominant performance cost. > > > When you get up around 1000 handshakes/s, the performance cost becomes quite > > > significant, even on fast processors. > > > > According to OpenSSL's benchmarks, MD5 is substantially faster than RC4, > > and SHA-1 a touch slower. > On my machines, substantially slower. I may have been unclear: slower than RC4, not MD5! > > However, you have to RC4 substantially more > > data, in general, so the dominant cost is surely the symmetric cipher > > (not forgetting that other symmetric ciphers are generally slower than > > RC4). > Not really. You always have to digest more data than you encrypt. > It's true that you encrypt the plaintext + digest but remember that > we're not just using MD5. We're using HMAC, which means that you have > to digest at least 3 extra hash input blocks (the key twice and the > output of the first digest block. Since you don't pad with RC4, you're > always digesting more than you encrypt--this ignores the message > digest cost for the handshake. I wasn't talking about the message digests, though I probably should have been, thanks for the correction. > However, the issue here isn't message processing. It's the amount of > time required by the digests in the handshake, specifically, the > additional time required by having to use MD5 and SHA-1 in parallel. > In the worst case, where the data being transferred is relatively > small the digest cost becomes quite significant. I misspoke when I > said it was dominant. It's more like 20-50% of the overall crypto > cost, depending on the size of the data records being transferred. Aha. So I was right :-) > More importantly, it's difficult to optimize this stuff out with > hardware for the reasons that Eric indicated earlier. Basically, > the computation is so complicated that just having an RC4 or HMAC > core on your hardware doesn't help that much--whereas it does help > substantially for record processing. > > As it happens, I don't agree with Eric that removing one of these > digests is a change worth making. We'd probably reclaim (at best) 20% > of the CPU and it introduces an incompatibility. IMHO, by the time > we've made the change, Moore's law will have done the job for > us. However, this doesn't change the fact that it's expensive. Agreed. Just not dominant. I may have overstated my objection, I hadn't realised how slow SHA-1 was. :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 16:44:26 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26574 for ; Wed, 17 Jan 2001 16:44:15 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 17 Jan 2001 09:15:12 -0800 In-Reply-To: Paul Koning's message of "Wed, 17 Jan 2001 11:32:14 -0500 (Eastern Standard Time)" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Paul Koning writes: > >>>>> "Ben" == Ben Laurie writes: > > Ben> Eric Rescorla wrote: > >> Ben Laurie writes: > Eric Murray wrote: > > > >> Using two hashes also causes problems for high-performance TLS > >> servers. > > Perhaps you should consider upgrading from the Z80, > >> then? Surely you > can't be serious about this? > Actually, > >> Eric's quite right. Once you optimize out the RSA operation, the > >> message digests for key expansion are the dominant performance > >> cost. When you get up around 1000 handshakes/s, the performance > >> cost becomes quite significant, even on fast processors. > > Ben> According to OpenSSL's benchmarks, MD5 is substantially faster > Ben> than RC4, and SHA-1 a touch slower. However, you have to RC4 > Ben> substantially more data, in general, so the dominant cost is > Ben> surely the symmetric cipher (not forgetting that other symmetric > Ben> ciphers are generally slower than RC4). > > It is a serious error to extrapolate like this from one benchmark of > one software-based implementation. It doesn't necessarily apply on > other platforms, it doesn't necessarily apply with other > implementations of the algorithms. And it most definitely has no > relevance whatsoever when analyzing hardware-assisted implementations. > > My comment came from analyzing the performance issues with hardware > assisted TLS implementations. It's clear that Eric R. is doing > likewise. A software-only mindset is not helpful in making > appropriate design decisions here. We've already accelerated the RSA implementation but haven't accelerated the MD5 and SHA yet. Have you? Did you gain performance or did the bus overhead kill you? -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 16:44:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26576 for ; Wed, 17 Jan 2001 16:44:22 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 17 Jan 2001 09:19:24 -0800 In-Reply-To: Eric Rescorla's message of "17 Jan 2001 09:05:27 -0800" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Eric Rescorla writes: > More importantly, it's difficult to optimize this stuff out with > hardware for the reasons that Eric indicated earlier. Basically, > the computation is so complicated that just having an RC4 or HMAC > core on your hardware doesn't help that much--whereas it does help > substantially for record processing. This last paragraph is confusing. What I meant to say is that just having an MD5 or SHA core on the hardware means that you have to take a lot of trips across the bus, which can be quite expensive. Obviously, having an RC4 core on the hardware is only useful for record processing. That'll teach me to write stuff first thing in the morning. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 17 17:28:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27212 for ; Wed, 17 Jan 2001 17:28:45 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Wed, 17 Jan 2001 17:28:32 -0500 (Eastern Standard Time) From: Paul Koning To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent X-Mailer: VM 6.75 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <14950.7312.909000.442798@gargle.gargle.HOWL> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit >>>>> "Ben" == Ben Laurie writes: Ben> Paul Koning wrote: >> >>>>> "Ben" == Ben Laurie writes: >> Ben> Eric Rescorla wrote: >> >> Ben Laurie writes: > Eric Murray wrote: > > >> >> Using two hashes also causes problems for high-performance TLS >> >> servers. > > Perhaps you should consider upgrading from the >> Z80, >> then? Surely you > can't be serious about this? > >> Actually, >> Eric's quite right. Once you optimize out the RSA >> operation, the >> message digests for key expansion are the >> dominant performance >> cost. When you get up around 1000 >> handshakes/s, the performance >> cost becomes quite significant, >> even on fast processors. >> Ben> According to OpenSSL's benchmarks, MD5 is substantially faster Ben> than RC4, and SHA-1 a touch slower. However, you have to RC4 Ben> substantially more data, in general, so the dominant cost is Ben> surely the symmetric cipher (not forgetting that other symmetric Ben> ciphers are generally slower than RC4). >> It is a serious error to extrapolate like this from one benchmark >> of one software-based implementation. It doesn't necessarily >> apply on other platforms, Ben> Did I say anything about which platforms that applied to? No. But the relative speeds of these algorithms definitely depends on the instruction set. >> it doesn't necessarily apply with other implementations of the >> algorithms. Ben> If people have some strange need to use slower implementations, Ben> that is not my problem. Well, some people do care about the performance of slow (low cost, or more importantly, low power implementations). But as it happens, that's not what I was talking about. I'm talking about much faster implementations. If you apply various accelerators, some algorithms accelerate far more than others do (for example, typical crypto hardware can do SHA-1 and MD5 significantly faster than RC4, which makes sense if you consider what's involved.) >> And it most definitely has no relevance whatsoever when analyzing >> hardware-assisted implementations. >> >> My comment came from analyzing the performance issues with >> hardware assisted TLS implementations. It's clear that Eric R. is >> doing likewise. A software-only mindset is not helpful in making >> appropriate design decisions here. Ben> Thankyou for the lecture. The supposition was that RSA was being Ben> done by hardware, leaving the hashes and the symmetric crypto to Ben> be done in software. I would be surprised to hear that the Ben> measured performance of the symmetric crypto is less than that Ben> of the hashes in this case. Which is the point I was trying to Ben> make. My point is that you're objecting to a general proposal for optimizing things, based on arguments that assume a particular supposition of hardware vs. software, some (unstated) assumptions on the speeds of engines and the performance requirements of the implementation, etc. For the sort of systems I'm interested in, your assumptions do not apply and the conclusions you draw from them don't either. In particular, if you have hardware assists for all the crypto stuff, then every additional crypto primitive is (typically) another pass over the bus and another round trip through drivers and queues. One thing that's clear when you look at SSL/TLS key establishment: there's a very large number of crypto operations being performed. It seems likely that a significant fraction could be taken out without damaging security. (For example, looking at IKE, I believe that it takes far fewer crypto operations than TLS key establishment does.) paul --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jan 19 10:41:15 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00739 for ; Fri, 19 Jan 2001 10:41:14 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Fri, 19 Jan 2001 10:38:40 -0500 Subject: [ietf-tls] TLS extensions comments Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <852569D9.00559B5D.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi folks, Many thanks for all the comments on the TLS extensions draft. Magnus and I are in the process of producing an updated draft folding in all the suggestions we received for improvements. There are a few issues where we'd like to solicit comments on proposed resolutions or seek feedback with a view to getting consensus. Comments please. 1. Truncated MACs ... our original draft supported truncated MACs via the general hello extension mechanism. We received a number of comments in support of this approach (which avoids ciphersuite explosion), and a number of comments in favour instead of defining truncated MACs via new cipher suites (which avoids addressing cipher suite issues outside of cipher suite definition). Our inclination is to leave definition as an extension mechanism, but leave the door open for future cipher suites to define truncated MACs as part of the cipher suite for cipher suites involving new algorithms like AES. 2. Certificate URLs ... our draft allowed a single cert to be referenced rather than a cert chain (placing the burden for chain building on servers). Again several comments supported this approach to save complexity on constrained clients, while several comments felt chain building was an unacceptable burden to place on servers and therefore favoured using a single URL to reference a cert chain. We'd like to propose a compromise solution in which each URL references a single cert, but a list of URLs corresponding to a cert chain may be transmitted by clients. 3. Maximum record size negotiation ... the draft was unclear on whether negotiated maximum record sizes apply during session resumption. We propose to clarify that the negotiated size does apply during resumption, but remove the smallest sizes to avoid substantial fragmentation of handshake messages during resumption. 4. Trusted key ids ... several comments suggested that it may be desirable to identify trusted key ids by both DN and key hash. We're open to allowing this possibility while continuing to allow the options to identify via only DN and only key hash when these options are sufficient to uniquely identify the keys ... but are concerned about the potential increase in complexity. Note that RFC 2246 currently identifies trusted keys held by the server simply by the ditinguished name, right? Comments please. 5. DNS name extension ... several comments requested to add the proposed DNS name extension to the draft. We agree and will approach the original proponents of this extension to see if they would like to be added as co-authors of the draft. 6. New error messages ... it's been pointed out that the draft should add new error messages to support errors that may arise as a result of the extensions. We propose to add new messages, along with rules for when these error messages may be sent in order ot avoid the new messages breaking existing clients and servers. 7. Short session ids ... the draft recommended the use of short session ids (in order to potentially save some bandwidth and memory on clients). Eric Rescorla commented that he felt this recommendation did not offer significant benefits, and that the cost of updating existing server implementations to follow the recommendation was therefore not justified. We'd appreciate any other opinions on this issue in order to try and gain a sense of the overall feeling within the group. Best regards. Simon --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 00:07:37 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16255 for ; Mon, 22 Jan 2001 00:07:36 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Minutes from San Diego meeting Date: Sun, 21 Jan 2001 23:59:39 -0500 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200101220459.f0M4xdj03732@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Minutes from TLS Working Group 49th IETF, 12 December 2000 The TLS working group met in a one-hour session at the 49th IETF in San Diego. The agenda was: * Discussion of handling ciphersuite proposals * Presentation on Kerberos ciphersuite revisions * Discussion of AES ciphersuite proposals * Presentation on TLS extension proposal In general, the working group needs to adopt some guidelines for how new applications for ciphersuites are handled. The IANA originally rejected the idea of managing the ciphersuites, but Win Treese will revisit the question with them. Matt Hur of Cisco presented proposed revisions to the Kerberos cipher suites (draft-ietf-tls-kerb-00.txt). The specification details need work, and Eric Rescorla volunteered to help Matt with them. The AES (draft-ietf-tls-ciphersuite-02.txt) ciphersuites were discussed. The general consensus of the group was that the draft is acceptable, with two changes: 1. There should be no mandatory specification in this document 2. There should not be a specification for 192-bit keys, unless complying with the forthcoming Federal Information Processing Specification (FIPS) would require it. John Linn of RSA presented a proposal (draft-ietf-tls-wireless-00.txt) for an extension mechanism and some specific extensions inspired by work with mobile and wireless devices. Some specific comments on the draft have been taken back to the authors. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 00:12:56 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16297 for ; Mon, 22 Jan 2001 00:12:56 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] change of address Date: Mon, 22 Jan 2001 00:05:04 -0500 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200101220505.f0M554c03850@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net As I am no longer with Open Market, please send mail about the TLS working group to me at treese@acm.org. Don't worry, I've already updated the list server. - Win Treese --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 10:16:45 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06191 for ; Mon, 22 Jan 2001 10:16:44 -0500 (EST) Message-ID: From: "Al Arsenault" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Clarification re: certificates in TLS Date: Mon, 22 Jan 2001 10:19:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C0845C.C7740120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <006601c08486$b08d53b0$7901a8c0@CC787228A> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C0845C.C7740120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, Could someone please clarify for me the requirements on client and = server certificates in TLS? I was under the impression that the only certificates supported were = X.509v3, and they are "supposed to be" (although mostly aren't for = legacy & algorithm reasons) compliant with the PKIX spec, RFC 2459. However, looking again at RFC 2246, I found the following: Section 7.4.2, Server certificate: "....The certificate type must = be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509v3 = certificate. ..." (bottom of p. 37) I could read between the lines there, and think that "is generally" = means "isn't always" or "is sometimes not". Should I? Now, later on in the same section (bottom of p. 38) it says: = "...All certificate profiles, key and cryptographic formats are defined by the IETF PKIX working group [PKIX]. ..." For client certificates, section 7.4.6 refers back to 7.4.2. Given the contents of the document as a whole, I believe that the = intent was to mandate X.509v3/PKIX certificates for both clients and = servers. So, my suggestion is to delete the word "generally" from the = line in Section 7.4.2 quoted above, so that people like me won't try to = read too much into it. :-) If the intent is to support other types of certificates, would = somebody like to suggest what types and why? Thanks, Al Arsenault Chief Security Architect Diversinet Corp. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com ------=_NextPart_000_0063_01C0845C.C7740120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
    Could someone please = clarify for=20 me the requirements on client and server certificates in = TLS?
 
    I was under the = impression that=20 the only certificates supported were X.509v3, and they are "supposed to = be"=20 (although mostly aren't for legacy & algorithm reasons) compliant = with the=20 PKIX spec, RFC 2459.
 
    However, looking = again at RFC=20 2246, I found the following:
 
    Section 7.4.2, = Server=20 certificate:  "....The certificate type must be appropriate for the = selected cipher
       suite's key = exchange=20 algorithm, and is generally an X.509v3 certificate. ..." (bottom of p.=20 37)
 
    I could read between = the lines=20 there, and think that "is generally" means "isn't always" or "is = sometimes=20 not".  Should I?
 
    Now, later on in the = same=20 section (bottom of p. 38) it says:  "...All certificate profiles, = key and=20 cryptographic formats are defined
   by the IETF PKIX = working group=20 [PKIX]. ..."
 
    For client = certificates, section=20 7.4.6 refers back to 7.4.2.
 
    Given the contents = of the=20 document as a whole, I believe that the intent was to mandate = X.509v3/PKIX=20 certificates for both clients and servers. So, my=20 suggestion is to delete the word "generally" from the line in Section = 7.4.2=20 quoted above, so that people like me won't try to read too much into it. = :-)
 
    If the intent is to = support=20 other types of certificates, would somebody like to suggest what types = and=20 why?
 
    Thanks,
 
 
       =20             Al=20 Arsenault
       =20             Chief Security=20 Architect
       =20             Diversinet=20 Corp.
 
 
---
You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org
To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com ------=_NextPart_000_0063_01C0845C.C7740120-- From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 10:52:55 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07011 for ; Mon, 22 Jan 2001 10:52:54 -0500 (EST) Date: Mon, 22 Jan 2001 10:52:45 EST From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Clarification re: certificates in TLS In-Reply-To: Your message of Mon, 22 Jan 2001 10:19:18 -0500 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > However, looking again at RFC 2246, I found the following: > > Section 7.4.2, Server certificate: "....The certificate type must = > be appropriate for the selected cipher > suite's key exchange algorithm, and is generally an X.509v3 = > certificate. ..." (bottom of p. 37) > > I could read between the lines there, and think that "is generally" = > means "isn't always" or "is sometimes not". Should I? This opens the door for Kerberos cipher suites and the use of Kerberos tickets in the server or client certificate messages. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 11:34:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08148 for ; Mon, 22 Jan 2001 11:34:43 -0500 (EST) Message-ID: From: "Al Arsenault" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Clarification re: certificates in TLS Date: Mon, 22 Jan 2001 11:37:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <009d01c08491$9e75ab90$7901a8c0@CC787228A> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Jeffrey Altman To: IETF Transport Layer Security WG Cc: IETF Transport Layer Security WG Sent: Monday, January 22, 2001 10:52 AM Subject: [ietf-tls] Re: Clarification re: certificates in TLS > > However, looking again at RFC 2246, I found the following: > > > > Section 7.4.2, Server certificate: "....The certificate type must > = > > be appropriate for the selected cipher > > suite's key exchange algorithm, and is generally an X.509v3 = > > certificate. ..." (bottom of p. 37) > > > > I could read between the lines there, and think that "is > generally" = > > means "isn't always" or "is sometimes not". Should I? > > This opens the door for Kerberos cipher suites and the use of Kerberos > tickets in the server or client certificate messages. > > Okay, then should the comment about "...All certificate profiles, key and cryptographic formats are defined by the IETF PKIX working group [PKIX]. ..." be removed? Kerberos stuff isn't defined by PKIX. Al Arsenault Chief Security Architect Diversinet Corp. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 11:34:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08158 for ; Mon, 22 Jan 2001 11:34:51 -0500 (EST) Message-ID: From: "Al Arsenault" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Clarification re: certificates in TLS Date: Mon, 22 Jan 2001 11:37:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <009d01c08491$9e75ab90$7901a8c0@CC787228A> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Jeffrey Altman To: IETF Transport Layer Security WG Cc: IETF Transport Layer Security WG Sent: Monday, January 22, 2001 10:52 AM Subject: [ietf-tls] Re: Clarification re: certificates in TLS > > However, looking again at RFC 2246, I found the following: > > > > Section 7.4.2, Server certificate: "....The certificate type must > = > > be appropriate for the selected cipher > > suite's key exchange algorithm, and is generally an X.509v3 = > > certificate. ..." (bottom of p. 37) > > > > I could read between the lines there, and think that "is > generally" = > > means "isn't always" or "is sometimes not". Should I? > > This opens the door for Kerberos cipher suites and the use of Kerberos > tickets in the server or client certificate messages. > > Okay, then should the comment about "...All certificate profiles, key and cryptographic formats are defined by the IETF PKIX working group [PKIX]. ..." be removed? Kerberos stuff isn't defined by PKIX. Al Arsenault Chief Security Architect Diversinet Corp. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 12:55:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10312 for ; Mon, 22 Jan 2001 12:55:09 -0500 (EST) Date: Mon, 22 Jan 2001 12:54:49 EST From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" , "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Clarification re: certificates in TLS In-Reply-To: Your message of Mon, 22 Jan 2001 11:37:32 -0500 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > > ----- Original Message ----- > From: Jeffrey Altman > To: IETF Transport Layer Security WG > Cc: IETF Transport Layer Security WG > Sent: Monday, January 22, 2001 10:52 AM > Subject: [ietf-tls] Re: Clarification re: certificates in TLS > > > > > However, looking again at RFC 2246, I found the following: > > > > > > Section 7.4.2, Server certificate: "....The certificate type must > > = > > > be appropriate for the selected cipher > > > suite's key exchange algorithm, and is generally an X.509v3 = > > > certificate. ..." (bottom of p. 37) > > > > > > I could read between the lines there, and think that "is > > generally" = > > > means "isn't always" or "is sometimes not". Should I? > > > > This opens the door for Kerberos cipher suites and the use of Kerberos > > tickets in the server or client certificate messages. > > > > > > Okay, then should the comment about "...All certificate profiles, > key and cryptographic formats are defined > by the IETF PKIX working group [PKIX]. ..." be removed? Kerberos stuff > isn't defined by PKIX. Are you confusing the difference between what is sent during the "Server Certificate" message and the format of the Certificate data? When certificates are used, the profiles, key and crypto formats are indeed specified by PKIX. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jan 22 16:27:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14948 for ; Mon, 22 Jan 2001 16:27:51 -0500 (EST) Message-ID: Date: Mon, 22 Jan 2001 21:19:00 +0000 From: David Hopwood Reply-To: "IETF Transport Layer Security WG" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Clarification re: certificates in TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A6CA3C4.309BBFDF@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Al Arsenault wrote: > However, looking again at RFC 2246, I found the following: > > Section 7.4.2, Server certificate: "....The certificate type must > be appropriate for the selected cipher suite's key exchange algorithm, > and is generally an X.509v3 certificate. ..." (bottom of p. 37) > > I could read between the lines there, and think that "is generally" > means "isn't always" or "is sometimes not". Should I? If new ciphersuites (or possibly extensions) are added, they might allow other certificate formats. However, for all of the existing ciphersuites that use certs, they must be X.509v3. This is possibly constrained further (i.e. to a subset of X.509v3) by an application profile. > Given the contents of the document as a whole, I believe that the > intent was to mandate X.509v3/PKIX certificates for both clients and > servers. Only for the currently defined ciphersuites, not for the TLS protocol. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOmyjqTkCAxeYt5gVAQFs6wgAvGefqqH0NEOrvoDWv/kqY1O4iT0GNsuy iVHLfox8b0hxlQuy/vzta7U3D5rV4+Bxoys3CDIcCnh/gzCLriUkLMJ7SBYhf/99 8KOvbG6Wx77LOcD4n13TYPZ0Gva3imjwdfxqIlqZll6BR4wHW483nRXtognO115J 6cLK1ZgNH1nL6xeymdSL65Ls+n0WcqR3Kdf6ltF14jcG/p0NT759OqDhHsSMRJ1r VXe1pA+6O4jgJaUqT1uJTwSX8nN/bT9neTmZF/hGPXHGHS/mBCYfIX71EhKwLBlr YQmC0tZy35CoTDx0wcnmlHQN04CrPRaXW3oucnNfx+FhWI+WrUjDnQ== =Jz2W -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 23 08:33:23 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10983 for ; Tue, 23 Jan 2001 08:33:22 -0500 (EST) Message-ID: Date: Tue, 23 Jan 2001 14:32:48 +0100 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" CC: IETF Transport Layer Security WG Subject: [ietf-tls] Re: Clarification re: certificates in TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3A6D8800.61204727@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Hopwood wrote: > If new ciphersuites (or possibly extensions) are added, they might allow > other certificate formats. However, for all of the existing ciphersuites > that use certs, they must be X.509v3. This is possibly constrained > further (i.e. to a subset of X.509v3) by an application profile. One question I have is that if the certificate formats, and possibly profiles of are specified on a per-ciphersuite basis, would the same logic apply to the verification of said certificates? The TLS specification, as far as I can tell, only mentions certificate verification very briefly in section D.3. If the current set of ciphersuites employ (un-profiled) X.509v3 certificates, would it then follow that verification of said certificates is to be performed according to the path validation algorithm of X.509 (1997)? Or is this left to the implementors discretion? Cheers, //oscar --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 30 09:26:49 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07562 for ; Tue, 30 Jan 2001 09:26:48 -0500 (EST) Reply-To: "IETF Transport Layer Security WG" From: "Limor Elbaz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Wireless TLS Date: Tue, 30 Jan 2001 16:23:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <004801c08ac8$27e51230$010710ac@discretix.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hi, Does anyone know where can I find information about ideal blocksize for tpc to http communication in wireless applications? I'm refering mainly implementing SSL and TLS (Not WTLS standard). Thanks, Limor Elbaz Discretix Technologies, Ltd. 43 Hamelacha st. Nathania, Israel Tel: 972-9-8858810 Fax: 972-9-8858820 Mobile: 972-56-338332 Email: Limor.Elbaz@Discretix.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jan 30 21:47:19 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21635 for ; Tue, 30 Jan 2001 21:47:18 -0500 (EST) Subject: [ietf-tls] Proposal: SRP as a TLS authentication mechanism To: "IETF Transport Layer Security WG" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "David Taylor" Date: Wed, 31 Jan 2001 13:47:41 +1100 X-MIMETrack: Serialize by Router on macha.forge.com.au/Forge(Release 5.0.4 |June 8, 2000) at 01/31/2001 01:47:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi all, While doing some work with SASL and SRP recently, I realised I was trying to recreate the TLS session/connection relationship using an SASL mechanism. After finishing the design I went back to our TLS implementation and added a TLS_SRP_IDEA_CBC_SHA cipher suite as a proof of concept. This is almost done and seems like it will work (the client and server are using the 40-byte shared secret generated by the SRP algorithm as the pre-master secret). No new handshake messages were required, although extra data was added to the client hello message, and the handshake now has client and server messages interleaved while exchanging SRP parameters. Does the idea of name/password client authentication built into TLS sound useful or not? Looking through the TLS mailing list archives, it seems there has been some interest in secure passwords and TLS, but there also seemed to be a lot of opposition to the idea. The main point seemed to be that application protocols can use SASL (or something similar) to improve their security, so there is no point adding these features to TLS. If this SRP work is of interest, I will write a document describing the changes to the handshake protocol and the messages. If the idea takes off, I will also review the earlier documents produced when people were talking about this a few years ago (if I can still find them via the links in the e-mails) and see if they have a better mechanism than the handshake I'm using at present. Regards, David Taylor Forge Information Technology. http://www.forge.com.au http://www.protekt.com Ph: +61 2 9209 4152 Fax: +61 2 9209 4172 ----------------------------------------------------------------------------------------------------------------------------------------- This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). ----------------------------------------------------------------------------------------------------------------------------------------- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jan 31 00:58:43 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23998 for ; Wed, 31 Jan 2001 00:58:38 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Tue, 30 Jan 2001 22:59:16 -0800 From: Tom Wu Organization: Arcot Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Proposal: SRP as a TLS authentication mechanism Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3A77B7C4.242DCC15@arcot.com> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Taylor wrote: > > Hi all, > > While doing some work with SASL and SRP recently, I realised I was trying > to recreate the TLS session/connection relationship using an SASL > mechanism. > > After finishing the design I went back to our TLS implementation and added > a TLS_SRP_IDEA_CBC_SHA cipher suite as a proof of concept. This is almost > done and seems like it will work (the client and server are using the > 40-byte shared secret generated by the SRP algorithm as the pre-master > secret). No new handshake messages were required, although extra data was > added to the client hello message, and the handshake now has client and > server messages interleaved while exchanging SRP parameters. I'd be very interested in reviewing your proposal, since getting secure password auth integrated with SSL is a nontrivial accomplishment. > Does the idea of name/password client authentication built into TLS sound > useful or not? > > Looking through the TLS mailing list archives, it seems there has been some > interest in secure passwords and TLS, but there also seemed to be a lot of > opposition to the idea. The main point seemed to be that application > protocols can use SASL (or something similar) to improve their security, so > there is no point adding these features to TLS. Since TLS already supports client authentication, and since Kerberos ciphersuties have been defined, it seems that user authentication/identification is within the scope of TLS. Strong password-based authentication should make it even more widely usable. One application where this would be applicable is the secure Telnet-over-TLS distribution I'm working on; currently authentication is done by using SRP to authenticate the TLS Finished messages, but integrating it into the handshake may prove to be a cleaner solution. > If this SRP work is of interest, I will write a document describing the > changes to the handshake protocol and the messages. If the idea takes off, > I will also review the earlier documents produced when people were talking > about this a few years ago (if I can still find them via the links in the > e-mails) and see if they have a better mechanism than the handshake I'm > using at present. > > Regards, > David Taylor > Forge Information Technology. > > http://www.forge.com.au > http://www.protekt.com > > Ph: +61 2 9209 4152 > Fax: +61 2 9209 4172 > > ----------------------------------------------------------------------------------------------------------------------------------------- > > This message contains privileged and confidential information intended only > for the use of > the addressee named above. If you are not the intended recipient of this > message you > must not disseminate, copy or take any action in reliance on it. If you > have received > this message in error please notify the sender immediately. Any views > expressed in this > message are those of the individual sender, except where the sender > specifically states > them to be the views of another (including a Body Corporate). > ----------------------------------------------------------------------------------------------------------------------------------------- Tom -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com