From bounce-ietf-tls-3458737@lists.certicom.com Sun Oct 1 18:37:00 2000 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 SAA12948 for ; Sun, 1 Oct 2000 18:36:59 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-025.dialup.zetnet.co.uk [194.247.41.31] claimed to be zetnet.co.uk Message-ID: Date: Sun, 01 Oct 2000 21:19:46 +0100 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] AES ciphersuites (was Proposed New Charter) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39D79C62.55AAFA14@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Pete Chown wrote: [snip] > > A better reason for not considering RC4 sufficient, is that the public > > cryptographic community has more experience in analysing the security > > of block ciphers than stream ciphers. > > Hmm, that's an interesting one. I've often thought myself that RC4 is > too simple to be really secure... IMHO this type of comment does not > belong in the RFC, though. No, it doesn't (hopefully analysis of stream ciphers will catch up to some extent). [...] > > Despite that, I think it would be a good idea to also include > > > > CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00, 0x66 }; > > CipherSuite TLS_DHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x67 }; > > > > in the draft. On second thoughts, I'll withdraw the suggestion of TLS_DHE_RSA_WITH_RC4_128_SHA. The reason is that a client has to include a DHE_DSS ciphersuite (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) in the client hello in order to guarantee interoperability [*]. If it includes two key exchange algorithms, an attacker will have a choice of which to break. Because of this, and because DSS signing is faster than RSA signing, there there is not really any advantage in adding new DHE_RSA ciphersuites. (There might be an advantage if it was mandated that servers support more than one algorithm - preferably based on independent PK cryptosystems, e.g. DHE_DSS and Elliptic Curve DHE with ECDSA - so that the client could effectively choose which to use. However, that should probably wait until the next version of TLS.) On the same grounds, I suggest only defining TLS_DHE_DSS_WITH_AES_128_CBC_SHA for the time being. I.e. the new ciphersuites would be: CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x2F }; CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00, 0x66 }; [*] Strictly speaking, the spec only says that TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA has to be implemented, not that clients and servers have to be able to negotiate it. However, I think most client writers have interpreted that as meaning that this ciphersuite "SHOULD" be in the client hello. > > The first of these was defined at the same time as the 56-bit > > ciphersuites (although it is not an export ciphersuite). The second is new; > > it's just the same thing for RSA signing keys. > > I think these ciphersuites make sense, along with Blowfish ones. > Unfortunately the goal at the moment seems to be to give the AES > ciphersuites priority. TLS_DHE_DSS_WITH_RC4_128_SHA is already implemented by several TLS clients and servers, so I'm not sure why there would be any point to a delay in documenting it. Does anyone object to it being included in the draft? As for Blowfish, the AES winner is being announced tomorrow (Monday 2nd), so we'll have more information then to decide whether it is worth adding ciphersuites for both Blowfish and AES. > > > The overall strength of TLS is such that > > > there is no gain from using a key length longer than 128 bits. > > > > OTOH, there is no loss of speed from using 256-bit keys either (except > > in the case of Rijndael). I'll have to have a look at the AES candidate > > key schedules more closely, to see whether there would be any advantage > > in using 256-bit keys (brute force attacks aren't significant for these > > key lengths, but other attacks might be). > > I've kicked this one backwards and forwards in my own mind. My old > draft had 256-bit keys, but then I changed my mind when I thought > about the security of the rest of the system. Yes, the Finished hashes are 96 bits, for example. Might as well wait until we know what AES is until deciding. - -- 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 iQEVAwUBOdecLTkCAxeYt5gVAQGkSQf/XrkGSoa4elySUF/F9fD22JkOp0/5b7Ur mH+L6iIjf1A9vHh1CMyDaSwXQQykyTdbL2cGHfz0z+QO9GuQ/OfjQ2VbEcI0S5b1 s3phn/g3LwN1xJMW/iNtE/BseZNo841Qdy5U6hX/jrxtHNk09Bs52vlROsw+rCs2 vSLYtZAe9AuaEC4owApNqoO1iPY0XFzUYJDD4BuYgBgBX2TOixB1GoekG7RivGZQ ckD0HjASJTvwhg79XMYWYYtBLMXMlyXLhzbYD2/JMwJVr0Y42RrlofhkxzWFi6pJ zTcA8YrDH61JJ7hj2PFSZIL07hwtEsQQSfCrkVGlAucMb2Mg4mn9eQ== =8wIi -----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 Mon Oct 2 14:31:27 2000 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 OAA12173 for ; Mon, 2 Oct 2000 14:31:26 -0400 (EDT) Date: Mon, 2 Oct 2000 19:30:46 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from hopwood@zetnet.co.uk on Sun, Oct 01, 2000 at 09:19:46PM +0100 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001002193046.A9838@hyena.skygate.co.uk> X-List-Host: SKYLIST.net So it's Rijndael! Why did they have to choose the one algorithm with an unpronounceable name? :-) I do like the 256-bit blocks though. It will be cool to be able to have a 256-bit hash by using Rijndael as a compression function. Anyway, back to the hard work... There is another version of my AES ciphersuite draft at the usual URL: ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ There is lots more text, but no really significant changes. I have included the intellectual property statements from Rijndael in the draft, and included a reference to the Rijndael paper. There are also a few typos fixed. BTW, does anyone know if the Rijndael paper was ever published in a proper journal? At the moment all I've got is the URL on the NIST site, and that could go away. It would be nice to be able to refer people to a paper journal that is likely to remain in libraries for a reasonable time. David Hopwood wrote: > Because of this, and because DSS signing is faster than RSA signing, > there there is not really any advantage in adding new DHE_RSA > ciphersuites. One problem is that DSA certificates never really took off, so there is a practical advantage to adding a new RSA ciphersuite. Also, because DSA verification is slower than RSA there may be circumstances where it is useful. In the https scenario, it is best to have efficient signing because the verification load is distributed amongst all of a web site's clients. However, in other scenarios the objective may be to minimise the overall amount of processing. For example in TLS-secured CORBA, there is probably no reason to push processing onto either the client or the server -- they are often peers. > TLS_DHE_DSS_WITH_RC4_128_SHA is already implemented by several TLS clients > and servers, so I'm not sure why there would be any point to a delay in > documenting it. Does anyone object to it being included in the draft? I do... :-) Seriously, though, I had two reasons for leaving it out, along with the other ciphersuites that were in my original draft. Firstly there seemed to be a lot of disagreement about how the other ciphersuites ought to work, so I doubted whether the necessary consensus could be achieved. Secondly I was going by Win's comment that he wanted the WG to consider the AES ciphersuites separately (http://www.imc.org/ietf-tls/mail-archive/msg04403.html if you are interested). Actually I don't know how happy I'd be about new RC4 ciphersuites anyway. Calling RC4 "Arcfour" and saying that it is free of IP claims is just the sort of thing that makes corporate lawyers nervous. But if we defined RC4 ciphersuites, implementations would appear that only implemented, say, 3DES and RC4. Then if you wanted to interwork you would have to choose between "slow" and "legally dodgy". > As for Blowfish, the AES winner is being announced tomorrow (Monday 2nd), > so we'll have more information then to decide whether it is worth adding > ciphersuites for both Blowfish and AES. Well, it's Rijndael. Perhaps we should have Blowfish because everyone knows how to pronounce that! :-) -- Pete --- 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 Oct 2 15:28:54 2000 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 PAA12976 for ; Mon, 2 Oct 2000 15:28:53 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 02 Oct 2000 12:31:51 -0700 In-Reply-To: Pete Chown's message of "Mon, 2 Oct 2000 19:30:46 +0100" Message-ID: Lines: 20 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 Pete Chown writes: > So it's Rijndael! Why did they have to choose the one algorithm with > an unpronounceable name? :-) > > I do like the 256-bit blocks though. It will be cool to be able to > have a 256-bit hash by using Rijndael as a compression function. > > Anyway, back to the hard work... There is another version of my AES > ciphersuite draft at the usual URL: > > ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ > > There is lots more text, but no really significant changes. I have > included the intellectual property statements from Rijndael in the > draft, and included a reference to the Rijndael paper. There are also > a few typos fixed. Please submit this as an I-D. -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 Mon Oct 2 16:16:20 2000 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 QAA13578 for ; Mon, 2 Oct 2000 16:16:19 -0400 (EDT) Message-ID: Date: Mon, 02 Oct 2000 21:16:22 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39D8ED16.35A9201C@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > > David Hopwood wrote: > > > Because of this, and because DSS signing is faster than RSA signing, > > there there is not really any advantage in adding new DHE_RSA > > ciphersuites. > > One problem is that DSA certificates never really took off, so there > is a practical advantage to adding a new RSA ciphersuite. > Also almost all servers will have an RSA certificate to support browsers, if they have to obtain (or purchase) a new DSA certificate each year this could discourage the use of AES ciphersuites. > Also, because DSA verification is slower than RSA there may be > circumstances where it is useful. In the https scenario, it is best > to have efficient signing because the verification load is distributed > amongst all of a web site's clients. However, in other scenarios the > objective may be to minimise the overall amount of processing. For > example in TLS-secured CORBA, there is probably no reason to push > processing onto either the client or the server -- they are often > peers. > Another case if where the client platform is relatively slow. The enforced use of DSA verification could significantly affect performance. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 3 04:07:41 2000 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 EAA04276 for ; Tue, 3 Oct 2000 04:07:40 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Date: Tue, 3 Oct 2000 10:06:28 +0200 Organization: IAIK MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.36A6BCD7--"; protocol="application/x-pkcs7-signature" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <006701c02d10$d6cf4b50$4c981b81@iaik.tugraz.ac.at> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.36A6BCD7-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pete Chown wrote: > Anyway, back to the hard work... There is another version of my AES > ciphersuite draft at the usual URL: > > ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ I think this is a fine draft, but I am in favor in adding an AES ciphersuite with an RSA key exchange as well, i.e. TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional overhead of ephemeral ciphersuites is not significant, I believe we cannot assume this will be the case for all applications. Forward secrecy is of course an argument, but I would like to see the server key exchange message be allowed for the RSA key exchange anyway. Some implementations already accept it by the way. But this does not really have anything to do with AES. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----IAIK.SMIME.MAPPER.36A6BCD7-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVODCCBFkwggNFoAMCAQICAw9CzTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTIwMTEzMzcyOVoXDTAwMTIw MTEzMzcyOVowgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEEFuZHJlYXMgU3RlcmJlbnowgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGB AONpF50rZXkgpQWGwLefFIVegTpRUtz8rH5d/QzYopDsznBivkmoGxOQdpGQC3+g fi2TXVI/w0GmdTwmOpB7IL6RIZ+duVqOj/9Vxt/75vB5cimp6doadlg0fi8UdlPU YgbpIeFp0DGExFf9I8Xi/JS0DQdRcNOMMdT+2vHA8HzfAgEFo4G6MIG3MDgGA1Ud HwQxMC8wLaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlL Q1JMMTARBglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2Vy dGlmaWNhdGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAjBgNVHREEHDAagRhBbmRy ZWFzLlN0ZXJiZW56QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEB AKagdoFWr6bm0N9+TW+7HECJErm+sq39d10wKSdWYBLZ8BRst3QzslC2ErzAap5Q EQvpwl2qEczDqeJs2V2RvqzHvpMd61idNvhIROSQrB8d+2o9qgO3mJo1zFmWi6co 1wNm7nmBvZU0H3jbRH+yEUVEKENF1UmS3UCjKziZcj7yvphBJjJcZblvlvDocm6A 8JTwXaDaoTsdUyzG74hnaMc/sdWLUXHUW/jwzQVPAZz+YCEN5OzyDbzmfRowmb4I ybaCVRQnDijOmZYraj+huWcrDPzq3sOErr7cnxXfhCBjfUiufg9/t9B+Uwp7E16H a8QS4k/2GvIU6xyzZNdt0XcwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZ MQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElO VFJBTkVUIENBMB4XDTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQsw CQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYD VQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkg T0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5m b3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsT EElBSUsgSU5UUkFORVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAg BgNVBAwTGUlBSUsgZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEB AQUAA4IBDQAwggEIAoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwV Hu1+XFLJeJ85AICkSQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/h Eb1T7XgO12ptG80qSOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4Hkr Nw5uH/vsJ72wRcRTFzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5Ff CknoMMCitSD38cULCCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64S urLoUUShPv108ELE6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgB hvhCAQEEBAMCAAIwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4D Ah0FAAOCAQEAc26nvl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUc ePEmXkKsFP4NuCFx2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZ Ukx99K70ncVxkwq7rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOK PbrBjZxjmXwBbZ7tsfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQ F50+Pt8ioAgZ/SAudxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTD kRLD/h8LKC1OpKV8lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZI hvcNAQEEBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1 OTMwWjCBmTELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBP RiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZv cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQ SUFJSyBJTlRSQU5FVCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB AMLr+IHe6qeAtYLkfvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnz h2MuAq84JS58zX5xLqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/ BWlXuZU33lgGky/RX84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVD QaQw+HRCvr7T4mAVYi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0u nIYWwUn1YzQI2RNBAjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWo i+btPX8oWDl5+7DEtCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/ oGofngJzbQLa7X2shWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVe qScURuwuihFURPhI7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347d XhKJOYJ0tsA583afEKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgD Z4NcCpiRSv9mWw6sPYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRG RztKQWeUiBLkqFCQxsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIEWTCCA0Wg AwIBAgIDHoUNMAkGBSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMG U3R5cmlhMQ0wCwYDVQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZh MSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UE CxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZ BgNVBAMTEklBSUsgVFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRl bnRpYWxpdHkgQ0EwHhcNOTkxMjAxMTM0MTQ2WhcNMDAxMjAxMTM0MTQ2WjCBmTEL MAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9M T0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQ cm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQQW5kcmVhcyBT dGVyYmVuejCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEAtTnY8l5rJXqdLGEs QFNR1uDX8lSDs5YdOHIBR0W4pFB4Z7010JRSQIB+ep0yna56BiFSiZRgluwcwzOZ A/wmtkIXxNPmTkbykmdDy9wUbIqkW0to18m1P5VA7mOmyQB3mDmRQFP17jSA2ZNu TaG7VBczGgt8v8E6DZO2vVUWZ8kCAQWjgbowgbcwOAYDVR0fBDEwLzAtoCugKaQn MCUxEDAOBgNVBAoTB2lhaWsuYXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG +EIBAQQEAwIAoDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRS QU5FVDAMBgNVHRMEBTADAQEAMCMGA1UdEQQcMBqBGEFuZHJlYXMuU3RlcmJlbnpA aWFpay5hdDALBgNVHQ8EBAMCA3gwCQYFKw4DAh0FAAOCAQEApyn/jb6x8/3tJCxM ke196dxNDrEQ+SB5aWEO5jL7L4CyU2RefUf5J+UCmSk8h6a4GqsA+iNRLuuM4lq1 2QO8sUwBTHqsRrkQKgK3dzVpWdtnndlr2E0Ry6gbi1RVwCAujjbZRxt+TvUNj9Pa 7e69W8sSHuUYVQdQcgDHc1bDbYsBHS8vikdM0kGBr65QiQpbcOvVF+iEMiVnIYhE u51uCkbe4UbdyrF545TJ0rSw/HjsfUIaHxTwfDv+wzNHQduxflao3YqoEhTGX/E7 82H2Ii/J6FJFimYe3vRywHBMV6eKoQ9MzQtAsRRIlnPlmdw62+L/Q9ayPcWPadf1 dRn1JTCCBFQwggNAoAMCAQICAnUwMAkGBSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFU MSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UE CxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5UUkFORVQgQ0EwHhcN OTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8w DQYDVQQIEwZTdHlyaWExDTALBgNVBAcTBEdyYXoxGTAXBgNVBAkTEEluZmZlbGRn YXNzZSAxNmExJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UECxMQSUFJSyBJTlRSQU5F VCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1HUkFaIENSWVBUMSAwHgYDVQQMExdJQUlL IGNvbmZpZGVudGlhbGl0eSBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgC ggEBAMEnzjatic90xi5VRmr0i2O16Z1aSElQFZitoNvAzGw+KehOTuKeUr5ALHib 9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKyqvZ+KphGy6ag6VcCVySJmeY1AqTM0W78 XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNgo4UMVdxjGHJweibT1AGvlFe2Bqulwtuw OLovMIuIyHHh+o6F2HXYKUB54GJpia1B2IfmqcpBBFdYtDlHyrxugB5QhuhLo0Bj D8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl12cZKkqaqPpOgP/znsdh62QBSabrRluvC p9OQW9M8u+mJlrxIIVwtThfzIW0CAQWjMzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAP BgNVHRMECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4J IzqbBydvFOaP/dA5D/GLWEWjPTF8tKcPhxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o 9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0CuxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0 QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64vGX+ayZn2P7naGHPfYjCBWUKzW0zS8ch Vf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSLCMmFEDc99iNzcCU7ILn+RgWPNYPVhCUq oDQ6buX00ohfNVS/OHgqkWpa1HLvLRXqE9NmYUJvfhE2zCY6w6bTME3IfDCXRat2 Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEwggEcMIIBEzELMAkGA1UEBhMCQVQxDzAN BgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5mZmVsZGdh c3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kx RzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nl c3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElOVFJBTkVU IENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJQUlLIGVs ZWN0cm9uaWMgc2lnbmF0dXJlAgMPQs0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEwMDMwODA2MzFaMCMG CSqGSIb3DQEJBDEWBBQCmphbsnyxQ9FJjrRlMdQSkX57ezBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAN BggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkqhkiG9w0BAQEFAASBgEDhkVAZjnXk oAwdh+Vv9MRtLdLF5VJ0Iw16Z9sD7Ecwkx8ITpr3rjH9Jce6xjJTYQHVz4f9Lo5a xMHoUY1b/jGiWbt31fjkEd2XPvTxE465VNARXc0yGurhIN6Bh6q6MPqK17W4RwsY wNgSMt8Zqk5yl06InEnWYNAq0xjWUU/uAAAAAAAA ----IAIK.SMIME.MAPPER.36A6BCD7-- Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 ----IAIK.SMIME.MAPPER.36A6BCD7---- From bounce-ietf-tls-3458737@lists.certicom.com Tue Oct 3 04:12:25 2000 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 EAA04311 for ; Tue, 3 Oct 2000 04:12:24 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Extension Mechanism (was Proposed New Charter) Date: Tue, 3 Oct 2000 10:11:33 +0200 Organization: IAIK MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.06EA8D14--"; protocol="application/x-pkcs7-signature" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <007301c02d11$8b473ed0$4c981b81@iaik.tugraz.ac.at> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.06EA8D14-- Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Win Trees wrote: > There is not such a plan right now, although the proposed charter > doesn't rule it out. The charter is focused on advancing TLS on the > standards track, so now is the time for concrete proposals. I seem to recall there was a draft quite some time ago maybe we could go from there. Does anyone know where we could find that? Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----IAIK.SMIME.MAPPER.06EA8D14-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVODCCBFkwggNFoAMCAQICAw9CzTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTIwMTEzMzcyOVoXDTAwMTIw MTEzMzcyOVowgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEEFuZHJlYXMgU3RlcmJlbnowgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGB AONpF50rZXkgpQWGwLefFIVegTpRUtz8rH5d/QzYopDsznBivkmoGxOQdpGQC3+g fi2TXVI/w0GmdTwmOpB7IL6RIZ+duVqOj/9Vxt/75vB5cimp6doadlg0fi8UdlPU YgbpIeFp0DGExFf9I8Xi/JS0DQdRcNOMMdT+2vHA8HzfAgEFo4G6MIG3MDgGA1Ud HwQxMC8wLaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlL Q1JMMTARBglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2Vy dGlmaWNhdGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAjBgNVHREEHDAagRhBbmRy ZWFzLlN0ZXJiZW56QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEB AKagdoFWr6bm0N9+TW+7HECJErm+sq39d10wKSdWYBLZ8BRst3QzslC2ErzAap5Q EQvpwl2qEczDqeJs2V2RvqzHvpMd61idNvhIROSQrB8d+2o9qgO3mJo1zFmWi6co 1wNm7nmBvZU0H3jbRH+yEUVEKENF1UmS3UCjKziZcj7yvphBJjJcZblvlvDocm6A 8JTwXaDaoTsdUyzG74hnaMc/sdWLUXHUW/jwzQVPAZz+YCEN5OzyDbzmfRowmb4I ybaCVRQnDijOmZYraj+huWcrDPzq3sOErr7cnxXfhCBjfUiufg9/t9B+Uwp7E16H a8QS4k/2GvIU6xyzZNdt0XcwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZ MQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElO VFJBTkVUIENBMB4XDTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQsw CQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYD VQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkg T0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5m b3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsT EElBSUsgSU5UUkFORVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAg BgNVBAwTGUlBSUsgZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEB AQUAA4IBDQAwggEIAoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwV Hu1+XFLJeJ85AICkSQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/h Eb1T7XgO12ptG80qSOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4Hkr Nw5uH/vsJ72wRcRTFzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5Ff CknoMMCitSD38cULCCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64S urLoUUShPv108ELE6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgB hvhCAQEEBAMCAAIwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4D Ah0FAAOCAQEAc26nvl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUc ePEmXkKsFP4NuCFx2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZ Ukx99K70ncVxkwq7rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOK PbrBjZxjmXwBbZ7tsfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQ F50+Pt8ioAgZ/SAudxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTD kRLD/h8LKC1OpKV8lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZI hvcNAQEEBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1 OTMwWjCBmTELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBP RiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZv cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQ SUFJSyBJTlRSQU5FVCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB AMLr+IHe6qeAtYLkfvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnz h2MuAq84JS58zX5xLqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/ BWlXuZU33lgGky/RX84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVD QaQw+HRCvr7T4mAVYi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0u nIYWwUn1YzQI2RNBAjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWo i+btPX8oWDl5+7DEtCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/ oGofngJzbQLa7X2shWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVe qScURuwuihFURPhI7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347d XhKJOYJ0tsA583afEKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgD Z4NcCpiRSv9mWw6sPYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRG RztKQWeUiBLkqFCQxsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIEWTCCA0Wg AwIBAgIDHoUNMAkGBSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMG U3R5cmlhMQ0wCwYDVQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZh MSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UE CxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZ BgNVBAMTEklBSUsgVFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRl bnRpYWxpdHkgQ0EwHhcNOTkxMjAxMTM0MTQ2WhcNMDAxMjAxMTM0MTQ2WjCBmTEL MAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9M T0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQ cm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQQW5kcmVhcyBT dGVyYmVuejCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEAtTnY8l5rJXqdLGEs QFNR1uDX8lSDs5YdOHIBR0W4pFB4Z7010JRSQIB+ep0yna56BiFSiZRgluwcwzOZ A/wmtkIXxNPmTkbykmdDy9wUbIqkW0to18m1P5VA7mOmyQB3mDmRQFP17jSA2ZNu TaG7VBczGgt8v8E6DZO2vVUWZ8kCAQWjgbowgbcwOAYDVR0fBDEwLzAtoCugKaQn MCUxEDAOBgNVBAoTB2lhaWsuYXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG +EIBAQQEAwIAoDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRS QU5FVDAMBgNVHRMEBTADAQEAMCMGA1UdEQQcMBqBGEFuZHJlYXMuU3RlcmJlbnpA aWFpay5hdDALBgNVHQ8EBAMCA3gwCQYFKw4DAh0FAAOCAQEApyn/jb6x8/3tJCxM ke196dxNDrEQ+SB5aWEO5jL7L4CyU2RefUf5J+UCmSk8h6a4GqsA+iNRLuuM4lq1 2QO8sUwBTHqsRrkQKgK3dzVpWdtnndlr2E0Ry6gbi1RVwCAujjbZRxt+TvUNj9Pa 7e69W8sSHuUYVQdQcgDHc1bDbYsBHS8vikdM0kGBr65QiQpbcOvVF+iEMiVnIYhE u51uCkbe4UbdyrF545TJ0rSw/HjsfUIaHxTwfDv+wzNHQduxflao3YqoEhTGX/E7 82H2Ii/J6FJFimYe3vRywHBMV6eKoQ9MzQtAsRRIlnPlmdw62+L/Q9ayPcWPadf1 dRn1JTCCBFQwggNAoAMCAQICAnUwMAkGBSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFU MSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UE CxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5UUkFORVQgQ0EwHhcN OTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8w DQYDVQQIEwZTdHlyaWExDTALBgNVBAcTBEdyYXoxGTAXBgNVBAkTEEluZmZlbGRn YXNzZSAxNmExJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UECxMQSUFJSyBJTlRSQU5F VCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1HUkFaIENSWVBUMSAwHgYDVQQMExdJQUlL IGNvbmZpZGVudGlhbGl0eSBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgC ggEBAMEnzjatic90xi5VRmr0i2O16Z1aSElQFZitoNvAzGw+KehOTuKeUr5ALHib 9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKyqvZ+KphGy6ag6VcCVySJmeY1AqTM0W78 XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNgo4UMVdxjGHJweibT1AGvlFe2Bqulwtuw OLovMIuIyHHh+o6F2HXYKUB54GJpia1B2IfmqcpBBFdYtDlHyrxugB5QhuhLo0Bj D8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl12cZKkqaqPpOgP/znsdh62QBSabrRluvC p9OQW9M8u+mJlrxIIVwtThfzIW0CAQWjMzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAP BgNVHRMECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4J IzqbBydvFOaP/dA5D/GLWEWjPTF8tKcPhxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o 9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0CuxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0 QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64vGX+ayZn2P7naGHPfYjCBWUKzW0zS8ch Vf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSLCMmFEDc99iNzcCU7ILn+RgWPNYPVhCUq oDQ6buX00ohfNVS/OHgqkWpa1HLvLRXqE9NmYUJvfhE2zCY6w6bTME3IfDCXRat2 Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEwggEcMIIBEzELMAkGA1UEBhMCQVQxDzAN BgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5mZmVsZGdh c3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kx RzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nl c3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElOVFJBTkVU IENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJQUlLIGVs ZWN0cm9uaWMgc2lnbmF0dXJlAgMPQs0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEwMDMwODExMzRaMCMG CSqGSIb3DQEJBDEWBBT6U9HC8/LNfGfYYLaUcJ3wJoJXijBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAN BggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkqhkiG9w0BAQEFAASBgMQXF0Vvimlg LylopVSNBK4KHONN2mkIWT3SlrmmWlZSo49vplX2XppeqQyuwa1pG7TuWufwgLLp b5eEVtrrFEUghukzzRWiacKkqXS/NyHmAvKiVBhAPadmH/6TuyEcp0OW2GG9Jxva y4HQXaYNiXQMTTBNzjZGPs1FGGi4GG83AAAAAAAA ----IAIK.SMIME.MAPPER.06EA8D14-- Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 ----IAIK.SMIME.MAPPER.06EA8D14---- From bounce-ietf-tls-3458737@lists.certicom.com Tue Oct 3 05:35:08 2000 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 FAA04824 for ; Tue, 3 Oct 2000 05:35:07 -0400 (EDT) Date: Tue, 3 Oct 2000 10:34:43 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from ekr@rtfm.com on Mon, Oct 02, 2000 at 12:31:51PM -0700 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001003103443.E18481@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Eric Rescorla wrote: > Please submit [the AES ciphersuite draft] as an I-D. Good idea -- now done. I will send another message to the list once it is available from the Internet Drafts directory. -- Pete --- 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 Oct 3 06:50:14 2000 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 GAA05498 for ; Tue, 3 Oct 2000 06:50:13 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-misty1-00.txt Date: Tue, 03 Oct 2000 06:49:57 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200010031049.GAA05482@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Addition of MISTY1 to TLS Author(s) : H. Ohta, H. Tsuji Filename : draft-ietf-tls-misty1-00.txt Pages : 3 Date : 02-Oct-00 This document proposes the addition of new cipher suites to the TLS protocol version 1.0 to support the MISTY1 encryption algorithm as a bulk cipher algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-misty1-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-misty1-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-misty1-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-misty1-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-misty1-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120706.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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-- From bounce-ietf-tls-3458737@lists.certicom.com Tue Oct 3 12:24:04 2000 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 MAA15932 for ; Tue, 3 Oct 2000 12:24:03 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 17:07:53 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DA0459.94A482BF@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Andreas Sterbenz wrote: > I think this is a fine draft, but I am in favor in adding an AES > ciphersuite with an RSA key exchange as well, i.e. > TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional > overhead of ephemeral ciphersuites is not significant, I believe we > cannot assume this will be the case for all applications. > Yes I suppose there's the client overhead to consider again for low powered clients. The client DH operations are considerably slower than the corresponding RSA encrypt and verify operations. > Forward secrecy is of course an argument, but I would like to see the > server key exchange message be allowed for the RSA key exchange anyway. > Some implementations already accept it by the way. But this does not > really have anything to do with AES. > This is a bit of a problem because the TLS spec bans the use of server key exchange except for certain export ciphers. If AES ciphersuites existed supporting RSA key exchange then I suppose the key exchange message could be specifically permitted. That wouldn't help already existing ciphersuites though. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 3 12:30:05 2000 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 MAA16147 for ; Tue, 3 Oct 2000 12:30:04 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 03 Oct 2000 09:33:22 -0700 In-Reply-To: Dr S N Henson's message of "Tue, 03 Oct 2000 17:07:53 +0100" Message-ID: Lines: 37 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 Dr S N Henson writes: > Andreas Sterbenz wrote: > > > I think this is a fine draft, but I am in favor in adding an AES > > ciphersuite with an RSA key exchange as well, i.e. > > TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional > > overhead of ephemeral ciphersuites is not significant, I believe we > > cannot assume this will be the case for all applications. > > > > Yes I suppose there's the client overhead to consider again for low > powered clients. The client DH operations are considerably slower than > the corresponding RSA encrypt and verify operations. > > > Forward secrecy is of course an argument, but I would like to see the > > server key exchange message be allowed for the RSA key exchange anyway. > > Some implementations already accept it by the way. But this does not > > really have anything to do with AES. > > > > This is a bit of a problem because the TLS spec bans the use of server > key exchange except for certain export ciphers. If AES ciphersuites > existed supporting RSA key exchange then I suppose the key exchange > message could be specifically permitted. That wouldn't help already > existing ciphersuites though. Steve, I think you're misreading Andreas's message. If I read it correctly, He doesn't want Ephemeral RSA. He wants static RSA, which isn't in the draft. I totally agree here. On the other hand, the value of ephemeral RSA strikes me as minimal. -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 Oct 3 12:36:29 2000 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 MAA16341 for ; Tue, 3 Oct 2000 12:36:29 -0400 (EDT) Date: Tue, 3 Oct 2000 11:46:40 -0500 From: Jeremey Barrett To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Message-ID: Reply-To: "IETF Transport Layer Security WG" Mail-Followup-To: IETF Transport Layer Security WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from Andreas.Sterbenz@iaik.at on Tue, Oct 03, 2000 at 10:06:28AM +0200 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <20001003114640.I19836@jfm.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Tue, Oct 03, 2000 at 10:06:28AM +0200, Andreas Sterbenz wrote: > > I think this is a fine draft, but I am in favor in adding an AES > ciphersuite with an RSA key exchange as well, i.e. > TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional > overhead of ephemeral ciphersuites is not significant, I believe we > cannot assume this will be the case for all applications. > I'd really like to see this as well. In fact, with RSA unencumbered, I'd like to see some (non-ephemeral) RSA as a MUST. Perhaps TLS_RSA_WITH_AES_128_CBC_SHA would be a good candidate? Regards, Jeremey. -- Jeremey Barrett [jeremey@cips.nokia.com, jeremey@network-alchemy.com] GnuPG fingerprint: 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F --- 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 Oct 3 13:17:20 2000 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 NAA18377 for ; Tue, 3 Oct 2000 13:17:19 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 18:17:49 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DA14BD.B39D7332@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Dr S N Henson writes: > > > Andreas Sterbenz wrote: > > > > > I think this is a fine draft, but I am in favor in adding an AES > > > ciphersuite with an RSA key exchange as well, i.e. > > > TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional > > > overhead of ephemeral ciphersuites is not significant, I believe we > > > cannot assume this will be the case for all applications. > > > > > > > Yes I suppose there's the client overhead to consider again for low > > powered clients. The client DH operations are considerably slower than > > the corresponding RSA encrypt and verify operations. > > > > > Forward secrecy is of course an argument, but I would like to see the > > > server key exchange message be allowed for the RSA key exchange anyway. > > > Some implementations already accept it by the way. But this does not > > > really have anything to do with AES. > > > > > > > This is a bit of a problem because the TLS spec bans the use of server > > key exchange except for certain export ciphers. If AES ciphersuites > > existed supporting RSA key exchange then I suppose the key exchange > > message could be specifically permitted. That wouldn't help already > > existing ciphersuites though. > Steve, > > I think you're misreading Andreas's message. If I read it correctly, > He doesn't want Ephemeral RSA. He wants static RSA, which isn't > in the draft. > I would've thought the line: > > > > Forward secrecy is of course an argument, but I would like to see the > > > > server key exchange message be allowed for the RSA key exchange anyway. suggested support for ephemeral RSA, can you clarify that Andreas? > On the other hand, the value of ephemeral RSA strikes me as minimal. > Well depends on what the application is. Low powered clients is one case, but if were allowing static RSA IMHO we shouldn't specifically prohibit the server key exchange message as is currently the case with non export ciphers. If server's don't want to use it they don't have to but clients should be able to handle it, as they would already do with already existing export ciphers. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 3 13:25:37 2000 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 NAA18650 for ; Tue, 3 Oct 2000 13:25:36 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 03 Oct 2000 10:26:00 -0700 In-Reply-To: Dr S N Henson's message of "Tue, 03 Oct 2000 18:17:49 +0100" Message-ID: Lines: 25 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 Dr S N Henson writes: > suggested support for ephemeral RSA, can you clarify that Andreas? You're right. I think what he may be saying that (1) He'd like static RSA. (2) he'd like to allow ephemeral RSA. > > On the other hand, the value of ephemeral RSA strikes me as minimal. > > > > Well depends on what the application is. Low powered clients is one > case, but if were allowing static RSA IMHO we shouldn't specifically > prohibit the server key exchange message as is currently the case with > non export ciphers. Honestly, I'd like to get rid of ephemeral RSA entirely. It's no longer necessary for export cipher. If we want to have a PFS mode, that's what DH is for. I understand the "low powered client" argument, but I tend to discount it. By the time we get to RFC, clients will be much faster :) -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 Oct 3 14:15:05 2000 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 OAA20211 for ; Tue, 3 Oct 2000 14:15:04 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 19:16:04 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DA2264.1C93B365@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Dr S N Henson writes: > > > suggested support for ephemeral RSA, can you clarify that Andreas? > You're right. I think what he may be saying that > (1) He'd like static RSA. > (2) he'd like to allow ephemeral RSA. > > > > On the other hand, the value of ephemeral RSA strikes me as minimal. > > > > > > > Well depends on what the application is. Low powered clients is one > > case, but if were allowing static RSA IMHO we shouldn't specifically > > prohibit the server key exchange message as is currently the case with > > non export ciphers. > Honestly, I'd like to get rid of ephemeral RSA entirely. It's no > longer necessary for export cipher. If we want to have a PFS mode, > that's what DH is for. > I agree though that DH is best suited for PFS in most circumstances. However in the few where it isn't I'd like to see some standard way of allowing ephemeral RSA without having to violate the specs or resort to "local hacks". > I understand the "low powered client" argument, but I tend to > discount it. By the time we get to RFC, clients will be much > faster :) > I wouldn't like to bet on Palms being obsolete by then :-) Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 3 15:15:08 2000 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 PAA21339 for ; Tue, 3 Oct 2000 15:15:07 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 20:13:09 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.75 [en] (WinNT; U) MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DA2FC5.E5F943BC@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > Honestly, I'd like to get rid of ephemeral RSA entirely. It's no > longer necessary for export cipher. If we want to have a PFS mode, > that's what DH is for. Or would be if anyone implemented it! Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.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 Oct 3 15:44:12 2000 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 PAA21948 for ; Tue, 3 Oct 2000 15:44:11 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 12:43:57 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DA36FD.8390ED3A@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Andreas Sterbenz wrote: > Pete Chown wrote: > > Anyway, back to the hard work... There is another version of my AES > > ciphersuite draft at the usual URL: > > > > ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ > > I think this is a fine draft, but I am in favor in adding an AES > ciphersuite with an RSA key exchange as well, i.e. > TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional > overhead of ephemeral ciphersuites is not significant, I believe we > cannot assume this will be the case for all applications. I agree. I very much want to see TLS_RSA_WITH_AES_128_CBC_SHA in addition to the others already proposed. -- Nelson Bolyard Sun / Netscape Alliance --- 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 Oct 3 16:10:55 2000 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 QAA22380 for ; Tue, 3 Oct 2000 16:10:54 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 03 Oct 2000 13:55:59 -0600 From: "Baber Amin" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_71299FC3.10711377" 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 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_71299FC3.10711377 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I agree that ephemeral cipher suites though my personal favorite do tend = to add more overhead, that Irather not add. Baber Amin >>> nelsonb@netscape.com 10/03/00 01:43PM >>> Andreas Sterbenz wrote: > Pete Chown wrote: > > Anyway, back to the hard work... There is another version of my AES > > ciphersuite draft at the usual URL: > > > > ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ >=20 > I think this is a fine draft, but I am in favor in adding an AES > ciphersuite with an RSA key exchange as well, i.e. > TLS_RSA_WITH_AES_128_CBC_SHA. While some may believe the additional > overhead of ephemeral ciphersuites is not significant, I believe we > cannot assume this will be the case for all applications. I agree. I very much want to see TLS_RSA_WITH_AES_128_CBC_SHA in addition to the others already proposed. -- Nelson Bolyard Sun / Netscape Alliance --- You are currently subscribed to ietf-tls as: BAMIN@novell.com To unsubscribe send a blank email to leave-ietf-tls-3174427R@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 --=_71299FC3.10711377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that ephemeral cipher suites though my = personal=20 favorite do tend to add more overhead, that Irather not add.
 
