Re: [TLS] TLS ECH, how much can the hint stick out?

[Christopher Patton <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Christopher Patton
> *Sent:* Tuesday, September 8, 2020 2:23 PM
> *To:* Christian Huitema <[e-mail]>
> *Cc:* [e-mail]
> *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.
>