[TLS] RFC 9849 clarifying split mode security

[Florentin Rochet <[e-mail]>]

Dear everyone,

First of all, many thanks to all the people involved in RFC 9849. This 
is a very nice privacy-preserving advancement for networking protocols.

Reading the RFC, I am being confused by the security guarantee(s) and 
the distinction existing between the split mode and the shared mode 
regarding their threat model, if any exists? Regarding the shared mode, 
we terminate the connection at the client-facing server and we have then 
to trust it for privacy of the data stream. Ok.

Regarding the split-mode, the reverse proxy forwards the handshake to 
the backend server. This does not seem to provide any added security 
value compared to the shared mode, at least within the TLS 1.3 
adversarial model assuming that any on-path middlebox can act as an 
active attacker. Worse, this could mislead deployment and users to 
believe there is a security benefit to the split-mode.

In split mode, I would consider the client-facing server as an untrusted 
middlebox for data stream privacy. But a malicious client-facing server 
should be able to MITM any client throwing an ECHClientHello by first 
having requested itself certificates for the backend domains that it is 
supposed to provide service to. That is, since similarly to the shared 
mode, the backend domain owner has to configure the DNS to point to the 
client-facing server. The client-facing server is then able to acquire 
valid certificates using the ACME protocol, and terminate the connection 
while the backend would expect split mode. Technically, it does not 
appear to me that either the client or the backend would understand that 
the connection is being MITM'ed; potentially, additional certificates 
would appear in CT logs, but that's about it.

So, I think I need clarification on the expected threat model difference 
between split mode and shared mode. From section 10.1, I read the following:

 >   Passive and active attackers can exist anywhere in the network,
 >   including between the client and client-facing server, as well as
 >   between the client-facing and backend servers when running ECH in
 >   split mode.  However, for split mode in particular, ECH makes two
 >   additional assumptions:
 >
 >   1.  The channel between each client-facing and each backend server is
 >       authenticated such that the backend server only accepts messages
 >       from trusted client-facing servers.  The exact mechanism for
 >       establishing this authenticated channel is out of scope for this
 >       document.

It looks like the client-facing server is excluded from the potential 
attackers, and is "trusted", similarly to the shared mode. Then what is 
the usefulness of the split mode? Why do we need it, what does it bring 
compared to shared mode (security-wise)?

Then I read the following statement within the RFC:

 >   Given this threat model, the primary goals of ECH are as follows.
 >
 >   1.  Security preservation.  Use of ECH does not weaken the security
 >       properties of TLS without ECH.

In split mode this statement appears only true if we trust the 
client-facing server. But since as the RFC says, the client-facing 
server and backend server are "separated" in split mode. Would that 
trust assumption always hold in such a separated context? Or will we 
have deployment that incorrectly claim that they provide end-to-end 
security because they use split mode, and use that argument to say that 
they're better than Cloudflare?

Thanks in advance to anyone pointing flaw(s) in the reasoning, or 
confirming the confusion :-)

Best,

Florentin