Baber Amin


>>> nelsonb@netscape.com 10/03/00 01:43PM=20 >>>
Andreas Sterbenz wrote:
> Pete Chown wrote:
> = >=20 Anyway, back to the hard work...  There is another version of my=20 AES
> > ciphersuite draft at the usual URL:
> >
> = >=20 ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/
>
> I think this = is a=20 fine draft, but I am in favor in adding an AES
> ciphersuite with an = RSA=20 key exchange as well, i.e.
> TLS_RSA_WITH_AES_128_CBC_SHA. While = some may=20 believe the additional
> overhead of ephemeral ciphersuites is = not=20 significant, I believe we
> cannot assume this will be the case for = all=20 applications.

I agree.  I very much want to see=20 TLS_RSA_WITH_AES_128_CBC_SHA in addition
to the others already=20 proposed.

--
Nelson=20 Bolyard           &n= bsp;  =20 Sun / Netscape Alliance

---
You are currently subscribed to = ietf-tls=20 as: BAMIN@novell.com
To unsubscribe send a blank email to=20 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 --=_71299FC3.10711377-- From bounce-ietf-tls-3458737@lists.certicom.com Tue Oct 3 16:12:48 2000 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 QAA22429 for ; Tue, 3 Oct 2000 16:12:47 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 21:13:51 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DA3DFF.549C2817@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > Eric Rescorla wrote: > > Honestly, I'd like to get rid of ephemeral RSA entirely. It's no > > longer necessary for export cipher. If we want to have a PFS mode, > > that's what DH is for. > > Or would be if anyone implemented it! > And if those that implemented broken versions fixed it when it was obvious they were wrong... Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 3 17:35:44 2000 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 RAA23784 for ; Tue, 3 Oct 2000 17:35:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: Date: Tue, 3 Oct 2000 14:35:30 -0700 To: "IETF Transport Layer Security WG" From: Paul Hoffman / IMC Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 Do we *really* want to waste time discussing a patent-encumbered algorithm in this WG? Why is this a WG work item? Although draft-ietf-tls-misty1-00.txt fails to mention any patent application, it points to the algorithm spec, draft-ohta-misty1desc-02.txt, which states: 5. Legal Issues The algorithm description is applied for a patent in several countries as PCT/JP96/02154. However, the algorithm is freely available for academic (non-profit) use. Additionally, the algorithm can be used for commercial use without paying the patent fee if you contract with Mitsubishi Electric Corporation. For more information, please contact at MISTY@isl.melco.co.jp. What is the point of discussing this in the WG? --Paul Hoffman, Director --Internet Mail Consortium --- 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 Oct 3 17:42:13 2000 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 RAA23867 for ; Tue, 3 Oct 2000 17:42:13 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 22:41:57 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.75 [en] (WinNT; U) MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt 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: <39DA52A5.5BD64334@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > Do we *really* want to waste time discussing a patent-encumbered > algorithm in this WG? Why is this a WG work item? > > Although draft-ietf-tls-misty1-00.txt fails to mention any patent > application, Which is in violation of the guidelines. > it points to the algorithm spec, > draft-ohta-misty1desc-02.txt, which states: > > 5. Legal Issues > > The algorithm description is applied for a patent in several > countries as PCT/JP96/02154. However, the algorithm is freely > available for academic (non-profit) use. Additionally, the algorithm > can be used for commercial use without paying the patent fee if you > contract with Mitsubishi Electric Corporation. For more information, > please contact at MISTY@isl.melco.co.jp. > > What is the point of discussing this in the WG? Its not exactly an onerous requirement, is it? An email saying "Hi" to MISTY@isl.melco.co.jp would appear to satisfy. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.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 Oct 3 17:44:51 2000 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 RAA23910 for ; Tue, 3 Oct 2000 17:44:50 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt 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: 03 Oct 2000 14:48:11 -0700 In-Reply-To: Ben Laurie's message of "Tue, 03 Oct 2000 22:41:57 +0100" Message-ID: Lines: 24 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: > > it points to the algorithm spec, > > draft-ohta-misty1desc-02.txt, which states: > > > > 5. Legal Issues > > > > The algorithm description is applied for a patent in several > > countries as PCT/JP96/02154. However, the algorithm is freely > > available for academic (non-profit) use. Additionally, the algorithm > > can be used for commercial use without paying the patent fee if you > > contract with Mitsubishi Electric Corporation. For more information, > > please contact at MISTY@isl.melco.co.jp. > > > > What is the point of discussing this in the WG? > > Its not exactly an onerous requirement, is it? An email saying "Hi" to > MISTY@isl.melco.co.jp would appear to satisfy. That's not obvious. You need to contact them for more information. It doesn't say what that information will be. Maybe you have to give them a DNA sample or your firstborn whild or something. That wouldn't be a "fee", strictly speaking. -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 Oct 3 17:47:11 2000 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 RAA23941 for ; Tue, 3 Oct 2000 17:47:10 -0400 (EDT) Message-ID: Date: Tue, 03 Oct 2000 22:47:00 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.75 [en] (WinNT; U) MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt 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: <39DA53D4.A462E905@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: > > > it points to the algorithm spec, > > > draft-ohta-misty1desc-02.txt, which states: > > > > > > 5. Legal Issues > > > > > > The algorithm description is applied for a patent in several > > > countries as PCT/JP96/02154. However, the algorithm is freely > > > available for academic (non-profit) use. Additionally, the algorithm > > > can be used for commercial use without paying the patent fee if you > > > contract with Mitsubishi Electric Corporation. For more information, > > > please contact at MISTY@isl.melco.co.jp. > > > > > > What is the point of discussing this in the WG? > > > > Its not exactly an onerous requirement, is it? An email saying "Hi" to > > MISTY@isl.melco.co.jp would appear to satisfy. > That's not obvious. You need to contact them for more information. > It doesn't say what that information will be. Sorry, misread it - I thought "contract with Mitsubishi" said "contact with Mitsubishi". Doh! I now agree with the original point. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.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 Oct 3 19:01:07 2000 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 TAA24539 for ; Tue, 3 Oct 2000 19:01:06 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-173.dialup.zetnet.co.uk [194.247.40.220] claimed to be zetnet.co.uk Message-ID: Date: Tue, 03 Oct 2000 21:39:33 +0100 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: I-D ACTION:draft-ietf-tls-misty1-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DA4405.A4D895AC@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- > This document proposes the addition of new cipher suites to the TLS > protocol version 1.0 to support the MISTY1 encryption algorithm as a > bulk cipher algorithm. What benefit does MISTY1 provide that is not provided by, say, AES? - From : # MISTY1 with eight rounds encrypts a data stream at a speed of 20Mbps # on an Intel Pentium 100MHz computer and 40Mbps on an HP PA7200 120MHz, # respectively. Note that this is significantly slower than 14-round Rijndael (i.e. 256-bit AES): - From : 320 clocks/block for 10-round Rijndael => 10/14 * 100*128/320 = 28.6 Mbps for 14 rounds on a P100. There are no figures for a PA7200, but 186 clocks/block for 10-round Rijndael => 10/14 * 120*128/186 = 59.0 Mbps for 14 rounds on a PA8200, normalised to 120 Mhz. (actually I'm not sure a PA8200 goes as low as 120 MHz, but you get the point). The hardware performance/size tradeoff is also worse than 14-round Rijndael, and I don't see any reason to believe that MISTY1 is more secure. In fact it has had a lot less analysis than Rijndael has (and certainly less than it will get as AES). Without that analysis, the 'proven' security properties should be treated with some skepticism; designs with similar proofs have been broken in the past. I'm not sure what the patent status is, either. If it was to be accepted, a IP statement from Mitsubishi would be required. - -- 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 iQEVAwUBOdpD0DkCAxeYt5gVAQFcTQf6AvK8B1KMMrfDbImRc1FUBeoBA2rJaKbY DewU6tn3yQgDvdNIMZegNOewPkELgpOEeK9jo52yQfrW1W9+Hz4Tlz1SCH+ap8s8 UBE7PJiXfUZPCGiVmwRAcW4C1nA4uUm0jH16SnTSWxvjmHjZZG1ju3sQx/n9pNg2 6JFH2YwTRghzpcC0RE3V8KhOA+YrabtLSlL5AqE6AkWiFFHZ/EYxc1kJuprFmZE/ wO16Mg8g6z9QyoTC6KYfUdewvtYKXXVcGhtR/Yv0LCLP3RlXLYGnuUOFfsB5qCso fvAVY1aa58fQOTqhIradp2jHwjrz8u53G+VRcLOsRtlZdCmtcnb6UA== =MRDt -----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 Oct 3 19:17:28 2000 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 TAA24692 for ; Tue, 3 Oct 2000 19:17:26 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-173.dialup.zetnet.co.uk [194.247.40.220] claimed to be zetnet.co.uk Message-ID: Date: Tue, 03 Oct 2000 21:56:00 +0100 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: I-D ACTION:draft-ietf-tls-misty1-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DA47E0.C14E0D3D@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Ben Laurie wrote: > Paul Hoffman / IMC wrote: > > > > Do we *really* want to waste time discussing a patent-encumbered > > algorithm in this WG? Why is this a WG work item? > > > > Although draft-ietf-tls-misty1-00.txt fails to mention any patent > > application, > > Which is in violation of the guidelines. Indeed. > > it points to the algorithm spec, > > draft-ohta-misty1desc-02.txt, which states: > > > > 5. Legal Issues > > > > The algorithm description is applied for a patent in several > > countries as PCT/JP96/02154. However, the algorithm is freely > > available for academic (non-profit) use. Additionally, the algorithm > > can be used for commercial use without paying the patent fee if you > > contract with Mitsubishi Electric Corporation. For more information, > > please contact at MISTY@isl.melco.co.jp. > > > > What is the point of discussing this in the WG? > > Its not exactly an onerous requirement, is it? An email saying "Hi" to > MISTY@isl.melco.co.jp would appear to satisfy. It might satisfy if-and-only-if Mitsubishi guaranteed that there would continue to be a royalty-free license permanently. However, as I pointed out in my other post, MISTY1 doesn't really have any advantages over AES. - -- 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 iQEVAwUBOdpHsTkCAxeYt5gVAQHxBwf+PHMvM1auKKsJkznLXD+VwkfbHqGaeWli Cr/W+nlpN4/RFXzuuNz+LnC4g0bi3Aja/TVCcfQx+ZKXiXhzb5DwDhNxZqk/d25I MQDA6luSOBEx86FDeiMWXJux5FOYue0CzEvESY2zl0fAG+sG3PD/avx0ry5NAKMN wlEv3zbUS2h++TasSodqu/K/PGDnysfhN0Vq/MbK9moaaFNRz3BpJymiRTzOtHwd vJWcovXpOt8uca2hn+SnN66gYNYwbjtiFshRJiXEfJTtffOtv5on9d4OmguuphgX TrHWtJMMBeVTe+corSaphVRE/A9pNgqK8+ai09wjfUJd8yBa++63cw== =5J26 -----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 Oct 3 19:23:52 2000 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 TAA24751 for ; Tue, 3 Oct 2000 19:23:51 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt 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: 03 Oct 2000 16:27:11 -0700 In-Reply-To: David Hopwood's message of "Tue, 03 Oct 2000 21:56:00 +0100" Message-ID: Lines: 11 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 David Hopwood writes: > It might satisfy if-and-only-if Mitsubishi guaranteed that there would > continue to be a royalty-free license permanently. However, as I pointed > out in my other post, MISTY1 doesn't really have any advantages over AES. I think this is the key issue here. If MISTY1 is a good idea then surely Twofish, CAST, etc. are even better ideas since they're strong fast, and royalty free. On the other hand, if there's not enough reason to standardize these algorithms, why would we even consider MISTY1? -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 Oct 4 05:07:37 2000 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 FAA13926 for ; Wed, 4 Oct 2000 05:07:36 -0400 (EDT) Date: Wed, 4 Oct 2000 11:07:22 +0200 From: Preda Mihailescu Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] AES ciphersuites Cc: mihailes@inf.ethz.ch List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200010040907.LAA01973@rasiowa.uni-paderborn.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I would like to signal that the DH performance bias _must not be_. In fact there is a way to perform DH in Galois extensions, so that rather then having performance loss (realtive to RSA) one has a gain. e.g. for 1024 (or equivalent) key size security, one has a performance gain factor of more then 10 with repsect to classical DH and about 3-4 with respect to RSA. The topic relatively new and was only developed in detail in an unpublished paper. I am currently working on a more general version of the same, which will be available in the next several weeks. NB: The approach is covered in the IEEE P1363a standard for cryptography too. Preda Mihailescu --- 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 Oct 4 05:12:48 2000 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 FAA13962 for ; Wed, 4 Oct 2000 05:12:47 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Date: Wed, 4 Oct 2000 11:11:31 +0200 Organization: IAIK MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.59DEA389--"; protocol="application/x-pkcs7-signature" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <007501c02de3$23c038c0$4c981b81@iaik.tugraz.ac.at> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a multipart MIME message, it may require a MIME capable user agent. ----IAIK.SMIME.MAPPER.59DEA389-- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric Rescorla wrore: > You're right. I think what he may be saying that > (1) He'd like static RSA. > (2) he'd like to allow ephemeral RSA. Yes, that is what I meant. Sorry if it was unclear. I do not know if we really want or need ephemeral RSA. In any case it is trivial to support for all (client) implementations that can do exportable RSA. That seems to make it at least worth considering, although it is in violation of the TLS spec a lot of people implemented. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----IAIK.SMIME.MAPPER.59DEA389-- Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA oIIVODCCBFkwggNFoAMCAQICAw9CzTAJBgUrDgMCHQUAMIIBEzELMAkGA1UEBhMC QVQxDzANBgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5m ZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElO VFJBTkVUIENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJ QUlLIGVsZWN0cm9uaWMgc2lnbmF0dXJlMB4XDTk5MTIwMTEzMzcyOVoXDTAwMTIw MTEzMzcyOVowgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEEFuZHJlYXMgU3RlcmJlbnowgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGB AONpF50rZXkgpQWGwLefFIVegTpRUtz8rH5d/QzYopDsznBivkmoGxOQdpGQC3+g fi2TXVI/w0GmdTwmOpB7IL6RIZ+duVqOj/9Vxt/75vB5cimp6doadlg0fi8UdlPU YgbpIeFp0DGExFf9I8Xi/JS0DQdRcNOMMdT+2vHA8HzfAgEFo4G6MIG3MDgGA1Ud HwQxMC8wLaAroCmkJzAlMRAwDgYDVQQKEwdpYWlrLmF0MREwDwYDVQQDEwhJQUlL Q1JMMTARBglghkgBhvhCAQEEBAMCAKAwKAYJYIZIAYb4QgENBBsWGVVzZXItQ2Vy dGlmaWNhdGUgSU5UUkFORVQwDAYDVR0TBAUwAwEBADAjBgNVHREEHDAagRhBbmRy ZWFzLlN0ZXJiZW56QGlhaWsuYXQwCwYDVR0PBAQDAgbAMAkGBSsOAwIdBQADggEB AKagdoFWr6bm0N9+TW+7HECJErm+sq39d10wKSdWYBLZ8BRst3QzslC2ErzAap5Q EQvpwl2qEczDqeJs2V2RvqzHvpMd61idNvhIROSQrB8d+2o9qgO3mJo1zFmWi6co 1wNm7nmBvZU0H3jbRH+yEUVEKENF1UmS3UCjKziZcj7yvphBJjJcZblvlvDocm6A 8JTwXaDaoTsdUyzG74hnaMc/sdWLUXHUW/jwzQVPAZz+YCEN5OzyDbzmfRowmb4I ybaCVRQnDijOmZYraj+huWcrDPzq3sOErr7cnxXfhCBjfUiufg9/t9B+Uwp7E16H a8QS4k/2GvIU6xyzZNdt0XcwggRUMIIDQKADAgECAgJOIDAJBgUrDgMCHQUAMIGZ MQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQDExBJQUlLIElO VFJBTkVUIENBMB4XDTk5MTExNDEyNTE0OVoXDTAyMTIzMTIyNTkzMFowggETMQsw CQYDVQQGEwJBVDEPMA0GA1UECBMGU3R5cmlhMQ0wCwYDVQQHEwRHUkFaMRkwFwYD VQQJExBJbmZmZWxkZ2Fzc2UgMTZhMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkg T0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5m b3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsT EElBSUsgSU5UUkFORVQgQ0ExGTAXBgNVBAMTEElBSUsgVFUtR1JBWiBTSUcxIjAg BgNVBAwTGUlBSUsgZWxlY3Ryb25pYyBzaWduYXR1cmUwggEgMA0GCSqGSIb3DQEB AQUAA4IBDQAwggEIAoIBAQDSyhKuZGsL1EPk5mOTG8RzhHS/Va+/WYjs7Zm91nwV Hu1+XFLJeJ85AICkSQ7yq9lWa9ur34cywbNhl/9QxaOBOiHkMvAuXxs2Bq/uhe/h Eb1T7XgO12ptG80qSOP8/nKxw1PXlbUkd1rD9727mO/5tpvagEQfz7CZQ5wI4Hkr Nw5uH/vsJ72wRcRTFzmHy/nOX3Y9sXLd/V7TG8j1x0oNWsR3b0tHEWM+Oc1Qq5Ff CknoMMCitSD38cULCCcLJtVxkOiapWaZrDXUAuhvshhsRPjkXh6IzpqsZEtRI64S urLoUUShPv108ELE6rfQKtm9FNnlFRD954diwfFHko/lAgEFozMwMTARBglghkgB hvhCAQEEBAMCAAIwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwCQYFKw4D Ah0FAAOCAQEAc26nvl5jQspoqD0fzjpZkqGARmFVj9uHNqVoWttqw/y6t46OhJUc ePEmXkKsFP4NuCFx2MyvmbWb6R6QNQ5WfoarGWyQ382cQN6mccPS5weDjXAzYeGZ Ukx99K70ncVxkwq7rINAhJtari2XSLxmfBJyTYrZuWEgd5C9NBuf2u3iZyArarOK PbrBjZxjmXwBbZ7tsfAhSVMGSr2ODgQcQjf7ZndNIsQZL75HkN21Pj+/x3wnMCAQ F50+Pt8ioAgZ/SAudxmdYNr2itI0vmsV/xjD1NQuwb6+HwmR2LxclhMzrT1VbtTD kRLD/h8LKC1OpKV8lQlS7Ir+Od/XNafKJjCCA8owggKyoAMCAQICAQEwDQYJKoZI hvcNAQEEBQAwgZkxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNV BAMTEElBSUsgSU5UUkFORVQgQ0EwHhcNOTkxMTE0MTIzMTU5WhcNMDIxMjMxMjI1 OTMwWjCBmTELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBP RiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZv cm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQ SUFJSyBJTlRSQU5FVCBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEB AMLr+IHe6qeAtYLkfvxyRI6ogrvBP5iKPEBZ7j3T1yVJL7CDPGH8hgPsI4qt6Fnz h2MuAq84JS58zX5xLqEUC/E5xw1xyAzorC6yWwxGRhb+fvTg4OlM2JVsTlyJO6F/ BWlXuZU33lgGky/RX84sItXKhmhbUPscnHYBsVKcQO5rFcRrJK/5c1Mha/bcQNVD QaQw+HRCvr7T4mAVYi+DVJv6jb393CoDBnffGP/mcIkFGFO5D6lyfP8QiSs06+0u nIYWwUn1YzQI2RNBAjXrCuAJtlf4qYrGXC09Neg8ymoI2uOglo6scWiZXt/prxWo i+btPX8oWDl5+7DEtCf0rx8CAQejHTAbMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQD AgEGMA0GCSqGSIb3DQEBBAUAA4IBAQAfdOMJ/ePlmrY0flkgiL6vyRDBuWGcIaB/ oGofngJzbQLa7X2shWzpIiVpvo64XcjIBuocpErhIQfc2UZTSqYYT7R2Uydh0wVe qScURuwuihFURPhI7GWCSrNwym2lrwsva2Xh/MTyzhXs9vo29dP2djjelN8n347d XhKJOYJ0tsA583afEKmKvkfzAb+sQLxEmPyasQTCGJMec/iWjLTsEDRfCrROYVgD Z4NcCpiRSv9mWw6sPYB8Chf5fJq1waFzluFYSUkuF24NKVopr1E4dKt2Lc1zdMRG RztKQWeUiBLkqFCQxsi6iZrl1nvMCdF+scuLj7G4lNshx6n1ZcabMIIEWTCCA0Wg AwIBAgIDHoUNMAkGBSsOAwIdBQAwggETMQswCQYDVQQGEwJBVDEPMA0GA1UECBMG U3R5cmlhMQ0wCwYDVQQHEwRHcmF6MRkwFwYDVQQJExBJbmZmZWxkZ2Fzc2UgMTZh MSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UE CxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAsTEElBSUsgSU5UUkFORVQgQ0ExGzAZ BgNVBAMTEklBSUsgVFUtR1JBWiBDUllQVDEgMB4GA1UEDBMXSUFJSyBjb25maWRl bnRpYWxpdHkgQ0EwHhcNOTkxMjAxMTM0MTQ2WhcNMDAxMjAxMTM0MTQ2WjCBmTEL MAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9M T0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQ cm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UEAxMQQW5kcmVhcyBT dGVyYmVuejCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEAtTnY8l5rJXqdLGEs QFNR1uDX8lSDs5YdOHIBR0W4pFB4Z7010JRSQIB+ep0yna56BiFSiZRgluwcwzOZ A/wmtkIXxNPmTkbykmdDy9wUbIqkW0to18m1P5VA7mOmyQB3mDmRQFP17jSA2ZNu TaG7VBczGgt8v8E6DZO2vVUWZ8kCAQWjgbowgbcwOAYDVR0fBDEwLzAtoCugKaQn MCUxEDAOBgNVBAoTB2lhaWsuYXQxETAPBgNVBAMTCElBSUtDUkwxMBEGCWCGSAGG +EIBAQQEAwIAoDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRS QU5FVDAMBgNVHRMEBTADAQEAMCMGA1UdEQQcMBqBGEFuZHJlYXMuU3RlcmJlbnpA aWFpay5hdDALBgNVHQ8EBAMCA3gwCQYFKw4DAh0FAAOCAQEApyn/jb6x8/3tJCxM ke196dxNDrEQ+SB5aWEO5jL7L4CyU2RefUf5J+UCmSk8h6a4GqsA+iNRLuuM4lq1 2QO8sUwBTHqsRrkQKgK3dzVpWdtnndlr2E0Ry6gbi1RVwCAujjbZRxt+TvUNj9Pa 7e69W8sSHuUYVQdQcgDHc1bDbYsBHS8vikdM0kGBr65QiQpbcOvVF+iEMiVnIYhE u51uCkbe4UbdyrF545TJ0rSw/HjsfUIaHxTwfDv+wzNHQduxflao3YqoEhTGX/E7 82H2Ii/J6FJFimYe3vRywHBMV6eKoQ9MzQtAsRRIlnPlmdw62+L/Q9ayPcWPadf1 dRn1JTCCBFQwggNAoAMCAQICAnUwMAkGBSsOAwIdBQAwgZkxCzAJBgNVBAYTAkFU MSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UE CxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBh bmQgQ29tbXVuaWNhdGlvbnMxGTAXBgNVBAMTEElBSUsgSU5UUkFORVQgQ0EwHhcN OTkxMTE0MTI1NTM2WhcNMDIxMjMxMjI1OTMwWjCCARMxCzAJBgNVBAYTAkFUMQ8w DQYDVQQIEwZTdHlyaWExDTALBgNVBAcTBEdyYXoxGTAXBgNVBAkTEEluZmZlbGRn YXNzZSAxNmExJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZ MUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9j ZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEZMBcGA1UECxMQSUFJSyBJTlRSQU5F VCBDQTEbMBkGA1UEAxMSSUFJSyBUVS1HUkFaIENSWVBUMSAwHgYDVQQMExdJQUlL IGNvbmZpZGVudGlhbGl0eSBDQTCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgC ggEBAMEnzjatic90xi5VRmr0i2O16Z1aSElQFZitoNvAzGw+KehOTuKeUr5ALHib 9tGInNm+jPTWVGl/u5Hab1JRzXj0xAKyqvZ+KphGy6ag6VcCVySJmeY1AqTM0W78 XdFQXnlZuciBv00Ktoulb/Ktgh6c0YNgo4UMVdxjGHJweibT1AGvlFe2Bqulwtuw OLovMIuIyHHh+o6F2HXYKUB54GJpia1B2IfmqcpBBFdYtDlHyrxugB5QhuhLo0Bj D8jCe8B2gkQnI2wIeyfpLlH+u3/VQAl12cZKkqaqPpOgP/znsdh62QBSabrRluvC p9OQW9M8u+mJlrxIIVwtThfzIW0CAQWjMzAxMBEGCWCGSAGG+EIBAQQEAwIAAjAP BgNVHRMECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjAJBgUrDgMCHQUAA4IBAQBa+v4J IzqbBydvFOaP/dA5D/GLWEWjPTF8tKcPhxlEYABH8dW5E2tk/nNE2CDyGjkJtR+o 9kiCDCa4N/qlc2LepJpa0I28Hi4wCd0CuxSWpEuDHNDrW6Y/bU8gJ8DpskVl+lR0 QFkqSCWAu3bY0e2VvUffk2ltrx1KvO64vGX+ayZn2P7naGHPfYjCBWUKzW0zS8ch Vf0aehu/qXFuZDfy1MlDgEnPl1DQ1vSLCMmFEDc99iNzcCU7ILn+RgWPNYPVhCUq oDQ6buX00ohfNVS/OHgqkWpa1HLvLRXqE9NmYUJvfhE2zCY6w6bTME3IfDCXRat2 Q3twP4/iP9xtsTbPMYICeDCCAnQCAQEwggEcMIIBEzELMAkGA1UEBhMCQVQxDzAN BgNVBAgTBlN0eXJpYTENMAsGA1UEBxMER1JBWjEZMBcGA1UECRMQSW5mZmVsZGdh c3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kx RzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nl c3NpbmcgYW5kIENvbW11bmljYXRpb25zMRkwFwYDVQQLExBJQUlLIElOVFJBTkVU IENBMRkwFwYDVQQDExBJQUlLIFRVLUdSQVogU0lHMSIwIAYDVQQMExlJQUlLIGVs ZWN0cm9uaWMgc2lnbmF0dXJlAgMPQs0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMDEwMDQwOTExNTRaMCMG CSqGSIb3DQEJBDEWBBRvqDpaY4usuIXw+l13wEGPt+EARDBSBgkqhkiG9w0BCQ8x RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAN BggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkqhkiG9w0BAQEFAASBgBAoyY+gyFRv M8kGuQzwia4ADfuuV3WzG0AfpEeYDjkEww1l7eUbGIg4QJJ3BCJxxqqK/33L4Z26 lO4AHtLGluXyCMtGMn5//NEme/TpvtSa9EJH4PU8/Gba+CU2PFtCHG65wq76JNJb n5Jh/bc1Zp2Wtro0gPWFDmSaPVZhZau0AAAAAAAA ----IAIK.SMIME.MAPPER.59DEA389-- Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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 ----IAIK.SMIME.MAPPER.59DEA389---- From bounce-ietf-tls-3458737@lists.certicom.com Wed Oct 4 06:09:03 2000 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 GAA14321 for ; Wed, 4 Oct 2000 06:09:02 -0400 (EDT) Date: Wed, 4 Oct 2000 11:08:35 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jeremey@cips.nokia.com on Tue, Oct 03, 2000 at 11:46:40AM -0500 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001004110835.C2251@hyena.skygate.co.uk> X-List-Host: SKYLIST.net I've noticed that a non-ephemeral RSA/AES ciphersuite has a lot of support. I want to spend a bit of time on this one, to work out what the actual performance benefits are. Unfortunately I am going to be away on a business trip for a few days so I won't be able to respond in detail until next week. In the meantime, am I right that people want this ciphersuite *just* because of performance benefits, or are there other advantages too? (I can't think of any; I just want to make sure.) I feel a bit uneasy about the non-ephemeral ciphersuite because it is definitely less secure than the EDH one. I worry that people will only implement the less secure ciphersuite, so diluting the usefulness of adding the AES. Jeremey Barrett wrote: > I'd really like to see this as well. In fact, with RSA unencumbered, > I'd like to see some (non-ephemeral) RSA as a MUST. Perhaps > TLS_RSA_WITH_AES_128_CBC_SHA would be a good candidate? I would certainly like to see at least one MUST ciphersuite from among the AES ones, but I don't think it is feasible. Suppose someone has a TLS implementation that conforms to the original RFC. We can't suddenly declare that it doesn't conform any more because we have "changed our minds" about what constitutes TLS. I would like to be proved wrong on this, but I can't see any way out of it myself. -- Pete --- 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 Oct 4 06:55:54 2000 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 GAA15037 for ; Wed, 4 Oct 2000 06:55:54 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-ciphersuite-00.txt Date: Wed, 04 Oct 2000 06:55:23 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200010041055.GAA14943@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : AES Ciphersuites for TLS Author(s) : P. Chown Filename : draft-ietf-tls-ciphersuite-00.txt Pages : 6 Date : 03-Oct-00 At present, the symmetric ciphers supported by TLS are RC2, RC4, IDEA, DES and triple DES. The protocol would be enhanced by the addition of AES [AES] ciphersuites, for the following reasons: 1. RC2, RC4 and IDEA are all subject to intellectual property claims. RSA Security Inc has trademark rights in the names RC2 and RC4, and claims that the RC4 algorithm itself is a trade secret. Ascom Systec Ltd owns a patent on the IDEA algorithm. 2. Triple DES is much less efficient than more modern ciphers. 3. Now the AES process is completed there will be commercial pres¡ sure to use the selected cipher. The AES is efficient and has withstood extensive cryptanalytic efforts. The AES is therefore a desirable choice. 4. Currently the DHE ciphersuites only allow triple DES (along with some ``export'' variants which offer reduced key lengths). At the same time the DHE ciphersuites are the only ones to offer forward secrecy. This document proposes two new ciphersuites, with the aim of over¡ coming these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ciphersuite-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ciphersuite-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001003122936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ciphersuite-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ciphersuite-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001003122936.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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-- From bounce-ietf-tls-3458737@lists.certicom.com Wed Oct 4 06:56:13 2000 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 GAA15065 for ; Wed, 4 Oct 2000 06:56:12 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-camellia-00.txt Date: Wed, 04 Oct 2000 06:55:53 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200010041055.GAA15031@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Addition of the Camellia Encryption Algorithm to TLS Author(s) : S. Moriai Filename : draft-ietf-tls-camellia-00.txt Pages : 4 Date : 03-Oct-00 This document proposes the addition of new cipher suites to the TLS protocol 1.0 to support the Camellia encryption algorithm as a bulk cipher algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-camellia-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-camellia-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001003150447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-camellia-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-camellia-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001003150447.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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-- From bounce-ietf-tls-3458737@lists.certicom.com Wed Oct 4 08:17:17 2000 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 IAA16944 for ; Wed, 4 Oct 2000 08:17:16 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 13:03:39 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DB1C9B.8DFBD286@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > I've noticed that a non-ephemeral RSA/AES ciphersuite has a lot of > support. I want to spend a bit of time on this one, to work out what > the actual performance benefits are. Unfortunately I am going to be > away on a business trip for a few days so I won't be able to respond > in detail until next week. > > In the meantime, am I right that people want this ciphersuite *just* > because of performance benefits, or are there other advantages too? > (I can't think of any; I just want to make sure.) > > I feel a bit uneasy about the non-ephemeral ciphersuite because it is > definitely less secure than the EDH one. I worry that people will > only implement the less secure ciphersuite, so diluting the usefulness > of adding the AES. > Well I'm not sure what the consensus on it being ephemeral is. Personally I'd say we should have an RSA/AES cipher suite and remove the TLS restriction on server key exchange: that is it *may* be ephemeral if the server wishes. Can others who expressed support also indicate whether the would ban server key exchange (as is the case with other cipher suites) or allow it? This places the additional requirement on the client: it MUST handle the server key exchange message if it is present. Currently TLS bans the use of this message for RSA key exchange in anything but certain export ciphers. Implementing this is relatatively easy to an already existing "RSA only" client. If it handles the usual export crippled ciphersuites it should simply be a case of stopping it choking when it sees server key exchange and adding AES. To get any useful performance out of a server using ephemeral RSA it would need to cache RSA temporary keys, however if it supports the export ciphersuites it may well be doing that anyway. In terms of client side peformance if I understand the process correctly the contrast is dramatic. An ephemral DH cipher suite will do (among other things) something like this client side: 1. Verify signature of server key exchange and server chain. 2. Generate a DH key pair. 3. Determine the DH shared secret. For DSA authentication operation 1. is expensive, for RSA it is not. 2 and 3 are expensive operations. For ephemeral RSA it will do: 1. Verify signature of server key exchange and server chain. 2. Encrypt premaster secret using server temporary key. Neither is expensive for RSA certificates. In the case of a low power client this could be crucial. People are doing SSL/TLS on things like Palm Pilots which might take 30s or more to do the epehemeral DH operations. This is enough to discourage the use of AES ephemeral DH ciphersuites completely. If we allow RSA it can have a much smaller overhead. If we also allow server key exchange it can also have forward secrecy: something which none of the other RSA strong ciphersuites supports. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 4 09:31:18 2000 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 JAA19578 for ; Wed, 4 Oct 2000 09:31:17 -0400 (EDT) Date: Wed, 4 Oct 2000 09:31:44 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drh@celocom.com on Wed, Oct 04, 2000 at 01:03:39PM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001004093144.A26135@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Wed, Oct 04, 2000 at 01:03:39PM +0100, Dr S N Henson wrote: > Pete Chown wrote: > > In the meantime, am I right that people want this ciphersuite *just* > > because of performance benefits, or are there other advantages too? > > I feel a bit uneasy about the non-ephemeral ciphersuite Me, too. > Well I'm not sure what the consensus on it being ephemeral is. > Personally I'd say we should have an RSA/AES cipher suite and remove the > TLS restriction on server key exchange: that is it *may* be ephemeral if > the server wishes. Optional, specified by the server? I think that may be the wrong way to go about it. We currently have a chicken-and-egg problem with ephemeral TLS/SSL3 suites, with neither Microsoft nor Netscape supporting ephemeral suites for https on the server or client end. Allowing the server to say whether to spec ephemeral would allow the relatively few server vendors to continue to avoid ephemeral support and forward secrecy. So I think the server should be required to support ephemeral suites. This would break the client-vs-server ephemeral support stalemate and allow TLS client vendors to provide more secure applications without fearing that they're wasting their time. Yes, there will be a lag time, but I think it may be the only way to make forward secrecy obtainable. > To get any useful performance out of a server using ephemeral RSA it > would need to cache RSA temporary keys, however if it supports the > export ciphersuites it may well be doing that anyway. > In terms of client side peformance if I understand the process correctly > the contrast is dramatic. > In the case of a low power client this could be crucial. People are > doing SSL/TLS on things like Palm Pilots which might take 30s or more to > do the epehemeral DH operations. This is enough to discourage the use of > AES ephemeral DH ciphersuites completely. If we allow RSA it can have a > much smaller overhead. If we also allow server key exchange it can also > have forward secrecy: something which none of the other RSA strong > ciphersuites supports. If there's little difference on the client end for ephemeral RSA, and caching of keys on the server end can conserve resources there, then I think that ephemeral is clearly the way to go. Anything on which a server cert is installed should have the resources to periodically regenerate temporary keys. -Peter -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.org/ --- 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 Oct 4 09:50:11 2000 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 JAA20297 for ; Wed, 4 Oct 2000 09:50:10 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt In-reply-to: Message from Eric Rescorla of 3 Oct 2000 16:27:11 PDT Date: Wed, 04 Oct 2000 09:53:17 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200010041353.e94DrHq01641@cirocco.openmarket.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I don't expect to put MISTY1 ciphersuites forward on the standards track. Are there substantive comments on the draft, or objections to it becoming an Informational RFC? - 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 Wed Oct 4 10:29:17 2000 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 KAA21206 for ; Wed, 4 Oct 2000 10:29:16 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 04 Oct 2000 07:32:33 -0700 In-Reply-To: Dr S N Henson's message of "Wed, 04 Oct 2000 13:03:39 +0100" Message-ID: Lines: 40 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 Dr S N Henson writes: [Ephemeral DH] > This places the additional requirement on the client: it MUST handle the > server key exchange message if it is present. Currently TLS bans the use > of this message for RSA key exchange in anything but certain export > ciphers. We can't remove this restriction for the current ciphers because that would declare current implementations nonconforming. We can remove it for all new ciphers. > To get any useful performance out of a server using ephemeral RSA it > would need to cache RSA temporary keys, however if it supports the > export ciphersuites it may well be doing that anyway. This concerns me. If the purpose is forward secrecy then the key can't be cached for very long (minutes, hours)? In any case you won't have _perfect_ forward secrecy if you cache it at all, since the attacker could notice that you had engaged in a transaction he cared about and attack your machine at that point. > In terms of client side peformance if I understand the process correctly > the contrast is dramatic. An ephemral DH cipher suite will do (among > other things) something like this client side: > > 1. Verify signature of server key exchange and server chain. > 2. Generate a DH key pair. > 3. Determine the DH shared secret. > > For DSA authentication operation 1. is expensive, for RSA it is not. 2 > and 3 are expensive operations. For ephemeral RSA it will do: > > 1. Verify signature of server key exchange and server chain. > 2. Encrypt premaster secret using server temporary key. > > Neither is expensive for RSA certificates. Quite right. Last time I measured it, DSS/DHE was something like 20 times more expensive than static RSA for the client. Thus about 10 times more expensive than ephemeral RSA. -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 Oct 4 10:46:15 2000 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 KAA21583 for ; Wed, 4 Oct 2000 10:46:14 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Date: Wed, 4 Oct 2000 16:45:33 +0200 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.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <01d401c02e11$c0284440$4c981b81@iaik.tugraz.ac.at> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Dr S N Henson writes: > Well I'm not sure what the consensus on it being ephemeral is. > Personally I'd say we should have an RSA/AES cipher suite and remove the > TLS restriction on server key exchange: that is it *may* be ephemeral if > the server wishes. There are three options not causing problems with current implementations: (a) Allow ephemeral for the new AES ciphersuites only (b) Wait for the next protocol version and allow it for all ciphersuites (c) Use the extension mechanism I favor (a) but would probably still like (b) when the time comes. Another question is if we want to leave it up to the server to decide whether to use static or ephemeral RSA. If not we could again use the extension mechanism. I do not have a firm opinion about this. Regards, 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 Oct 4 11:09:42 2000 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 LAA22126 for ; Wed, 4 Oct 2000 11:09:41 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Wed, 04 Oct 2000 17:09:29 +0200 From: Preda Mihailescu X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3smp i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt 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: <39DB4829.BD179E64@math.uni-paderborn.de> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Win Treese wrote: > I don't expect to put MISTY1 ciphersuites forward on the standards > track. Are there substantive comments on the draft, or objections to it > becoming an Informational RFC? > > - Win Treese > > --- > You are currently subscribed to ietf-tls as: preda@math.uni-paderborn.de > 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 Wed Oct 4 11:17:05 2000 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 LAA22383 for ; Wed, 4 Oct 2000 11:17:05 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Wed, 04 Oct 2000 17:16:46 +0200 From: Preda Mihailescu X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3smp i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DB49DE.D8FA32DB@math.uni-paderborn.de> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hi, I read some performance concerns about discrete logarithm based schemes (DH, DSA) along this thread. So I would like to point out that it is possible to uses such schemes in Galois extensions, rather then prime fields. By according choice of the extension and arithmetic bag of tricks, one achieves important improvements. Thus, for ~ 1024 bit key security, the improvement factor is at least 10 (thus also improving upon RSA for the same key size). This approach is coevered by the IEEE P1363a cryptography standard draft. The arithmetic is only descirbed in an unpuiblished paper and I am currently writing a more comprehensive update. I can provided more detail for interested questions. It may also be worhtwhile considering to reserve some ciphersuites for TSL using Galois extensions, given these nice to have performance qualities. --- Preda PS: The last message was a test, verifying that my previous 2 ones had not reached the list (sorry for the confusion :-( --- 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 Oct 4 12:31:58 2000 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 MAA25284 for ; Wed, 4 Oct 2000 12:31:50 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 17:29:50 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DB5AFE.158D7721@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Peter W wrote: > > > > Well I'm not sure what the consensus on it being ephemeral is. > > Personally I'd say we should have an RSA/AES cipher suite and remove the > > TLS restriction on server key exchange: that is it *may* be ephemeral if > > the server wishes. > > Optional, specified by the server? I think that may be the wrong way to > go about it. > > We currently have a chicken-and-egg problem with ephemeral TLS/SSL3 > suites, with neither Microsoft nor Netscape supporting ephemeral suites > for https on the server or client end. Allowing the server to say > whether to spec ephemeral would allow the relatively few server vendors > to continue to avoid ephemeral support and forward secrecy. > Well currently with strong RSA cipher suites there is no choice. I believe the SSL spec was ambiguous on this point and TLS specifically prohibits the use of server key exchange. As such there is no standard to use ephemeral RSA with strong encryption. I know of at least one client vendor that would like to support ephemeral RSA if a standard existed. > So I think the server should be required to support ephemeral suites. > This would break the client-vs-server ephemeral support stalemate and > allow TLS client vendors to provide more secure applications without > fearing that they're wasting their time. Yes, there will be a lag time, > but I think it may be the only way to make forward secrecy obtainable. > I'm not particularly opposed to making ephemeral RSA server support mandatory. I would say however that the differences on the client side between supporting static only AES and ephemeral/static AES are likely to be minimal if it supports the existing export cipher suites. IMHO this lesser requirement of only mandating client support would be sufficient to break the stalemate and server vendors or writers could then support ephemeral RSA, possibly pressured by some freeware servers supporting it. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 4 12:32:01 2000 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 MAA25300 for ; Wed, 4 Oct 2000 12:32:00 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 17:31:24 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DB5B5C.CC9C90E@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Dr S N Henson writes: > [Ephemeral DH] > > This places the additional requirement on the client: it MUST handle the > > server key exchange message if it is present. Currently TLS bans the use > > of this message for RSA key exchange in anything but certain export > > ciphers. > We can't remove this restriction for the current ciphers because > that would declare current implementations nonconforming. We can remove > it for all new ciphers. > Yes I meant that. I should've been clearer that the removal of the restriction can only apply to the new AES ciphersuite. > > To get any useful performance out of a server using ephemeral RSA it > > would need to cache RSA temporary keys, however if it supports the > > export ciphersuites it may well be doing that anyway. > This concerns me. If the purpose is forward secrecy then the > key can't be cached for very long (minutes, hours)? In any > case you won't have _perfect_ forward secrecy if you cache it > at all, since the attacker could notice that you had engaged in > a transaction he cared about and attack your machine at that point. > Yes ephemeral DH doesn't need to store the DH key pair and can use each key only once. However a server will typically include a session cache if it wants reasonable performance. An attacker might be able to retrieve or have access to the session cache's master secret and attack that instead. Admittedly though it is practiable to run ephemeral DH without a session cache, albeit with a big performance hit. This isn't true for ephemeral RSA due to the much longer key generation time. In any case even if the temporary RSA key does last an hour that is a vast improvement on the static RSA version which will typically have the same key in use for a year or so. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 4 16:57:24 2000 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 QAA01603 for ; Wed, 4 Oct 2000 16:57:23 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-027.dialup.zetnet.co.uk [194.247.41.33] claimed to be zetnet.co.uk Message-ID: Date: Wed, 04 Oct 2000 19:27:04 +0100 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: I-D ACTION:draft-ietf-tls-camellia-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DB7678.1B05DE92@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt Camellia is patented; from draft-nakajima-camellia-00.txt: Mitsubishi Electric Corporation (Mitsubishi Electric) and Nippon Telegraph and Telephone Corporation (NTT) have filed patent applications on the techniques used in Camellia. For more information, please contact at MISTY@isl.melco.co.jp and/or e2@isl.ntt.co.jp. Similar arguments against adding it apply as for MISTY1. Also, This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. I don't know why the draft was even allowed to be published with this condition. It's completely unacceptable. - -- 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 iQEVAwUBOdt2ODkCAxeYt5gVAQG4pwf8C4kUOKqsgEmDe/KXrDFevi53jJHqHgmd dn6PGJ/OMsiA1w5QhQW7SJBgZ+9oBfnG3/chrLwW1sMGgYzVDlt4HypaAIl12AFo /WTU2lhirYl1BvwkoLYbB7G3K7djptLV5ge/1zF2jacSohqyu4V/aAmZgY0s00R2 2/OvcucT5X71L8y7WkwxFPd2mOD0uZCM55Fgak7ky6sMkmd8XvsGqR75iNoK/JkS JzoGTOJIlQlHsAak2mtEeID0AhFC572DasPxUjIr0Iszbzsh7iDxileGh3+eXI1n fhBu08Jdp0MR7J2RwtgOcCpEBwfC7clCHKnUGbXIKLA0dzc4o0sGqg== =tWke -----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 Wed Oct 4 17:05:55 2000 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 RAA01794 for ; Wed, 4 Oct 2000 17:05:55 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-camellia-00.txt 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: 04 Oct 2000 14:09:16 -0700 In-Reply-To: David Hopwood's message of "Wed, 04 Oct 2000 19:27:04 +0100" 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 David Hopwood writes: > This document is an Internet-Draft and is NOT offered in accordance > with Section 10 of RFC2026, and the author does not provide the IETF > with any rights other than to publish as an Internet-Draft. > > I don't know why the draft was even allowed to be published with this > condition. It's completely unacceptable. Actually, it's not. It's quite legal. In fact this text comes right out of http://www.ietf.org/ietf/1id-guidelines.txt That doesn't mean it's not objectionable, of course. -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 Oct 4 17:08:13 2000 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 RAA01814 for ; Wed, 4 Oct 2000 17:08:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: Date: Wed, 4 Oct 2000 14:08:00 -0700 To: "IETF Transport Layer Security WG" From: Paul Hoffman / IMC Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-camellia-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 7:27 PM +0100 10/4/00, David Hopwood wrote: > This document is an Internet-Draft and is NOT offered in accordance > with Section 10 of RFC2026, and the author does not provide the IETF > with any rights other than to publish as an Internet-Draft. > >I don't know why the draft was even allowed to be published with this >condition. It's completely unacceptable. I fully agree. Drafts like this should not be a WG product. --Paul Hoffman, Director --Internet Mail Consortium --- 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 Oct 4 17:15:40 2000 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 RAA01902 for ; Wed, 4 Oct 2000 17:15:39 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-camellia-00.txt 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: 04 Oct 2000 14:18:58 -0700 In-Reply-To: Paul Hoffman / IMC's message of "Wed, 4 Oct 2000 14:08:00 -0700" Message-ID: Lines: 9 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 Hoffman / IMC writes: > >I don't know why the draft was even allowed to be published with this > >condition. It's completely unacceptable. > > I fully agree. Drafts like this should not be a WG product. oops. I hadn't noticed that it was draft-ietf-tls. I retract my previous disagreement and agree with Paul and David. -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 Oct 4 17:16:50 2000 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 RAA01914 for ; Wed, 4 Oct 2000 17:16:50 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-027.dialup.zetnet.co.uk [194.247.41.33] claimed to be zetnet.co.uk Message-ID: Date: Wed, 04 Oct 2000 19:46:39 +0100 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: I-D ACTION:draft-ietf-tls-misty1-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DB7B0F.BD8A94E3@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Win Treese wrote: > I don't expect to put MISTY1 ciphersuites forward on the standards > track. Are there substantive comments on the draft, or objections to it > becoming an Informational RFC? Yes, there are objections to it becoming an informational RFC: - the current draft does not conform to section 10 of RFC 2026, because MISTY1 is patented and the draft doesn't mention that. - MISTY1 has no apparent advantages over AES, and an unnecessary proliferation of ciphersuites is undesirable, even if they are only defined in informational RFCs. - new DH_anon ciphersuites should not be added. The same objections apply to the Camellia draft (with the additional objection that it defines 18 ciphersuites for a single cipher, which is arguably excessive). - -- 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 iQEVAwUBOdt6xDkCAxeYt5gVAQHJYwgAtqD0+ik4fS+emT0WaMcCSeuEukAI8GAf 9TWGS0gD3WNF77cojac747+m6QP50k6Ur0kJB49IDQqfDVnYVcwTtpyj0F3dQTQ3 bLI45MHNb7CWRv2dtLzwk5rb3oN4E6E2dppreQmgXpvWwxLL8lewYamCtUxcFOZa wUvJW7XOya3LyyIIpjVU6pA0L970Hfw+F9MhS3Uk3AVIXVN9Z7H7WQc4gLRrmclq rbTO1FRpUng2DJqgv1NEIT80JQw0rjDStsMYWimbhiQ7UT9/GXFI1QYwYpGsXzxe YXNH2a6ouuvdXhnZW6tsJ5JeI1ZoWB50i942+3vJmcf2jzAcQgE3UA== =/YNX -----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 Wed Oct 4 17:42:57 2000 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 RAA02514 for ; Wed, 4 Oct 2000 17:42:53 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 14:42:35 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DBA44B.87B455F7@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Dr S N Henson wrote: > Well I'm not sure what the consensus on it being ephemeral is. > Personally I'd say we should have an RSA/AES cipher suite and remove the > TLS restriction on server key exchange: that is it *may* be ephemeral if > the server wishes. > > Can others who expressed support also indicate whether the would ban > server key exchange (as is the case with other cipher suites) or allow > it? > > This places the additional requirement on the client: it MUST handle the > server key exchange message if it is present. Currently TLS bans the use > of this message for RSA key exchange in anything but certain export > ciphers. I think you're proposing that use of server key exchange to provide ephemera be "optional", and that the server may choose to use it, or not, as it wishes, within a given cipher suite, I very much dislike that idea. I believe that the use of a server key exchange ought to be required, or prohibited, as part of the definition of the cipher suite. If we want to allow a choice (ephermeral, or not), then we should define two cipher suites, one with SKE, one without. That way, a client can tell the server whether or not it supports the use of the SKE message by the choice of cipher suites it offers in the client hello. If the client wants to require, or prohibit, the use of the SKE, it simply includes the cipher suites in its client hello message accordingly. Likewise, when the server picks a cipher suite, it would be explicitly specifying whether or not an SKE is to be done. This approach doesn't change the definition of any of the existing cipher suites. A client that doesn't support SKE with existing non-export cipher suites would not suddenly be non-compliant. I would like to see cipher suites defined, both with and without the SKE. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape --- 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 Oct 4 18:38:29 2000 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 SAA03234 for ; Wed, 4 Oct 2000 18:38:28 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 15:35:22 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DBB0AA.34645F@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > nelsonb@netscape.com (Nelson Bolyard) writes: > > I very much dislike that idea. I believe that the use of a server key > > exchange ought to be required, or prohibited, as part of the definition > > of the cipher suite. > We already have quite a bad combinatoric explosion problem. Why > make it worse? With the Diffie-Hellman cipher suites, the use (or not) of ephemera is already coded as part of the cipher suite definition (e.g. DHE_ vs DH_). I merely propose that cipher suites be consistent in this regard, rather than having any "special case" cipher suites. Advantages of my proposal include: a) giving both the client and server control (via negotiation) on the use (or not) of ephemera. Clients can effectively require it if they choose. b) By removing any "optional" behavior from the cipher suite, it is easier to prove/demonstrate the correctness of any implemenation. IMO, two products are more likely to succesfully interoperate if there is "optional" behavior to the cipher suite. (OK, I realize that the server's request for client authentication is still an "optional" behavior of SSL/TLS.) c) This scheme doesn't require all TLS clients to support SKEs. "Lightweight" clients should appreciate that. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape --- 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 Oct 4 18:45:02 2000 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 SAA03341 for ; Wed, 4 Oct 2000 18:45:01 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 04 Oct 2000 15:48:14 -0700 In-Reply-To: nelsonb@netscape.com's message of "Wed, 04 Oct 2000 15:35:22 -0700" Message-ID: Lines: 30 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 nelsonb@netscape.com (Nelson Bolyard) writes: > Advantages of my proposal include: > a) giving both the client and server control (via negotiation) on the use > (or not) of ephemera. Clients can effectively require it if they choose. No they can't. The server can always just use some essentially static key as his ephemeral key. The only thing the client can actually force is doubling the server's workload. I'd point out that this is exactly what many servers do with "ephemeral" RSA today. > b) By removing any "optional" behavior from the cipher suite, it is easier > to prove/demonstrate the correctness of any implemenation. > > IMO, two products are more likely to succesfully interoperate if there is > "optional" behavior to the cipher suite. TLS is already so complicated that I don't think this makes much of a difference. > c) This scheme doesn't require all TLS clients to support SKEs. > "Lightweight" clients should appreciate that. The code to implement SKE is trivial compared to the rest of the SSL code. Moreover, many implementations will need to support SKE in any case to support old export modes. The primry disadvantage of this approach is that it makes the already quite bad combinatoric explosion problem even worse. -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 Oct 4 18:55:46 2000 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 SAA03533 for ; Wed, 4 Oct 2000 18:55:45 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 04 Oct 2000 15:20:06 -0700 In-Reply-To: nelsonb@netscape.com's message of "Wed, 04 Oct 2000 14:42:35 -0700" Message-ID: Lines: 8 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 nelsonb@netscape.com (Nelson Bolyard) writes: > I very much dislike that idea. I believe that the use of a server key > exchange ought to be required, or prohibited, as part of the definition > of the cipher suite. We already have quite a bad combinatoric explosion problem. Why make it worse? -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 Oct 4 18:55:52 2000 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 SAA03544 for ; Wed, 4 Oct 2000 18:55:51 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 15:55:35 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DBB567.AA8EC031@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > The primry disadvantage of this approach is that it makes the > already quite bad combinatoric explosion problem even worse. It doesn't make RSA any worse than DH. It only makes the distinction between ephemeral and non-ephemeral RSA be no different than the distinction between ephemeral and non-ephemeral DH. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape --- 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 Oct 4 18:59:23 2000 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 SAA03589 for ; Wed, 4 Oct 2000 18:59:22 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 04 Oct 2000 16:02:44 -0700 In-Reply-To: nelsonb@netscape.com's message of "Wed, 04 Oct 2000 15:55:35 -0700" Message-ID: Lines: 21 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 nelsonb@netscape.com (Nelson Bolyard) writes: > Eric Rescorla wrote: > > > The primry disadvantage of this approach is that it makes the > > already quite bad combinatoric explosion problem even worse. > > It doesn't make RSA any worse than DH. Correct, but the DH situation stinks. > It only makes the distinction between ephemeral and non-ephemeral RSA be no > different than the distinction between ephemeral and non-ephemeral DH. With DH, this distinction was marginally understandable because supporting DH certificates was rather different from supporting DHE. Most implementations already support SKE for RSA, so this doesn't add any additional implementation burden at all. What the change you suggest does do is create a needless opportunity for interoperability problems. -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 Oct 4 19:09:27 2000 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 TAA03757 for ; Wed, 4 Oct 2000 19:09:26 -0400 (EDT) Message-ID: Date: Thu, 05 Oct 2000 00:10:05 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DBB8CD.2EFF3ABC@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Nelson Bolyard wrote: > > Eric Rescorla wrote: > > > The primry disadvantage of this approach is that it makes the > > already quite bad combinatoric explosion problem even worse. > > It doesn't make RSA any worse than DH. > > It only makes the distinction between ephemeral and non-ephemeral RSA be no > different than the distinction between ephemeral and non-ephemeral DH. > Except that static DH ciphersuites are very rarely implemented (anyone know of *anything* that supports them?) whereas it would be hoped that ephemeral and non ephemeral RSA would be widely used. Anyway some export ciphersuites do something similar except of course that the conditions under which SKE is present are well defined and not at the servers disgression. However it can still result in one ciphersuite which sometimes uses SKE and sometimes does not. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 4 19:13:08 2000 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 TAA03801 for ; Wed, 4 Oct 2000 19:13:07 -0400 (EDT) Message-ID: Date: Thu, 05 Oct 2000 00:14:16 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DBB9C8.97E2A007@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > nelsonb@netscape.com (Nelson Bolyard) writes: > > > It only makes the distinction between ephemeral and non-ephemeral RSA be no > > different than the distinction between ephemeral and non-ephemeral DH. > With DH, this distinction was marginally understandable because supporting > DH certificates was rather different from supporting DHE. Most > implementations already support SKE for RSA, so this doesn't add > any additional implementation burden at all. > > What the change you suggest does do is create a needless opportunity for > interoperability problems. > It also gives the opportunity of preserving the current situation of lack of forward secrecy in "browser SSL/TLS" which was one of my motivations for suggesting it or an equivalent alternative. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 4 19:17:18 2000 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 TAA03890 for ; Wed, 4 Oct 2000 19:17:17 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 04 Oct 2000 16:20:38 -0700 In-Reply-To: Dr S N Henson's message of "Thu, 05 Oct 2000 00:14:16 +0100" Message-ID: Lines: 17 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 Dr S N Henson writes: > Eric Rescorla wrote: > > What the change you suggest does do is create a needless opportunity for > > interoperability problems. > > > > It also gives the opportunity of preserving the current situation of > lack of forward secrecy in "browser SSL/TLS" which was one of my > motivations for suggesting it or an equivalent alternative. Steve, I'm having a bit of trouble understanding your argument here. Can you restate it? Thanks, -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 Oct 4 20:53:51 2000 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 UAA05564 for ; Wed, 4 Oct 2000 20:53:50 -0400 (EDT) Message-ID: Date: Wed, 04 Oct 2000 23:15:37 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: <39DBAC09.F92B37A2@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Nelson Bolyard wrote: > > > I think you're proposing that use of server key exchange to provide ephemera > be "optional", and that the server may choose to use it, or not, as it wishes, > within a given cipher suite, > I wasn't suggesting the existing ciphersuites should be changed in any way. I was suggesting that the new AES ciphersuites only should have this property. > I would like to see cipher suites defined, both with and without the SKE. > What I wanted to avoid is the current situation where no strong encryption forward secrecy ciphersuites are generally usable. I'm not too concerned about how this is achieved in practice. I suppose an alternative would be to define SKE and non SKE ciphersuites and then state that they MUST both be supported, then leave it down to client and server preferences. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Thu Oct 5 00:31:39 2000 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 AAA09949 for ; Thu, 5 Oct 2000 00:31:38 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-189.dialup.zetnet.co.uk [194.247.40.240] claimed to be zetnet.co.uk Message-ID: Date: Thu, 05 Oct 2000 03:01:16 +0100 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 ciphersuites (was Proposed New Charter) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DBE0EC.285196D1@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Eric Rescorla wrote: > nelsonb@netscape.com (Nelson Bolyard) writes: > > Advantages of my proposal include: > > a) giving both the client and server control (via negotiation) on the > > use (or not) of ephemera. Clients can effectively require it if they > > choose. > No they can't. Yes they can, if the standard mandates that ephemeral keys with a specific maximum lifetime be used with that ciphersuite. (Obviously we can only talk about what is guaranteed for conforming implementations.) - -- 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 iQEVAwUBOdvgxzkCAxeYt5gVAQGVbAf/fdCmYPgUjCD7xFgxZFX3iOlByU5u2GO6 q2psvYONqL2YlSEzZChK8ZZByMNFIx9S1HPqq+PYNbySBL0Qh9Jqs6X3Y4QmACcR sufYUtw91aS8sORFgBBnfSlLiHvjFZX76I/K/KLYLh1ho+kJwKsPF7jQ/yJCsspE 1XomqMLAXpkEpNdo1TPQ8tbkFAgulQORnxldEHPPrnCf6AzhdR4BRLR8sDfrdJiT MMuyjSPXa2DZM8uD/t+xcCLUZsDPcNaBf1VVxh4kVIuPdq4cAtLsEztspwDYlnRO RnmrfiVB73VjyyRUsYBw4J4dQUsfhZEDvre3Pj7laY/yL0hgm+rbtg== =fXNy -----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 Thu Oct 5 00:40:23 2000 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 AAA10030 for ; Thu, 5 Oct 2000 00:40:22 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 04 Oct 2000 21:43:35 -0700 In-Reply-To: David Hopwood's message of "Thu, 05 Oct 2000 03:01:16 +0100" Message-ID: Lines: 22 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 David Hopwood writes: > -----BEGIN PGP SIGNED MESSAGE----- > > Eric Rescorla wrote: > > nelsonb@netscape.com (Nelson Bolyard) writes: > > > Advantages of my proposal include: > > > a) giving both the client and server control (via negotiation) on the > > > use (or not) of ephemera. Clients can effectively require it if they > > > choose. > > > No they can't. > > Yes they can, if the standard mandates that ephemeral keys with a specific > maximum lifetime be used with that ciphersuite. (Obviously we can only talk > about what is guaranteed for conforming implementations.) Specifying any form of key hygiene requirement would be a substantial departure from current TLS practice. We don't even specify the maximum lifetime for 512 bit keys, despite the fact that they were known to be weak at design time. -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 Thu Oct 5 06:29:43 2000 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 GAA24514 for ; Thu, 5 Oct 2000 06:29:41 -0400 (EDT) Date: Thu, 5 Oct 2000 11:29:08 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-camellia-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from hopwood@zetnet.co.uk on Wed, Oct 04, 2000 at 07:27:04PM +0100 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001005112908.A4239@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt I've just noticed that this draft uses the same ciphersuite numbers as the AES draft. I don't mind changing the numbers I am using, but whatever happens we mustn't forget! Personally I wonder whether Camellia is of wide enough interest to merit an RFC. I think parts of the introduction could do with changes as well: > However, the TLS Protocol Version 1.0 [4] currently does not support > cipher suites including 128-bit block ciphers that offer a high > level of security and performance. I hope people don't mind me "selling" my own draft here! IMHO while this is true, it is better addressed by adding AES ciphersuites. Camellia is patented and hasn't had anything like the same amount of cryptanalytic effort. > An optimized implementation of Camellia in assembly language can > encrypt on a Pentium III (800MHz) at the rate of more than 276 Mbits > per second, which is much faster than the speed of an optimized DES > implementation. Certainly -- any modern cipher ought to be faster than DES. How does it compare with AES or RC4? -- Pete --- 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 Thu Oct 5 07:58:35 2000 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 HAA26823 for ; Thu, 5 Oct 2000 07:58:34 -0400 (EDT) Date: Thu, 5 Oct 2000 07:59:07 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-camellia-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Pete.Chown@skygate.co.uk on Thu, Oct 05, 2000 at 11:29:08AM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001005075906.A3395@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Thu, Oct 05, 2000 at 11:29:08AM +0100, Pete Chown wrote: > Internet-Drafts@ietf.org wrote: > > > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt > > I've just noticed that this draft uses the same ciphersuite numbers as > the AES draft. I don't mind changing the numbers I am using, but > whatever happens we mustn't forget! > > Personally I wonder whether Camellia is of wide enough interest to > merit an RFC. > Camellia is patented and hasn't had anything like the same amount of > cryptanalytic effort. We don't need it, we're not sure we can trust it, and we can't freely implement it. Somewhere in there is a sufficient reason to abandon Camellia. ;-) -Peter -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.org/ --- 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 Thu Oct 5 08:52:34 2000 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 IAA27914 for ; Thu, 5 Oct 2000 08:52:34 -0400 (EDT) Message-Id: Date: Thu, 5 Oct 2000 08:46:24 -0400 (EDT) From: "David P. Kemp" Reply-To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt To: "IETF Transport Layer Security WG" MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: z9I/BPfeC4MjQImoX+wsVg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200010051234.IAA14562@roadblock.missi.ncsc.mil> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I believe anyone has the right to submit an Informational RFC and request IANA registration for non-general-purpose algorithms. I do agree with David, Paul, and Eric that the TLS working group should have no sponsorship of these drafts/RFCs. They should be purely individual submissions. Dave > Date: Wed, 04 Oct 2000 19:46:39 +0100 > From: David Hopwood > To: "IETF Transport Layer Security WG" > Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt > > Win Treese wrote: > > I don't expect to put MISTY1 ciphersuites forward on the standards > > track. Are there substantive comments on the draft, or objections to it > > becoming an Informational RFC? > > Yes, there are objections to it becoming an informational RFC: > > - the current draft does not conform to section 10 of RFC 2026, because > MISTY1 is patented and the draft doesn't mention that. > > - MISTY1 has no apparent advantages over AES, and an unnecessary > proliferation of ciphersuites is undesirable, even if they are only > defined in informational RFCs. > > - new DH_anon ciphersuites should not be added. > > The same objections apply to the Camellia draft (with the additional > objection that it defines 18 ciphersuites for a single cipher, which is > arguably excessive). > > - -- > David Hopwood --- 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 Thu Oct 5 14:03:43 2000 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 OAA04092 for ; Thu, 5 Oct 2000 14:03:43 -0400 (EDT) Date: Thu, 5 Oct 2000 14:03:49 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ekr@rtfm.com on Wed, Oct 04, 2000 at 09:43:35PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001005140349.A6392@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Wed, Oct 04, 2000 at 09:43:35PM -0700, Eric Rescorla wrote: > David Hopwood writes: > > Eric Rescorla wrote: > > > nelsonb@netscape.com (Nelson Bolyard) writes: > > > > Advantages of my proposal include: > > > > a) giving both the client and server control (via negotiation) on the > > > > use (or not) of ephemera. Clients can effectively require it if they > > > > choose. > > > > > No they can't. > > > > Yes they can, if the standard mandates that ephemeral keys with a specific > > maximum lifetime be used with that ciphersuite. (Obviously we can only talk > > about what is guaranteed for conforming implementations.) And the whole point of ephemera was forward secrecy. With extra work on the client side, the RSA premaster secret exchange could be modified to give the client some control over forward secrecy. The client could use its own keypair (if client cert auth is being used, or the client doesn't care about anonymity) or a temporary RSA keypair (if no client cert used, or for extra safety) so that each party (client and server) would suggest half of the premaster secret and encrypt its suggestion with the other party's public key. An attacker would need access to either application's memory space (an attack vector TLS can never protect against) or access to both parties' keypairs (in which case there are probably bigger problems). With one party's key info, an attacker would have a much smaller premaster secret to dissect, but still would need to do some work. This would also help protect the communications from weak pseudorandom number generators. Maybe the client is using a Palm device that doesn't have the resources to pick a good premaster secret, but the server has a very well implemented PRNG mechanism. With the current system, you need either the server keypair (thus the talk about ephemera) or the premaster secret created by the client. Hopefully everyone learned from Netscape's early blunders, but I wonder if all these new mobile devices can be trusted to pick good secrets. Leaving aside the issue of how radically this would change the protocol, how does the expense of the client decrypting half the premaster secret compare to, say, DH calculation? How good are the PRNG on the client devices where DH is unacceptably slow? Would it make sense to increase the premaster secret size? Client keypair generation time would also be an issue, for privacy reasons, for connections where client certs are not used. If a client reused the same temporary public key with multiple TLS servers, those servers would then have a common identifier with which they could share information about the client. :-( But if a client cert is being presented, then there is no keypair generation involved, and no expectation of privacy, so the only issue is whether the group feels forward secrecy is important enough to change the protocol significantly. If not, then there's no practical way of guaranteeing forward secrecy with RSA premaster secret exchange. > Specifying any form of key hygiene requirement would be a substantial > departure from current TLS practice. We don't even specify the > maximum lifetime for 512 bit keys, despite the fact that they were > known to be weak at design time. Perhaps that ought to be specified? -Peter -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.org/ --- 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 Thu Oct 5 14:13:31 2000 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 OAA04231 for ; Thu, 5 Oct 2000 14:13:28 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES ciphersuites (was Proposed New Charter) 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: 05 Oct 2000 11:16:45 -0700 In-Reply-To: Peter W's message of "Thu, 5 Oct 2000 14:03:49 -0400" Message-ID: Lines: 36 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 Peter W writes: > > > Yes they can, if the standard mandates that ephemeral keys with a specific > > > maximum lifetime be used with that ciphersuite. (Obviously we can only talk > > > about what is guaranteed for conforming implementations.) > > And the whole point of ephemera was forward secrecy. Actually, no. Historically the purpose of ephemera was (1) to permit "domestic" SSL implementations to use a single (long) key to communicate with "export" implementations. (2) To allow the use of DH keys with DSA certificates, since the number of DSA certificates, while small, is larger than the number of DH certificates. PFS was sort of a nice side effect. > But if a client cert is being presented, then there is no keypair > generation involved, and no expectation of privacy, so the only issue is > whether the group feels forward secrecy is important enough to change the > protocol significantly. > > If not, then there's no practical way of guaranteeing forward secrecy with > RSA premaster secret exchange. The same argument that I made earlier applies to DH key exchange as well. There's no way of guaranteeing secrecy, forward or otherwise, in the face of servers which engage in bad security practices. Nowhere in the spec does it say that the DHE key must be freshly generated for each transaction. The point I'm trying to make here is that historically TLS has been agnostic about specifying good security practices. I don't see why a draft whose primary purpose is to add AES is the right way to change that. -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 Thu Oct 5 22:43:26 2000 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 WAA12103 for ; Thu, 5 Oct 2000 22:43:25 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-042.dialup.zetnet.co.uk [194.247.41.52] claimed to be zetnet.co.uk Message-ID: Date: Fri, 06 Oct 2000 01:13:20 +0100 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: I-D ACTION:draft-ietf-tls-camellia-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DD1920.B3F48793@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Pete Chown wrote: > Internet-Drafts@ietf.org wrote: > > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt [...] > I hope people don't mind me "selling" my own draft here! IMHO while > this is true, it is better addressed by adding AES ciphersuites. > Camellia is patented and hasn't had anything like the same amount of > cryptanalytic effort. > > > An optimized implementation of Camellia in assembly language can > > encrypt on a Pentium III (800MHz) at the rate of more than 276 Mbits > > per second, which is much faster than the speed of an optimized DES > > implementation. > > Certainly -- any modern cipher ought to be faster than DES. How does > it compare with AES or RC4? http://www.tml.hut.fi/~helger/aes/table.html 10-round Rijndael is 441.4 Mbps on an 800 MHz PIII. 14-round Rijndael is about 315 Mbps. RC4 is much faster still. - -- 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 iQEVAwUBOd0ZAjkCAxeYt5gVAQFArggAor7eCdLbrdCe/tp+VuzgLotwtvuzsQd9 Ng0ssy+fJ66VOs6UkGbHZg6dTaSK2uNsXIommjS/wwiP8Sr/19FVTcVRMojI3GMB 9UfTwL8g0yvZxulEC8rGTcJ+hM43z4H1Qy2xzI3itAFpknn8hJzXBiS/XyFr0KG1 5i3wpI3xKc+nCuiuKcZLl0HETNWqvpH4p9AAl+73VbHJZNJnjorL1sS3GO8/nBZR C3sWsgjBUtYqfLzlCcaOwK74BG3dPm9PwpiYanGRLzFZgeB1OAglOmiqS9uj+AXR EsyYmAOteMgRAv8hhVyPJlIWesbfAZAaL1tRqcsEsWEl+wzv3tfbsQ== =wrOZ -----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 Oct 6 02:32:23 2000 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 CAA26069 for ; Fri, 6 Oct 2000 02:32:20 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-camellia-00.txt Date: Fri, 06 Oct 2000 15:31:15 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200010060631.PAA28124@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thank you very much for many comments about the Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt. I will update the Internet-Draft as follows soon. * Status of this Memo > This document is an Internet-Draft and is NOT offered in accordance > with Section 10 of RFC2026, and the author does not provide the > IETF with any rights other than to publish as an Internet-Draft. The statement above was inadequate for a WG Internet-Draft. This is my mistake. Sorry. * Intellectual Property Statement The intellectual property statement regarding royalty-free license is now under review. The current intellectual property statement will be updated before the draft is expired. * The number of ciphersuites Since Camellia supports three key sizes, 128, 192, and 256 bits, similarly to the AES, I simply defined ciphersuites for Camellia with each key size. So there are 18 ciphersuites in total. However, I will define only necessary ciphersuites following the AES ciphersuites. I also remove a DH-anon ciphersuite, since I just followed the 3DES ciphersuites in RFC2246. I don't mind changing the numbers I am using. > Pete Chown The collision of the ciphersuite numbers just happened accidentally. Both of the internet-drafts were submitted almost at the same time. * Advantage of Camellia As is written in the Internet-Draft and I told at the last IETF meeting, Camellia is suitable for both software and hardware implementations. The TLS protocol will be implemented on a wide range of platforms including restricted-space environments. DES and Triple DES have very small hardware (within 10Kgates), which perfectly meet the current market requirements in wireless cards, for instance, where low power consumption is a mandatory condition. As far as the designers know, Camellia is a 128-bit block cipher that can be an alternative for Triple DES from hardware viewpoint: a small number of gate counts and low power consumption. The encryption and decryption procedures of Camellia are symmetric, that is, they are the same without the order of subkeys, while for Rijndael implementing both encryption and decryption requires roughly double the area needed for encryption alone. Also Camellia establishes high software performance in modern PC processors in the same level as that of AES finalists. We hence believe that Camellia is worthy of being included in ciphersuites for the TLS protocol. The performance shown in the Internet-Draft leaves room for further optimizations; we expect it will achieve around 300 cycles/block (about 341.3 Mbps on an 800 MHz PIII), although it will not be superior to Rijndael on this platform. > David Hopwood As Pete Chown said, certainly, Camellia hasn't had the same amount of cryptanalytic effort as AES, but Camellia was designed by experts of cryptanalysis and evaluated by some external experts, too. Camellia is designed based on the techniques used in E2 and MISTY. E2 was evaluated during the Round 1 public evaluation period of the AES development effort, and there were no major attacks found. Camellia was presented at SAC and CRYPTO this summer and was also submitted to NESSIE project. Its high level of security will be recognized soon. Anyway, we need alternative algorithms for TLS in terms of resiliency, as is discussed in the NIST's report on the development of the AES. I hope Camellia will be a good choice. Best regards, Shiho Moriai --- 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 Sun Oct 8 02:41:53 2000 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 CAA25016 for ; Sun, 8 Oct 2000 02:41:52 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-172.dialup.zetnet.co.uk [194.247.40.218] claimed to be zetnet.co.uk Message-ID: Date: Sun, 08 Oct 2000 05:09:19 +0100 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] Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39DFF36F.F525C1DC@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Peter W wrote: > On Wed, Oct 04, 2000 at 09:43:35PM -0700, Eric Rescorla wrote: > > David Hopwood writes: > > > Eric Rescorla wrote: > > > > nelsonb@netscape.com (Nelson Bolyard) writes: > > > > > Advantages of my proposal include: > > > > > a) giving both the client and server control (via negotiation) on > > > > > the use (or not) of ephemera. Clients can effectively require it > > > > > if they choose. > > > > > > > No they can't. > > > > > > Yes they can, if the standard mandates that ephemeral keys with a > > > specific maximum lifetime be used with that ciphersuite. (Obviously we > > > can only talk about what is guaranteed for conforming implementations.) > > And the whole point of ephemera was forward secrecy. and later, > ... the only issue is whether the group feels forward secrecy is important > enough to change the protocol significantly. > > If not, then there's no practical way of guaranteeing forward secrecy with > RSA premaster secret exchange. Ephemeral RSA with a maximum temporary key lifetime would work perfectly well to guarantee forward secrecy, assuming it is negotiated, with minimal change to the protocol. However, to see whether there is any point in making that change, we first need to consider the performance of all the existing key exchange algorithms, and a few variations on them. Assume the following optimisations: - For DHE, the server chooses a subgroup of GF(p) of order q ~ 161 bits, where q and (p-1)/2q are both prime. The server uses short exponents between 0 and q-1. - For new DHE ciphersuites q is included in the server DH parameters. In that case the client can also use short exponents. - DSS signing and verification are optimised using well-known techniques (fixed base exponentiation with precomputation for signing, and simultaneous exponentiation for verification). - Server exponentials can be reused over several connections. The client always generates a new exponential for each connection. - RSA uses the Chinese Remainder Theorem for private key operations. The RSA public exponent is 3, and the modulus is the product of two 512-bit primes. Reusing DHE server exponentials (i.e. dh_Ys values) is safe provided that: - g generates a subgroup of prime order q, and (p-1)/2q has no small factors. - client certificate types that use static DH parameters (i.e. rsa_fixed_dh and dss_fixed_dh) are not included in CertificateRequest.certificate_types. The first condition prevents an attacker from gaining information about the private value of a reused exponential using small-subgroup attacks. (Actually the attacker can still find the low-order bit of the private value; that's compensated for by making q one bit longer than would otherwise be necessary.) The reason for disallowing client certificates with static DH parameters when reusing exponentials, is that otherwise it would be possible to negotiate the same pre-master secret more than once. (Forward secrecy is not achieved anyway when using static DH client certificates. IMHO they should be deprecated.) A short maximum lifetime should be set for the server exponentials, in order to avoid weakening the forward secrecy property. This maximum lifetime should be in the spec (30 seconds should be more than sufficient to get the performance advantages), rather than being left to the discretion of server implementors. Note that being able to solve the discrete log problem in a ~ 160-bit prime order subgroup of GF(p) with p ~ 1024 bits would imply being able to break DSA signature keys, so by making DHE_DHE_DSS_WITH_3DES_EDE_CBC_SHA a mandatory ciphersuite, we are already assuming that this problem is infeasible. OK, now for the performance analysis. For the server, computations that can be amortized over many connections (e.g. exponential generation in ephemeral DH, and RSA key pair generation in ephemeral RSA) are not included in the times below. The fact that some operations can be done in advance to reduce latency is not taken into account; only the total computational load per connection (this may penalise DHE in situations where traffic is bursty; it has no effect on RSA). On the client side, all public key computations are included. Differences in the amount of data hashed or sent in the handshake would not have a significant effect on performance. All times are in milliseconds on a 233 Mhz Pentium II running NT 4.0, measuring elapsed time with no other non-system processes running. Two libraries were used: the default Windows build of Miracl (which has a well-optimised x86 assembler bignum implementation), and OpenSSL. On the assumption that TLS implementations will be heavily optimised, for each operation I've taken the time from whichever of Miracl and OpenSSL is fastest. I also tried Crypto++; it was consistently slower, but the relative speeds of operations were in about the same ratio. times (ms) Miracl OpenSSL fastest RSAd RSA private key operation (CRT) 46.21 44.6 44.6 RSAe RSA public key operation (e = 3) 0.29 2.5 0.29 DHk DH key agreement (short exponent) 25.70 25.70 DHlk DH key agreement (long exponent) 151.73 151.73 DSAs DSA signing 9.22 23.4 9.22 DSAv DSA verification 31.10 29.0 29.0 ECDHk ECDH key agreement ECDSAs ECDSA signing ECDSAv ECDSA verification OpenSSL implements DH, but I'd have to write a benchmark program; there isn't one provided. It looks from the RSAd and DSAv times as though its performance for DH would be similar to Miracl. Miracl also has an implementation of elliptic curves over GF(p) and GF(2^m), but there's no point in giving times because the code isn't optimised. An optimised implementation would be significantly faster than ordinary DH. Algorithm FS? Server ops cost Client ops base extra _cost _cost ECDHE_ECDSA* yes ECDHa+ECDSAs ? 2*ECDHk+(xc+2)*ECDSAv ? ? DHE_DSS* yes DHk+DSAs 34.9 2*DHk+(xc+2)*DSAv 109.4 29.0 DHE_DSS yes DHk+DSAs 34.9 2*DHlk+(xc+2)*DSAv 361.5 29.0 RSA no RSAd 44.6 (xc+2)*RSAe 0.6 0.3 RSAE_DSS yes RSAd+DSAs 53.8 RSAe+(xc+2)*DSAv 58.3 29.0 DHE_RSA* yes DHk+RSAd 70.3 2*DHk+(xc+2)*RSAe 52.0 0.3 DHE_RSA yes DHk+RSAd 70.3 2*DHlk+(xc+2)*RSAe 304.0 0.3 RSAE_RSA yes 2*RSAd 89.2 (xc+3)*RSAe 0.9 0.3 FS? supports forward secrecy? * with group order in DH or ECDH server params (only possible for new ciphersuites) RSAE_X ephemeral RSA with signatures and certs using X. xc the number of "extra" certificates in the certificate chain that need to be verified (the baseline assumes only the cert that directly certifies the server key needs to be verified, because the others will already be in the client's database). I.e. the total client load is base_cost + xc*extra_cost, but xc will normally be zero. In summary, DHE_DSS is slightly faster than static RSA for the server, and much faster than ephemeral RSA, when all applicable optimisations are taken into account. On the client side, DHE_DSS* takes about a tenth of a second on a 233 Mhz PII, so there is no client performance problem for things like web browsing. For protocols where the client and server are peers, DHE_RSA* seems a reasonable choice. For computationally challenged clients, RSAE_RSA or ECDHE_ECDSA might be worth considering in future. Conclusions: - There is no need to give up forward secrecy in order to have good performance. Therefore, newly defined ciphersuites should use key exchange algorithms that guarantee forward secrecy. - Assuming, then, that we don't add new static RSA ciphersuites, there is little point in adding RSAE_RSA either. It would be better just to use DHE_DSS or DHE_RSA instead, which are more efficient for the server. - -- 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 iQEVAwUBOd/yhzkCAxeYt5gVAQFJCAf/e3u0K8XkVdj5HUUBHHBIrK0UqeZa9APD t/EeAO//9d97qIU3WXjRZREV875HQsG/WKrF1Z1gSFv0RiSonahT4DQhF4fnmQXn 2tTUAndSar53wokSD6o1QrMrqEzY4IkB38xLICUjUWe+kvpITFmUK46I7sd6l2Kh CH+20+7vP5qlhWG/Aevng5FjD9AkZFztFJ0K2WXE03fB0BluZJKeDtB4V/4tadma 4gHFcjVI3EP5I2nlusRDlZm4R4OjNge2ShsUlm4r5amppldv9KGJbM/FMoZvfqzo CLtVS5vBEqkPQTzRJ0xVACjeYNJjG6SXNdv78E3AzCP9cbPE/Sm7Bg== =JQ1J -----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 Sun Oct 8 11:38:03 2000 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 LAA09787 for ; Sun, 8 Oct 2000 11:38:02 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 08 Oct 2000 08:40:50 -0700 In-Reply-To: David Hopwood's message of "Sun, 08 Oct 2000 05:09:19 +0100" Message-ID: Lines: 54 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 David Hopwood writes: I'm not sure that your data leads to these conclusions. > There is no need to give up forward secrecy in order to have good > performance. Therefore, newly defined ciphersuites should use > key exchange algorithms that guarantee forward secrecy. To a first order DSS certificates do not exist. Essentially all existing servers have RSA certificates, so that's what we've got to work with. Therefore all ephemeral schemes will cost more than what people are currently doing. How much? The choices we're faced with are DHE_RSA and RSAE_RSA, right? DHE_RSA imposes roughly a 50% additional performance load on the server and RSAE_RSA of course imposes a 100% additional performance load on the server. This is not insignificant. Remember that we're trying to replace existing infrastructure here. Servers usually use RC4 because they're afraid of the performance consequences of 3DES. There will already be resistance to using Rijndael because it's slower than RC4. Confronting server admins with a simultaneous slowdown in their public key operations seems to me to be a good way to inhibit uptake. > - Assuming, then, that we don't add new static RSA ciphersuites, > there is little point in adding RSAE_RSA either. It would be better > just to use DHE_DSS or DHE_RSA instead, which are more efficient > for the server. Your argument seems to hinge on the client DH performance being "fast enough" The rationale for using ephemeral RSA for PFS is to reduce the load on really slow clients. Even the full 400 ms required to do all long DH the client operations isn't really that noticeable given typical Internet RTTs. [0] However, this ignores a really slow client machine such as a Palm Pilot. It's widely maintained that 1024-bit RSA operations on the Palm are too slow to be useful (30s is often bandied about). Now, if we assume that Palm performance is roughly proportional to your test machine across the board, we can see that all four DHE variants clock in at 45 s or above, which would be similarly unacceptable. By contrast, RSAE_RSAE performance would be clearly acceptable. Thus, we're basically forced to define some RSA variant for any new cipher anyway. In my mind the question becomes why define a DH variant? -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 Oct 10 15:00:58 2000 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 PAA10841 for ; Tue, 10 Oct 2000 15:00:55 -0400 (EDT) Date: Tue, 10 Oct 2000 19:59:45 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from hopwood@zetnet.co.uk on Sun, Oct 08, 2000 at 05:09:19AM +0100 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001010195945.A2641@hyena.skygate.co.uk> X-List-Host: SKYLIST.net David, thank you for analysing the computational costs of the different options. That was what I wanted to do, and I don't know when I would have got the time! It sounds as though the consensus is for supporting at least one RSA ciphersuite. However, we don't want to lose forward secrecy if possible. It seems that if we implement it along the lines of the old "export" ciphers we can achieve this. Unfortunately, this means that we must go against the statement in section 7.4.3 of RFC2246: > It is not legal to send the server key exchange message for the > following key exchange methods: > > ... > > RSA I suggest, therefore, that this statement should be reversed for the AES cipher suite. Also, one thing I don't like about ephemeral RSA is that it is tempting for servers to keep keys around for too long. There is effectively no overhead in generating a new DH key, so there is no reason not to create a new one each time. With RSA this is not the case; there is a temptation just to keep using the same key, or to use it for an unreasonably long time. For this reason, I am proposing including "key hygiene" requirements, even though historically these have been left out of TLS RFCs. Here is some suggested wording: | When TLS_RSA_WITH_AES_128_SHA has been negotiated, servers MUST send | a server key exchange message. This is a specific exception to | section 7.4.3 of RFC2246. For the avoidance of doubt, section 7.4.3 | of RFC2246 MUST still be followed when no such exception has been | created. | | The ephemeral RSA key supplied by the server in the server key | exchange message MUST be regenerated with a frequency appropriate to | the overall threat model, and SHOULD be regenerated at least every | four hours. | | Servers MUST ensure that expired ephemeral RSA keys are destroyed | securely, having regard to the overall threat model. I would be very interested in feedback. If you were one of the people who asked for an RSA ciphersuite, does this proposal satisfy your concerns? My feeling is that the RSA ciphersuite issue is the last major problem with the draft. Hopefully I can produce one new draft and then we can take it to last call -- or is this over optimistic? :-) At any rate, if you have any other issues with the current draft, please could you let me know so I can address them at the same time as the RSA ciphersuite problem. -- Pete --- 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 Oct 10 15:10:26 2000 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 PAA11082 for ; Tue, 10 Oct 2000 15:10:25 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 10 Oct 2000 12:12:53 -0700 In-Reply-To: Pete Chown's message of "Tue, 10 Oct 2000 19:59:45 +0100" Message-ID: Lines: 28 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 Pete Chown writes: > | When TLS_RSA_WITH_AES_128_SHA has been negotiated, servers MUST send > | a server key exchange message. This is a specific exception to > | section 7.4.3 of RFC2246. For the avoidance of doubt, section 7.4.3 > | of RFC2246 MUST still be followed when no such exception has been > | created. No, I'm not comfortable with mandating ephemeral RSA. This doubles the computational load on the server and there are circumstances where the threat model simply doesn't warrant it. > | The ephemeral RSA key supplied by the server in the server key > | exchange message MUST be regenerated with a frequency appropriate to > | the overall threat model, and SHOULD be regenerated at least every > | four hours. It's senseless to have a MUST that actually doesn't require anything. I'd put this in "Security Considerations". Because forward secrecy depends on secrecy of the ephemeral keys, the ephemeral RSA key SHOULD be regenerated frequently. Although this specification does not require a specific lifetime, it is recommended that regeneration happen no less frequently than once an hour. Given that 1024-bit RSA key generation takes less than 10s, I'm not particularly bothered by once an hour. -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 Oct 10 15:44:01 2000 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 PAA11862 for ; Tue, 10 Oct 2000 15:43:58 -0400 (EDT) Date: Tue, 10 Oct 2000 14:54:51 -0500 From: Jeremey Barrett To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Reply-To: "IETF Transport Layer Security WG" Mail-Followup-To: IETF Transport Layer Security WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from Pete.Chown@skygate.co.uk on Tue, Oct 10, 2000 at 07:59:45PM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <20001010145451.N8463@jfm.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Tue, Oct 10, 2000 at 07:59:45PM +0100, Pete Chown wrote: > > Here is some suggested wording: > > | When TLS_RSA_WITH_AES_128_SHA has been negotiated, servers MUST send > | a server key exchange message. This is a specific exception to > | section 7.4.3 of RFC2246. For the avoidance of doubt, section 7.4.3 > | of RFC2246 MUST still be followed when no such exception has been > | created. > | > | The ephemeral RSA key supplied by the server in the server key > | exchange message MUST be regenerated with a frequency appropriate to > | the overall threat model, and SHOULD be regenerated at least every > | four hours. > | > | Servers MUST ensure that expired ephemeral RSA keys are destroyed > | securely, having regard to the overall threat model. > > I would be very interested in feedback. If you were one of the people > who asked for an RSA ciphersuite, does this proposal satisfy your > concerns? > Not really. I don't want to see ephemeral RSA mandated. My interest in an RSA ciphersuite is for interoperability: there ought to be at least _one_ ciphersuite which is mandated by the TLS spec and which can be reasonably implemented in all environments. IMO, that ciphersuite should be TLS_RSA_WITH_AES_128_SHA, with no mandate for ephemeral RSA. Regards, Jeremey. -- Jeremey Barrett [jeremey@cips.nokia.com, jeremey@network-alchemy.com] GnuPG fingerprint: 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F --- 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 Oct 10 17:14:45 2000 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 RAA13538 for ; Tue, 10 Oct 2000 17:14:42 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C032FC.56D80B34" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Date: Tue, 10 Oct 2000 13:54:53 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Thread-Index: AcAy7bB26tFtYOZdQJ+8M23F/lghGwAC/f7w From: "John Banes" To: "IETF Transport Layer Security WG" X-OriginalArrivalTime: 10 Oct 2000 20:54:54.0403 (UTC) FILETIME=[574AA130:01C032FC] List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5B90AD65A9E8934987DB0C8C07626574339AE7@DF-BOWWOW.platinum.corp.microsoft.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a multi-part message in MIME format. ------_=_NextPart_001_01C032FC.56D80B34 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable According to the people running secure webservers that I've talked to, TLS is already way too slow. I don't think that substantially slowing it down even further is going to be acceptable. In my opinion, the TLS_RSA_WITH_AES_128_SHA cipher suite needs to operate without ephemeral keys of any kind. A completely separate cipher suite should be defined that supports forward secrecy. Regards, John Banes Microsoft Corp. -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Tuesday, October 10, 2000 12:13 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Pete Chown writes: > | When TLS_RSA_WITH_AES_128_SHA has been negotiated, servers MUST send > | a server key exchange message. This is a specific exception to > | section 7.4.3 of RFC2246. For the avoidance of doubt, section 7.4.3 > | of RFC2246 MUST still be followed when no such exception has been > | created. No, I'm not comfortable with mandating ephemeral RSA. This doubles the computational load on the server and there are circumstances where the threat model simply doesn't warrant it. > | The ephemeral RSA key supplied by the server in the server key > | exchange message MUST be regenerated with a frequency appropriate to > | the overall threat model, and SHOULD be regenerated at least every > | four hours. It's senseless to have a MUST that actually doesn't require anything.=20 I'd put this in "Security Considerations". Because forward secrecy depends on secrecy of the ephemeral keys, the ephemeral RSA key SHOULD be regenerated frequently. Although this specification does not require a specific lifetime, it is recommended that regeneration happen no less frequently than once an hour. Given that 1024-bit RSA key generation takes less than 10s, I'm not particularly bothered by once an hour. -Ekr --- You are currently subscribed to ietf-tls as: jbanes@Exchange.Microsoft.com 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 ------_=_NextPart_001_01C032FC.56D80B34 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ietf-tls] Re: Forward secrecy and performance (was AES = ciphersuites)

