Re: [radext] Server identity and RFC7585bis

[Stephen Farrell <[e-mail]>]

Hiya,

On 11/04/2024 13:21, Jan-Frederik Rieckers wrote:
> 
> I shortly had it in mind when I started writing the text, but good to 
> raise it explicitly.

Ah good. I suspect just verifying that there's no impact
will be enough, but anyway...

> 
> I don't think that it would really affect deployments.
> 
> As far as I understand ECH, one use case that can be achieved by ECH is 
> that a load balancer decrypts the Client Hello and then makes a 
> forwarding/routing decision based on the data in the "plaintext" Client 
> hello, and forwards the Client Hello and any subsequent traffic to the 
> final endpoint.

That's possible yes. That's ECH "split-mode" which so far
seems less likely to be deployed so much for the web, but
could I guess be more useful here, e.g. maybe as part of
something like eduroam or similar? Again though, I've not
thought it through, but be good if someone did that.

> So if an SNI is part of the ECH and we are routing the TLS traffic to 
> different RADIUS servers in the backend, it should not be a problem that 
> the endpoint that makes the routing decision is also the ECH-Endpoint.
> I can't really picture a scenario where the routing decision based on 
> SNI is made by an untrusted party.

Fair enough. Might be no harm somewhere though to note in
the spec that ECH exists and might end up being used, and
so it'd therefore be fragile for intermediaries to depend
on the visible (possibly "outer") SNI in the ClientHello
mapping to the eventual TLS server identity. I'd say a note
like that is probably sufficient.

Cheers,
S.