Trying to reply succinctly inline below! On Mon, Mar 23, 2020, at 3:54 AM, Nick Sullivan wrote: > 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 design: both. > 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. Agreed. I think we should assume that attackers know which servers support ECHO and which do not. > 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. It's definitely an active attack. I don't disagree that it's possible to fix. What I am concerned with is the cost of fixing it. > 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? Yep -- David's attack still applies. If the outer CH has no ciphersuites and the connection succeeds, then the inner CH was used. > 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? Not that specific one. But we probably shouldn't pick and choose which things we need to bind, as that was problematic in past designs. Instead, we would probably need to bind the entire outer CH to the inner CH. (The current design has the machinery to do this: export a PSK from the HPKE context and use it to compute a binder over the outer CH.) > > 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. Admittedly, this is a nice feature. However, I don't have confidence in its efficacy without server-side changes. (This is probably worth a separate thread.) Thanks! Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