According to the people running secure webservers that = I've talked to, TLS is already way too slow. I don't think that = substantially slowing it down even further is going to be = acceptable.

In my opinion, the TLS_RSA_WITH_AES_128_SHA cipher = suite needs to operate without ephemeral keys of any kind. A completely = separate cipher suite should be defined that supports forward = secrecy.

Regards,

John Banes
Microsoft Corp.


-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Tuesday, October 10, 2000 12:13 PM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] Re: Forward secrecy and = performance (was AES
ciphersuites)


Pete Chown <Pete.Chown@skygate.co.uk> = writes:
> | When TLS_RSA_WITH_AES_128_SHA has been = negotiated, servers MUST send
> | a server key exchange message.  This is a = specific exception to
> | section 7.4.3 of RFC2246.  For the = avoidance of doubt, section 7.4.3
> | of RFC2246 MUST still be followed when no such = exception has been
> | created.
No, I'm not comfortable with mandating ephemeral RSA. = This doubles
the computational load on the server and there are = circumstances where
the threat model simply doesn't warrant it.

> | The ephemeral RSA key supplied by the server in = the server key
> | exchange message MUST be regenerated with a = frequency appropriate to
> | the overall threat model, and SHOULD be = regenerated at least every
> | four hours.
It's senseless to have a MUST that actually doesn't = require anything.
I'd put this in "Security = Considerations".

        Because = forward secrecy depends on secrecy of the ephemeral keys,
        the = ephemeral RSA key SHOULD be regenerated frequently. Although
        this = specification does not require a specific lifetime, it is
        recommended that regeneration happen no less frequently than = once
        an = hour.

