- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Wed, 23 Feb 2022 01:27:53 +0000
- To: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
- Message-ID: <8cab79d5-ef22-02fc-b4a5-ecec32a94132@cs.tcd.ie>
Hiya, On 23/02/2022 00:54, Martin Thomson wrote: > 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; Sure, it's a valid point. My argument for this is that there do seem to be cases where a mechanism like this seems needed and as you say that's independent of the relative benefits from ECH at different scales. But this .well-known (being a URL on the ECH frontend) should also work fine at scale, and that might have a role even for large scale frontends if a backend web server uses a different DNS operator (be that split-mode ECH or not). > 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? Nope, I've not. I guess that might work but even so it seems better to allow for an explicit value in the response body. In my case I just set the requested TTL to half the cadence of ECH key rotation, not for any particularly good reason;-) Cheers, S. PS: In case it helps - I've no real attachment to the current JSON thing, it's just what I implemented but (if this goes forward), I'd expect that to change, and that's fine. > > > 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 >
Attachments
- application/pgp-keys attachment: OpenPGP public key
Received on Wednesday, 23 February 2022 01:28:17 UTC