Subject: updating ECH keys from a web server

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Feb 2022 01:35:31 +0000

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/

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 22 Feb 2022 10:57:30 -0500

Given that this is a protocol for communication between an HTTP origin (as
the server) and the authoritative DNS server for its hostname (as the
client), I think we'll also need some input from DNSOP.

That context also helps me to see other things that might naturally fit
here, such as the list of supported HTTP versions (i.e. ALPN values), to
populate the HTTPS records correctly.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Feb 2022 17:13:46 +0000

Hi Ben,

> client), I think we'll also need some input from DNSOP.

Fair point.

> populate the HTTPS records correctly.

Good point - I only publish very bare-bones HTTPS RRs for my
test servers, so didn't include that, but will. I created an
issue for that. [1]

Cheers,
S.

[1] https://github.com/sftcd/wkesni/issues/1

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 23 Feb 2022 11:54:27 +1100

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:
> Attachments:
> * OpenPGP_0x5AB2FAF17B172BEA.asc
> * OpenPGP_signature

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Feb 2022 01:27:53 +0000

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.

>> 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
>