Given that 1024-bit RSA key generation takes less than = 10s, I'm not
particularly bothered by once an hour.

-Ekr


---
You are currently subscribed to ietf-tls as: = jbanes@Exchange.Microsoft.com
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 ------_=_NextPart_001_01C032FC.56D80B34-- From bounce-ietf-tls-3458737@lists.certicom.com Tue Oct 10 18:15:45 2000 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 SAA14497 for ; Tue, 10 Oct 2000 18:15:39 -0400 (EDT) Message-ID: Date: Tue, 10 Oct 2000 15:14:03 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E394AB.C12DC28D@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > John Banes wrote: > > According to the people running secure webservers that I've talked to, TLS is > already way too slow. I don't think that substantially slowing it down even > further is going to be acceptable. > > In my opinion, the TLS_RSA_WITH_AES_128_SHA cipher suite needs to operate > without ephemeral keys of any kind. A completely separate cipher suite should > be defined that supports forward secrecy. > > Regards, > > John Banes > Microsoft Corp. I concur, completely. -- Nelson Bolyard Sun / Netscape Alliance --- 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 Oct 10 19:15:33 2000 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 TAA15398 for ; Tue, 10 Oct 2000 19:14:39 -0400 (EDT) Date: Tue, 10 Oct 2000 19:15:03 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nelsonb@netscape.com on Tue, Oct 10, 2000 at 03:14:03PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001010191503.A25823@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net So folks from the two largest vendors of SSL/TLS applications don't like ephemeral suites, even if the language is that keys SHOULD be replaced only once an hour? That's too demanding? What I'm hearing, and maybe I'm too cynical, is MSFT and iPlanet suggesting that they're more concerned about server performance than security. What completely separate cipher suite do you propose? Are your companies prepared to support new FS suites in both server and client applications? Or the existing DH schemes that provide forward secrecy? How do we actually provide FS, short of telling everyone to use Mozilla[0] and Apache/mod_ssl/OpenSSL? I'm afraid I'm not being very politic here, but ISTM that for the most important/vulnerable applications of TLS (i.e., https), MSFT and iPlanet/AOL are *the* key players.[1] You want your server customers to have fast sites. We want better security. At this point, even though my Apache install supports DH ciphers (thanks to Stephen, Ralf, et. al.), I can't achieve PFS because Navigator and IE don't support those ciphers. Outlining a new scheme does little good if its optional and MSFT/iPlanet/AOL choose to ignore it. How do we, in the real world, make forward secrecy possible? -Peter [0] which might need to use OpenSSL instead of the iPlanet code to provide forward secrecy [1] In controlled environments, I imagine most folks who care are using things like the OpenSSL toolkit to build more secure systems, but most users are constrained to whatever MSFT/iPlanet/AOL offer them. On Tue, Oct 10, 2000 at 03:14:03PM -0700, Nelson Bolyard wrote: > > John Banes wrote: > > > > According to the people running secure webservers that I've talked to, TLS is > > already way too slow. I don't think that substantially slowing it down even > > further is going to be acceptable. > > > > In my opinion, the TLS_RSA_WITH_AES_128_SHA cipher suite needs to operate > > without ephemeral keys of any kind. A completely separate cipher suite should > > be defined that supports forward secrecy. > > John Banes > > Microsoft Corp. > > I concur, completely. > > -- > Nelson Bolyard Sun / Netscape Alliance -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.org/ --- 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 Oct 10 19:23:11 2000 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 TAA15505 for ; Tue, 10 Oct 2000 19:23:10 -0400 (EDT) Message-ID: Date: Tue, 10 Oct 2000 16:22:00 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E3A498.90D03CFC@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Peter W wrote: > How do we, in the real world, make forward secrecy possible? > > -Peter IMO, John Banes already answered that question. > On Tue, Oct 10, 2000 at 03:14:03PM -0700, Nelson Bolyard wrote: > > > John Banes wrote: > > > A completely separate cipher suite should > > > be defined that supports forward secrecy. > > > > John Banes > > > Microsoft Corp. > > > > > I concur, completely. > > > > -- > > Nelson Bolyard Sun / Netscape Alliance By defining the cipher suites separately, the server administrator is given the choice of whether or not he wishes to pay the price for the PFS, and likewise, the client has the option of requiring, allowing, or disallowing the use of PFS. -- Nelson Bolyard Sun / Netscape Alliance --- 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 Oct 10 20:03:26 2000 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 UAA15844 for ; Tue, 10 Oct 2000 20:03:25 -0400 (EDT) Message-ID: Date: Tue, 10 Oct 2000 17:02:59 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] The https client TLS deployment dilemma 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: <39E3AE33.66CF6278@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Today a substantial percentage of the https/SSL servers out there do not successfully negotiate an SSL3 session with a standard-compliant TLS/SSL3 client. This includes servers run by large fortune 500 corporations, as well as smaller web sites. Let's call these server "TLS intolerant". These servers REQUIRE that the value presented in the client_version field of the PreMasterSecret component of the ClientKeyExchange message contain exactly 0x0300, and they will not complete an SSL/TLS handshake if it contains any other value. The TLS spec requires (and it was also the intent of the SSL3 spec) that the client_version field in the RSA encrypted premaster secret exactly match the value sent by the client in the ClientHello message. So a spec-compliant TLS/SSL client will send 0x0301 in the client_version fields of both the ClientHello and the ClientKeyExchange messages, even if it negotiates down to SSL3 (0x0300) in the ServerHello message. A client that behaves that way (following the spec) will not interoperate with the servers described above. To an end user, such a client product will appear to be defective, buggy, at fault, when in fact it is correct. One extant client product that claims to support TLS apparently sends the negotiated protocol version number, not necessarily the version number it sent in the ClientHello message, to the server in the client_version field in the RSA-encrypted pre-master secret message. Besides not being spec compliant, this behavior makes roll-back detection impossible. But that client does interoperate with the "TLS Intolerant" SSL3 servers mentioned above. To an end user comparing that product with one that follows the spec strictly, that client product appears to be superior, because it interoperates with a larger number of servers. The dilemma: If https client vendors today wish to deploy TLS (as well as SSL3) in their client products, their choices appear to be: a) Implement TLS per the spec, and don't interoperate with a large number of servers out there, and thereby appear to be inferior to the products that do interoperate with those "TLS Intolerant" servers, or b) Implement TLS, but send the negotiated protocol version in the pre-master secret message. This is not spec compliant, but interoperates with more servers than choice a above, and is seen as superior by end users. c) Wait until either (A) most of the "TLS intolerant" servers are replaced, or (B) all (or most) other https clients out there follow the TLS spec, thereby leveling the field for https clients, or (C) until some other as-yet-unseen market force creates a demand for TLS spec-compliant https clients. Issues like this one must be resolved before the world will switch from SSL3 to TLS. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape or iPlanet --- 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 Oct 10 20:34:55 2000 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 UAA16076 for ; Tue, 10 Oct 2000 20:34:48 -0400 (EDT) Message-ID: Date: Wed, 11 Oct 2000 01:27:28 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E3B3F0.884E8CC0@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Nelson Bolyard wrote: > > > By defining the cipher suites separately, the server administrator is given > the choice of whether or not he wishes to pay the price for the PFS, and > likewise, the client has the option of requiring, allowing, or disallowing > the use of PFS. > This assumes that the clients will actually support PFS and non PFS suites. We could end up in the situation where only the non PFS ciphersuite is implemented and we are back to the current situation where there are no "browser TLS/SSL" ciphersuites supporting PFS. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 11 01:17:13 2000 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 BAA22219 for ; Wed, 11 Oct 2000 01:17:08 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-160.dialup.zetnet.co.uk [194.247.40.203] claimed to be zetnet.co.uk Message-ID: Date: Wed, 11 Oct 2000 03:46:39 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39E3D48F.6CF7EA51@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Nelson Bolyard wrote: > Peter W wrote: > > How do we, in the real world, make forward secrecy possible? > > IMO, John Banes already answered that question. > > > On Tue, Oct 10, 2000 at 03:14:03PM -0700, Nelson Bolyard wrote: > > > > John Banes wrote: > > > > > A completely separate cipher suite should > > > > be defined that supports forward secrecy. > > > > > > I concur, completely. > > By defining the cipher suites separately, the server administrator is > given the choice of whether or not he wishes to pay the price for the > PFS, and likewise, the client has the option of requiring, allowing, or > disallowing the use of PFS. No, that's not sufficient. Suppose we assume that servers might have either RSA or DSS certificates, and there's no simple way to require them to switch. In that case, for clients to be able to require PFS, all new servers MUST be able to negotiate at least one PFS-only ciphersuite; i.e. either one with RSA certification, or one with DSS certification [*]. The one with DSS certification should be TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, in order to interoperate with existing TLS clients and servers that wanted to support PFS. For servers to be able to require PFS, all new clients MUST be able to negotiate *both* the RSA PFS-only ciphersuite, and TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [**]. Note that "MUST be able to negotiate" is stronger than saying that a ciphersuite with PFS simply has to be implemented; the TLS 1.0 spec did that, and it's had basically no effect. If both clients and servers can require PFS, then it is not possible for either a client or a server to disallow PFS (when talking to a peer that implements the new spec), but that is exactly as it should be. Clearly, it is not possible to say that all TLS 1.0 implementations have to satisfy these requirements, because that would declare existing implementations non-conformant. However, what we could do is effectively define a "TLS 1.0 and a half", i.e. a specification such that if a TLS implementation conforms to it, it will have done all it can to facilitate the use of strong ciphersuites that provide forward secrecy. Note that since any "TLS 1.0 and a half" implementations will have been changed since the relaxation of the U.S. export restrictions, it is also possible to define the spec so that if two such implementations communicate, they are guaranteed to negotiate a non-export ciphersuite [***]. An alternative would be to put this in the next version of TLS, but if that's going to take a long time, I don't think there's any need to wait for it. Two recent events have made it possible to significantly improve the security and interoperability of TLS: the relaxation of the U.S. export regs, and the expiry of the RSA patent. We should take advantage of those events without further delay. [*] Technically, certificates can be marked as for RSA encryption only (i.e. they have a keyUsage extension with keyEncipherment but not digitalSignature set), in which case it's not possible to use either ephemeral RSA or ephemeral DH with them, and still conform to RFC 2246. However, I believe I'm correct in saying that in order to support export algorithms, almost all RSA certificates in practice support signing. [**] I argued in a previous post that having the client include more than key exchange algorithm in the client hello allows an adversary to attack the weakest of them. That argument is correct, but if it's not feasible to make servers switch to DSS certificates, we'll just have to put up with this, because PFS is more important. [***] ... except that the attack described in http://www.imc.org/ietf-tls/mail-archive/msg01671.html and http://www.imc.org/ietf-tls/mail-archive/msg01677.html may still be possible. I'll have to think about whether it is possible to fix that at the same time. There may be an argument for bumping the TLS version number (without making any other significant changes) in order to fix it. - -- 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 iQEVAwUBOePUDzkCAxeYt5gVAQFdpggAufslytsiObPDw8ikYn0+rYEJRUX1uHED rKAtlnyYXkRA12Bhf3bUzg8xWTiWqok2YJCA84e0UH9hAAxgCdVY+DcDmISaLBJY Ea2XE5wgRuvfMN5Cu3DViopv00M5nj/0sqyBVk56+TQod9U4LWI6HVHxMHLvMWji fPXt8DA/0OId8w0K5IXViFYYoHG8TGrTHLzAS5GRYOySL1BMIAudBl1zpyw2Cr1p NIUBHBIJi0Gpa+IEtQLMwDDZzF7P/INCoIAJfa3UU+RXRx1Tit/FU8VWguyurxSx 5NPQ85UbhRF32eSyXwfkJlP14Q+zDi2iQ8k69ar1+jmDJKW0ievYUA== =I07c -----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 Wed Oct 11 10:32:51 2000 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 KAA11801 for ; Wed, 11 Oct 2000 10:32:49 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 11 Oct 2000 07:35:55 -0700 In-Reply-To: David Hopwood's message of "Wed, 11 Oct 2000 03:46:39 +0100" Message-ID: Lines: 10 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 David Hopwood writes: > Note that "MUST be able to negotiate" is stronger than saying that a > ciphersuite with PFS simply has to be implemented; the TLS 1.0 spec did > that, and it's had basically no effect. Are you suggesting that all compliant clients must offer at all times one of the PFS cipher suites? Regardless of user configuration? -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 Oct 11 17:37:35 2000 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 RAA22378 for ; Wed, 11 Oct 2000 17:37:34 -0400 (EDT) Date: Wed, 11 Oct 2000 22:36:55 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from jbanes@Exchange.Microsoft.com on Tue, Oct 10, 2000 at 01:54:53PM -0700 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001011223655.A4832@hyena.skygate.co.uk> X-List-Host: SKYLIST.net John Banes wrote: > According to the people running secure webservers that I've talked to, > TLS is already way too slow. I don't think that substantially slowing it > down even further is going to be acceptable. I have been doing a bit of thinking about this... I think that by doing the forward secrecy ciphersuites right, we can actually speed things up. First of all, here is the ServerKeyExchange message, taken from RFC2246, but simplified a bit: struct { select (KeyExchangeAlgorithm) { case diffie_hellman: opaque dh_p<1..2^16-1>; opaque dh_g<1..2^16-1>; opaque dh_Ys<1..2^16-1>; digitally-signed struct { opaque sha_hash[20]; }; case rsa: opaque rsa_modulus<1..2^16-1>; opaque rsa_exponent<1..2^16-1>; digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; }; } ServerKeyExchange; Now, in each case, the signature is on the ephemeral key *only*. If the ephemeral key is only regenerated every four hours (as in my original wording) this signature only needs to be calculated once. So ephemeral RSA will cost the server about the same as static RSA. Now suppose we use ephemeral Diffie-Hellman. The RSA signature on the DH parameters will be precalculated. (This assumes a slight change to my original text which assumed a new DH secret each time.) Now because of the short exponent optimisation described by David Hopwood, the DH agreement is faster than RSA decryption. Static RSA has to do one RSA decryption on the server. EDH as described here only needs to do one Diffie-Hellman agreement. This should speed things up quite significantly. (I hope I've not missed something silly here! :-) ) -- Pete --- 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 Oct 11 17:44:08 2000 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 RAA22497 for ; Wed, 11 Oct 2000 17:44:07 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 11 Oct 2000 14:47:27 -0700 In-Reply-To: Pete Chown's message of "Wed, 11 Oct 2000 22:36:55 +0100" 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 Pete Chown writes: > > According to the people running secure webservers that I've talked to, > > TLS is already way too slow. I don't think that substantially slowing it > > down even further is going to be acceptable. > > I have been doing a bit of thinking about this... I think that by > doing the forward secrecy ciphersuites right, we can actually speed > things up. > > First of all, here is the ServerKeyExchange message, taken from > RFC2246, but simplified a bit: > > struct { > select (KeyExchangeAlgorithm) { > case diffie_hellman: > opaque dh_p<1..2^16-1>; > opaque dh_g<1..2^16-1>; > opaque dh_Ys<1..2^16-1>; > > digitally-signed struct { > opaque sha_hash[20]; > }; > case rsa: > opaque rsa_modulus<1..2^16-1>; > opaque rsa_exponent<1..2^16-1>; > > digitally-signed struct { > opaque md5_hash[16]; > opaque sha_hash[20]; > }; > }; > } ServerKeyExchange; > > Now, in each case, the signature is on the ephemeral key *only*. Huh? See S 7.4.3 of RFC 2246: md5_hash MD5(ClientHello.random + ServerHello.random + ServerParams); sha_hash SHA(ClientHello.random + ServerHello.random + ServerParams); Even if we changed TLS in the way you propose, it would introduce active attacks. An attacker who had broken one ephemeral key could then actively insert it into any connection by replaying the SKE. > (I hope I've not missed something silly here! :-) ) I'm afraid that you have. -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 Oct 11 19:22:27 2000 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 TAA23666 for ; Wed, 11 Oct 2000 19:22:26 -0400 (EDT) Message-ID: Date: Thu, 12 Oct 2000 00:18:16 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E4F538.CEF6C248@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Pete Chown writes: > > > According to the people running secure webservers that I've talked to, > > > TLS is already way too slow. I don't think that substantially slowing it > > > down even further is going to be acceptable. > > > > I have been doing a bit of thinking about this... I think that by > > doing the forward secrecy ciphersuites right, we can actually speed > > things up. > > [description deleted] > > > > Now, in each case, the signature is on the ephemeral key *only*. > Huh? > > See S 7.4.3 of RFC 2246: > > md5_hash > MD5(ClientHello.random + ServerHello.random + ServerParams); > > sha_hash > SHA(ClientHello.random + ServerHello.random + ServerParams); > > Even if we changed TLS in the way you propose, it would introduce > active attacks. An attacker who had broken one ephemeral key could > then actively insert it into any connection by replaying the SKE. > I've been thinking along similar lines wrt performance and precomputation. The best I could come up with to avoid a replay attack was to have some kind of timestamp and key lifetime protected by the signature. So it would say something like the time the key was generated and its lifetime. This would then rely on the client checking and rejecting an expired key. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 11 19:44:13 2000 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 TAA24107 for ; Wed, 11 Oct 2000 19:44:13 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 11 Oct 2000 16:47:27 -0700 In-Reply-To: Dr S N Henson's message of "Thu, 12 Oct 2000 00:18:16 +0100" 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 Dr S N Henson writes: > I've been thinking along similar lines wrt performance and > precomputation. The best I could come up with to avoid a replay attack > was to have some kind of timestamp and key lifetime protected by the > signature. So it would say something like the time the key was generated > and its lifetime. This would then rely on the client checking and > rejecting an expired key. I hate using time in cryptographic protocols. This requires clocks to be synchronized. As you know, this was a big problem with Kerberos. Granted, we don't need such tight synchronization here, but I think it's asking for trouble. -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 Oct 11 22:34:20 2000 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 WAA28131 for ; Wed, 11 Oct 2000 22:34:19 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-185.dialup.zetnet.co.uk [194.247.40.235] claimed to be zetnet.co.uk Message-ID: Date: Thu, 12 Oct 2000 01:02:44 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39E4FFA4.A22C4EA2@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Pete Chown wrote: [snip] > Now, in each case, the signature is on the ephemeral key *only*. If > the ephemeral key is only regenerated every four hours (as in my > original wording) this signature only needs to be calculated once. No, the signature is also on the client and server random values, and this is essential to prevent replay attacks. The same applies to ephemeral DH. > (I hope I've not missed something silly here! :-) ) Don't worry, I thought the same thing for a few minutes when I was doing the performance analysis :-) - -- 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 iQEVAwUBOeT/mTkCAxeYt5gVAQEffAf9HeHEI5BguQCSqgiKBB5CKcMnHBrJZ2mM pouCPOGBwni9ClCMq0Tre7WT/j8ZB79ZtTzj+YHkyEAF2cbUNDOZVoWwHRfqj9gj vKt8yfiVUf05H79ibV/UuHfPZfZ8o2D5PTRcgjXSqyaUXWRzzMFi/siiTrEav1rI RGcHM1VAe8QGs2dt0GX6fl8rxzVhIg2B34SCtZVWWp3G/x+f3I6N60R7VvD8UOm0 rSEQNZvrhew/HMiQv4zj633yTkFut72xDyh7W2idE8w1nhiOUKugcyukwGZ3fkfv oX9wzFe6EUdtkBiMZjSNbFEcsMXsfvEDRiUJla+ShANCI42lrgVeIQ== =B6MS -----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 Thu Oct 12 08:17:00 2000 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 IAA22762 for ; Thu, 12 Oct 2000 08:16:59 -0400 (EDT) Message-ID: Date: Thu, 12 Oct 2000 13:12:38 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E5AAB6.B351EC5C@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Dr S N Henson writes: > > I've been thinking along similar lines wrt performance and > > precomputation. The best I could come up with to avoid a replay attack > > was to have some kind of timestamp and key lifetime protected by the > > signature. So it would say something like the time the key was generated > > and its lifetime. This would then rely on the client checking and > > rejecting an expired key. > I hate using time in cryptographic protocols. This requires clocks > to be synchronized. As you know, this was a big problem with Kerberos. > Granted, we don't need such tight synchronization here, but I think it's > asking for trouble. > I'm not too keen on using time myself. However if this can be used to provide PFS with minimal performance penalty, and no one has any better ideas, then I can live with it. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Thu Oct 12 08:59:32 2000 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 IAA24406 for ; Thu, 12 Oct 2000 08:59:31 -0400 (EDT) Date: Thu, 12 Oct 2000 09:00:29 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hopwood@zetnet.co.uk on Wed, Oct 11, 2000 at 03:46:39AM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001012090029.A8126@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Wed, Oct 11, 2000 at 03:46:39AM +0100, David Hopwood wrote: > Nelson Bolyard wrote: > > By defining the cipher suites separately, the server administrator is > > given the choice of whether or not he wishes to pay the price for the > > PFS, and likewise, the client has the option of requiring, allowing, or > > disallowing the use of PFS. > > No, that's not sufficient. > For servers to be able to require PFS, all new clients MUST be able to > negotiate *both* the RSA PFS-only ciphersuite, and > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [**]. > > Note that "MUST be able to negotiate" is stronger than saying that a > ciphersuite with PFS simply has to be implemented; the TLS 1.0 spec did > that, and it's had basically no effect. I agree wholeheartedly. :-( > However, what we could do is effectively > define a "TLS 1.0 and a half", i.e. a specification such that if a > TLS implementation conforms to it, it will have done all it can to > facilitate the use of strong ciphersuites that provide forward secrecy. There are a few things I am concerned about re: PFS. 1) what code is required to be present in a conformant app? 2) what suites, if any, are required to be enabled "out of the box"? 3) what suites, if any, may not be disabled by the app user? An issue we can't even begin to address is software configuration, e.g. in Navigator I can enable/disable certain SSL3 suites, but I cannot specify the order of preference. I suspect that Microsoft, iPlanet, and AOL will take measures to make PFS unlikely to be used. I'd love to see PFS at least meet criteria two: required to be enabled in "out of the box" configurations. Criteria one is only sufficient if the app is well designed: can the users find the configuration? Does the app give good error messages? [0] As for server performance issues: how bad is it, really? John said that he had heard second hand that "TLS" was "way too slow". What does that mean? 25% slower than SSL/RSA? 250% slower? Which TLS suites? What is an acceptable penalty for FS? I'm encouraged by the recent talk about ways to achieve FS without big performance penalties. Goodness knows fast FS is better than slow FS. Fast FS + good spec requirements sounds like a winning combination. > An alternative would be to put this in the next version of TLS, but if > that's going to take a long time, I don't think there's any need to wait > for it. Two recent events have made it possible to significantly improve > the security and interoperability of TLS: the relaxation of the U.S. > export regs, and the expiry of the RSA patent. We should take advantage > of those events without further delay. Yes, absolutely. The marketing folks love to boast SSL/TLS support as if it were magic security pixie dust. Let's make sure it does its job well. -Peter [0] For instance, if I deliberately disable most ciphers in Navigator 4.75 and visit a site that I had been to before making the client changes, my browser tells me "Netscape and this server cannot communicate securely because they have no common encryption algorithm(s)" -- I have most ciphers disabled, but the browser doesn't suggest checking my configuration. Now suppose the problem is that the server only supports PFS suites, and my TLS 1.5 browser lacks the optional suites and has the others disabled by default. This would stop many, maybe most, users in their tracks. Get an obscure error message trying amazon.com but bn.com works fine? Poor choice of client defaults + poor error messages = enticement to not use PFS. -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.org/ --- 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 Thu Oct 12 10:58:20 2000 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 KAA28735 for ; Thu, 12 Oct 2000 10:58:19 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 12 Oct 2000 08:01:36 -0700 In-Reply-To: Peter W's message of "Thu, 12 Oct 2000 09:00:29 -0400" Message-ID: Lines: 26 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 Peter W writes: > On Wed, Oct 11, 2000 at 03:46:39AM +0100, David Hopwood wrote: > > Nelson Bolyard wrote: > > For servers to be able to require PFS, all new clients MUST be able to > > negotiate *both* the RSA PFS-only ciphersuite, and > > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [**]. > > > > Note that "MUST be able to negotiate" is stronger than saying that a > > ciphersuite with PFS simply has to be implemented; the TLS 1.0 spec did > > that, and it's had basically no effect. > > I agree wholeheartedly. :-( As far as I can tell, the reason that there has been no real deployment of the PFS ciphersuite is that it's DSS/DHE, and there's been no real CA support for DSA. > As for server performance issues: how bad is it, really? John said that > he had heard second hand that "TLS" was "way too slow". What does that > mean? 25% slower than SSL/RSA? 250% slower? Which TLS suites? What is an > acceptable penalty for FS? I can't speak for John, but I suspect he means that SSL is also too slow already. Quite reasonable server machines get brought to their knees by the introduction of SSL/TLS, even in the relatively fast RSA mode. -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 Thu Oct 12 10:59:11 2000 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 KAA28781 for ; Thu, 12 Oct 2000 10:59:09 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 12 Oct 2000 08:02:28 -0700 In-Reply-To: Dr S N Henson's message of "Thu, 12 Oct 2000 13:12:38 +0100" Message-ID: Lines: 25 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 Dr S N Henson writes: > Eric Rescorla wrote: > > > > Dr S N Henson writes: > > > I've been thinking along similar lines wrt performance and > > > precomputation. The best I could come up with to avoid a replay attack > > > was to have some kind of timestamp and key lifetime protected by the > > > signature. So it would say something like the time the key was generated > > > and its lifetime. This would then rely on the client checking and > > > rejecting an expired key. > > I hate using time in cryptographic protocols. This requires clocks > > to be synchronized. As you know, this was a big problem with Kerberos. > > Granted, we don't need such tight synchronization here, but I think it's > > asking for trouble. > > > > I'm not too keen on using time myself. However if this can be used to > provide PFS with minimal performance penalty, and no one has any better > ideas, then I can live with it. I don't think I am. This seems to me to introduce a whole new set of potential security risks. PFS is not the only desirable security goal here. Protection against active attacks is also important. -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 Thu Oct 12 14:01:28 2000 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 OAA03274 for ; Thu, 12 Oct 2000 14:01:23 -0400 (EDT) Message-ID: Date: Thu, 12 Oct 2000 18:58:32 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E5FBC8.FBE2D974@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Peter W wrote: > > > As for server performance issues: how bad is it, really? John said that > he had heard second hand that "TLS" was "way too slow". What does that > mean? 25% slower than SSL/RSA? 250% slower? Which TLS suites? What is an > acceptable penalty for FS? > Well as has been indicated RSA FS doubles the number of server private key operations so doubling the handshake time is a rough estimate. This may not be tolerable in all situations but its similar to the overhead used by the "magic certificates" which enabled 128 bits connections in export browsers or those which perform client authentication by doing two handshakes. In any case if TLS is "way too slow" already then users may well not use AES on those grounds and stick with RC4. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Thu Oct 12 14:13:52 2000 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 OAA03420 for ; Thu, 12 Oct 2000 14:13:52 -0400 (EDT) Message-ID: Date: Thu, 12 Oct 2000 19:13:16 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E5FF3C.1B8583A6@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Dr S N Henson writes: > > > Eric Rescorla wrote: > > > > > > Dr S N Henson writes: > > > > I've been thinking along similar lines wrt performance and > > > > precomputation. The best I could come up with to avoid a replay attack > > > > was to have some kind of timestamp and key lifetime protected by the > > > > signature. So it would say something like the time the key was generated > > > > and its lifetime. This would then rely on the client checking and > > > > rejecting an expired key. > > > I hate using time in cryptographic protocols. This requires clocks > > > to be synchronized. As you know, this was a big problem with Kerberos. > > > Granted, we don't need such tight synchronization here, but I think it's > > > asking for trouble. > > > > > > > I'm not too keen on using time myself. However if this can be used to > > provide PFS with minimal performance penalty, and no one has any better > > ideas, then I can live with it. > I don't think I am. This seems to me to introduce a whole new set > of potential security risks. PFS is not the only desirable security > goal here. Protection against active attacks is also important. > Have you any specific attacks in mind? We're already using time in TLS anyway with certificate verification, which could be exploited if the server or client time can be manipulated by an attacker. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Thu Oct 12 14:22:02 2000 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 OAA03563 for ; Thu, 12 Oct 2000 14:22:01 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 12 Oct 2000 11:25:26 -0700 In-Reply-To: Dr S N Henson's message of "Thu, 12 Oct 2000 18:58:32 +0100" Message-ID: Lines: 17 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 Dr S N Henson writes: > This may not be tolerable in all situations but its similar to the > overhead used by the "magic certificates" which enabled 128 bits > connections in export browsers or those which perform client > authentication by doing two handshakes. Only for Netscape. As you know, Microsoft went to great trouble to optimize out this second handshake. > In any case if TLS is "way too slow" already then users may well not use > AES on those grounds and stick with RC4. I think you've hit the nail on the head here. It's already going to be a stretch to get users to use AES instead of RC4. RSA performance is much more relevant to SSL performance than symmetric performance, so it will be an even harder sell to convince them to use AES if it also doubles handshake cost. -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 Thu Oct 12 14:24:42 2000 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 OAA03596 for ; Thu, 12 Oct 2000 14:24:41 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 12 Oct 2000 11:28:10 -0700 In-Reply-To: Dr S N Henson's message of "Thu, 12 Oct 2000 19:13:16 +0100" Message-ID: Lines: 25 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 Dr S N Henson writes: > > > I'm not too keen on using time myself. However if this can be used to > > > provide PFS with minimal performance penalty, and no one has any better > > > ideas, then I can live with it. > > I don't think I am. This seems to me to introduce a whole new set > > of potential security risks. PFS is not the only desirable security > > goal here. Protection against active attacks is also important. > > Have you any specific attacks in mind? Only the one I already mentioned where you exploit the compromise of the ephemeral key. On the other hand, I haven't had time to analyze it very carefully. > We're already using time in TLS anyway with certificate verification, > which could be exploited if the server or client time can be manipulated > by an attacker. Sure, but the certificate verification basically operates on a much longer time scale. Most people can get their clocks right on a day/week timescale. Lots of people's clocks are off by a couple of hours. I'd also like to point out that a change of this magnitude would likely result in recycling TLS at Proposed. -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 Thu Oct 12 17:12:01 2000 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 RAA05956 for ; Thu, 12 Oct 2000 17:11:59 -0400 (EDT) Message-ID: Date: Thu, 12 Oct 2000 14:11:44 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E62910.82AE86EC@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > Peter W writes: > > As for server performance issues: how bad is it, really? John said that > > he had heard second hand that "TLS" was "way too slow". What does that > > mean? 25% slower than SSL/RSA? 250% slower? Which TLS suites? What is an > > acceptable penalty for FS? > I can't speak for John, but I suspect he means that SSL is also too > slow already. I also interpreted it that way. The comparison isn't TLS vs SSL, it's https vs http, I suspect. > Quite reasonable server machines get brought to their > knees by the introduction of SSL/TLS, even in the relatively fast RSA mode. Yes. In my experience, the single largest factor limiting the deployment of SSL/TLS today is the performance hit of https as opposed to http. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape --- 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 Sun Oct 15 08:45:19 2000 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 IAA08306 for ; Sun, 15 Oct 2000 08:45:18 -0400 (EDT) Message-ID: Date: Sun, 15 Oct 2000 13:44:40 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.75 [en] (WinNT; U) MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39E9A6B8.E24DFFCC@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Nelson Bolyard wrote: > Eric Rescorla wrote: > > Quite reasonable server machines get brought to their > > knees by the introduction of SSL/TLS, even in the relatively fast RSA mode. > > Yes. In my experience, the single largest factor limiting the deployment > of SSL/TLS today is the performance hit of https as opposed to http. I find these remarks hard to understand - from where I'm sitting, performance doesn't limit the deployment of TLS - almost every site we host uses it where needed, without any performance problems at all. OK, you have to size your kit appropriately, but this isn't exactly news, and for all except the largest sites, "appropriately" means perfectly ordinary high end PCs. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.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 Sun Oct 15 17:31:30 2000 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 RAA10660 for ; Sun, 15 Oct 2000 17:31:29 -0400 (EDT) Date: Mon, 16 Oct 2000 08:31:12 +1100 (EST) From: Damien Miller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) In-Reply-To: Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you 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 On Sun, 15 Oct 2000, Ben Laurie wrote: > I find these remarks hard to understand - from where I'm sitting, > performance doesn't limit the deployment of TLS - almost every site we > host uses it where needed, without any performance problems at all. It would be nice to use TLS everywhere, not just ``where needed''. -d -- | ``The power of accurate observation is | Damien Miller | commonly called cynicism by those who | @Work | have not got it'' - George Bernard Shaw | http://www.mindrot.org --- 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 Oct 16 02:31:33 2000 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 CAA29717 for ; Mon, 16 Oct 2000 02:31:27 -0400 (EDT) Message-ID: Date: Mon, 16 Oct 2000 15:30:12 +0900 From: Hirosato Tsuji Reply-To: "IETF Transport Layer Security WG" X-Mailer: Mozilla 4.73 [ja] (WinNT; U) X-Accept-Language: ja MIME-Version: 1.0 To: "IETF Transport Layer Security WG" CC: atsuhiro@iss.isl.melco.co.jp, m-saeki@iss.isl.melco.co.jp, nakawaji@iss.isl.melco.co.jp, matsui@iss.isl.melco.co.jp, chika@iss.isl.melco.co.jp, hidenori@iss.isl.melco.co.jp, norim@iss.isl.melco.co.jp, hirosato@iss.isl.melco.co.jp Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39EAA074.438E5924@iss.isl.melco.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Dear TLS-WG members, Win Treese wrote: > > I don't expect to put MISTY1 ciphersuites forward on the standards > track. Are there substantive comments on the draft, or objections to it > becoming an Informational RFC? We are very sorry to be late in responding your comments. As our previous draft didn't mention an enough statement on IPR of MISTY1, there might be misunderstandings. So please let me introduce the current IPR of MISTY1 to you. David Hopwood wrote: > > Yes, there are objections to it becoming an informational RFC: > > - the current draft does not conform to section 10 of RFC 2026, because > MISTY1 is patented and the draft doesn't mention that. Agreed. We will add the IPR statement of MISTY1 to the next draft. Ben Laurie wrote: > > > > Its not exactly an onerous requirement, is it? An email saying "Hi" to > > > MISTY@isl.melco.co.jp would appear to satisfy. > > > > That's not obvious. You need to contact them for more information. > > It doesn't say what that information will be. > > Sorry, misread it - I thought "contract with Mitsubishi" said "contact > with Mitsubishi". We are sorry that currently email saying "Hi" from you isn't enough to give you the royalty-free patent license. We need the "MISTY Patent Roalty-Free License Agreement" from you. This rule was decided to consider the Japanese goverment's export control law. Please understand that it is NOT intended to restrict your implementation and application of MISTY. The followings are the extracts from the IPR statement on Mitsubishi Electric's home page. - Conditions for the royalty-free patent license - Only entites who complete the "MISTY Patent Roalty-Free License Agreement" may reserve a copy of the royalty free license. - MISTY1 Patent Royalty-Free License Agreement English version (sample) - Information on the MISTY1 Patent Royalty-Free License Agreement Mitsubishi Electric Corporation Corporate$B!!(BLicensing$B!!(BDept. (Group 1) FAX: +81-3-5252-7879 You can find the complete IPR statement at the following URL. http://www.mitsubishi.com/ghp_japan/misty/licensee.htm Eric Rescorla wrote: > > That's not obvious. You need to contact them for more information. > It doesn't say what that information will be. > > Maybe you have to give them a DNA sample or your firstborn whild > or something. That wouldn't be a "fee", strictly speaking. Sorry for our ambiguous statements. But We promise that we don't require your DNA samples nor your firstborn children. David Hopwood wrote: > > It might satisfy if-and-only-if Mitsubishi guaranteed that there would > continue to be a royalty-free license permanently. However, as I pointed > out in my other post, MISTY1 doesn't really have any advantages over AES. We believe that Mitsubishi Electric will continue the royalty-free patent license permanetly. But our current IPR statement doesn't mention about that issue explicitly. Do we need the explicit statement to guarantee? We proposed the cipher suites with "MISTY1" not only for our internal use nor private use. We hope that you can implement TLS with "MISTY1" and use them worldwide freely. If you have more comments and suggestions to improve our internet draft, please let us know. Thank you for your cooperation. -------------------------------------------------- Hirosato Tsuji Mitsubishi Electric Corporation Information Technology R&D Center 5-1-1 Ofuna, Kamakura, Kanagawa 247-8501 JAPAN -------------------------------------------------- --- 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 Oct 16 12:47:43 2000 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 MAA09950 for ; Mon, 16 Oct 2000 12:47:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: Date: Mon, 16 Oct 2000 09:47:19 -0700 To: "IETF Transport Layer Security WG" From: Paul Hoffman / IMC Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-misty1-00.txt Cc: atsuhiro@iss.isl.melco.co.jp, m-saeki@iss.isl.melco.co.jp, nakawaji@iss.isl.melco.co.jp, matsui@iss.isl.melco.co.jp, chika@iss.isl.melco.co.jp, hidenori@iss.isl.melco.co.jp, norim@iss.isl.melco.co.jp, hirosato@iss.isl.melco.co.jp Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 3:30 PM +0900 10/16/00, Hirosato Tsuji wrote: > > - the current draft does not conform to section 10 of RFC 2026, because > > MISTY1 is patented and the draft doesn't mention that. > > Agreed. We will add the IPR statement of MISTY1 to the next draft. That is not what RFC 2026 says. Please read RFC 2026 and then follow it. Otherwise, you will be wasting your time and our time. This extended discussion on how to handle IPR for what should be an Informational RFC is kind of a waste of the technical resources on this mailing list. --Paul Hoffman, Director --Internet Mail Consortium --- 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 Oct 17 01:31:09 2000 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 BAA25877 for ; Tue, 17 Oct 2000 01:31:08 -0400 (EDT) Date: Tue, 17 Oct 2000 01:32:12 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from djm@mindrot.org on Mon, Oct 16, 2000 at 08:31:12AM +1100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001017013212.K364@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Mon, Oct 16, 2000 at 08:31:12AM +1100, Damien Miller wrote: > On Sun, 15 Oct 2000, Ben Laurie wrote: > > > I find these remarks hard to understand - from where I'm sitting, > > performance doesn't limit the deployment of TLS - almost every site we > > host uses it where needed, without any performance problems at all. > > It would be nice to use TLS everywhere, not just ``where needed''. Not everywhere. TLS does impose extra burdens, from the cost of encryption to the inherently proxy-unfriendly nature of encrypted communication. TLS should be used where privacy or authenticity[0] are issues; otherwise, why bother? I'm a bit confounded by this, too. Employees of two big SSL/TLS software vendors have made vague statements about the cost of encryption. They have not provided more detail to help us understand, for instance, how much increased cost of encryption the market will tolerate. In fact, we have messages appearing to suggest that *any* encryption cost is too much. If that's where we stand, then I think it's even more important that the official specs *require* reasonable PFS suites. By all means, performance should be a consideration. But it seems we can't count on software vendors -- even those writing server apps designed for very capable Pentium-III and UltraSPARC boxes, likely with hardware accelerators -- to implement strong suites of their own accord if there's any feeling that the stronger suites might slow things down. Back to why/when to use TLS: I haven't run into very many folks using TLS simply for its authentication features, at least for HTTP. If this were the case, then I would --in other channels-- press an idea I've had for a while, about embedding crypto signatures inside HTML/XML documents to provide authentication over speedy unencrypted channels.[0] Most TLS implementations, especially what MSFT/SUN are dealing with, are used mostly, if not entirely, for data privacy.[1] And there's no getting around channel encryption for that. So let's do it right. -Peter [0] For simple document verification, something like PGP is ideal. No extra per-transaction overhead, caches well, etc. Web docs could add markup like this to enable seamless document signing:

