I personally propose the community to reconsider the design of accept_confirmation.
May be it sounds crazy, I advise to drop the requirements of the accept_confirmation. So that we can deploy the IETF without touching the backend server in the Split-Mode. And this will be a big promotion for the deployment of ETH, in the cost of the complication of client side. The client side must be modified to deploy the ETH. However, the server-side modifications is optional. Requiring modify the server-side will do harm for the deployment rate of ETH. Just FYI~ > On Sep 17, 2024, at 13:05, Joseph Salowey <j...@salowey.net> wrote: > > ECH has been revised based on working group input and is ready to go to the > IESG. You can see the diff between the latest (-22) and the one published > previous to the last IETF (-18) here: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-esni-18&url2=draft-ietf-tls-esni-22&difftype=--html. > > There has been some discussion of ECH proxy on the list, but something > similar has already been discussed as pointed out in the thread and there > does not appear to be consensus to make this sort of change in this version. > > I plan to submit this early next week. > > Cheers, > > Joe > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
