Re: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)

[Christian Huitema <[e-mail]>]

This scenario is not a great fit for the extension mechanism. Extensions are normally negotiated using transport parameters. We could see an exchange such as:

* Client: set "minimal_initial_packet_size = 512"
* Server: set "minimal_initial_packet_size = 768"

After which the client would remember the minimal initial packet size for this application as the maximum of the client proposed value and the server proposed value, or 1200 if either the client or the server do not set the parameter. The client could then remember that value with the session ticket, and use it for resumed connections.

But the client would not be able to use this for the first exchange with the server -- that's the limit of our extension mechanism. If we want shorter first packets in general, the alternate minimal initial has to be part of the application specification.

On the other hand, even an application specification is a bit problematic if the server multiplexes several applications and demuxes on the ALPN. The server will only be able to verify that the size is OK after obtaining the ALPN, which means after processing the Initial packet. With the current spec, the server can reject packets too short before doing any processing.

-- 
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/3523#issuecomment-599121809