HTML data that we signed (along with closest two comment lines).

Such that older browsers would render normally, and crypto-aware browsers could verify the signature of various components on a page. Similarly, an HTTP header could be used to tell a client where to find a detached signature for the rare cases where an entire HTML doc is signed. [1] Most. I said most. Yes, many folks are using client certificates. Yes, some folks are using TLS as a means of verifying server identity. But most are not. -- This fall, taxpaying American citizens will elect voting representatives to the US Congress. Except for those in Washington, DC. http://www.dcvote.org/ --- 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 Oct 17 05:18:25 2000 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 FAA06254 for ; Tue, 17 Oct 2000 05:18:22 -0400 (EDT) Date: Tue, 17 Oct 2000 10:17:38 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from peterw@usa.net on Tue, Oct 17, 2000 at 01:32:12AM -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001017101738.N14533@hyena.skygate.co.uk> X-List-Host: SKYLIST.net I just wanted to reassure everyone that I haven't forgotten about the draft and the ephemeral ciphersuite issue. I have been having some interesting offline discussions about efficiency; hopefully these will lead to a way forward. Peter W wrote: > In fact, we have > messages appearing to suggest that *any* encryption cost is too much. If that is the case just make the *decryption* key 3 instead of the encryption key! That should speed things up a bit, while still making the padlock light up... :-) > ... an idea I've had for a > while, about embedding crypto signatures inside HTML/XML documents to > provide authentication over speedy unencrypted channels. Have you seen XML-DSIG? I think the W3C draft for this is currently in last call. I don't agree with all the design decisions, but it looks as though it would achieve what you want (with XHTML at least). -- Pete --- 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 Oct 18 03:30:52 2000 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 DAA12806 for ; Wed, 18 Oct 2000 03:30:51 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-164.dialup.zetnet.co.uk [194.247.40.208] claimed to be zetnet.co.uk Message-ID: Date: Wed, 18 Oct 2000 05:45:45 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39ED2AF9.5AC4249F@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- David Hopwood wrote: > Pete Chown wrote: > [snip] > > Now, in each case, the signature is on the ephemeral key *only*. If > > the ephemeral key is only regenerated every four hours (as in my > > original wording) this signature only needs to be calculated once. > > No, the signature is also on the client and server random values, and > this is essential to prevent replay attacks. Actually, it's not essential. The reason why the client and server random values needed to be in the input to the server's signature for the export ciphersuites, was that only the signing key could be relied on to be secure. I.e. if an attacker broke a short ephemeral public key by factoring or computing discrete logs, and signatures were not tied to a specific session, then the attacker would have been able to replay a signature in order to impersonate the server (or do a MITM attack). This only applies to *breaking* an ephemeral key, though, not compromising it. If the server is compromised, an attacker will normally get the private signature key as well (but see the caveat below). In that case, the attacker will be able to do impersonation or MITM attacks anyway, and forward secrecy can't prevent this. When the ephemeral keys are as long as the signature key, we can rely on them not to be broken, so signing each ephemeral key once is perfectly sufficient, and it doesn't matter if signatures are replayed. The checks on the Finished hashes are enough to prevent other attacks. There is a caveat: consider servers that use protected hardware to hold the private signature key. For the existing ciphersuites, if an attacker breaks into such a server by exploiting a software bug, say, he/she will not be able to get at the private key. [This assumes that it isn't possible for the attacker to do a chosen ciphertext attack against the hardware device to recover the key - which would be possible if the device can perform raw RSA private key operations, for example, or if it does PKCS #1 v1.5 encryption without protection against Bleichenbacher's attack *in the hardware itself*.] If the client and server random values are not included in the server's signature, then depending on the interface to the hardware device, the attacker might be able to submit his own public key to it, and get back a signed key that will be sufficient to impersonate the server. New hardware or upgraded firmware could easily fix this by generating the ephemeral keys and signing them internally. However, there might still be an attack against existing hardware that is not possible with the current ciphersuites. If so, it could be fixed by changing the padding method used for signatures, in such a way that a new-style signature cannot be generated by an "old" device without firmware changes (for example the padding could be changed to PSS). If the hardware just does raw RSA, this will not work, but as discussed above, in that case an attacker who compromises the server will be able to get the private key anyway. (Some of the above is speculation, because I'm not entirely sure what the interfaces to nCipher's stuff and the other SSL/TLS hardware accelerators look like - perhaps someone from those companies could give more details?) If the random values are not included in the server signature, all of the ephemeral keys need to be at least as secure as the original server key. Secure random number generation might be an issue here, but in practice, I think the time between generating ephemeral key pairs (an hour?) is easily long enough to be able to collect enough entropy for a secure key. Version rollback also needs to be analysed taking into account this change, but that's complicated issue (not least because of the bugs in various implementations) that I'll leave for another post. Here are the performance figures for all ciphersuites, with the random values not signed. "URSA" means Unbalanced RSA (a.k.a. Shamir's "RSA for Paranoids"), which I'll also describe in a separate post. Algorithm FS? Server ops cost Client ops base extra _cost _cost URSA no URSAd 13.1 URSAe+(xc+1)*RSAe 1.0 0.3 URSAE_RSA yes URSAd 13.1 URSAe+(xc+2)*RSAe 1.3 0.3 URSAE_DSS yes URSAd 13.1 URSAe+(xc+2)*DSAv 58.7 29.0 DHE_RSA yes DHk 25.7 2*DHk+(xc+2)*RSAe 52.0 0.3 DHE_DSS yes DHk 25.7 2*DHk+(xc+2)*DSAv 109.4 29.0 RSA no RSAd 44.6 (xc+2)*RSAe 0.6 0.3 RSAE_RSA yes RSAd 44.6 (xc+3)*RSAe 0.9 0.3 RSAE_DSS yes RSAd 44.6 RSAe+(xc+2)*DSAv 58.3 29.0 I.e. the [U]RSAE_RSA ciphersuites with forward secrecy have the same server-side performance as [U]RSA without forward secrecy (neglecting the cost of generating and signing ephemeral keys, because that is only done once per hour or whatever), and they only require one extra RSA verification by the client. Obviously this greatly strengthens the case for only defining new ciphersuites with forward secrecy. It also means that there is a good argument for trying to make sure that when a new client and a new server communicate, they will *always* negotiate a ciphersuite with forward secrecy. - -- 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 iQEVAwUBOe0qdjkCAxeYt5gVAQG2yAf/W1xHzv+egpHBZkCdkKKCe6nxX9KJ6RKJ HOFEl65xE85EvV9YIM9R0r8fQYKjM+YpViGBLs4ZmF3ULHA25WjXnS952Yfv7A96 jF2Jqb5iMW4aTWDX2l1E2M4BkJ7b9z+IyNATJ9IUjGD+XWcnUClG/yr6684Qa3Jy gE4xDv/F1dtMmvcR/ctVxqwAaVs7zW9NumKhCAcNnopwKvlkbUz54zt8Gjvxov5j QHcXI1nYBNBvgEY5Db9qn08aWrv5TKQ9N7QtOTTduzePTit2bLnvvlog/arq9p3i A/zgAfwQBn9tHpAVC6nV0Y6PAu+kkOdwy3+fS/SHlNR39jFYbLUM0Q== =Yj1a -----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 Wed Oct 18 06:56:45 2000 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 GAA15102 for ; Wed, 18 Oct 2000 06:56:44 -0400 (EDT) Message-ID: Date: Wed, 18 Oct 2000 12:51:15 +0200 From: Holger Reif Reply-To: "IETF Transport Layer Security WG" Organization: SmartTrust GmbH X-Mailer: Mozilla 4.03 [de] (WinNT; I) MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39ED80A3.C002F661@sonera.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Peter W schrieb: > > [0] For simple document verification, something like PGP is ideal. No > extra per-transaction overhead, caches well, etc. Web docs could add > markup like this to enable seamless document signing: > > >

