Certainly it’s better for the server if it can be consistent, especially if it expects multi-packet first flights. If the same back-end sees both, it can discard the second, and that’s what I’d expect most of the time. But here’s what I think is possible:
The client sends an Initial packet (randomly selected Destination CID), PTOs, then sends another Initial packet to the same Destination CID. On the server side, the infrastructure assumes that Initial packets whose CIDs aren’t issued by them can be routed to a random back-end, and that back-end will set a new DCID that routes to it in the future. The client will receive either of the Server Initial packets, switch to the new DCID, and will reject the other because attempts to change the server’s CID a second time. The connection succeeds because whichever server’s ServerHello is used also has its DCID used, so all subsequent packets go to that back-end. From: Eric Rescorla <e...@rtfm.com> Sent: Thursday, September 10, 2020 3:58 PM To: Mike Bishop <mbis...@evequefou.be> Cc: Christopher Patton <cpatton=40cloudflare....@dmarc.ietf.org>; Christian Huitema <huit...@huitema.net>; tls@ietf.org Subject: Re: [TLS] TLS ECH, how much can the hint stick out? On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop <mbis...@evequefou.be <mailto:mbis...@evequefou.be> > wrote: This is primarily an active attack, but not purely so. Clearly the MITM is an active attacker, but there are situations in QUIC (and DTLS, I presume) where a ClientHello gets retransmitted. Depending on server infrastructure, the client might get two different responses. This doesn't sound correct. In this circumstance, the client and the server might have mismatched SH values and the handshake will fail. To the best of my knowledge, the server is required to behave consistently in this case, even if it consists of multiple machines. -Ekr So I think we need to decide whether it’s a goal that, given that relatively narrow situation, the observer shouldn’t be able to identify ECH acceptance by comparing two ServerHellos that both respond to the same ClientHello. From: TLS <tls-boun...@ietf.org <mailto:tls-boun...@ietf.org> > On Behalf Of Christopher Patton Sent: Tuesday, September 8, 2020 2:23 PM To: Christian Huitema <huit...@huitema.net <mailto:huit...@huitema.net> > Cc: tls@ietf.org <mailto:tls@ietf.org> Subject: Re: [TLS] TLS ECH, how much can the hint stick out? Hi Christian, Hi list, The "don't stick out" property is a steganographic security goal: we want the "real" protocol, i.e. TLS with ECH acceptance, to be indistinguishable from the "cover" protocol, i.e., the handshake pattern in which the client sends a "dummy" ECH extension that is ignored or rejected by the server. This is a property that TLS was never designed to have, but it seems that we need some degree of it in order to deploy ECH. The fundamental question that Christian raises is what is the right threat model for this property. The "status quo" threat model considers a distinguisher that is strictly passive---it does not interfere with a handshake or probe the server---and that does not know the ECH configuration. This seems (to me, at least) sufficient to account for middleboxes that might ossify on the ECH extension. It also seems achievable, both by the ECH as it is and for the proposed change. The distinguishing attacks described by Christian are much stronger, in the sense that they involve an active attacker. I don't believe there is any way of implementing ECH---either as it is or with the proposed change---that defeats active attacks in general. In particular---and as Christian points out---an active attacker can probe the server to learn the ECH configuration (via the ECH retry logic), which it can use to easily distinguish the real protocol from the cover protocol. This works regardless of whether the change is adopted. In my view, achieving don't-stick-out-security against active attackers requires us to revisit the design of ECH altogether. The main difficulty is that client-facing servers publish the ECH configuration in a way that's easily accessible to an active attacker. Keeping the configuration secret may provide a way to achieve security, and some deployments might opt to do this; but the vast majority won't. We might consider adding support for this deployment scenario, but this can (and should, I think) wait for a later draft. That said, it is worth considering mitigations against known attacks, in particualr (1). I think the suggestion for mitigating (2) adds too much complexity, and if it doesn't fully address the intended threat model (I don't think it does), then we'll likely need to replace it in the future. I think it's better to keep things simple until we fully address the intended threat model. Best, Chris P. _______________________________________________ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
