RE: How does a server identify a new connection?

["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).


> 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.

- Igor