Subject: [dispatch] dispatching draft-farrell-tls-wkesni

From: Stephen Farrell <[email-masked]>
Date: Tue, 5 Apr 2022 00:06:27 +0100

Hi all,

(Thanks again to Joe Salowey for presenting this in Vienna
when I had to be in another room.)

My impression of the discussion [1] of this draft [2] is
that there's interest in the draft but people were fuzzy
as to where it might best be processed. The meeting notes
indicate that more dispatch discussion on this list was
the desired outcome, so here goes...

My take, in case it helps: ask TLS to adopt with review
from HTTPBIS. I fully agree it ought be processed by an
IETF WG.

Responding to what I think is the main technical issue
identified at the meeting (relevant to the dispatch
question) and that will need to be addressed during WG
processing: the appropriate level of generality here is
a tricky issue, and (again as pointed out in the notes)
needs input from those who'll operate servers.

I figure though that there's a useful guideline we can use
here. The relevant HTTP server for this spec is the ECH
private key holder. The ECH private key holder processes
the outer ClientHello so whatever they wish to ask be used
there by eventual TLS clients, in the outer ClientHello,
seems like it should be supported here. And that's the
ECHConfigList which is already an extensible structure
and is the meat of the HTTP response defined here.

What ought be in the inner ClientHello is up to the
eventual/backend web origin (the "publisher" of the
HTTPS/SVCB RR) which is the HTTP client in this spec
and so ought not be represented in the JSON (or
whatever) HTTP response messages defined here. IOW,
that's an argument for the current design in [2].

Of course, experience may demonstrate that some more
is needed, but I'm sure that'd emerge in WG processing,
regardless of which WG "owns" the spec.

Also looking at the notes, I agree that the timing for
this ought be driven by ECH (also a TLS spec) - from
my POV, this one would ideally turn into an RFC a few
months after the ECH spec, which again, for me, argues
that the TLS WG is best placed to process this.

Cheers,
S.

[1] 
https://notes.ietf.org/notes-ietf-113-dispatch#A-well-known-URI-for-publishing-ECHConfigList-values-20-mins
[2] https://datatracker.ietf.org/doc/html/draft-farrell-tls-wkesni

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 5 Apr 2022 10:18:10 -0400

I support dispatch to the TLS WG.

On Mon, Apr 4, 2022 at 7:07 PM Stephen Farrell <[email-masked]>
wrote:
...

> and is the meat of the HTTP response defined here.

This is an interesting observation, and I agree that it supports dispatch
to TLS, because both the client and server of this protocol are TLS servers
in this view.

I also think this raises some questions about whether HTTP is the
appropriate transport for this information.  If we assume, as you propose,
that (1) client and server are both TLS servers and (2) origin->DNS sync is
handled through some other means, then there are many other possible ways
to convey this information.  Two that come to mind are (1) reading the
ECHConfigList out of the fallback ServerHello and (2) publishing the
ECHConfigList in a SVCB record.

> HTTPS/SVCB RR)

Note that this is true only in true "split mode" deployments.  In ordinary
shared hosting, the origin should normally publish a CNAME or AliasMode
HTTPS/SVCB record, in order to avoid this entire synchronization problem.

To me, this suggests that what is really needed here is an "ECH Deployment
Architectures" draft or similar.  Regardless, that would happen in the TLS
WG.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 5 Apr 2022 16:22:31 +0100

Hi Ben,

> to TLS, because both the client and server of this protocol are TLS servers

At the risk of diving too deep for dispatch (but no harm
to have in the archive for later...)

> ECHConfigList out of the fallback ServerHello 

That's possible, however, at least for my implementation,
only one (the most recent) ECHConfig will be returned to
clients that way, whereas I publish 3 in the DNS (current,
previous, and one-before). I'm not sure what others do in
the fallback case, but to depend on that, more text would
be needed in the ECH draft.

> and (2) publishing the

I guess that could work if that SVCB were somewhere below
the public_name, but it might get onerous if one frontend
serves many backends. (It also smells a bit of turtles
all the way down:-)

> Note that this is true only in true "split mode" deployments. 

That's fair, yes.

> In ordinary

Sure - as the draft says, the proposed mechanism doesn't
aim to be the one-true way, but addresses a use-case that
matches my existing trial deployment. I'd be v. happy for
the content to evolve to better handle others, as needed.

> Architectures" draft or similar.  

Yeah, that'd make sense perhaps. I'd be happy to contribute
text or co-author such if some others wanted to play along.
(If someone wants to get started on that, and would like me
to help, just ping me.)

> Regardless, that would happen in the TLS
> WG.

Right.

Cheers,
S.