HTML data that we signed (along with closest two comment lines).

> This has been suggested already and is (still?) known as S-HTTP. You can probably find references at www.terisa.com. Please note however that S-HTTP never took of, due to lack of browser support. Furthermore, this is *transport layer security* WG and not about application layer. > Such that older browsers would render normally, and crypto-aware browsers > could verify the signature of various components on a page. Similarly, an > HTTP header could be used to tell a client where to find a detached > signature for the rare cases where an entire HTML doc is signed. At least this would provide perfect backward compatibility. BTW I remember a similiar, working solution for PGP signed HTML pages, sorry that I can't provide you with the reference. Rgeards -- Holger Reif Tel.: +49 361 74707-0 SmartRing GmbH Fax.: +49 361 7470720 Europaplatz 5 Holger.Reif@Sonera.com D-99091 Erfurt WWW.Smarttrust.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 Wed Oct 18 10:32:40 2000 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 KAA20757 for ; Wed, 18 Oct 2000 10:32:39 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 18 Oct 2000 07:36:07 -0700 In-Reply-To: Holger Reif's message of "Wed, 18 Oct 2000 12:51:15 +0200" Message-ID: Lines: 29 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 Holger Reif writes: > Peter W schrieb: > > > > [0] For simple document verification, something like PGP is ideal. No > > extra per-transaction overhead, caches well, etc. Web docs could add > > markup like this to enable seamless document signing: > > > > > >

