[ech] custom TLS client hello extensions
matt at openssl.org
Thu Mar 2 14:40:11 UTC 2023
On 02/03/2023 13:53, Stephen Farrell wrote:
> On 02/03/2023 13:31, Salz, Rich wrote:
>> I think a reasonable thing to do, in the initial implementation, is
>> to say that custom extensions only appear in the outer hello message.
> Almost. The custom ext type would also need to be in the
> inner CH (in compressed form) to get best interop I guess.
> Beyond that, it could get complex very easily, with all
> the potential mixtures of inner, outer, compressed and
> same or different values in inner and outer. APIs for all
> that could be added, but I'm very unsure what'd be useful.
> (E.g. using a server API that provided a map of which
> extension values had been seen where could be a bit of a
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
SSL_EXT_CLIENT_HELLO | SSL_EXT_TLS1_2_SERVER_HELLO
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
>> But maybe I'm wrong, is there a particular extension you are thinking
> Nope. Fact is, I don't know anything about how these
> are/have been used, so I'm trying to find out a bit.
> (Any more info/pointers appreciated.)
> I could envisage all sorts of PII being put in such
> extensions, for example, and if that were the case, it
> may well make sense to provide more fully featured
> APIs. But if that doesn't happen, then probably better
> to leave such for another day.
More information about the ech