[ech] custom TLS client hello extensions

[Matt Caswell]

On 02/03/2023 13:53, Stephen Farrell wrote:
> 
> Hiya,
> 
> 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
> nightmare;-)

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).

Matt



> 
>> But maybe I'm wrong, is there a particular extension you are thinking
>> of?
> 
> 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.
> 
> Cheers,
> S.
> 
>