[ech] custom TLS client hello extensions

[Stephen Farrell]

Hiya,

On 02/03/2023 14:40, Matt Caswell wrote:
> 
> Well, extensions can already be added to most message types in TLSv1.3 
> and the current extension handling code manages most of this complexity.
> 
> All extensions have the concept of a "context" which specifies which 
> messages it is allowed to appear in, e.g. the server_name extension has 
> this:
> 
>          TLSEXT_TYPE_server_name,
>          SSL_EXT_CLIENT_HELLO | SSL_EXT_TLS1_2_SERVER_HELLO
>          | SSL_EXT_TLS1_3_ENCRYPTED_EXTENSIONS,
> 
> We will need to consider what the SSL_EXT_CLIENT_HELLO context value 
> maps to: is it inner or outer CH? I would expect to see a new context 
> value, e.g. SSL_EXT_CLIENT_HELLO_INNER (or possibly 
> SSL_EXT_CLIENT_HELLO_OUTER).

Could be, though it's unfortunately a bit more complex;-(

What I've done so far (for standard extensions) is to add
new arrays (similar to ext_defs) that encode whether or not
an extension should have different values for inner and outer
or not, and if not, whether the inner value should be the
compressed form of the outer value. Extensions where there's
special handling of inner/outer, like SNI, alpn and psk are
handled a bit specially but the above is the general case.

I do plan for those flags to end up in the general ext_defs
array in the end, but it's been easier to keep 'em separate
for the moment (for git rebasing). I'm not sure yet whether
that'd be best done via a new field in EXTENSION_DEFINITION
or, as you suggest, via SSL_EXT_CLIENT_HELLO_INNER or
something like that as new values for the context field.
(As there're a few combinations, it may be better to have
a new ech_handling field, or function pointer.)

Once that's closer to being ready to merge, we may also
decide that there's no need to support sending identical
extension values in both inner and outer, which'd make
things simpler, but then we might also decide there's
value in making it easier (at compile time or run time)
to support sending some only in the inner when ECH is
attempted, or the opposite, making it more complicated;-)
IIRC, nss tries to maximally compress, though I forget
what boring does. (And in case you're wondering, sometimes
having the same extension value in both inner and outer
has been useful to test the server can handle all the
combinations allowed by the protocol, e.g. right now I
send different key_share extension values "just because":-)

Once we bottom out on all that, I guess mimicing some
or all of what we end up with enabling for standard
extensions (via the ext_defs array) will probably make
sense for custom extensions.

Meanwhile, any/all thoughts on the above are welcome!

Cheers,
S.

PS: I coded up a test - it didn't crash or leak, but of
course didn't work first time:-) Will work that in the
coming days.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE4D8E9F997A833DD.asc
Type: application/pgp-keys
Size: 1197 bytes
Desc: OpenPGP public key
URL: <https://mta.openssl.org/pipermail/ech/attachments/20230302/2459832c/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/ech/attachments/20230302/2459832c/attachment.sig>