On Tue, Sep 20, 2011 at 03:33:42PM -0400, Nick Mathewson wrote:
Design: Indicating variable-length cells.
Beginning with the v3 link protocol, we specify that all cell types in the range 128..255 indicate variable-length cells. Cell types in the range 0..127 are still used for 512-byte cells, except that the VERSIONS cell type (7) also indicates a variable-length cell (for backward compatibility).
As before, all Tor instances must ignore cells with types that they don't recognize.
Sounds good.
Design: Variable-length padding.
We add a new variable-length cell type, "VPADDING", to be used for padding. All Tor instances may send a DROP cell at any point that a VERSIONS cell is not required; a VPADDING cell's body may be any length; the body of a VPADDING cell MAY have any content. Upon receiving a VPADDING cell, the recipient should drop it, as with a PADDING cell.
Also sounds fine. But to clarify, did you mean to talk about a DROP cell in one of those sentences? I think you meant to say VPADDING there?
Also to be clear, there's no way to send a variable-length padding cell that's less than 5 bytes, right? I don't imagine that will bite us immediately, but we should call it out as a known constraint.
By "the body of a vpadding cell may have any content", did you have in mind to randomize it to help protect against future TLS gotchas? Or just to leave us the option to do so in the future?
Interaction with proposal 176:
Proposal 176 says that during the v3 handshake, no cells other than VERSIONS, AUTHENTICATE, AUTH_CHALLENGE, CERT, and NETINFO are allowed, and those are only allowed in their standard order. If this proposal is accepted, then VPADDING cells should also be allowed in the handshake at any point after the VERSIONS cell. They should be included when computing the "SLOG" and "CLOG" handshake-digest fields of the AUTHENTICATE cell.
Ok.
--Roger