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

[Ben Schwartz <[e-mail]>]

I don't know enough about QUIC's connection management rules to know
whether Mike's scenario here is strictly compliant, but I don't think we
need to figure that out, because the mitigation (mixing in
ServerHello.Random[0:24]) is pretty trivial.

The interesting question here is about mixing in the server key_share,
which seems somewhat less trivial.

On Thu, Sep 10, 2020 at 5:22 PM Mike Bishop <[e-mail]> wrote:

> 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-mail]>
> *Sent:* Thursday, September 10, 2020 3:58 PM
> *To:* Mike Bishop <[e-mail]>
> *Cc:* Christopher Patton <cpatton=[e-mail]>;
> Christian Huitema <[e-mail]>; [e-mail]
> *Subject:* Re: [TLS] TLS ECH, how much can the hint stick out?
>
>
>
>
>
>
>
> 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 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 <[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.
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>