[ech] ECH split mode API

[Stephen Farrell]

Hiya,

I'm wondering about changing the API I defined to allow
applications to support ECH split-mode, mostly due to
having now gotten that working for nginx and haproxy,
with the recent work including support for handling the
second ClientHello when one hits HRR, and properly
handling early data when that's present.

The main off-the-wire input for the existing API is an
encoded (outer) ClientHello (including the record layer
header) as that's what's easily available when processing
the first client hello. When ECH decryption works, we
return the inner ClientHello, similarly encoded.

But it turns out that it may be better to accept a
different input, for two reasons: the 2nd ClientHello
when one hits HRR is preceded by 6 octets of (pretend)
ChangeCipherSuite and secondly, if the first ClientHello
is accompanied by early data, then the buffer that the
application has may include that after the ClientHello.
And in the application code, when not terminating TLS,
those all tend to be present in one buffer (when the
client sent 'em) as they likely arrived in one packet.

I had to write basically the same code in nginx and
haproxy to handle the wrangling of the above and, if
ECH decryption works, to re-constitute the right buffer
containing as appropriate the CCS, inner ClientHello and
early data.

So, I'm thinking of changing the API to accept as input
a sequence of catenated encoded TLS messages, with the
success case behaviour being to return a buffer that's
the same but with the outer ClientHello being replaced
by the inner. That should eliminate the need to peek
into the TLS encoding so much in the application.

The current API is below, (or at [1]) and the change
would be to go from ``outer_ch`` as an input to
``tls_msgs_buf`` or some such, likely with a check
that the input contains an optional CCS, then a CH
and may have additional octets we don't look into
(the early_data).

Any thoughts or ideas about potential gotchas welcome.
(I think I recall someone possibly holding their nose
about this API when we spoke before, so other comments
on this are also welcome since I'm likely to be making
these changes soonish anyway:-)

Thanks,
S.

[1] 
https://github.com/sftcd/openssl/blob/ECH-draft-13c/include/openssl/ech.h#L117

int SSL_CTX_ech_raw_decrypt(SSL_CTX *ctx,
        int *decrypted_ok,
        char **inner_sni, char **outer_sni,
        unsigned char *outer_ch, size_t outer_len,
        unsigned char *inner_ch, size_t *inner_len,
        unsigned char **hrrtok, size_t *toklen);
-------------- 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/20230830/2b80480a/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/20230830/2b80480a/attachment.sig>