Re: [quicwg/base-drafts] Client's initial destination CID is unauthenticated (#1486)

[Kazuho Oku <[e-mail]>]

> Ahh, though it's only the first one, that might be enough. Not sure how much this matters, but we should do something, even if that is only write this down.

Yes.

Consider you want to build a middlebox that verifies Client Hello. What you might do is:
* precompute AES-CTR for a special 8-octet CID (e.g., 0000000000000000)
* send a Retry packet that contains the special CID in the source CID field and a zero-length token for every Initial packet that does not contain the special CID in the destination CID field

By doing these, a middlebox can skip the cost of AES for decrypting the Initial packet, because the every Initial packet that it forwards will be encrypted using the same bitstream.

I think we should permit the use of zero-length token, because it would be useful for *stateful* path validation.

OTOH, I would like to prevent seeing these kind of hacks being applied by middleboxes (since it is an ossification concern), if the cost of preventing it is marginal. IMO, including initial DCID in TP and requiring the servers to validate the value when possible meets that goal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1486#issuecomment-400568727