On 3/23/2021 4:48 PM, Stephen Farrell wrote:
Hiya,
On 23/03/2021 22:52, Christopher Patton wrote:
I think the right thing here would be to analyse that attack
again and re-evaluate which of the two answers now seems
best. For me, the github issue discussion didn't leave
behind enough information to do that. (Or I need to stare
at it some more maybe:-)
If we constrain the model so that the "don't stick out" attacker is
The attack is more one that allows the adversary to
distinguish a real ECH attempt vs GREASE, right? So
we need to start out assuming that GREASEd CH's are
fairly well done. (Which is fine but might need to
be explained some more in the draft maybe.)
passive, then PR#287
(https://github.com/tlswg/draft-ietf-tls-esni/pull/287
suffices). The attack described at the top of PR#353 (
https://github.com/tlswg/draft-ietf-tls-esni/pull/353) is what led
everyone
to agree that the acceptance confirmation needed to be derived from the
secret shared by the client and backend server. It's an active "don't
stick
out" attack. Basically, the attacker replies to the client's CH with a
bogus SH; and by observing the client's reply, it can learn whether the
client sent real or GREASE ECH.
Doesn't that imply that the 2nd flight message sizes, and
the timing of producing (and consuming) those, mustn't allow
the observer to distinguish the reaction to a real ECH vs. a
GREASEd one?
That may be a bit of an aside, but it may also mean that if
we don't believe we can get constant time such that the
passive attack here fails, then we also aren't really that
worried about these active attacks. I'm also not sure we yet
know how to use padding so that sizes don't give away the
game. (I know I'm not yet sure about that for sure:-)
There are a number of variants of this
basic attack, some of which can be pulled off without actually
tipping off
most clients.
Ack. And maybe there are other active attacks that could
distinguish a real ECH attempt vs. GREASE based on the
adversary interacting with the server - mightn't e.g. the
timing of handling a simple replay of the ECH octets reveal
if those were GREASE or not?
If we intend to thwart active "don't stick out" distinguishers, then
PR#353
seems necessary to me. The key difference between PR#287 and PR#353 is
that, in the latter, the secret used to derive the acceptance signal is
authenticated. This isn't true in the former. I don't think trying to
find
a middle ground between PR#353 and PR#287 will be fruitful, unless we
can
hack in backend-server authentication by some means other than the
handshake signature.
You may well be right. It is hard to see a possible middle
ground. There is also the 3rd option of the original use of
a nonce in EncryptedExtensions - we might or might not
discard that due tothe QUIC argument raised earlier I guess.
Yes, a secret dependent nonce will also be able to verify that the
server has processed the ECH. But the nonce can only be sent as an
encrypted extension. That's fairly late in the process. That might work
for TLS over TCP, because the client can read the entire flight before
sending any information to the server. But a QUIC client cannot really
"remain silent until it has seen the nonce", it may have to send some
transport level acks in between. In the attack case, if the hint in the
HelloRandom matches the ECH case, the client will assume an ECH
handshake key, and it will not be able to decrypt the QUIC Handshake
packets sent by the attacker. The attacker will be able to detect that,
and thus distinguish ECH from !ECH.
-- Christian Huitema
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
