From bounce-ietf-tls-3458737@lists.certicom.com Mon Jul 2 10:57: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 KAA11249 for ; Mon, 2 Jul 2001 10:57:14 -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-srp-01.txt Date: Mon, 02 Jul 2001 10:56:50 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200107021456.KAA10953@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 : Using SRP for TLS Authentication Author(s) : D. Taylor Filename : draft-ietf-tls-srp-01.txt Pages : 13 Date : 29-Jun-01 This memo presents a technique for using the SRP (Secure Remote Password) protocol as an authentication method for the TLS (Transport Layer Security) protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-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-srp-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-srp-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: <20010629141606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010629141606.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 Mon Jul 2 11:20:22 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28847 for ; Mon, 2 Jul 2001 11:20:20 -0400 (EDT) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-srp-01.txt Date: Mon, 2 Jul 2001 17:19:40 +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: <016f01c1030a$6a4a8730$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I do not recall if this was discussed before, but I am not sure if there is a good reason for including HMAC-MD5 ciphersuites. I think it would make more sense to define one (or more) SRP with AES ciphersuites and 128 (192? / 256?) bit keys. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----- Original Message ----- From: To: "IETF Transport Layer Security WG" Cc: Sent: Monday, July 02, 2001 4:56 PM Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-srp-01.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Using SRP for TLS Authentication > Author(s) : D. Taylor > Filename : draft-ietf-tls-srp-01.txt > Pages : 13 > Date : 29-Jun-01 > > This memo presents a technique for using the SRP (Secure Remote > Password) protocol as an authentication method for the TLS > (Transport Layer Security) protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-01.txt --- 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 Jul 4 15:50: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 PAA10850 for ; Wed, 4 Jul 2001 15:50:29 -0400 (EDT) Message-ID: From: "Mark Nottingham" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Date: Wed, 4 Jul 2001 19:50:53 -0800 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.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <042801c10505$b02d51e0$8401a8c0@mnotlaptop> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit There's a difference between jumping between what are perceived as two different protocols (even though they're similar) and jumping versions (especially away from 1.0). Yes, this is just a perception thing, but that's part of what versioning is about. Also, I'm concerned about user identification of the capabilities of a browser or other product; I'm not too optimistic about MS or anyone else clearly labeling their product as "TLS plus extensions foo, bar and baz"; while they'll be more apt to state "TLS 1.1" once they're compliant. In the case of dns_name, CDNs will want to use it ASAP. If some clients are clearly labeled (as above), CDN and other virtual hosters can have their customers specify the use of such browsers; otherwise, there will be significant overhead in identifying the appropriate products to use. Cheers, > > Rationale: a version rev is more visible, and more likely to get wide > > adoption in clients, which is needed to make dns_name worthwhile. > > I don't find this rationale particularly convincing. In my > experience, implementors feel almost no pressure to upgrade their > implementations to newer versions. Look how long it took Microsoft > and Netscape to upgrade from SSLv3 to TLS. > > If there's a lot of market demand for dns_name then implementors > will put it in whether it's a new version or not. If there's no > demand then incrementing the version number will make almost > no difference. --- 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 Jul 4 18:12:05 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 SAA12057 for ; Wed, 4 Jul 2001 18:12:04 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London 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 Jul 2001 15:19:24 -0700 In-Reply-To: "Mark Nottingham"'s message of "Wed, 4 Jul 2001 19:50:53 -0800" Message-ID: Lines: 23 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 "Mark Nottingham" writes: > There's a difference between jumping between what are perceived as two > different protocols (even though they're similar) and jumping versions > (especially away from 1.0). Yes, this is just a perception thing, but that's > part of what versioning is about. I agree that there is a difference but I think you've got it backwards. Customers are a lot more sensitive to full version upgrades than minor upgrades. They're a lot more likely to say "I want TLS" than "I want v 1.1". > In the case of dns_name, CDNs will want to use it ASAP. If some clients are > clearly labeled (as above), CDN and other virtual hosters can have their > customers specify the use of such browsers; otherwise, there will be > significant overhead in identifying the appropriate products to use. I don't buy this. The way you specify which browsers to use is by naming the versions, not by saying "you must have TLS 1.1". The overhead of determining which clients support these extensions is relatively trivial. -Ekr [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 Jul 5 09:28: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 JAA11694 for ; Thu, 5 Jul 2001 09:28:38 -0400 (EDT) Date: Thu, 5 Jul 2001 15:29:05 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from mnot@akamai.com on Wed, Jul 04, 2001 at 07:50:53PM -0800 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010705152904.I13399@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Wed, Jul 04, 2001 at 07:50:53PM -0800, Mark Nottingham wrote: > There's a difference between jumping between what are perceived as two > different protocols (even though they're similar) and jumping versions > (especially away from 1.0). Yes, this is just a perception thing, but that's > part of what versioning is about. > > Also, I'm concerned about user identification of the capabilities of a > browser or other product; I'm not too optimistic about MS or anyone else > clearly labeling their product as "TLS plus extensions foo, bar and baz"; > while they'll be more apt to state "TLS 1.1" once they're compliant. The extensions are mostly optional -- the client is not obliged to generate them, and the server can ignore them except that it must abort the handshake if server_hello_extension_list does not parse correctly. So "TLS 1.1 compliancy" wouldn't mean a lot. Internal version numbers, such as { 3, 1 } for TLS 1.0, are important for protocol negotiation. There is no need to use anything other than { 3, 1 } for using TLS extensions as proposed in draft-ietf-tls-extensions-00.txt. Of course we could declare that { 3, 1 } denotes both TLS 1.0 (if used without extensions) and TLS 1.1 (if used with extensions), but I think this is pointless. Using a new internal version number such as { 3, 2 } would make things unnecessarily complicated. There is no need to increment the version number unless we are doing incompatible changes. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 5 15:29:50 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 PAA24594 for ; Thu, 5 Jul 2001 15:29:47 -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: London Date: Thu, 5 Jul 2001 12:31:12 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcEFVp7fE2CKFUE9R4Kpxhyvmq1dTgAGZcTQ 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 PAA24594 Incrementing the minor number may complicate whatever somehow. But it would certainly "uncomplicate" to great extent the task of convincing browser/server vendors to adopt dns_name quickly. The fact of matter is: the vendors are not direct beneficiaries of dns_name, so they need some extra incentives to move. If we can't tempt them with greed (as all browsers are free), then fear -- the fear of falling behind one TLS revision -- is the obvious alternative. I'd like to remind ourselves, in the final analysis, the issue is not so much about potential complication, necessary or unnecessary, but about prompt dns_name adoption. Vendors will do what needs to be done. It so happens that we're now in the position to articulate the need. So let's not blow it. If we don't make dns_name a big deal to the vendors the first time we may not get a second chance. Squeaky wheels get more oil. Let's make it big and keep it simple, so vendors and end users are not burdened with caveats and stipulations. Seems to me incrementing the rev# will help the cause, so I'm for it. We've been in this neighborhood twice before and gotten nowhere. Perhaps this time, before jumping straight to the rev# decision, we first try characterizing dns_name as: 1) a bug fix (for TLS 1.0), 2) a new functionality (of TLS); or 3) a new feature (of an existing functionality). If we can agree on the characterization, then the answer to the rev# question should arrive accordingly. Regards, Joe Hui Digital Island ==================================================================== -----Original Message----- From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] Sent: Thursday, July 05, 2001 6:29 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: London On Wed, Jul 04, 2001 at 07:50:53PM -0800, Mark Nottingham wrote: > There's a difference between jumping between what are perceived as two > different protocols (even though they're similar) and jumping versions > (especially away from 1.0). Yes, this is just a perception thing, but that's > part of what versioning is about. > > Also, I'm concerned about user identification of the capabilities of a > browser or other product; I'm not too optimistic about MS or anyone else > clearly labeling their product as "TLS plus extensions foo, bar and baz"; > while they'll be more apt to state "TLS 1.1" once they're compliant. The extensions are mostly optional -- the client is not obliged to generate them, and the server can ignore them except that it must abort the handshake if server_hello_extension_list does not parse correctly. So "TLS 1.1 compliancy" wouldn't mean a lot. Internal version numbers, such as { 3, 1 } for TLS 1.0, are important for protocol negotiation. There is no need to use anything other than { 3, 1 } for using TLS extensions as proposed in draft-ietf-tls-extensions-00.txt. Of course we could declare that { 3, 1 } denotes both TLS 1.0 (if used without extensions) and TLS 1.1 (if used with extensions), but I think this is pointless. Using a new internal version number such as { 3, 2 } would make things unnecessarily complicated. There is no need to increment the version number unless we are doing incompatible changes. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658. html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 5 16:51:25 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 QAA27225 for ; Thu, 5 Jul 2001 16:51: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: London Date: Thu, 5 Jul 2001 13:52:51 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcEE1pV2vRqBTqYJTTaVruqhwdv+4gAvHYdg 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 QAA27225 What we need, IMHO, is a sound bite that can succinctly communicate to the end users. "You need the dns_name patch" (not unlike the "you need the 128-bit patch" (for IE 5, e.g.)) would work well. "You need a TLS 1.1 compliant browser" might work better, I think. Joe Hui Digital Island ================================ -----Original Message----- From: Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Wednesday, July 04, 2001 3:19 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: London "Mark Nottingham" writes: > There's a difference between jumping between what are perceived as two > different protocols (even though they're similar) and jumping versions > (especially away from 1.0). Yes, this is just a perception thing, but that's > part of what versioning is about. I agree that there is a difference but I think you've got it backwards. Customers are a lot more sensitive to full version upgrades than minor upgrades. They're a lot more likely to say "I want TLS" than "I want v 1.1". > In the case of dns_name, CDNs will want to use it ASAP. If some clients are > clearly labeled (as above), CDN and other virtual hosters can have their > customers specify the use of such browsers; otherwise, there will be > significant overhead in identifying the appropriate products to use. I don't buy this. The way you specify which browsers to use is by naming the versions, not by saying "you must have TLS 1.1". The overhead of determining which clients support these extensions is relatively trivial. -Ekr [Eric Rescorla ekr@rtfm.com] http://www.rtfm.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 Jul 5 17:13:51 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 RAA27725 for ; Thu, 5 Jul 2001 17:13:51 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London 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 Jul 2001 13:45:53 -0700 In-Reply-To: "Joseph Hui"'s message of "Thu, 5 Jul 2001 12:31:12 -0700" 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 "Joseph Hui" writes: > Incrementing the minor number may complicate whatever somehow. > But it would certainly "uncomplicate" to great extent the task > of convincing browser/server vendors to adopt dns_name quickly. > The fact of matter is: the vendors are not direct beneficiaries > of dns_name, so they need some extra incentives to move. > If we can't tempt them with greed (as all browsers are free), > then fear -- the fear of falling behind one TLS revision -- is > the obvious alternative. I see no reason to believe that incrementing the version number will have this effect. Perhaps the representatives from Microsoft and Netscape would be so good as to offer an opinion here. -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 Jul 9 07:08:11 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 HAA09289 for ; Mon, 9 Jul 2001 07:08:11 -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-ntru-00.txt Date: Mon, 09 Jul 2001 07:07:47 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200107091107.HAA09260@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 : NTRU Cipher Suites for TLS Author(s) : A. Singer Filename : draft-ietf-tls-ntru-00.txt Pages : 15 Date : 06-Jul-01 This document defines a group of new TLS cipher suites that utilize the NTRU encryption algorithm and the NSS signature algorithm. These cipher suites are designed to maximize computational efficiency on both the client and server sides and ease deployment of the TLS protocol on constrained and embedded devices. The document assumes the reader is familiar with the TLS protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ntru-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-ntru-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-ntru-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: <20010706135254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ntru-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ntru-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010706135254.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 Mon Jul 9 07:08:12 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 HAA09291 for ; Mon, 9 Jul 2001 07:08:11 -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-04.txt Date: Mon, 09 Jul 2001 07:07:42 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200107091107.HAA09244@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-04.txt Pages : 9 Date : 06-Jul-01 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-04.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-04.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-04.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: <20010706135244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ciphersuite-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ciphersuite-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010706135244.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 Mon Jul 9 11:56: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 LAA19489 for ; Mon, 9 Jul 2001 11:56:26 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-ntru-00.txt In-reply-to: Message from Internet-Drafts@ietf.org of 9 Jul 2001 7:07:47 EDT Date: Mon, 09 Jul 2001 11:54:07 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107091554.f69Fs7R24468@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net You may have seen the NTRU ciphersuite draft by now. At the moment, I don't expect this to be a standards-track document, but we may choose to publish it as Informational. 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 Tue Jul 10 07:22:18 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26647 for ; Tue, 10 Jul 2001 07:22:17 -0400 (EDT) Importance: Normal MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] draft-ietf-tls-ntru-00.txt CipherSuite conflict X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 From: "Paul V Ford-Hutchinson" Message-ID: Date: Tue, 10 Jul 2001 11:46:34 +0100 X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.6 |December 14, 2000) at 10/07/2001 11:46:34, Serialize complete at 10/07/2001 11:46:34 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 I notice that there is a conflict in the CipherSuite namespace between the NTRU draft and the expired draft-ietf-tls-56bit-ciphersiutes-00.txt - dated April 13th 1999. The new Draft defines: CipherSuite TLS_NTRU_NSS_WITH_RC4_128_SHA = { 0x00, 0x61 } CipherSuite TLS_NTRU_NSS_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x62 } CipherSuite TLS_NTRU_NSS_WITH_AES_128_CBC_SHA = { 0x00, 0x63 } CipherSuite TLS_NTRU_NSS_WITH_AES_256_CBC_SHA = { 0x00, 0x64 } CipherSuite TLS_NTRU_RSA_WITH_RC4_128_SHA = { 0x00, 0x65 } CipherSuite TLS_NTRU_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x66 } CipherSuite TLS_NTRU_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x67 } CipherSuite TLS_NTRU_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x68 } The expired one defines: CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 }; CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 }; CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 }; CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 }; CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 }; I guess that this in itself is not an issue, however, OpenSSL has these defined in its' code /* Additional TLS ciphersuites from draft-ietf-tls-56-bit-ciphersuites-00.txt * (available if TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES is defined, see * s3_lib.c). We actually treat them like SSL 3.0 ciphers, which we probably * shouldn't. */ #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5 0x03000060 #define TLS1_CK_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 0x03000061 #define TLS1_CK_RSA_EXPORT1024_WITH_DES_CBC_SHA 0x03000062 #define TLS1_CK_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA 0x03000063 #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_SHA 0x03000064 #define TLS1_CK_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA 0x03000065 #define TLS1_CK_DHE_DSS_WITH_RC4_128_SHA 0x03000066 to compound this, the following line is just above #define TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES 1 and. indeed, a vanilla openssl install returns the following from the "$ openssl ciphers -cipherlist EXPORT1024" command EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EXP1024-RC4-MD5 Apart from any procedural issues about implementing drafts etc... I think there are two questions: 1) can we move the NTRU specs out of conflict ? 2) is publishing an RFC really the best way to reserve CipherSuite specs ? Cheers, Paul -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html --- 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 Jul 10 08:31:24 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 IAA27633 for ; Tue, 10 Jul 2001 08:31:24 -0400 (EDT) Message-ID: Date: Tue, 10 Jul 2001 12:43:11 +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: draft-ietf-tls-ntru-00.txt CipherSuite conflict 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: <3B4AEA4F.8EC99A36@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Paul V Ford-Hutchinson wrote: > > I notice that there is a conflict in the CipherSuite namespace between the > NTRU draft and the expired > draft-ietf-tls-56bit-ciphersiutes-00.txt - dated April 13th 1999. > [stuff deleted] > > I guess that this in itself is not an issue, however, OpenSSL has these > defined in its' code > > /* Additional TLS ciphersuites from > draft-ietf-tls-56-bit-ciphersuites-00.txt > * (available if TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES is defined, see > * s3_lib.c). We actually treat them like SSL 3.0 ciphers, which we > probably > * shouldn't. */ > #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5 0x03000060 > #define TLS1_CK_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 0x03000061 > #define TLS1_CK_RSA_EXPORT1024_WITH_DES_CBC_SHA 0x03000062 > #define TLS1_CK_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA 0x03000063 > #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_SHA 0x03000064 > #define TLS1_CK_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA 0x03000065 > #define TLS1_CK_DHE_DSS_WITH_RC4_128_SHA 0x03000066 > > to compound this, the following line is just above > > #define TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES 1 > > and. indeed, a vanilla openssl install returns the following from the "$ > openssl ciphers -cipherlist EXPORT1024" command > > EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EXP1024-RC4-MD5 > Its not just OpenSSL that implements these. They are also implemented in Netscape and MSIE. 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 Jul 10 09:09:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28383 for ; Tue, 10 Jul 2001 09:09:05 -0400 (EDT) Importance: Normal MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 From: "Paul V Ford-Hutchinson" Message-ID: Date: Tue, 10 Jul 2001 14:08:44 +0100 X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.6 |December 14, 2000) at 10/07/2001 14:08:44, Serialize complete at 10/07/2001 14:08:44 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 Dr Stephen Henson Wrote: >Its not just OpenSSL that implements these. They are also >implemented in Netscape and MSIE. I wasn't trying to point a finger, just trying to explain that this wasn't an academic discussion, as there already was a major player in the SSL/TLS world which had ciphersuites enabled that conflict directly with a draft just published by the tls w/g. (BTW my IE and NS seem to only advertise 62 and 64 from this list) It seems to me that the act of registering number(s) for a ciphersuite should be more port number-esque. Having seemingly sensible values in Internet Drafts can only cause confusion, no matter how many disclaimers are above or below. Especially in cases like this, where the draft (draft-ietf-tls-56-bit-ciphersuites-00.txt) died so long ago (is there any reason why it didn't become Informational ?) but has been widely implemented. Cheers, Paul -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html --- 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 Jul 10 09:43:50 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 JAA29199 for ; Tue, 10 Jul 2001 09:43:50 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 10 Jul 2001 09:44:05 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict 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.20010710094324.02206b48@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Given the wide deployment, it seems that an Informational RFC is appropriate. Russ At 02:08 PM 7/10/2001 +0100, Paul V Ford-Hutchinson wrote: >It seems to me that the act of registering number(s) for a ciphersuite >should be more port number-esque. Having seemingly sensible values in >Internet Drafts can only cause confusion, no matter how many disclaimers >are above or below. Especially in cases like this, where the draft >(draft-ietf-tls-56-bit-ciphersuites-00.txt) died so long ago (is there >any reason why it didn't become Informational ?) but has been widely >implemented. --- 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 Jul 10 10:09: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 KAA29848 for ; Tue, 10 Jul 2001 10:09:29 -0400 (EDT) Importance: Normal MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 From: "Paul V Ford-Hutchinson" Message-ID: Date: Tue, 10 Jul 2001 15:09:21 +0100 X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.6 |December 14, 2000) at 10/07/2001 15:09:19, Serialize complete at 10/07/2001 15:09:19 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 Russ Housley wrote: >Given the wide deployment, it seems that an Informational RFC > is appropriate. There's a copy here: http://www.ford-hutchinson.com/~fh-1-pfh/draft-ietf-tls-56-bit-ciphersuites-00.txt if anyone wants to adopt/revive it. Cheers, Paul -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html --- 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 Jul 10 14:46:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14220 for ; Tue, 10 Jul 2001 14:46:08 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict In-reply-to: Message from "Paul V Ford-Hutchinson" of 10 Jul 2001 14:08:44 BST Date: Tue, 10 Jul 2001 14:43:56 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107101843.f6AIhup23163@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thanks for the notes about the 56-bit ciphersuites--I missed that draft on my latest summary of assigned numbers. We'll assign new ones for the NTRU draft, and I would like to see the 56-bit draft resurrected so we can take a look at it again. 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 Jul 11 05:42: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 FAA29115 for ; Wed, 11 Jul 2001 05:42:00 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict Date: Wed, 11 Jul 2001 19:46:57 +1000 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.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: <000b01c109ee$700b9c00$54448990@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > /* Additional TLS ciphersuites from > draft-ietf-tls-56-bit-ciphersuites-00.txt > * (available if TLS1_ALLOW_EXPERIMENTAL_CIPHERSUITES is defined, see > * s3_lib.c). We actually treat them like SSL 3.0 ciphers, which we > probably > * shouldn't. */ > #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5 0x03000060 draft-ietf-tls-srp-01.txt also uses 0x00 0x60: CipherSuite TLS_SRP_WITH_RC4_128_SHA = { 0x00,0x5C }; CipherSuite TLS_SRP_WITH_IDEA_CBC_SHA = { 0x00,0x5D }; CipherSuite TLS_SRP_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x5E }; CipherSuite TLS_SRP_WITH_RC4_128_MD5 = { 0x00,0x5F }; CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { 0x00,0x60 }; I wrote about this a few months back, but didn't seem to get any concrete answer on how to allocate cipher suite numbers in drafts. You have to put something in there while it's in draft form, otherwise implementations won't necessarily work together. Regards, David. --- 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 Jul 11 07:16: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 HAA00207 for ; Wed, 11 Jul 2001 07:16:15 -0400 (EDT) Importance: Normal MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 From: "Paul V Ford-Hutchinson" Message-ID: Date: Wed, 11 Jul 2001 12:08:19 +0100 X-MIMETrack: Serialize by Router on D06ML035/06/M/IBM(Release 5.0.6 |December 14, 2000) at 11/07/2001 12:16:01, Serialize complete at 11/07/2001 12:16:01 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 David Taylor Wrote: >> #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5 0x03000060 >draft-ietf-tls-srp-01.txt also uses 0x00 0x60: >CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { 0x00,0x60 }; > >I wrote about this a few months back, but didn't seem to get any concrete >answer on how to allocate cipher suite numbers in drafts. > >You have to put something in there while it's in draft form, otherwise >implementations won't necessarily work together. sure, and draft-ietf-tls-camellia-01.txt and draft-ietf-tls-ecc-01.txt both allocate 'x47' thru 'x4C' The purist view is that nothing should be set in stone until it goes RFC. Clearly this approach is broken. - there could be a process, like IANA port registration, where the reservation of a number is separate to the specification of the use of that number. This should ensure that there is no realistic probability of number re-use. - there could be a process where someone (Win ?) has to vet any draft that defines new CipherSuites (is it even possible to fit that into the I-D process ?) and Win has a master list . (this is pretty similar to the approach above - but with Win instead of IANA) - there could be an agreement that all drafts specify private ciphersuites (xFF xhh) until they get published as RFC (My guess is that we would lose the concept of private ciphersuites pretty quickly). - there could be an agreement that no draft specify any ciphersuite numbers. But I think that would lead to even greater confusion. - or we could decide that, after this heads-up, the problem is sufficiently well known by the groups that matter (NS, IE, OpenSSL, RSA, anyone else ?) that this won't happen again. Paul -- Paul Ford-Hutchinson : eCommerce application security : paulfordh@uk.ibm.com MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 462005 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html --- 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 Jul 11 14:59: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 OAA16120 for ; Wed, 11 Jul 2001 14:59:18 -0400 (EDT) Message-ID: Date: Wed, 11 Jul 2001 19:59:55 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict 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: <3B4CA22B.24B5D551@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Paul V Ford-Hutchinson wrote: > > David Taylor Wrote: > > >> #define TLS1_CK_RSA_EXPORT1024_WITH_RC4_56_MD5 0x03000060 > >draft-ietf-tls-srp-01.txt also uses 0x00 0x60: > >CipherSuite TLS_SRP_WITH_IDEA_CBC_MD5 = { 0x00,0x60 }; > > > >I wrote about this a few months back, but didn't seem to get any concrete > >answer on how to allocate cipher suite numbers in drafts. > > > >You have to put something in there while it's in draft form, otherwise > >implementations won't necessarily work together. > > sure, and draft-ietf-tls-camellia-01.txt and draft-ietf-tls-ecc-01.txt > both allocate 'x47' thru 'x4C' > > The purist view is that nothing should be set in stone until it goes RFC. > Clearly this approach is broken. > > - there could be a process, like IANA port registration, where the > reservation of a number is separate to the specification of the use of > that number. This should ensure that there is no realistic probability of > number re-use. > > - there could be a process where someone (Win ?) has to vet any draft > that defines new CipherSuites (is it even possible to fit that into the > I-D process ?) and Win has a master list . (this is pretty similar to > the approach above - but with Win instead of IANA) > > - there could be an agreement that all drafts specify private ciphersuites > (xFF xhh) until they get published as RFC (My guess is that we would lose > the concept of private ciphersuites pretty quickly). > > - there could be an agreement that no draft specify any ciphersuite > numbers. But I think that would lead to even greater confusion. > > - or we could decide that, after this heads-up, the problem is > sufficiently well known by the groups that matter (NS, IE, OpenSSL, RSA, > anyone else ?) that this won't happen again. Guess what? OpenSSL doesn't use the same numbers twice. But how does that help? It seems to me that you have two realistic alternatives: a) Register all numbers, regardless of their status b) Only allow experimental numbers that are _guaranteed_ to be reused for experimental ciphersuites. I vote for a), but it may require an address space extension, or at least a future provision for one. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jul 11 16:19:25 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 QAA18807 for ; Wed, 11 Jul 2001 16:19:24 -0400 (EDT) Message-ID: From: "Singer, Ari" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflic t Date: Wed, 11 Jul 2001 16:20:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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: <30F37C4533D8564FB1D58BFDAF6687C13FA1C1@OHTHREE.jjj-i.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi - I will be happy to change the ciphersuite numbers for the next draft of the NTRU-TLS document. > - there could be a process where someone (Win ?) has to vet > any draft > that defines new CipherSuites (is it even possible to fit > that into the > I-D process ?) and Win has a master list . (this is pretty > similar to > the approach above - but with Win instead of IANA) This makes the most sense to me and was the approach that I took when I submitted this draft. Since the chair must approve the drafts before they become official working group drafts, he can exercise some control over the numbers that get put into the drafts before they are published. That should also help us avoid running out of numbers. Would it be possible to have some kind of document made publicly available that includes the official working group approved ciphersuite numbers? I think as long as it is on the web somewhere and the working group (or Chair) is screening new submissions, it should avoid most of the future problems with this issue. > - or we could decide that, after this heads-up, the problem is > sufficiently well known by the groups that matter (NS, IE, > OpenSSL, RSA, > anyone else ?) that this won't happen again. My feeling is that no matter how well known it is, its better to put extra controls in place. Cheers, Ari Ari Singer, Principal Engineer NTRU 5 Burlington Woods Burlington, MA 01803 Main: (781) 418-2500 Personal: (781) 418-2515 Fax: (781) 418-2532 --- 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 Jul 11 16:49:08 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 QAA19728 for ; Wed, 11 Jul 2001 16:49:08 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-ntru-00.txt CipherSuite conflict 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 Jul 2001 07:18:21 -0700 In-Reply-To: "Paul V Ford-Hutchinson"'s message of "Tue, 10 Jul 2001 15:09:21 +0100" Message-ID: Lines: 7 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 V Ford-Hutchinson" writes: > http://www.ford-hutchinson.com/~fh-1-pfh/draft-ietf-tls-56-bit-ciphersuites-00.txt > > if anyone wants to adopt/revive it. I'd be willing to volunteer if noone elese wants to. -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 Jul 12 07: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 HAA01753 for ; Thu, 12 Jul 2001 07:06:35 -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-madhu-tls-spki-00.txt Date: Thu, 12 Jul 2001 07:06:23 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200107121106.HAA01672@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPKI Certificate Integration with Transport Layer Security (TLS) for Client Authentication and Authorization Author(s) : H. Madhusudhana, V. Ramachandran Filename : draft-madhu-tls-spki-00.txt Pages : 7 Date : 11-Jul-01 This document extends version 1.0 of the TLS specification [TLS] to support client SPKI certificates and associated public key algorithms, symmetric ciphers, hash algorithms and the appropriate trust model. The server is required to possess a X.509 certificate for authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-madhu-tls-spki-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-madhu-tls-spki-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-madhu-tls-spki-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: <20010711155803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-madhu-tls-spki-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-madhu-tls-spki-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010711155803.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 Jul 12 14:18:54 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 OAA00015 for ; Thu, 12 Jul 2001 14:18:54 -0400 (EDT) Message-ID: Date: Thu, 12 Jul 2001 11:19:05 -0700 From: thayes@netscape.com (Terry Hayes) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1+) Gecko/20010621 Netscape6/6.1b1 X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RSA-OAEP in draft-ietf-tls-ciphersuite-04 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B4DEA19.4040107@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Netscape would prefer that the current (PKCS #1 v1.5) RSA encryption mechanism is used in any new AES-based TLS ciphersuite. We do not think it is appropriate to change the algorithm at this late stage (at final call of the draft). The text from version -03 should be reinstated in this document. The current RSA encryption mechanism should be retained for the following reasons: 1. Deploying AES-based ciphersuites is the primary goal The AES block cipher provides a step up in security from 3DES including true 128 bit (and larger) keys, and a larger block size. At the same time, it provides increased performance across a wide set of platforms. The definitions of the AES ciphersuites should introduce only the new block cipher, not additional protocol or cryptographic mechanisms that would complicate or delay deployment of AES. If OAEP has benefits for TLS it should be introduced as a separate ciphersuite using an existing and established encryption mechanism such as 3DES. 2. RSA-OAEP is not required for security In message to this list on 31 May, David Hopwood said: "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." So it seems that OAEP adds no benefit for TLS, since the suggested method from RFC 2246 must be used in any case. 3. Adding RSA-OAEP adds complexity Requiring RSA-OAEP for the AES ciphersuites means that implementations will need to provide both RSA padding schemes. In some situations the extra code space and complexity won't be a problem, but some memory or performance contrained devices would be better off without both implemenations. It is unlikely that AES-only deployments will be possible in the near term, so devices will need to implement both old and new methods for interoperability reasons. 4. Adding RSA-OAEP delays implementation This requirement will delay the availability of the new ciphersuites for two reasons. First, the time to implement the OAEP padding will delay the availability of products with this capability. Second, testing independantly developed products will take longer since the interoperability of both OAEP and the AES cipher will need to be tested. 5. Adding RSA-OAEP delays adoption of AES in hardware devices Many services that use TLS rely on hardware devices to improve the performance of TLS or to provide additional security. These hardware devices will need to be updated to provide both the AES cipher, and the new RSA-OAEP encryption mechanism. Hardware updates are typically less frequent than updates for software packages, and 6. Alternatives to RSA (PKCS #1 v1.5) are available The current ID proposes ciphersuites that use either static or ephemeral Diffie-Hellman for key exchange. If a user is particularly concerned about attacks on PKCS #1 v1.5 (even though most experts agree that appropriate measures have already been taken), they can use one of the DH key exchange ciphersuites and avoid the question altogether. For these reasons, Netscape would prefer to use the existing PKCS #1 v1.5 padding for AES ciphersuites. Terry Hayes thayes@netscape.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 Jul 12 14:41:44 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 OAA03111 for ; Thu, 12 Jul 2001 14:41:43 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] Re: London Date: Thu, 12 Jul 2001 11:08:49 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcEFkpvqIWMb25jtSuqOFB4mygdLvgFW7sdA From: "David Mowers" To: "IETF Transport Layer Security WG" X-OriginalArrivalTime: 12 Jul 2001 18:08:49.0719 (UTC) FILETIME=[B379C470:01C10AFD] List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <0170DDAD0BADFA4CBEC3B55A0748DCCC03C74238@red-msg-02.redmond.corp.microsoft.com> 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 OAA03111 First, an introduction: I took over Program Manager responsibilities for SChannel, Microsoft's implementation of SSL/TLS, last year. I work with John Banes, our principal Developer for SSL/TLS, in the Windows Security team. As I settle into my position here at Microsoft, I am looking forward to taking a more active role in this working group and helping out where possible in the ongoing efforts to improve TLS. Back to the issue: It's hard to predict when Microsoft will implement and deploy the dns_name extension although it is getting a very close look. I don't think that incrementing the version number will have much of an effect either way, though, so don't let that turn into a blocking issue. Deploying this change in the context of HTTP over TLS (HTTPS) is going to take some time. Changing the format of the client_hello message has historically caused lots of grief and various compatibility problems. There are a lot of internet servers out there and just testing against them all is a very large effort. I think this change is worth doing, but it is going to take some time. David Mowers Program Manager Windows Security -----Original Message----- From: Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Thursday, July 05, 2001 1:46 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: London "Joseph Hui" writes: > Incrementing the minor number may complicate whatever somehow. > But it would certainly "uncomplicate" to great extent the task > of convincing browser/server vendors to adopt dns_name quickly. > The fact of matter is: the vendors are not direct beneficiaries > of dns_name, so they need some extra incentives to move. > If we can't tempt them with greed (as all browsers are free), > then fear -- the fear of falling behind one TLS revision -- is > the obvious alternative. I see no reason to believe that incrementing the version number will have this effect. Perhaps the representatives from Microsoft and Netscape would be so good as to offer an opinion here. -Ekr --- You are currently subscribed to ietf-tls as: davemo@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 From bounce-ietf-tls-3458737@lists.certicom.com Thu Jul 12 15:23:59 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 PAA10555 for ; Thu, 12 Jul 2001 15:23:59 -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: London Date: Thu, 12 Jul 2001 12:25:28 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcEFkpvqIWMb25jtSuqOFB4mygdLvgFW7sdAAAQ0O9A= 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 PAA10555 David, Thanks for shedding light on Microsoft's position on the dns_name extension. Taking it as good faith from a major vendor to implement dns_name in due time, hopefully soon, I think the TLS revision number has just become academic, from a CDN's vantage point. Maybe now it's a good time to bring up an issue of compatibility that may cause grief during the dns_name roll-out: dsn_name-server : dns_name-browser, works; dns_name-server : non-dns_name-browser, doesn't work; non-dns_name-server : dns_name-browser, doesn't work; non-dns_name-server : non-dns_name-browser, doesn't work. IMHO, Microsoft can do lots of good to help mitigate the migration pain as we move onto the dns_name-servers:dns_name-browsers world, like launching the dns_name feature in IE server and browser simultaneously. Regards, Joe Hui Digital Island ==================================================================== -----Original Message----- From: David Mowers [mailto:davemo@microsoft.com] Sent: Thursday, July 12, 2001 11:09 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: London First, an introduction: I took over Program Manager responsibilities for SChannel, Microsoft's implementation of SSL/TLS, last year. I work with John Banes, our principal Developer for SSL/TLS, in the Windows Security team. As I settle into my position here at Microsoft, I am looking forward to taking a more active role in this working group and helping out where possible in the ongoing efforts to improve TLS. Back to the issue: It's hard to predict when Microsoft will implement and deploy the dns_name extension although it is getting a very close look. I don't think that incrementing the version number will have much of an effect either way, though, so don't let that turn into a blocking issue. Deploying this change in the context of HTTP over TLS (HTTPS) is going to take some time. Changing the format of the client_hello message has historically caused lots of grief and various compatibility problems. There are a lot of internet servers out there and just testing against them all is a very large effort. I think this change is worth doing, but it is going to take some time. David Mowers Program Manager Windows Security -----Original Message----- From: Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Thursday, July 05, 2001 1:46 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: London "Joseph Hui" writes: > Incrementing the minor number may complicate whatever somehow. > But it would certainly "uncomplicate" to great extent the task > of convincing browser/server vendors to adopt dns_name quickly. > The fact of matter is: the vendors are not direct beneficiaries > of dns_name, so they need some extra incentives to move. > If we can't tempt them with greed (as all browsers are free), > then fear -- the fear of falling behind one TLS revision -- is > the obvious alternative. I see no reason to believe that incrementing the version number will have this effect. Perhaps the representatives from Microsoft and Netscape would be so good as to offer an opinion here. -Ekr --- You are currently subscribed to ietf-tls as: davemo@MICROSOFT.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 Jul 12 17:13: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 RAA25225 for ; Thu, 12 Jul 2001 17:13:32 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London 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 Jul 2001 14:20:30 -0700 In-Reply-To: "Joseph Hui"'s message of "Thu, 12 Jul 2001 12:25:28 -0700" 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 "Joseph Hui" writes: > Maybe now it's a good time to bring up an issue of compatibility > that may cause grief during the dns_name roll-out: > > dsn_name-server : dns_name-browser, works; > dns_name-server : non-dns_name-browser, doesn't work; > non-dns_name-server : dns_name-browser, doesn't work; > non-dns_name-server : non-dns_name-browser, doesn't work. > > IMHO, Microsoft can do lots of good to help mitigate the migration pain > as we move onto the dns_name-servers:dns_name-browsers world, like > launching the dns_name feature in IE server and browser simultaneously. Actually, the situation is more complicated than this. In theory, all of these should WORK. It's just a matter of whether name-based virtual hosting will work. Of course, in practice many servers may not accept the extended client_hello, but that's a bug in those servers. The only situation in which the dns_name client is required or useful is when talking to a server which uses name-based virtual hosting. It won't pay off to deploy such servers until suitable clients are already ubiquitous. -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 Jul 12 17:43: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 RAA29349 for ; Thu, 12 Jul 2001 17:43:45 -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: London Date: Thu, 12 Jul 2001 14:45:20 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELF8Bhc7USHCffTfqsF4IEhdYbdAAALtqg 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 RAA29349 It's reasonable to assume the context of dns_name discussion to be always name-based virtual hosting. So the compatibility issue raised was specific for such practice. Anyway, I think it helps and it never hurts to deploy dns_name-servers prior to the ubiquity of dns_name-clients, as the dns_name-server:non-dns_name-client case is no worse than non-dns_name-server:non-dns_name-client (which is the current situation), and yet half way closer to the dns_name-servers:dns_name-clients nirvana. Of course, it's up to individual hosting entities to decide for themselves the best timing for deployment. Yet I bet none of them will complain for having the implementations available to them too early. Joe Hui Digital Island =================================================================== -----Original Message----- From: Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Thursday, July 12, 2001 2:21 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: London "Joseph Hui" writes: > Maybe now it's a good time to bring up an issue of compatibility > that may cause grief during the dns_name roll-out: > > dsn_name-server : dns_name-browser, works; > dns_name-server : non-dns_name-browser, doesn't work; > non-dns_name-server : dns_name-browser, doesn't work; > non-dns_name-server : non-dns_name-browser, doesn't work. > > IMHO, Microsoft can do lots of good to help mitigate the migration pain > as we move onto the dns_name-servers:dns_name-browsers world, like > launching the dns_name feature in IE server and browser simultaneously. Actually, the situation is more complicated than this. In theory, all of these should WORK. It's just a matter of whether name-based virtual hosting will work. Of course, in practice many servers may not accept the extended client_hello, but that's a bug in those servers. The only situation in which the dns_name client is required or useful is when talking to a server which uses name-based virtual hosting. It won't pay off to deploy such servers until suitable clients are already ubiquitous. -Ekr --- 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 Jul 12 17:54:07 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 RAA00891 for ; Thu, 12 Jul 2001 17:54:06 -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] London. Book signing? Date: Thu, 12 Jul 2001 14:55:40 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELF8Bhc7USHCffTfqsF4IEhdYbdAABOH7A 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 RAA00891 Eric, Will you be in London for the TLS meeting? If you will, I'd like to bring my copy of your book along and perhaps you'd be so gracious to sign it. Thanks, 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 Jul 12 18:20:29 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 SAA04119 for ; Thu, 12 Jul 2001 18:20:28 -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: London. Book signing? Date: Thu, 12 Jul 2001 15:22:02 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELF8Bhc7USHCffTfqsF4IEhdYbdAABOH7AAADKroA= 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 SAA04119 My apology for the wide distribution of my mail meant for only Eric. (I neglected to check the recipient when I clicked Reply to an Eric's mail addressed to the TLS mailing list.) Joe Hui Digital Island ================================================== -----Original Message----- From: Joseph Hui Sent: Thursday, July 12, 2001 2:56 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] London. Book signing? Eric, Will you be in London for the TLS meeting? If you will, I'd like to bring my copy of your book along and perhaps you'd be so gracious to sign it. Thanks, Joe Hui 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 Fri Jul 13 01:45:33 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02634 for ; Fri, 13 Jul 2001 01:45:33 -0400 (EDT) Message-ID: Date: Fri, 13 Jul 2001 00:30:37 +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: I-D ACTION:draft-madhu-tls-spki-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: <3B4E331D.501A54D1@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- : > H. S. Madhusudhana > INTERNET-DRAFT V. R. Ramachandran > Document: draft-madhu-tls-spki-00.txt Novell > Expires: January 11 2002 July 11 2001 > > SPKI Certificate Integration with Transport Layer Security > (TLS) for Client Authentication and Authorization ... > 1. Abstract > > This document extends version 1.0 of the TLS specification [TLS] to > support client SPKI certificates and associated public key > algorithms, symmetric ciphers, hash algorithms and the appropriate > trust model. The server is required to possess a X.509 certificate > for authentication. The client certificate type is basically orthogonal to the server certificate type. New server certificate options may be defined in future, using new ciphersuites. Therefore, this should say something like "The type of certificate required by the server is defined by the negotiated ciphersuite (X.509 for the ciphersuites specified in [TLS])." > ... [TLS] supports X.509.v3 certificate based > authentication and RFC 2712 [KERB-TLS] shows how to extend TLS to > Kerberos based authentication within an organization. [OpenPGP] > explains extension of TLS to work with OpenPGP keys. > [OpenPGP] W. Price, M. Elkins, " Extensions to TLS for OpenPGP > keys", INTERNET-DRAFT, March 23 2001. The text should note that this is an I-D, if it is referenced at all. It could change significantly, or it could be dropped. It would probably be better just to say that support for other certificate types, for example OpenPGP, may be added in future. ... > SPKI does not require a server to possess a SPKI certificate. In > order to facilitate server authentication, the server MUST have a > X.509.v3 server certificate. Same comment as above: the server must have *some* certificate that is valid for the ciphersuite. > The semantics of ServerKeyExchange is not changed from TLS protocol. > If the server accepts a SPKI-based cipher suite from the client, it > MUST send the CertificateRequest message to the client. Note "SPKI-based cipher suite", which is explained here: > 4. Cipher Suites > > The CipherSuite field is extended to indicate type of certificate > whether SPKI or X509 or OpenPGP. The CipherSuite of the form {0x00, > 0xMN} indicates use of X.509.v3 certificate and 0xMN indicates type > of public key encryption, signature, shared key encryption and > message digest algorithms employed; The CipherSuite {0x01, 0xYZ} is > suggested for TLS extension with OpenPGP [OpenPGP]; The CipherSuite > {0x02, 0xYZ} is proposed to denote the employment of SPKI > certificates. I don't agree that it's necessary or desirable to encode the *client* certificate type in the ciphersuite. That is what the ClientCertificateType field is for. There is no good reason for negotiating the client certificate type and the ciphersuite together, and that is not how TLS is currently designed. Currently, a server can specify any client certificate type in the list it will accept (with the restriction that the *_fixed_dh types only work for the DH ciphersuites). The functionality of this draft can be achieved without any new ciphersuites, just by adding SPKI client certificate types that can be used with the existing X.509 ciphersuites. That would be simpler, IMHO. I don't think there is really any need for the client to be able to announce in advance which certificate types it has; the current method of client cert type negotiation works fine. If that is considered necessary, though, a client hello extension would probably be a better way of implementing it. > The second byte of CipherSuite for SPKI takes the same > value as defined in CipherSuites for X.509.v3 in [TLS] for > indicating types of public key encryption, signature, shared key > encryption and message digest algorithms employed. > > For example, the CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA has a > value {0x00, 0x12}. Ciphersuites with symmetric key length <= 56 bits should preferably not be used in examples. > The corresponding cipher suite for SPKI is > {0x02, 0x12}. The interpretation of cipher suite for TLS 1.0 is that > key exchange is based on ephemeral DH keys which is signed using DSS > algorithm by a X.509.v3 certificate issued by CA, the hash algorithm > is SHA and the encryption algorithm is DES in CBC mode. This is unclear. At no point does TLS sign any ephemeral keys in the format of an X.509 cert, and nothing can be signed *by* a certificate. Presumably it's intended to mean: In the TLS_DHE_DSS_* ciphersuites, the ephemeral DH parameters and public key are signed using the DSS algorithm by the server's long-term private key; the corresponding public key is certified by an X.509 v3 certificate. > The interpretation for SPKI based security context remains the same > except that a SPKI certificate signs the ephemeral DH key. This seems rather odd; is it really what was intended? It seems to suggest using SPKI certs for server authentication, not client authentication, which contradicts what is said in the abstract. Why would using SPKI for client authentication make any difference to how the DH parameters and ephemeral key are signed? > This specification extends ClientCertificateType as shown in Figure 2 > to include the server name and details of applications/services on it > and to support different kinds of SPKI certificates. > > TLS defines several kinds of client certificates to facilitate > different methods of key exchange and message authentication. The > newly defined SPKI certificate types are semantically same as the > corresponding X.509.v3 certificate types except for representation > in S-expression format. When X.509.v3 client certificate is used, > the DistinguishedName field of CertificateRequest message specifies > acceptable CA's distinguished names. When SPKI certificate is used > by the client, it is proposed to use the DistinguishedName field to > specify server name/application name etc. in order to help the > client to select the appropriate SPKI certificate. How is this encoded? Is it shoehorned into the format of a DistinguishedName somehow? (Note that clients will try to parse it as a DistinguishedName, especially if we use the existing X.509 ciphersuites, as I suggest.) Perhaps a client hello extension meaning "I have at least one SPKI client cert, and I can understand an extended CertificateRequest format." would help. > This is useful > because a client may hold multiple SPKI certificates from many > servers/applications. > > +----------------------------------------------------------+ > | enum { | > | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), | > | dss_fixed_dh(4), kerberos(5), | > | spki_rsa_sign(6), spki_dss_sign(7), | > | spki_rsa_fixed_dh(8), spki_dss_fixed_dh(9), | > | (255) | > | } ClientCertificateType; | Where did kerberos(5) come from? It is not defined in RFC 2712. SSL 3.0 (draft-freier-ssl-version3-02.txt, which although expired, is the only current definition of SSL3) has the following: enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20), (255) } ClientCertificateType; 5, 6 and 20 are not defined in TLS, but these numbers should not be reused arbitrarily. In addition, draft-ietf-tls-ecc-01.txt has enum { ecdsa_sign(5), rsa_fixed_ecdh(6), ecdsa_fixed_ecdh(7), (255) } ClientCertificateType; and draft-ietf-tls-ntru-00.txt has enum { nss_sign(8), nss_rsa(9), (255) } ClientCertificateType; I'm rather dubious about adding new *_fixed_dh types; isn't it correct that the existing *_fixed_dh types are basically never used? Note that using these types prevents forward secrecy for the DHE ciphersuites (the same would be true for *_fixed_ecdh and ECDHE). I therefore suggest: enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), ssl3_reserved_5(5), ssl3_reserved_6(6), ecdsa_sign(7), nss_sign(8), nss_rsa_sign(9), spki_rsa_sign(10), spki_dss_sign(11), ssl3_reserved_20(20), (255) } ClientCertificateType; with ecdsa_sign, nss_sign and nss_rsa_sign only provisionally assigned for the moment (I don't agree with much of the ECC draft; it is too complicated). > | | > | opaque DistinguishedName <1..2^16-1>; | > | | > | struct { | > | ClientCertificateType certificate_types<1..2^8-1>; | > | DistinguishedName certificate_authorities <3..2^16-1>; | > |} CertificateRequest; | > | | > +----------------------------------------------------------+ > > FIGURE 2: Extended ClientCertificateType > > +-----------------------------------------------+ > | | > | opaque Certificate <1..2^24-1>; | > | | > +-----------------------------------------------+ > FIGURE 3: Certificate Message > > To get server authorization for access/service, the client MUST > respond to the server by sending Certificate Message as in Figure 3 > In case of SPKI, it is to be noted that Certificate is not an array > of elementary certificates as in the case of X.509.v3. ... is not a DER SEQUENCE of ... > A Tuple-reduction and authorization computation in a SPKI Certificate Does Appendix A come directly from [SPKI-JUL 1999]? If so, that should be stated. In summary, I think the basic idea of the draft is fine, but it could be simplified quite a bit by using the existing ciphersuites, rather than trying to define new ones. - -- 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 iQEVAwUBO04yOTkCAxeYt5gVAQHFuggApAU4XQSXvFm2mumuU1JePcbWUM/zH/MY 3qQc4nRKKZeSxqAKYbaefe+FvkMC+icmf7jZ1co21PNT0m4XCI7e+c8ijIqa71xf ueHA6Rm32uZt/539OUWmX/E/wIAyAl5yMIaXLqFIyR7TsTzMoTXMicrmmH5Bim0t BU6bu8TVzeO2c0MG6oit49OzGr7mbd6mYuifMTZ88GpeLeMst+BGXVF+Fz+hz2Bp QH2Qq7C7V0BAS7/4hWiYJHHGVI/pZWoD6fkp0VHTae2j3ltE3lBDHrzcygBnF84a 9g4EnA3t7uHCZgLWC5RoP+IujXFodinpDJ7Ro6m1J+6AYiw3ao2b/g== =OxmA -----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 Jul 13 01:59:24 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 BAA06017 for ; Fri, 13 Jul 2001 01:59:23 -0400 (EDT) Message-ID: Date: Fri, 13 Jul 2001 00:47:38 +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: London 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: <3B4E371A.EFEAAB7A@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: > "Joseph Hui" writes: > > > It's reasonable to assume the context of dns_name discussion > > to be always name-based virtual hosting. So the compatibility > > issue raised was specific for such practice. > > Well, that wasn't the compatibility issue that David was > raising. There's a serious concern that if clients use this > extension it will break servers who don't know about it. > Such servers are broken but that's not much comfort to > anyone concerned. Can't the client simply re-connect if the server breaks (as least if it can determine that this was the reason for the breakage)? SSL/TLS client libraries already have to be designed in a way that allows them to re-connect, in order to implement "Server Gated Cryptography" (either the Microsoft or Netscape version, I can't remember which). Perhaps we need to test various servers, and if necessary include workarounds in the extensions draft, before publishing it as an RFC. Re-connection should also work as a way of fixing the problem of some SSL servers not tolerating a version number of {3, 1} in the encrypted pre-master secret. I'll think about that some more and post the details. - -- 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 iQEVAwUBO0420zkCAxeYt5gVAQF9Egf/a2Cq3mtAM/rj/bjrQY2jKjM8g4E6dfy2 II2MO39cfyPpFcLK6nz98xM7STNeqmLCAecrSxf2SZVzK3DsfI6SuCyBWAcyAtWy glcl4GxAk95zd8HblRxaKjA7c+1BkcOVz0N32R/3n9tFh8mIq7rPrSJ5JaERB0K+ E2ro7zNPxkonAZ4Pp+oQkIaKJI1YsvEZR28YensH+iaDnLUUdd+6BKi+0eVukkGv cgtBlXd1rVYykL/JLw8oSO7AKZxpgjaxboeqEC/1g4h8gfP01qdIGs/EoDwlzoMZ RK8PAbknLS7T+KTP4zErj65abRTaWuzNOqH3Vlp93ALW9h5xLplPfQ== =x4cr -----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 Jul 13 02:10:41 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 CAA15701 for ; Fri, 13 Jul 2001 02:10:39 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London 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 Jul 2001 22:40:39 -0700 In-Reply-To: "Joseph Hui"'s message of "Thu, 12 Jul 2001 14:45:20 -0700" Message-ID: Lines: 13 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: > It's reasonable to assume the context of dns_name discussion > to be always name-based virtual hosting. So the compatibility > issue raised was specific for such practice. Well, that wasn't the compatibility issue that David was raising. There's a serious concern that if clients use this extension it will break servers who don't know about it. Such servers are broken but that's not much comfort to anyone concerned. -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 Fri Jul 13 04:29: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 EAA00218 for ; Fri, 13 Jul 2001 04:29:15 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-madhu-tls-spki-00.txt Date: Fri, 13 Jul 2001 18:34:16 +1000 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.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: <003501c10b76$9aa20380$75d336cb@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > > This specification extends ClientCertificateType as shown in Figure 2 > > to include the server name and details of applications/services on it > > and to support different kinds of SPKI certificates. > > > > TLS defines several kinds of client certificates to facilitate > > different methods of key exchange and message authentication. The > > newly defined SPKI certificate types are semantically same as the > > corresponding X.509.v3 certificate types except for representation > > in S-expression format. When X.509.v3 client certificate is used, > > the DistinguishedName field of CertificateRequest message specifies > > acceptable CA's distinguished names. When SPKI certificate is used > > by the client, it is proposed to use the DistinguishedName field to > > specify server name/application name etc. in order to help the > > client to select the appropriate SPKI certificate. > > How is this encoded? Is it shoehorned into the format of a DistinguishedName > somehow? (Note that clients will try to parse it as a DistinguishedName, > especially if we use the existing X.509 ciphersuites, as I suggest.) > Perhaps a client hello extension meaning "I have at least one SPKI client > cert, and I can understand an extended CertificateRequest format." would > help. What about using a server hello extension (corresponding to the suggested client hello extension) to advertise this server name/application name data? Then the certificate request message can still carry the ClientCertificateType data but not mangle the DistinguishedName element. If the existing cipher suites are used and the server ignores the client hello extension, the server hello extension won't be sent so the client will know it's not going to be able to do SPKI authentication. This would still allow the existing cipher suites to be used. Regards, David Taylor. --- 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 Jul 13 04:41: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 EAA01655 for ; Fri, 13 Jul 2001 04:41:45 -0400 (EDT) Message-ID: From: "Jan Mikkelsen" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Date: Fri, 13 Jul 2001 18:40:38 +1000 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 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <033d01c10b77$7e0f4bf0$0801a8c0@janm.transactionware.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Hopwood wrote: >Eric Rescorla wrote: >> Well, that wasn't the compatibility issue that David was >> raising. There's a serious concern that if clients use this >> extension it will break servers who don't know about it. >> Such servers are broken but that's not much comfort to >> anyone concerned. > >Can't the client simply re-connect if the server breaks (as least if it >can determine that this was the reason for the breakage)? SSL/TLS client >libraries already have to be designed in a way that allows them to >re-connect, in order to implement "Server Gated Cryptography" (either >the Microsoft or Netscape version, I can't remember which). > >Perhaps we need to test various servers, and if necessary include >workarounds in the extensions draft, before publishing it as an RFC. > >Re-connection should also work as a way of fixing the problem of some >SSL servers not tolerating a version number of {3, 1} in the encrypted >pre-master secret. I'll think about that some more and post the details. Some time ago, Jay Kistler did some simple tests against deployed servers (Apache/OpenSSL, IIS 4, IIS 5, Netscape Enterprise 3.5 & 3.6) by sending a TLS ClientHello with extra data on the end. Apache/OpenSSL & IIS 5 successfully established a session, I think the others failed with a version error. At the time, our (my, Jay Kistler & Rene Eberhard) thinking was exactly the same as David's: That the client would attempt reconnection with a lower version. We did the tests to make sure that servers didn't break outright. Jan Mikkelsen --- 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 Jul 13 05:29:53 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 FAA07148 for ; Fri, 13 Jul 2001 05:29:52 -0400 (EDT) Date: Fri, 13 Jul 2001 11:30:35 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from jhui@digisle.net on Thu, Jul 12, 2001 at 12:25:28PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010713113035.A18671@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Thu, Jul 12, 2001 at 12:25:28PM -0700, Joseph Hui wrote: > Maybe now it's a good time to bring up an issue of compatibility > that may cause grief during the dns_name roll-out: > > dsn_name-server : dns_name-browser, works; > dns_name-server : non-dns_name-browser, doesn't work; > non-dns_name-server : dns_name-browser, doesn't work; > non-dns_name-server : non-dns_name-browser, doesn't work. This is misleading. SSL 3.0 and TLS 1.0 servers are required to ignore extra data at the end of the ClientHello message, and obviously non-dns_name servers would only be used in situations where the dns_name extension is not needed (i.e., no name-based virtual hosting). Thus the only configuration that is problematic is when a server requires dns_name, but the client does not support it. This is similar to the HTTP "Host" header situation some time ago. A more important compatibility issue has not been mentioned yet, as far as I know: TLS extensions can only be used in SSL 3.0 and TLS 1.0 ClientHello messages, not in SSL 2.0 CLIENT-HELLO messages. While it is time to give up the actual SSL 2.0 protocol, the SSL 2.0 CLIENT-HELLO format still play an important role for protocol version negotiation, and handshakes usually start using this format. Clients still cannot rely on TLS 1.0 being available on all servers, so they must allow for SSL 3.0 to be negotiated as well (and sometimes even SSL 2.0, but I wouldn't mind giving this up). In theory, such protocol version negotiation is no problem -- set client_version to { 0x03, 0x01 } (= TLS 1.0) in a SSL 3.0 ClientHello (the main difference to a TLS 1.0 ClientHello is the 'version' value in the record header). In practice, many buggy servers handle such ClientHello messages incorrectly, confusing the client_version value (highest protocol version supported by the client) with the record header version value (protocol version tolerated by the client), or checking for the wrong version number in the encrypted PreMasterSecret. I predict that this will cause more interoperability problems than the actual TLS extensions. Ignoring some extra data is not difficult, but the details of protocol version negotiation are apparently easy to get wrong -- we only can rely on it to work quite well when using SSL 2.0 CLIENT-HELLO messages. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 13 05:36:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07944 for ; Fri, 13 Jul 2001 05:36:47 -0400 (EDT) Date: Fri, 13 Jul 2001 11:37:23 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from david.hopwood@zetnet.co.uk on Fri, Jul 13, 2001 at 12:47:38AM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010713113723.B18671@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Fri, Jul 13, 2001 at 12:47:38AM +0100, David Hopwood wrote: > Can't the client simply re-connect if the server breaks (as least if it > can determine that this was the reason for the breakage)? SSL/TLS client > libraries already have to be designed in a way that allows them to > re-connect, in order to implement "Server Gated Cryptography" (either > the Microsoft or Netscape version, I can't remember which). "Server Gated Cryptography" does not use reconnects, the client just requests re-negotiation on the exisiting connecton. But of course reconnecting after a failed handshake, using a more conservatively built client hello message, is always an option. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 13 06:54:41 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 GAA17027 for ; Fri, 13 Jul 2001 06:54:40 -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-delegation-01.txt Date: Fri, 13 Jul 2001 06:54:32 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200107131054.GAA17003@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 : TLS Delegation Protocol Author(s) : K. Jackson, S. Tuecke, D. Engert Filename : draft-ietf-tls-delegation-01.txt Pages : 10 Date : 12-Jul-01 This document specifies a delegation protocol for use with the Transport Layer Security (TLS) protocol. When the TLS session is using X.509 certificates for authentication, then the delegation is of an X.509 Proxy Certificate, as defined in draft-ggf-x509-proxy. When the TSL session is using Kerberos 5 for authentication, then the delegation is of a Kerberos 5 forwardable ticket, as defined in RFC 1510. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-delegation-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-delegation-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-delegation-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: <20010712144348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-delegation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-delegation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010712144348.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 Fri Jul 13 11:40:09 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24905 for ; Fri, 13 Jul 2001 11:40:08 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London 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: 13 Jul 2001 08:47:39 -0700 In-Reply-To: David Hopwood's message of "Fri, 13 Jul 2001 00:47:38 +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 David Hopwood writes: > Can't the client simply re-connect if the server breaks (as least if it > can determine that this was the reason for the breakage)? This is the sticking point. Expect to receive a "handshake failed" alert from the server for pretty much any failure. > SSL/TLS client > libraries already have to be designed in a way that allows them to > re-connect, in order to implement "Server Gated Cryptography" (either > the Microsoft or Netscape version, I can't remember which). This isn't the same at all. In order to implement the retry you suggest you would need to destroy the TCP connection and reinitiate. You don't do that for either SGC or Step-Up. What you propose requires logic in the client rather than in the library. -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 Fri Jul 13 12:39: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 MAA03743 for ; Fri, 13 Jul 2001 12:39: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: London Date: Fri, 13 Jul 2001 09:40:49 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELfqDR3slVtG5vTLWdJEVK1gQSnAAOi3fQ 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 MAA03743 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >> Maybe now it's a good time to bring up an issue of compatibility >> that may cause grief during the dns_name roll-out: >> >> dsn_name-server : dns_name-browser, works; >> dns_name-server : non-dns_name-browser, doesn't work; >> non-dns_name-server : dns_name-browser, doesn't work; >> non-dns_name-server : non-dns_name-browser, doesn't work. > >This is misleading. SSL 3.0 and TLS 1.0 servers are required to >ignore extra data at the end of the ClientHello message, and obviously >non-dns_name servers would only be used in situations where the >dns_name extension is not needed (i.e., no name-based virtual >hosting). Thus the only configuration that is problematic is when a >server requires dns_name, but the client does not support it. This is >similar to the HTTP "Host" header situation some time ago. The context of discussion was about dns_name only. I.e. the tabulation was only meant for dns_name deployment. (What else was the thread about?) 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 Fri Jul 13 13:00: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 NAA06795 for ; Fri, 13 Jul 2001 13:00:29 -0400 (EDT) Date: Fri, 13 Jul 2001 19:01:12 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from jhui@digisle.net on Fri, Jul 13, 2001 at 09:40:49AM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010713190112.B20167@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>> Maybe now it's a good time to bring up an issue of compatibility >>> that may cause grief during the dns_name roll-out: >>> >>> dsn_name-server : dns_name-browser, works; >>> dns_name-server : non-dns_name-browser, doesn't work; >>> non-dns_name-server : dns_name-browser, doesn't work; >>> non-dns_name-server : non-dns_name-browser, doesn't work. >> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >> ignore extra data at the end of the ClientHello message, and obviously >> non-dns_name servers would only be used in situations where the >> dns_name extension is not needed (i.e., no name-based virtual >> hosting). Thus the only configuration that is problematic is when a >> server requires dns_name, but the client does not support it. This is >> similar to the HTTP "Host" header situation some time ago. > The context of discussion was about dns_name only. > I.e. the tabulation was only meant for dns_name deployment. > (What else was the thread about?) It is obvious that dns_name can be *used* only if it is supported both by the client and the server. Since the server implementation should be selected depending on the needs of the specific site, why is it a "compatibility" problem that non-dns_name servers would have to ignore the dns_name extension? But TLS extensions can cause compatibility problems even for connections where they are not needed at all (see my previous message). When connecting to an HTTPS server, a browser does not know whether dns_name is required for this specific connection or not. Thus the dns_name extension would have to appear in *all* connection attempts (ruling out use of the SSL 2.0 client hello format), and *this* is a possible source of compatibility nightmares. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 13 14:39:07 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 OAA20760 for ; Fri, 13 Jul 2001 14:39:07 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] AES, OAEP, and TLS Date: Fri, 13 Jul 2001 14:36:54 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107131836.f6DIasU08121@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net [I tried to send this several days ago, but a conspiracy of mailer failures kept it from appearing on the list. --WT] Since I understood that NIST was encouraging the use of OAEP with AES cryptosystems, I asked Tim Polk at NIST for some more background. Here's what he said: The basic NIST position is that the standard PKCS #1 V1.5 padding can and should be improved upon. As we transition to AES, we are already needing to support bigger keys, etc. so it makes sense to upgrade the padding at the same time. We could probably argue forever about padding schemes, but OAEP presents a clear improvement that everyone should be able to support. The NIST strategy for RSA-based key management in AES ciphersuites will utilize OAEP padding. We presume these cryptographic modules will be used to support a variety of protocols, so we want a padding technique that is secure for the broadest range of protocols. The advantages of OAEP may not be relevant in some protocols, but it doesn't seem to present any problem in those protocols. We recognize that there is a cost, particularly when implementing new techniques in hardware. However, many of these accelerators would need to be updated anyway to handle the larger key sizes that make sense now that we're using 128-bit and larger symmetric keys. NIST is also working to promote this position in the ANSI X9 standards community, in particular on the ANSI X9.44 RSA Key Management standard. We would like to see standards in the IETF like TLS specify consistent ciphersuites as well. 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 Fri Jul 13 17:01: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 RAA10570 for ; Fri, 13 Jul 2001 17:01:22 -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: London Date: Fri, 13 Jul 2001 14:02:55 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELvZANq7aipB9rRhyegqVRcuUeWwAAu0wg 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 RAA10570 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] > >On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >>> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>>> Maybe now it's a good time to bring up an issue of compatibility >>>> that may cause grief during the dns_name roll-out: >>>> >>>> dsn_name-server : dns_name-browser, works; >>>> dns_name-server : non-dns_name-browser, doesn't work; >>>> non-dns_name-server : dns_name-browser, doesn't work; >>>> non-dns_name-server : non-dns_name-browser, doesn't work. > >>> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >>> ignore extra data at the end of the ClientHello message, and obviously >>> non-dns_name servers would only be used in situations where the >>> dns_name extension is not needed (i.e., no name-based virtual >>> hosting). Thus the only configuration that is problematic is when a >>> server requires dns_name, but the client does not support it. This is >>> similar to the HTTP "Host" header situation some time ago. > >> The context of discussion was about dns_name only. >> I.e. the tabulation was only meant for dns_name deployment. >> (What else was the thread about?) > >It is obvious that dns_name can be *used* only if it is supported both >by the client and the server. Since the server implementation should >be selected depending on the needs of the specific site, why is it a >"compatibility" problem that non-dns_name servers would have to ignore >the dns_name extension? First of all, I think the quoted text was taken out of context. For starter, the sentence where I made my point had been omitted. (The quoted part was only the preamble.) My point was to appeal to vendors to do the best they can to mitigate the migration pain, as migrate we must, having established dns_name is worth doing. I might be guilty of overstating the obvious. But hey, traffic signs too are obvious, yet accidents abound. Look where we're at now with this thread, where not everything was made perfectly clear. Why a problem? Suffice to say, as long as the dns_name-server:dns_name-browsers state hasn't been achieved, we have a problem, practicing secured virtual hosting. I'm comfortable in characterizing the problem as compatibility related, especially during the roll-out stage, taking into consideration of what best to inform the end users during the transition period, e.g. on an http page, say "You need a xyz compatible browser to login. Click here to get the https page, click there to download the xyz patch. blah blah blah ..." This may not be the same characterization of "compatibility" you had in mind. Yours might be more intrinsic to the TLS semantics, I guess. >But TLS extensions can cause compatibility problems even for >connections where they are not needed at all (see my previous >message). When connecting to an HTTPS server, a browser does not know >whether dns_name is required for this specific connection or not. >Thus the dns_name extension would have to appear in *all* connection >attempts (ruling out use of the SSL 2.0 client hello format), and >*this* is a possible source of compatibility nightmares. This is yet another compatibility issue that merits to be addressed in a separate thread. It raises a good point, because we should cover all corners, bending backwards to be backward-compatibility-friendly. Having said that, I should also say, going out on a limp, even contortionists have limits. Extrapolating from the success of the 128-bit roll-out, we may not have to lose sleep over this. E.g. there're more than few 128-bit commercial sites that tell users to upgrade or get lost. So far I've heard no complaints, not to make light of the situation. Now, I think I've gotten enough mileage out of this thread, which has served the purpose of granting dns_name the attention it deserves from vendors/implementers. To continue the discourse on compatibility issues, which appear to be many. I suggest a new thread be created for each of them, for the sake of clarity and posterity. Cheers, 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 Fri Jul 13 17:42: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 RAA15984 for ; Fri, 13 Jul 2001 17:42:17 -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: London Date: Fri, 13 Jul 2001 14:02:55 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELvZANq7aipB9rRhyegqVRcuUeWwAAu0wg 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 RAA15984 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] > >On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >>> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>>> Maybe now it's a good time to bring up an issue of compatibility >>>> that may cause grief during the dns_name roll-out: >>>> >>>> dsn_name-server : dns_name-browser, works; >>>> dns_name-server : non-dns_name-browser, doesn't work; >>>> non-dns_name-server : dns_name-browser, doesn't work; >>>> non-dns_name-server : non-dns_name-browser, doesn't work. > >>> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >>> ignore extra data at the end of the ClientHello message, and obviously >>> non-dns_name servers would only be used in situations where the >>> dns_name extension is not needed (i.e., no name-based virtual >>> hosting). Thus the only configuration that is problematic is when a >>> server requires dns_name, but the client does not support it. This is >>> similar to the HTTP "Host" header situation some time ago. > >> The context of discussion was about dns_name only. >> I.e. the tabulation was only meant for dns_name deployment. >> (What else was the thread about?) > >It is obvious that dns_name can be *used* only if it is supported both >by the client and the server. Since the server implementation should >be selected depending on the needs of the specific site, why is it a >"compatibility" problem that non-dns_name servers would have to ignore >the dns_name extension? First of all, I think the quoted text was taken out of context. For starter, the sentence where I made my point had been omitted. (The quoted part was only the preamble.) My point was to appeal to vendors to do the best they can to mitigate the migration pain, as migrate we must, having established dns_name is worth doing. I might be guilty of overstating the obvious. But hey, traffic signs too are obvious, yet accidents abound. Look where we're at now with this thread, where not everything was made perfectly clear. Why a problem? Suffice to say, as long as the dns_name-server:dns_name-browsers state hasn't been achieved, we have a problem, practicing secured virtual hosting. I'm comfortable in characterizing the problem as compatibility related, especially during the roll-out stage, taking into consideration of what best to inform the end users during the transition period, e.g. on an http page, say "You need a xyz compatible browser to login. Click here to get the https page, click there to download the xyz patch. blah blah blah ..." This may not be the same characterization of "compatibility" you had in mind. Yours might be more intrinsic to the TLS semantics, I guess. >But TLS extensions can cause compatibility problems even for >connections where they are not needed at all (see my previous >message). When connecting to an HTTPS server, a browser does not know >whether dns_name is required for this specific connection or not. >Thus the dns_name extension would have to appear in *all* connection >attempts (ruling out use of the SSL 2.0 client hello format), and >*this* is a possible source of compatibility nightmares. This is yet another compatibility issue that merits to be addressed in a separate thread. It raises a good point, because we should cover all corners, bending backwards to be backward-compatibility-friendly. Having said that, I should also say, going out on a limp, even contortionists have limits. Extrapolating from the success of the 128-bit roll-out, we may not have to lose sleep over this. E.g. there're more than few 128-bit commercial sites that tell users to upgrade or get lost. So far I've heard no complaints, not to make light of the situation. Now, I think I've gotten enough mileage out of this thread, which has served the purpose of granting dns_name the attention it deserves from vendors/implementers. To continue the discourse on compatibility issues, which appear to be many. I suggest a new thread be created for each of them, for the sake of clarity and posterity. Cheers, 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 Fri Jul 13 19:52: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 TAA01617 for ; Fri, 13 Jul 2001 19:52:16 -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: London Date: Fri, 13 Jul 2001 14:02:55 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELvZANq7aipB9rRhyegqVRcuUeWwAAu0wg 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 TAA01617 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] > >On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >>> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>>> Maybe now it's a good time to bring up an issue of compatibility >>>> that may cause grief during the dns_name roll-out: >>>> >>>> dsn_name-server : dns_name-browser, works; >>>> dns_name-server : non-dns_name-browser, doesn't work; >>>> non-dns_name-server : dns_name-browser, doesn't work; >>>> non-dns_name-server : non-dns_name-browser, doesn't work. > >>> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >>> ignore extra data at the end of the ClientHello message, and obviously >>> non-dns_name servers would only be used in situations where the >>> dns_name extension is not needed (i.e., no name-based virtual >>> hosting). Thus the only configuration that is problematic is when a >>> server requires dns_name, but the client does not support it. This is >>> similar to the HTTP "Host" header situation some time ago. > >> The context of discussion was about dns_name only. >> I.e. the tabulation was only meant for dns_name deployment. >> (What else was the thread about?) > >It is obvious that dns_name can be *used* only if it is supported both >by the client and the server. Since the server implementation should >be selected depending on the needs of the specific site, why is it a >"compatibility" problem that non-dns_name servers would have to ignore >the dns_name extension? First of all, I think the quoted text was taken out of context. For starter, the sentence where I made my point had been omitted. (The quoted part was only the preamble.) My point was to appeal to vendors to do the best they can to mitigate the migration pain, as migrate we must, having established dns_name is worth doing. I might be guilty of overstating the obvious. But hey, traffic signs too are obvious, yet accidents abound. Look where we're at now with this thread, where not everything was made perfectly clear. Why a problem? Suffice to say, as long as the dns_name-server:dns_name-browsers state hasn't been achieved, we have a problem, practicing secured virtual hosting. I'm comfortable in characterizing the problem as compatibility related, especially during the roll-out stage, taking into consideration of what best to inform the end users during the transition period, e.g. on an http page, say "You need a xyz compatible browser to login. Click here to get the https page, click there to download the xyz patch. blah blah blah ..." This may not be the same characterization of "compatibility" you had in mind. Yours might be more intrinsic to the TLS semantics, I guess. >But TLS extensions can cause compatibility problems even for >connections where they are not needed at all (see my previous >message). When connecting to an HTTPS server, a browser does not know >whether dns_name is required for this specific connection or not. >Thus the dns_name extension would have to appear in *all* connection >attempts (ruling out use of the SSL 2.0 client hello format), and >*this* is a possible source of compatibility nightmares. This is yet another compatibility issue that merits to be addressed in a separate thread. It raises a good point, because we should cover all corners, bending backwards to be backward-compatibility-friendly. Having said that, I should also say, going out on a limp, even contortionists have limits. Extrapolating from the success of the 128-bit roll-out, we may not have to lose sleep over this. E.g. there're more than few 128-bit commercial sites that tell users to upgrade or get lost. So far I've heard no complaints, not to make light of the situation. Now, I think I've gotten enough mileage out of this thread, which has served the purpose of granting dns_name the attention it deserves from vendors/implementers. To continue the discourse on compatibility issues, which appear to be many. I suggest a new thread be created for each of them, for the sake of clarity and posterity. Cheers, 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 Sat Jul 14 00:03: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 AAA01582 for ; Sat, 14 Jul 2001 00:03:03 -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: London Date: Fri, 13 Jul 2001 14:02:55 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELvZANq7aipB9rRhyegqVRcuUeWwAAu0wg 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 AAA01582 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] > >On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >>> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>>> Maybe now it's a good time to bring up an issue of compatibility >>>> that may cause grief during the dns_name roll-out: >>>> >>>> dsn_name-server : dns_name-browser, works; >>>> dns_name-server : non-dns_name-browser, doesn't work; >>>> non-dns_name-server : dns_name-browser, doesn't work; >>>> non-dns_name-server : non-dns_name-browser, doesn't work. > >>> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >>> ignore extra data at the end of the ClientHello message, and obviously >>> non-dns_name servers would only be used in situations where the >>> dns_name extension is not needed (i.e., no name-based virtual >>> hosting). Thus the only configuration that is problematic is when a >>> server requires dns_name, but the client does not support it. This is >>> similar to the HTTP "Host" header situation some time ago. > >> The context of discussion was about dns_name only. >> I.e. the tabulation was only meant for dns_name deployment. >> (What else was the thread about?) > >It is obvious that dns_name can be *used* only if it is supported both >by the client and the server. Since the server implementation should >be selected depending on the needs of the specific site, why is it a >"compatibility" problem that non-dns_name servers would have to ignore >the dns_name extension? First of all, I think the quoted text was taken out of context. For starter, the sentence where I made my point had been omitted. (The quoted part was only the preamble.) My point was to appeal to vendors to do the best they can to mitigate the migration pain, as migrate we must, having established dns_name is worth doing. I might be guilty of overstating the obvious. But hey, traffic signs too are obvious, yet accidents abound. Look where we're at now with this thread, where not everything was made perfectly clear. Why a problem? Suffice to say, as long as the dns_name-server:dns_name-browsers state hasn't been achieved, we have a problem, practicing secured virtual hosting. I'm comfortable in characterizing the problem as compatibility related, especially during the roll-out stage, taking into consideration of what best to inform the end users during the transition period, e.g. on an http page, say "You need a xyz compatible browser to login. Click here to get the https page, click there to download the xyz patch. blah blah blah ..." This may not be the same characterization of "compatibility" you had in mind. Yours might be more intrinsic to the TLS semantics, I guess. >But TLS extensions can cause compatibility problems even for >connections where they are not needed at all (see my previous >message). When connecting to an HTTPS server, a browser does not know >whether dns_name is required for this specific connection or not. >Thus the dns_name extension would have to appear in *all* connection >attempts (ruling out use of the SSL 2.0 client hello format), and >*this* is a possible source of compatibility nightmares. This is yet another compatibility issue that merits to be addressed in a separate thread. It raises a good point, because we should cover all corners, bending backwards to be backward-compatibility-friendly. Having said that, I should also say, going out on a limp, even contortionists have limits. Extrapolating from the success of the 128-bit roll-out, we may not have to lose sleep over this. E.g. there're more than few 128-bit commercial sites that tell users to upgrade or get lost. So far I've heard no complaints, not to make light of the situation. Now, I think I've gotten enough mileage out of this thread, which has served the purpose of granting dns_name the attention it deserves from vendors/implementers. To continue the discourse on compatibility issues, which appear to be many. I suggest a new thread be created for each of them, for the sake of clarity and posterity. Cheers, 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 Sat Jul 14 08:13:35 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 IAA08003 for ; Sat, 14 Jul 2001 08:13:35 -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: London Date: Fri, 13 Jul 2001 14:02:55 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELvZANq7aipB9rRhyegqVRcuUeWwAAu0wg 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 IAA08003 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] > >On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >>> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>>> Maybe now it's a good time to bring up an issue of compatibility >>>> that may cause grief during the dns_name roll-out: >>>> >>>> dsn_name-server : dns_name-browser, works; >>>> dns_name-server : non-dns_name-browser, doesn't work; >>>> non-dns_name-server : dns_name-browser, doesn't work; >>>> non-dns_name-server : non-dns_name-browser, doesn't work. > >>> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >>> ignore extra data at the end of the ClientHello message, and obviously >>> non-dns_name servers would only be used in situations where the >>> dns_name extension is not needed (i.e., no name-based virtual >>> hosting). Thus the only configuration that is problematic is when a >>> server requires dns_name, but the client does not support it. This is >>> similar to the HTTP "Host" header situation some time ago. > >> The context of discussion was about dns_name only. >> I.e. the tabulation was only meant for dns_name deployment. >> (What else was the thread about?) > >It is obvious that dns_name can be *used* only if it is supported both >by the client and the server. Since the server implementation should >be selected depending on the needs of the specific site, why is it a >"compatibility" problem that non-dns_name servers would have to ignore >the dns_name extension? First of all, I think the quoted text was taken out of context. For starter, the sentence where I made my point had been omitted. (The quoted part was only the preamble.) My point was to appeal to vendors to do the best they can to mitigate the migration pain, as migrate we must, having established dns_name is worth doing. I might be guilty of overstating the obvious. But hey, traffic signs too are obvious, yet accidents abound. Look where we're at now with this thread, where not everything was made perfectly clear. Why a problem? Suffice to say, as long as the dns_name-server:dns_name-browsers state hasn't been achieved, we have a problem, practicing secured virtual hosting. I'm comfortable in characterizing the problem as compatibility related, especially during the roll-out stage, taking into consideration of what best to inform the end users during the transition period, e.g. on an http page, say "You need a xyz compatible browser to login. Click here to get the https page, click there to download the xyz patch. blah blah blah ..." This may not be the same characterization of "compatibility" you had in mind. Yours might be more intrinsic to the TLS semantics, I guess. >But TLS extensions can cause compatibility problems even for >connections where they are not needed at all (see my previous >message). When connecting to an HTTPS server, a browser does not know >whether dns_name is required for this specific connection or not. >Thus the dns_name extension would have to appear in *all* connection >attempts (ruling out use of the SSL 2.0 client hello format), and >*this* is a possible source of compatibility nightmares. This is yet another compatibility issue that merits to be addressed in a separate thread. It raises a good point, because we should cover all corners, bending backwards to be backward-compatibility-friendly. Having said that, I should also say, going out on a limp, even contortionists have limits. Extrapolating from the success of the 128-bit roll-out, we may not have to lose sleep over this. E.g. there're more than few 128-bit commercial sites that tell users to upgrade or get lost. So far I've heard no complaints, not to make light of the situation. Now, I think I've gotten enough mileage out of this thread, which has served the purpose of granting dns_name the attention it deserves from vendors/implementers. To continue the discourse on compatibility issues, which appear to be many. I suggest a new thread be created for each of them, for the sake of clarity and posterity. Cheers, 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 Sun Jul 15 00:23: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 AAA21635 for ; Sun, 15 Jul 2001 00:23:39 -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: London Date: Fri, 13 Jul 2001 14:02:55 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: London Thread-Index: AcELvZANq7aipB9rRhyegqVRcuUeWwAAu0wg 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 AAA21635 >From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] > >On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote: >>> From: Bodo Moeller [mailto:moeller@cdc.informatik.tu-darmstadt.de] >>>> Maybe now it's a good time to bring up an issue of compatibility >>>> that may cause grief during the dns_name roll-out: >>>> >>>> dsn_name-server : dns_name-browser, works; >>>> dns_name-server : non-dns_name-browser, doesn't work; >>>> non-dns_name-server : dns_name-browser, doesn't work; >>>> non-dns_name-server : non-dns_name-browser, doesn't work. > >>> This is misleading. SSL 3.0 and TLS 1.0 servers are required to >>> ignore extra data at the end of the ClientHello message, and obviously >>> non-dns_name servers would only be used in situations where the >>> dns_name extension is not needed (i.e., no name-based virtual >>> hosting). Thus the only configuration that is problematic is when a >>> server requires dns_name, but the client does not support it. This is >>> similar to the HTTP "Host" header situation some time ago. > >> The context of discussion was about dns_name only. >> I.e. the tabulation was only meant for dns_name deployment. >> (What else was the thread about?) > >It is obvious that dns_name can be *used* only if it is supported both >by the client and the server. Since the server implementation should >be selected depending on the needs of the specific site, why is it a >"compatibility" problem that non-dns_name servers would have to ignore >the dns_name extension? First of all, I think the quoted text was taken out of context. For starter, the sentence where I made my point had been omitted. (The quoted part was only the preamble.) My point was to appeal to vendors to do the best they can to mitigate the migration pain, as migrate we must, having established dns_name is worth doing. I might be guilty of overstating the obvious. But hey, traffic signs too are obvious, yet accidents abound. Look where we're at now with this thread, where not everything was made perfectly clear. Why a problem? Suffice to say, as long as the dns_name-server:dns_name-browsers state hasn't been achieved, we have a problem, practicing secured virtual hosting. I'm comfortable in characterizing the problem as compatibility related, especially during the roll-out stage, taking into consideration of what best to inform the end users during the transition period, e.g. on an http page, say "You need a xyz compatible browser to login. Click here to get the https page, click there to download the xyz patch. blah blah blah ..." This may not be the same characterization of "compatibility" you had in mind. Yours might be more intrinsic to the TLS semantics, I guess. >But TLS extensions can cause compatibility problems even for >connections where they are not needed at all (see my previous >message). When connecting to an HTTPS server, a browser does not know >whether dns_name is required for this specific connection or not. >Thus the dns_name extension would have to appear in *all* connection >attempts (ruling out use of the SSL 2.0 client hello format), and >*this* is a possible source of compatibility nightmares. This is yet another compatibility issue that merits to be addressed in a separate thread. It raises a good point, because we should cover all corners, bending backwards to be backward-compatibility-friendly. Having said that, I should also say, going out on a limp, even contortionists have limits. Extrapolating from the success of the 128-bit roll-out, we may not have to lose sleep over this. E.g. there're more than few 128-bit commercial sites that tell users to upgrade or get lost. So far I've heard no complaints, not to make light of the situation. Now, I think I've gotten enough mileage out of this thread, which has served the purpose of granting dns_name the attention it deserves from vendors/implementers. To continue the discourse on compatibility issues, which appear to be many. I suggest a new thread be created for each of them, for the sake of clarity and posterity. Cheers, 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 Sun Jul 15 10:12: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 KAA24207 for ; Sun, 15 Jul 2001 10:12:45 -0400 (EDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Sender: bounce-ietf-tls-3458737@lists.certicom.com Reply-To: "IETF Transport Layer Security WG" X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Mon, 16 Jul 2001 02:13:27 (NZST) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <99520640701563@kahu.cs.auckland.ac.nz> X-List-Host: SKYLIST.net Bodo Moeller writes: >SSL 3.0 and TLS 1.0 servers are required to ignore extra data at the end of >the ClientHello message, The servers are required to ignore extra data, and implementors may even have tried to implement this, but until clients come along which include extra data it won't be possible to tell whether they handle this properly or not. It may well be that some widely-deployed server doesn't get it quite right, which will cause serious deployment problems. >TLS extensions can only be used in SSL 3.0 and TLS 1.0 ClientHello messages, >not in SSL 2.0 CLIENT-HELLO messages. While it is time to give up the actual >SSL 2.0 protocol, the SSL 2.0 CLIENT-HELLO format still play an important role >for protocol version negotiation, and handshakes usually start using this >format. Only Netscape does it, I've never seen IE start with v2 (in fact Netscape always sends a v2 hello no matter what you do, even with SSLv2 turned off). Given that IE doesn't send a v2 hello, I think it's safe to assume that everything can handle v3 hellos. Peter. --- 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 Jul 15 18:20:50 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 SAA07963 for ; Sun, 15 Jul 2001 18:20:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] Re: Re: London Date: Sun, 15 Jul 2001 15:20:34 -0700 Message-ID: Thread-Topic: [ietf-tls] Re: Re: London Thread-Index: AcENOEHpnEgUX+JxR+GfOAeoiBq9wgAQtvkQ From: "John Banes" To: "IETF Transport Layer Security WG" X-OriginalArrivalTime: 15 Jul 2001 22:20:34.0493 (UTC) FILETIME=[5DDC9ED0:01C10D7C] List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <4AEE3169443CDD4796CA8A00B02191CD69BFC6@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> 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 SAA07963 > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Sunday, July 15, 2001 7:13 PM > To: IETF Transport Layer Security WG > Subject: [ietf-tls] Re: Re: London > > > Bodo Moeller writes: > > >SSL 3.0 and TLS 1.0 servers are required to ignore extra > data at the end of > >the ClientHello message, > > The servers are required to ignore extra data, and > implementors may even have > tried to implement this, but until clients come along which > include extra data > it won't be possible to tell whether they handle this > properly or not. It may > well be that some widely-deployed server doesn't get it quite > right, which will > cause serious deployment problems. Agreed. Odds are, one or more major SSL server implementations will choke when faced with a client_hello message that contains extra data. > > >TLS extensions can only be used in SSL 3.0 and TLS 1.0 > ClientHello messages, > >not in SSL 2.0 CLIENT-HELLO messages. While it is time to > give up the actual > >SSL 2.0 protocol, the SSL 2.0 CLIENT-HELLO format still play > an important role > >for protocol version negotiation, and handshakes usually > start using this > >format. > > Only Netscape does it, I've never seen IE start with v2 (in > fact Netscape > always sends a v2 hello no matter what you do, even with > SSLv2 turned off). > Given that IE doesn't send a v2 hello, I think it's safe to > assume that > everything can handle v3 hellos. > Internet Explorer sends an SSL2-format client_hello message by default, since the SSL2 protocol is still enabled by default. IE does send an SSL3-format client_hello message if the user has disabled the SSL2 protocol, though. Regards, John Banes Microsoft Corp. > Peter. > > > --- > You are currently subscribed to ietf-tls as: > jbanes@windows.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 From bounce-ietf-tls-3458737@lists.certicom.com Mon Jul 16 04:38:57 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 EAA24680 for ; Mon, 16 Jul 2001 04:38:56 -0400 (EDT) Date: Mon, 16 Jul 2001 10:39:37 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from pgut001@cs.auckland.ac.nz on Mon, Jul 16, 2001 at 02:13:27AM +1200 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010716103937.A21042@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Jul 16, 2001 at 02:13:27AM +1200, Peter Gutmann wrote: >> TLS extensions can only be used in SSL 3.0 and TLS 1.0 ClientHello messages, >> not in SSL 2.0 CLIENT-HELLO messages. While it is time to give up the actual >> SSL 2.0 protocol, the SSL 2.0 CLIENT-HELLO format still play an important role >> for protocol version negotiation, and handshakes usually start using this >> format. > Only Netscape does it, I've never seen IE start with v2 (in fact Netscape > always sends a v2 hello no matter what you do, even with SSLv2 turned off). > Given that IE doesn't send a v2 hello, I think it's safe to assume that > everything can handle v3 hellos. Last I checked (Windows 2000 Professional, IE 5.50.whatever), IE still had SSL 2.0 support enabled by default, so it used the SSL 2.0 CLIENT-HELLO format. If you disabled SSL 2.0 and enabled TLS 1.0 (the latter was disabled by default), it did not use the SSL 3.0 ClientHello format as it should have done, but the TLS 1.0 ClientHello format; that is, the record header contained a 'version' value of {0x03, 0x01}, i.e. the 'client_version' value, while it should contain {0x03, 0x00} for backwards compatibility. With ClientHellos built like this, IE avoided the bug in servers that use 'version' where they should use 'client_version' -- in those ClientHellos, these two were the same value, after all. Using the SSL 3.0 ClientHello format for backwards compatibility may or may not work well in practice. IE does not prove that it does. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 16 09:51: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 JAA11392 for ; Mon, 16 Jul 2001 09:51:18 -0400 (EDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: Re: London Sender: bounce-ietf-tls-3458737@lists.certicom.com Reply-To: "IETF Transport Layer Security WG" X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Tue, 17 Jul 2001 01:52:03 (NZST) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <99529152305432@kahu.cs.auckland.ac.nz> X-List-Host: SKYLIST.net Bodo Moeller writes: >Last I checked (Windows 2000 Professional, IE 5.50.whatever), IE still had SSL >2.0 support enabled by default, so it used the SSL 2.0 CLIENT-HELLO format. Ah, sorry, my message wasn't very clear: If you disable SSLv2 (which I always do), MSIE works as expected but Netscape still sends an SSLv2 handshake. >If you disabled SSL 2.0 and enabled TLS 1.0 (the latter was disabled by >default), it did not use the SSL 3.0 ClientHello format as it should have >done, but the TLS 1.0 ClientHello format; that is, the record header contained >a 'version' value of {0x03, 0x01}, i.e. the 'client_version' value, while it >should contain {0x03, 0x00} for backwards compatibility. That's correct isn't it? RFC 2246 says: TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol. (Why is TLS disabled by default in MSIE? I always enable it at the same time I disable SSLv2, and it's never caused me any problems). Peter. --- 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 Jul 16 10:09: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 KAA15654 for ; Mon, 16 Jul 2001 10:09:18 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 07:16:42 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 10:39:37 +0200" 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 Bodo Moeller writes: > Last I checked (Windows 2000 Professional, IE 5.50.whatever), IE still > had SSL 2.0 support enabled by default, so it used the SSL 2.0 > CLIENT-HELLO format. If you disabled SSL 2.0 and enabled TLS 1.0 (the > latter was disabled by default), it did not use the SSL 3.0 > ClientHello format as it should have done, but the TLS 1.0 ClientHello > format; that is, the record header contained a 'version' value of > {0x03, 0x01}, i.e. the 'client_version' value, while it should contain > {0x03, 0x00} for backwards compatibility. This sounds like the correct behavior to me. > With ClientHellos built like this, IE avoided the bug in servers that > use 'version' where they should use 'client_version' -- in those > ClientHellos, these two were the same value, after all. As I understood it, the client_version/version problem was about checking in the PMS decryption process. Is there any server which is confused about version checking in the record layer? -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 Jul 16 10:26: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 KAA19314 for ; Mon, 16 Jul 2001 10:26:45 -0400 (EDT) Date: Mon, 16 Jul 2001 16:27:34 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from ekr@speedy.rtfm.com on Mon, Jul 16, 2001 at 07:16:42AM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010716162734.A22489@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Jul 16, 2001 at 07:16:42AM -0700, Eric Rescorla wrote: > Bodo Moeller writes: >> Last I checked (Windows 2000 Professional, IE 5.50.whatever), IE still >> had SSL 2.0 support enabled by default, so it used the SSL 2.0 >> CLIENT-HELLO format. If you disabled SSL 2.0 and enabled TLS 1.0 (the >> latter was disabled by default), it did not use the SSL 3.0 >> ClientHello format as it should have done, but the TLS 1.0 ClientHello >> format; that is, the record header contained a 'version' value of >> {0x03, 0x01}, i.e. the 'client_version' value, while it should contain >> {0x03, 0x00} for backwards compatibility. > This sounds like the correct behavior to me. Which one? RFC 2246 appendix E says that the SSL 3.0 record format should be used for connection attempts if SSL 3.0 backwards compatibility is desired. Thus 'version' in the record headers ('The version of the protocol being employed') should be {0x03, 0x00}, while 'client_version' in the actual ClientHello message ('The version of the TLS protocol by which the client wishes to communicate during this session') must be {0x03, 0x01}. Of course, as long as ClientHello formats stay consistent, servers can simply ignore the minor digit of the record header 'version' field. >> With ClientHellos built like this, IE avoided the bug in servers that >> use 'version' where they should use 'client_version' -- in those >> ClientHellos, these two were the same value, after all. > As I understood it, the client_version/version problem was about > checking in the PMS decryption process. Is there any server which > is confused about version checking in the record layer? I'm not sure I understand this question. If a server uses 'version' instead of 'client_version' for premaster secret decryption verification and the values odiffer, then the handshake quite simply will fail. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 16 10:41:15 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23026 for ; Mon, 16 Jul 2001 10:41:14 -0400 (EDT) Date: Mon, 16 Jul 2001 16:42:01 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from pgut001@cs.auckland.ac.nz on Tue, Jul 17, 2001 at 01:52:03AM +1200 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010716164200.B22489@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Tue, Jul 17, 2001 at 01:52:03AM +1200, Peter Gutmann wrote: >> If you disabled SSL 2.0 and enabled TLS 1.0 (the latter was disabled by >> default), it did not use the SSL 3.0 ClientHello format as it should have >> done, but the TLS 1.0 ClientHello format; that is, the record header contained >> a 'version' value of {0x03, 0x01}, i.e. the 'client_version' value, while it >> should contain {0x03, 0x00} for backwards compatibility. > That's correct isn't it? RFC 2246 says: > > TLS clients who wish to negotiate with SSL 3.0 servers should send client > hello messages using the SSL 3.0 record format and client hello structure, > sending {3, 1} for the version field to note that they support TLS 1.0. If > the server supports only SSL 3.0, it will respond with an SSL 3.0 server > hello; if it supports TLS, with a TLS server hello. The negotiation then > proceeds as appropriate for the negotiated protocol. 'The version field' is singular, so this refers just to the version field of the ClientHello message, i.e. client_version. The complete wording 'sending {3, 1} for the version field to note that they support TLS 1.0' also suggests that this is about client_version, because client_version's purpose is to name 'the latest (highest valued) version supported by the client'. The record header 'version' field names '[the] version of the protocol being employed', i.e. 3.0 in this case. Otherwise it would be the TLS 1.0 record format, not the SSL 3.0 record format. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 16 10:51: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 KAA25506 for ; Mon, 16 Jul 2001 10:51:38 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 07:59:08 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 16:27:34 +0200" Message-ID: Lines: 60 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 Bodo Moeller writes: > Which one? RFC 2246 appendix E says that the SSL 3.0 record format > should be used for connection attempts if SSL 3.0 backwards > compatibility is desired. Thus 'version' in the record headers ('The > version of the protocol being employed') should be {0x03, 0x00}, while > 'client_version' in the actual ClientHello message ('The version of > the TLS protocol by which the client wishes to communicate during this > session') must be {0x03, 0x01}. Of course, as long as ClientHello > formats stay consistent, servers can simply ignore the minor digit of > the record header 'version' field. Actually, I'm not sure that I read it this way. Here's the text: TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0. If the server supports only SSL 3.0, it will respond with an SSL 3.0 server hello; if it supports TLS, with a TLS server hello. The negotiation then proceeds as appropriate for the negotiated protocol. It seems to me that one could read this as indicating that you should use the SSLv3 record format but substitute the version field (which would make it the TLS record format, I suppose). Perhaps we should ask what the desired behavior is so we can fix it before we go to Draft. > >> With ClientHellos built like this, IE avoided the bug in servers that > >> use 'version' where they should use 'client_version' -- in those > >> ClientHellos, these two were the same value, after all. > > > As I understood it, the client_version/version problem was about > > checking in the PMS decryption process. Is there any server which > > is confused about version checking in the record layer? > > I'm not sure I understand this question. If a server uses 'version' > instead of 'client_version' for premaster secret decryption > verification and the values odiffer, then the handshake quite simply > will fail. There are a number of values to consider (1) The version number in the record header of the client_hello (2) The version number in the client_hello message (the client_version) (3) The negotiated version (in the server_hello) (4) The version number in the record header of server_hello and subsequent messages. (5) The version number in the PMS. The client is supposed to use value 2 in the PMS. I would expect the server to compare it against either value 2 (correctly) or value 3 (incorrectly). In either case, I don't see why the contents of the client_hello record header should cause a problem for this comparison. On the other hand, the server might check value 1 against his highest supported version and send an alert prior to sending the server hello. Have I missed something? -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 Jul 16 11:05:41 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 LAA28186 for ; Mon, 16 Jul 2001 11:05:40 -0400 (EDT) Date: Mon, 16 Jul 2001 17:06:28 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from ekr@speedy.rtfm.com on Mon, Jul 16, 2001 at 07:59:08AM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010716170628.A22621@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: [...] >>>> With ClientHellos built like this, IE avoided the bug in servers that >>>> use 'version' where they should use 'client_version' -- in those >>>> ClientHellos, these two were the same value, after all. >>> As I understood it, the client_version/version problem was about >>> checking in the PMS decryption process. Is there any server which >>> is confused about version checking in the record layer? >> I'm not sure I understand this question. If a server uses 'version' >> instead of 'client_version' for premaster secret decryption >> verification and the values odiffer, then the handshake quite simply >> will fail. > There are a number of values to consider > (1) The version number in the record header of the client_hello > (2) The version number in the client_hello message (the client_version) > (3) The negotiated version (in the server_hello) > (4) The version number in the record header of server_hello > and subsequent messages. > (5) The version number in the PMS. > > The client is supposed to use value 2 in the PMS. I would expect > the server to compare it against either value 2 (correctly) or > value 3 (incorrectly). In either case, I don't see why the contents > of the client_hello record header should cause a problem for this > comparison. Some servers (including all version of SSLeay with SSL 3.0 support and OpenSSL before release 0.9.5) use the version number from the ClientHello's record header when they should have used the client_version value appearing in the actual message. If the former is lower than the latter, the server will negotiate the wrong version, which breaks the handshake in the case of ciphersuites with RSA-encrypted premaster secrets. > On the other hand, the server might check value 1 against his > highest supported version and send an alert prior to sending the > server hello. Exactly; this is why clients probably should use the lower version number in the record header. (But servers shouldn't really insist on any particular minor version number in the record headers -- there does not appear to be any advantage in looking at this value.) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 16 11:16:29 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 LAA00917 for ; Mon, 16 Jul 2001 11:16:28 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 08:23:58 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 17:06:28 +0200" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bodo Moeller writes: > On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: > > The client is supposed to use value 2 in the PMS. I would expect > > the server to compare it against either value 2 (correctly) or > > value 3 (incorrectly). In either case, I don't see why the contents > > of the client_hello record header should cause a problem for this > > comparison. > > Some servers (including all version of SSLeay with SSL 3.0 support and > OpenSSL before release 0.9.5) use the version number from the > ClientHello's record header when they should have used the > client_version value appearing in the actual message. If the former > is lower than the latter, the server will negotiate the wrong version, > which breaks the handshake in the case of ciphersuites with > RSA-encrypted premaster secrets. I see. Interesting bug. I thought you were talking about a different PMS-related bug--using the negotiated version instead of the client's offered version for the PMS version. This bug can happen even if the record version number and the client_version are the same. > > On the other hand, the server might check value 1 against his > > highest supported version and send an alert prior to sending the > > server hello. > > Exactly; this is why clients probably should use the lower version > number in the record header. (But servers shouldn't really insist on > any particular minor version number in the record headers -- there > does not appear to be any advantage in looking at this value.) I agree. -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 Jul 16 11:58: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 LAA08648 for ; Mon, 16 Jul 2001 11:58:04 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 08:23:58 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 17:06:28 +0200" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bodo Moeller writes: > On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: > > The client is supposed to use value 2 in the PMS. I would expect > > the server to compare it against either value 2 (correctly) or > > value 3 (incorrectly). In either case, I don't see why the contents > > of the client_hello record header should cause a problem for this > > comparison. > > Some servers (including all version of SSLeay with SSL 3.0 support and > OpenSSL before release 0.9.5) use the version number from the > ClientHello's record header when they should have used the > client_version value appearing in the actual message. If the former > is lower than the latter, the server will negotiate the wrong version, > which breaks the handshake in the case of ciphersuites with > RSA-encrypted premaster secrets. I see. Interesting bug. I thought you were talking about a different PMS-related bug--using the negotiated version instead of the client's offered version for the PMS version. This bug can happen even if the record version number and the client_version are the same. > > On the other hand, the server might check value 1 against his > > highest supported version and send an alert prior to sending the > > server hello. > > Exactly; this is why clients probably should use the lower version > number in the record header. (But servers shouldn't really insist on > any particular minor version number in the record headers -- there > does not appear to be any advantage in looking at this value.) I agree. -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 Jul 16 14:02: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 OAA06805 for ; Mon, 16 Jul 2001 14:02:37 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 08:23:58 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 17:06:28 +0200" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bodo Moeller writes: > On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: > > The client is supposed to use value 2 in the PMS. I would expect > > the server to compare it against either value 2 (correctly) or > > value 3 (incorrectly). In either case, I don't see why the contents > > of the client_hello record header should cause a problem for this > > comparison. > > Some servers (including all version of SSLeay with SSL 3.0 support and > OpenSSL before release 0.9.5) use the version number from the > ClientHello's record header when they should have used the > client_version value appearing in the actual message. If the former > is lower than the latter, the server will negotiate the wrong version, > which breaks the handshake in the case of ciphersuites with > RSA-encrypted premaster secrets. I see. Interesting bug. I thought you were talking about a different PMS-related bug--using the negotiated version instead of the client's offered version for the PMS version. This bug can happen even if the record version number and the client_version are the same. > > On the other hand, the server might check value 1 against his > > highest supported version and send an alert prior to sending the > > server hello. > > Exactly; this is why clients probably should use the lower version > number in the record header. (But servers shouldn't really insist on > any particular minor version number in the record headers -- there > does not appear to be any advantage in looking at this value.) I agree. -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 Jul 16 15:03: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 PAA18096 for ; Mon, 16 Jul 2001 15:03:19 -0400 (EDT) content-class: urn:content-classes:message Subject: [ietf-tls] Re:London Date: Mon, 16 Jul 2001 14:03:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: London X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEOKhGMjKNWW3l1EdWmrgAIx0X1pw== From: To: "IETF Transport Layer Security WG" X-OriginalArrivalTime: 16 Jul 2001 19:03:59.0016 (UTC) FILETIME=[119F6A80:01C10E2A] List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <57A26D272F67A743952F6B4371B8F811063232@daebe007.NOE.Nokia.com> 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 PAA18096 David, Thank you for your thoughts on the dns_name extension. Do you have any comments/plans for the other extensions (which were previously referred to as wireless extensions)? Your message only mentions dns_name which is one specific extension defined in draft-ietf-tls-extensions-00.txt. Nokia Mobile: (607)227-2933 e-mail: maureen.stillman@nokia.com -----Original Message----- From: ext David Mowers To: IETF Transport Layer Security WG Sent: 7/12/01 1:08 PM Subject: [ietf-tls] Re: London First, an introduction: I took over Program Manager responsibilities for SChannel, Microsoft's implementation of SSL/TLS, last year. I work with John Banes, our principal Developer for SSL/TLS, in the Windows Security team. As I settle into my position here at Microsoft, I am looking forward to taking a more active role in this working group and helping out where possible in the ongoing efforts to improve TLS. Back to the issue: It's hard to predict when Microsoft will implement and deploy the dns_name extension although it is getting a very close look. I don't think that incrementing the version number will have much of an effect either way, though, so don't let that turn into a blocking issue. Deploying this change in the context of HTTP over TLS (HTTPS) is going to take some time. Changing the format of the client_hello message has historically caused lots of grief and various compatibility problems. There are a lot of internet servers out there and just testing against them all is a very large effort.=20 I think this change is worth doing, but it is going to take some time. David Mowers Program Manager Windows Security --- 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 Jul 16 18:14:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21485 for ; Mon, 16 Jul 2001 18:14:11 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 08:23:58 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 17:06:28 +0200" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bodo Moeller writes: > On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: > > The client is supposed to use value 2 in the PMS. I would expect > > the server to compare it against either value 2 (correctly) or > > value 3 (incorrectly). In either case, I don't see why the contents > > of the client_hello record header should cause a problem for this > > comparison. > > Some servers (including all version of SSLeay with SSL 3.0 support and > OpenSSL before release 0.9.5) use the version number from the > ClientHello's record header when they should have used the > client_version value appearing in the actual message. If the former > is lower than the latter, the server will negotiate the wrong version, > which breaks the handshake in the case of ciphersuites with > RSA-encrypted premaster secrets. I see. Interesting bug. I thought you were talking about a different PMS-related bug--using the negotiated version instead of the client's offered version for the PMS version. This bug can happen even if the record version number and the client_version are the same. > > On the other hand, the server might check value 1 against his > > highest supported version and send an alert prior to sending the > > server hello. > > Exactly; this is why clients probably should use the lower version > number in the record header. (But servers shouldn't really insist on > any particular minor version number in the record headers -- there > does not appear to be any advantage in looking at this value.) I agree. -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 Jul 17 02:23:59 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 CAA01333 for ; Tue, 17 Jul 2001 02:23:59 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 08:23:58 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 17:06:28 +0200" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bodo Moeller writes: > On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: > > The client is supposed to use value 2 in the PMS. I would expect > > the server to compare it against either value 2 (correctly) or > > value 3 (incorrectly). In either case, I don't see why the contents > > of the client_hello record header should cause a problem for this > > comparison. > > Some servers (including all version of SSLeay with SSL 3.0 support and > OpenSSL before release 0.9.5) use the version number from the > ClientHello's record header when they should have used the > client_version value appearing in the actual message. If the former > is lower than the latter, the server will negotiate the wrong version, > which breaks the handshake in the case of ciphersuites with > RSA-encrypted premaster secrets. I see. Interesting bug. I thought you were talking about a different PMS-related bug--using the negotiated version instead of the client's offered version for the PMS version. This bug can happen even if the record version number and the client_version are the same. > > On the other hand, the server might check value 1 against his > > highest supported version and send an alert prior to sending the > > server hello. > > Exactly; this is why clients probably should use the lower version > number in the record header. (But servers shouldn't really insist on > any particular minor version number in the record headers -- there > does not appear to be any advantage in looking at this value.) I agree. -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 Jul 17 18:33: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 SAA29174 for ; Tue, 17 Jul 2001 18:33:31 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 16 Jul 2001 08:23:58 -0700 In-Reply-To: Bodo Moeller's message of "Mon, 16 Jul 2001 17:06:28 +0200" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bodo Moeller writes: > On Mon, Jul 16, 2001 at 07:59:08AM -0700, Eric Rescorla wrote: > > The client is supposed to use value 2 in the PMS. I would expect > > the server to compare it against either value 2 (correctly) or > > value 3 (incorrectly). In either case, I don't see why the contents > > of the client_hello record header should cause a problem for this > > comparison. > > Some servers (including all version of SSLeay with SSL 3.0 support and > OpenSSL before release 0.9.5) use the version number from the > ClientHello's record header when they should have used the > client_version value appearing in the actual message. If the former > is lower than the latter, the server will negotiate the wrong version, > which breaks the handshake in the case of ciphersuites with > RSA-encrypted premaster secrets. I see. Interesting bug. I thought you were talking about a different PMS-related bug--using the negotiated version instead of the client's offered version for the PMS version. This bug can happen even if the record version number and the client_version are the same. > > On the other hand, the server might check value 1 against his > > highest supported version and send an alert prior to sending the > > server hello. > > Exactly; this is why clients probably should use the lower version > number in the record header. (But servers shouldn't really insist on > any particular minor version number in the record headers -- there > does not appear to be any advantage in looking at this value.) I agree. -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 Jul 17 23:11: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 XAA23033 for ; Tue, 17 Jul 2001 23:11:27 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] Re:London Date: Tue, 17 Jul 2001 20:12:08 -0700 Message-ID: Thread-Topic: London Thread-Index: AcEOKhGMjKNWW3l1EdWmrgAIx0X1pwBCvg5g From: "David Mowers" To: "IETF Transport Layer Security WG" X-OriginalArrivalTime: 18 Jul 2001 03:12:08.0917 (UTC) FILETIME=[6E2D6050:01C10F37] List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <0170DDAD0BADFA4CBEC3B55A0748DCCC03C74256@red-msg-02.redmond.corp.microsoft.com> 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 XAA23033 Hi, No comments at this time. Microsoft has several groups implementing SSL/TLS for wireless technologies and we need to mull over these ideas for a bit. Thanks, Dave -----Original Message----- From: Maureen.Stillman@nokia.com [mailto:Maureen.Stillman@nokia.com] Sent: Monday, July 16, 2001 12:04 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re:London David, Thank you for your thoughts on the dns_name extension. Do you have any comments/plans for the other extensions (which were previously referred to as wireless extensions)? Your message only mentions dns_name which is one specific extension defined in draft-ietf-tls-extensions-00.txt. Nokia Mobile: (607)227-2933 e-mail: maureen.stillman@nokia.com -----Original Message----- From: ext David Mowers To: IETF Transport Layer Security WG Sent: 7/12/01 1:08 PM Subject: [ietf-tls] Re: London First, an introduction: I took over Program Manager responsibilities for SChannel, Microsoft's implementation of SSL/TLS, last year. I work with John Banes, our principal Developer for SSL/TLS, in the Windows Security team. As I settle into my position here at Microsoft, I am looking forward to taking a more active role in this working group and helping out where possible in the ongoing efforts to improve TLS. Back to the issue: It's hard to predict when Microsoft will implement and deploy the dns_name extension although it is getting a very close look. I don't think that incrementing the version number will have much of an effect either way, though, so don't let that turn into a blocking issue. Deploying this change in the context of HTTP over TLS (HTTPS) is going to take some time. Changing the format of the client_hello message has historically caused lots of grief and various compatibility problems. There are a lot of internet servers out there and just testing against them all is a very large effort.=20 I think this change is worth doing, but it is going to take some time. David Mowers Program Manager Windows Security --- You are currently subscribed to ietf-tls as: davemo@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 From bounce-ietf-tls-3458737@lists.certicom.com Wed Jul 18 16:42: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 QAA28821 for ; Wed, 18 Jul 2001 16:42:54 -0400 (EDT) Errors-To: Reply-To: "IETF Transport Layer Security WG" From: "imran badr" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Some questions about tls handshake Date: Wed, 18 Jul 2001 13:42:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <002c01c10fca$38e162f0$6401a8c0@IMRANPC> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hi, I am studying TLS1.0. I have some questions about handshake, rehandshake, session resumption etc. I looked at many resources (rfc, books, internet links) but couldn't find answer to the following questions. I apologize to interrupt everyone with this mesage but unfortunately I couldn't thought of any other way than to ask for help from the ietf woking group. I will be grateful if anyone helps. * On a TLS session resumption, partial handshake hashes doesnot include the handshake messages from the prior full handshake. Is that true? * Suppose that a renegotiation/rehandshake occurs after a full handshake. Does the handshake hash for the renegotiation/rehandshake have to include the handshake messages of the prior full handshake? * What if another renegotiation/rehandshake occurs? Does the handshake hash include both the prior full handshake and renegotiation/rehandshake? * Same question when a renegotiation/rehandshake occurs after a resume. Does the renegotiation/rehandshake then include the handshake messages from the prior resume? What if another one happens? Thanks, Imran Badr. --- 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 Jul 18 16:53:53 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 QAA00853 for ; Wed, 18 Jul 2001 16:53:52 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Some questions about tls handshake 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 Jul 2001 14:01:27 -0700 In-Reply-To: "imran badr"'s message of "Wed, 18 Jul 2001 13:42:54 -0700" 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 "imran badr" writes: > I am studying TLS1.0. I have some questions about handshake, rehandshake, > session resumption etc. I looked at many resources (rfc, books, internet > links) but couldn't find answer to the following questions. I apologize to > interrupt everyone with this mesage but unfortunately I couldn't thought of > any other way than to ask for help from the ietf woking group. I will be > grateful if anyone helps. > > * On a TLS session resumption, partial handshake hashes doesnot include the > handshake messages from the prior full handshake. Is that true? Correct. The handshake hashes for any given handshake only include the data from that handshake. > * Suppose that a renegotiation/rehandshake occurs after a full handshake. > Does the handshake hash for the renegotiation/rehandshake have to include > the handshake messages of the prior full handshake? No. > * What if another renegotiation/rehandshake occurs? Does the handshake hash > include both the prior full handshake and renegotiation/rehandshake? No. > * Same question when a renegotiation/rehandshake occurs after a resume. Does > the renegotiation/rehandshake then include the handshake messages from the > prior resume? What if another one happens? No. -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 Jul 18 17:52:02 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 RAA13040 for ; Wed, 18 Jul 2001 17:52:01 -0400 (EDT) From: "Rene G. Eberhard" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: Some questions about tls handshake Date: Wed, 18 Jul 2001 23:11:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: 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 RAA13040 > I am studying TLS1.0. I have some questions about handshake, rehandshake, > session resumption etc. I looked at many resources (rfc, books, internet > links) but couldn't find answer to the following questions. I apologize to > interrupt everyone with this mesage but unfortunately I couldn't > thought of > any other way than to ask for help from the ietf woking group. I will be > grateful if anyone helps. > > * On a TLS session resumption, partial handshake hashes doesnot > include the > handshake messages from the prior full handshake. Is that true? Yes. > * Suppose that a renegotiation/rehandshake occurs after a full handshake. > Does the handshake hash for the renegotiation/rehandshake have to include > the handshake messages of the prior full handshake? No. Renegotiation is similar (equal) to a full (new) handshake. > * What if another renegotiation/rehandshake occurs? Does the > handshake hash > include both the prior full handshake and renegotiation/rehandshake? No, just the handshake messages of the current (latest) renegotiation. > * Same question when a renegotiation/rehandshake occurs after a > resume. Does > the renegotiation/rehandshake then include the handshake messages from the > prior resume? What if another one happens? No. Just hash everything from the client hello up to (but not including) the finished message. (See also RFC 2246 7.4.9. Finished) Regards Rene -- Rene G. Eberhard keyon > the PKI experts Herrenberg 35, CH-8640 Rapperswil, Switzerland Phone +41 (0)55 220 71 63, Fax +41 (0)55 220 71 61 See www.keyon.ch, www.tess.ch and www.freecerts.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 Jul 19 04:52:55 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02532 for ; Thu, 19 Jul 2001 04:52:54 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Some questions about tls handshake Date: Thu, 19 Jul 2001 18:58:09 +1000 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.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: <001901c11030$f21ce8a0$9f418990@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > I am studying TLS1.0. I have some questions about handshake, rehandshake, > session resumption etc. I looked at many resources (rfc, books, internet > links) but couldn't find answer to the following questions. I apologize to > interrupt everyone with this mesage but unfortunately I couldn't thought of > any other way than to ask for help from the ietf woking group. I will be > grateful if anyone helps. > > * On a TLS session resumption, partial handshake hashes doesnot include the > handshake messages from the prior full handshake. Is that true? > > * Suppose that a renegotiation/rehandshake occurs after a full handshake. > Does the handshake hash for the renegotiation/rehandshake have to include > the handshake messages of the prior full handshake? > > * What if another renegotiation/rehandshake occurs? Does the handshake hash > include both the prior full handshake and renegotiation/rehandshake? > > * Same question when a renegotiation/rehandshake occurs after a resume. Does > the renegotiation/rehandshake then include the handshake messages from the > prior resume? What if another one happens? As Eric said, no in all cases. Something else to note is that the mechanism for reusing session information for a new connection and renegotiating the keys in use on an existing connection (resumption and renegotiation/rehandshake) are exactly the same mechanism. Regards, David Taylor. --- 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 Jul 19 16:21:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07151 for ; Thu, 19 Jul 2001 16:21:12 -0400 (EDT) Errors-To: Reply-To: "IETF Transport Layer Security WG" From: "imran badr" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Some questions about tls handshake Date: Thu, 19 Jul 2001 13:20:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <000801c11090$4dee9160$6401a8c0@IMRANPC> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Thanks for all your resplies. It looks like that there is no need to include server finish ( on a server ) in the partial handshake hashes and to remember the states of SHA1 and MD5 handshake hashes once you have sent out server finish. But some implementations like openSSL include server finish to handshake hashes although there is no protocol requiremenet to do so. Is that right? Does these rules apply to SSL3.0 also? Best regards, Imran Badr. -----Original Message----- From: bounce-ietf-tls-4298017@lists.certicom.com [mailto:bounce-ietf-tls-4298017@lists.certicom.com]On Behalf Of David Taylor Sent: Thursday, July 19, 2001 1:58 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: Some questions about tls handshake > I am studying TLS1.0. I have some questions about handshake, rehandshake, > session resumption etc. I looked at many resources (rfc, books, internet > links) but couldn't find answer to the following questions. I apologize to > interrupt everyone with this mesage but unfortunately I couldn't thought of > any other way than to ask for help from the ietf woking group. I will be > grateful if anyone helps. > > * On a TLS session resumption, partial handshake hashes doesnot include the > handshake messages from the prior full handshake. Is that true? > > * Suppose that a renegotiation/rehandshake occurs after a full handshake. > Does the handshake hash for the renegotiation/rehandshake have to include > the handshake messages of the prior full handshake? > > * What if another renegotiation/rehandshake occurs? Does the handshake hash > include both the prior full handshake and renegotiation/rehandshake? > > * Same question when a renegotiation/rehandshake occurs after a resume. Does > the renegotiation/rehandshake then include the handshake messages from the > prior resume? What if another one happens? As Eric said, no in all cases. Something else to note is that the mechanism for reusing session information for a new connection and renegotiating the keys in use on an existing connection (resumption and renegotiation/rehandshake) are exactly the same mechanism. Regards, David Taylor. --- You are currently subscribed to ietf-tls as: imran.badr@caveonetworks.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 Jul 19 16:29:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08607 for ; Thu, 19 Jul 2001 16:29:44 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Some questions about tls handshake 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 Jul 2001 13:37:21 -0700 In-Reply-To: "imran badr"'s message of "Thu, 19 Jul 2001 13:20:50 -0700" Message-ID: Lines: 33 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 "imran badr" writes: > Thanks for all your resplies. > > It looks like that there is no need to include server finish ( on a server ) > in the partial handshake hashes and to remember the states of SHA1 and MD5 > handshake hashes once you have sent out server finish. But some > implementations like openSSL include server finish to handshake hashes > although there is no protocol requiremenet to do so. Is that right? Does > these rules apply to SSL3.0 also? In normal mode the client's Finished message must be included in a handshake hash but the server's Finished is not. In resumed mode the server's Finished message gets hashed and the client's does not. However, as a matter of programming convenience, some implementations might simply choose to digest all the handshake messages--even though the digest may be thrown away without being used. E.g. rather than having: if(certain conditions){ hash_update(message); } one just does: hash_update(message); Note that even if an implementation behaves in this way the data that it transmits will remain the same. As far as this goes, SSLv3 has the same semantics as TLS. -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 Fri Jul 20 00:35: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 AAA28864 for ; Fri, 20 Jul 2001 00:35:51 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Last call: AES ciphersuites for TLS Date: Fri, 20 Jul 2001 00:33:29 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107200433.f6K4XT814589@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This is a working group Last Call for draft-ietf-tls-ciphersuite-04.txt to be submitted to the IESG for Proposed Standard. It incorporates the changes to use OAEP for RSA. Because there were no other unresolved issues on this draft in the original Last Call, this is a one-week Last Call. Thanks, 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 Fri Jul 20 00:36:35 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 AAA29085 for ; Fri, 20 Jul 2001 00:36:34 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] getting RFC 2246 to Draft Standard Date: Fri, 20 Jul 2001 00:34:25 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107200434.f6K4YP314602@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net am pleased to announce that Eric Rescorla has agreed to work with Tim Dierks on revising RFC 2246 for progression to Draft Standard. As we have discussed before, the primary goal of this work is to advance the standard, rather than making substantial changes to the protocol. We will, of course, continue discussions of such changes, such as the extensions proposal, and some of those may advance on the standards track as well. We will have some discussion of this Draft Standard work in London; in the meantime, I'd like to ask that anyone with suggestions for changes to RFC 2246 please send them to the list (or, for minor items, to Eric, Tim, and me). Thanks to Eric for agreeing to help with this work. 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 Fri Jul 20 05:44: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 FAA09583 for ; Fri, 20 Jul 2001 05:44:02 -0400 (EDT) Message-ID: Date: Fri, 20 Jul 2001 10:43:45 +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: AES, OAEP, and TLS 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: <3B57FD51.5FB2ADFA@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 FAA09583 -----BEGIN PGP SIGNED MESSAGE----- Win Treese wrote: > Since I understood that NIST was encouraging the use of OAEP with AES > cryptosystems, I asked Tim Polk at NIST for some more > background. Here's what he said: > > The basic NIST position is that the standard PKCS #1 V1.5 padding can > and should be improved upon. As we transition to AES, we are already > needing to support bigger keys, etc. so it makes sense to upgrade the > padding at the same time. We could probably argue forever about > padding schemes, but OAEP presents a clear improvement that everyone > should be able to support. In general, I'd strongly advise the people at NIST to read Victor Shoup's paper [Sho01], and consider advocating Simple-RSA as another option to RSA-OAEP. The main reason for that is that it provides non-malleability for an arbitrarily long message, which is not achieved just by using RSA-OAEP to encrypt a symmetric key. It's also simpler, and therefore probably less vulnerable to the kind of implementation problems mentioned in James Manger's recent paper [Man01]. The fact that the security reduction is 'tighter' is a useful bonus, although the preceding two reasons are more important in practice. I don't know Tim Polk's address; perhaps you could forward this post to him. However, that's almost beside the point for TLS: RFC 2246 already has an effective and provably secure (see below) fix to PKCS #1 v1.5. Using that fix was a good solution to Bleichenbacher's attack because it minimised interoperability problems. I've checked that the proof of Simple-RSA in [Sho01] can be applied almost unchanged, treating the RSA key exchange as a Key Encapsulation Mechanism [*1]. This assumes that the computation of the handshake hashes can be modelled as a random oracle, which is reasonable. The tightness of the reduction will be worse than for Simple-RSA by a constant factor (for the single encryption attack model), because the PKCS #1 v1.5 formatting and the non-random version number mean that the block is not uniformly distributed on [0, n), but it will still be better than the reduction given by the OAEP proof [*2]. (Incidentally, the nBound/q_D term in equation (8) of [Sho01] should be q_D/nBound. This is such a strange error to make, that I think perhaps Shoup may be checking whether anyone is actually paying attention to the detail of security proofs.) [*1] Technically, this doesn't prove non-malleability of the version number encrypted with the pre-master secret. There are good reasons to believe that that isn't a problem, and I was going to work the details more thoroughly before posting - but I'd better send this post now, given the limited time for the final call of the AES draft. [*2] ... unless the pre-master secret is replaced by a random value when OAEP unpadding fails (i.e. the same method as used for PKCS #1), in which case the reduction for this variant of OAEP is as tight as Simple-RSA. It's also necessary to consider the effect on the security of TLS against compromise attacks - that is, in the situation where an attacker gets access to the server, but can only make queries to a protected security module, and the goal is to obtain enough information to impersonate the server after access is lost. I haven't had time to study this in as much detail as I'd like, but it appears that the choice of RSA-OAEP vs PKCS #1 v1.5 makes no difference here, assuming the Gap RSA Assumption. (If the Gap RSA Assumption is false, OTOH, then TLS's security against compromise attacks is non-existant, and fixing that would require major changes.) > The NIST strategy for RSA-based key management in AES ciphersuites > will utilize OAEP padding. We presume these cryptographic modules > will be used to support a variety of protocols, so we want a padding > technique that is secure for the broadest range of protocols. For new protocols, or for protocols where there is no good backward- compatible fix to existing security problems, I agree entirely with the second sentence above (except that I think Simple-RSA would better satisfy that goal). If, OTOH, it is interpreted as meaning that existing uses of RSA are to be replaced with RSA-OAEP (or any other scheme) without looking carefully at the costs and benefits in each case, then I would have to disagree, strongly. > The advantages of OAEP may not be relevant in some protocols, but it > doesn't seem to present any problem in those protocols. It does present problems in many protocols (the first two of these don't apply to TLS): 1. How do you encrypt messages that do not fit in one block? (Just replacing hybrid use of PKCS #1 v1.5 with OAEP is almost always the wrong answer.) 2. How do you negotiate the use of RSA-OAEP as opposed to whatever was used before? (This is *very easy* to get wrong. Adding a negotiation mechanism to a protocol that didn't previously have one is one of the most complicated and error-prone parts of protocol design. TLS's negotiation mechanism is has had more analysis than that of any other protocol I've seen, and it still has known security flaws, even though negotiation was designed into SSL 2.0 from the start.) 3. When a hardware security module is used, the 'padding' and 'unpadding' parts of OAEP should normally be implemented together with the RSA operation inside the module, but they *can* also be implemented outside the module. The latter would be implementable given existing hardware that doesn't directly support OAEP, but it might well be less secure in some situations, or require stronger assumptions than the standard RSA problem. So, should it be prohibited? (The answer requires a careful analysis of the whole protocol, which hasn't been done for TLS.) 4. The description of how to do OAEP 'unpadding' in PKCS #1 v2.0 and IEEE Std 1363-2000 does not give the best order of operations to avoid side channel attacks, so do you reference a standard that you know is not optimal? This is not academic; unless RSA-OAEP is very carefully implemented, in some entirely plausible situations a timing attack (or certain other kinds of side channel attack) against it can require fewer messages than a corresponding attack on PKCS #1 v1.5 [Man01]. A description of how to implement the OAEP unpadding function that should be used instead of the one given by PKCS #1 v2 and 1363-2000, to minimise the possibility of this kind of attack, is given at the end of this post. (I've checked the details of this with James Manger.) [...] > NIST is also working to promote this position in the ANSI X9 standards > community, in particular on the ANSI X9.44 RSA Key Management > standard. We would like to see standards in the IETF like TLS specify > consistent ciphersuites as well. Consistency certainly has some benefits. However, it's never one of the primary goals of a security protocol: those are that the protocol is secure, and that it works (in a broad sense, including being efficient and practical). Consistency may help those goals indirectly by making it easier or cheaper to implement some collection of protocols that use similar algorithms, but if pursued for its own sake, it may also hinder them. It is naïve to imagine that OAEP can act as a quick fix for any security problem in a protocol using RSA, which is how some people seem to want to apply it. If the effects are not analysed on a protocol-by-protocol basis, serious errors *will* be made, and fixing them (if they are detected, and if they get fixed) will add still more complexity. [Sho01] Victor Shoup, "A Proposal for an ISO Standard for Public Key Encryption (version 1.1)," Revised May 29, 2001. http://www.shoup.net/papers/ [Man01] James Manger, "A Chosen Ciphertext Attack On RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized In PKCS #1," To appear in Advances in Cryptology - Proceedings of CRYPTO 2001. - -- 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 - ----- OAEP unpadding, with compatible modifications to prevent side channel attacks: 1. If the length of P is greater than the length limitation, output "error" and stop. Otherwise, apply the hash function Hash to the parameters P to produce an octet string cHash of length hLen. 2. Let oLen = floor(l/8) and seedLen = hLen. If oLen < seedLen + hLen + 1, output "error" and stop. 3. Convert f to an octet string EM of length oLen + 1 with the primitive I2OSP. If the primitive outputs "error", output "error" and stop. 4. Let X be the leftmost octet of EM, let maskedSeed be the next seedLen octets, and maskedDB the remaining octets. 5. Apply the mask generation function G to the string maskedDB to produce an octet string seedMask of length seedLen octets. 6. Let seed = maskedSeed xor seedMask. 7. Apply the mask generation function G to the string seed to produce an octet string dbMask of length oLen - seedLen octets. 8. Let DB = maskedDB xor dbMask. 9. Let M' be all but the first hLen octets of DB. 10. Let T be the leftmost nonzero octet of M'. 11. If the first hLen octets of DB are not equal to cHash, or X != 00, or T != 01, then output "error" and stop. 12. Remove T and all octets to the left of it (which are all zero) from M' to produce an octet string M. 13. Output the message M. NOTES 1--It is important that the implementation output the same error message at the same time regardless of the cause of error in step 11. 2--The description of the decoding operation has been modified from that in IEEE Std 1363-2000, to make it clearer how to implement decoding in a way that avoids the attack described in [Man01]. This does not affect compatibility; the differences only affect when errors are detected. In particular, the previous description used the I2OSP primitive to produce an octet string of length oLen, rather than oLen + 1. If an implementation reveals whether the length of the message representative is greater than oLen octets, then an opponent will be able to determine whether the most significant octet of an RSA decryption is nonzero, which may lead to an attack. 3--The error in step 3 cannot occur for RSA-OAEP, since in that case the message representative will always be in the range [0, 2^(l+1)-1]. 4--Step 1 may be precomputed, if P is known in advance. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBO1f8UDkCAxeYt5gVAQFIfwf+LUpj7r5GBmoz0V/pGo7eEIRAlpzC0Mzy J+PkPTrWNM3PUBRVBXF3e9WujLRHK4CgM0+OR5p7b0T6UFRAsR4HTyu5HZnR35et bwO18PdWTEtbei7JBExGp6vhriowRsHRZRrUgvP/0tewgL1y/ZgkmmO4a1k+qHgp Om5MiLQAW+XLEjMPIHXGnU5H/6iCIAO6cw7JRH82b7yucyDHH3CZ0ItXCT/vgP8i HjoVUB6fyGJYoidxiSs5Ms4W96zoVMcmMjfC8mwBciWoYK75SEJXgzLY9U8/Vjro e8PqK9wtWIuB6c/nkeLO75/UZe7f3Sszh0FgkLsOHGzo+s5/Ro71hg== =GbSN -----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 Jul 20 07:09:26 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27906 for ; Fri, 20 Jul 2001 07:09:25 -0400 (EDT) Date: Fri, 20 Jul 2001 13:10:07 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES, OAEP, and TLS Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from david.hopwood@zetnet.co.uk on Fri, Jul 20, 2001 at 10:43:45AM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010720131007.B28165@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Fri, Jul 20, 2001 at 10:43:45AM +0100, David Hopwood wrote: >> The advantages of OAEP may not be relevant in some protocols, but it >> doesn't seem to present any problem in those protocols. > It does present problems in many protocols (the first two of these don't > apply to TLS): [...] > 2. How do you negotiate the use of RSA-OAEP as opposed to whatever was used > before? (This is *very easy* to get wrong. Adding a negotiation mechanism > to a protocol that didn't previously have one is one of the most > complicated and error-prone parts of protocol design. TLS's negotiation > mechanism is has had more analysis than that of any other protocol I've > seen, and it still has known security flaws, even though negotiation was > designed into SSL 2.0 from the start.) Good point, and actually this *does* apply to TLS in some sense. Assume that a TLS server implements a RSA-OAEP ciphersuite and that TLS with RSA-OAEP were more secure than TLS with RSA-PKCS #1 v1.5 encryption (e.g. because the Bleichenbacher attack countermeasure is not implemented correctly). Then, unless the server uses independent RSA keys for RSA-OAEP and RSA-PKCS #1 v1.5 encryption, RSA-OAEP provides no security advantage whatsoever -- the attacker can simply use PKCS #1 v1.5 ciphersuites for his attacks. (Note that Bleichenbacher's attack is not limited to PKCS #1 v1.5 *target* ciphertexts, it just uses a PKCS #1 v1.5 oracle for *chosen* ciphertexts). Thus, adding RSA-OAEP ciphersuites is a nuisance not just to implementors, but also to server operators, who will need an additional key and certificate if adding OAEP is to make at least some sense. (In fact with the current set of ciphersuites, different keys should already be used for RSA encryption and RSA signing -- I'm not sure if anyone really does that.) Why worry about RSA encryption that much, anyway? The forward secure ciphersuites, except export-crippled ones, use RSA only for signatures. As far as security is concerned, OAEP is advantegeous for TLS only for servers that do not have an unpredictable PRNG. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Jul 20 09:56:08 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 JAA07065 for ; Fri, 20 Jul 2001 09:56:07 -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: Fri, 20 Jul 2001 09:53:46 -0400 Subject: [ietf-tls] Re: Last call: 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.20010720095122.02455b98@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net TLS WG: Since I will be out of the office for the bulk of this Last Call, I wanted to post a message supporting the adoption of RSA-OAEP for use with AES. I think that it is a major step toward the selection of an IETF-wide crypto algorithm suite that includes RSA-OAEP for key management and AES for encryption. Russ At 12:33 AM 7/20/2001 -0400, Win Treese wrote: >This is a working group Last Call for draft-ietf-tls-ciphersuite-04.txt >to be submitted to the IESG for Proposed Standard. It incorporates the >changes to use OAEP for RSA. > >Because there were no other unresolved issues on this draft in the >original Last Call, this is a one-week Last Call. > >Thanks, > >Win Treese >Chair, TLS working group >treese@acm.org > > >--- >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 Fri Jul 20 10:24: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 KAA17825 for ; Fri, 20 Jul 2001 10:24:47 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 20 Jul 2001 10:25:02 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: Last call: AES ciphersuites for TLS Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by grover.local.aus.rsa.com id f6KETLB08945 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.20010720102026.02478660@exna07.securitydynamics.com> 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 KAA17825 I agree with Bodo's point. If the same private key is used with both RSA-OAEP and PKCS #1 v1.5, it can be attacked via the weaker method. However, this is not a reason to delay the introduction of RSA-OAEP; eventually the server can support just AES with RSA-OAEP. Russ >Date: Fri, 20 Jul 2001 13:27:11 +0200 >From: Bodo Moeller >To: "IETF Transport Layer Security WG" >Subject: [ietf-tls] Re: Last call: AES ciphersuites for TLS > >On Fri, Jul 20, 2001 at 12:33:29AM -0400, Win Treese wrote: > > > This is a working group Last Call for draft-ietf-tls-ciphersuite-04.txt > > to be submitted to the IESG for Proposed Standard. It incorporates the > > changes to use OAEP for RSA. > > > > Because there were no other unresolved issues on this draft in the > > original Last Call, this is a one-week Last Call. > >As explained in the follow-up to David Hopwood's message (Re: AES, >OAEP, and TLS), I object to adding RSA ciphersuites with OAEP. >Having both PKCS #1 v1.5 encryption and OAEP ciphersuites enabled >in the same server cannot provide any security advantage and in >fact is more likely to make the system *less* secure than always >using PKCS #1 v1.5. > >The above concern would be resolved by using independent RSA keys for >different ciphersuites. However, this would mean servers would need >additional certificates just so that they can use AES. This would >mean a lot of extra effort and provide no advantages whatsoever >because TLS with PKCS #1 v1.5 encryption and the Bleichenbacher attack >countermeasure described in RFC 2246 is cryptographically sound. > >Instead of introducing OAEP, the AES ciphersuites should use RSA >encryption similar to existing ciphersuites. > > >-- >Bodo Möller --- 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 Jul 20 11:16: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 LAA00558 for ; Fri, 20 Jul 2001 11:16:35 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: 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: 20 Jul 2001 08:24:11 -0700 In-Reply-To: "Housley, Russ"'s message of "Fri, 20 Jul 2001 10:25:02 -0400" 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 "Housley, Russ" writes: > I agree with Bodo's point. If the same private key is used with both > RSA-OAEP and PKCS #1 v1.5, it can be attacked via the weaker > method. However, this is not a reason to delay the introduction of > RSA-OAEP; eventually the server can support just AES with RSA-OAEP. The probability that this will happen in the foreseeable future is negligible. While I think it's a laudable goal to have future IETF protocols share a common suite of algorithms, I fail to see that any particular benefit is achieved by imposing that suite on current protocols. I'm against this change. -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 Fri Jul 20 12:20:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17591 for ; Fri, 20 Jul 2001 12:20:45 -0400 (EDT) Message-ID: Date: Fri, 20 Jul 2001 09:25:38 -0700 From: thayes@netscape.com (Terry Hayes) User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010713 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: AES ciphersuites for TLS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B585B82.90802@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I object to the changes that require OAEP padding for the AES ciphersuite. My previous email (12 July) outlines my reasons for this position. The goal of this draft should be to define AES ciphersuites that can be deployed soon. Coupling that goal with changes in the RSA padding will only delay implementations and cause interoperability problems without providing any increased security. Terry Hayes Netscape Communications Corp. Win Treese wrote: >This is a working group Last Call for draft-ietf-tls-ciphersuite-04.txt >to be submitted to the IESG for Proposed Standard. It incorporates the >changes to use OAEP for RSA. > >Because there were no other unresolved issues on this draft in the >original Last Call, this is a one-week Last Call. > >Thanks, > >Win Treese >Chair, TLS working group >treese@acm.org > > >--- >You are currently subscribed to ietf-tls as: thayes@netscape.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 Fri Jul 20 13:37: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 NAA08509 for ; Fri, 20 Jul 2001 13:37:47 -0400 (EDT) Message-ID: Date: Fri, 20 Jul 2001 18:40:58 +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: Last call: 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: <3B586D2A.1D9E2632@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I am also opposed to the change to making OAEP mandatory for AES ciphersuites. I agree with many of the objections already raised. I have an additional issue. Crypto hardware with some form of private key protection will have varying degrees of difficulty with OAEP. How bad this is depends on the hardware in use and I don't claim to be familiar with all variants. However typical issues might be: 1. The firmware cannot be upgraded and it only supports PKCS#1 v1.5 internally. 2. Upgrading the firmware can only be done if the existing hardware protected keys are destroyed. 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 Fri Jul 20 14:27:22 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21719 for ; Fri, 20 Jul 2001 14:27:19 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 20 Jul 2001 14:27:55 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: Last call: 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.20010720142559.0248e800@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Stephen: >2. Upgrading the firmware can only be done if the existing hardware >protected keys are destroyed. This is not always the case. I have personally used devices that allowed the firmware to be updated without wiping out certificates or private keys that were stored in them. I am sorry to hear that some hardware vendors were short sighted in this area. 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 Fri Jul 20 14:45: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 OAA27134 for ; Fri, 20 Jul 2001 14:45:34 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: 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: 20 Jul 2001 11:52:51 -0700 In-Reply-To: "Housley, Russ"'s message of "Fri, 20 Jul 2001 14:27:55 -0400" Message-ID: Lines: 18 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 "Housley, Russ" writes: > >2. Upgrading the firmware can only be done if the existing hardware > >protected keys are destroyed. > > This is not always the case. I have personally used devices that allowed > the firmware to be updated without wiping out certificates or private keys > that were stored in them. > > I am sorry to hear that some hardware vendors were short sighted in this area. I'm not sure I consider this shortsighted. One of the claimed invariants of such hardware is that the key cannot leave the device. Allowing the firmware to be upgraded potentially violates this invariant. [0] -Ekr [0] Yes, I know you can have signed firmware and the like but you're then depending on the future security of the signing key, among other things. --- 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 Jul 20 15:56:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23115 for ; Fri, 20 Jul 2001 15:56:46 -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: Fri, 20 Jul 2001 15:57:03 -0400 Subject: [ietf-tls] Re: Last call: AES ciphersuites for TLS In-Reply-To: References: <"Housley, Russ"'s message of "Fri, 20 Jul 2001 14:27:55 -0400"> 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.20010720155359.02472ec8@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Eric: > > >2. Upgrading the firmware can only be done if the existing hardware > > >protected keys are destroyed. > > > > This is not always the case. I have personally used devices that allowed > > the firmware to be updated without wiping out certificates or private keys > > that were stored in them. > > > > I am sorry to hear that some hardware vendors were short sighted in > this area. >I'm not sure I consider this shortsighted. One of the claimed invariants >of such hardware is that the key cannot leave the device. Allowing >the firmware to be upgraded potentially violates this invariant. > >Yes, I know you can have signed firmware and the like but you're >then depending on the future security of the signing key, among other >things. Interesting security policy. However, it is quite difficult to repair a bug in this situation. If I had a root key stored in such a device I would be quite upset if there was no way to repair a bug in the firmware without destroying the root key. 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 Fri Jul 20 16:34: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 QAA10291 for ; Fri, 20 Jul 2001 16:34:29 -0400 (EDT) Message-ID: Date: Fri, 20 Jul 2001 21:35:15 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: 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: <3B589603.5E7EC3CE@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit "Housley, Russ" wrote: > > Eric: > > > > >2. Upgrading the firmware can only be done if the existing hardware > > > >protected keys are destroyed. > > > > > > This is not always the case. I have personally used devices that allowed > > > the firmware to be updated without wiping out certificates or private keys > > > that were stored in them. > > > > > > I am sorry to hear that some hardware vendors were short sighted in > > this area. > >I'm not sure I consider this shortsighted. One of the claimed invariants > >of such hardware is that the key cannot leave the device. Allowing > >the firmware to be upgraded potentially violates this invariant. > > > >Yes, I know you can have signed firmware and the like but you're > >then depending on the future security of the signing key, among other > >things. > > Interesting security policy. However, it is quite difficult to repair a > bug in this situation. If I had a root key stored in such a device I would > be quite upset if there was no way to repair a bug in the firmware without > destroying the root key. How upset would you be if your root key became available to an attacker because the "upgraded" the firmware? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jul 20 17:40:42 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 RAA28730 for ; Fri, 20 Jul 2001 17:40:41 -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: Fri, 20 Jul 2001 17:41:20 -0400 Subject: [ietf-tls] Re: Last call: 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.20010720173855.0248e948@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Ben: > > > > >2. Upgrading the firmware can only be done if the existing hardware > > > > >protected keys are destroyed. > > > > > > > > This is not always the case. I have personally used devices that > allowed > > > > the firmware to be updated without wiping out certificates or > private keys > > > > that were stored in them. > > > > > > > > I am sorry to hear that some hardware vendors were short sighted in > this area. > > >I'm not sure I consider this shortsighted. One of the claimed invariants > > >of such hardware is that the key cannot leave the device. Allowing > > >the firmware to be upgraded potentially violates this invariant. > > > > > >Yes, I know you can have signed firmware and the like but you're > > >then depending on the future security of the signing key, among other > > >things. > > > > Interesting security policy. However, it is quite difficult to repair a > > bug in this situation. If I had a root key stored in such a device I would > > be quite upset if there was no way to repair a bug in the firmware without > > destroying the root key. > >How upset would you be if your root key became available to an attacker >because the "upgraded" the firmware? As Eric pointed out, there are ways to ensure that the firmware comes from the device manufacturer. This discussion has gone way off topic. We should talk about the TLS protocol and associated algorithms. I will stop here. 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 Fri Jul 20 17:53:53 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 RAA02919 for ; Fri, 20 Jul 2001 17:53:50 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: 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: 20 Jul 2001 15:01:29 -0700 In-Reply-To: "Housley, Russ"'s message of "Fri, 20 Jul 2001 17:41:20 -0400" 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 "Housley, Russ" writes: > >How upset would you be if your root key became available to an attacker > >because the "upgraded" the firmware? > > As Eric pointed out, there are ways to ensure that the firmware comes from > the device manufacturer. Right, but imagine that the manufacturer makes two different kinds of firmware, one of which permits key export and one of which does not. Clearly you wouldn't want the "key export" firmware loaded onto your previously secure box. So, now we need some way of differentiating various kinds of firmware, which means that you need different hardware, some of which can only run certain firmware. This is getting pretty complicated. -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 Fri Jul 20 18:01:02 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 SAA05216 for ; Fri, 20 Jul 2001 18:01:01 -0400 (EDT) Message-ID: Date: Fri, 20 Jul 2001 23:02:59 +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] Straw poll on RSA-OAEP (Last call: AES ciphersuites for TLS) Content-Type: text/plain; charset=UTF-8 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B58AA93.20FC30B0@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 SAA05216 -----BEGIN PGP SIGNED MESSAGE----- "Housley, Russ" wrote: > I agree with Bodo's point. If the same private key is used with both > RSA-OAEP and PKCS #1 v1.5, it can be attacked via the weaker > method. However, this is not a reason to delay the introduction of > RSA-OAEP; eventually the server can support just AES with RSA-OAEP. I think it is a good reason to delay. All of the key exchange algorithms should really be thoroughly re-analysed from the point of view of both security and efficiency. There are several possibilities for improving speed and forward secrecy properties. We certainly can't do such an analysis in one week. If we introduce RSA-OAEP now as specified in the draft, and then find that there was a better way of doing so (which is likely), are we then going to add yet another RSA key exchange variant later? I've just checked that there were no changes between drafts -03 and -04 apart from RSA-OAEP (and a change to Pete Chown's phone number). So, I formally propose that it should be draft-ietf-tls-ciphersuite-03.txt (with the phone number change) that is taken to Proposed Standard RFC, not -04. Some people have already made their position clear: For draft -04, with RSA-OAEP: Russ Housley For draft -03, with PKCS #1 v1.5: David Hopwood Terry Hayes , speaking for Netscape Bodo Möller Against draft -04 (does this mean for draft -03?): Dr S N Henson Eric Rescorla (If I've misinterpreted anyone's position, please say so.) - -- 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 iQEVAwUBO1iqgTkCAxeYt5gVAQHVuQf/WnfNFVyDmcIdFJod02Y/XqI5GVK0m5Nc +zliekYihvmB2q/FsU6rMMZnK2kcnlT/WVMnQA+1SJCzlvX/KruZUrXLacQS5nRE upHR0qNcnnmyMVnLvuikghkJvhH8NoOqUHcCE+uzU6DmYlAQONhJZsop5NVceRBA DUhZzeim61LevrC4vqfyJArgAMTwwmoivFkvoGzbaMPHZjv2+ozuMJLQo86XsEyx /VqI1A2C5sk5Bp13kduh2h4eng/LxxRY0qMBSSG2Gs+5CAjUpNZ6sDEDeSN5m2o5 PNUdunyDGzT84dvmKtpw3NWdLR4IMDVO9/E8J13TGMEiNhuC0rwONg== =AWbn -----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 Jul 20 18:15:53 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 SAA11166 for ; Fri, 20 Jul 2001 18:15:52 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: 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: 20 Jul 2001 14:48:21 -0700 In-Reply-To: "Housley, Russ"'s message of "Fri, 20 Jul 2001 15:57:03 -0400" 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 "Housley, Russ" writes: > >I'm not sure I consider this shortsighted. One of the claimed invariants > >of such hardware is that the key cannot leave the device. Allowing > >the firmware to be upgraded potentially violates this invariant. > > > >Yes, I know you can have signed firmware and the like but you're > >then depending on the future security of the signing key, among other > >things. > > Interesting security policy. However, it is quite difficult to repair a > bug in this situation. If I had a root key stored in such a device I would > be quite upset if there was no way to repair a bug in the firmware without > destroying the root key. I agree that this is unfortunate, however it's consistent with what seems to me to be the general philosophy behind such hardware crypto devices, namely that just about any amount of inconvenience is acceptable if it renders the system more secure. -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 Fri Jul 20 21:44:14 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 VAA21503 for ; Fri, 20 Jul 2001 21:44:14 -0400 (EDT) Message-ID: Date: Sat, 21 Jul 2001 01:16: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: Straw poll on RSA-OAEP (Last call: 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: <3B58C9E0.AAE81952@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Hopwood wrote: > > > Against draft -04 (does this mean for draft -03?): > Dr S N Henson Yes it does mean that in my case. 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 Fri Jul 20 21:44:24 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 VAA21570 for ; Fri, 20 Jul 2001 21:44:23 -0400 (EDT) Message-ID: Date: Sat, 21 Jul 2001 01:27:48 +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: Last call: 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: <3B58CC84.9E91E9A9@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Ben Laurie wrote: > > > How upset would you be if your root key became available to an attacker > because the "upgraded" the firmware? > There's also the possibility of the manufacturer being forced to extract keys from boxes via legal sanction. In this scenario the "attacker" would be the manufacturer. Some manufacturers, and indeed some customers, would want to be ultra safe and have hardware from which keys cannot be extracted under any (known) circumstances. 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 Sat Jul 21 06:24:56 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14764 for ; Sat, 21 Jul 2001 06:24:53 -0400 (EDT) Message-Id: Date: Sat, 21 Jul 2001 11:51:29 +0200 (CEST) From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: AES ciphersuites for TLS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Eric Rescorla : > "Housley, Russ" writes: >>> 2. Upgrading the firmware can only be done if the existing hardware >>> protected keys are destroyed. >> This is not always the case. I have personally used devices that allowed >> the firmware to be updated without wiping out certificates or private keys >> that were stored in them. >> I am sorry to hear that some hardware vendors were short sighted in this area. > I'm not sure I consider this shortsighted. One of the claimed invariants > of such hardware is that the key cannot leave the device. Allowing > the firmware to be upgraded potentially violates this invariant. [...] As separate RSA keys should be used for RSA OAEP and RSA PKCS #1 v1.5 decryption (otherwise any OAEP "provable security" is void, anyway), there would not be a need to upgrade the firmware used with existing keys. The simplest sound solution would be simply not to implement those AES ciphersuites that require OAEP decryption. (This leaves availabe AES ciphersuites using RSA signatures.) It would be a matter of minutes to implement OAEP-based ciphersuites in OpenSSL such that a single RSA key is used for different styles of RSA decryption; but I won't do this because it can make security only worse, not better. Using multiple RSA keys would be OK, but it's hardly worth the implementation effort because few server operators would bother to obtain an additional certificate for the additional key. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- 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 Sat Jul 21 07:13:31 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20350 for ; Sat, 21 Jul 2001 07:13:30 -0400 (EDT) Date: Sat, 21 Jul 2001 13:46:33 +1200 (NZST) Message-ID: From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: Last call: AES ciphersuites for TLS List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107210146.NAA147640@ruru.cs.auckland.ac.nz> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net "Housley, Russ" writes: >>2. Upgrading the firmware can only be done if the existing hardware >>protected keys are destroyed. > >This is not always the case. I have personally used devices that allowed the >firmware to be updated without wiping out certificates or private keys that >were stored in them. > >I am sorry to hear that some hardware vendors were short sighted in this area. That's not short-sighted, that's a good security precaution (in fact I'd be rather suspicious of a device which allowed the firmware to be upgraded without zeroising the cryptovariables). What happens if I upgrage the firmware to a new version which leaks the private key(s)? (Some of the papers covering the IBM 4758 design go into this problem, and how to avoid it, in some detail). Peter. --- 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 Sat Jul 21 10:28:54 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 KAA28996 for ; Sat, 21 Jul 2001 10:28:53 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last call: 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: 21 Jul 2001 07:36:33 -0700 In-Reply-To: Bodo Moeller's message of "Sat, 21 Jul 2001 11:51:29 +0200 (CEST)" 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 Bodo Moeller writes: > Eric Rescorla : > > "Housley, Russ" writes: > > >>> 2. Upgrading the firmware can only be done if the existing hardware > >>> protected keys are destroyed. > > >> This is not always the case. I have personally used devices that allowed > >> the firmware to be updated without wiping out certificates or private keys > >> that were stored in them. > > >> I am sorry to hear that some hardware vendors were short sighted in this area. > > > I'm not sure I consider this shortsighted. One of the claimed invariants > > of such hardware is that the key cannot leave the device. Allowing > > the firmware to be upgraded potentially violates this invariant. [...] > > As separate RSA keys should be used for RSA OAEP and RSA PKCS #1 v1.5 > decryption (otherwise any OAEP "provable security" is void, anyway), > there would not be a need to upgrade the firmware used with existing > keys. I was more thinking that one might have hardware which could supported multiple keys and didn't wish to buy a separate piece of hardware. You'd need to upgrade the firmware in order to do OAEP at all but you could then enforce the key separation in software. -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 Sun Jul 22 19:21:59 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 TAA14830 for ; Sun, 22 Jul 2001 19:21:59 -0400 (EDT) Message-Id: X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Straw poll on RSA-OAEP (Last call: AES ciphersuites for TLS) In-Reply-To: Message from David Hopwood of "Fri, 20 Jul 2001 23:02:59 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 23 Jul 2001 09:22:44 +1000 From: Dean Povey List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107222322.f6MNMim19309@thunder.dstc.qut.edu.au> 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 TAA14830 >Some people have already made their position clear: > >For draft -04, with RSA-OAEP: > Russ Housley > >For draft -03, with PKCS #1 v1.5: > David Hopwood > Terry Hayes , speaking for Netscape > Bodo Möller > I'd also like to support draft-03 with PKCS#1 v1.5 for all the reasons stated. I think that OAEP should be added to TLS, but should not be mandatory with AES. Cheers. -- 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 Mon Jul 23 10:11:24 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 KAA22529 for ; Mon, 23 Jul 2001 10:11:13 -0400 (EDT) To: "IETF Transport Layer Security WG" MIME-Version: 1.0 Subject: [ietf-tls] Last call: AES ciphersuites for TLS X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Todd Arnold" Date: Mon, 23 Jul 2001 10:11:55 -0400 X-MIMETrack: Serialize by Router on D04NMS24/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/23/2001 10:11:57 AM, Serialize complete at 07/23/2001 10:11:57 AM Content-Type: multipart/alternative; boundary="=_alternative 004E0FAC85256A92_=" 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 multipart message in MIME format. --=_alternative 004E0FAC85256A92_= Content-Type: text/plain; charset="us-ascii" I was just made aware of the discussion going on here, so I'm catching up. I have a number of comments on some of the recent issues people have posted. For background, let me state that I am a designer of IBM cryptographic hardware products, like the 4758 card (see http://www.ibm.com/security/cryptocards) which is used in all of IBM's server platforms from the largest (mainframes) to the smallest (PC-based). I see that Peter Gutmann, who has worked with the 4758 in IBM Research, has also provided some information about this. > I have an additional issue. Crypto hardware with some form of private > key protection will have varying degrees of difficulty with OAEP. How > bad this is depends on the hardware in use and I don't claim to be > familiar with all variants. > > However typical issues might be: > > 1. The firmware cannot be upgraded and it only supports PKCS#1 v1.5 > internally. > > 2. Upgrading the firmware can only be done if the existing hardware > protected keys are destroyed. Neither of these is true with the IBM 4758. The firmware can be securely upgraded (in fact, the mechanisms are part of what received FIPS 140 Level 4 validation by NIST). Furthermore, you can upgrade the firmware in a way that destroys all secret data in the card (if you are paranoid), or you can upgrade it in a way that preserves all the secret data (which is what most customers choose to do). > There's also the possibility of the manufacturer being forced to extract > keys from boxes via legal sanction. In this scenario the "attacker" > would be the manufacturer. We have always designed our products with a firm principle that it will be IMPOSSIBLE for us, as the designers and manufacturers, to get to any secret data the customer puts in our hardware crypto units. No matter how much the government, or even the customer insists on it, there is no way we can get secrets out if you intended for them to be protected. That is a requirement for any of our crypto design. > Interesting security policy. However, it is quite difficult to repair a > bug in this situation. If I had a root key stored in such a device I would > be quite upset if there was no way to repair a bug in the firmware without > destroying the root key. This is precisely the point that drives the requirements for the design. There are standards that REQUIRE root keys to reside in the hardware, in such a way that they can never be extracted, backed up, or cloned. People running large businesses with CAs do not want their CA root keys to be destroyed because they installed a firmware upgrade in order to get some desirable new feature. (Maybe they want to add OAEP support... :-) ) > How upset would you be if your root key became available to an attacker > because the "upgraded" the firmware? This is why you need secure code validation and loading procedures. If you trusted your vendor not to have a Trojan horse or other security hole in the original firmware, and if the code delivery and installation process guarantees that the code originated with that vendor, has not been tampered, and is reliably loaded into the hardware, then you should not have any concern with the update that you did not also have with the code it replaces. > Right, but imagine that the manufacturer makes two different kinds > of firmware, one of which permits key export and one of which does > not. Clearly you wouldn't want the "key export" firmware loaded > onto your previously secure box. > > > So, now we need some way of differentiating various kinds of > firmware, which means that you need different hardware, some of > which can only run certain firmware. It doesn't have to be that complicated. A single firmware load can have all the functions - "secure" and "less-secure". A highly secure integrated access control system (which the 4758 has in its CCA API) can then be used by a system administrator to selectively enable and disable functions, as desired. Don't want to allow private keys to exist outside the hardware? OK, just disable the related functions. The CCA API on the 4758 supports RSA keys that can never leave the secure module, but it also supports RSA keys that can be stored outside the module, triple-DES protected under a key inside the module. You can enable either of these, or both, as you desire. > You also have downgrade attacks where I replace the current (signed) > firmware with the previous (signed, buggy) firmware... The 4758 architecture allows you to place all kinds of restrictions on where code can be loaded. Among those are restrictions on what versions it will load on top of - so you can prevent loading old code on top of newer versions. (In fact, you can even do things like targeting the code to specific cards, by serial number.) As an aside... The ANSI standards committees are discussing future key management standards, and are heading to a conclusion that OAEP formatting should be used with AES keys. That is not final yet, but it seems to be the feeling of most of the experts who participate. I happen to agree. Let me say that I am not familiar with the IETF TLS discussion that is the source of this thread, so I appologize if specifics related to that standard reduce the relevance of my comments. ------------------------------------------------------------------- Todd W. Arnold IBM Cryptographic Technology Development (704) 594-8253 FAX 594-1790 ------------------------------------------------------------------- email: arnoldt@us.ibm.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 --=_alternative 004E0FAC85256A92_= Content-Type: text/html; charset="us-ascii"
I was just made aware of the discussion going on here, so I'm catching
up.  I have a number of comments on some of the recent issues people
have posted.  For background, let me state that I am a designer of IBM
cryptographic hardware products, like the 4758 card (see
http://www.ibm.com/security/cryptocards) which is used in all of IBM's
server platforms from the largest (mainframes) to the smallest
(PC-based).  

I see that Peter Gutmann, who has worked with the 4758 in IBM
Research, has also provided some information about this.  


> I have an additional issue. Crypto hardware with some form of private
> key protection will have varying degrees of difficulty with OAEP. How
> bad this is depends on the hardware in use and I don't claim to be
> familiar with all variants.
>
> However typical issues might be:
>
> 1. The firmware cannot be upgraded and it only supports PKCS#1 v1.5
> internally.
>
> 2. Upgrading the firmware can only be done if the existing hardware
> protected keys are destroyed.

Neither of these is true with the IBM 4758.  The firmware can be
securely upgraded (in fact, the mechanisms are part of what received
FIPS 140 Level 4 validation by NIST).  Furthermore, you can upgrade
the firmware in a way that destroys all secret data in the card (if
you are paranoid), or you can upgrade it in a way that preserves all
the secret data (which is what most customers choose to do).  


> There's also the possibility of the manufacturer being forced to extract
> keys from boxes via legal sanction. In this scenario the "attacker"
> would be the manufacturer.

We have always designed our products with a firm principle that it
will be IMPOSSIBLE for us, as the designers and manufacturers, to get
to any secret data the customer puts in our hardware crypto units.  No
matter how much the government, or even the customer insists on it,
there is no way we can get secrets out if you intended for them to be
protected.  That is a requirement for any of our crypto design.  


> Interesting security policy.  However, it is quite difficult to repair a
> bug in this situation.  If I had a root key stored in such a device I would
> be quite upset if there was no way to repair a bug in the firmware without
> destroying the root key.

This is precisely the point that drives the requirements for the
design.  There are standards that REQUIRE root keys to reside in the
hardware, in such a way that they can never be extracted, backed up,
or cloned.  People running large businesses with CAs do not want their
CA root keys to be destroyed because they installed a firmware upgrade
in order to get some desirable new feature.  (Maybe they want to add
OAEP support...  :-) )


