From bounce-ietf-tls-3458737@lists.certicom.com Tue May 1 07:01:27 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22966 for ; Tue, 1 May 2001 07:01:23 -0400 (EDT) Message-ID: From: "gabriel olariu" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] TLS over satellite links Date: Tue, 1 May 2001 07:00:08 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BB5_01C0D20C.5BE3F340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <0bb801c0d22d$e3172500$dca2558b@golariupc> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a multi-part message in MIME format. ------=_NextPart_000_0BB5_01C0D20C.5BE3F340 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello everyone, Being involved with performance of TCP over satellite links, I came to ask myself how will TLS behave over high bandwidth=20 delay product networks. Is there any work done so far in this direction? I would be interested to learn about experimental=20 results. Thanks, gabriel olariu --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com ------=_NextPart_000_0BB5_01C0D20C.5BE3F340 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello everyone,

Being involved with performance of TCP over = satellite=20 links,

I came to ask myself how will TLS behave over high = bandwidth=20

delay product networks. Is there any work done so = far in=20 this

direction? I would be interested to learn about = experimental=20

results.

Thanks,

gabriel olariu

---
You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org
To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com ------=_NextPart_000_0BB5_01C0D20C.5BE3F340-- From bounce-ietf-tls-3458737@lists.certicom.com Wed May 2 19:26:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26157 for ; Wed, 2 May 2001 19:26:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] TLS roadmap, and spot for dns_name extension Date: Wed, 2 May 2001 16:26:36 -0700 Message-ID: Thread-Topic: TLS roadmap, and spot for dns_name extension Thread-Index: AcDTX0dizI1qedYgS/K801ejjnZTGQ== From: "Joseph Hui" To: "IETF Transport Layer Security WG" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26157 Hi everyone, If you would indulge me, may I suggest we have a discussion on plotting a TLS roadmap, at least for 1.1 and 1.2, based on the extensions currently proposed, in the interest of ensuring their timely roll-out? I further suggest (to the group chairs and all) we make it the primary goal that by the next IETF meeting timeline (August), we at least reach a consensus on some tangible dates for 1.1 , and what will be in it. (Good luck! Right? ;-) Where I'm coming from is about the DNS Name Extension proposed by Jan M, et al. It's been, and still is, badly needed by CDNs since yesteryears. To my understanding, the original dns_name thread started last August, and soon ended with general acceptance of the solution but without agreement on its TLS revision#. I then read indication that such extension might get folded into a draft mainly for the wireless environment. Of extensions, there're those that are needed and those that are needed badly. Lumping them together may have virtue of its own, but I'm concerned that it may also make the long wait for the dns_name solution even longer. My hope, and hopefully the same hope of many, is that a roadmap would help us move things along faster, plan better, and avoid unnecessary/inadvertant hold-ups. Regards, Joe Joe Hui Digital Island --- 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 May 3 08:49:23 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21344 for ; Thu, 3 May 2001 08:49:22 -0400 (EDT) Date: Thu, 3 May 2001 13:48:31 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: TLS roadmap, and spot for dns_name extension 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 jhui@digisle.net on Wed, May 02, 2001 at 04:26:36PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010503134831.H17408@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Joseph Hui wrote: > If you would indulge me, may I suggest we have a discussion on > plotting a TLS roadmap, at least for 1.1 and 1.2, based on the > extensions currently proposed, in the interest of ensuring their > timely roll-out? That sounds like a good idea to me. If we set ourselves particular target dates it will help to make things happen, because everyone will know what they are working towards. I will probably come to the next IETF meeting because it's in London, and only about half an hour from where I live. I would like to meet the rest of you if you will be there for a TLS meeting. -- 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 May 7 11:47:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14762 for ; Mon, 7 May 2001 11:47:28 -0400 (EDT) Message-ID: From: Maureen.Stillman@nokia.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: TLS roadmap, and spot for dns_name extension Date: Mon, 7 May 2001 08:00:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 understand the pressing need for the DNS Name Extension, but I also feel that the wireless extensions are very important. I would like to see us proceed with both for TLS 1.1. The wireless extensions have been discussed since last November. I'm in agreement with you on getting a roadmap defined so that we know where we are headed and to help us plan. My preference is to see the wireless extensions and DNS name extension in TLS 1.1. It was suggested that these come under the more general heading of "extensions to TLS". Simon Blake-Wilson said that he would be releasing an updated internet draft soon on wireless extensions reflecting the earlier discussions. I'm hoping general consensus can be reached on this I-D so that we can move forward. The deadline that you mentioned for the August meeting in London sounds reasonable. -- maureen Maureen Stillman Nokia Member of Scientific Staff Voice: (607)273-0724 x62 Internet Commerce Enhancement Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman@nokia.com www.nokia.com -----Original Message----- From: ext Joseph Hui [mailto:jhui@digisle.net] Sent: Wednesday, May 02, 2001 7:27 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] TLS roadmap, and spot for dns_name extension Hi everyone, If you would indulge me, may I suggest we have a discussion on plotting a TLS roadmap, at least for 1.1 and 1.2, based on the extensions currently proposed, in the interest of ensuring their timely roll-out? I further suggest (to the group chairs and all) we make it the primary goal that by the next IETF meeting timeline (August), we at least reach a consensus on some tangible dates for 1.1 , and what will be in it. (Good luck! Right? ;-) Where I'm coming from is about the DNS Name Extension proposed by Jan M, et al. It's been, and still is, badly needed by CDNs since yesteryears. To my understanding, the original dns_name thread started last August, and soon ended with general acceptance of the solution but without agreement on its TLS revision#. I then read indication that such extension might get folded into a draft mainly for the wireless environment. Of extensions, there're those that are needed and those that are needed badly. Lumping them together may have virtue of its own, but I'm concerned that it may also make the long wait for the dns_name solution even longer. My hope, and hopefully the same hope of many, is that a roadmap would help us move things along faster, plan better, and avoid unnecessary/inadvertant hold-ups. Regards, Joe Joe Hui Digital Island --- You are currently subscribed to ietf-tls as: Maureen.Stillman@nokia.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 From bounce-ietf-tls-3458737@lists.certicom.com Mon May 7 12:23:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15755 for ; Mon, 7 May 2001 12:23:25 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] RE: TLS roadmap, and spot for dns_name extension Date: Mon, 7 May 2001 09:23:38 -0700 Message-ID: Thread-Topic: [ietf-tls] RE: TLS roadmap, and spot for dns_name extension Thread-Index: AcDW9ghhmOtxqRRoQPmLyMhASwDfLwAFWiWw From: "Joseph Hui" To: "IETF Transport Layer Security WG" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA15755 Maureen, Thanks for the echo. As both of the dns_name problem and solution have been openly discussed and reached a conclusive state, I'd like to suggest we start the TLS 1.1 roadmap with the DNS Name Extension, if that's also alright with the authors -- Jan M, et al. Regards, Joe Joe Hui Research Engineer Digital Island (805) 370-2165 =================================================== -----Original Message----- From: Maureen.Stillman@nokia.com [mailto:Maureen.Stillman@nokia.com] Sent: Monday, May 07, 2001 6:01 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] RE: TLS roadmap, and spot for dns_name extension I understand the pressing need for the DNS Name Extension, but I also feel that the wireless extensions are very important. I would like to see us proceed with both for TLS 1.1. The wireless extensions have been discussed since last November. I'm in agreement with you on getting a roadmap defined so that we know where we are headed and to help us plan. My preference is to see the wireless extensions and DNS name extension in TLS 1.1. It was suggested that these come under the more general heading of "extensions to TLS". Simon Blake-Wilson said that he would be releasing an updated internet draft soon on wireless extensions reflecting the earlier discussions. I'm hoping general consensus can be reached on this I-D so that we can move forward. The deadline that you mentioned for the August meeting in London sounds reasonable. -- maureen Maureen Stillman Nokia Member of Scientific Staff Voice: (607)273-0724 x62 Internet Commerce Enhancement Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman@nokia.com www.nokia.com -----Original Message----- From: ext Joseph Hui [mailto:jhui@digisle.net] Sent: Wednesday, May 02, 2001 7:27 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] TLS roadmap, and spot for dns_name extension Hi everyone, If you would indulge me, may I suggest we have a discussion on plotting a TLS roadmap, at least for 1.1 and 1.2, based on the extensions currently proposed, in the interest of ensuring their timely roll-out? I further suggest (to the group chairs and all) we make it the primary goal that by the next IETF meeting timeline (August), we at least reach a consensus on some tangible dates for 1.1 , and what will be in it. (Good luck! Right? ;-) Where I'm coming from is about the DNS Name Extension proposed by Jan M, et al. It's been, and still is, badly needed by CDNs since yesteryears. To my understanding, the original dns_name thread started last August, and soon ended with general acceptance of the solution but without agreement on its TLS revision#. I then read indication that such extension might get folded into a draft mainly for the wireless environment. Of extensions, there're those that are needed and those that are needed badly. Lumping them together may have virtue of its own, but I'm concerned that it may also make the long wait for the dns_name solution even longer. My hope, and hopefully the same hope of many, is that a roadmap would help us move things along faster, plan better, and avoid unnecessary/inadvertant hold-ups. Regards, Joe Joe Hui Digital Island --- You are currently subscribed to ietf-tls as: Maureen.Stillman@nokia.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: jhui@digisle.net 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 May 10 13:59:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05097 for ; Thu, 10 May 2001 13:59:38 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 10 May 2001 13:59:00 -0400 Subject: [ietf-tls] AES for TLS (draft-ietf-tls-ciphersuite-03.txt) 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: <5.0.1.4.2.20010510135755.0183c010@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I recently reviewed draft-ietf-tls-ciphersuite-03.txt. The S/MIME WG (which I chair) is going through a similar exercise. S/MIME is on track to mandate the use of RSA-OAEP (RFC 2347) with AES. This approach provides improved protection against Bleichenbacher's Million Message Attack. I have spoken at the SAAG to encourage a common set of algorithms and modes throughout the IETF Security Area. I realize that such a lofty goal cannot be archived overnight, but I do believe that we can make steady incremental improvement. Here is one opportunity. I urge the TLS WG to the use of RSA-OAEP with AES. Thanks for listening, Russ --- 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 May 10 19:21:19 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09937 for ; Thu, 10 May 2001 19:21:15 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES for TLS (draft-ietf-tls-ciphersuite-03.txt) Date: Fri, 11 May 2001 01:19:12 +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 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <007501c0d9a7$a097c280$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I agree that OAEP is the way to go, but I would suggest that TLS 1.1 simply switches to OAEP for all ciphersuites using RSA key exchange. This seems preferable to making standard ciphersuites using different RSA padding modes for a given version of TLS. Since the current TLS spec already describes a workaround for the Bleichenbacher attack I do not see a pressing time limit for using OAEP. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----- Original Message ----- From: "Housley, Russ" To: "IETF Transport Layer Security WG" Sent: Thursday, May 10, 2001 7:59 PM Subject: [ietf-tls] AES for TLS (draft-ietf-tls-ciphersuite-03.txt) > > I recently reviewed draft-ietf-tls-ciphersuite-03.txt. The S/MIME WG > (which I chair) is going through a similar exercise. S/MIME is on track to > mandate the use of RSA-OAEP (RFC 2347) with AES. This approach provides > improved protection against Bleichenbacher's Million Message Attack. > > I have spoken at the SAAG to encourage a common set of algorithms and modes > throughout the IETF Security Area. I realize that such a lofty goal cannot > be archived overnight, but I do believe that we can make steady incremental > improvement. Here is one opportunity. I urge the TLS WG to the use of > RSA-OAEP with AES. > > Thanks for listening, > Russ --- 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 May 14 16:31:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23926 for ; Mon, 14 May 2001 16:31:45 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 14 May 2001 16:31:17 -0400 Subject: [ietf-tls] Re: AES for TLS (draft-ietf-tls-ciphersuite-03.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: <5.0.1.4.2.20010514162935.018e0720@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I have no problem with support for RSA-OAEP with all symmetric ciphers. As I said, I am pushing for a common algorithm set across the IETF Security Area. RSA-OAEP with AES seems like a very nice start. Russ At 01:19 AM 5/11/2001 +0200, Andreas Sterbenz wrote: >I agree that OAEP is the way to go, but I would suggest that TLS 1.1 simply >switches to OAEP for all ciphersuites using RSA key exchange. This seems >preferable to making standard ciphersuites using different RSA padding modes >for a given version of TLS. Since the current TLS spec already describes a >workaround for the Bleichenbacher attack I do not see a pressing time limit >for using OAEP. > > Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at > > >----- Original Message ----- >From: "Housley, Russ" >To: "IETF Transport Layer Security WG" >Sent: Thursday, May 10, 2001 7:59 PM >Subject: [ietf-tls] AES for TLS (draft-ietf-tls-ciphersuite-03.txt) > > > > > > I recently reviewed draft-ietf-tls-ciphersuite-03.txt. The S/MIME WG > > (which I chair) is going through a similar exercise. S/MIME is on track >to > > mandate the use of RSA-OAEP (RFC 2347) with AES. This approach provides > > improved protection against Bleichenbacher's Million Message Attack. > > > > I have spoken at the SAAG to encourage a common set of algorithms and >modes > > throughout the IETF Security Area. I realize that such a lofty goal >cannot > > be archived overnight, but I do believe that we can make steady >incremental > > improvement. Here is one opportunity. I urge the TLS WG to the use of > > RSA-OAEP with AES. > > > > Thanks for listening, > > Russ > > > >--- >You are currently subscribed to ietf-tls as: rhousley@rsasecurity.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 From bounce-ietf-tls-3458737@lists.certicom.com Tue May 29 22:38:40 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16141 for ; Tue, 29 May 2001 22:38:40 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] revised I-D (Addition of Camellia to TLS) Date: Wed, 30 May 2001 11:38:43 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200105300238.LAA27274@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Dear IETF TLS WG, I've just submitted draft-ietf-tls-camellia-01.txt (Addition of the Camellia Encryption Algorithm to TLS). Major changes from the previous version include: 1. Intellectual property section is updated. We are prepared to grant, on the basis of reciprocity and non-discriminatory, a royalty-free license under Camellia essential patents in accordance with Section 10 of RFC 2026. I sent a formal patent statement pertaining to Camellia to the IETF Secretariat a few days ago. It will be available on the IETF page of IPR Notices. 2. Camellia ciphersuites are defined and numbered according to the discussion of this mailing list. Best regards, Shiho Moriai NTT Laboratories Information Security Project --- 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 May 30 09:39:17 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10515 for ; Wed, 30 May 2001 09:39:15 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] WG Last Call for "AES Ciphersuites for TLS" Date: Wed, 30 May 2001 09:36:00 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200105301337.f4UDaud18627@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is LAST CALL for comments on advancing the draft "AES Ciphersuites for TLS" to Proposed Standard. The last call period is two weeks for the working group. The current draft is draft-ietf-tls-ciphersuite-03.txt and is at http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt ftp://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt Win Treese Chair, TLS working group treese@acm.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 May 30 10:19:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12332 for ; Wed, 30 May 2001 10:19:28 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] On doing TLS 1.1 Date: Wed, 30 May 2001 09:40:52 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200105301341.f4UDfmr18645@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net There has been a small bit of discussion recently about a "1.1" specification for TLS. I'd like to see a bit more discussion about this, particularly about to whether or not this working group needs to do that work. The charter is (and always has been) focused mainly on defining a standard for TLS and advancing it on the standards track. I certainly appreciate the desire for adding newer and innovative work, and I'm please to see such thinking. But before undertaking the larger project, I'd like to get a better sense from the working group about whether or not it makes sense to do. Comments? Win Treese Chair, TLS working group treese@acm.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 May 30 12:00:36 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15854 for ; Wed, 30 May 2001 12:00:34 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 30 May 2001 12:00:08 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" 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: <5.0.1.4.2.20010530115149.01d66f38@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On the 8th of May, I requested that RSA-OAEP be used with AES. The proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like to see this changed. I have spoken at the SAAG to encourage a common set of algorithms and modes throughout the IETF Security Area. I realize that such a lofty goal cannot be archived overnight, but I do believe that we can make steady incremental improvement. Here is one opportunity. The S/MIME working group is on track to mandate the use of RSA-OAEP with AES, so we have a real opportunity to achieve significant commonality. Again, I urge the TLS working group to the use of RSA-OAEP with AES. Russ At 09:36 AM 5/30/2001 -0400, Win Treese wrote: >This is LAST CALL for comments on advancing the draft "AES >Ciphersuites for TLS" to Proposed Standard. The last call period is >two weeks for the working group. > >The current draft is draft-ietf-tls-ciphersuite-03.txt and is at >http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt >ftp://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt > >Win Treese >Chair, TLS working group >treese@acm.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 May 30 12:10:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16183 for ; Wed, 30 May 2001 12:10:44 -0400 (EDT) X-Lotus-FromDomain: HNS From: dillon@hns.com Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" cc: border@hns.com, jheath@hns.com Message-ID: Date: Wed, 30 May 2001 11:35:15 -0400 Subject: [ietf-tls] Re: On doing TLS 1.1 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A5C.0055D82D.00@ngw2.hns.com> X-List-Host: SKYLIST.net Has anyone considered adding compression to TLS? Should be easy and would save a lot bandwidth for wireless apps at no cost in CPU (MIPs spent compressing would offset MIPs which would have been spent on crypto). Doug Dillon Win Treese @lists.certicom.com on 05/30/2001 09:40:52 AM Please respond to "IETF Transport Layer Security WG" Sent by: bounce-ietf-tls-4215505@lists.certicom.com To: "IETF Transport Layer Security WG" cc: (bcc: Doug Dillon/HNS) Subject: [ietf-tls] On doing TLS 1.1 There has been a small bit of discussion recently about a "1.1" specification for TLS. I'd like to see a bit more discussion about this, particularly about to whether or not this working group needs to do that work. The charter is (and always has been) focused mainly on defining a standard for TLS and advancing it on the standards track. I certainly appreciate the desire for adding newer and innovative work, and I'm please to see such thinking. But before undertaking the larger project, I'd like to get a better sense from the working group about whether or not it makes sense to do. Comments? Win Treese Chair, TLS working group treese@acm.org --- You are currently subscribed to ietf-tls as: dillon@hns.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 From bounce-ietf-tls-3458737@lists.certicom.com Wed May 30 13:16:03 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18526 for ; Wed, 30 May 2001 13:15:58 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] RE: On doing TLS 1.1 Date: Wed, 30 May 2001 10:15:37 -0700 Message-ID: Thread-Topic: [ietf-tls] On doing TLS 1.1 Thread-Index: AcDpDsJPDYFGWLmLSbuG1OKOQUVM+AAERt6w From: "Joseph Hui" To: "IETF Transport Layer Security WG" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18526 My take is it makes sense to do an appropriately scoped 1.1. Let's keep it light, to ensure its timely roll-out. As we are committing ourselves to do 1.1, then it also makes sense to set a schedule for 1.2. Otherwise, nobody wants to get left behind, fearing the uncertainty of 1.2 (or whatever the next version that may never come), which will result in 1.1 being laden with so many goodies that it just can't take off. So allow me to reiterate my previous suggestion that we plot a TLS roadmap, i.e. what will be in 1.1 and what next. I believe Simon & company are finalizing their TLS extensions draft, which encompasses several reasonably mature proposals. It should give us a good starting point to scope out 1.1. Regards, Joe Hui Research Engineer Digital Island ================================================================ -----Original Message----- From: Win Treese [mailto:treese@acm.org] Sent: Wednesday, May 30, 2001 6:41 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] On doing TLS 1.1 There has been a small bit of discussion recently about a "1.1" specification for TLS. I'd like to see a bit more discussion about this, particularly about to whether or not this working group needs to do that work. The charter is (and always has been) focused mainly on defining a standard for TLS and advancing it on the standards track. I certainly appreciate the desire for adding newer and innovative work, and I'm please to see such thinking. But before undertaking the larger project, I'd like to get a better sense from the working group about whether or not it makes sense to do. Comments? Win Treese Chair, TLS working group treese@acm.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 May 30 17:03:17 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24700 for ; Wed, 30 May 2001 17:03:16 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 Date: Wed, 30 May 2001 23:02:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <001a01c0e94b$d9672b10$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit Given the way TLS achieves backwards compatibility - namely by implementing all desired protocol versions - I am very much in favor of keeping the number of versions to a minimum. As all the features people really seem to be interested in (name based virtual hosting, applicability to low bandwidth devices, additional ciphersuites) can be achieved without requiring changes to the TLS 1.0 spec itself, I see no reason to rush TLS 1.1. I would suggest that this working group takes on TLS 1.1 and fixes the (arguably) theoretical cryptographic weaknesses in the protocol and improves protocol efficiency. My list of topics would include the Bodo M�ller handshake attack, MACing before encrypting (insecure according to Krawczyk), the PRF function, and record protocol overhead among other things. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----- Original Message ----- From: "Joseph Hui" To: "IETF Transport Layer Security WG" Sent: Wednesday, May 30, 2001 7:15 PM Subject: [ietf-tls] RE: On doing TLS 1.1 My take is it makes sense to do an appropriately scoped 1.1. Let's keep it light, to ensure its timely roll-out. As we are committing ourselves to do 1.1, then it also makes sense to set a schedule for 1.2. Otherwise, nobody wants to get left behind, fearing the uncertainty of 1.2 (or whatever the next version that may never come), which will result in 1.1 being laden with so many goodies that it just can't take off. So allow me to reiterate my previous suggestion that we plot a TLS roadmap, i.e. what will be in 1.1 and what next. I believe Simon & company are finalizing their TLS extensions draft, which encompasses several reasonably mature proposals. It should give us a good starting point to scope out 1.1. Regards, Joe Hui Research Engineer Digital Island --- 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 May 30 18:07:19 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26000 for ; Wed, 30 May 2001 18:07:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] RE: On doing TLS 1.1 Date: Wed, 30 May 2001 15:07:59 -0700 Message-ID: Thread-Topic: [ietf-tls] RE: On doing TLS 1.1 Thread-Index: AcDpTAYT8vgK9A47SBW8KHcy0WCb2AAAux3w From: "Joseph Hui" To: "IETF Transport Layer Security WG" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA26000 If we reserve 1.1 for the grandiose, then there arises the need for 1.0 plus or 1.0.whatever to cram in the urgently needed features, such as the dns_name extension. However, I recall sound arguments were made in the past that if we don't increment the version number (for instituting such features), then web servers and browsers that are now TLS 1.0 compatible will suddenly become TLS 1.0 incompatible and their vendors/custodians will thus squawk, rightfully so, because of the confusion. Joe ========================================== -----Original Message----- From: Andreas Sterbenz [mailto:Andreas.Sterbenz@iaik.at] Sent: Wednesday, May 30, 2001 2:03 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] RE: On doing TLS 1.1 Given the way TLS achieves backwards compatibility - namely by implementing all desired protocol versions - I am very much in favor of keeping the number of versions to a minimum. As all the features people really seem to be interested in (name based virtual hosting, applicability to low bandwidth devices, additional ciphersuites) can be achieved without requiring changes to the TLS 1.0 spec itself, I see no reason to rush TLS 1.1. I would suggest that this working group takes on TLS 1.1 and fixes the (arguably) theoretical cryptographic weaknesses in the protocol and improves protocol efficiency. My list of topics would include the Bodo M�ller handshake attack, MACing before encrypting (insecure according to Krawczyk), the PRF function, and record protocol overhead among other things. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----- Original Message ----- From: "Joseph Hui" To: "IETF Transport Layer Security WG" Sent: Wednesday, May 30, 2001 7:15 PM Subject: [ietf-tls] RE: On doing TLS 1.1 My take is it makes sense to do an appropriately scoped 1.1. Let's keep it light, to ensure its timely roll-out. As we are committing ourselves to do 1.1, then it also makes sense to set a schedule for 1.2. Otherwise, nobody wants to get left behind, fearing the uncertainty of 1.2 (or whatever the next version that may never come), which will result in 1.1 being laden with so many goodies that it just can't take off. So allow me to reiterate my previous suggestion that we plot a TLS roadmap, i.e. what will be in 1.1 and what next. I believe Simon & company are finalizing their TLS extensions draft, which encompasses several reasonably mature proposals. It should give us a good starting point to scope out 1.1. Regards, Joe Hui Research Engineer Digital Island --- You are currently subscribed to ietf-tls as: jhui@digisle.net 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 May 30 18:38:32 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26541 for ; Wed, 30 May 2001 18:38:31 -0400 (EDT) Date: Wed, 30 May 2001 18:38:16 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 (version numbers) 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 jhui@digisle.net on Wed, May 30, 2001 at 03:07:59PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010530183816.I22949@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Wed, May 30, 2001 at 03:07:59PM -0700, Joseph Hui wrote: > If we reserve 1.1 for the grandiose, then there arises the need for 1.0 > plus or 1.0.whatever to cram in the urgently needed features, such as the > dns_name extension. However, I recall sound arguments were made in the > past that if we don't increment the version number (for instituting such features), > then web servers and browsers that are now TLS 1.0 compatible will suddenly > become TLS 1.0 incompatible and their vendors/custodians will thus squawk, > rightfully so, because of the confusion. Plus there are benefits for customers, as a product marketed as supporting TLS 1.1 sounds better, thus encouraging vendors to provide support for the newer features like dns_name... -Peter > -----Original Message----- > From: Andreas Sterbenz [mailto:Andreas.Sterbenz@iaik.at] > Given the way TLS achieves backwards compatibility - namely by > implementing > all desired protocol versions - I am very much in favor of keeping the > number of versions to a minimum. As all the features people really seem > to > be interested in (name based virtual hosting, applicability to low > bandwidth > devices, additional ciphersuites) can be achieved without requiring > changes > to the TLS 1.0 spec itself, I see no reason to rush TLS 1.1. --- 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 May 30 22:12:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29885 for ; Wed, 30 May 2001 22:12:51 -0400 (EDT) Message-ID: Date: Thu, 31 May 2001 00:38:36 +0100 From: David Hopwood 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: WG Last Call for "AES Ciphersuites for TLS" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B15847C.28D72CAC@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- "Housley, Russ" wrote: > On the 8th of May, I requested that RSA-OAEP be used with AES. The > proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like > to see this changed. Using OAEP with TLS makes effectively no difference to the provable security properties of the RSA ciphersuites, assuming that the method described in section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is replaced with a random value whenever the PKCS #1 v1.5 block is invalid). The effect of that method is to prevent chosen ciphertext attacks in much the same way as the "Simple RSA" scheme described in [Shoup01], which has a tighter reduction from the RSA problem than OAEP does. To get the same tightness of reduction when using OAEP in TLS, you would still have to require that no information is leaked about whether the decryption of the premaster secret succeeds or not. The disadvantage of switching to OAEP, is that firmware for TLS hardware accelerators would probably have to be changed. For that reason I would not be in favour of switching, at least for the AES ciphersuites. Instead, the RSA AES ciphersuites should say that the method in section 7.4.7.1 of RFC 2246 MUST be followed. (Note that currently, not all TLS implementations use that method. For example, last time I looked, OpenSSL just checked for additional redundancy, which makes Bleichenbacher's attack more difficult, but is not provably secure.) [Shoup01] Victor Shoup, "A Proposal for an ISO Standard for Public Key Encryption," February 13, 2001. Available from http://www.shoup.net/papers/ or http://citeseer.nj.nec.com/shoup01proposal.html - -- 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 iQEVAwUBOxV7SzkCAxeYt5gVAQGLjQf/R1iThHAdzVa2bHl9s6W6kiDPNykQh3Mx hl3WNa6Uy2K81FMizlQ07i5p/UKE3PIhxr6SFUgnyacOhM37wDG2jQiZKT7k1Ks7 cRtP63FRUjJ3UQCmipLmSLMCzm8K5Z7jGw5CUWgENDL1AAg9YTot1LTN94sXN/F0 te1nm2rUfeCDL4YR7n3Il88zY6pDNquFTRFqFiRInIAgUJmnA4DqDVJNfTsASIaP JA/NPiSejAXsaLEXEm6di3njwkrT9/yxHaAkxGwEi/4gjS3AsExUDFSvuf6BqNb5 A2H7rRo2i7iyVcMb6rU32Yn+vZJMJwFlbwE1hkWWiOP0rm2uRSoHYg== =4j0Y -----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 May 31 01:05:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03064 for ; Thu, 31 May 2001 01:05:38 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 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: 30 May 2001 22:12:00 -0700 In-Reply-To: "Joseph Hui"'s message of "Wed, 30 May 2001 15:07:59 -0700" Message-ID: Lines: 19 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 "Joseph Hui" writes: > If we reserve 1.1 for the grandiose, then there arises the need for > 1.0 plus or 1.0.whatever to cram in the urgently needed features, > such as the dns_name extension. However, I recall sound arguments > were made in the past that if we don't increment the version number > (for instituting such features), then web servers and browsers that > are now TLS 1.0 compatible will suddenly become TLS 1.0 incompatible > and their vendors/custodians will thus squawk, rightfully so, > because of the confusion. We can't make these features MUSTs for TLS 1.0, but the point of extensions is that you can implement them or not as you choose. It won't cause any problem to add these as optional extensions to 1.0 -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 May 31 01:06:36 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03131 for ; Thu, 31 May 2001 01:06:35 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 From: Eric Rescorla Date: 30 May 2001 22:13:01 -0700 In-Reply-To: "Andreas Sterbenz"'s message of "Wed, 30 May 2001 23:02:33 +0200" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA03131 "Andreas Sterbenz" writes: > I would suggest that this working group takes on TLS 1.1 and fixes the > (arguably) theoretical cryptographic weaknesses in the protocol and improves > protocol efficiency. My list of topics would include the Bodo M�ller > handshake attack, MACing before encrypting (insecure according to Krawczyk), I'd like to hear an argument as to why MACing before encrypting is a problem. It's relatively standard practice. > the PRF function What's wrong with the PRF function? >and record protocol overhead Computational or bandwidth overhead? -Erk --- 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 May 31 02:24:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15174 for ; Thu, 31 May 2001 02:24:37 -0400 (EDT) Message-Id: X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: security/TLS To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Message from David Hopwood of "Thu, 31 May 2001 00:38:36 +0100." Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 31 May 2001 16:24:39 +1000 From: Dean Povey List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200105310624.f4V6Odm12343@thunder.dstc.qut.edu.au> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net >"Housley, Russ" wrote: >> On the 8th of May, I requested that RSA-OAEP be used with AES. The >> proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like >> to see this changed. I have been lurking so I may have missed all the issues. Isn't the simplest solution to just consider RSA-OAEP a different algorithm to RSA (w/PKCS#1 pad), keep the existing identifiers and add the following: CipherSuite TLS_RSA_OAEP_WITH_AES_128_CBC_SHA = { 0x00, 0xXX }; CipherSuite TLS_DH_RSA_OAEP_WITH_AES_128_CBC_SHA = { 0x00, 0xXX }; CipherSuite TLS_DHE_RSA_OAEP_WITH_AES_128_CBC_SHA = { 0x00, 0xXX }; CipherSuite TLS_RSA_OAEP_WITH_AES_256_CBC_SHA = { 0x00, 0xXX }; CipherSuite TLS_DH_RSA_OAEP_WITH_AES_256_CBC_SHA = { 0x00, 0xXX }; CipherSuite TLS_DHE_RSA_OAEP_WITH_AES_256_CBC_SHA = { 0x00, 0xXX }; And so on.. This means you can have a path to migrate software over from PKCS#1 padding to OAEP as they see fit. When products catch up, you can quietly deprecate the PKCS#1 padding. Just a thought. -- Dean Povey, | e-m: povey@dstc.edu.au | JCSI: Java Crypto Toolkit Research Scientist | ph: +61 7 3864 5120 | uPKI: C PKI toolkit for embedded Security Unit, DSTC | fax: +61 7 3864 1282 | systems Brisbane, Australia | www: security.dstc.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 May 31 04:27:38 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18675 for ; Thu, 31 May 2001 04:27:32 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 Date: Thu, 31 May 2001 10:26:37 +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 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <003b01c0e9ab$6a675450$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > I'd like to hear an argument as to why MACing before encrypting is > a problem. It's relatively standard practice. That is based on a remark made by Hugo Krawczyk at his EuroCrypt 2001 presentation "Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels." I quickly glanced over the paper but could not find a mention of the problem. I suppose this will be covered in his Crypto 2001 paper "The Order Of Encryption And Authentication For Protecting Communications (Or: How Secure Is SSL?)." I have not read it but it sure sounds relevant to us, at least as a theoretical weakness. > What's wrong with the PRF function? Some people on the list have argued that it is unneccessarily complex and I tend to agree. > Computational or bandwidth overhead? Bandwidth. Computational would be nice, but I do not see a way to achieve that. 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 Thu May 31 06:59:34 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19835 for ; Thu, 31 May 2001 06:59:33 -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-01.txt Date: Thu, 31 May 2001 06:59:20 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200105311059.GAA19783@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-01.txt Pages : 4 Date : 30-May-01 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. Please send comments on this document to the TLS mailing list A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-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-ietf-tls-camellia-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-ietf-tls-camellia-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: <20010530130729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-camellia-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-camellia-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010530130729.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 Thu May 31 08:54:04 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22901 for ; Thu, 31 May 2001 08:54:02 -0400 (EDT) Date: Thu, 31 May 2001 13:54:11 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" 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 david.hopwood@zetnet.co.uk on Thu, May 31, 2001 at 12:38:36AM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010531135411.E2019@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net David Hopwood wrote: > Using OAEP with TLS makes effectively no difference to the provable > security properties of the RSA ciphersuites, assuming that the > method described in section 7.4.7.1 of RFC 2246 is followed > (i.e. the premaster secret is replaced with a random value whenever > the PKCS #1 v1.5 block is invalid). Yes. If the existing TLS padding scheme was vulnerable to attack I would agree that it should be updated immediately. As it is I don't see any real urgency although it is something that we should aim towards. For that reason I tend to favour switching for TLS 1.1, but not doing anything specifically for AES. > The disadvantage of switching to OAEP, is that firmware for TLS > hardware accelerators would probably have to be changed. For that > reason I would not be in favour of switching, at least for the AES > ciphersuites. This is a good point. I think I would still favour switching for TLS 1.1 though. Standardising the way RSA is used does make things more elegant, although IMHO it is a fairly low priority. -- 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 May 31 11:08:15 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27906 for ; Thu, 31 May 2001 11:08:13 -0400 (EDT) Message-ID: From: Maureen.Stillman@nokia.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 Date: Thu, 31 May 2001 10:08:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 agree with Eric. There is no need to increment the version number for TLS in order to add the dns_name extension and the wireless extensions. These extensions are all backwards compatible. It is possible to communicate between a client that supports the extensions and a server that does not and vice versa. As they are all optional features no vendor's web server or browser currently supporting TLS 1.0 will break as a result of them. The latest I-D will be out soon from Simon Blake-Wilson and Magnus Nystrom and it will present the technical details on how this is achieved. I would like to see these extensions in TLS 1.0. -- maureen Maureen Stillman Nokia Member of Scientific Staff Voice: (607)273-0724 x62 Internet Commerce Enhancement Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman@nokia.com www.nokia.com -----Original Message----- From: ext Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Thursday, May 31, 2001 1:12 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] RE: On doing TLS 1.1 "Joseph Hui" writes: > If we reserve 1.1 for the grandiose, then there arises the need for > 1.0 plus or 1.0.whatever to cram in the urgently needed features, > such as the dns_name extension. However, I recall sound arguments > were made in the past that if we don't increment the version number > (for instituting such features), then web servers and browsers that > are now TLS 1.0 compatible will suddenly become TLS 1.0 incompatible > and their vendors/custodians will thus squawk, rightfully so, > because of the confusion. We can't make these features MUSTs for TLS 1.0, but the point of extensions is that you can implement them or not as you choose. It won't cause any problem to add these as optional extensions to 1.0 -Ekr --- You are currently subscribed to ietf-tls as: Maureen.Stillman@nokia.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 From bounce-ietf-tls-3458737@lists.certicom.com Thu May 31 11:08:43 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27931 for ; Thu, 31 May 2001 11:08:42 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 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: 31 May 2001 08:15:09 -0700 In-Reply-To: "Andreas Sterbenz"'s message of "Thu, 31 May 2001 10:26:37 +0200" Message-ID: Lines: 16 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 "Andreas Sterbenz" writes: > > What's wrong with the PRF function? > Some people on the list have argued that it is unneccessarily complex and I > tend to agree. Unfortunately, the reason it's so complex is that it was provided to us by Hugo's group and is therefore allegedly free of theoretical weaknesses. :( > > Computational or bandwidth overhead? > Bandwidth. Computational would be nice, but I do not see a way to achieve > that. Neither do I. OTOH, The only way to save a significant amount of bandwidth is MAC truncation. -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 May 31 11:18:45 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28296 for ; Thu, 31 May 2001 11:18:44 -0400 (EDT) Date: Thu, 31 May 2001 16:18:53 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" 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 povey@dstc.qut.edu.au on Thu, May 31, 2001 at 04:24:39PM +1000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010531161853.F4120@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Dean Povey wrote: > I have been lurking so I may have missed all the issues. Isn't the > simplest solution to just consider RSA-OAEP a different algorithm to > RSA (w/PKCS#1 pad), keep the existing identifiers and add the > following: Yes this would work I guess. This would probably be done best with a separate RFC, since there is no reason to restrict ourselves to OAEP with AES. OAEP variants could be defined for any ciphersuites that we were interested in. -- 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 May 31 11:43:37 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29177 for ; Thu, 31 May 2001 11:43:36 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 Date: Thu, 31 May 2001 17:43:18 +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 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <01a901c0e9e8$6a8c54c0$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > > Computational or bandwidth overhead? > > Bandwidth. Computational would be nice, but I do not see a way to achieve > > that. > Neither do I. OTOH, The only way to save a significant amount of > bandwidth is MAC truncation. Yes and no. I see two places to save bandwidth in addition to MAC truncation: (a) the record version number, which serves no particular purpose except in the initial hello messages and (b) block cipher padding. For AES average padding length is 8.5 bytes which could be reduces to 0 by using counter mode or cipher text stealing mode. Combined that is an average saving of 10.5 byte per record in case of a 128 bit block cipher, which is not too bad. Please note that I will be out of the office for three weeks starting tomorrow and may not be able discuss this further during that time. 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 Thu May 31 12:39:48 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01306 for ; Thu, 31 May 2001 12:39:43 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 31 May 2001 11:35:43 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Cc: jis@mit.edu, mleech@nortelnetworks.com 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: <5.0.1.4.2.20010531110502.01e77908@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net David: I fear that you are missing the point of my posting. I strongly believe that the IETF Security Area should be moving toward a common set of security mechanisms. I gave a presentation at the August 2000 SAAG meeting with this same message. To add support for AES, all vendors must open up their crypto software, so this provides a unique opportunity to adjust other algorithms in the ciphersuite. I am not disputing the countermeasures that make PKCS#1 v1.5 safe. I am not advocating new techniques. The recent work by Victor Shoup is very interesting, and it might become a standard. However, I would not recommend adopting it until the ISO working group has finished their work. As we all know, a sound submission to a standards development process usually gets altered in some way. On the other hand, RSA-OAEP is being used in many areas. VISA and Master Card were probably the early adopters in SET. Since then, there has been considerable activity involving RSA-OAEP. IEEE Std 1363-2000 includes RSA-OAEP. The current draft of ANSI X9.44 includes RSA-OAEP. Japan's Cryptrec project is reviewing RSA-OAEP. There are probably others that I am not ware of. I am proposing a well studied, and reasonably well adopted technique as the successor to PKCS#1 v1.5 for TLS. I am proposing an evolution to a stronger mechanism, in the same way that we are evolving to the stronger symmetric cipher. We have an opportunity to adopt AES and RSA-OAEP across the entire IETF Security Area. We should not miss this opportunity. Russ >"Housley, Russ" wrote: > > On the 8th of May, I requested that RSA-OAEP be used with AES. The > > proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I would like > > to see this changed. > >Using OAEP with TLS makes effectively no difference to the provable security >properties of the RSA ciphersuites, assuming that the method described in >section 7.4.7.1 of RFC 2246 is followed (i.e. the premaster secret is replaced >with a random value whenever the PKCS #1 v1.5 block is invalid). > >The effect of that method is to prevent chosen ciphertext attacks in much >the same way as the "Simple RSA" scheme described in [Shoup01], which has >a tighter reduction from the RSA problem than OAEP does. To get the same >tightness of reduction when using OAEP in TLS, you would still have to >require that no information is leaked about whether the decryption of the >premaster secret succeeds or not. > >The disadvantage of switching to OAEP, is that firmware for TLS hardware >accelerators would probably have to be changed. For that reason I would not >be in favour of switching, at least for the AES ciphersuites. Instead, the >RSA AES ciphersuites should say that the method in section 7.4.7.1 of >RFC 2246 MUST be followed. > >(Note that currently, not all TLS implementations use that method. For >example, last time I looked, OpenSSL just checked for additional redundancy, >which makes Bleichenbacher's attack more difficult, but is not provably >secure.) > >[Shoup01] Victor Shoup, > "A Proposal for an ISO Standard for Public Key Encryption," > February 13, 2001. > Available from http://www.shoup.net/papers/ or > http://citeseer.nj.nec.com/shoup01proposal.html > >- -- >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 May 31 12:53:55 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01847 for ; Thu, 31 May 2001 12:53:53 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" 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: 31 May 2001 10:00:17 -0700 In-Reply-To: David Hopwood's message of "Thu, 31 May 2001 00:38:36 +0100" Message-ID: Lines: 12 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: > The disadvantage of switching to OAEP, is that firmware for TLS hardware > accelerators would probably have to be changed. David, Due to the need to check the TLS version number and the SSLv2-rollback protection padding, don't most implementations simply do a raw RSA operation and then unpad in software? Do you know of an accelerator that forbids this? -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 May 31 14:21:17 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04944 for ; Thu, 31 May 2001 14:21:15 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Cc: IETF Transport Layer Security WG Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Thu, 31 May 2001 14:10:12 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" 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: <5.0.1.4.2.20010531140805.01ed7398@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Pete: > > Using OAEP with TLS makes effectively no difference to the provable > > security properties of the RSA ciphersuites, assuming that the > > method described in section 7.4.7.1 of RFC 2246 is followed > > (i.e. the premaster secret is replaced with a random value whenever > > the PKCS #1 v1.5 block is invalid). > >Yes. If the existing TLS padding scheme was vulnerable to attack I >would agree that it should be updated immediately. As it is I don't >see any real urgency although it is something that we should aim >towards. For that reason I tend to favour switching for TLS 1.1, but >not doing anything specifically for AES. > > > The disadvantage of switching to OAEP, is that firmware for TLS > > hardware accelerators would probably have to be changed. For that > > reason I would not be in favour of switching, at least for the AES > > ciphersuites. > >This is a good point. I think I would still favour switching for TLS >1.1 though. Standardising the way RSA is used does make things more >elegant, although IMHO it is a fairly low priority. Since you believe that RSA-OAEP should be used in the future, why not define both PKCS#1 v1.5 and OAEP now, and warn implementors that the switch is coming. This will allow a transition period. Russ --- 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 May 31 15:33:19 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06918 for ; Thu, 31 May 2001 15:33:17 -0400 (EDT) Message-ID: Date: Thu, 31 May 2001 17:59:14 +0100 From: David Hopwood 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: WG Last Call for "AES Ciphersuites for TLS" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B167862.DA028A47@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Dean Povey wrote: > >"Housley, Russ" wrote: > >> On the 8th of May, I requested that RSA-OAEP be used with AES. The > >> proposed ciphersuite does not use RSA-OAEP (see RFC 2347), and I > >> would like to see this changed. > > > > I have been lurking so I may have missed all the issues. Isn't the > simplest solution to just consider RSA-OAEP a different algorithm to > RSA (w/PKCS#1 pad), keep the existing identifiers and add the following: > > CipherSuite TLS_RSA_OAEP_WITH_AES_128_CBC_SHA = { 0x00, 0xXX }; > CipherSuite TLS_DH_RSA_OAEP_WITH_AES_128_CBC_SHA = { 0x00, 0xXX }; > CipherSuite TLS_DHE_RSA_OAEP_WITH_AES_128_CBC_SHA = { 0x00, 0xXX }; > CipherSuite TLS_RSA_OAEP_WITH_AES_256_CBC_SHA = { 0x00, 0xXX }; > CipherSuite TLS_DH_RSA_OAEP_WITH_AES_256_CBC_SHA = { 0x00, 0xXX }; > CipherSuite TLS_DHE_RSA_OAEP_WITH_AES_256_CBC_SHA = { 0x00, 0xXX }; The DH[E]_RSA ciphersuites use RSA signing, not encryption. (There are theoretical security problems with the RSA signing used in TLS, especially with respect to resistance to compromise of hardware-based implementations, but that's an entirely different issue, that I think should probably be fixed in TLS 1.1.) In any case, I don't see the point of adding TLS_RSA_OAEP_*. From a provable security point of view, I re-iterate that RSA-OAEP in TLS would be no more secure than PKCS #1 v1.5 with the fix from section 7.4.7.1 of RFC 2246. - -- 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 iQEVAwUBOxZ4STkCAxeYt5gVAQHjBgf/TQNDBs1P2FpkF9+LW3dEVNGE9CvXFzQp BCRnTwzQ+qvMB9Qav0vBG/WHGSYjkmZq8p7705rEPOPXsVpt1GJm32+hcQwd/02V 59wiJjxkKt/EoF7wz8Zqf6ZaFdylDOohROQcIgRnutz80wRgbyxdBP8ifYlCkcu7 9UJubkKZ0jRTzxuezl11v5+QL7U0Sukxix8iqtl3SK/RrDmjFWvNBiN+ips64nhj 5u0nZ1MdZOWOXpHuDj20Ve+ZTWscSty+1vDLlTTghYJZDD20zVonKxNzpQuuarZT HgLj/px9eNjbFGFgh4d5a6QNzYkQkNeFvbov+auWJLom1Pjv5ddXxQ== =ekur -----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 May 31 22:25:20 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12972 for ; Thu, 31 May 2001 22:25:19 -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-01.txt Date: Fri, 01 Jun 2001 11:25:22 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106010225.LAA13244@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net David, Thank you for your comments. >We don't believe that proprietary algorithms should be added to the TLS >standard. I agree with you on that point. So we have decided to grant royalty-free licenses for the essential patents of Camellia. Camellia is being extensively scrutinized as well as AES. For example, it is being reviewed in the NESSIE project (http://cryptonessie.org). Camellia is also relatively efficient to implement, even for small systems (We have compared its performance to the results in Report on the Development of the Advanced Encryption Standard (AES) James Nechvatal, Elaine Barker, Lawrence Bassham, William Burr, Morris Dworkin, James Foti, Edward Roback Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Technology Administration U.S. Department of Commerce Publication Date: October 2, 2000), and will be widely available in both hardware and software implementations. Camellia is a candidate of the cryptographic techniques to be used in the electronic government system of Japan, and we NEED TLS to support Camellia soon. Our proposal also gives a new option, an efficient 128-bit block cipher that is royalty-free! Since the only such cipher currently available is AES, our actions with regard to Camellia should be well received. I hope our proposal will be accepted in TLS 1.1. Shiho -------------------------------------------- Shiho Moriai NTT Laboratories Information Security Project 1-1 Hikarinooka, Yokosuka, 239-0847, Japan -------------------------------------------- >Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt >From: David Blaker >Date: Thu, 31 May 2001 08:59:20 -0400 > >We don't believe that proprietary algorithms should be added to the TLS >standard. AES with 128 and 256 bit keys should be more than sufficient. AES >has been extensively scrutinized, is relatively efficient to implement, even >for small systems (see Report on the Development of the Advanced Encryption >Standard (AES) James Nechvatal, Elaine Barker, Lawrence Bassham, William >Burr, Morris Dworkin, James Foti, Edward Roback Computer Security Division >Information Technology Laboratory National Institute of Standards and >Technology Technology Administration U.S. Department of Commerce Publication >Date: October 2, 2000), and will be widely available in both hardware and >software implementations. This position would also be consistent with the >IPSec WG. >_________________________________________ >David Blaker, CTO >NetOctave, Inc. >P.O. Box 14824 >Research Triangle Park, NC 27709 >Phone (919) 463-9903 x.206 / Fax (919) 463-9905 >email mailto:dblaker@netoctave.com >website http://www.netoctave.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 May 31 23:16:19 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14408 for ; Thu, 31 May 2001 23:16:18 -0400 (EDT) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "Thu, 31 May 2001 08:59:20 -0400." Date: Fri, 01 Jun 2001 12:16:30 +0900 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: <200106010316.MAA20184@blue.h2np.net> X-List-Host: SKYLIST.net > We don't believe that proprietary algorithms should be added to the > TLS standard. Camellia has the royalty-free licenses for the essential patents of Camellia. So, I can write and distribute the Camellia codes with GNU Public License. Because English language is not my mother tongue, actually I don't know good English expression but it wouldn't be called "proprietary algorithms". > AES with 128 and 256 bit keys should be more than sufficient. I don't think so. In the next generation of TLS, old-TLS's all block-ciphers should be replaced AES style block-ciphers, 128bit block / 128, 192, 256bit key length AES, I mean Rijndael, is a pretty good. But I need another(or more) strong cipher(s) as backup algorithms or use's choice (because I'm a security paranoia!). I have been thinking that Camellia is a good choice to use TLS. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://www.pp.iij4u.or.jp/~h2np/ --- 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