What does ECH acceptance mean in Split Mode?

[kazuho]

In Shared Mode, when a client receives ECH accept confirmation and the handshake successfully completes, the client knows that sensitive extensions such as SNI were hidden from observers, regardless of how DNS is configured. This is because we can assume that the owner of the ECH private key is the owner of the private key corresponding to the server certificate. Fine.

But what does ECH acceptance mean in Split Mode?

At the moment, we do not prohibit backend servers signaling ECH acceptance against connections that originate from arbitrary location.

If backend servers are to accept connections from arbitrary client-facing servers and respond with an ECH accept confirmation, it becomes trivial for a network operator controlling DNS responses to setup a client-facing proxy. If such a client-facing proxy acting as a transparent proxy is setup by a local network operator, then the IP address of the client and the SNI would be visible on the Internet. I would be hesitant to say that ECH is providing any value in such scenario.

To paraphrase, in contrast to Shared Mode, ECH acceptance means very little when the server is in Split Mode.

Admittedly, section 10.9.6 (Enable Multi-party Security Contexts) states that “assuming ECH records retrieved from DNS are authenticated (snip) Resolver, spoofing a client-facing server operating in Split Mode is not possible.”

But I wonder if we should better be more direct about the problem. To give an example, it might be a good idea to state in Section 3 (Topologies) that use of a secure channel between the client-facing server and backend server is assumed, and that otherwise spoofing is possible.

[sayrer]

Is there any way for a client to tell the difference between a server operating in "Shared Mode" vs one in "Split Mode"? I support ECH as a wire protocol, but these deployment considerations don't belong in the document. They can and do inform the design.

[kazuho]

@sayrer

Is there any way for a client to tell the difference between a server operating in "Shared Mode" vs one in "Split Mode"? I support ECH as a wire protocol, but these deployment considerations don't belong in the document. They can and do inform the design.

That's a good point though I'm not sure if that follows the precedent we have.

In normal TLS/1.3, when the handshake succeeds, we assume that the owner of the private key corresponding to the certificate is either a) the owner of the ECDH key sent in ServerHello, or that b) there is a trust relationship between the owner of the former and the latter.

b is the so-called "Keyless SSL" case.

We do not have a wire signal that distinguishes between the two.

IMO, ECH in Split Mode is no different from the Keyless SSL case modulo the fact that we explicitly talk about a split deployment without stating that there should be a trust relationship.

Hence my original comment suggests adding a statement that requires such trust relationship.

[huitema]

I would expect the exchanges between the client-facing server and the backed server to run on some kind of private network, maybe using something like Masque. If third parties can spoof the client-facing server, then, yes, there will be all kinds of issues. And simply encrypting this front-to-backend traffic may not be enough. If the traffic can be observed, the observers can send ECH requests to the frontend, and see where the next packets from the server go.

[huitema]

Maybe you need to add some guidance in the draft about fronting-backend communications. Could be in the security considerations. If third parties can spoof a fronting server then there are certainly some plausible attacks. If third parties can observe the traffic between fronting and backend, there are other possible attacks.

[richsalz]

Strong +1 to @huitema 's comments above. I could do a PR if needed.

[huitema]

The more I think of it, the more I think that the "split" works well if fronting and back-end servers are in the same data center. For example, some load balancing scenario in which a specific pool of back-end servers handles a specific SNI. Then, the attack surface is pretty much the same as attacks against the classic LB to back-end communication. If the communication between fronting and back-end goes over the public Internet, we are closer to a proxy scenario and we have to worry about all the attacks against proxy servers.

[sayrer]

Maybe you need to add some guidance in the draft about fronting-backend communications. Could be in the security considerations. If third parties can spoof a fronting server then there are certainly some plausible attacks. If third parties can observe the traffic between fronting and backend, there are other possible attacks.

This is all true, but these considerations have little to do with ECH. It's not ECH, after all.

I guess I'd say I think the draft is wrong to lead with "topologies", since they do not change the protocol. After that, they only get briefly mentioned.

[kazuho]

IIRC, there were people who showed their interest in deploying ECH in split mode. That's why we have the requirement in RFC 8744 section 3.6, after all.

Considering that fact, I think it'd be favorable to retain the distinction of the topologies as well as the notion of client-facing and backend servers, and also to expand deployment requirements / recommendations for Split Mode, as @huitema and @richsalz have argued. Unless we write them down, the risk becomes higher of people deploying Split Mode in risky ways.

[sayrer]

IIRC, there were people who showed their interest in deploying ECH in split mode.

Sure, no argument. The document is poorly organized, though. Section 3 should start with what is now 3.2, and refer to the "topologies" with something like "See section 10 (Security Considerations)". In the current draft, "Split Mode" doesn't appear again until Section 10.7, and "Shared Mode" never appears again.

[chris-wood]

@kazuho can you please take a look at #564 and let me know if this clarification resolves your concern? I attempted to describe what assumptions are in place about the attacker and their capabilities, with special emphasis on split mode.