[ech] custom TLS client hello extensions

[David Benjamin]

There was some previous discussion of this here:
https://github.com/tlswg/draft-ietf-tls-esni/issues/398#issuecomment-796287240

For existing API callers, I think the two reasonable options are to put it
in both or just in the inner ClientHello.

Just in the outer ClientHello doesn't make much sense because the true
ClientHello is the inner one, and presumably the ECH-unware application
configured the extension in order to use it!

Just inner vs. both probably depends on the shape of the API, and whether
the application would likely to be upset about the recovery flow's
handshake failing to negotiate it. I haven't looked too closely at that,
but I would guess both is the better answer. Note that, even though custom
ClientHello extensions may be sensitive, existing, ECH-unaware callers were
evidently perfectly happy putting it in the cleartext ClientHello, so
saying you need to update your calls to put something in inner without
outer would still be perfectly sound.

David

On Thu, Mar 2, 2023, 09:40 Matt Caswell <matt at openssl.org> wrote:

>
>
> 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.
> >
> >
> --
> ech mailing list
> ech at openssl.org
> https://mta.openssl.org/mailman/listinfo/ech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/ech/attachments/20230302/c6359972/attachment-0001.htm>