Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
Hello, Since I was pretty active in providing the current code, here are some of our thoughts which may or may not be compatible with the core team. In 2004, we had developped some extensions for the 0.9.7d version concerning servername and srp. We initially also had the idea and a logic where one could try to have a very generic extension mechanism. The problem is that extensions may require modification of the internal states of openssl, or at least have to interfere with it in some cases. Or, in other words, extension doesn't mean that either all extensions are logically equivalent because they are indicated with some number in the hellos, some are extensions of the protocol which may be done with almost no interaction with the application. Example, treating the maximum packet size. It would mean that an application would call a SSL_set_hello_extension to set the value of the extension. Well, ok, but then openssl has to check first, whether it needs additional logic to support the required extension in any way, but how can it know this? I also have the feeling that applications don't really want to understand how the ssl protocols happens, and neither how encodings are done, but rather just interfere as either providing parameters or being called at an appropriate instance. To me it seems too low level to allow applications to interfere with the protocol data, I'd prefer an API for some abstract service with set/get functions and callbacks, i.e., following exactly the same logic as with 'normal/standard' features. Thus, each extension is independant and needs support code. What has been attempted in the current snapshot is to concentrate the encoding/decoding stuff in one place where the appropriate encoding/decoding would be added for new extensions, and then, add the required logic where it has to be added. The global compile option of whether tls extensions are supported may not really be necessary unless one really has a small footprint problem. Well, this is my current state of thinking, the code in the devel snapshot is experimental, and the core team may change it at any time. Am I right that your current patch only provides a callback for ONE extension? Regards Peter Jouni Malinen wrote: On Tue, Jan 31, 2006 at 09:00:04PM +0100, Dr. Stephen Henson wrote: As has happened previously the functionality in the HEAD is not set in stone and may be subject to change. I'm aware of the 0.9.9 TLS extension efforts but I'm not currently actively involved with them. I have a shed load of other things to do. It looks like the current implementation is going more towards adding each TLS extension as a separate implementation whereas the patch that wpa_supplicant is using for EAP-FAST support has a more generic mechanism that allows arbitrary TLS extensions to be added to ClientHello without having to modify OpenSSL for each new type. Current CVS HEAD includes support for servername and host_name extensions. EAP-FAST is using PAC-Opaque extension, so it would need additional code to add that into the ClientHello. This would likely be something similar to the way setting host_name extension is done. Before starting to port the patch I've used with OpenSSL 0.9.8 to 0.9.9, I would like to get a better understanding on the desired design for TLS extensions and to find out whether someone else is working on implementing additional extensions at the moment. Is the current design of separate implementation without generic support for arbitrary extensions the preferred way of doing this (i.e., is it likely to remain in 0.9.9)? CHANGES file is marking most of the TLS extension code with subject to change. If separate implementation is desired, it would probably be a combination of adding the PAC-Opaque extension (a.k.a. SessionTicket TLS extension) and taking care of a callback for fetching pre-shared secret for session resumption. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
I'd like to see a generic callback mechanism in that I want to be able to write my own dispatcher for TLS extensions. I also want to be able to call something to put my own extension data in place per-SSL_CTX. (I want to be able to violate the TLS extension specification, if only to verify that my application is talking to another instance of itself, using a high-numbered extension. I'm surprised that the TLS extension authors didn't create an 'experimental' range of extension numbers -- it's going to take separate IETF action to reserve a small range.) Just because a lot of applications don't want to know how SSL/TLS is done doesn't mean that all of them don't. -Kyle H On 2/2/06, Peter Sylvester [EMAIL PROTECTED] wrote: Hello, The problem is that extensions may require modification of the internal states of openssl, or at least have to interfere with it in some cases. Or, in other words, extension doesn't mean that either all extensions are logically equivalent because they are indicated with some number in the hellos, some are extensions of the protocol which may be done with almost no interaction with the application. Example, treating the maximum packet size. It would mean that an application would call a SSL_set_hello_extension to set the value of the extension. Well, ok, but then openssl has to check first, whether it needs additional logic to support the required extension in any way, but how can it know this? I also have the feeling that applications don't really want to understand how the ssl protocols happens, and neither how encodings are done, but rather just interfere as either providing parameters or being called at an appropriate instance. To me it seems too low level to allow applications to interfere with the protocol data, I'd prefer an API for some abstract service with set/get functions and callbacks, i.e., following exactly the same logic as with 'normal/standard' features. Thus, each extension is independant and needs support code. What has been attempted in the current snapshot is to concentrate the encoding/decoding stuff in one place where the appropriate encoding/decoding would be added for new extensions, and then, add the required logic where it has to be added. The global compile option of whether tls extensions are supported may not really be necessary unless one really has a small footprint problem. Well, this is my current state of thinking, the code in the devel snapshot is experimental, and the core team may change it at any time. Am I right that your current patch only provides a callback for ONE extension? Regards Peter __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
Kyle Hamilton wrote: I'd like to see a generic callback mechanism in that I want to be able to write my own dispatcher for TLS extensions. You already have this, you can intercept all messages. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
On Tue, Jan 31, 2006 at 09:00:04PM +0100, Dr. Stephen Henson wrote: As has happened previously the functionality in the HEAD is not set in stone and may be subject to change. I'm aware of the 0.9.9 TLS extension efforts but I'm not currently actively involved with them. I have a shed load of other things to do. It looks like the current implementation is going more towards adding each TLS extension as a separate implementation whereas the patch that wpa_supplicant is using for EAP-FAST support has a more generic mechanism that allows arbitrary TLS extensions to be added to ClientHello without having to modify OpenSSL for each new type. Current CVS HEAD includes support for servername and host_name extensions. EAP-FAST is using PAC-Opaque extension, so it would need additional code to add that into the ClientHello. This would likely be something similar to the way setting host_name extension is done. Before starting to port the patch I've used with OpenSSL 0.9.8 to 0.9.9, I would like to get a better understanding on the desired design for TLS extensions and to find out whether someone else is working on implementing additional extensions at the moment. Is the current design of separate implementation without generic support for arbitrary extensions the preferred way of doing this (i.e., is it likely to remain in 0.9.9)? CHANGES file is marking most of the TLS extension code with subject to change. If separate implementation is desired, it would probably be a combination of adding the PAC-Opaque extension (a.k.a. SessionTicket TLS extension) and taking care of a callback for fetching pre-shared secret for session resumption. -- Jouni MalinenPGP id EFC895FA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: [EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]: This patch is adding support for TLS hello extensions and externally generated pre-shared key material to OpenSSL 0.9.8. This is based on the patch from Alexey Kobozev [EMAIL PROTECTED] (sent to openssl-dev mailing list on Tue, 07 Jun 2005 15:40:58 +0300). Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Stephen, Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to features like TLS extensions? Do you expect vendors like Red Hat or Suse to include and support patches like TLS extensions on their own once they have standardized on a version of openssl for their enterprise products? For example, Red Hat Enterprise Linux 4 was released almost 1 year ago and includes 0.9.7a plus all the security patches issue over the last year. If I need the TLS extension patch officially supported by Red Hat, it would have to come from upstream -- your group -- or they would have to support it as a one-off patch. I was hoping your group would accept it, but it appears your efforts are concentrated on 0.9.9- dev. Thanks for your time. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||:...:|||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
Brian Long wrote: On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to features like TLS extensions? The message above means that there's no way a patch that's different and incompatible with the one in 0.9.9 will be included. Not more than that. This will never get inside 0.9.7, that's certain. But I think the door is not completely closed on it getting inside an evolution of 0.9.8. 0.9.8 is really recent as far as openssl development goes, 0.9.9 is a really far perspective, so I think we *could* get in a situation where a convincing case could be presented to the openssl team that this feature is important enough to deserve to be back-ported and integrated in the stable release. But only if the code gets really stable and the change does not impact too much of 0.9.8. For example, Red Hat Enterprise Linux 4 was released almost 1 year ago and includes 0.9.7a plus all the security patches issue over the last year. If I need the TLS extension patch officially supported by Red Hat, it would have to come from upstream -- your group -- or they would have to support it as a one-off patch. I was hoping your group would accept it, but it appears your efforts are concentrated on 0.9.9- dev. Please check how your patch compares to the one that's in 0.9.9, if it brings something useful to it and in that case submit the enhancements to the 0.9.9 version. Then see how to create a patch based on the 0.9.9 version (and on any enhancement you could find), but that applies to 0.9.8. Then there's a chance in the future, RHEL 5 with 0.9.8 will some day include it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
On Tue, Jan 31, 2006, Jean-Marc Desperrier wrote: Brian Long wrote: On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to features like TLS extensions? The message above means that there's no way a patch that's different and incompatible with the one in 0.9.9 will be included. Not more than that. Well I didn't quite mean it like that. As has happened previously the functionality in the HEAD is not set in stone and may be subject to change. I'm aware of the 0.9.9 TLS extension efforts but I'm not currently actively involved with them. I have a shed load of other things to do. But I think the door is not completely closed on it getting inside an evolution of 0.9.8. 0.9.8 is really recent as far as openssl development goes, 0.9.9 is a really far perspective, so I think we *could* get in a situation where a convincing case could be presented to the openssl team that this feature is important enough to deserve to be back-ported and integrated in the stable release. But only if the code gets really stable and the change does not impact too much of 0.9.8. Along with stability an issue of primary importance is binary compatibility. If the proposed change breaks binary compatibility in a stable branch that is a very bad thing(TM). It is also my understaning that existing applications would in any case need to be modified to support TLS extensions. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Long Sent: Tuesday, January 31, 2006 5:58 AM To: openssl-dev@openssl.org Subject: Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2) On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: [EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]: This patch is adding support for TLS hello extensions and externally generated pre-shared key material to OpenSSL 0.9.8. This is based on the patch from Alexey Kobozev [EMAIL PROTECTED] (sent to openssl-dev mailing list on Tue, 07 Jun 2005 15:40:58 +0300). Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Stephen, Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to features like TLS extensions? Do you expect vendors like Red Hat or Suse to include and support patches like TLS extensions on their own once they have standardized on a version of openssl for their enterprise products? For example, Red Hat Enterprise Linux 4 was released almost 1 year ago and includes 0.9.7a plus all the security patches issue over the last year. If I need the TLS extension patch officially supported by Red Hat, it would have to come from upstream -- your group -- or they would have to support it as a one-off patch. I was hoping your group would accept it, but it appears your efforts are concentrated on 0.9.9- dev. Brian, let me butt-in here if I may. The linux distribution managers for redhat, suse, and so on typically will use the same version of major packages like openssl, apache, sshd, and so on for every minor version release in that train. As you noted, RHEv4 came out with 0.9.7 I would expect newer minor releases of RHEv4 to come with newer 0.9.7 versions of openssl. I would expect that when RHEv5 comes out that it would use openssl version 0.9.8 Now, you want TLS support. So you have a choice: use RHEv4, delete their binary of openssl and all it's libraries, along with all dynamically linked binaries supplied in RHEv4 that are linked to the openssl libraries, compile the latest openssl that has TLS support, then recompile all the binaries that you need that are linked to this. Use RHE version -future meaning wait for some version of RHE to come out that supports TLS Use some minimal Linux distro that does not inclue any ssl-aware apps in it, and build the latest version of openssl with tls support, then build what ssl-aware apps you want. People use products like RHE because they want to pay someone for a binary linus distro that has a bunch of pre-rolled programs in it, rolled to some fixed, supportable definition. People that do this are happy to pay RH to patch their RHE v4 to get features they want, which I think is where your TLS patches might be useful. But, how RH does it, which incidentally is how the traditional major UNIX vendors do it (like Sun) isn't how the Open Source community does it. The open source community wants people like you, who are willing to do the work, to put their efforts into the current code. The features you put into the current code will eventually percolate down to packagers like RH and their customers. But, you should not be concerned with what RH is doing. If RH wants to take TLS support from the latest rev of openSSL and back-port it to RHE v4, that is their problem. You are making it your problem, and you need to know that this is going to be wasted effort. The OpenSSL developers cannot use your effort, because your working with old code, and the RH people don't have customers demanding TLS support in RHE v4, and so they aren't going to be interested in your patches either. Most likely, if RH did get a bunch of customers wanting TLS, they would put their development effort into putting TLS into the next version of RHE, then tell all their customers to spend money to upgrade to the new version of RHE. It is not to the open source communitites benefit to have the opensssl developers spend a lot of time back-porting new features to old openssl distros. It always distresses me when I see a cool feature patched into older open source code, because I know it's a dead end. I learned this myself a few years ago when I spent a lot of effort porting ancient patches to the mt command that supported moving the tape to a specific block number. Unfortunately I stupidly worked with production, not development code, so when I finally got it all working, the development code had so changed in that code section, all my effort was wasted also. Eventually someone did put that support into mt, a few years later, fortunately, but not using any of my work. Anyway, I hope that you do take a look at the current openssl development code and see if anything you worked on can be used there. Ted __ OpenSSL Project
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: [EMAIL PROTECTED] - Fri Jan 27 15:01:56 2006]: This patch is adding support for TLS hello extensions and externally generated pre-shared key material to OpenSSL 0.9.8. This is based on the patch from Alexey Kobozev [EMAIL PROTECTED] (sent to openssl-dev mailing list on Tue, 07 Jun 2005 15:40:58 +0300). Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Understood. Is there any way to get TLS extension code back-ported to 0.9.7 and 0.9.8? I've just recently joined the list, so I don't understand the development cycle. Is 0.9.7 only accepting security fixes? What about 0.9.8? /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||:...:|||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
On Fri, Jan 27, 2006 at 03:23:32PM +0100, Stephen Henson via RT wrote: This patch is adding support for TLS hello extensions and externally generated pre-shared key material to OpenSSL 0.9.8. Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. That's nice to hear. I'll need to take a look at that and see how much of the functionality needed for EAP-FAST is already included. The other part would be to have support for session resumption using draft-salowey-tls-ticket-07.txt. Has anyone taken a look at that and are there plans on adding support for it in 0.9.9-dev? The patch mentioned above includes at least the parts of this that are needed for peer side implementation of EAP-FAST. tls-ticket draft may include somewhat more generic mechanism, though. -- Jouni MalinenPGP id EFC895FA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
