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

[Stephen Farrell <[e-mail]>]

Hi Ben,

On 05/04/2022 15:18, Ben Schwartz wrote:
> I support dispatch to the TLS WG.
> 
> On Mon, Apr 4, 2022 at 7:07 PM Stephen Farrell <[e-mail]>
> wrote:
> ...
> 
>> 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.
>>
> 
> 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.

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

> 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 

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
> ECHConfigList in a SVCB record.

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

> What ought be in the inner ClientHello is up to the
>> eventual/backend web origin (the "publisher" of the
>> HTTPS/SVCB RR)
> 
> Note that this is true only in true "split mode" deployments. 

That's fair, yes.

> In ordinary
> shared hosting, the origin should normally publish a CNAME or AliasMode
> HTTPS/SVCB record, in order to avoid this entire synchronization problem.

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.

> To me, this suggests that what is really needed here is an "ECH Deployment
> 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.


>