I have reservations. On Sun, Mar 22, 2020 at 9:54 AM Christopher Wood <c...@heapingbits.net> wrote:
> One of the original motivating requirements for ECHO (then ENSI) was "do > not stick > out" [1]. This complicates the current ECHO design, as clients must > trial decrypt > the first encrypted handshake message to determine whether a server used > the inner > or outer ClientHello for a given connection. It's also trivial to probe > for ECHO > support, e.g., by sending a bogus ECHO with the same key ID used in a > target client > connection and checking what comes back. Do you mean that it’s trivial for an attacker to probe a server for ECHO support or whether it’s trivial to check if a given connection used ECHO or not? In the current draft it seems trivial to identify servers that support ECHO by: - querying DNS and seeing whether the record exists - connecting to the server with an ECHO extension that has a random key ID and ECHO ciphertext and checking if the server returns “retry_keys” (yes means ECHO support) Both of these can be done without observing a specific connection. If we’re talking about “don’t stand out,” would it be fair to consider the attack you hinted at above as an active attack to identifies whether a given connection used ECHO or not (3b in Ben’s email)? If so, it points to a weakness in the current protocol description that could be remedied. Here are three scenarios: Client connects to confirmed ECHO-enabled server with valid key: 1) client connects to server using an ECHO extension created with a valid key ID and a valid ciphertext for that ID 2) server responds with handshake encrypted using the inner CH Client connects to confirmed non-ECHO-enabled server with GREASE: 1) client connects to server using an ECHO extension with a random invalid key ID, and an invalid ciphertext 2) server responds with handshake encrypted using the outer CH, no retry_keys Client connects to ECHO-enabled server with GREASE (say DNS was blocked): 1) client connects to server using an ECHO extension with a random invalid key ID, and an invalid ciphertext 2) server responds with handshake encrypted using the inner CH, sends default cert and retry_keys For these scenarios, the attacker collects the handshakes and key IDs, and wants to determine which is which. The attacker then probes the servers with three connections: A. client connects to ECHO-enabled server using an ECHO extension with a valid key ID (taken from a connection), and an invalid ciphertext The server will match the key ID and return “decryption_error” when the ECHO ciphertext fails to decrypt. B. client connects to ECHO-enabled server using an ECHO extension with an invalid key ID (taken from a GREASE connection), and an invalid ciphertext The server will respond with handshake encrypted using the outer CH, including retry_keys. C. client connects to non-ECHO-enabled server using an ECHO extension with a the invalid key ID (taken from a GREASE connection), and an invalid ciphertext The server will respond with handshake encrypted using the outer CH. All three are distinguishable. This lets the attacker know whether a given connection actually used ECHO (outer handshake) or GREASE for an ECHO -enabled site. This shows that we don’t currently have property 3a from Ben’s reply. A simple way to eliminate this oracle would be for the server to treat ECHOs that have valid IDs but are corrupted or don’t match the outer CH differently: treat them as GREASE handshakes and respond using the outer CH and retry_keys. This would make the results from A and B indistinguishable. Given this modification, is there still an active attack to determine if a specific connection used the outer or inner CH? Does David Benjamin’s cut-and-paste attack still work if the cipher list in the inner client hello is just a pointer to the cipher list in the outer client hello? > > I propose we remove this requirement and add an explicit signal in SH > that says > whether or not ECHO was negotiated. (This will require us to revisit > GREASE.) A downside of this modification is that ECHO is no longer able to be used by existing TLS 1.3 servers without modification. One of the neat features of ECHO is that a a server-controlled proxy that only has access to ESNI keys can determinate which client hello to use (inner vs. outer). This allows a shim proxy to decrypt ECHO (or fail to) and send a singular CH on to the real server running unmodified TLS 1.3 software. This modularity opens up a massive opportunity for the large TCP load balancing providers out there with a lot of IP space to enable ECHO for legacy applications without needing access to their private key. Having a signaling extension in the handshake eliminates this deployment scenario (one that CF is currently exploring). Of course, without modifying the server, ECHO is less effective since it won’t be possible to apply padding to the server’s portion of the handshake. However, being able to deploy ECHO as an independent proxy service is something I consider a huge plus of the current design. We’d be losing it by adding a new signaling extension. > > What do others think? > > Thanks, > Chris (no hat) > > [1] > https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09#section-3.4 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
