Re: updating ECH keys from a web server

Hi Stephen,

The thing that I got stuck on when reading the draft this time is the conditions under which this might provide value.

For ECH to provide privacy benefits, you need multiple web servers to share an ECH config.  That is, there is coordination.

For each server to independently publish an config doesn't fit with that model particularly well.  It's good, in the sense that you might be able to *use* ECH, but that doesn't mean that there is any benefit arising from that deployment model.

Sorry, that's TLS-level feedback; the HTTP feedback I might give is: you set a desired TTL, but that leads to some interesting interactions with the HTTP caching semantics (Expires and Cache-Control in particular).  Have you considered driving the TTL from the HTTP response freshness?


On Tue, Feb 22, 2022, at 12:35, Stephen Farrell wrote:
> Hiya,
>
> TL;DR: I'm hoping to get feedback from httpbis folks
> related to draft-farrell-tls-wkesni [1].
>
> The TLS WG is well down the (long;-) road developing the
> encrypted client hello (ECH) spec. [2] I implemented [3]
> that and as part of that, to support rotating ECH keys, I
> needed to implement a way to get newly generated keys into
> the DNS, within HTTPS RRs (or SVCB RRs) according to [4].
> So I implemented [1] which allows a web server to make it's
> current set(s) of ECH keys available to DNS infrastructure
> via a .well-known URL. (In my case the web server has no
> dynamic DNS API, hence the need for something more.)
> This leaves control of the ECH private values with the
> web server (admins), which seems desirable in many cases,
> and control over modifying zone files to DNS admins which
> also seems desirable.
>
> This was briefly discussed at a few TLS WG sessions, but
> hasn't yet been "adopted." In part, that's because it's
> not clear whether or not this is a sufficiently useful
> way to handle the task, nor whether some web server
> administrators might be more interested in other tooling
> that might include this kind of feature.
>
> So, I'd appreciate feedback as to whether this seems like
> a useful tool to be in the toolbox or whether something
> else might be more useful, in particular for web server
> admins who don't have a dynamic DNS API available and for
> implementers developing web servers that need to support
> such deployments.
>
> Thanks,
> Stephen.
>
> [1] https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/
> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> [3] https://defo.ie/
> [4] https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>
> Attachments:
> * OpenPGP_0x5AB2FAF17B172BEA.asc
> * OpenPGP_signature

Received on Wednesday, 23 February 2022 00:55:00 UTC