Clarify 1200 bytes Initial packet rule

[tatsuhiro-t]

While reading https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.14, one can read that any Initial packet from client and server MUST be padded to at least 1200 bytes.

The payload of a UDP datagram carrying the Initial packet MUST be expanded to at least 1200 bytes, by adding PADDING frames to the Initial packet and/or by combining the Initial packet with a 0-RTT packet (see Section 12.2).

My understanding is that only client first Initial packet MUST be 1200 bytes. If it is correct, it would be nice to explicitly state that so.

[ianswett]

In an effort to prevent handshake deadlocks due to the amplification factor limiting the number of bytes the server can send, I think it's wise to pad all UDP packets containing a client Initial. I suspect that is why the text is written that way.

[marten-seemann]

This is needed in the following case: The server sends a ServerHello that spans two (INITIAL) packets, one of which is lost, and then starts sending the cert (in HANDSHAKE packets) until it is blocked by the 3x limit. The client will send an ACK for the one INITIAL packet that arrived.
In order for the server to be unblocked from the 3x limit and to be able to retransmit the lost INITIAL packet, the packet sent by the client must be at least 1/3 of the size of lost packet. It doesn't hurt if it's larger than that, because the server can then continue sending the cert.

[tatsuhiro-t]

It would be nice to state that it is a requirement for client and not server.

[tatsuhiro-t]

Regarding when to stop padding Initial:

Clients MUST pad UDP datagrams that contain only Initial packets to 1200 bytes. Once a client has received an acknowledgment for a Handshake packet it MAY send smaller datagrams. Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction.

I think that client can stop padding Initial when it has CRYPTO frame to send in Handshake packet. This is because at this time server has nothing to send and client will retransmit Handshake packet thus no dead lock.

[marten-seemann]

With the fix for the Initial injection attack that we discussed in Bangkok, the client won't send any more Initial packet after transitioning to Handshake keys.

[martinthomson]

Let's roll this up into the changes for dropping Initial keys early. @marten-seemann, I don't see your slides in the quicwg/wg-materials repo, can you create a PR for that?

[marten-seemann]

Done: quicwg/wg-materials#96

[MikeBishop]

Fixed in a326fec.