Server's initial plaintext packet should be PMTU sized

[janaiyengar]

Sec 9 should include this, without which the PMTU discovery that happens with client + server handshake packets is not complete.

[huitema]

I was thinking, what about DOS amplification attacks, if the server plaintext is larger than the client initial? But in fact, the server plain text is already larger than the client initial -- certificates are large enough to often require two packets.

[huitema]

OTOH, I would not call that PMTU discovery. You are speaking about the minimum MTU of 1532/1552 bytes, right?

Another way to see that is that the server should assume that the "guaranteed" MTU is at most the size of the largest packet that it sent during the handshake.

[janaiyengar]

@huitema: Yes, exactly. There's no text right now for the server to know what it's max packet size ought to be. I was going to suggest that the server use the size of the client's first packet, unless it knows that the PMTU in the server -> client direction is smaller, in which case, it uses a smaller size. Either ways, this ought to become the max packet size for the server.

[ianswett]

PR #1013 is very bit-rotten.

I think the current text is sufficient? It was updated after the new crypto handshake design.
https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#packet-size-packet-size

[janaiyengar]

Yup, this is dead.