> How upset would you be if your root key became available to an attacker
> because the "upgraded" the firmware?

This is why you need secure code validation and loading procedures.  
If you trusted your vendor not to have a Trojan horse or other
security hole in the original firmware, and if the code delivery and
installation process guarantees that the code originated with that
vendor, has not been tampered, and is reliably loaded into the
hardware, then you should not have any concern with the update that
you did not also have with the code it replaces.  


> Right, but imagine that the manufacturer makes two different kinds
> of firmware, one of which permits key export and one of which does  
> not.  Clearly you wouldn't want the "key export" firmware loaded
> onto your previously secure box.  
>
>
> So, now we need some way of differentiating various kinds of
> firmware, which means that you need different hardware, some of
> which can only run certain firmware.  

It doesn't have to be that complicated.  A single firmware load can
have all the functions - "secure" and "less-secure".  A highly secure
integrated access control system (which the 4758 has in its CCA API)
can then be used by a system administrator to selectively enable and
disable functions, as desired.  Don't want to allow private keys to
exist outside the hardware?  OK, just disable the related functions.  
The CCA API on the 4758 supports RSA keys that can never leave the
secure module, but it also supports RSA keys that can be stored
outside the module, triple-DES protected under a key inside the
module.  You can enable either of these, or both, as you desire.  


