Re: [quicwg/base-drafts] Endpoints cannot verify padding (#4253)

[Kazuho Oku <[e-mail]>]

@martinthomson @gloinul I totally agree that this has to stop. I'm sorry to have missed this point when working on #4188; I realized the problem when I was wondering about the MUST vs. SHOULD discussion in #4241.

That said, I do think that it would be a good idea to adopt the proposal in this issue.

Let me go through the facts first. They are:
* An encrypted transport has to discard unauthenticated signals to prevent MOTS attackers from disrupting the connection.
* The size of the datagram is an unauthenticated signal throughout the lifetime of the connection. As noted above, this is the case for 1-RTT packets after handshake confirmation too.

Due to these facts, "MUST NOT close, can discard" is a principle that we've always had. The reason we hadn't written it down is because we used to have only one requirement regarding datagram length, that correctly follow the principle, stating that "servers MUST discard non-full-sized datagrams containing Initial packets."

But now that we have emerging consensus that datagrams carrying PATH_CHALLENGE / PATH_RESPONSE MUST be padded to full size (#4241), we need to write down that the receiver cannot enforce that.

Realizing that, I started to wonder if the "MAY close" rule that we added in #4188 has been correct.

As @janaiyengar points out, #4188 is a change that has not shipped yet. It's a recent change due to an issue discovered during *this* IETF last call. I do not think we have official consensus yet.

Therefore, I tend to think there would be less confusion if the next draft would contain:
* servers MUST pad datagrams carrying ack-eleciting Initial packets (the basis of #4188)
* endpoints MUST pad datagrams carrying PATH_CHALLENGE / PATH_RESPONSE frames (#4241)
* endpoints MUST NOT close a connection when receiving datagrams with size requirements (#4254)

rather than having two different of rules for handling small-sized datagrams, of which one does not follow the 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/4253#issuecomment-712764115