Replies inline again. On Mon, Mar 23, 2020 at 8:40 AM Christopher Wood <c...@heapingbits.net> wrote:
> 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. > This malleability seems troublesome. My position has been that with ECHI/ESNI, we are introducing a new threat model into TLS, one in which the handshake no longer protects high-entropy secrets, but also low-entropy secrets. With low-entropy secrets, the risks of oracles from taking chunks of the handshake and plugging them into different flows is high, so malleability is a risk. My intuition here is that having malleability also makes the analysis (say, with Tamarin) much more complex. > 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.) > We have a binding mechanism right now, OuterExtensions.hash. In the default case where inner and outer cipher lists are the same, the inner cipher list will be a pointer to the outer cipher list with a hash. Any modification of the outer extensions will result in a different OuterExtensions.hash, causing the ECHO extension to become invalid. I'm not saying that this is the only attack of the type, but that we do have a binding mechanism that defends against it. The OuterExtensions feature is a weak binding mechanism, though. It only applies to extensions that are identical for both inner and outer CH. I would be (again) in favor of exporting a PSK from the ECHO and using it as a binder for the outer client hello. You mentioned that this may be too much juice to squeeze, but is it? The only conflict I can see with TLS 1.3 is during resumed connections, in which two binders need to be verified, which doesn't seem like a big deal since binders already cover each other. Having a binder over the outer handshake also removes the need for the additional overhead of the OuterExtensions.hash. I consider both active and passive blocking to be threats since both in-line (middlebox blocks on known extension) and probe-based post-hoc blocking (middlebox replays client hello to see certificate) are both deployed in middleboxes today. With a PSK binder and the proposed mechanism above (always fall back to retry_keys if the ECHO extension or the binder is corrupt), I don't see a mechanism for an attacker to test whether the inner or outer CH was used for a given connection. Still, I'd like to see a proof of this from the theoreticians. Adding an explicit signal on the wire seems like a very bad choice since it makes inline blocking trivial (and likely!), which could hinder the ability to ramp up deployment. Upgrading from a widely deployed blockable solution to a non-blockable solution seems like it will be challenging. We should fix this now rather than later. > > > 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.) > What do you mean by efficacy? Once we have a PoC of an ECHO load balancer, I'd be happy to share it. > > Thanks! > Chris >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