> You also have downgrade attacks where I replace the current (signed)
> firmware with the previous (signed, buggy) firmware...  

The 4758 architecture allows you to place all kinds of restrictions on
where code can be loaded.  Among those are restrictions on what
versions it will load on top of - so you can prevent loading old code
on top of newer versions.  (In fact, you can even do things like
targeting the code to specific cards, by serial number.)


As an aside...  The ANSI standards committees are discussing future
key management standards, and are heading to a conclusion that OAEP
formatting should be used with AES keys.  That is not final yet, but
it seems to be the feeling of most of the experts who participate.  I
happen to agree.  


Let me say that I am not familiar with the IETF TLS discussion that is
the source of this thread, so I appologize if specifics related to
that standard reduce the relevance of my comments.  


-------------------------------------------------------------------
Todd W. Arnold
IBM Cryptographic Technology Development
(704) 594-8253   FAX 594-1790
-------------------------------------------------------------------
email:  arnoldt@us.ibm.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 --=_alternative 004E0FAC85256A92_=-- From bounce-ietf-tls-3458737@lists.certicom.com Mon Jul 23 10:46:44 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 KAA25522 for ; Mon, 23 Jul 2001 10:46:41 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Mon, 23 Jul 2001 10:45:24 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" CC: tsvwg@ietf.org, ietf-tls@lists.certicom.com Subject: [ietf-tls] Re security considerations for draft-tuexen-tsvwg-tls-over-sctp-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: <3B5C3884.7C793B7A@hns.com> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Just curious... (I don't know the answer.) Does the use of abbreviated handshakes for additional SCTP streams (as described in Section 5.2 of the document) introduce any security considerations which need to be captured in Section 6? I didn't see any discussion of any issues related to the use of abbreviated handshakes in RFC 2246 (but I am enough of a security novice that it may be there and I just didn't recognize it)... John --- 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 Jul 23 11:29:10 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 LAA28820 for ; Mon, 23 Jul 2001 11:29:09 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Cc: tsvwg@ietf.org Subject: [ietf-tls] Re: Re security considerations for draft-tuexen-tsvwg-tls-over-sctp-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: 23 Jul 2001 08:36:34 -0700 In-Reply-To: John Border's message of "Mon, 23 Jul 2001 10:45:24 -0400" 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 John Border writes: > Just curious... (I don't know the answer.) Does the use of abbreviated > handshakes for additional SCTP streams (as described in Section 5.2 of the > document) introduce any security considerations which need to be captured in > Section 6? I didn't see any discussion of any issues related to the use of > abbreviated handshakes in RFC 2246 (but I am enough of a security novice that > it may be there and I just didn't recognize it)... The use of the term "abbreviated" in this draft is a bug. The correct term is "resumed". There are no real security issues here. They simply need to be treated as if they had the same security properties as the original handshake. -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 Jul 23 15:01:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16228 for ; Mon, 23 Jul 2001 15:01:46 -0400 (EDT) Message-ID: Date: Mon, 23 Jul 2001 19:55:18 +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] Fwd: Straw poll on RSA-OAEP 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: <3B5C7316.66014B52@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: [ietf-tls] Straw poll on RSA-OAEP (Last call: AES ciphersuites for TLS) Date: Sun, 22 Jul 2001 16:27:22 -0700 (PDT) From: David Wagner To: david.hopwood@zetnet.co.uk I tried to send one or two messages objecting to draft-04 (and favoring draft-03) as well, but they don't seem to have gone through (I suspect it is because I read from a different address that I post from, and maybe someone configured this list to automatically reject such posts without notice--- grr...!), but I don't have time to deal with it right now. Anyway, you can count me on your straw poll. -- David [Wagner] ---------------------------------- --- 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 Jul 24 07:00:42 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 HAA07958 for ; Tue, 24 Jul 2001 07:00:41 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Jungmaier Organization: University of Essen, Germany To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: security considerations for draft-tuexen-tsvwg-tls-over-sctp-00.txt... Date: Tue, 24 Jul 2001 12:37:04 -0400 X-Mailer: KMail [version 1.2] References: <3B5C3884.7C793B7A@hns.com> In-Reply-To: <3B5C3884.7C793B7A@hns.com> Cc: tsvwg@ietf.org, ietf-tls@lists.certicom.com, Michael.Tuexen@icn.siemens.de MIME-Version: 1.0 Message-Id: Content-Transfer-Encoding: 8bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <01072412370403.31709@biene.exp-math.uni-essen.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 23. July 2001 10:45, you wrote: > Just curious... (I don't know the answer.) Does the use of > abbreviated handshakes for additional SCTP streams (as described in Section > 5.2 of the document) introduce any security considerations which need to be > captured in Section 6? I didn't see any discussion of any issues related > to the use of abbreviated handshakes in RFC 2246 (but I am enough of a > security novice that it may be there and I just didn't recognize it)... It is a resumed session as per appendix F.1.4. of RFC 2246, which we intended to use, of course, as an abbreviated handshake. Therefore it is just an adaptation of TLS to the SCTP. This is one of the points that will need to be rephrased for the next version. Apart from that we invite further comments ! Best regards, Andreas Jungmaier - ---------------------------------------------------------------------------- \|/ _____ \|/ Andreas Jungmaier, Dipl.-Ing. "@'/ , . \`@" University of Essen ajung@exp-math.uni-essen.de /_| \___/ |__\ -> Computer Networking Tel. : +49 (0201) 183-7636 \___U_/ Technology Group <- - ---------------------------------------------------------------------------- PGP Public Key and Fingerprint: see http://www.exp-math.uni-essen.de/~ajung - ---------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7XaQwd2Uw+xBvGUIRAq/yAJ926LmmeOeu7mV0S/SyD4goHgchygCaAvxf xgwnJDIMAbpqkKDj9Q8aIQY= =gyFG -----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 Jul 25 02:26: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 CAA01996 for ; Wed, 25 Jul 2001 02:26:44 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] CipherSuite number conflict Date: Wed, 25 Jul 2001 15:27:31 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107250627.PAA28103@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Win, could you show us some kind of document that includes the official working group approved ciphersuite numbers? From: "Singer, Ari" Date: Wed, 11 Jul 2001 16:20:01 -0400 > I will be happy to change the ciphersuite numbers for the next draft > of the NTRU-TLS document. Which ciphersuite numbers will you use? We also have to change some of the ciphersuite numbers in draft-ietf-tls-camellia-01.txt, because draft-ietf-tls-ecc-01.txt and ours both allocate 'x47' thru 'x4C' as Paul V Ford-Hutchinson pointed out. (Thank you!) When I wrote draft-ietf-tls-camellia-01.txt, I consulted Hidenori's proposal: > Subject: [ietf-tls] Re: I-D cipher suite numbers > From: "Hidenori Ohta" > Date: Sat, 17 Mar 2001 00:04:32 +0900 however, the numbers 'x47' thru 'x4C' had been used. Anyway, implementations of some SSL/TLS products including Camellia are in progress. I have to let them know the approved ciphersuite numbers soon. Best regards, Shiho Shiho Moriai NTT Laboratories --- 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 Jul 25 16:51: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 QAA06625 for ; Wed, 25 Jul 2001 16:51:50 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Straw poll on RSA-OAEP (Last call: AES ciphersuites for TLS) From: Jon Saperia Date: Wed, 25 Jul 2001 16:52:31 -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: <200107252052.QAA15002@europa-h0001027441c5.ne.mediaone.net> X-List-Host: SKYLIST.net I support draft-03 with PKCS#1 v1.5 for two reasons -- it is the right technical solution and is the right way to update the specification.  I do not support any broad changes in the padding scheme as an interim change.   On a technical basis, I support draft-03 with PKCS#1 v1.5 for many of the reasons previously stated. Of at least equal importance, I think that the implications of changing the padding scheme are so broad that they should be implemented not in an interim change, but during the next draft of TLS.  By making these changes as part of the next draft of TLS, many of the potential technical shortcomings could be addressed -- and a well thought-out solution could be applied to all of the cipher suites.  Ideally, this solution would not require the end users (e.g. owner's of web servers ) to have to start buying 2 web certs. instead of the current one. Interim revisions should address interim issues or urgent matters.  Significant changes such as this require the greater deliberation, testing and peer review that comes with releasing a new standard.   Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.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 Jul 25 17:24:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10198 for ; Wed, 25 Jul 2001 17:24:05 -0400 (EDT) Message-ID: Date: Wed, 25 Jul 2001 14:24:28 -0700 From: relyea@netscape.com (Bob Relyea) User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1+) Gecko/20010628 Netscape6/6.1b1 X-Accept-Language: en-us MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Straw poll on RSA-OAEP (Last call: AES ciphersuites for TLS) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B5F390C.9050000@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I also support draft-03. While I think that we need to address OAEP vs PKCS #1 1.5 vs other padding options, I don't think last call on the AES draft is the right place to do so. This kind of change needs appropriate time for analysis on it's effects on the protocol. The fact that others have so easily presented potential issues shows the need to be conservative and not introduce to many new concepts in the new cipher suite. bob --- 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 Jul 26 17:31: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 RAA13612 for ; Thu, 26 Jul 2001 17:31:38 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] draft agenda for London meeting Date: Thu, 26 Jul 2001 17:29:23 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200107262129.f6QLTNs13697@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Here is a proposed agenda for the TLS meeting in London. Please send comments or suggestions to me. Win Treese Chair, TLS working group treese@acm.org Transport Layer Security WG (tls) Wednesday, August 08 at 1300-1500 =============================== CHAIR: Win Treese AGENDA: 1. Review of agenda and current status 2. Moving RFC 2246 to Draft Standard 3. CipherSuites AES Ciphersuites for TLS draft-ietf-tls-ciphersuite-04.txt ECC Cipher Suites For TLS draft-ietf-tls-ecc-01.txt 56-bit Export Cipher Suites For TLS draft-ietf-tls-56-bit-ciphersuites-01.txt Extensions to TLS for OpenPGP keys draft-ietf-tls-openpgp-01.txt Addition of MISTY1 to TLS draft-ietf-tls-misty1-01.txt Addition of the Camellia Encryption Algorithm to TLS draft-ietf-tls-camellia-01.txt Kerberos Cipher Suites in Transport Layer Security (TLS) draft-ietf-tls-kerb-00.txt NTRU Cipher Suites for TLS draft-ietf-tls-ntru-00.txt 4. Other Proposals TLS Extensions draft-ietf-tls-extensions-00.txt TLS Delegation Protocol draft-ietf-tls-delegation-01.txt Using SRP for TLS Authentication draft-ietf-tls-srp-01.txt 5. Open discussion: should the WG undertake to define a major revision to TLS? If so, what changes should we focus on? --- 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-message-3458737@lists.certicom.com Fri Jul 27 08:48:59 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 IAA13567 for ; Fri, 27 Jul 2001 08:48:58 -0400 (EDT) Message-Id: X-lyris-type: held From: "Lyris ListManager" Reply-To: "Lyris ListManager" To: tls-archive@ietf.org Subject: Your membership on ietf-tls has been put on hold Date: Fri, 27 Jul 2001 07:54:06 -0500 This email message is to notify you that your membership to ietf-tls has been put on "hold". This means that you will not receive mail from 'ietf-tls'. Your subscription has been held because at least 5 recent messages have been either bounced by your email system, or could not be delivered at all. Your membership can be restored to "normal", by sending the command "unhold" to lyris@lists.certicom.com Note that if your email address continues to reject mail your subscription will once again be "held". You may want to contact the people responsible for your electronic mail to determine why your email address has been having trouble. ---For your information, a non-delivery report is included below: