Re: updating ECH keys from a web server

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
>