The `padding` field in `welcome.proto` is declared as `bytes` with no documented upper bound on its length:
// Random bytes appended so that the encrypted Welcome size varies
// across sessions, mirroring Auth.padding.
bytes padding = 4;
A rogue or compromised Node can send a `Welcome` frame with an arbitrarily large `padding` value. The client must parse and buffer the entire proto message before it can inspect `status`, so the allocation happens before any application-layer check can reject the frame. There is no proto-level or documented protocol-level cap that a client implementation can enforce.
This is the post-auth counterpart of issue #18, which covers the same defect in `Auth.padding` from the client-to-Node direction. The threat model differs: here the attacker controls the Node (compromised infrastructure or a forged endpoint reached via DNS or routing manipulation), and the victim is the client process.
Add a comment to the `padding` field in `welcome.proto` specifying a concrete maximum, matching the cap that will be added to `Auth.padding` when #18 is resolved. Both fields serve the same traffic-analysis purpose, so the same bound applies.
The `padding` field in `welcome.proto` is declared as `bytes` with no documented upper bound on its length:
A rogue or compromised Node can send a `Welcome` frame with an arbitrarily large `padding` value. The client must parse and buffer the entire proto message before it can inspect `status`, so the allocation happens before any application-layer check can reject the frame. There is no proto-level or documented protocol-level cap that a client implementation can enforce.
This is the post-auth counterpart of issue #18, which covers the same defect in `Auth.padding` from the client-to-Node direction. The threat model differs: here the attacker controls the Node (compromised infrastructure or a forged endpoint reached via DNS or routing manipulation), and the victim is the client process.
Add a comment to the `padding` field in `welcome.proto` specifying a concrete maximum, matching the cap that will be added to `Auth.padding` when #18 is resolved. Both fields serve the same traffic-analysis purpose, so the same bound applies.