HTML data that we signed (along with closest two comment lines).

> > > > This has been suggested already and is (still?) known as S-HTTP. You > can probably find references at www.terisa.com. Actually, S-HTTP is much more along the lines of an S/MIME wrapper. (see RFC 2660/2661). It is not transparently compatible and was never intended to be. > Please note however that S-HTTP never took of, due to lack of browser > support Quite so. -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 Oct 18 13:26:00 2000 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 NAA03828 for ; Wed, 18 Oct 2000 13:25:59 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 18 Oct 2000 07:51:35 -0700 In-Reply-To: David Hopwood's message of "Wed, 18 Oct 2000 05:45:45 +0100" Message-ID: Lines: 37 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 David Hopwood writes: > -----BEGIN PGP SIGNED MESSAGE----- > > David Hopwood wrote: > > Pete Chown wrote: > > [snip] > > > Now, in each case, the signature is on the ephemeral key *only*. If > > > the ephemeral key is only regenerated every four hours (as in my > > > original wording) this signature only needs to be calculated once. > > > > No, the signature is also on the client and server random values, and > > this is essential to prevent replay attacks. > > Actually, it's not essential. It is if you wish to prevent replay of signed ephemeral keys. Your argument below is simply that that's not important. I believe this is wrong. 1. Consider the case where the keys aren't the same length. (The generalized version of the export case). This becomes very desirable if the length of the signing key isn't a performance problem. In this situation, the ephemeral key might be within the realm of breakability while the signing key is not. 2. Consider the case where the cipher suites aren't the same and the attacker has a computationally expensive attack on the ephemeral key. In either of these two cases, it's quite believable that the ephemeral keys are weaker than the signing key and that the server would wish to enforce a changeover. On a more philosophical level, what you propose has the critical flaw that it fails to enforce the server's control over the ephemeral key. This is a form of defense in depth that I'd rather like to retain. -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 Oct 18 14:03:14 2000 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 OAA08490 for ; Wed, 18 Oct 2000 14:03:13 -0400 (EDT) Message-ID: Date: Wed, 18 Oct 2000 19:02:55 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39EDE5CF.5E4A9C41@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Hopwood wrote: > > > There is a caveat: consider servers that use protected hardware to > hold the private signature key. For the existing ciphersuites, if an > attacker breaks into such a server by exploiting a software bug, say, > he/she will not be able to get at the private key. > > [This assumes that it isn't possible for the attacker to do a chosen > ciphertext attack against the hardware device to recover the key - > which would be possible if the device can perform raw RSA private key > operations, for example, or if it does PKCS #1 v1.5 encryption without > protection against Bleichenbacher's attack *in the hardware itself*.] > My understanding of the Bleichenbacher's attack is that one cannot recover the private key but rather can persuade a vulnerable server to ultimately (after a few million operations) reveal a premaster secret. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Oct 18 22:43:17 2000 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 WAA11596 for ; Wed, 18 Oct 2000 22:43:15 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-040.dialup.zetnet.co.uk [194.247.41.49] claimed to be zetnet.co.uk Message-ID: Date: Thu, 19 Oct 2000 00:38:42 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39EE3482.BD286CE4@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Dr S N Henson wrote: > David Hopwood wrote: > > There is a caveat: consider servers that use protected hardware to > > hold the private signature key. For the existing ciphersuites, if an > > attacker breaks into such a server by exploiting a software bug, say, > > he/she will not be able to get at the private key. > > > > [This assumes that it isn't possible for the attacker to do a chosen > > ciphertext attack against the hardware device to recover the key - > > which would be possible if the device can perform raw RSA private key > > operations, for example, or if it does PKCS #1 v1.5 encryption without > > protection against Bleichenbacher's attack *in the hardware itself*.] > > My understanding of the Bleichenbacher's attack is that one cannot > recover the private key but rather can persuade a vulnerable server to > ultimately (after a few million operations) reveal a premaster secret. I stand corrected. However, note that if the attacker has enough time to be able to decrypt all primes less than B, before his access to the server is terminated, he will still be able to decrypt ciphertexts that are B-smooth (i.e. can be expressed as a product of those primes). Anyway, we need to know what how hardware interfaces are typically defined, before concluding what the effect would be on their security. - -- 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 iQEVAwUBOe40ZTkCAxeYt5gVAQFeQgf9HH+/RZojw30IF4wnwLdEXfvnT/lU9514 gPR4isdUf/lrSbIH2MsaQshdiSVlgrqUQcnPKs8Rw6BKzYxlWS8QOnyhKdNx7R0/ a+AYe7d64483lNUcPNadtN+be8SX2j7MHLbuEvAr49ij1rekAFOXFXbk7bNlO6au plz3eZ0YQHQBc6XtNXypAKorBVsJKzHiKng7GbAD6p/LGrF5BEdgS6KOvji9muPz TgEUIqzUYYqw/wlUiICsd8qChZKUfj7U/A6+Y0v8xalGN0r+mkS1PgXi+kw7JafV AfnKaUK1hn2zbgqLGBz/lFMpNyRfkd0OfP8VoybC4EG0NDJjh6xlXw== =Irjc -----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 Wed Oct 18 22:44:38 2000 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 WAA11771 for ; Wed, 18 Oct 2000 22:44:34 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-040.dialup.zetnet.co.uk [194.247.41.49] claimed to be zetnet.co.uk Message-ID: Date: Thu, 19 Oct 2000 00:27:08 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39EE31CC.C7C115AB@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- [Note: below RSAE_RSA refers to the version of ephemeral RSA where the random values are included in the signature, and RSAE_RSA* refers to the version where they are not.] Eric Rescorla wrote: > David Hopwood writes: > > David Hopwood wrote: > > > Pete Chown wrote: > > > [snip] > > > > Now, in each case, the signature is on the ephemeral key *only*. If > > > > the ephemeral key is only regenerated every four hours (as in my > > > > original wording) this signature only needs to be calculated once. > > > > > > No, the signature is also on the client and server random values, and > > > this is essential to prevent replay attacks. > > > > Actually, it's not essential. > > It is if you wish to prevent replay of signed ephemeral keys. > Your argument below is simply that that's not important. I believe this > is wrong. > > 1. Consider the case where the keys aren't the same length. In that case the security would be limited to that of the shorter key. So don't do that. > (The generalized version of the export case). This becomes very > desirable if the length of the signing key isn't a performance problem. > In this situation, the ephemeral key might be within the realm of > breakability while the signing key is not. There are two key exchange methods that it's meaningful to compare the RSAE_RSA* method with: - If you compare it to RSAE_RSA with an ephemeral encryption key length of k1, and a signature key length of k2 > k1, then the server load for that will be RSAd_k1 + RSAs_k2 per connection. Choose the corresponding RSAE_RSA* key size to be k2 for both the ephemeral and signing keys; then the server load will be RSAd_k2 (equal to RSAs_k2) per connection, i.e. more efficient *and* more secure. - If you compare it to static RSA with an encryption key length of k, then the server load will be RSAd_k per connection. Choose the RSAE_RSA* key size to be k for both the ephemeral and signing keys; then it will be equally efficient on the server side, will require one extra RSA verification on the client side, and will be more secure because it provides forward secrecy. It does not make sense to compare RSAE_RSA* with a hypothetical key exchange method where signatures cannot be replayed, but that does not incur the cost of a signature per connection, because no such method has been proposed. [Actually Pete Chown and I also discussed an alternative based on one-time signatures as well as RSA, but I think we rejected that, on complexity grounds and because it might be subject to a patent that doesn't expire until 2008.] Just to make this clearer: in the proposed RSAE_RSA* scheme the signature key and the ephemeral keys are all the same length, and that length is chosen according to the same criteria that would be used to choose a signature key length in RSAE_RSA. > 2. Consider the case where the cipher suites aren't the same and the > attacker has a computationally expensive attack on the ephemeral key. I assume you're referring to the case where the encryption and signature algorithms are different. The RSAE_DSS suites aren't very interesting; I only included them in the performance analysis for completeness. If we use RSAE_RSA*, the signatures and the encryption will have effectively the same security, because they use the same trapdoor function with the same key length. (Technically that depends on using encryption and signature padding methods that both have security proven to be tightly reducible to the RSA Problem, under comparable assumptions. OAEP and PSS would be suitable methods.) URSAE_RSA is a bit more complicated, but I'll discuss that separately. > In either of these two cases, it's quite believable that the ephemeral > keys are weaker than the signing key and that the server would wish > to enforce a changeover. I think I've addressed both of these objections, but here's another one: 3. A server administrator's opinion of the security provided by a given key length could change, in which case he/she might want to increase the length of ephemeral keys, without getting a new signature key certificate. This is also invalid for the same reason as 1. If the ephemeral key length is chosen to the same as the signature key length, then increasing it will not help. All ciphersuites have a key length that has to be chosen large enough to resist attacks within the validity period of the certificate. > On a more philosophical level, what you propose has the critical flaw > that it fails to enforce the server's control over the ephemeral key. Once a server has deleted an ephemeral private key, it cannot be recovered by compromise of the server. Breaking it without compromising the server is as hard as breaking the signature key would be. There is no flaw here. > This is a form of defense in depth that I'd rather like to retain. I'm all for defense in depth, but I don't think you've presented a valid argument that RSAE_RSA* is any weaker in that regard. - -- 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 iQEVAwUBOe4xuDkCAxeYt5gVAQEziAf+Mhg40uJgYzXSUqgpi01L+ejlw7eOq7Dp 7PZqSEGgFUeKeXKiHDnhj0/ivkqd+7K+o9G1JEi+BHXWEq6EXXuoqQ8nM9z7U8ub 4bDg/EtwCNrjf3D7PJQDMPexp1evbMwfMYdA3um8eO4YAFbKQzvy+XumIuEQQn23 FEZ2vLNYR7oZD3LHQhhafs57ux1h8cmF3ykKZxPlHG5UERiHCS20g4dcf3r/WTBR XtOQEbTkcHSRzjmsgYRC2kqZqJuXoI0i9Oha0HpXNIb5igNtP4N4PeNdPZjGmiMw 5CpObQeCgf70Z3ywkOCMQMdF/QoFqlLwc2xMjU3m2yGLsIxT9cKaIw== =Ri9A -----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 Wed Oct 18 23:14:12 2000 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 XAA15054 for ; Wed, 18 Oct 2000 23:14:11 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 18 Oct 2000 20:17:25 -0700 In-Reply-To: David Hopwood's message of "Thu, 19 Oct 2000 00:27:08 +0100" Message-ID: Lines: 28 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 David Hopwood writes: > > On a more philosophical level, what you propose has the critical flaw > > that it fails to enforce the server's control over the ephemeral key. > > Once a server has deleted an ephemeral private key, it cannot be > recovered by compromise of the server. Breaking it without compromising > the server is as hard as breaking the signature key would be. There is > no flaw here. I should have spoken more clearly. The server's control over the client's use of the ephemeral key. If the ephemeral key is compromised, the server can't stop people using it in RSAE_RSA*. The system is permanently open to active attack, even if the static key is secure. This is not the case in RSAE_RSA. If you can't imagine situations in which the ephemeral key can be compromised while the static key is not, then I maintain that you're not very imaginative. Consider, for instance, the case where you're dealing with hardware whose signature interface REQUIRES the data to be passed in on an I/O channel (this applies to pretty much every piece of cryptographic hardware that I know of). If you had such a piece of hardware that also kept the static key securely on the card, then compromising the server would permit compromise of the ephemeral key, but not of the static authentication key. -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 Thu Oct 19 01:38:06 2000 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 BAA12092 for ; Thu, 19 Oct 2000 01:37:21 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-045.dialup.zetnet.co.uk [194.247.41.56] claimed to be zetnet.co.uk Message-ID: Date: Thu, 19 Oct 2000 04:05:34 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39EE64FE.49838FC0@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Eric Rescorla wrote: > David Hopwood writes: > > > On a more philosophical level, what you propose has the critical flaw > > > that it fails to enforce the server's control over the ephemeral key. > > > > Once a server has deleted an ephemeral private key, it cannot be > > recovered by compromise of the server. Breaking it without compromising > > the server is as hard as breaking the signature key would be. There is > > no flaw here. > > I should have spoken more clearly. The server's control over the > client's use of the ephemeral key. If the ephemeral key is compromised, > the server can't stop people using it in RSAE_RSA*. The system is > permanently open to active attack, even if the static key is secure. The system depends on the ephemeral keys being as secure as the static key. I already made that quite clear, and while not trivial, I believe it can be readily achieved in practice. > This is not the case in > RSAE_RSA. If you can't imagine situations in which the ephemeral key > can be compromised while the static key is not, then I maintain that > you're not very imaginative. > > Consider, for instance, the case where you're dealing with hardware > whose signature interface REQUIRES the data to be passed in on an > I/O channel (this applies to pretty much every piece of cryptographic > hardware that I know of). It's pretty annoying to be called "not imaginative" enough to think of a case that I already covered in detail in the same article in which I suggested the scheme. If the hardware signs any input with RSA PKCS #1 v1.5 type 0 using MD5 and SHA-1 (whether the hashes are done inside or outside the hardware), then as I stated in that article, a possible solution is to change the encoding scheme, for example to PSS (since a PSS-encoded signature will not be a valid PKCS #1 v1.5 type 0 signature with the same key, or vice versa). I also pointed out that this will not work if the hardware acts as a raw RSA decryption/signing oracle, and asked for information, preferably from people who know directly, on whether that is actually the case for real-world implementations of SSL/TLS accelerators. (Note that if the hardware does act as a raw RSA oracle, it may be possible for an attacker who breaks into a server to gain sufficient information to decrypt a non-negligable proportion of ciphertexts even after their access to the hardware is cut off.) Of course, firmware would need to be modified in order to support the new ciphersuites, but I don't see any way to avoid that when introducing a new key exchange algorithm. - -- 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 iQEVAwUBOe5kwzkCAxeYt5gVAQE13Af/eqogpPdBOiuJyvCG2dle6N7GQHaPJ3++ Ko9GiacaKo4EOiDKVxehL6Z4oBn3AQOjz1CvN7Sw5M7ZfAKA5sidlRr6CUyTVMdi Z19K4E48jPbh0RZ+lenAN5/QEp9duviIXVF4Br68WmiDiincW/hqW5Wstsj/J/wm 1A4422GLxCYFphSBzxz1NeW/6ELJvkab2nmYTZ5W8vuHkB8deFkRSssqnNsHc0oj Rt99REnva5rRVtS9HqE724rinJESOUGKX8GAbBn1wHkI9F9+QIKkCoTx85/9phU4 3JXCB18ucjGbqtzttDwHCyFAplyf6lzEyVWpVcchU+rBOyZ9u2Ol6A== =Gd23 -----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 Thu Oct 19 02:12:28 2000 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 CAA25878 for ; Thu, 19 Oct 2000 02:12:19 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 18 Oct 2000 23:15:40 -0700 In-Reply-To: David Hopwood's message of "Thu, 19 Oct 2000 04:05:34 +0100" Message-ID: Lines: 58 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 David Hopwood writes: > Eric Rescorla wrote: > > I should have spoken more clearly. The server's control over the > > client's use of the ephemeral key. If the ephemeral key is compromised, > > the server can't stop people using it in RSAE_RSA*. The system is > > permanently open to active attack, even if the static key is secure. > > The system depends on the ephemeral keys being as secure as the > static key. I already made that quite clear, and while not trivial, > I believe it can be readily achieved in practice. However, this isn't required AT ALL with previous ephemeral schemes. Those schemes AREN'T brittle against compromise of a single ephemeral key. I consider this a significant drawback in your scheme. > It's pretty annoying to be called "not imaginative" enough to think > of a case that I already covered in detail in the same article in > which I suggested the scheme. Sorry about that. I rush-added the example right before sending the message and heading out to dinner and didn't bother to reedit the previous text. Moreover, I admit it's not much of an example. My apologies. That said, your entire point appears to be to demonstrate that PFS doesn't create additional CPU cost and thus we should require it in all cases. However, you're only able to achieve this goal by sacrificing security. You may not consider that sacrifice to be substantial, but it's not zero, and I think that reasonable people can differ on how substantial it is. To recap: 1. You give up PFS because you can't afford to create a new key every time as you would with DH. 2. You create the additional restriction that the ephemeral key must be controlled every bit as tightly as the static key because if it's ever compromised, the whole game is up. The static key must be revoked as well. Basically, you've created something which is better than static RSA but worse than true PFS. Personally, I'd far rather see two cipher suites, one with PFS (presumably DHE_RSA with a modification to permit the client to use a short exponent) and one without (static RSA). Then, those who DO care about PFS can have it, at a performance cost but more securely than RSAE_RSA. Those who don't could choose not to. I understand that you'd like to require PFS, but I don't think that's reasonable to do in a protocol standard, particulary since you've managed to do it by sacrificing PFS. -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 Thu Oct 19 03:32:20 2000 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 DAA06783 for ; Thu, 19 Oct 2000 03:32:19 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: 19 Oct 2000 00:35:38 -0700 In-Reply-To: Eric Rescorla's message of "18 Oct 2000 23:15:40 -0700" Message-ID: Lines: 17 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: > David Hopwood writes: > To recap: > 1. You give up PFS because you can't afford to create a new key every > time as you would with DH. > 2. You create the additional restriction that the ephemeral key must > be controlled every bit as tightly as the static key because if it's > ever compromised, the whole game is up. The static key must be revoked > as well. Note that this second objection doesn't apply as strongly if you have some sort of expiry time in the signed RSA key, as suggested by Steve Henson. In that case, the window of compromise only lasts as long as the key is valid. On the other hand, you introduce a requirement for at aleat somewhat synchronized clocks into he protocol. -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 Thu Oct 19 19:33:33 2000 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 TAA26654 for ; Thu, 19 Oct 2000 19:33:32 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-210.dialup.zetnet.co.uk [194.247.43.12] claimed to be zetnet.co.uk Message-ID: Date: Thu, 19 Oct 2000 22:02:05 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39EF614D.D2DE8105@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- I wrote: > If the hardware signs any input with RSA PKCS #1 v1.5 type 0 using > MD5 and SHA-1 (whether the hashes are done inside or outside the > hardware), then as I stated in that article, a possible solution is > to change the encoding scheme, for example to PSS (since a PSS-encoded > signature will not be a valid PKCS #1 v1.5 type 0 signature with the > same key, or vice versa). Correction: there is an attack on this if the hashes are done outside the hardware (at least for 1024-bit keys) - see [*] below. > I also pointed out that this will not work if the hardware acts as > a raw RSA decryption/signing oracle, and asked for information, > preferably from people who know directly, on whether that is actually > the case for real-world implementations of SSL/TLS accelerators. > (Note that if the hardware does act as a raw RSA oracle, it may be > possible for an attacker who breaks into a server to gain sufficient > information to decrypt a non-negligable proportion of ciphertexts > even after their access to the hardware is cut off.) I should have said here, "to sign a non-negligable proportion of inputs". Also, this is true even if the oracle only accepts inputs of length up to 288 bits (i.e. the length of concatenated MD5 and SHA-1 hashes). Let Psi(x, B) be the number of integers <= x that are B-smooth (i.e. do not have a prime factor > B). Then according to [Ste85], Psi(x, B)/x ~= u^-u, where u = log(x)/log(B). Let H(m) = MD5(m) || SHA-1(m). An output of H can be modelled as a random integer < 2^288. So if B = 2^25, for example, then the probability of a hash being B-smooth is roughly 2^-40.6. The attacker breaks into the server, and finds { C^d mod n : C < B and C is prime }. Access to the server is then lost. The attacker now waits for a client to send the client_random, then hashes an expected 2^40.6 values H(client_random || server_random || rsa_public) (where the private key to rsa_public is known), to find one where the hash is B-smooth. If the hash is product[i = 1..k](C_i^t_i), then its PKCS #1 type 0 signature is product[i = 1..k]((C_i^d)^t_i), and the attacker can use this to impersonate the server using either the RSAE or RSA_EXPORT ciphersuites. Note that the value of B can be traded against the number of hash computations needed. [*] The reason why switching to PSS for RSAE_RSA* only works if hashing is done internally, is that otherwise we can use the same technique as above with B = 2^288 to find a B-smooth PSS input of length just under 1024 bits, and forge a PSS signature given access to the PKCS #1 type 0 signing oracle. IOW, roughly speaking, hardware that does hashing internally will resist a compromised-server impersonation attack, and hardware where hashing is done externally will not adequately resist it. This applies whether or not the RSAE_RSA* ciphersuite is added. [Ste85] N. M. Stephens, "Lenstra's Factorisation Method Based on Elliptic Curves," Advances in Cryptology - Proceedings of CRYPTO '85. - -- 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 iQEVAwUBOe9dKTkCAxeYt5gVAQFE4wgAu68McH69Mgo/OmLszEJ7KRxlVbm7N5tL U89SMRcU8t+ptBW42DdLHmvnRl5SBLBpLuoODLIwZfNrb26+PFwvkL66Wb2uUBmw Q5GueaJp9an8131SuTvMVS30O8fb51WifHzQIW1dAq77XRA1GVjKiHwVcv+qA5mU pjDSAPwsQgh0tZGynfpndudny8VNAHJZ2c0xY9CQ7kVWUGYodxtKkw7FlFAmii0U xXrvHLXBABN0dtOcbVft2JKEjTeQmjQanim5MLxHEnqwUxUe1l+xzXhgdhjErR2u we8JOz+wdbJaRif1HLg4qPGd/FEObhvrrYjjzQxjt6r9iVOOX2/UTg== =yV4e -----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 Wed Oct 25 04:20:23 2000 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 EAA17243 for ; Wed, 25 Oct 2000 04:20:20 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a134.dialup.zetnet.co.uk [194.247.44.134] claimed to be zetnet.co.uk Message-ID: Date: Wed, 25 Oct 2000 09:19:52 +0100 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: Forward secrecy and performance (was AES ciphersuites) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39F697A8.80599BE7@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Eric Rescorla wrote: > David Hopwood writes: > > Eric Rescorla wrote: > > > I should have spoken more clearly. The server's control over the > > > client's use of the ephemeral key. If the ephemeral key is compromised, > > > the server can't stop people using it in RSAE_RSA*. The system is > > > permanently open to active attack, even if the static key is secure. > > > > The system depends on the ephemeral keys being as secure as the > > static key. I already made that quite clear, and while not trivial, > > I believe it can be readily achieved in practice. > > However, this isn't required AT ALL with previous ephemeral schemes. No, it isn't, but so what? The main point of dispute seems to be whether it is realistic to expect that the ephemeral keys can be kept as secure as the static key. Consider two types of implementation: "Monolithic server" - the server is implemented as a single component (usually software), and compromising it can be expected to reveal all of its secret data. "Split server" - the server is split into inner and outer layers; the inner layer (usually hardware) is designed to be more resistant to compromise. The outer layer (usually software) never gets direct access to the private key. In the monolithic server case, I think it's definitely realistic to expect that the ephemeral keys can be kept as secure as the static key. In the split server case, it is more complicated, but it's also complicated for the existing ciphersuites, because chosen-signature attacks against PKCS #1 type 0, attacks against the RNG, etc. need to be considered. > Those schemes AREN'T brittle against compromise of a single ephemeral > key. I consider this a significant drawback in your scheme. I think this is an exaggeration of the differences between the schemes. Do you consider the existing ciphersuites "brittle" because they are vulnerable to compromise of a single key (the long-term signing or encryption key)? Let's look at the reasons why a key might be compromised in more detail: 1. Key generation a. random number generation The RNG needs to have sufficient entropy when the server starts to guarantee that all the ephemeral keys generated while that process instance is running are unpredictable. For a monolithic server: The RNG must initially have enough entropy to generate the long-term key pair, before the server is started for the first time (if it does not then the other ciphersuites will also be vulnerable). Assume that a one-way hash of the random state is periodically saved, and if the server crashes (or is shut down), this saved state is used to provide part of the entropy on restarting. The potential problem is that the entropy input might cease to be sufficiently random, *after* the long-term key has been generated. However, as long as the RNG behaves like a cryptographically secure pseudo-random number generator in that case [*], and as long as the state remains secret, an attacker will still not be able to predict any of its output. In order to get at the RNG state (either in memory, or the saved state), an attacker would have to compromise the server. If he does that, then for a monolithic server, he would also be able to get the long-term signing key. [*] The RNG needs to be secure according to the criteria in [KSWH98] or [Gut00]. For example, /dev/random or Yarrow would suffice. For a split server: The RNG state should be held securely by the inner layer of the server, and this RNG has to be designed so that it cannot be predicted even if the outer layer is controlled by an attacker. This is quite difficult, but it's equally as difficult and as necessary for the existing ciphersuites (predicting a value of k used in DSA signing allows finding the private key, for instance). b. weak keys If a small but non-negligable proportion of RSA key pairs generated by a particular method were weak, then the probability of this happening for at least one key that allows server impersonation, would be greater for RSAE_RSA*. However, for randomly generated 512-bit or larger primes, and either random large e or constant e, there does not appear to be any class of weak RSA moduli that occur with non-negligable probability (see [RS98], and note that the "Time-to-First-Solution Principle" given in that paper is exactly the right model for analysing security when there are a large number of target keys). 2. Key use a. side channel attacks Since the RSAE and DHE ciphersuites have an on-line signature operation, a timing or other side channel attack against RSAE_RSA* would presumably also be applicable to the long-term key in those ciphersuites (RSA decryption and signing are effectively the same operation as far as side-channel attacks are concerned). Countermeasures against timing attacks are well-known (e.g. blinding, or making decryption take the same time for all inputs). b. chosen-ciphertext attacks Using OAEP would completely prevent these; the combination of replacing invalid PKCS #1 blocks with a random value, and the fact that the premaster_secret is only used after being hashed, also appears to prevent them. c. attacks against the RSA Problem These would apply equally to the other RSA ciphersuites. Note that the problem parameters (distribution of p, q, and e) are the same for the ephemeral keys as they would be for signing keys in RSAE_RSA. d. hardware or software faults (see [BDL97]) These would apply equally to other ciphersuites. (The attack against CRT-based RSA operations in [BDL97] can be applied to RSAE_RSA* and RSAE_RSA, and is easy to protect against in both cases.) 3. Key storage and deletion Ephemeral keys never need to be stored on stable media (it is always acceptable to lose the current key if the server crashes). For a monolithic server, the current ephemeral key, the next ephemeral key that is being generated, the signing key, and any intermediate results for signing or encryption should all be stored in locked physical memory, so that they cannot be swapped to disk. In that case, deleting them is not difficult. For a split server, the inner layer must generate and sign ephemeral keys internally, and only give access to an encryption oracle for the current ephemeral key. (It's desirable for the encryption to be done in hardware anyway for performance reasons.) I.e. at any given time it has to store up to three keys securely (including the one being generated) instead of one, which I don't see as being a big problem. Existing SSL/TLS accelerators would require at least firmware changes in order to support the new ciphersuites, though. Since certificates do not specify which ciphersuites they can be used with, we also need to make sure that current implementations of the inner layer of a split server do not allow forging a signature on an ephemeral key for RSAE_RSA*, if they would not have done for the existing ciphersuites. That will be true provided: - the encoding method for RSAE_RSA* signatures is PSS, - the inner layer only gives access to a signing oracle for PKCS #1 type 0 with MD5 and SHA-1 hashing done internally. If hashing is not done internally, there is a practical attack when the outer layer is compromised, that allows impersonating the server. However, not doing hashing internally is an extremely bad idea, and allows a similar attack much easier than factoring on the existing ciphersuites. 4. Deliberate key compromise a. insider attacks Insiders are no different from any other attacker who compromises the server, except that they may also have physical access. This doesn't appear to introduce any new problems that don't also apply to the existing ciphersuites. b. legal attack Some countries (e.g. the UK) have laws that can compel someone to disclose a key needed to decrypt information, if it is still available. If a server administrator is asked to do this for an ephemeral key, then: - if the key has been deleted, then it obviously isn't possible to disclose it. In that case all the administrator could do is provide the plaintext, if it has been retained or can be reconstructed. - if the key has not been deleted, the server administrator could say that it is an authentication key that allows impersonating the server, and therefore that he/she wants to give the session key instead. One way of doing that is for whoever was intercepting the session to give the administrator a copy of the handshake messages, and the ephemeral key can then be used to decrypt the ClientKeyExchange message. The UK "RIP Act" and the accompanying code of practice is supposed to be drafted to allow things like this, although realistically, it would probably only be practical to intercept sessions with prior arrangement with the server administrator, since ephemeral keys will be deleted too quickly otherwise. Have I missed anything? [snip] > That said, your entire point appears to be to demonstrate that PFS > doesn't create additional CPU cost and thus we should require it in > all cases. However, you're only able to achieve this goal by > sacrificing security. If I thought it was sacrificing security, I wouldn't be suggesting it. > You may not consider that sacrifice to be > substantial, but it's not zero, and I think that reasonable people > can differ on how substantial it is. > > To recap: > 1. You give up PFS because you can't afford to create a new key every > time as you would with DH. You appear to be thinking of a model where as each session terminates, it immediately becomes impossible to recover its keys. That isn't achieved by the DHE ciphersuites, because the session cache holds master secrets for up to a day (if the "suggestion" in section F.1.4 of RFC 2246 is followed): # An upper limit of 24 hours is suggested for # session ID lifetimes, since an attacker who obtains a master_secret # may be able to impersonate the compromised party until the # corresponding session ID is retired. The server can choose a shorter limit, of course, or it can return a zero-length session ID, meaning that the session cannot be resumed. I doubt many servers do the latter in practice (for HTTP, in particular, it would kill performance [*]). There is currently no way for the client to make any request for, or to require a shorter maximum lifetime for master secrets. [*] less so if HTTP 1.1 is used, but then the client would have to keep connections open for longer than would normally be desirable. Also, if an attacker notices a particularly interesting session, it can break into the server while the session is still in progress, and get the master secret that way. Note that renegotiating session keys without doing a full handshake does not ensure forward secrecy for the part of the session before the renegotiation, which is significant for applications that use long-lived sessions. These problems could be fixed by applying a one-way hash to the master secret as it is stored in the cache, and every time it is subsequently used. However, I think that could only be done in the next TLS version (since the client and server have to agree on whether the master secret will be hashed). For SSL 3.0/TLS 1.0, the extent to which the DHE ciphersuites provide forward secrecy depends on the expiry time of the session cache. Technically, a server could even cache master secrets indefinitely and still conform to the spec. > 2. You create the additional restriction that the ephemeral key must > be controlled every bit as tightly as the static key because if it's > ever compromised, the whole game is up. The static key must be > revoked as well. Yes, at any given time two keys (and possibly another that is being generated) have to be controlled tightly instead of one. >From another article: >> Note that this second objection doesn't apply as strongly if you have some >> sort of expiry time in the signed RSA key, as suggested by Steve Henson. >> In that case, the window of compromise only lasts as long as the key >> is valid. On the other hand, you introduce a requirement for at least >> somewhat synchronized clocks into the protocol. I'd have no objection to putting an expiry time in the signature, as a second line of defense (for example to make sure that if a flaw were found in the protocol, the validity time of signatures on all ephemeral keys signed up to that point would be limited, as long as a client's clock cannot be forced to an earlier time). This is quite different from relying completely on synchronised clocks for security, as, say, Kerberos does. Note that we already rely on clients having a clock, and it not being totally wrong (e.g. if a clock gets reset to 1970 or 1980, which might be quite a common failure mode in battery-operated devices, for instance, then certificates will not verify). > Basically, you've created something which is better than static RSA but > worse than true PFS. Exactly the same could be said of the DHE ciphersuites, since they don't provide what I think you mean by "true PFS" either (see above). > Personally, I'd far rather see two cipher suites, one with PFS (presumably > DHE_RSA with a modification to permit the client to use a short exponent) > and one without (static RSA). > Then, those who DO care about PFS can have > it, at a performance cost but more securely than RSAE_RSA. Those who > don't could choose not to. The only possible advantage in using ciphersuites that don't provide forward secrecy, would be performance. If forward secrecy can be achieved without significant performance penalty (I don't consider the extra RSA verification by the client to be significant), then there is no reason why it shouldn't be required. > I understand that you'd like to require PFS, but I don't think that's > reasonable to do in a protocol standard, Why not? > particulary since you've managed to do it by sacrificing PFS. The strictest possible version of forward secrecy could only be achieved by not storing master secrets at all after the handshake, and applying a one-way hash to all the secret information associated with a connection *each time a block is sent*. (Even this assumes that the data doesn't exist in plaintext on the server, but that's beyond the scope of a transport-layer security protocol.) In practice, forward secrecy is always time limited, i.e. the most it can guarantee that if an attacker compromises the server at time T, it will not be able to recover data sent before time T - X. It's just a matter of how long X is. The TLS 1.0 spec is very lax about requiring sensitive secrets to be deleted quickly; it's not possible to pin down a guaranteed value for X at all. I would be strongly in favour of making the changes necessary to guarantee a reasonable upper bound on X (some of which can only be done in the next TLS version). The practical reason for wanting X to be as small as possible is to limit the damage done by a compromise. While an attacker is actually controlling the server, he/she can get the keys for all connections that are active during that time. So if a compromise lasts, say, 20 minutes, then reducing X from 10 minutes to 10 seconds is not going to improve security by a substantial amount - the attacker still gets 20 minutes + 10 seconds' worth of data, as opposed to 30 minutes. Also, we want forward secrecy to be practical for small clients. You've done a good job of convincing me of the need to use RSA, both for performance on small clients, and because that's what HTTPS servers currently have certificates for. So, RSAE_RSA*, or something very much like it, is what we need for a common-case ciphersuite. [BDL97] Dan Boneh, Richard A. DeMillo, Richard J. Lipton, "On the Importance of Checking Cryptographic Protocols for Faults," Advances in Cryptology - Proceedings of EUROCRYPT '97. [RS98] R. Rivest, R. Silverman, "Are 'Strong' Primes Needed for RSA?" December 1, 1998 (also RSA Laboratories tech note, August 1, 2000). http://www.rsalabs.com/technotes/ (the PDF version has some minor font problems) [KSWH98] J. Kelsey, B. Schneier, D. Wagner, C. Hall, "Cryptanalytic Attacks on Pseudorandom Number Generators," Fast Software Encryption, Fifth International Workshop Proceedings (March 1998), Springer-Verlag, 1998, pp. 168-188. http://www.counterpane.com/pseudorandom_number.html [Gut00] Peter Gutmann, "Software Generation of Practically Strong Random Numbers" (updated June 2000), Original version presented at the 1998 Usenix Security Symposium. http://www.cryptoengines.com/~peter/06_random.pdf - -- 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 iQEVAwUBOfaXdTkCAxeYt5gVAQFtvQf/Q1CAQr5PQ73Co+6zxay944aTy/0+Kub1 YQUhFLW53ikPj2l6xpe5ER5lXm+kIl03AGzi7L3/H8uRbhaZ/Q7rqaK2MULVYgrU Df/KIPGkO/01IkUVwuEoJ40jfkPYYYrx7dosFN7NwVJLFkuHrGz/qWGXWcqQNtQ6 V9FBOBWRCeOAHD9NjEL8mxWBQdemCouK0TeNVxB4VBCjWC6CgeaJViQL3aiatc2R qz7ficwVMqpkzx2cKtTTYDAhrMH5UB9mY4WUoRvIZ7vDrsqK0isNA/ADl7m2i0NG 5j28j2BVQqUHpNa26u68M2cex8mqFX/cZajRlN34W7Fj8HlM4+6qkA== =mBZQ -----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 Wed Oct 25 06:16:17 2000 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 GAA23312 for ; Wed, 25 Oct 2000 06:16:16 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" CC: ipsec@lists.tislabs.com, ietf-tls@lists.certicom.com, saag@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-krovetz-umac-01.txt Date: Wed, 25 Oct 2000 06:16:02 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200010251016.GAA23219@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : UMAC: Message Authentication Code using Universal Hashing Author(s) : T. Krovetz et al. Filename : draft-krovetz-umac-01.txt Pages : 39 Date : 24-Oct-00 This specification describes how to generate an authentication tag (also called a 'MAC') using the UMAC message authentication code. UMAC is designed to be very fast to compute, in software, on contemporary processors. Measured speeds are as low as 1.0 cycles per byte. The heart of UMAC is a universal hash function, UHASH, which relies on addition and multiplication of 16-bit, 32-bit, or 64-bit numbers, operations well-supported by contemporary machines. To generate the authentication tag on a given message, UHASH is applied to the message and key to produce a short, fixed-length, hash value, and this hash value is then XOR-ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis and its only 'cryptographic' use is a block cipher, AES, to generate the pseudorandom pads and internal key material. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-krovetz-umac-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-krovetz-umac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-krovetz-umac-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001024110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-krovetz-umac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-krovetz-umac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001024110923.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- 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-- From bounce-ietf-tls-3458737@lists.certicom.com Wed Oct 25 08:23:37 2000 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 IAA06110 for ; Wed, 25 Oct 2000 08:23:37 -0400 (EDT) Message-ID: Date: Wed, 25 Oct 2000 13:24:36 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Forward secrecy and performance (was AES ciphersuites) 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: <39F6D104.CC33E13@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Hopwood wrote: > > > In the monolithic server case, I think it's definitely realistic to > expect that the ephemeral keys can be kept as secure as the static > key. In the split server case, it is more complicated, but it's also > complicated for the existing ciphersuites, because chosen-signature > attacks against PKCS #1 type 0, attacks against the RNG, etc. need to > be considered. > I may be missing something here but I'm not sure where the "type 0 attacks" fits into this. I presume "type 0" refers to PKCS#1 v1.5 block type 0. TLS always uses block type 1 (see RFC 2246 8.1.1). > > For a split server, the inner layer must generate and sign > ephemeral keys internally, and only give access to an encryption > oracle for the current ephemeral key. (It's desirable for the > encryption to be done in hardware anyway for performance reasons.) > I.e. at any given time it has to store up to three keys securely > (including the one being generated) instead of one, which I don't > see as being a big problem. Existing SSL/TLS accelerators would > require at least firmware changes in order to support the new > ciphersuites, though. > Here I think is the problem. Current servers may well allow unrestricted signing with the servers private key and it may use some standard such as PKCS#11 for this operation which doesn't AFAIK currently have a mechanism that can be restricted in this way. Getting a new mechanism standardised and getting hardware vendors to support it (assuming their harware can) is likely to be time consuming. As I believe you have mentioned, unrestricted signing would allow an attack on the server to sign a bogus public key and then use it to perform "man in the middle" attacks on the server until its certificate expired (or was revoked if the clients actually checked revocation). I'd also say that many servers would want to use more than just one key for all ephemeral cipher suites. I know of some that have a "pool" of ephemeral keys and use one at random. This would place additional demands on the server crypto hardware. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- 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 Thu Oct 26 03:20:02 2000 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 DAA16137 for ; Thu, 26 Oct 2000 03:20:02 -0400 (EDT) Message-ID: Date: Thu, 26 Oct 2000 00:18:31 -0700 From: Lewis McCarthy Organization: Cypherpunks X-Mailer: Mozilla 4.73 [en]C-compaq (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-krovetz-umac-01.txt 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: <39F7DAC7.DF1AD80@acm.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hi, > This specification describes how to generate an authentication tag > (also called a 'MAC') using the UMAC message authentication code. [...] > To generate the authentication tag on a given message, UHASH is [...] I have a question about the terminology used in this draft. Throughout the document the term "authentication tag" seems to be preferred to "message authentication code" (or simply "MAC"). Since the term "MAC" is very well established in the literature and community, I wonder why you would prefer to use the other phrase. (I took a quick look on the web and at the Crypto `00 proceedings in search of evidence for "authentication tag" coming into vogue. An Alta Vista search on "message authentication code" alone produced the maximum 1000 hits. A corresponding search for "authentication tag" yielded just 46 hits. In the Message Authentication session of the last Crypto, the abstracts of all three papers use "MAC" and none use "authentication tag".) -Lewis -- http://home.att.net/~lewis.mccarthy pseudonym@acm.org 1-408-499-5708 UTC-07 "An article in The Times Magazine last Sunday about Ivana Trump and her spending habits misstated the number of bras she buys. It is two dozen black, two dozen beige and two dozen white, not two thousand of each." --NY Times `Corrections` 22 Oct 2000 --- 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 Thu Oct 26 11:53:51 2000 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 LAA09365 for ; Thu, 26 Oct 2000 11:53:50 -0400 (EDT) Date: Thu, 26 Oct 2000 17:53:34 +0200 (IST) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-krovetz-umac-01.txt In-Reply-To: <200010251016.GAA23219@ietf.org> Message-ID: 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 As recently announced, the draft draft-krovetz-umac-01.txt is available from the Internet-Drafts directory. This document contains a full specification of the "UMAC" Message Authentication Code (i.e a function that provides data integrity verification for entities that share a key). This is the result of a three-year project involving several researchers. A paper describing the mathematical foundations of the algorithm was published more than a year ago in CRYPTO '99 [1]. UMAC was designed to provide strong authenticity guarantees while being flexible, provably secure, and **as fast as possible** on modern (and emerging) processors. Experiments show that UMAC achieves software speeds that are many times the speed of HMAC-SHA1. A quite unique feature of UMAC is that it lets you easily trade performance and security: from weak authentication against Denial of Service at GigaByte/second to the strongest authentication for the real paranoids at 100's of MegaBytes/second. For the most speed-demanding applications, as they emerge, I believe that UMAC provides a solution that is superior to current algorithms based on cryptographic hash functions (e.g. HMAC) or block ciphers (e.g. CBC-MAC). See the the UMAC homepage, http://www.cs.ucdavis.edu/~rogaway/umac, for additional information, including some performance details. Hugo PS: A word about UMAC's security. UMAC's security analysis is based on two factors: 1) The 20-year old methodology (due to Carter and Wegman) for building MAC functions on the basis of universal hashing. 2) The availability of a strong cipher (e.g. AES). The result of this analysis is that the only way that the proven security bounds for UMAC could fail is by breaking the underlying cipher (say Rijndael). As long as this cipher is unbroken so is UMAC. In this sense, UMAC does not need to be subject to cryptanalytical scrutiny before it can be used; you just need to believe that the underlying block cipher is secure. (See more information in [1] and in the draft's Security Considerations) [1] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway. "UMAC: Fast and secure message authentication". Advances in Cryptology - CRYPTO '99. Lecture Notes in Computer Science, vol. 1666, Springer-Verlag, 1999, pp. 216-233. --- 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 Thu Oct 26 12:29:52 2000 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 MAA18169 for ; Thu, 26 Oct 2000 12:29:51 -0400 (EDT) Date: Thu, 26 Oct 2000 18:29:38 +0200 (IST) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-krovetz-umac-01.txt In-Reply-To: Message-ID: 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 On Thu, 26 Oct 2000, Lewis McCarthy wrote: > Hi, > > > This specification describes how to generate an authentication tag > > (also called a 'MAC') using the UMAC message authentication code. > [...] > > To generate the authentication tag on a given message, UHASH is > [...] > > I have a question about the terminology used in this draft. > Throughout the document the term "authentication tag" seems to be > preferred to "message authentication code" (or simply "MAC"). > Since the term "MAC" is very well established in the literature > and community, I wonder why you would prefer to use the other > phrase. In the cryptographic context the word MAC is used to denote data authentication functions based on shared keys. Sometimes MAC is also used to denote the output of the function. However, this is confusing. Therefore it is quite common to find in the crypto literature the term "authentication tag" to denote the output of the function, i,e the actual authentication bits that you append to a message for transmission. (In other words, an authentication tag is to a MAC as a ciphertext to encryption.) Hugo > > (I took a quick look on the web and at the Crypto `00 proceedings > in search of evidence for "authentication tag" coming into > vogue. An Alta Vista search on "message authentication code" > alone produced the maximum 1000 hits. A corresponding search for > "authentication tag" yielded just 46 hits. In the Message > Authentication session of the last Crypto, the abstracts of > all three papers use "MAC" and none use "authentication tag".) > > -Lewis > -- > http://home.att.net/~lewis.mccarthy > pseudonym@acm.org 1-408-499-5708 UTC-07 > "An article in The Times Magazine last Sunday about > > Ivana Trump and her spending habits misstated the > number of bras she buys. It is two dozen black, two > dozen beige and two dozen white, not two thousand > of each." --NY Times `Corrections` 22 Oct 2000 > > --- > You are currently subscribed to ietf-tls as: hugo@ee.technion.ac.il > 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 Thu Oct 26 14:39:53 2000 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 OAA05219 for ; Thu, 26 Oct 2000 14:39:52 -0400 (EDT) Message-Id: Date: Thu, 26 Oct 2000 14:33:04 -0400 (EDT) From: "David P. Kemp" Reply-To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-krovetz-umac-01.txt To: "IETF Transport Layer Security WG" MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Ew5xV9DgsnX2v+FrAYogFA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200010261819.OAA10093@roadblock.missi.ncsc.mil> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net The Handbook of Applied Cryptography refers to "MAC algorithms" as the functions, and MAC as the resulting output: "Keyed hash functions whose specific purpose is message authentication are called message authentication code (MAC) algorithms." and "Algorithm CBC-MAC INPUT: data x; ... OUTPUT: n-bit MAC on x" It is also common usage for the term "code" to refer to a data value; I ordered a computer by phone this past weekend, and was given both a "customer code" and an "order code". Using message authentication code for data doesn't seem especially confusing. ----- While we're on the topic of vocabulary, I'd like to hear opinions on the meaning of PFS. I'm inclined to believe David Hopwood that "perfect" implies forward secrecy against a computationally-unbound opponent. Is the IETF idiom of using PFS to mean nothing other than FS at odds with its generally-accepted cryptographic meaning? Dave > From: Hugo Krawczyk > > In the cryptographic context the word MAC is used to denote > data authentication functions based on shared keys. > Sometimes MAC is also used to denote the output of the function. > However, this is confusing. Therefore it is quite common to find > in the crypto literature the term "authentication tag" > to denote the output of the function, i,e the actual authentication bits > that you append to a message for transmission. > (In other words, an authentication tag is to a MAC as a ciphertext to > encryption.) > > Hugo --- 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 Thu Oct 26 17:03:12 2000 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 RAA22406 for ; Thu, 26 Oct 2000 17:03:11 -0400 (EDT) Message-Id: X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Oct 2000 16:38:41 -0400 To: "IETF Transport Layer Security WG" From: David Jablon Subject: [ietf-tls] Re: I-D ACTION:draft-krovetz-umac-01.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <4.3.2.7.0.20001026163435.00b25d30@world.std.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net David, The term PFS came first (introduced by Diffie vanOorschot & Weiner in 1992 perhaps?), got changed to FS in certain circles (like P1363) to avoid the implied meaning that you mention, and which almost nobody intended it to mean. For what it's worth, I think the P should be dropped entirely, and the term PFS deprecated, rather than trying to transmute it to mean something other than FS. -- David At 02:33 PM 10/26/00 -0400, you wrote: >While we're on the topic of vocabulary, I'd like to hear opinions on >the meaning of PFS. I'm inclined to believe David Hopwood that >"perfect" implies forward secrecy against a computationally-unbound >opponent. Is the IETF idiom of using PFS to mean nothing other than FS >at odds with its generally-accepted cryptographic meaning? --- 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 Oct 27 11:56:24 2000 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 LAA07509 for ; Fri, 27 Oct 2000 11:56:23 -0400 (EDT) Date: Fri, 27 Oct 2000 16:55:46 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] New AES draft available Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001027165546.A15638@hyena.skygate.co.uk> X-List-Host: SKYLIST.net A new draft of the AES ciphersuite document is available from the usual place: ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/ The latest version is: ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-01a.txt The main change in this revision is that the document now provides AES analogues for most of the original ciphersuites, including static RSA. The exceptions are the "anon" and export ciphersuites. The first group have been deprecated ever since the original TLS specification, while recent legal changes have made the second group essentially irrelevant. I have had an extensive discussion off-list with some of the people who originally opposed this change. I believe (my apologies if I have misunderstood anyone's position) that no one has serious objections to us proceeding on this new basis. Of course, if this is not the case, please send an email to me or the list. This is particularly important because not everyone was involved in the off-list discussion. (Note: the sequence of documents that led up to the draft published by the IETF are now called 00a, 00b, 00c and so on. Hopefully the 01a sequence will eventually become a document that will be numbered 01 by the IETF.) -- Pete --- 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 Oct 27 16:01:02 2000 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 QAA15937 for ; Fri, 27 Oct 2000 16:01:01 -0400 (EDT) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-188.dialup.zetnet.co.uk [194.247.40.238] claimed to be zetnet.co.uk Message-ID: Date: Fri, 27 Oct 2000 21:00:56 +0100 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: I-D ACTION:draft-krovetz-umac-01.txt Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <39F9DEF8.AEC1F81@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA15937 -----BEGIN PGP SIGNED MESSAGE----- David Jablon wrote: > The term PFS came first (introduced by Diffie vanOorschot & Weiner in 1992 > perhaps?), ... I believe it was first used in Cristoph G. Günther, "An identity-based key-exchange protocol," Advances in Cryptology - EUROCRYPT '89 Proceedings, Lecture Notes in Comp. Sci. Vol. 434 (J-J. Quisquater, J. Vandewille ed.), Springer-Verlag, 1989. It's also worth pointing out that forward secrecy is usually associated with security against passive known-key attacks (i.e. if an attacker knows the long-term authentication key of one of the parties, he still cannot do a passive eavesdropping attack on the protocol, only an active attack). Technically they are two distinct properties, though. > For what it's worth, I think the P should be dropped entirely, and the > term PFS deprecated, rather than trying to transmute it to mean something > other than FS. I agree. For MACs, "authentication tag" and "MAC output" are synonyms, and there's not much to choose between them. - -- 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 iQEVAwUBOfkUZzkCAxeYt5gVAQGLEAgAgCDYCTtQXrmBuPkgZX3WelF09FQQsKzh XaVfSITmcuqxsC2YJX1sTcLVShH4cs86LvNP7DbNOvEpXm4Ssz4yK52eXSw4CJSG 70QE/FARWL6bKITMafihsV7LTi6CBe4uwI0cfjQGZbi6g3MU/uNf79O06F/1BbM8 vVm6W0XTETZF7wJ0SSpe43uagjxmDMWHL1Lg2fjdYNx2J8ZIn0z4Je53/33dDEey rUyshWWHUr2eOKRS2E69YPfuydGH7iBZUtFf1gTte6i7//k+CnjGBMQ5duLkMs4B 4ZcXRyZypQNGGDcOpVHUsnA8ZCsPR9fwAqJS2BZl5496wLhkVc1kqw== =Fi40 -----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 Oct 31 09:32:44 2000 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 JAA08038 for ; Tue, 31 Oct 2000 09:32:43 -0500 (EST) From: Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites I-d Date: Tue, 31 Oct 2000 14:30:53 -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 support Pete Chown's new version of the AES ciphersuites I-d, with one proviso - in specifying support of the new ciphersuites, I'd like to suggest that the spec distinguish between clients and servers. The server MUST support a selection of ciphersuites, and MAY support others, and clients MUST support one of the server-mandated selection and MAY support others. This way inter-operability is guaranteed (which it isn't by Pete's current formulation) and client implementers can choose a ciphersuite (or suites) appropriate to a client's capabilities. By the by, PFS, though a good thing to have, is not so important in the mobile environment, I would say, if the mobile has a smartcard to store private keys, master_secrets, generate randoms, etc. assuming decent hardware security, access control, DPA, and so forth. 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