<div dir="auto"><div><div dir="auto">There was some previous discussion of this here:</div><div dir="auto"><a href="https://github.com/tlswg/draft-ietf-tls-esni/issues/398#issuecomment-796287240">https://github.com/tlswg/draft-ietf-tls-esni/issues/398#issuecomment-796287240</a></div><div dir="auto"><br></div>For existing API callers, I think the two reasonable options are to put it in both or just in the inner ClientHello.</div><div dir="auto"><br></div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">David<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Mar 2, 2023, 09:40 Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 02/03/2023 13:53, Stephen Farrell wrote:<br>
> <br>
> Hiya,<br>
> <br>
> On 02/03/2023 13:31, Salz, Rich wrote:<br>
>> I think a reasonable thing to do, in the initial implementation, is<br>
>> to say that custom extensions only appear in the outer hello message.<br>
> <br>
> Almost. The custom ext type would also need to be in the<br>
> inner CH (in compressed form) to get best interop I guess.<br>
> <br>
> Beyond that, it could get complex very easily, with all<br>
> the potential mixtures of inner, outer, compressed and<br>
> same or different values in inner and outer. APIs for all<br>
> that could be added, but I'm very unsure what'd be useful.<br>
> (E.g. using a server API that provided a map of which<br>
> extension values had been seen where could be a bit of a<br>
> nightmare;-)<br>
<br>
Well, extensions can already be added to most message types in TLSv1.3 <br>
and the current extension handling code manages most of this complexity.<br>
<br>
All extensions have the concept of a "context" which specifies which <br>
messages it is allowed to appear in, e.g. the server_name extension has <br>
this:<br>
<br>
         TLSEXT_TYPE_server_name,<br>
         SSL_EXT_CLIENT_HELLO | SSL_EXT_TLS1_2_SERVER_HELLO<br>
         | SSL_EXT_TLS1_3_ENCRYPTED_EXTENSIONS,<br>
<br>
We will need to consider what the SSL_EXT_CLIENT_HELLO context value <br>
maps to: is it inner or outer CH? I would expect to see a new context <br>
value, e.g. SSL_EXT_CLIENT_HELLO_INNER (or possibly <br>
SSL_EXT_CLIENT_HELLO_OUTER).<br>
<br>
Matt<br>
<br>
<br>
<br>
> <br>
>> But maybe I'm wrong, is there a particular extension you are thinking<br>
>> of?<br>
> <br>
> Nope. Fact is, I don't know anything about how these<br>
> are/have been used, so I'm trying to find out a bit.<br>
> (Any more info/pointers appreciated.)<br>
> <br>
> I could envisage all sorts of PII being put in such<br>
> extensions, for example, and if that were the case, it<br>
> may well make sense to provide more fully featured<br>
> APIs. But if that doesn't happen, then probably better<br>
> to leave such for another day.<br>
> <br>
> Cheers,<br>
> S.<br>
> <br>
> <br>
-- <br>
ech mailing list<br>
<a href="mailto:ech@openssl.org" target="_blank" rel="noreferrer">ech@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/ech" rel="noreferrer noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/ech</a><br>
</blockquote></div></div></div>