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

[Kazuho Oku <[e-mail]>]

I'm tempted to argue that this proposal should be considered as an extension, if we are to consider it.

Amount of data that a server might be willing to send before it confirms the client's address depends on if the server is resuming the TLS handshake. It is my understanding that the reason we require clients to pad Initial up to 1200 bytes is to provide server enough room to send the certificate chain before the client's address is confirmed. That room is unnecessary when the handshake is resumed.

However, it is questionable if a TLS server sending a session ticket is committed to getting the handshake being resumed. As an example, each server behind an anycast address might be issuing session tickets that can be only handled by the server that generated the ticket. This is fine, because resumption is considered as an "optimization."

I think we should stick to the design principle of TLS that resumption is an optimization that sometimes work, but not always guaranteed to be.

Allowing clients to send a small-sized Initial when attempting resumption goes against that principle.

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