Re: How does a server identify a new connection?

[Kazuho Oku <[e-mail]>]

2018年11月30日(金) 6:38 Lubashev, Igor <[e-mail]>:
>
> > -----Original Message-----
> > From: Christian Huitema <[e-mail]>
> >
> > On 11/29/2018 11:06 AM, Mike Bishop wrote:
> >
> > > 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.
> >
> > This is making the assumption that if the client repeats an Initial packet, the
> > content will be exactly the same. I know that this is false in at least one case:
> > the first UDP packet contains a short Initial packet coalesced with a 0-RTT
> > packet; the repeated Initial packet contains a long Initial packet, padded up
> > to the required length.
> >
> > If you want to make that work, you want the DCID to be a hash of the crypto
> > frame inside the Initial packet.
>
> I am not sure I see why the coalesced packet matters, since the protection is for the integrity of the Initial QUIC packet only (not the entire UDP datagram).  It seems to be better to protect the entire packet and not just the crypto frame(s).

In addition to PADDING and PN being different, the content of the
CRYPTO frame will be different for the 2nd ClientHello when HRR is
involved.

Therefore, distinguishing different handshake contexts need to be done
using the CRYPTO frame of the first Initial (which is the first
ClientHello message).

>
>
> > But I don't understand very well how that's
> > supposed to be verified by the server. Do we want to specify a default hash
> > algorithm?
>
> The server would need to know the algorithm used.  Any cryptographic hash function would do, but it would need to be specified.
>
> The downside, of course, is another case of multi-path encryption: plaintext -> DCID -> initial packet encryption.

The approach does not help the client, because a middlebox can spoof
the server's Initial packet. A client needs to collect all the Initial
packets it receives, and determine which one was correct. This is why
the complexity is O(N * M) on the client side, as I pointed out in the
mail that started this thread.

>
> - Igor



-- 
Kazuho Oku