RE: How does a server identify a new connection?

[Mike Bishop <[e-mail]>]

The layering on using CH is problematic.  If the server is supposed to ignore the attacker's packet, that implies that it pre-parses the contents of the Initial into the TLS data before deciding whether to actually injest the packet.  I don't think a productive solution lies there.  At the same time, I agree it would be nice to be able to protect against these attacks, iff we can find a straightforward way.  I think some of the ideas here are heading in the right direction.



IIUC, the attack is that the attacker races an Initial containing a different ClientHello, some DCID (maybe same as client’s, maybe different), the same SCID as the client (easy if the client uses zero-length), and spoofs the client’s source IP:port.



Then:

  *   If attacker uses same DCID as client but modifies the ClientHello, server can discard the packet without processing it and await the real packet
  *   If attacker uses different CID from client, server sees it as a separate connection attempt; client can identify and discard these packets (even if it used a zero-length SCID).



With no shared context, this is a challenging problem.  Handshake packets will already have this property – decryption will fail and they’ll get dropped if it’s in response to the attacker’s Initial.  But if the Initial packet received from the server was responsive to the attacker, the client will generate the wrong Handshake key and drop the real Handshake packets as well, so the attack succeeds.



If the server were to reflect back something to uniquely identify the Initial that it received, the client could discard responses to the attacker and wait for the response to its own message.  As Mikkel suggests, the authentication tag might work here, which would give us the second property.  If clients retransmit with different packet numbers, they simply remember multiple outstanding tags.  A sufficiently unique SCID is a weaker defense, but still requires the attacker to see the real packet before crafting the false one.



For the first property, Igor’s idea seems sensible.  If the initial DCID were a hash of the unencrypted packet payload, that doesn’t require interpreting the ClientHello, just the bytes at the transport.  Then the server would accept Initials with either this property or a valid token from a Retry.



HRR makes that more difficult; perhaps the client’s second Initial similarly includes proof / identification of which server Initial it’s responding to.



Of course, if clients just always used a non-zero-length SCID, this attack would be less likely to work.  Maybe the simpler change is to require a non-zero-length SCID during the handshake, then provide a way to switch to a zero-length CID post-handshake?  It doesn’t close the door as effectively, but it makes the attack harder and is a much smaller change this late in the process.



-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Lubashev, Igor
Sent: Thursday, November 29, 2018 7:53 AM
To: Kazuho Oku <[e-mail]>; Martin Thomson <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: RE: How does a server identify a new connection?



A simpler way would be making Client Initial CID be not just a random string of bits but a hash of the rest of the CI packet.



If the H(CI) is not included in the server's initial, how does the client know which of the SI packets is a reply to the attacker's CI and which is a reply to client's own CI?



- Igor





> -----Original Message-----

> From: Kazuho Oku <[e-mail]<mailto:[e-mail]>>

> Sent: Wednesday, November 28, 2018 10:02 PM

> To: Martin Thomson <[e-mail]<mailto:[e-mail]>>

> Cc: IETF QUIC WG <[e-mail]<mailto:[e-mail]>>

> Subject: Re: How does a server identify a new connection?

>

> 2018年11月29日(木) 11:50 Martin Thomson <[e-mail]<mailto:[e-mail]>>:

> >

> > On Thu, Nov 29, 2018 at 1:41 PM Kazuho Oku <[e-mail]<mailto:[e-mail]>>

> wrote:

> > > The question is what happens if a man-on-the-side attacker races

> > > an Initial packet with the same 5-tuple, same SCID / DCID, but

> > > having different values in other fields.

> >

> > Yep, can't guarantee a win here.

>

> My proposal is that we _can_ guarantee a win, if we use a hash value

> derived from ClientHello as an identifier of a connection attempt.

>

> This is because ClientHello is the only thing that could be different

> to cause a connection establishment attempt to fail, assuming that we adopt PR #2045.

>

> > So that makes me inclined to say

> > that we don't put it in the draft.  If it turns out to be useful, we

> > can regret it later, but writing down a defense that doesn't really

> > work that well doesn't seem right.

>

>

>

> --

> Kazuho Oku