Hi Mike, I've since updated the proposal to address the replay attack, but not Christian's MITM attack: https://github.com/tlswg/draft-ietf-tls-esni/pull/287
A quick question about Chrisitian's suggestion of using the "key_shares" to derive the hint. I believe a slightly stronger variant of the MITM attack beats this mitigation: suppose the server replays not only the original hint, but also the original "key_shares" shares extension. It won't be able to decrypt the client's response, but can't the attacker still detect ECH usage? Best, Chris P. On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop <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 isn’t > limited to cases where the observer/attacker is the one performing the > replay. > > > > 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> *On Behalf Of *Christopher Patton > *Sent:* Tuesday, September 8, 2020 2:23 PM > *To:* Christian Huitema <huit...@huitema.net> > *Cc:* 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 https://www.ietf.org/mailman/listinfo/tls
