Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)

[Peter Sylvester]

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

try to have a very generic extension mechanism.


protocol which may be done with almost no interaction with the application.
Example, treating the maximum packet size. It would mean that an application

the required extension in any way, but how can it know this?



To me it seems too low level to allow applications to interfere with the


Thus, each "extension" is independant and needs support code. What has been

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.



Regards
Peter

Jouni Malinen wrote:

servername and srp. We initially also had the idea and a logic where one could 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 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 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. 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. attempted in the current snapshot is to concentrate the encoding/decoding stuff Am I right that your current patch only provides a callback for ONE extension?

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