[RFC] TLS Session Resumption Support for Streams

I would like to introduce a TLS Session Resumption Support for Streams
RFC that is part of my stream evolution work (PHP Foundation project
funded by Sovereign Tech Fund) :

https://wiki.php.net/rfc/tls_session_resumption_api

I have a few questions/comments:

| Client-Only Options:
|
| session_data (string) - Binary session data from a previous connection
| to resume. Data must be from a session_new_cb callback.
...
| session_new_cb (callable) - Callback invoked when a new session is
| established.
| ...
| - $sessionData: Serialized session (OpenSSL format via
| i2d_SSL_SESSION)

1. Would it be possible to ensure this data is from the callback?

2. I am asking mostly whether we think it is wise that this internal
   openssl data is exposed to the user, for which this is mainly an opaque
   blob of data — or in other words, an implementation detail of OpenSSL.

| Client Behavior
| ...
| 3. Server-only options (''session_get_cb'', ''session_remove_cb'',
| ''session_cache'', ''num_tickets'', etc.) are ignored

I don't think it is wise to ignore these, and I would prefer an error
situation to be caused by supplying options that have no effect.

| Server Behaviour
| ...
| With External Cache (session_get_cb provided):
| - session_new_cb becomes required (E_WARNING if missing)
| - session_context_id becomes required (E_WARNING if missing)

If is is required, it shouldn't be a warning as it is a programming
error for which an Error-type exception ought to be thrown. On many
occasions warnings appear in a logging black hole.

| - session_cache_size and session_timeout are ignored (application
| manages storage)

For similar reasons, I don't think these should be just ignored either
(again: it's a programming error).

| Backward Incompatible Changes
| ...
| - New options are ignored in older PHP versions (standard stream
| context behavior)

That's not a Backward Compatibility issue, but a Forward Compatibility
issue.

| Potential Considerations:
| ...
| - The new callbacks use resources passed as parameters - these must
| not be stored beyond the callback scope (documented limitation)

Would it be possible to do this without introducing new
resources/resource types?

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

Hi

I would like to introduce a TLS Session Resumption Support for Streams RFC
that is part of my stream evolution work (PHP Foundation project funded by
Sovereign Tech Fund) :

https://wiki.php.net/rfc/tls_session_resumption_api

Thank you for the RFC. The feature makes sense to me and fills a clear
gap. I'm sharing some of Derick's concerns and questions, particularly:

1. What will happen if an incorrect / outdated / malformed
   session_data string is provided? Will it silently be ignored? Will it
   emit an error? Will there be issues internally in OpenSSL?

2. We should avoid introducing new E_WARNINGs, particularly for clear
   error situation (session_get_cb without session_new_cb).

Best regards
Tim Düsterhus